Broken LVDS output at mode changes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At Thu, 29 Mar 2012 14:51:32 +0200,
Daniel Vetter wrote:
> 
> On Thu, Mar 29, 2012 at 01:44:28PM +0100, Chris Wilson wrote:
> > On Thu, 29 Mar 2012 14:16:38 +0200, Daniel Vetter <daniel at ffwll.ch> wrote:
> > > On Wed, Mar 28, 2012 at 03:29:04PM +0200, Takashi Iwai wrote:
> > > > Hi,
> > > > 
> > > > we've encountered a broken LVDS output on some IVY/SNB machines when
> > > > the mode is changed (from/to native resolution).  When this happens,
> > > > the whole laptop panel gets half white and half black.  This doesn't
> > > > recover until the LVDS is turned off once.
> > > > 
> > > > And, there is no signficant difference between working and non-working
> > > > cases in the register dumps.  From the software POV, all looks sane.
> > > > So, we suspect this is rather specific to some panel hardware.
> > > > 
> > > > However, through debugging, I found that disabling LVDS at mode change
> > > > works around the problem.  A test patch is attached below.
> > > > 
> > > > My question now is: can this workaround have any serious drawback?
> > > > I thought of a longer blank time, but I didn't notice any difference
> > > > before and after the patch.
> > > > 
> > > > Or, any other suggestion as a saner fix?
> > > 
> > > No idea, I'm wondering though whether we should just accept some
> > > flickering while modesetting unconditionally. Does anyone know what
> > > Windows does in this case and at least on my work machine here it looks
> > > like Windows just blanks the screen. I haven't checked with reg dumps
> > > though how exactly they upscale stuff on lvds.
> > > 
> > > git blame says that Chris Wilson created the original PCH_SPLIT check.
> > > Chris, any comments on this?
> > 
> > It dates back from an earlier commit that presupposes that we can modify
> > the panel on the fly and avoid the power-cycling delays.
> > 
> > PP_STATUS: Panel Power On Status [bit 31]
> > 
> > In conjunction with bits Power Sequence Progress field and Power Cycle
> > Delay Active, this bit set to a one indicates that the panel is
> > currently powered up or is currently in the power down sequence and it
> > is unsafe to change the timing, port, and DPLL registers for the pipe or
> > transcoder that is assigned to the panel output.
> > 
> > Guess that rules that out.
> 
> Takashi, can you respin your patch to just unconditionally switch of the
> lvds also on PCH_SPLIT platforms then?

The hardware I've tested are actually on PCH_SPLIT, IvyBridge and
SandyBridge machines.  I'll test IronLake and GM45 machines whether
unconditonally switching will give any regressions.


Takashi


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux