On Tue, 28 Sep 2004, David Brownell wrote: > > I included them only as a way of communicating to drivers that they should > > prepare for a memory snapshot. Given some other way to do that, there's > > no reason to keep an "idle" bit. > > I'd rather have an "active" bit (everything is initially idle, yes?); > it'd be useful for things other than snapshotting.
Such as? > However it WOULD eventually let the suspend-to-disk and > suspend-to-ram scenarios look pretty much the same to > drivers: In both cases they get: > > - a "quiesce" pass, at the end of which all drivers are idled > so (for STD) a snapshot can be done (with swap partition); > > - then a "power down" pass, where suspend-to-disk > turns everything more or less "off" while suspend-to-ram > leaves at least non-wakeup devices in PCI D3cold (or a > roughly equivalent state), and RAM alive. > > So those "spurious resume during suspend" paths would > start to go away, because the first pass wouldn't need to > involve PM operations -- only the second. 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? 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? Or if STR called for a device to be in D3hot but the user had selectively placed it in D3cold, then what should happen? > > You should call them "suspend-with-wakeup" and "suspend". Don't confuse > > it with "idle". (Unless I'm the one who's confused and you mean something > > totally different...) > > Different. 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. As examples: USB root hubs that > have suspended their busses; USB mice that are suspended > and enabled wakeup. Okay, so you shouldn't have mentioned "idle-with-wakeup" in a previous email, as it is a contradiction in terms. 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. > > The PM core works its way down the device > > tree, telling drivers about the change. When it reaches a PCI USB host > > controller driver, the code in hcd-pci decides what the new PCI state > > should be (D3hot -- this may already have been decided by higher-level PCI > > drivers) > > ... and bus-specific logic (like driver-specific logic) would be factored > a bit differently. Probably all PCI devices would use common rules, > entering D3hot in most cases -- but only in the power-it-down stage, > at the very end of "enter standby" (~= PCI D1 for some devices) > or whatever system stae was specified.. Yes. In the down-and-back-up traversal of the device tree I've been talking about, the down phase decides what the next state should be while the up phase actually enters that state. (For suspends, that is; resumes are different.) 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. Alan Stern ------------------------------------------------------- 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
