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    [from the cache]
©2003-2011 Jasper Spaans