On Friday 04 September 2009, ykzhao wrote: > On Fri, 2009-09-04 at 06:07 +0800, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki <rjw@xxxxxxx> > > > > Some PCI devices (not PCI Express), like PCI add-on cards, can > > generate PME#, but they don't have any special platform wake-up > > support. For this reason, even if they generate PME# to wake up the > > system from a sleep state, wake-up events are not generated by the > > platform. > > > > It turns out that, at least on some systems, PCI bridges and the PCI > > host bridge have ACPI GPEs associated with them that, if enabled to > > generate wake-up events, allow the system to wake up if one of the > > add-on devices asserts PME# while the system is in a sleep state. > > Following this observation, if a PCI device without direct ACPI > > wake-up support is prepared to wake up the system during a transition > > into a sleep state (eg. suspend to RAM), configure all the bridges on > > the path from the device to the root bridge (including the root > > bridge itself) to wake-up the system. > >From the description it seems that it will propagate the wake-up > function to its parent device. > Is it enough to stop the propagation when we find one device that can > generate wake-up events in its parent device tree? Quite frankly, I'm not sure of that. It really depends on how PME# is routed in given system. The spec permits routing it directly to the chipset as well as routing it through bridges and I don't know if we can assume that the first upstream device capable of generating wake-up events will handle it. That said, I think we can try returning from acpi_pci_propagate_wakeup_enable() as soon as acpi_pm_device_sleep_wake() returns 0 for current device. On the test systems I have it won't make any difference, because the GPE is shared among the root bridge and the first upstream bridge of the device in question. 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
