[PATCH] i915: initialize CADL in opregion

[Daniel Vetter]

On Thu, Jun 28, 2012 at 01:05:58PM +0200, Daniel Vetter wrote:
> On Thu, Jun 28, 2012 at 1:24 AM, Lekensteyn <lekensteyn at gmail.com> wrote:
> > Thank you, I've now written a partial analysis which is available at
> > https://github.com/Lekensteyn/acpi-
> > stuff/blob/HEAD/dsl/Asus_Zenbook_DanielVetter/analysis.txt (note: URL is cut in
> > two parts in this mail, concat them as needed).
> >
> > Question: can you try disabling the asus-laptop module and try booting again
> > w/ and w/o the CADL patch applied?
> > - Does it boot in both cases?
> > - Do the brightness hotkeys work?
> > - Can you change brightness via /sys/class/backlight?
> > Can you SSH in it and check the logs? Any ACPI warnings/errors or messages
> > from the asus-laptop module? (or whatever asus module(s) is/are loaded)
> >
> > Can you also generate dmidecode.txt? (peek in http://lekensteyn.nl/files/get-
> > acpi-info.sh, you do not have to run all of the commands since I already have
> > your acpidump)
> 
> Ok, because I have an ecrypted root fs I've tried to reload the
> i915.ko with CADL after booting. Test-results:
> - asus_wmi.ko doesn't seem to have any effect whatsoever on the endresult.
> - asus_nb_wmi.ko doesn't load (ENODEV).
> - brightness-keys (and also sound control) don't work, but controlling
> the backlight with /sys/class/backlight/acpi_video0/brightness works
> (if I can turn the panel on somehow, see below).
> - When loading the i915.ko with the CADL patch the screen went black
> (like at boot), but with some excessive vt-switching and X restarting
> I've managed to light it up. Although it is flickery as hell,
> especially the lower part of the screen. And if the screen is somewhat
> stable, I just get the upper part of the screen duplicated in the
> lower part.
> - dmidecode is attached.
> - no errors in the logs anywhere (if you ignore some ACPI resource
> conflicts because ACPI reserves some pch stuff itself, which then
> conflicts with the native gpio, sensors, whatever drivers).
> 
> So I think this might be simply a timing issue that with CADL enabled
> we expose a pre-existing bug somewhere in our modeset sequence. I'm
> already chasing two issues on this machine:
> - edp refuses to light up crtc 1/2, only works after having switched
> back to crtc 0.
> - disabled pipes get stuck in the active state once having been used be edp.
> 
> I have a feeling that all these issues are related, so I guess until
> I've tracked down the above the things we won't make much progress
> with this CADL patch.

Good news: I've fixed my edp issues (switching crtcs works reliable now
and nothing gets stuck in a half-disabled state) and now I don't get a
black/flashing screen any more when applying your patch.

Bad news: We need to refactor a big chunk of our driver to properly fix
this issue. Which means I can't merge your patch right away :(

Cheers, Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48