Christian König [Wed, 19 Aug 2015 14:12:15 +0000 (16:12 +0200)]
drm/amdgpu: rework scheduler submission handling.
Remove active_hw_rq and it's protecting queue_lock, they are unused.
User 32bit atomic for hw_rq_count, 64bits for counting to three is a bit
overkill.
Cleanup the function name and remove incorrect comments.
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com>
Junwei Zhang [Wed, 19 Aug 2015 08:24:19 +0000 (16:24 +0800)]
drm/amdgpu: modify amdgpu_fence_wait_any() to amdgpu_fence_wait_multiple()
Rename the function and update the related code with this modified function.
Add the new parameter of bool wait_all.
If wait_all is true, it will return when all fences are signaled or timeout.
If wait_all is false, it will return when any fence is signaled or timeout.
Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: Monk Liu <monk.liu@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd
Most of the time this isn't an issue since hotplugging an adaptor will
trigger a crtc mode change which in turn, causes the driver to probe
every DisplayPort for a dpcd. However, in cases where hotplugging
doesn't cause a mode change (specifically when one unplugs a monitor
from a DisplayPort connector, then plugs that same monitor back in
seconds later on the same port without any other monitors connected), we
never probe for the dpcd before starting the initial link training. What
happens from there looks like this:
- GPU has only one monitor connected. It's connected via
DisplayPort, and does not go through an adaptor of any sort.
- User unplugs DisplayPort connector from GPU.
- Change in HPD is detected by the driver, we probe every
DisplayPort for a possible connection.
- Probe the port the user originally had the monitor connected
on for it's dpcd. This fails, and we clear the first (and only
the first) byte of the dpcd to indicate we no longer have a
dpcd for this port.
- User plugs the previously disconnected monitor back into the
same DisplayPort.
- radeon_connector_hotplug() is called before everyone else,
and tries to handle the link training. Since only the first
byte of the dpcd is zeroed, the driver is able to complete
link training but does so against the wrong dpcd, causing it
to initialize the link with the wrong settings.
- Display stays blank (usually), dpcd is probed after the
initial link training, and the driver prints no obvious
messages to the log.
In theory, since only one byte of the dpcd is chopped off (specifically,
the byte that contains the revision information for DisplayPort), it's
not entirely impossible that this bug may not show on certain monitors.
For instance, the only reason this bug was visible on my ASUS PB238
monitor was due to the fact that this monitor using the enhanced framing
symbol sequence, the flag for which is ignored if the radeon driver
thinks that the DisplayPort version is below 1.1.
Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
Christian König [Tue, 18 Aug 2015 19:09:33 +0000 (21:09 +0200)]
drm/amdgpu: fix CS error handling v2
Stop double freeing the the BO list by pulling the content
of amdgpu_cs_parser_prepare_job() into the IOCTL function again.
v2: better commit message
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1) Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Christian König [Tue, 18 Aug 2015 16:23:16 +0000 (18:23 +0200)]
drm/amdgpu: fix zeroing all IB fields manually v2
The problem now is that we don't necessarily call amdgpu_ib_get()
in some error paths and so work with uninitialized data.
Better require that the memory is already zeroed.
v2: better commit message
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> (v1) Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Marek Olšák [Tue, 18 Aug 2015 21:58:47 +0000 (23:58 +0200)]
drm/amdgpu: bump the DRM version for new allowed mem-mapped registers
Used by mesa, etc. for profiling.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Marek Olšák <marek.olsak@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Dave Airlie [Thu, 20 Aug 2015 04:11:17 +0000 (14:11 +1000)]
Merge branch 'drm-next-fsl-dcu' of https://github.com/Jianwei-Wang/linux-drm-fsl-dcu into drm-next
Merge Freescale DCU FRM driver.
* 'drm-next-fsl-dcu' of https://github.com/Jianwei-Wang/linux-drm-fsl-dcu:
MAINTAINERS: Add Freescale DCU DRM driver maintainer
devicetree: Add NEC to the vendor-prefix list
drm/layerscape: Add Freescale DCU DRM driver
Add Alison and myself as maintainers of the Freescale DCU DRM driver.
Signed-off-by: Alison Wang <b18965@freescale.com> Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by: Jianwei Wang <jianwei.wang.chn@gmail.com>
Jianwei Wang [Thu, 20 Aug 2015 02:24:45 +0000 (22:24 -0400)]
devicetree: Add NEC to the vendor-prefix list
NEC represent NEC LCD Technologies, Ltd.
Signed-off-by: Alison Wang <b18965@freescale.com> Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by: Jianwei Wang <jianwei.wang.chn@gmail.com>
Jianwei Wang [Thu, 20 Aug 2015 02:19:49 +0000 (22:19 -0400)]
drm/layerscape: Add Freescale DCU DRM driver
This patch add support for Two Dimensional Animation and Compositing
Engine (2D-ACE) on the Freescale SoCs.
2D-ACE is a Freescale display controller. 2D-ACE describes
the functionality of the module extremely well its name is a value
that cannot be used as a token in programming languages.
Instead the valid token "DCU" is used to tag the register names and
function names.
The Display Controller Unit (DCU) module is a system master that
fetches graphics stored in internal or external memory and displays
them on a TFT LCD panel. A wide range of panel sizes is supported
and the timing of the interface signals is highly configurable.
Graphics are read directly from memory and then blended in real-time,
which allows for dynamic content creation with minimal CPU
intervention.
The features:
(1) Full RGB888 output to TFT LCD panel.
(2) Blending of each pixel using up to 4 source layers
dependent
on size of panel.
(3) Each graphic layer can be placed with one pixel resolution
in either axis.
(4) Each graphic layer support RGB565 and RGB888 direct colors
without alpha channel and BGRA8888 BGRA4444 ARGB1555 direct
colors
with an alpha channel and YUV422 format.
(5) Each graphic layer support alpha blending with 8-bit
resolution.
This is a simplified version, only one primary plane, one
framebuffer, one crtc, one connector and one encoder for TFT
LCD panel.
Signed-off-by: Alison Wang <b18965@freescale.com> Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by: Jianwei Wang <jianwei.wang.chn@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Dave Airlie [Thu, 20 Aug 2015 00:35:29 +0000 (10:35 +1000)]
Merge branch 'drm-atmel-hlcdc-devel' of https://github.com/bbrezillon/linux-at91 into drm-next
The following PR add support for 3 more atmel SoCs and for some missing
features (new input formats and PRIME support).
* 'drm-atmel-hlcdc-devel' of https://github.com/bbrezillon/linux-at91:
drm: atmel-hlcdc: add support for sama5d4 SoCs
drm: atmel-hlcdc: add support for at91sam9n12 SoC
drm: atmel-hlcdc: add support for at91sam9x5 SoCs
drm: atmel-hlcdc: add RGB565 and RGB444 output support
drm: atmel-hlcdc: add the missing DRM_ATOMIC flag
drm: atmel-hlcdc: add PRIME support
Dave Airlie [Wed, 19 Aug 2015 23:40:49 +0000 (09:40 +1000)]
Merge branch 'drm-next-4.3' of git://people.freedesktop.org/~agd5f/linux into drm-next
amdgpu and radeon changes for 4.3. Highlights:
- Fiji support for amdgpu.
- CGS support for amdgpu. This is a new driver
internal cross-component API.
- Initial GPU scheduler for amdgpu. Still disabled
by default.
- Lots of bug fixes and optimizations
* 'drm-next-4.3' of git://people.freedesktop.org/~agd5f/linux: (130 commits)
drm/amdgpu: wait on page directory changes. v2
drm/amdgpu: Select BACKLIGHT_LCD_SUPPORT
drm/radeon: Select BACKLIGHT_LCD_SUPPORT
drm/amdgpu: cleanup sheduler rq handling v2
drm/amdgpu: move prepare work out of scheduler to cs_ioctl
drm/amdgpu: fix unnecessary wake up
drm/amdgpu: fix duplicated mapping invoke bug
drm/amdgpu: drop bo_list_clone when no scheduler
drm/amdgpu: disable GPU reset by default
drm/amdgpu: fix type mismatch error
drm/amdgpu: add reference for **fence
drm/amdgpu: fix waiting for all fences before flipping
drm/amdgpu: fix UVD return code checking
drm/amdgpu: remove scheduler fence list v2
drm/amdgpu: remove amd_sched_wait_emit v2
drm/amdgpu: remove unecessary scheduler fence callbacks
drm/amdgpu: fix scheduler fence implementation
drm/amdgpu: don't grab dev->struct_mutex in pm functions
drm/amdgpu: Don't take dev->struct_mutex in bo_force_delete
drm/radeon: Don't take dev->struct_mutex in pm functions
...
Pagetables can be moved and therefore the page directory update can be necessary
for the current cs even if none of the the bo's are moved. In that scenario
there is no fence between the sdma0 and gfx ring, so we add one.
v2 (chk): rebased
Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Thierry Reding [Fri, 14 Aug 2015 10:50:12 +0000 (12:50 +0200)]
drm/amdgpu: Select BACKLIGHT_LCD_SUPPORT
Explicitly select BACKLIGHT_LCD_SUPPORT to satisfy the direct dependency
of BACKLIGHT_CLASS_DEVICE.
Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Thierry Reding [Fri, 14 Aug 2015 10:50:11 +0000 (12:50 +0200)]
drm/radeon: Select BACKLIGHT_LCD_SUPPORT
Explicitly select BACKLIGHT_LCD_SUPPORT to satisfy the direct dependency
of BACKLIGHT_CLASS_DEVICE.
Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
monk.liu [Wed, 12 Aug 2015 09:56:52 +0000 (17:56 +0800)]
drm/amdgpu: fix type mismatch error
remaining timeout returned by amdgpu_fence_wait_any can be larger than
max int value, thus the truncated 32 bit value in r ends up being
negative while its original long value is positive.
Signed-off-by: monk.liu <monk.liu@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Jammy Zhou <jammy.zhou@amd.com>
Christian König [Tue, 11 Aug 2015 14:35:54 +0000 (16:35 +0200)]
drm/amdgpu: fix UVD return code checking
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Tested-and-Reviewed-by: Leo Liu <leo.liu@amd.com>
Daniel Vetter [Thu, 9 Jul 2015 21:32:50 +0000 (23:32 +0200)]
drm/amdgpu: don't grab dev->struct_mutex in pm functions
Similar to radeon, except that amdgpu doesn't even use struct_mutex to
protect anything like the shared z buffer (sane gpu architecture,
yay!). And the code already grabs the globa adev->ring_lock, so this
code can't race with itself. Which makes struct_mutex completely
redundnant. Remove it.
Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Daniel Vetter [Thu, 9 Jul 2015 21:32:48 +0000 (23:32 +0200)]
drm/radeon: Don't take dev->struct_mutex in pm functions
We already grab 2 device-global locks (write-sema rdev->pm.mclk_lock
and rdev->ring_lock), adding another global mutex won't serialize this
code more. And since there's really nothing interesting that gets
protected in radeon by dev->struct mutex (we only have the global z
buffer owners and it's still serializing gem bo destruction in the drm
core - which is irrelevant since radeon uses ttm anyway internally)
this doesn't add protection. Remove it.
Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Monk Liu <monk.liu@amd.com> (v1) Reviewed-by: Jammy Zhou <Jammy.Zhou@amd.com> (v2)
Christian König [Wed, 5 Aug 2015 19:22:10 +0000 (21:22 +0200)]
drm/amdgpu: cleanup and fix scheduler fence handling v2
v2: rebased
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Christian König [Wed, 5 Aug 2015 16:18:52 +0000 (18:18 +0200)]
drm/amdgpu: fix coding style in a couple of places
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Christian König [Wed, 5 Aug 2015 16:11:14 +0000 (18:11 +0200)]
drm/amdgpu: remove unused parent entity
Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Jammy Zhou [Mon, 3 Aug 2015 02:27:57 +0000 (10:27 +0800)]
drm/amdgpu: add amd_sched_next_queued_seq function
This function is used to get the next queued sequence number
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
This function is to update last_emitted_v_seq and wake up the waiters.
It should be called by driver in the run_job backend function
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
drm/amdgpu: return new seq_no for amd_sched_push_job
It is clean to update last_queued_v_seq in the scheduler module
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jammy Zhou <Jammy.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
origninal method will sleep/schedule at the granurarity of HZ/2 and
based on seq signal method, the new implement is based on kernel fance
interface, no unnecessary schedule at all
v2: replace logic of original amdgpu_fence_wait_any
Signed-off-by: monk.liu <monk.liu@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
projects / linux-beck.git / log