linux-toradex.git/drivers/gpu, branch v4.4.38

drm/radeon: Ensure vblank interrupt is enabled on DPMS transition to on

2016-12-02T08:09:01+00:00

NOTE: This patch only applies to 4.5.y or older kernels. With newer
kernels, this problem cannot happen because the driver now uses
drm_crtc_vblank_on/off instead of drm_vblank_pre/post_modeset[0]. I
consider this patch safer for older kernels than backporting the API
change, because drm_crtc_vblank_on/off had various issues in older
kernels, and I'm not sure all fixes for those have been backported to
all stable branches where this patch could be applied.

    ---------------------

Fixes the vblank interrupt being disabled when it should be on, which
can cause at least the following symptoms:

* Hangs when running 'xset dpms force off' in a GNOME session with
  gnome-shell using DRI2.
* RandR 1.4 slave outputs freezing with garbage displayed using
  xf86-video-ati 7.8.0 or newer.

[0] See upstream commit:

commit 777e3cbc791f131806d9bf24b3325637c7fc228d
Author: Daniel Vetter 
Date:   Thu Jan 21 11:08:57 2016 +0100

    drm/radeon: Switch to drm_vblank_on/off

Reported-and-Tested-by: Max Staudt 
Reviewed-by: Daniel Vetter 
Reviewed-by: Alex Deucher 
Signed-off-by: Michel Dänzer

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

2016-11-26T08:54:52+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: Respect alternate_ddc_pin for all DDI ports

2016-11-18T09:48:36+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

drm/radeon: fix DP mode validation

2016-11-15T06:46:40+00:00

commit ff0bd441bdfbfa09d05fdba9829a0401a46635c1 upstream.

Switch the order of the loops to walk the rates on the top
so we exhaust all DP 1.1 rate/lane combinations before trying
DP 1.2 rate/lane combos.

This avoids selecting rates that are supported by the monitor,
but not the connector leading to valid modes getting rejected.

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

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

drm/radeon/dp: add back special handling for NUTMEG

2016-11-15T06:46:40+00:00

commit c8213a638f65bf487c10593c216525952cca3690 upstream.

When I fixed the dp rate selection in:
092c96a8ab9d1bd60ada2ed385cc364ce084180e
drm/radeon: fix dp link rate selection (v2)
I accidently dropped the special handling for NUTMEG
DP bridge chips.  They require a fixed link rate.

Reviewed-by: Christian König 
Reviewed-by: Ken Wang 
Reviewed-by: Harry Wentland 
Tested-by: Ken Moffat 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: fix DP mode validation

2016-11-15T06:46:40+00:00

commit c47b9e0944e483309d66c807d650ac8b8ceafb57 upstream.

Switch the order of the loops to walk the rates on the top
so we exhaust all DP 1.1 rate/lane combinations before trying
DP 1.2 rate/lane combos.

This avoids selecting rates that are supported by the monitor,
but not the connector leading to valid modes getting rejected.

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

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

drm/amdgpu/dp: add back special handling for NUTMEG

2016-11-15T06:46:40+00:00

commit 02d27234759dc4fe14a880ec1e1dee108cb0b503 upstream.

When I fixed the dp rate selection in:
3b73b168cffd9c392584d3f665021fa2190f8612
drm/amdgpu: fix dp link rate selection (v2)
I accidently dropped the special handling for NUTMEG
DP bridge chips.  They require a fixed link rate.

Reviewed-by: Christian König 
Reviewed-by: Ken Wang 
Reviewed-by: Harry Wentland 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/exynos: fix error handling in exynos_drm_subdrv_open

2016-11-10T15:36:36+00:00

commit 55c4b906aa2aec3fa66310ec03c6842e34a04b2a upstream.

gcc-6 warns about a pointless loop in exynos_drm_subdrv_open:

drivers/gpu/drm/exynos/exynos_drm_core.c: In function 'exynos_drm_subdrv_open':
drivers/gpu/drm/exynos/exynos_drm_core.c:104:199: error: self-comparison always evaluates to false [-Werror=tautological-compare]
  list_for_each_entry_reverse(subdrv, &subdrv->list, list) {

Here, the list_for_each_entry_reverse immediately terminates because
the subdrv pointer is compared to itself as the loop end condition.

If we were to take the current subdrv pointer as the start of the
list (as we would do if list_for_each_entry_reverse() was not a macro),
we would iterate backwards over the &exynos_drm_subdrv_list anchor,
which would be even worse.

Instead, we need to use list_for_each_entry_continue_reverse()
to go back over each subdrv that was successfully opened until
the first entry.

Signed-off-by: Arnd Bergmann 
Signed-off-by: Inki Dae 
Signed-off-by: Greg Kroah-Hartman

drm/dp/mst: Check peer device type before attempting EDID read

2016-11-10T15:36:36+00:00

commit 4da5caa6a6f82cda3193bca855235b87debf78bd upstream.

Only certain types of pdts have the DDC bus registered, so check for
that before we attempt the EDID read. Othwewise we risk playing around
with an i2c adapter that doesn't actually exist.

Cc: Carlos Santa 
Cc: Kirill A. Shutemov 
Tested-by: Carlos Santa 
Tested-by: Kirill A. Shutemov 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97666
Signed-off-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
Link: http://patchwork.freedesktop.org/patch/msgid/1477472755-15288-5-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

drm/radeon: drop register readback in cayman_cp_int_cntl_setup

2016-11-10T15:36:36+00:00

commit 537b4b462caa8bfb9726d9695b8e56e2d5e6b41e upstream.

The read is taking a considerable amount of time (about 50us on this
machine). The register does not ever hold anything other than the ring
ID that is updated in this exact function, so there is no need for
the read modify write cycle.

This chops off a big chunk of the time spent in hardirq disabled
context, as this function is called multiple times in the interrupt
handler. With this change applied radeon won't show up in the list
of the worst IRQ latency offenders anymore, where it was a regular
before.

Reviewed-by: Christian König 
Signed-off-by: Lucas Stach 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman