litmus-rt.git/drivers/gpu/drm/i915, branch master

Revert "drm/i915: Don't skip request retirement if the active list is empty"

2015-06-15T11:32:54+00:00

This reverts commit 0aedb1626566efd72b369c01992ee7413c82a0c5.

I messed things up while applying [1] to drm-intel-fixes. Rectify.

[1] http://mid.gmane.org/1432827156-9605-1-git-send-email-ville.syrjala@linux.intel.com

Fixes: 0aedb1626566 ("drm/i915: Don't skip request retirement if the active list is empty")
Cc: stable@vger.kernel.org
Acked-by: Ville Syrjälä 
Signed-off-by: Jani Nikula

drm/i915: Always reset vma->ggtt_view.pages cache on unbinding

2015-06-15T06:49:59+00:00

With the introduction of multiple views of an obj in the same vm, each
vma was taught to cache its copy of the pages (so that different views
could have different page arrangements). However, this missed decoupling
those vma->ggtt_view.pages when the vma released its reference on the
obj->pages. As we don't always free the vma, this leads to a possible
scenario (e.g. execbuffer interrupted by the shrinker) where the vma
points to a stale obj->pages, and explodes.

Fixes regression from commit fe14d5f4e5468c5b80a24f1a64abcbe116143670
Author: Tvrtko Ursulin 
Date:   Wed Dec 10 17:27:58 2014 +0000

    drm/i915: Infrastructure for supporting different GGTT views per object

