[Natty-SRU] Lenovo x420s panel display corruption when mode-setting
Herton Ronaldo Krzesinski
herton.krzesinski at canonical.com
Mon Oct 3 16:01:09 UTC 2011
On Mon, Oct 03, 2011 at 02:55:24PM +0100, Andy Whitcroft wrote:
> 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.
master-next should be up to date now, synced with master with new
release getting abi from c-k-t ppa.
>
> -apw
>
--
[]'s
Herton
More information about the kernel-team
mailing list