linux/drivers/gpu, branch v3.2.22

drm/i915: Fix eDP blank screen after S3 resume on HP desktops

2012-07-04T04:44:27Z

commit 6db65cbb941f9d433659bdad02b307f6d94465df upstream. This patch fixes the problem on some HP desktop machines with eDP which give blank screens after S3 resume. It turned out that BLC_PWM_CPU_CTL must be written after BLC_PWM_CPU_CTL2. Otherwise it doesn't take effect on these SNB machines. Tested with 3.5-rc3 kernel. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49233 Signed-off-by: Takashi Iwai Signed-off-by: Daniel Vetter Signed-off-by: Ben Hutchings

drm/i915: rip out the PM_IIR WARN

2012-07-04T04:44:26Z

commit 58bf8062d0b293b8e1028e5b0342082002886bd4 upstream. After banging my head against this for the past few months, I still don't see how this could possible race under the premise that once an irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again until we unmask it in PM_IMR. Still, we have reports of this being seen in the wild. Now Bspec has this little bit of lovely language in the PMIIR register: Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR": "For each bit, the IIR can store a second pending interrupt if two or more of the same interrupt conditions occur before the first condition is cleared. Upon clearing the interrupt, the IIR bit will momentarily go low, then return high to indicate there is another interrupt pending." Now if we presume that PMIMR only prevent new interrupts from being queued, we could easily end up masking an interrupt and clearing it, but the 2nd pending interrupt setting the bit in PMIIR right away again. Which leads, the next time the irq handler runs, to hitting the WARN. Also, no bad side effects of this have ever been reported. And we've tracked down our issues with the gpu turbo getting stuck to bogus interrupt generation limits in th RPLIMIT register. So let's just rip out this WARN as bogus and call it a day. The only shallow thing here is that this 2-deep irq queue in the hw makes you wonder how racy the windows irq handler is ... Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907 Acked-by: Chris Wilson Signed-Off-by: Daniel Vetter Signed-off-by: Ben Hutchings

drm/i915: Refactor the deferred PM_IIR handling into a single function

2012-07-04T04:44:26Z

commit fc6826d1dcd65f3d1e9a5377678882e4e08f02be upstream. This function, along with the registers and deferred work hander, are all shared with SandyBridge, IvyBridge and their variants. So remove the duplicate code into a single function. Signed-off-by: Chris Wilson Reviewed-by: Ben Widawsky Signed-Off-by: Daniel Vetter [bwh: Backported to 3.2: adjust context; drop changes for Valley View] Signed-off-by: Ben Hutchings

drm/nouveau/fbcon: using nv_two_heads is not a good idea

2012-07-04T04:44:16Z

commit 9bd0c15fcfb42f6245447c53347d65ad9e72080b upstream. nv_two_heads() was never meant to be used outside of pre-nv50 code. The code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific chipsets to 1 CRTC based on (pci_device & 0x0ff0). The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, which gets detected as an NV20 (0x020x) with 1 CRTC by nv_two_heads(), causing memory corruption because there's actually 2 CRTCs.. This switches fbcon to use the CRTC count directly from the mode_config structure, which will also fix the same issue on Kepler boards which have 4 CRTCs. Signed-off-by: Ben Skeggs Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings

drm/edid: don't return stack garbage from supports_rb

2012-07-04T04:44:15Z

commit b196a4980ff7bb54db478e2a408dc8b12be15304 upstream. We need to initialize this to false, because the is_rb callback only ever sets it to true. Noticed while reading through the code. Signed-Off-by: Daniel Vetter Reviewed-by: Adam Jackson Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings

drm/i915: Do the fallback non-IRQ wait in ring throttle, too.

2012-07-04T04:44:13Z

commit 7ea29b13e5e3e1e61e612349eb0366efdb6457f3 upstream. As a workaround for IRQ synchronization issues in the gen7 BLT ring, we want to turn the two wait functions into polling loops. Signed-off-by: Eric Anholt Tested-by: Eugeni Dodonov Reviewed-by: Eugeni Dodonov Acked-by: Kenneth Graunke Signed-off-by: Keith Packard Signed-off-by: Ben Hutchings

