On Sat, 25 Sep 2004, David Brownell wrote: > On Saturday 25 September 2004 9:23 am, Alan Stern wrote: > > > > On Fri, 24 Sep 2004, Pavel Machek wrote: > > > > [ in email that didn't make it to the list, or at least to me ... ]
My fault, sorry. I mistyped a mailing-list abbreviation. > > Although the picture isn't really clear, I gather the device states one > > really needs to consider could be described something like this (using an > > ad hoc notation): > > These states don't correspond to PCI or ACPI states, so it'd > be clearer to talk using names that can't be confused with > either of them (like ACPI S1) ... Yes, of course. I just invented those names on the spur of the moment. > In general I think the PM core has to firmly accept the notion > of driver-specified device power states ... as things that are > distinct from system power states, and that drivers sometimes > use to coordinate with each other. That may be so, but it doesn't mean the PM core has to pay attention to what drivers do internally. The core may have its own set of recognized state, and drivers may divide each of those into their own private sub-states if they like. But you can't expect the core to be aware of the idiosyncracies of all the different drivers and devices. > > S0' is a device's initial unconfigured state. > > That'd be hardware-specific. Some initialize in your S2', and there can > be multiple analogues of PME# and power (like autogated clocks). Sure. That's not a problem. All that matters is that we have a label for the unconfigured state, and that devices in that state don't perform DMA or issue IRQs. > Which means lots more states in some devices than this S0/S1/S2/... Again, not a problem so long as the driver is aware of this and classifies each device-state as belonging to one of those levels. > > S0 is the normal > > operational state. Selective suspend would use state S1. Suspend-to-RAM > > and suspend-to-disk would use S2 for devices that support PME#, otherwise > > S2'. Perhaps there's no need to distinguish between the two; I don't know > > how closely people want to tie remote wakeup enable/disable with power > > states, although they are related concepts. > > They're coupled in that wakeup makes no sense without some kind of > suspend ... and a usable "selective suspend" has to account for devices > waking up out of low-power states (just like "system suspend", except > of course only waking up part of the system). Exactly. Furthermore, the suspend call is a logical place to specify whether wakeup should be enabled. Also note that once a device is suspended, it may not be possible to change whether wakeup is enabled or disabled without first resuming the device. > PME# is wierd though, since at least in current Linux it's only relevant > for _system_ wakeup. > > Which makes it useless for systems that want to leave devices in > selective suspend almost all the time, since only devices in PCI D0 > can issue IRQs, yet deeply suspended devices can only issue PME#. That's right. It means selective suspend with wakeup enabled has to use D0, with the driver somehow doing its best to minimize power consumption anyway. On Sun, 26 Sep 2004, Pavel Machek wrote: > What is PME#? It's a special signal used by PCI power management. A device may generate this signal even when it is in a low-power or power-off state (unlike normal IRQs, which can only be generated in D0). The signal is generally used to wake up the system -- for instance, the ACPI firmware might turn on the system power. Think of Wake-On-Ring or Wake-On-LAN. I don't believe there's any way for PME# to be at all device-specific. That is, if several devices are selectively suspended and one of them generates PME#, there's no way to tell which one it was. (If that's wrong, someone please let me know.) Consequently PME# is useless for indicating a wakeup request during selective suspend, as David said. > Yes, agreed. Feel free to submit a patch ;-). I would prefer to wait until there is some consensus on how selective suspend works as well as system-wide suspend. After all, the two ought to share a lot of code... Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
