linux.git/drivers/gpu, branch v4.8.10

drm/i915: Fix mismatched INIT power domain disabling during suspend

2016-11-18T09:51:53+00:00

commit fd58753ead86ee289ea89fe26e1842f36e54b36c upstream.

Currently the display INIT power domain disabling/enabling happens in a
mismatched way in the suspend/resume_early hooks respectively. This can
leave display power wells incorrectly disabled in the resume hook if the
suspend sequence is aborted for some reason resulting in the
suspend/resume hooks getting called but the suspend_late/resume_early
hooks being skipped. In particular this change fixes "Unclaimed read
from register 0x1e1204" on BYT/BSW triggered from i915_drm_resume()->
intel_pps_unlock_regs_wa() when suspending with /sys/power/pm_test set
to devices.

Fixes: 85e90679335f ("drm/i915: disable power wells on suspend")
Cc: Ville Syrjälä 
Cc: David Weinehall 
Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1476358446-11621-1-git-send-email-imre.deak@intel.com
(cherry picked from commit 4c494a5769cd0de92638b25960ba0158c36088a6)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix a vm_flush fence leak

2016-11-18T09:51:53+00:00

commit 2d7c17be00e0dce3bc1a092a2c277a9f86c69ca9 upstream.

Looks like .last_flush reference is left at teardown.
Leak reported by CONFIG_SLUB_DEBUG.

Fixes: 41d9eb2c5a2a ("drm/amdgpu: add a fence after the VM flush")
Reviewed-by: Chunming Zhou 
Reviewed-by: Christian König 
Signed-off-by: Grazvydas Ignotas 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix fence slab teardown

2016-11-18T09:51:53+00:00

commit 0f10425e811355986907c54f7d1d06703e406092 upstream.

To free fences, call_rcu() is used, which calls amdgpu_fence_free()
after a grace period. During teardown, there is no guarantee all
callbacks have finished, so amdgpu_fence_slab may be destroyed before
all fences have been freed. If we are lucky, this results in some slab
warnings, if not, we get a crash in one of rcu threads because callback
is called after amdgpu has already been unloaded.

Fix it with a rcu_barrier().

Fixes: b44135351a3a ("drm/amdgpu: RCU protected amdgpu_fence_release")
Acked-by: Chunming Zhou 
Reviewed-by: Christian König 
Signed-off-by: Grazvydas Ignotas 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amd: fix scheduler fence teardown order v2

2016-11-18T09:51:49+00:00

commit c24784f01549ecdf23fc00d0588423bcf8956714 upstream.

Some fences might be alive even after we have stopped the scheduler leading
to warnings about leaked objects from the SLUB allocator.

Fix this by allocating/freeing the SLUB allocator from the module
init/fini functions just like we do it for hw fences.

v2: make variable static, add link to bug

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=97500

Reported-by: Grazvydas Ignotas 
Signed-off-by: Christian König 
Reviewed-by: Alex Deucher  (v1)
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix sched fence slab teardown

2016-11-18T09:51:49+00:00

commit a053fb7e512c77f0742bceb578b10025256e1911 upstream.

To free fences, call_rcu() is used, which calls amd_sched_fence_free()
after a grace period. During teardown, there is no guarantee all
callbacks have finished, so sched_fence_slab may be destroyed before
all fences have been freed. If we are lucky, this results in some slab
warnings, if not, we get a crash in one of rcu threads because callback
is called after amdgpu has already been unloaded.

Fix it with a rcu_barrier().

Fixes: 189e0fb76304 ("drm/amdgpu: RCU protected amd_sched_fence_release")
Acked-by: Chunming Zhou 
Reviewed-by: Christian König 
Signed-off-by: Grazvydas Ignotas 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix crash in acp_hw_fini

2016-11-18T09:51:49+00:00

commit 757124d95c42bb579d67df51e51789849929ee31 upstream.

On CZ/ST systems with AZ rather than ACP audio, we need to bail
early in hw_fini since there is nothing to do.

bug: https://bugs.freedesktop.org/show_bug.cgi?id=98276

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: disable runtime pm in certain cases

2016-11-18T09:51:49+00:00

commit 84b1528e8cef55274f0df20e93513b3060ce495a upstream.

If the platform does not support hybrid graphics or ATPX dGPU
power control.

Acked-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms

2016-11-18T09:51:48+00:00

commit 61e0c5438866d0e737937fc35d752538960e1e9f upstream.

According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less
than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
cycling on/off.

Let's apply this work around to GEN9 platforms too, as it fixes the same
issue.

v2: Move drm_device to drm_i915_private conversion

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97907
Cc: Libin Yang 
Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Jani Nikula 
Signed-off-by: Jani Nikula 
Link: http://patchwork.freedesktop.org/patch/msgid/1478117601-19122-1-git-send-email-dhinakaran.pandiyan@intel.com
(cherry picked from commit 9c7540241885838cfc7fa58c4a8bd75be0303ed1)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915/dp: BDW cdclk fix for DP audio

2016-11-18T09:51:48+00:00

commit fbb21c5202ae7f1e71e832b1af59fb047da6383e upstream.

According to BSpec, cdclk for BDW has to be not less than 432 MHz with DP
audio enabled, port width x4, and link rate HBR2 (5.4 GHz). With cdclk less
than 432 MHz, enabling audio leads to pipe FIFO underruns and displays
cycling on/off.

From BSpec:
"Display» BDW-SKL» dpr» [Register] DP_TP_CTL [BDW+,EXCLUDE(CHV)]
Workaround : Do not use DisplayPort with CDCLK less than 432 MHz, audio
enabled, port width x4, and link rate HBR2 (5.4 GHz), or else there may
be audio corruption or screen corruption."

Since, some DP configurations (e.g., MST) use port width x4 and HBR2
link rate, let's increase the cdclk to >= 432 MHz to enable audio for those
cases.

v4: Changed commit message
v3: Combine BDW pixel rate adjustments into a function (Jani)
v2: Restrict fix to BDW
    Retain the set cdclk across modesets (Ville)
Signed-off-by: Dhinakaran Pandiyan 
Reviewed-by: Ville Syrjälä 
Reviewed-by: Jani Nikula 
Signed-off-by: Jani Nikula 
Link: http://patchwork.freedesktop.org/patch/msgid/1478026080-2925-1-git-send-email-dhinakaran.pandiyan@intel.com
Signed-off-by: Greg Kroah-Hartman 

(cherry picked from commit b30ce9e0552aa017ac6f2243f3c2d8e36fe52e69)
Signed-off-by: Jani Nikula

drm/i915: Respect alternate_ddc_pin for all DDI ports

2016-11-18T09:51:48+00:00

commit 8d83bc22b259e5526625b6d298f637786c71129f upstream.

The VBT provides the platform a way to mix and match the DDI ports vs.
GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose
has no standard GMBUS pin assignment. However, there are machines out
there that use a non-standard mapping for the other ports as well.
Let's start trusting the VBT on this one for all ports on DDI platforms.

I've structured the code such that other platforms could easily start
using this as well, by simply filling in the ddi_port_info. IIRC there
may be CHV system that might actually need this.

v2: Include a commit message, include a debug message during init

Cc: Maarten Maathuis 
Tested-by: Maarten Maathuis 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97877
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-3-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Jim Bride 
(cherry picked from commit e4ab73a13291fc844c9e24d5c347bd95818544d2)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman