linux.git/drivers/gpu/drm/amd, branch v5.0-rc2

Merge branch 'drm-fixes-5.0' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

2019-01-10T21:38:56+00:00

- Powerplay fixes
- Virtual display pinning fixes
- Golden register updates for vega
- Pitch and gem size validation fixes
- Fix for error case in sr-iov init
- Disable page tables in system memory on RV due to issues with IOMMU
  reported on some platforms

Signed-off-by: Dave Airlie 
From: Alex Deucher 
Link: https://patchwork.freedesktop.org/patch/msgid/20190109204336.3315-1-alexander.deucher@amd.com

drm/amdgpu: disable system memory page tables for now

2019-01-09T20:01:18+00:00

We hit a problem with IOMMU with that. Disable until we have time to
debug further.

Signed-off-by: Christian König 
Reviewed-by: Michel Dänzer 
Signed-off-by: Alex Deucher

drm/amdgpu: set WRITE_BURST_LENGTH to 64B to workaround SDMA1 hang

2019-01-09T20:01:10+00:00

effect asics: VEGA10 and VEGA12

Signed-off-by: Jim Qu 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amdgpu: fix CPDMA hang in PRT mode for VEGA20

2019-01-09T20:00:50+00:00

Fix CPDMA hang in PRT mode for both VEGA10 and VEGA20

Signed-off-by: Tao Zhou 
Tested-by: Yukun.Li 
Acked-by: Alex Deucher 
Signed-off-by: Alex Deucher

drm/amdgpu: Don't fail resume process if resuming atomic state fails

2019-01-08T22:58:26+00:00

This is an ugly one unfortunately. Currently, all DRM drivers supporting
atomic modesetting will save the state that userspace had set before
suspending, then attempt to restore that state on resume. This probably
worked very well at one point, like many other things, until DP MST came
into the picture. While it's easy to restore state on normal display
connectors that were disconnected during suspend regardless of their
state post-resume, this can't really be done with MST because of the
fact that setting up a downstream sink requires performing sideband
transactions between the source and the MST hub, sending out the ACT
packets, etc.

Because of this, there isn't really a guarantee that we can restore the
atomic state we had before suspend once we've resumed. This sucks pretty
bad, but so far I haven't run into any compositors that this actually
causes serious issues with. Most compositors will notice the hotplug we
send afterwards, and then reprobe state.

Since nouveau and i915 also don't fail the suspend/resume process due to
failing to restore the atomic state, let's make amdgpu match this
behavior. Better to resume the GPU properly, then to stop the process
half way because of a potentially unavoidable atomic commit failure.

Eventually, we'll have a real fix for this problem on the DRM level. But
we've got some more important low-hanging fruit to deal with first.

Signed-off-by: Lyude Paul 
Reviewed-by: Harry Wentland 
Cc: Jerry Zuo 
Cc:  # v4.15+
Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-3-lyude@redhat.com

drm/amdgpu: Don't ignore rc from drm_dp_mst_topology_mgr_resume()

2019-01-08T22:58:24+00:00

drm_dp_mst_topology_mgr_resume() returns whether or not it managed to
find the topology in question after a suspend resume cycle, and the
driver is supposed to check this value and disable MST accordingly if
it's gone-in addition to sending a hotplug in order to notify userspace
that something changed during suspend.

Currently, amdgpu just makes the mistake of ignoring the return code
from drm_dp_mst_topology_mgr_resume() which means that if a topology was
removed in suspend, amdgpu never notices and assumes it's still
connected which leads to all sorts of problems.

So, fix this by actually checking the rc from
drm_dp_mst_topology_mgr_resume(). Also, reformat the rest of the
function while we're at it to fix the over-indenting.

Signed-off-by: Lyude Paul 
Reviewed-by: Harry Wentland 
Cc: Jerry Zuo 
Cc:  # v4.15+
Link: https://patchwork.freedesktop.org/patch/msgid/20190108211133.32564-2-lyude@redhat.com

drm/amdgpu: validate user GEM object size

2019-01-08T21:26:50+00:00

When creating frame buffer, userspace may request to attach to a
previously allocated GEM object that is smaller than what GPU
requires. Validation must be done to prevent out-of-bound DMA,
otherwise it could be exploited to reveal sensitive data.

This fix is not done in a common code path because individual
driver might have different requirement.

Cc: stable@vger.kernel.org # v4.2+
Reviewed-by: Michel Dänzer 
Signed-off-by: Yu Zhao 
Signed-off-by: Alex Deucher

drm/amdgpu: validate user pitch alignment

2019-01-08T21:26:41+00:00

Userspace may request pitch alignment that is not supported by GPU.
Some requests 32, but GPU ignores it and uses default 64 when cpp is
4. If GEM object is allocated based on the smaller alignment, GPU
DMA will go out of bound.

Cc: stable@vger.kernel.org # v4.2+
Reviewed-by: Michel Dänzer 
Signed-off-by: Yu Zhao 
Signed-off-by: Alex Deucher

drm/amd/powerplay: drop the unnecessary uclk hard min setting

2019-01-08T21:26:34+00:00

Since soft min setting is enough. Hard min setting is redundant.

Reported-by: Likun Gao 
Signed-off-by: Evan Quan 
Acked-by: Alex Deucher 
Reviewed-by: Likun Gao 
Signed-off-by: Alex Deucher

drm/amd/powerplay: avoid possible buffer overflow

2019-01-08T21:26:26+00:00

Make sure the clock level enforced is within the allowed
ranges.

Signed-off-by: Evan Quan 
Reviewed-by: Alex Deucher 
Reviewed-by: Likun Gao 
Signed-off-by: Alex Deucher