On Tuesday 28 September 2004 12:03 pm, Alan Stern wrote:
> > I'd rather have an "active" bit (everything is initially idle, yes?);
> > it'd be useful for things other than snapshotting.
>
> Such as?
Decoupling "idle" driver states from power states; that's
the "USB bus suspend" state, for example. (With wakeup
disabled.) Meaningful even on "legacy PCI" systems
without PCI PM support, and not just for USB.
> > � - a "quiesce" pass, ...
> > � - then a "power down" pass, ...
>
> I see. �That makes sense. �Having a special "system idle" state would
> simplify things. �It would be a system state though, not a device-specific
> active bit. �Unless you have some reason for wanting to idle specific
> devices?
I feel like I'm repeating myself here; I certainly described
that as a _per-device_ idle-vs-active flags. There might also
be various "system idle" states in some implementations of
system suspend, sure -- but that's certainly not something
that a device driver (or the device power model) should
care about.
> Also, it's not so easy to eliminate the "resume needed during suspend"
> problem. For instance, if the device holding the swap partition happened
> to be suspended at the start of the "quiesce" pass, would that pass wake
> it up?
Nothing would need the swap partition until the END of that
pass, at which point code could just wake up that device.
> Or if STR called for a device to be in D3hot but the user had
> selectively placed it in D3cold, then what should happen?
Last I noticed, it was impossible to selectively put something
into D3cold. But regardless, STR shouldn't care: if the
device is already suspended at level N, then "N-1" suffices.
> > If it's idle, by definition it will not issue wakeups.
> > But there are lots of suspend states that can wake up; those
> > are still active devices. ..
>
> Okay, so you shouldn't have mentioned "idle-with-wakeup" in a previous
> email, as it is a contradiction in terms.
Right, my bad. "Idle" is overloaded; for a USB mouse,
"idle with wakeup" was an active (but suspended) state,
not an idle state. PCI allows such states too, but that
PME# issue gets in the way.
> And I disagree with your USB examples. In the sense we've been using,
> _all_ USB devices are always "idle". That is, they can never issue IRQs
> or do DMA; only host controllers can do that.
Hence my focus on "idle" vs "active" being a driver state issue,
since that way of looking at things doesn't embed nonportable
assumptions. How about I2C? No DMA, polled -- but the chips
can often issue IRQs. Unless the driver is idled....
> I'm not sure about all PCI device using common rules. Certainly they
> would use _similar_ rules -- but a PCI Ethernet driver and a PCI USB
> driver have to behave differently if Wake-On-LAN is enabled but
> Wake-On-USB isn't.
Any PCI driver can enter "idle" state.
(probably saves some power, e.g. no-DMA, no-clock, etc)
Any device with PCI PM support can enter D0 and D3hot.
(D3hot implies an "idle" state, and some PCI power savings)
No device without PCI PM support can enter PCI suspend states.
(but such "legacy PCI devices" can always use "idle" states)
Some devices with PCI PM support can enable wakeups by PME#.
(and effectively no other PCI devices can do it)
Driver model core controls whether a device uses wakeup.
(NEW mechanism as I've sketched.)
There are _also_ device-specific rules, but they can't change
those common ground rules.
- 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
