From: Takashi Iwai <tiwai@suse.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: Broken LVDS output at mode changes
Date: Thu, 29 Mar 2012 14:55:49 +0200 [thread overview]
Message-ID: <s5hd37vva5m.wl%tiwai@suse.de> (raw)
In-Reply-To: <20120329125132.GC20275@phenom.ffwll.local>
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@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
next prev parent reply other threads:[~2012-03-29 12:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-28 13:29 Broken LVDS output at mode changes Takashi Iwai
2012-03-29 12:16 ` Daniel Vetter
2012-03-29 12:44 ` Chris Wilson
2012-03-29 12:51 ` Daniel Vetter
2012-03-29 12:55 ` Takashi Iwai [this message]
2012-03-29 15:07 ` Keith Packard
2012-03-29 16:12 ` Takashi Iwai
2012-03-29 16:57 ` Keith Packard
2012-03-29 18:02 ` Takashi Iwai
2012-03-30 4:27 ` Keith Packard
2012-03-30 16:56 ` Jesse Barnes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hd37vva5m.wl%tiwai@suse.de \
--to=tiwai@suse.de \
--cc=daniel@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox