On Monday 27 September 2004 1:16 pm, Alan Stern wrote: > > > This should be subsumed under a policy setting such as PM_SNAPSHOT. > > > > Snapshotting is not a policy, it's an action involved in one kind of > > system PM state change (not all of them). > > You're right, of course. I've been calling these things policy settings > (not policies) but it would be good to have a more suitable term. "System > power state" maybe -- although one of them is SELECTIVE_SUSPEND, which is > hardly system-wide.
I've been trying to get you to stop talking about "selective suspend" as a system-wide power policy, for exactly that reason. Maybe it'd be clearer to factor it like this: - System policy #1: everything full power, all the time. - System policy #2: selective suspend is allowed (sysadmin choice) - System policy #3: drivers enter selective suspend themselves I suspect you think my "low power" operating point was #2 not #3. In my book, #2 is not very interesting ... it needs to work, and doesn't currently behave well, but it implies sysadmin tools that know about too much random hardware and its system-specific operations. > > I think it'd be fair to say that if a driver is really idle, then by > > definition its state can be snapshotted. True equally of > > polled (timer-driven?) or IRQ/DMA drivers. > > Idleness, as I'm using it here, is a property of devices, not drivers. It > means specifically that the device isn't changing the contents of memory > (DMA write), relying on the contents of memory (DMA read) or trying to > change the flow of control (IRQ). That's necessarily achieved with driver cooperation though; can you really argue that it's not a driver-defined state? I'm trying to talk about things software developers affect, AND to make sense for all kinds of drivers/devices. > It also means that the device is in > some "good" state from which the driver can go back to normal operation, > even if the device has lost power in the meantime. That "even if the device has lost power" would be a major malfunction if it weren't accompanied by a power state transition. It's a requirement for certain resume() transitions, but otherwise ... not IMO a good idea. > I'm not sure what you mean here. As an example, a user would want to know > whether a device supports remote wakeup. And the user might want to be > able to specify whether or not remote wakeup should be disabled when the > device is suspended. As I said separately (to Oliver): two bits in the driver model, one saying if the hardware supports wakeup and the other defining the policy. Sysfs can easily show all three wakeup states: none, disabled, enabled. I've got a patch for this in the works. > > The issue is that for the PCI device, wakeup through PME# currently > > only applies during system resume. That still seems buglike to me > > (the hardware signal is generated, something's just ignoring it), > > but for now it means the HC must stay in PCI_D0 until the final stage > > of a system suspend operation. That rule can be enforced several > > ways, including ugly (global state) as well as clean (only system PM > > transitions changing power state, PME# working better, etc). > > Are you worried that if the PCI device is put into D3 too early and it > generates a PME# wakeup signal, then Linux will receive the signal but > ignore it? What would happen -- how would the signal be turned off? No, just annoyed that this PCI PM mechanism is not yet very usable in Linux. I'd like to see PCI devices sitting in low power states until they're used, not forced to stay in full power modes just because some software is discarding PME# signals except during system suspend. > Is there any possibility of implementing the PME# handler the same as > every other shared interrupt handler, with drivers registering interrupt > routines? Possibility? Of course! It's just a signal line. The thing is, I dont' know where it goes or what software handles it. I suspect that it goes to some ACPI "embedded controller", which either (a) issues a notification that's currently ignored by Linux ... after all, /proc/acpi/wakeup is very new, the first PME# support; or (b) doesn't issue notifications except during system sleep, which would indicate deeper issues with Wintel architecture. Of course, non-Wintel systems likely act in other ways ... not all PCI systems use ACPI. - Dave ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
