linux-stable.git/drivers/gpu, branch v3.12.45

drm/i915: Evict CS TLBs between batches

2015-07-30T11:21:20+00:00

commit c4d69da167fa967749aeb70bc0e94a457e5d00c1 upstream.

Running igt, I was encountering the invalid TLB bug on my 845g, despite
that it was using the CS workaround. Examining the w/a buffer in the
error state, showed that the copy from the user batch into the
workaround itself was suffering from the invalid TLB bug (the first
cacheline was broken with the first two words reversed). Time to try a
fresh approach. This extends the workaround to write into each page of
our scratch buffer in order to overflow the TLB and evict the invalid
entries. This could be refined to only do so after we update the GTT,
but for simplicity, we do it before each batch.

I suspect this supersedes our current workaround, but for safety keep
doing both.

V2: The magic number shall be 2.

This doesn't conclusively prove that it is the mythical TLB bug we've
been trying to workaround for so long, that it requires touching a number
of pages to prevent the corruption indicates to me that it is TLB
related, but the corruption (the reversed cacheline) is more subtle than
a TLB bug, where we would expect it to read the wrong page entirely.

Oh well, it prevents a reliable hang for me and so probably for others
as well.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Ville Syrjälä 
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Takashi Iwai 
Signed-off-by: Jiri Slaby

drm/i915: save/restore GMBUS freq across suspend/resume on gen4

2015-07-30T11:21:20+00:00

commit 9f49c37635d5c2a801f7670d5fbf0b25ec461f2c upstream.

Should probably just init this in the GMbus code all the time, based on
the cdclk and HPLL like we do on newer platforms.  Ville has code for
that in a rework branch, but until then we can fix this bug fairly
easily.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76301
Signed-off-by: Jesse Barnes 
Reviewed-by: Ville Syrjälä 
Tested-by: Nikolay 
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula 
Signed-off-by: Takashi Iwai 
Signed-off-by: Jiri Slaby

drm/i915: Handle failure to kick out a conflicting fb driver

2015-07-30T11:21:19+00:00

commit f96de58fc7e7d3d717c7c63975c3b896c906b5e3 upstream.

Signed-off-by: Chris Wilson 
Reviewed-by: Jani Nikula 
Signed-off-by: Daniel Vetter 
Signed-off-by: Jiri Slaby

drm/i915: drop WaSetupGtModeTdRowDispatch:snb

2015-07-30T11:21:19+00:00

commit 2208d655a91f9879bd9a39ff9df05dd668b3512c upstream.

This reverts the regressing

commit 6547fbdbfff62c99e4f7b4f985ff8b3454f33b0f
Author: Daniel Vetter 
Date:   Fri Dec 14 23:38:29 2012 +0100

    drm/i915: Implement WaSetupGtModeTdRowDispatch

that causes GPU hangs immediately on boot.

Reported-by: Leo Wolf 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=79996
Cc: stable@vger.kernel.org (v3.8+)
Signed-off-by: Daniel Vetter 
[Jani: amended the commit message slightly.]
Signed-off-by: Jani Nikula 

Signed-off-by: Jiri Slaby

drm/mgag200: Reject non-character-cell-aligned mode widths

2015-06-23T13:15:06+00:00

commit 25161084b1c1b0c29948f6f77266a35f302196b7 upstream.

Turns out 1366x768 does not in fact work on this hardware.

Signed-off-by: Adam Jackson 
Signed-off-by: Dave Airlie 
Signed-off-by: Jiri Slaby

drm/radeon: fix freeze for laptop with Turks/Thames GPU.

2015-06-23T12:55:13+00:00

commit 6dfd197283bffc23a2b046a7f065588de7e1fc1e upstream.

Laptop with Turks/Thames GPU will freeze if dpm is enabled. It seems
the SMC engine is relying on some state inside the CP engine. CP needs
to chew at least one packet for it to get in good state for dynamic
power management.

This patch simply disabled and re-enable DPM after the ring test which
is enough to avoid the freeze.

Signed-off-by: Jérôme Glisse 
Signed-off-by: Alex Deucher 
Signed-off-by: Jiri Slaby

drm/i915: Fix DDC probe for passive adapters

2015-06-23T12:55:13+00:00

commit 3f5f1554ee715639e78d9be87623ee82772537e0 upstream.

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 
Tested-by: Oliver Grafe  (v2)
Tested-by: Jim Bride 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Jani Nikula 
Signed-off-by: Jiri Slaby

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

2015-06-23T12:55:12+00:00

commit e058c945e03a629c99606452a6931f632dd28903 upstream.

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.

Signed-off-by: Jim Bride 
Signed-off-by: Jani Nikula 
Signed-off-by: Jiri Slaby

drm/radeon: partially revert "fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling"

2015-06-03T09:33:15+00:00

commit 7c0411d2fabc2e2702c9871ffb603e251158b317 upstream.

We have that bug for years and some users report side effects when fixing it on older hardware.

So revert it for VM_CONTEXT0_PAGE_TABLE_END_ADDR, but keep it for VM 1-15.

Signed-off-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Jiri Slaby

drm/radeon: fix VM_CONTEXT*_PAGE_TABLE_END_ADDR handling

2015-06-03T09:33:15+00:00

commit 607d48063512707a414e346972e2210dc71ab491 upstream.

The mapping range is inclusive between starting and ending addresses.

Signed-off-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Jiri Slaby