Re: Nested suspends; messages vs. states

[Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

Hi!

> > > > Note that rather than enter_state, I'd rather just have a function
> > > > pointer enter_this_state in the driver state array ...
> > >
> > > Wouldn't that imply a different ->enter_state() method for each system
> > > state?
> >
> > one enter state method for each driver state. If the driver has one
> > enter state for each system state, then go for it.
> 
> Two things:
> 
> 1) I meant just 1 ->enter_state() entry point for the core to call. It
> won't call a different function depending on the state; it will leave it
> up to the driver to determine what state to enter/what function to call.
> Internally (or in its bus core), is where the array of enter_state()
> methods would reside. Do you agree?
> 
> 2) The system states are totally dependent on the platform. I don't see
> how we could have a sane array that encapsulates every possible system
> state. Thoughts?

Seems to me that suspend-to-RAM and suspend-to-DISK make sense, and
cover 90% of what people want to do. Add "standby" for "fast
suspend-to-RAM" and you cover even ARM. I'd say that's good enuogh.

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]