[Natty-SRU] Lenovo x420s panel display corruption when mode-setting

Andy Whitcroft apw at canonical.com
Mon Oct 3 13:55:24 UTC 2011


On Mon, Oct 03, 2011 at 10:50:22AM -0300, Herton Ronaldo Krzesinski wrote:
> On Mon, Oct 03, 2011 at 02:23:24PM +0100, Andy Whitcroft wrote:
> > On Mon, Oct 03, 2011 at 01:19:55PM +0100, Andy Whitcroft wrote:
> > 
> > > Well its a vast and epic patch.  I am left wondering whether this is
> > > a backport or a cherry-pick in this context, below its reported as a
> > > backport which implies it was modified, but you say here "as-is" implying
> > > the opposite.
> > [...]
> > > > Subject: [PATCH] drm/i915: add pipe/plane enable/disable functions
> > > > 
> > > > Add plane enable/disable functions to prevent duplicated code and allow
> > > > us to easily check for plane enable/disable requirements (such as pipe
> > > > enable, plane status, pll status etc).
> > > 
> > > It is clear that this description is inadequate if we are actually
> > > changing pipe init order.  (Not that that is anything you should change
> > > as it _is_ the upstream commit description.)  Bad Jesse.
> > > 
> > > > 
> > > > Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
> > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > > 
> > > > (Backport to 2.6.38.y)
> > > 
> > > BugLink: http://bugs.launchpad.net/bugs/812638
> > > (backported from commit b24e71798871089da1a4ab049db2800afc1aac0c)
> > > 
> > > "backported from" if its modified, "cherry-picked from" if its not ... ?
> > 
> > Ok, having talked to Jose a bit on IRC I am now able to answer my own
> > question.  Actually this patch is the merge of _two_ upstream commits
> > only retaining one of the descriptions.
> > 
> > It is a merge of the two commits below:
> > 
> >   commit 65993d64a31844ad444694efb2d159eb9c883e49
> >   Author: Jesse Barnes <jbarnes at virtuousgeek.org>
> >   Date:   Tue Jan 4 15:09:29 2011 -0800
> > 
> >     drm/i915: don't enable plane, pipe and PLL prematurely
> >     
> >     On Ironlake+ we need to enable these in a specific order.
> >     
> >     Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
> >     Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > 
> > and:
> > 
> >   commit b24e71798871089da1a4ab049db2800afc1aac0c
> >   Author: Jesse Barnes <jbarnes at virtuousgeek.org>
> >   Date:   Tue Jan 4 15:09:30 2011 -0800
> > 
> >     drm/i915: add pipe/plane enable/disable functions
> >     
> >     Add plane enable/disable functions to prevent duplicated code and allow
> >     us to easily check for plane enable/disable requirements (such as pipe
> >     enable, plane status, pll status etc).
> >     
> >     Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
> >     Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > 
> > If we try applying these onto the current natty head the first is a clean
> > cherry-pick, the second collised in context _only_ with the patch below,
> > keeping both sides gives us the combined commit on this thread:
> > 
> >   commit bbeaf8811ba070fd186dfcabc957044c3a1149ac
> >   Author: Keng-Yu Lin <keng-yu.lin at canonical.com>
> >   Date:   Wed Jun 22 09:49:34 2011 +0800
> > 
> >     drm/i915: disable PCH ports if needed when disabling a CRTC
> > 
> > For me this should have been submitted as two patched as clearly the
> > change in the first one is a key component.  From these discusssions it
> > seems that this improves things from 100% failure to ~10% failure on
> > boot.  It looks a lot like the changes in the second patch, such as
> > waiting for vblank on enabling the pipes fixes that final 10%.
> 
> Just droping a note about the "drm/i915: disable PCH ports if needed
> when disabling a CRTC", it's now reverted on current natty master,
> because of regressions. So once pushed to master-next, I guess the
> second patch will not collide anymore. I was just waiting for the natty
> update to be copied to -proposed so I could push master to master-next
> and do a proper startnewrelease, but may be I'll do something to get
> the abis from the c-k-t ppa instead and sync master-next earlier.

Thanks for the heads up on that.

-apw




More information about the kernel-team mailing list