kernel/linux.git/drivers/gpu/drm/amd, branch v4.17.18

drm/amdgpu: Avoid reclaim while holding locks taken in MMU notifier

2018-08-03T05:48:02+00:00

[ Upstream commit 6e08e0995b8f339fd2a7ee4fa11f17396405ef60 ] When an MMU notifier runs in memory reclaim context, it can deadlock trying to take locks that are already held in the thread causing the memory reclaim. The solution is to avoid memory reclaim while holding locks that are taken in MMU notifiers. This commit fixes kmalloc while holding rmn->lock by moving the call outside the lock. The GFX MMU notifier also locks reservation objects. I have no good solution for avoiding reclaim while holding reservation objects. The HSA MMU notifier will not lock any reservation objects. v2: Moved allocation outside lock instead of using GFP_NOIO Signed-off-by: Felix Kuehling Acked-by: Oded Gabbay Reviewed-by: Christian König Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Fix dim display on DCE11

2018-08-03T05:47:51+00:00

[ Upstream commit 84ffa80123f56f80145dc638f21dfcbedda5610d ] Before programming the input gamma, check that we're not using the identity correction. Signed-off-by: Leo (Sunpeng) Li Reviewed-by: Anthony Koo Acked-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Remove VRAM from shared bo domains.

2018-08-03T05:47:51+00:00

[ Upstream commit 9b3f217faf48603c91d4ca44a18e6ff74c3c1c0c ] This fixes an issue introduced by change "allow framebuffer in GART memory as well" which could lead to a shared buffer ending up pinned in vram. Use GTT if it is included in the domain, otherwise return an error. Signed-off-by: Samuel Li Reviewed-by: Alex Deucher Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/amd/display: remove need of modeset flag for overlay planes (V2)

2018-08-03T05:47:50+00:00

[ Upstream commit a2a330ad66313084c9432b32862aa7e1255da9b4 ] This patch is in continuation to the "843e3c7 drm/amd/display: defer modeset check in dm_update_planes_state" where we started to eliminate the dependency on DRM_MODE_ATOMIC_ALLOW_MODESET to be set by the user space, which as such is not mandatory. After deferring, this patch eliminates the dependency on the flag for overlay planes. This has to be done in stages as its a pretty complex and requires thorough testing before we free primary planes as well from dependency on modeset flag. V2: Simplified the plane type check. Signed-off-by: Shirish S Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Do not program interrupt status on disabled crtc

2018-08-03T05:47:41+00:00

[ Upstream commit 4ea7fc09539bd2399c1fa7acea14529406120d9e ] Prevent interrupt programming of a crtc on which the stream is disabled and it doesn't have an OTG to reference. Signed-off-by: Mikita Lipski Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

drm/amd/powerplay: Set higher SCLK&MCLK frequency than dpm7 in OD (v2)

2018-08-03T05:47:33+00:00

[ Upstream commit 5c16f36f6f003b4415237acca59384a074cd8030 ] Fix the issue that SCLK&MCLK can't be set higher than dpm7 when OD is enabled in SMU7. v2: fix warning (Alex) Signed-off-by: Kenneth Feng Acked-by: Rex Zhu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

Revert "drm/amd/display: Don't return ddc result and read_bytes in same return value"

2018-07-25T09:26:09+00:00

commit 5292221d6ddfed75e5b46cd42237a677094b99f3 upstream. This reverts commit 018d82e5f02ef3583411bcaa4e00c69786f46f19. This breaks DDC in certain cases. Revert for 4.18 and previous kernels. For 4.19, this is fixed with the following more extensive patches: drm/amd/display: Serialize is_dp_sink_present drm/amd/display: Break out function to simply read aux reply drm/amd/display: Return aux replies directly to DRM drm/amd/display: Right shift AUX reply value sooner than later drm/amd/display: Read AUX channel even if only status byte is returned Link: https://lists.freedesktop.org/archives/amd-gfx/2018-July/023788.html Acked-by: Harry Wentland Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Reserve VM root shared fence slot for command submission (v3)

2018-07-25T09:26:09+00:00

commit ed6b4b5559769c6c5a0fcb3fac8a9e1f4e58c4ae upstream. Without this, there could not be enough slots, which could trigger the BUG_ON in reservation_object_add_shared_fence. v2: * Jump to the error label instead of returning directly (Jerry Zhang) v3: * Reserve slots for command submission after VM updates (Christian König) Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/106418 Reported-by: mikhail.v.gavrilov@gmail.com Signed-off-by: Michel Dänzer Signed-off-by: Junwei Zhang Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Dynamically probe for ATIF handle (v2)

2018-07-11T14:31:28+00:00

commit f9ff68521a5541e1fdaeb0ef11871c035b30e409 upstream. The other day I was testing one of the HP laptops at my office with an i915/amdgpu hybrid setup and noticed that hotplugging was non-functional on almost all of the display outputs. I eventually discovered that all of the external outputs were connected to the amdgpu device instead of i915, and that the hotplugs weren't being detected so long as the GPU was in runtime suspend. After some talking with folks at AMD, I learned that amdgpu is actually supposed to support hotplug detection in runtime suspend so long as the OEM has implemented it properly in the firmware. On this HP ZBook 15 G4 (the machine in question), amdgpu wasn't managing to find the ATIF handle at all despite the fact that I could see acpi events being sent in response to any hotplugging. After going through dumps of the firmware, I discovered that this machine did in fact support ATIF, but that it's ATIF method lived in an entirely different namespace than this device's handle (the device handle was \_SB_.PCI0.PEG0.PEGP, but ATIF lives in ATPX's handle at \_SB_.PCI0.GFX0). So, fix this by probing ATPX's ACPI parent's namespace if we can't find ATIF elsewhere, along with storing a pointer to the proper handle to use for ATIF and using that instead of the device's handle. This fixes HPD detection while in runtime suspend for this ZBook! v2: Update the comment to reflect how the namespaces are arranged based on the system configuration. (Alex) Signed-off-by: Lyude Paul Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Add amdgpu_atpx_get_dhandle()

2018-07-11T14:31:28+00:00

commit 4aa5d5eb82bb237d0bb3a38b2a7555054d018081 upstream. Since it seems that some vendors are storing the ATIF ACPI methods under the same handle that ATPX lives under instead of the device's own handle, we're going to need to be able to retrieve this handle later so we can probe for ATIF there. Signed-off-by: Lyude Paul Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman