On Thursday, November 03, 2011, Alan Stern wrote:
> On Wed, 2 Nov 2011, Rafael J. Wysocki wrote:
>
> > Well, pci_acpi_wake_dev() appears to be the only one, at least in the PCI
> > land. pci_pme_wakeup_bus() calls pci_pme_wakeup() recursively and that _does_
> > check PME Status. The polling uses pci_pme_wakeup() too.
> >
> > However, the Matthew's patch changing pci_acpi_wake_dev(), reproduced below,
> > didn't make any difference for you and, moreover, the DSDT doesn't seem to
> > contain any device objects for xHCI, so at least this one shouldn't be notified
> > via ACPI. Bummer.
> >
> > So I wonder if the wakeups may actually originate in the USB land? I mean,
> > we have the logic causing child devices to resume their parents, so perhaps
> > when EHCI is woken up, it wakes up USB-something and that causes the other
> > controllers to resume? Alan, is that possible at all?
>
> No, it isn't. USB host controllers are completely independent as far
> as runtime PM is concerned.
>
> Perhaps it would help to add something like
>
> if (rpmflags == 0) {
> dev_info(dev, "Runtime resume\n");
> dump_stack();
> }
>
> to the place where rpm_resume() calls rpm_callback(). If that doesn't
> generate too much information, you ought to be able to tell where the
> wakeup comes from.
Yes, that may give us some clue and, quite frankly, I'm running out of
other ideas how that can be debugged any furhter.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
