Hi!
> > I don't like this notion of "stop" separated from power states anyway, I
> > think it just doesn't work in practice.
>
> Yeah, after giving it some additional thought, I think there are better ways.
>
> >
> > Ben.
> >
>
> Ok, here's a new idea.
>
> For many devices "->suspend" and "->resume" with pm_message_t is exactly what
> we need. However, as we support more advanced power management features, such
> as runtime power management, or power containers, we need something a little
> more specific. The exact power state must be specified among other
> issues.
Okay, maybe. But not by adding 3 new callbacks that mirror existing
functionality.
> We might do something like this:
>
> Keep "->suspend" and "->resume" around unchanged. (so the states would
> probably remain as PMSG_FREEZE and PMSG_SUSPEND). If the driver doesn't
> support the more advanced PM methods just use these. They work well enough
> for system sleep states etc.
>
> Alternatively drivers could support a more rich power management interface
> via the following methods:
>
>
> change_state - changes a device's power state
>
> change_state(struct device * dev, pm_state_t state, struct system_state *
> sys_state, int reason);
> @dev - the device
> @state - the target device-specific power state
> @sys_state - a data structure containing information about the intended
> global system power state
> @reason - why the state must be changed (ex. RUNTIME_PM,
> SYSTEM_SLEEP, SYSTEM_RESUME, etc.)
If drivers really need to know system state and reason, just put it
into pm_message_t. I wanted to add "flags" there from the begining,
serving similar purpose as your "reason".
> halt - acts somewhat like PMSG_FREEZE, stops device activity, doesn't change
> power state
>
> halt(struct device * dev, struct system_state * sys_state, int reason);
> @dev - the device
> @sys_state - a data structure containing information about the intended
> global system power state
> @reason - why we are halting operation (ex. RUNTIME_CHANGES (like cpufreq),
> SYSTEM_SLEEP, SHUTDOWN, REBOOT)
If it is similar to PMSG_FREEZE, just pass PMSG_FREEZE and put
* sys_state and reason into pm_message_t.
> contine - resumes from a "halt"
>
> continue(struct device * dev, struct system_state * sys_state, int reason);
> @dev - the device
> @sys_state - a data structure containing information about the intended
> global system power state
> @reason - why we are resuming operation (ex. RUNTIME_CHANGES (like cpufreq),
> SYSTEM_RESUME)
Now, here you have a point. resume() should get pm_message_t,
too. This should be rather easy to change (simple matter of coding),
and we have agreed before that it is good idea. Patches welcome.
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
