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.
Alan Stern
--
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