drm/i915: Remove use of the autoreported ringbuffer HEAD position

2012-07-04T04:44:11Z

This is a revert of 6aa56062eaba67adfb247cded244fd877329588d. This was originally introduced to workaround reads of the ringbuffer registers returning 0 on SandyBridge causing hangs due to ringbuffer overflow. The root cause here was reads through the GT powerwell require the forcewake dance, something we only learnt of later. Now it appears that reading the reported head position from the HWS is returning garbage, leading once again to hangs. For example, on q35 the autoreported head reports: [ 217.975608] head now 00010000, actual 00010000 [ 436.725613] head now 00200000, actual 00200000 [ 462.956033] head now 00210000, actual 00210010 [ 485.501409] head now 00400000, actual 00400020 [ 508.064280] head now 00410000, actual 00410000 [ 530.576078] head now 00600000, actual 00600020 [ 553.273489] head now 00610000, actual 00610018 which appears reasonably sane. In contrast, if we look at snb: [ 141.970680] head now 00e10000, actual 00008238 [ 141.974062] head now 02734000, actual 000083c8 [ 141.974425] head now 00e10000, actual 00008488 [ 141.980374] head now 032b5000, actual 000088b8 [ 141.980885] head now 03271000, actual 00008950 [ 142.040628] head now 02101000, actual 00008b40 [ 142.180173] head now 02734000, actual 00009050 [ 142.181090] head now 00000000, actual 00000ae0 [ 142.183737] head now 02734000, actual 00009050 In addition, the automatic reporting of the head position is scheduled to be defeatured in the future. It has no more utility, remove it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45492 Reviewed-by: Daniel Vetter Tested-by: Eric Anholt Signed-off-by: Chris Wilson Signed-off-by: Jesse Barnes (cherry picked from commit 5d031e5b633d910f35e6e0abce94d9d842390006) Signed-off-by: Timo Aaltonen Signed-off-by: Ben Hutchings

drm/i915: Finish any pending operations on the framebuffer before disabling

2012-07-04T04:44:10Z

Similar to the case where we are changing from one framebuffer to another, we need to be sure that there are no pending WAIT_FOR_EVENTs on the pipe for the current framebuffer before switching. If we disable the pipe, and then try to execute a WAIT_FOR_EVENT it will block indefinitely and cause a GPU hang. We attempted to fix this in commit 85345517fe6d4de27b0d6ca19fef9d28ac947c4a (drm/i915: Retire any pending operations on the old scanout when switching) for the case of mode switching, but this leaves the condition where we are switching off the pipe vulnerable. There still remains the race condition were a display may be unplugged, switched off by the core, a uevent sent to notify the DDX and the DDX may issue a WAIT_FOR_EVENT before it processes the uevent. This window does not exist if the pipe is only switched off in response to the uevent. Time to make sure that is so... Reported-by: Francis Leblanc Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36515 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45413 Signed-off-by: Chris Wilson Reviewed-by: Eugeni Dodonov [danvet: fixup spelling in comment, noticed by Eugeni.] Signed-off-by: Daniel Vetter (cherry picked from commit 14667a4bde4361b7ac420d68a2e9e9b9b2df5231) Signed-off-by: Timo Aaltonen Signed-off-by: Ben Hutchings

drm/radeon: add some additional 6xx/7xx/EG register init

2012-06-19T22:18:29Z

commit b866d1334ba2d544bc575d75357dea6bdcdc7f46 upstream. - SMX_SAR_CTL0 needs to be programmed correctly to prevent problems with memory exports in certain cases. - VC_ENHANCE needs to be initialized on 6xx/7xx. Signed-off-by: Alex Deucher Signed-off-by: Dave Airlie Signed-off-by: Ben Hutchings

drm/nouveau/disp: fix dithering not being enabled on some eDP macbooks

2012-06-19T22:18:04Z

commit a6a17859f1bdf607650ee055101f54c5f207762b upstream. Signed-off-by: Ben Skeggs [Maarten Lankhorst backported to 3.2, changing nv_connector->type to nv_connector->dcb->type] Signed-off-by: Ben Hutchings