On Tue, 28 Sep 2004, David Brownell wrote: > 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
Maybe the terminology I started using today will suit you better. The three items above only apply in the Power-On system state, and each is a policy. (Though I'm not sure it's a good idea to rule out the user's ability to selectively change device power levels in #1 above.) > > 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. But it's unavoidable that drivers will encounter devices that have lost power when resuming from the "idle" state -- and with no intervening power state transition -- if power isn't available (not even suspend power) while the system is off. Think about it: For STD you start by putting the device into an idle state. Then a memory snapshot is taken and you go through a power-down state transition. Later on the system reboots and restores the memory snapshot. As far as the driver can tell, no time has passed since the snapshot was taken; in particular, the driver has no recollection of the power-down state transition. To the driver, it looks like the device has gone directly from the idle state to the uninitialized state, having lost power in the process. > 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. What about Oliver's objection that support for wakeup depends on the power level? Like he said, it's easier just to try turning on wakeup and see if you get a "not-supported" error. > > 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. Have you tried asking about this on the ACPI mailing list? 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
