lkml.org 
[lkml]   [2012]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [linux-pm] "i8042: Can't reactivate AUX port" after s2ram on 3.4-rc2
    Date
    On Sunday, April 15, 2012, Rafael J. Wysocki wrote:
    > On Sunday, April 15, 2012, Mikko Vinni wrote:
    > > From: Rafael J. Wysocki:
    > >
    > > >> > Please change that dev_dbg() in pci_restore_state() into dev_info()
    > > >> > and see how many times it gets printed with the commit applied (not
    > > > reverted).
    > > >>
    > > >>
    > > >> I ran the dmesg through "uniq -c" and it looks like this:
    > > >>
    > > >> 1 ACPI: Low-level resume complete
    > > >> 1 PM: Restoring platform NVS memory
    > > >> 1 Enabling non-boot CPUs ...
    > > >> 1 Booting Node 0 Processor 1 APIC 0x1
    > > >> 1 CPU1 is up
    > > >> 1 ACPI: Waking up from system sleep state S3
    > > >> 10 pcieport 0000:00:02.0: restoring config space at offset 0x7 (was
    > > > 0x20005151, writing 0x5151)
    > > >
    > > > Well, yeah. So the commit you bisected it to is total and utter crap.
    > > > Most importantly, it retries the writes for all of the dwords in the
    > > > device's
    > > > config space _including_ the status register (which by definition need not be
    > > > the same as the written value).
    > > >
    > > > I wonder if the appended patch helps?
    > >
    > > It does. It seems there is a change only in the devices that refuse to wake up;
    > > somehow writing too many times to them affects the rest of the machine.
    > > So, for this machine your patch fixes the problem of the touchpad not working.
    >
    > Good, thanks for the confirmation. :-)
    >
    > > The write is now attempted (at most) 11 times, as shown below. Probably not
    > > a huge deal.
    > >
    > > 1 ACPI: Waking up from system sleep state S3
    > > 11 pcieport 0000:00:02.0: restoring config space at offset 0x1c (was 0x20005151, writing 0x5151)
    >
    > Well, here you see that the PCI Express port is refusing to accept a new BAR value.
    > It seems not to be operational and this probably is the reason why the device below
    > the port don't respond later.
    >
    > I'm not sure why that happens, though.

    OK, I know. There simply are fewer BARs for bridges (and PCIe ports)
    and here we're attempting to overwrite the secondary status register. Sigh.

    Well, I guess we should only retry the writes to BARs for Type 0 headers.

    Thanks,
    Rafael


    \
     
     \ /
      Last update: 2012-04-15 21:51    [W:0.021 / U:59.836 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site