| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
into drm-next
Some final bits for 4.1. Some fixes for userptrs and allow a new
packet for VCE to enable some new features in mesa.
* 'drm-next-4.1' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: allow creating overlapping userptrs
drm/radeon: add userptr config option
drm/radeon: add video usability info support for VCE
|
|
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next
- gk20a iommu support
- gm107 graphics support without needing proprietary ucode
- various random fixes
- more gm20x bring-up, fifo/ce are ok, gr is mostly complete with the
exception of ctxsw ucode.. nvidia aren't playing nice yet so there's
not much more that can be done at this point...
I spent a lot of time trying to find a viable way of doing gr ctxsw
without signed firmware, but the "security" restrictions on the
fecs/gpccs falcons are excessive and go beyond what'd be necessary to
protect the host from malicious firmware. This newer nvidia hw is
VERY open-source unfriendly.
I have some experimental host-based ctxsw work that could be a viable
(albeit unsatisfactory and slow) workaround in the meantime, but it
needs some more work and i'd like to get the 3d driver working
properly before i commit to pushing it.
* 'linux-4.1' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (40 commits)
drm/nouveau/bios: fix fetching from acpi on certain systems
drm/nouveau/gr/gm206: initial init+ctx code
drm/nouveau/ce/gm206: enable support via gm204 code
drm/nouveau/fifo/gm206: enable support via gm204 code
drm/nouveau/gr/gm204: initial init+ctx code
drm/nouveau: support for buffer moves via MaxwellDmaCopyA
drm/nouveau/ce/gm204: initial support
drm/nouveau: add support for gm20x fifo channels
drm/nouveau/fifo/gm204: initial support
drm/nouveau/gr/gk104-: prevent reading non-existent regs in intr handler
drm/nouveau/gr/gm107: very slightly demagic part of attrib cb setup
drm/nouveau/gr/gk104-: correct crop/zrop num_active_fbps setting
drm/nouveau/gr/gf100-: add symbolic names for classes
drm/nouveau/gr/gm107: support tpc "strand" ctxsw in gpccs ucode
drm/nouveau/gr/gf100-: support mmio access with gpc offset from gpccs ucode
drm/nouveau/gr: fix engine name, cosmetic search+replace mistake
drm/nouveau/pmu/gk20a: add some missing statics
drm/nouveau/platform: fix probe error path
drm/nouveau/platform: release IOMMU's mm upon exit
drm/nouveau/gr/gk104-gk20a: call pmu to disable any power-gating before ctor()
...
|
|
nvbios_extend() returns 1 to indicate "extended the array" and 0 to
indicate the array is already big enough. This is used by the core
shadowing code to prevent re-fetching chunks of the image that have
already been shadowed.
The ACPI fetching code may possibly need to extend this further due
to requiring fetches to happen in 4KiB chunks.
Under certain circumstances (that happen if the total image size is
a multiple of 4KiB), the memory allocated to store the shadow will
already be big enough, causing the ACPI code's nvbios_extend() call
to return 0, which is misinterpreted as a failure.
The fix is simple, accept >= 0 as a successful condition here. The
core will have already made sure that we're not re-fetching data we
already have.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89047
v2 (Ben Skeggs):
- dropped hunk which would cause unnecessary re-fetching
- more descriptive explanation
Signed-off-by: Jan Vesely <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Uncertain whether the GPC pack change is due to a newer driver version,
or a legitimate difference from GM204. My GM204 has broken vram, so
can't currently try a newer binary driver on it to confirm.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Under certain circumstances the trapped address will contain subc 7,
which GK104 GR doesn't have anymore.
Notice this case to avoid causing additional priv ring faults.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
No idea if "3" is a constant or derived from something else, but the
value is unchanged in the limited traces of gm107/gm204 I have here.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Make static a few functions and structures that should be.
Signed-off-by: Alexandre Courbot <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
A "return 0" found its way in the middle of the error path of
nouveau_platform_probe(), remove it as it will make the kernel crash if
we try to unload the module afterwards.
While we are at it, also remove the IOMMU domain if it has been created,
as we should.
Signed-off-by: Alexandre Courbot <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
nvkm_mm_fini() was not called when exiting the driver, resulting in a
memory leak. Fix this.
Signed-off-by: Alexandre Courbot <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
On some of these chipsets, reading NV_PGRAPH_GPC_GPM_PD_PES_TPC_ID_MASK
can trigger a PRI fault and return an error code instead of a TPC mask,
unless PGOB has been disabled first.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Before we moved gk110's implementation of this to pmu, the functions were
identical. This commit just switches GK208 to use the new (more complete)
implementation of the power-up sequence.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Turns out the PTHERM part of this dance is bracketed by the same PMU
fiddling that occurs on GK104/6, let's assume it's also PGOB.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
So we can actually use the full 512 byte code space
Signed-off-by: Roy Spliet <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Roy Spliet <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
If a memory allocation fails when using the DMA allocator,
gk20a_instobj_dtor_dma() will be called on the failed instmem object.
At this time, node->handle might not be NULL despite the call to
dma_alloc_attrs() having failed. node->cpuaddr is the right member to
check for such a failure, so use it instead.
Reported-by: Vince Hsu <[email protected]>
Signed-off-by: Alexandre Courbot <[email protected]>
Reviewed-by: Thierry Reding <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
User-space use mappable BOs notably for fences, and expects that a
value update by the GPU will be immediatly visible through the
user-space mapping.
ARM has a property that may prevent this from happening though: memory
can be mapped multiple times only if the different mappings share the
same caching properties. However all the lowmem memory is already
identity-mapped into the kernel with cache enabled, so when user-space
requests an uncached mapping, we actually get an "undefined caching
policy" one and this has strange side-effects described on Freedesktop
bug 86690.
To prevent this from happening, allow user-space to explicitly specify
which objects should be coherent, and create such objects with the
TTM_PL_FLAG_UNCACHED flag. This will make TTM allocate memory using the
DMA API, which will fix the identify mapping and allow us to safely map
the objects to user-space uncached.
Signed-off-by: Alexandre Courbot <[email protected]>
Reviewed-by: Lucas Stach <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Let GK20A's instmem take advantage of the IOMMU if it is present. Having
an IOMMU means that instmem is no longer allocated using the DMA API,
but instead obtained through page_alloc and made contiguous to the GPU
by IOMMU mappings.
Signed-off-by: Alexandre Courbot <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Tegra SoCs have an IOMMU that can be used to present non-contiguous
physical memory as contiguous to the GPU and maximize the use of large
pages in the GPU MMU, leading to performance gains. This patch adds
support for probing such a IOMMU if present and make its properties
available in the nouveau_platform_gpu structure so subsystems can take
advantage of it.
Signed-off-by: Alexandre Courbot <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
instmem for GK20A is allocated using dma_alloc_coherent(), which
provides us with a coherent CPU mapping that we never use because
instmem objects are accessed through PRAMIN. Switch to
dma_alloc_attrs() which gives us the option to dismiss that CPU mapping
and free up some CPU virtual space.
Signed-off-by: Alexandre Courbot <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Now that Nouveau can operate even when there is no RAM device, remove
the dummy one used by GK20A.
Signed-off-by: Alexandre Courbot <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
GK20A does not have dedicated RAM, thus having a RAM device for it does
not make sense. Move the contiguous physical memory allocation to
instmem.
Signed-off-by: Alexandre Courbot <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Having a RAM device does not make sense for chips like GK20A which have
no dedicated video memory. The dummy RAM device that we used so far
works as a temporary band-aid, but in the longer term it is desirable
for the driver to be able to work without any kind of VRAM.
This patch adds a few conditionals in places where a RAM device was
assumed to be present and allows some more objects to be allocated from
the TT domain, allowing Nouveau to handle GPUs for which
pfb->ram == NULL.
Signed-off-by: Alexandre Courbot <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Notify interrupt is only used for cyclestats. We can just clear it and
avoid an "unknown stat" error that gets printed to dmesg otherwise.
Signed-off-by: Lauri Peltonen <[email protected]>
Signed-off-by: Alexandre Courbot <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Other methods in this file suggest this is the correct way to retrieve
the engine pointer.
Signed-off-by: Lauri Peltonen <[email protected]>
Signed-off-by: Alexandre Courbot <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
We use -1 to mean "not read from hw yet"
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
This if statement is correct but it wasn't indented, so it looked like
some code was missing.
Signed-off-by: Dan Carpenter <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Spotted by coccinelle:
drivers/gpu/drm/nouveau/core/subdev/fuse/gm107.c:50:5-8: WARNING: end returns can be simpified
Signed-off-by: Martin Peres <[email protected]>
Reviewed-by: Tobias Klausmann <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Similar to the Intel implementation, but instead of just falling back to a
global linear list when we have an overlapping userptr request we accumulate
all overlapping userptrs in a local list.
Signed-off-by: Christian König <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
This allows selecting CONFIG_MMU_NOTIFIER if it isn't already selected.
Signed-off-by: Christian König <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
git://git.pengutronix.de/git/pza/linux into drm-next
imx-drm changes to use media bus formats and LDB drm_panel support
- Add media bus formats needed by imx-drm
- Switch to use media bus formats to describe the pixel format
on the internal parallel bus between display interface and
encoders
- Some preparations for TV Output via TVEv2 on i.MX5
- Add drm_panel support to the i.MX LVDS driver, allow to
determine the bus pixel format from the panel descriptor.
* tag 'imx-drm-next-2015-03-31' of git://git.pengutronix.de/git/pza/linux:
drm/imx: imx-ldb: allow to determine bus format from the connected panel
drm/imx: imx-ldb: reset display clock input when disabling LVDS
drm/imx: imx-ldb: add drm_panel support
drm/imx: consolidate bus format variable names
drm/imx: switch to use media bus formats
Add RGB666_1X24_CPADHI media bus format
Add YUV8_1X24 media bus format
Add BGR888_1X24 and GBR888_1X24 media bus formats
Add LVDS RGB media bus formats
Add RGB444_1X12 and RGB565_1X16 media bus formats
drm/imx: ipuv3-crtc: Allow to divide DI clock from TVEv2
drm/imx: Add support for interlaced scanout
|
|
git://git.pengutronix.de/git/pza/linux into drm-next
drm: Use of-graph helpers to loop over endpoints
Convert all drm callers that use of_graph_get_next_endpoint to loop over
of-graph endpoints to the newly introduced for_each_endpoint_of_node
helper macro.
* tag 'of-graph-drm-2015-04-08' of git://git.pengutronix.de/git/pza/linux:
drm/rockchip: use for_each_endpoint_of_node macro, drop endpoint reference on break
drm/rcar-du: use for_each_endpoint_of_node macro
drm/imx: use for_each_endpoint_of_node macro in imx_drm_encoder_get_mux_id
drm: use for_each_endpoint_of_node macro in drm_of_find_possible_crtcs
of: Explicitly include linux/types.h in of_graph.h
dt-bindings: brcm: rationalize Broadcom documentation naming
of/unittest: replace 'selftest' with 'unittest'
Documentation: rename of_selftest.txt to of_unittest.txt
Documentation: update the of_selftest.txt
dt: OF_UNITTEST make dependency broken
MAINTAINERS: Pantelis Antoniou device tree overlay maintainer
of: Add of_graph_get_port_by_id function
of: Add for_each_endpoint_of_node helper macro
of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
This pull request contains just cleanup for atomic pageflip/modeset
support, and some fixeups.
We wanted to merge atomic pageflip/modeset feature support, new drivers
- MIC and DECON for exynos5433 SoC - and relevant patches this time.
However, I'd found that these features are not only safe enough
but also aren't tested yet. So for them, I'd like to have enough times
for the reviews.
* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm/exynos: Fix FIMD buffer size calculation
drm/exynos: Enable DP clock to fix display on Exynos5250 and other
drm/exynos: fimd: check whether exynos_drm_crtc_create succeed or not
drm/exynos: dsi: remove the empty mode_valid callback
drm/exynos: add ratio calculation
drm/exynos: use src_x and src_y instead of fb_x and fb_y
drm/exynos: mixer: add 2x scaling to mixer_graph_buffer
drm/exynos: remove superfluous error messages
drm/exynos: fix typos in hdmi and mixer
drm/exynos/ipp: Validate buffer enqueue requests
drm/exynos: track vblank events on a per crtc basis
drm/exynos: remove leftover functions declarations
drm/exynos: remove exynos_plane_destroy()
drm/exynos: make zpos property immutable
drm/exynos: preset zpos value for overlay planes
drm/exynos: remove struct *_win_data abstraction on planes
drm/exynos: remove unused exynos_crtc->win_enable() callback
drm/exynos: fimd: fix alpha setting for XR24 pixel format
|
|
Commit adacb228d72b ("drm: Exynos: Respect framebuffer pitch for
FIMD/Mixer") fixed the buffer size calculation by using the FB
pitch value but later commit 26b9c2813ede1 ("drm/exynos: remove
struct *_win_data abstraction on planes") added a regression so
fix the buffer size calculation again.
Tested on Chromebook Snow / Peach Pit.
Fixes: 26b9c2813ede1 ("drm/exynos: remove struct *_win_data abstraction on planes")
Signed-off-by: Daniel Stone <[email protected]>
Tested-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Gustavo Padovan <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
After adding display power domain for Exynos5250 in commit
2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
display on Chromebook Snow and others stopped working after boot.
The reason for this suggested Andrzej Hajda: the DP clock was disabled.
This clock is required by Display Port and is enabled by bootloader.
However when FIMD driver probing was deferred, the display power domain
was turned off. This effectively reset the value of DP clock enable
register.
When exynos-dp is later probed, the clock is not enabled and display is
not properly configured:
exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok
exynos-dp 145b0000.dp-controller: unable to config video
Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
Cc: <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Reported-by: Javier Martinez Canillas <[email protected]>
Tested-by: Javier Martinez Canillas <[email protected]>
Tested-by: Andreas Färber <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
>From the commit "drm/exynos: fix the execution order in FIMD
initialization" (598285bfdce46d7c47632a2ba4b980f60be4a677), the error
checking code is removed improperly. This patch fix the regression.
Signed-off-by: Hyungwon Hwang <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|