Continuation of bug 31188.

Created attachment 41120 [details] [review]
unlock panel regs unconditionally

Can those who were having trouble with the VBT data patch revert the revert and try this patch on top?

My Vaio VPCZ1 works with your patch in addition to the eDP VBT patch
(or rather the revert reverted). It does not work without the eDP VBT 
patch.

The above is true for drm-intel-next and drm-intel-fixes.

        -jhz

Created attachment 41635 [details] [review]
correct eDP encoder check

This one gets drm-intel-next working on my vaio again, can you give it a try?

(In reply to comment #4)
> Created an attachment (id=41635) [details]
> correct eDP encoder check
> 
> This one gets drm-intel-next working on my vaio again, can you give it a try?

Okay, I just tried it and it works fine on my Vaio as well.

Applied the patch to -fixes:

commit 369581028e2528122cc109abacf11766ae231f01
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Tue Jan 4 10:46:49 2011 -0800

    drm/i915: check eDP encoder correctly when setting modes
    
    We were using a stale pointer in the check which caused us to use CPU
    attached DP params when we should have been using PCH attached params.
    
    Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=31988
    Tested-by: Jan-Hendrik Zab <jan@jhz.name>
    Tested-by: Christoph Lukas <christoph.lukas@gmx.net>
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

However, the reverted patch was trying to avoid training by using the stored parameters in the VBT, so I'll leave it to Jesse as to whether he wants to close this bug.

I confirm this patch doesn't break QA's Dell e6510.

I guess this patch doesn't make into 2.6.37, right?

No, too late, but it is a good candidate for .37.1.

I can confirm that this fix is working for me as well on my Sony VAIO VPC Z13M9E.

The only problem left is a blank screen after suspend/resume cycle. If I attach an external monitor via VGA after the resume then the black screen goes away and I can use the computer again.

just to note this doesn't seem to have been applied to drm-next (unless I missed it or it's under a different description...)

Not yet since the trees are in flux. I'm waiting to resolve some more eDP patches, and these are intended to in via drm-intel-fixes->drm-fixes->linus

(In reply to comment #10)

> The only problem left is a blank screen after suspend/resume cycle. If I attach
> an external monitor via VGA after the resume then the black screen goes away
> and I can use the computer again.

Interesting enough this procedure is only required once after each cold boot of the system - is no-one else experiencing this problem?

(In reply to comment #13)
> (In reply to comment #10)
> 
> > The only problem left is a blank screen after suspend/resume cycle. If I attach
> > an external monitor via VGA after the resume then the black screen goes away
> > and I can use the computer again.
> 
> Interesting enough this procedure is only required once after each cold boot of
> the system - is no-one else experiencing this problem?

I've had a similar report over at kernel.bugzilla.org. Not up at the moment, so I can give the actual link.

However, the eDP training fixes are in drm-intel-next. (A single negative report meant that I could not apply them directly to -fixes...)

(In reply to comment #14)

> I've had a similar report over at kernel.bugzilla.org. Not up at the moment, so
> I can give the actual link.
> 
> However, the eDP training fixes are in drm-intel-next. (A single negative
> report meant that I could not apply them directly to -fixes...)

Just to let you know: the problem got worse with the current 2.6.38-rc1 - I can no longer use the workaround to turn the internal display back on after resume from suspend-to-ram, only the external display hooked up via VGA still works :-(

Can you please give me the commit ids which are supposed to fix this issue?

Closing really old resolved+fixed.