http://bugzilla.kernel.org/show_bug.cgi?id=6892
------- Comment #29 from [EMAIL PROTECTED] 2008-08-17 23:36 ------- Not clear what you mean by "usage model". See for example Comment #2 re PCI; drivers need some kind of notification that their device(s) issued PME# (or other non-PCI wakeup signals, like the out-of-band scheme used by Intel's UHCI). It's not clear why that notification wouldn't just be calling the driver's resume() method; for now I'll assume that's what is used. Lots of PCI PM stuff has changed recently. I've yet to make time to understand all the changes. Shaohua, do you mean to say that ACPI will now detect PME# events issued at runtime, clear them, and notify the device's driver? IMO the standard parts of the model should not change: driver decides to enter low power state with wakeup enabled, enables the wakeup, changes the power state, then later gets a resume(). The same model *should* be used if the system is staying in S0 as if it's going into S3 (or any other S-state). And it shouldn't matter if ACPI is in use or not... If you're talking about how/why a device enters a low power state, when it wasn't just told to suspend() as part of a system power state transition, that's a different question and is best left to the driver. Last I looked, network and USB drivers were the main ones in a position to leverage runtime wakeup events. One reason this bug was filed is that USB has been in a position to use such mechanisms for some years now, but the PCI-over-ACPI infrastructure hasn't been there yet. (I noticed it wasn't working when I was testing the first USB PM support back on 2.6.9 kernels...) Today, a number of USB device drivers can handle runtime PM, so it's possible that entire trees of idle non-hub USB devices can enter low power states. Root hubs have, for some time now, suspended themselves when they have no active USB peripherals downstream. When a USB root hub suspends, its HCD could choose to suspend its upstream bus link too (in this context PCI, but in other cases a SOC's platform bus) to save more power. It needs to enable wakeup, so that it can re-activate when a USB peripheral reactivates itself (remote wakeup) or is plugged/unplugged. If PCI is now ready to support this through ACPI, we could start filling in some of those missing pieces... -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
