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

drm/i915: Assume non-DP++ port if dvo_port is HDMI and there's no AUX ch specified in the VBT

2016-11-26T08:56:56+00:00

commit bc9db5ad3253c8e17969bd802c47b73e63f125ab upstream.

My heuristic for detecting type 1 DVI DP++ adaptors based on the VBT
port information apparently didn't survive the reality of buggy VBTs.
In this particular case we have a machine with a natice HDMI port, but
the VBT tells us it's a DP++ port based on its capabilities.

The dvo_port information in VBT does claim that we're dealing with a
HDMI port though, but we have other machines which do the same even
when they actually have DP++ ports. So that piece of information alone
isn't sufficient to tell the two apart.

After staring at a bunch of VBTs from various machines, I have to
conclude that the only other semi-reliable clue we can use is the
presence of the AUX channel in the VBT. On this particular machine
AUX channel is specified as zero, whereas on some of the other machines
which listed the DP++ port as HDMI have a non-zero AUX channel.

I've also seen VBTs which have dvo_port a DP but have a zero AUX
channel. I believe those we need to treat as DP ports, so we'll limit
the AUX channel check to just the cases where dvo_port is HDMI.

If we encounter any more serious failures with this heuristic I think
we'll have to have to throw it out entirely. But that could mean that
there is a risk of type 1 DVI dongle users getting greeted by a
black screen, so I'd rather not go there unless absolutely necessary.

v2: Remove the duplicate PORT_A check (Daniel)
    Fix some typos in the commit message

Cc: Daniel Otero 
Tested-by: Daniel Otero 
Fixes: d61992565bd3 ("drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97994
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1478884464-14251-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter 
(cherry picked from commit 7a17995a3dc8613f778a9e2fd20e870f17789544)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Refresh that status of MST capable connectors in ->detect()

2016-11-26T08:56:56+00:00

commit fc22b787890f9f9067fd130feec42297a4ee62ba upstream.

Once we've determined that the sink is MST capable we never end up
running through the full detect cycle again, despite getting HPDs.
Fix tht by ripping out the incorrect piece of code responsible.

This got broken when I moved the long HPD handling to the ->detect()
hook, but failed to remove the leftover code.

Cc: Ander Conselvan de Oliveira 
Cc: drm-intel-fixes@lists.freedesktop.org
Cc: Rui Tiago Matos 
Tested-by: Rui Tiago Matos 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98323
Cc: Kirill A. Shutemov 
Tested-by: Kirill A. Shutemov 
References: https://bugs.freedesktop.org/show_bug.cgi?id=98306
Fixes: 1015811609c0 ("drm/i915: Move long hpd handling into the hotplug work")
Signed-off-by: Ville Syrjälä 
Link: http://patchwork.freedesktop.org/patch/msgid/1477057478-29328-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson 
(cherry picked from commit 1aab956c7b8872fb6976328316bfad62c6e67cf8)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5)

2016-11-26T08:56:55+00:00

commit 8e94a46c1770884166b31adc99eba7da65a446a7 upstream.

External clients which import our bo's wait only
for exclusive dmabuf-fences, not on shared ones,
ditto for bo's which we import from external
providers and write to.

Therefore attach exclusive fences on prime shared buffers
if our exported buffer gets imported by an external
client, or if we import a buffer from an external
exporter.

See discussion in thread:
https://lists.freedesktop.org/archives/dri-devel/2016-October/122370.html

Prime export tested on Intel iGPU + AMD Tonga dGPU as
DRI3/Present Prime render offload, and with the Tonga
standalone as primary gpu.

v2: Add a wait for all shared fences before prime export,
    as suggested by Christian Koenig.

v3: - Mark buffer prime_exported in amdgpu_gem_prime_pin,
    so we only use the exclusive fence when exporting a
    bo to external clients like a separate iGPU, but not
    when exporting/importing from/to ourselves as part of
    regular DRI3 fd passing.

    - Propagate failure of reservation_object_wait_rcu back
    to caller.

v4: - Switch to a prime_shared_count counter instead of a
      flag, which gets in/decremented on prime_pin/unpin, so
      we can switch back to shared fences if all clients
      detach from our exported bo.

    - Also switch to exclusive fence for prime imported bo's.

v5: - Drop lret, instead use int ret -> long ret, as proposed
      by Christian.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95472
Tested-by: Mike Lothian  (v1)
Signed-off-by: Mario Kleiner 
Reviewed-by: Christian König .
Cc: Christian König 
Cc: Michel Dänzer 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

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