With Ironlake and SandyBridge laptops, the VGA output gets broken on 2.6.37. This happens when the VGA cable was connected before boot. After mode-switching, the output works as normal. This is a regression from 2.6.36 kernel. The affecting commit is: commit 77d07fd9d73ef28689737c0952dbd5d6a5017743 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Sep 12 12:42:35 2010 +0100 drm/i915/lvds: Remove busy wait for powering down the panel Looking at this change, one problem I found was that removing the wait-sync in the LVDS power-off causes (strangely) the VGA-output breakage. Just putting this hunk back fixes the issue at this commit. But, since the codebase was changed heavily during 2.6.37 development, this patch can't be reverted so easily. The patch below is the result, which brought again the VGA output in the end with 2.6.37. The patch fixes two issues: - Use the right PP_STATUS register for PCH, - Add wait-sync in intel_lvds_disable() independently from panel-fitter.
Created attachment 44462 [details] Fix patch
(In reply to comment #0) > With Ironlake and SandyBridge laptops, the VGA output gets broken on 2.6.37. > This happens when the VGA cable was connected before boot. After > mode-switching, the output works as normal. Can you explain more clearly? Initial VGA console output is unaffected, then we modeswitch and lose VGA fbcon output, then modeswitch again and regain VGA fbcon? > This is a regression from 2.6.36 kernel. The affecting commit is: > commit 77d07fd9d73ef28689737c0952dbd5d6a5017743 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Sun Sep 12 12:42:35 2010 +0100 > drm/i915/lvds: Remove busy wait for powering down the panel > > Looking at this change, one problem I found was that removing the wait-sync > in > the LVDS power-off causes (strangely) the VGA-output breakage. Just putting > this hunk back fixes the issue at this commit. > > But, since the codebase was changed heavily during 2.6.37 development, this > patch can't be reverted so easily. The patch below is the result, which > brought again the VGA output in the end with 2.6.37. > > The patch fixes two issues: > - Use the right PP_STATUS register for PCH, pfit_dirty can only be true for !PCH, so the first chunk is redundant. > - Add wait-sync in intel_lvds_disable() independently from panel-fitter. Are we just hiding another timing bug else where, methinks?
(In reply to comment #2) > (In reply to comment #0) > > With Ironlake and SandyBridge laptops, the VGA output gets broken on > 2.6.37. > > This happens when the VGA cable was connected before boot. After > > mode-switching, the output works as normal. > > Can you explain more clearly? Initial VGA console output is unaffected, then > we > modeswitch and lose VGA fbcon output, then modeswitch again and regain VGA > fbcon? No, the initial VGA output is broken when the machine is booted with VGA-cable plugged from the beginning. In the case of IronLake, it shows the vibrating frame-buffer picture (like unsync'ed). On SandyBridge, fb picture is shown in a pretty psychedelic way. Then after mode-switching (changing VGA-mode to a different resolution or such), the VGA output starts working correctly. > > > This is a regression from 2.6.36 kernel. The affecting commit is: > > commit 77d07fd9d73ef28689737c0952dbd5d6a5017743 > > Author: Chris Wilson <chris@chris-wilson.co.uk> > > Date: Sun Sep 12 12:42:35 2010 +0100 > > drm/i915/lvds: Remove busy wait for powering down the panel > > > > Looking at this change, one problem I found was that removing the wait-sync > in > > the LVDS power-off causes (strangely) the VGA-output breakage. Just > putting > > this hunk back fixes the issue at this commit. > > > > But, since the codebase was changed heavily during 2.6.37 development, this > > patch can't be reverted so easily. The patch below is the result, which > > brought again the VGA output in the end with 2.6.37. > > > > The patch fixes two issues: > > - Use the right PP_STATUS register for PCH, > > pfit_dirty can only be true for !PCH, so the first chunk is redundant. Hm, right. > > - Add wait-sync in intel_lvds_disable() independently from panel-fitter. > > Are we just hiding another timing bug else where, methinks? I suppose so, too. But it's hard to find out...
Is this still a problem in current mainline kernels?
Again, can you please retest on latest 3.3 and report back? If not, please close as unreproducible.
Looks working with 3.x kernels. I'll reopen if encountering the same issue with the upstream code.