Tvrtko says, if someone else will be confused how this can happen, key
is the reservation execbuffer path. That puts the VMA on the exec_list
which prevents i915_vma_unbind and i915_gem_vma_destroy from fully
destroying the VMA. So the VMA is left existing as an empty object in
the list - unbound and disassociated with the backing store. Kind of a
cached memory object. And then re-using it needs to clear the cached
pages pointer which is fixed above.

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1227892
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Daniel Vetter 
Cc: Michel Thierry 
Cc: stable@vger.kernel.org
Reviewed-by: Tvrtko Ursulin 
[Jani: Added Tvrtko's explanation to commit message.]
Signed-off-by: Jani Nikula

drm/i915: Fix DDC probe for passive adapters

2015-06-09T07:34:15+00:00

Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
devices, as they do not have a sink device in them to respond to any AUX
traffic. When probing these dongles over the DDC, sometimes they will
NAK the first attempt even though the transaction is valid and they
support the DDC protocol. The retry loop inside of
drm_do_probe_ddc_edid() would normally catch this case and try the
transaction again, resulting in success.

That, however, was thwarted by the fix for [1]:

commit 9292f37e1f5c79400254dca46f83313488093825
Author: Eugeni Dodonov 
Date:   Thu Jan 5 09:34:28 2012 -0200

    drm: give up on edid retries when i2c bus is not responding

This added code to exit immediately if the return code from the
i2c_transfer function was -ENXIO in order to reduce the amount of time
spent in waiting for unresponsive or disconnected devices. That was
possible because the underlying i2c bit banging algorithm had retries of
its own (which, of course, were part of the reason for the bug the
commit fixes).

Since its introduction in

commit f899fc64cda8569d0529452aafc0da31c042df2e
Author: Chris Wilson 
Date:   Tue Jul 20 15:44:45 2010 -0700

    drm/i915: use GMBUS to manage i2c links

we've been flipping back and forth enabling the GMBUS transfers, but
we've settled since then. The GMBUS implementation does not do any
retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
the retry on -ENXIO.

Retry GMBUS once on -ENXIO on first message to mitigate the issues with
passive adapters.

This patch is based on the work, and commit message, by Todd Previte
.

[1] https://bugs.freedesktop.org/show_bug.cgi?id=41059

v2: Don't retry if using bit banging.

v3: Move retry within gmbux_xfer, retry only on first message.

v4: Initialize GMBUS0 on retry (Ville).

v5: Take index reads into account (Ville).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
Cc: Todd Previte 
Cc: stable@vger.kernel.org
Tested-by: Oliver Grafe  (v2)
Tested-by: Jim Bride 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula

drm/i915: Properly initialize SDVO analog connectors

2015-06-08T10:42:00+00:00

In the commit below, I missed the connector allocation in the function
intel_sdvo_analog_init(), leading to those connectors to have a NULL
state pointer.

commit 08d9bc920d465bbbbd762cac9383249c19bf69a2
Author: Ander Conselvan de Oliveira 
Date:   Fri Apr 10 10:59:10 2015 +0300

    drm/i915: Allocate connector state together with the connectors

Reported-by: Stefan Lippers-Hollmann 
Tested-by: Stefan Lippers-Hollmann 
Signed-off-by: Ander Conselvan de Oliveira 
Signed-off-by: Jani Nikula

drm/i915: Move WaBarrierPerformanceFixDisable:skl to skl code from chv code

2015-06-04T11:15:45+00:00

 commit 65ca7514e21adbee25b8175fc909759c735d00ff
 Author: Damien Lespiau 
 Date:   Mon Feb 9 19:33:22 2015 +0000

    drm/i915/skl: Implement WaBarrierPerformanceFixDisable

got misapplied and the code landed in chv_init_workarounds() instead of
the intended skl_init_workarounds(). Move it over to the right place.

Cc: Damien Lespiau 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Damien Lespiau 
Reviewed-by: Ben Widawsky 
Signed-off-by: Jani Nikula

drm/i915: Include G4X/VLV/CHV in self refresh status

2015-06-04T08:19:38+00:00

Add all missing platforms handled by intel_set_memory_cxsr() to the
i915_sr_status debugfs entry.

v2: Add G4X too. (Ville)
    Clarify the change also affects CHV. (Ander)

References: https://bugs.freedesktop.org/show_bug.cgi?id=89792
Signed-off-by: Ander Conselvan de Oliveira 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula

drm/i915: Initialize HWS page address after GPU reset

2015-06-04T08:10:21+00:00

After GPU reset, HW is losing the address of HWS page in the register.
The page itself is valid except that HW is not aware of its location.

[   64.368623] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address = 0x00000000
[   64.368655] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address = 0x00000000
[   64.368681] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address = 0x00000000
[   64.368704] [drm:gen8_init_common_ring [i915]] *ERROR* HWS Page address = 0x00000000

This patch reloads this value into the register during ring init.

Signed-off-by: Arun Siluvery 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula

drm/i915: Don't skip request retirement if the active list is empty

2015-06-01T07:55:51+00:00

Apparently we can have requests even if though the active list is empty,
so do the request retirement regardless of whether there's anything
on the active list.

The way it happened here is that during suspend intel_ring_idle()
notices the olr hanging around and then proceeds to get rid of it by
adding a request. However since there was nothing on the active lists
i915_gem_retire_requests() didn't clean those up, and so the idle work
never runs, and we leave the GPU "busy" during suspend resulting in a
WARN later.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Chris Wilson 
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula

drm/i915/hsw: Fix workaround for server AUX channel clock divisor

2015-06-01T07:55:51+00:00

According to the HSW b-spec we need to try clock divisors of 63
and 72, each 3 or more times, when attempting DP AUX channel
communication on a server chipset.  This actually wasn't happening
due to a short-circuit that only checked the DP_AUX_CH_CTL_DONE bit
in status rather than checking that the operation was done and
that DP_AUX_CH_CTL_TIME_OUT_ERROR was not set.

[v2] Implemented alternate solution suggested by Jani Nikula.

Cc: stable@vger.kernel.org
Signed-off-by: Jim Bride 
Signed-off-by: Jani Nikula

drm/i915: fix screen flickering

2015-05-19T07:28:34+00:00

Commit c9f038a1a592 ("drm/i915: Don't assume primary & cursor are
always on for wm calculation (v4)") fixes a null pointer dereference.
Setting the primary and cursor panes to false in
ilk_compute_wm_parameters to false does however give the following
errors in the kernel log and causes the screen to flicker.

[  101.133716] [drm:intel_set_cpu_fifo_underrun_reporting [i915]]
*ERROR* uncleared fifo underrun on pipe A
[  101.133725] [drm:intel_cpu_fifo_underrun_irq_handler [i915]]
*ERROR* CPU pipe A FIFO underrun

Always setting the panes to enabled fixes this error.

Helped-by: Matt Roper 
Signed-off-by: Thomas Gummerer 
Reviewed-by: Matt Roper 
Tested-by: Mario Kleiner 
Signed-off-by: Jani Nikula