suspend/resume on Lenovo X1 (regression from reports on wiki)

[Jung-uk Kim]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2013-09-03 16:47:47 -0400, John Baldwin wrote:
> On Tuesday, September 03, 2013 4:12:01 pm Jung-uk Kim wrote:
>> On 2013-09-03 12:28:30 -0400, John Baldwin wrote:
>>> On Sunday, September 01, 2013 3:51:47 pm Adrian Chadd wrote:
>>>> (cc jkim)
>>>> 
>>>> Hi! Would you mind taking a look at the -acpi list posts
>>>> with this subject? It looks like a lot of the video
>>>> suspend/resume issues on these thinkpads boil down to the
>>>> VESA driver code. If it's disabled, (at least) x11 resume
>>>> works.
>>>> 
>>>> Would you be able to help us track down what's going on?
>>>> 
>>>> Thanks!
>>> 
>>> Most likely vga_suspend()/vga_resume() in sys/isa/vga_isa.c is 
>>> calling vidd_save_state() and vidd_load_state() which in the
>>> VESA case map to the _save_state() and _load_state() methods
>>> in sys/dev/fb/vesa.c.
>> 
>> Unfortunately, I don't really know where it actually fails
>> because I do not have *any* Intel GPUs to test.  If vesa.c is
>> really causing trouble, vesa_bios_post() in vesa_load_state() may
>> be the culprit, however.
> 
> I can try narrowing it down.

Please do.

>>> These methods look fairly sane to me, so it's probably either
>>> a BIOS bug, or the fact that KMS is bypassing the BIOS, so when
>>> KMS is active we should perhaps disable the VESA BIOS.
>> 
>> AFAIK, KMS does not play nice with syscons(4) ATM, e.g., syscons
>> does automatic VT switching and it may need to be turned off.
>> Again, it is just my guess.
> 
> Well, I don't have to do that, just having no VESA in the kernel
> results in resume working fine in X.  It seems that the i915drm
> driver is doing something to explicitly enable the backlight on the
> LCD btw.

Normally, I expect a device tree like this to do properly
suspend/resume with *drm1*:

nexus0
  acpi0
    pcib0
      pci0
        hostb0
        pcib1
          pci1
            vgapci0
              vgapm0
                dpms0
              drm0
...
        isab0
          isa0
            sc0
            vga0
...

Not sure about i915kms.ko.

>>> However, one thing that might help is that this is being called
>>> at a "random" time rather than when vgapci0 is being suspended
>>> and resumed. Actually, it looks like jkim fixed this via the
>>> vgapm driver, except I have no vgapm0 device on my laptop.
>> 
>> If you don't have vgapm0, its BIOS is not setting
>> PCIB_BCR_VGA_ENABLE bit to its bridge.  Often times, that means
>> it is "legacy free" stuff.
>> 
>>> I wonder if it's supposed to be device_get_unit() instead of 
>>> device_get_flags() in the vgapm identify routine?
>> 
>> No.  With multiple GPUs, it is (was?) the only way to find the
>> "boot display" because unit number is not always 0.  Although
>> dumbbell added vga_pci_is_boot_display() in current, this
>> interface should be kept for 9.x.
> 
> Hmm, so there is magic to set this I guess?  Ah, I see it now in
> vga_pci.c. That does seem gross compared to an ivar or some such.
> :)

And you said the almost exact same thing but okayed at the time. :-)

> In my case btw, x86bios_match_device() doesn't work because the
> BIOS ROM has a PCI device ID of 0x0106 while the device itself is
> 0x0126.

It's a bug.

> Even with that hacked so I force vgapm0 and dpms0 to attach, I
> still can't resume in console mode, and resume in X refuses to
> wakeup with VESA in the kernel (hitting the power button doesn't
> make it wakeup).

Please try to make syscons resume first.

Jung-uk Kim
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (FreeBSD)

iQEcBAEBAgAGBQJSJmgdAAoJECXpabHZMqHOh6kH/RpRVeXz3n8eb72PMfZ1eQDy
2LBn/NCpxbRAHhNkwclLqCorQp6CDAEM1iO4IJMgUG4BrRYcrGUybM7kHDGn5Oy3
7qLkXmu1TmBGwFndHMZ8VaqLsUV2mgKG1DLgCCEp2NG3szOuSgg1KwBaZuT1OUhm
TtJIWyuuwWld+DAaBaJJqCTJun6s3rpddXIEKj/2R+f4q99cjLt5I5qel+goArE+
yym4VrkY0S1Fn3Vj5+Nv8WMXlTgknIymsEg7fNJ9RDBGDPZ11l5DLztLjj+UfvIL
K6L3+AMNJ58HRA/PibPIGNgI0WXUDJ/KSNN0A44RIItiYwTxJSh482PkghlrLE4=
=jHx2
-----END PGP SIGNATURE-----