Hi!
> > Updated proposal, if it looks okay, I'll submit it as a patch for
> > Documentation/power/devices.txt.
> >
> > pm_message_t meaning
> >
> > pm_message_t has two fields. event ("major"), and flags. If driver
> > does not know event code, it aborts the request, returning
> > error. Unknown flag should be non-fatal.
>
> Should it return an error ? If we want to add new events, like pre/post
> suspend or whatever else, do I need to fix all drivers ?
Pre-suspend can be nicely defined as event = ON, flags =
PREPARE_FOR_SUSPEND. I am not sure what new event would be... probably
some kinds of RUNTIME_SUSPEND would qualify (please enter low-power
state but remain functional; that does not imply freeze, right?). If
driver does not know what that's about, it should tell us.
> Also, we need to add pm_message_t argument to resume.
>
> > Event codes are:
> >
> > ON - no need to do anything except special cases like broken hw
> > FREEZE - stop dma and interrupts, and be prepared to reinit hw from scratch
> > SUSPEND - like FREEZE, but also put hardware into low-power state
>
> I think that
>
> 1) ON is useless. FREEZE is the logical semantic. It doesn't harm to
> FREEZE on reboot/halt, and it can even be useful since kexec uses that
> too.
>
> 2) Keep STANDBY (or IDLE) event. Even if nobody cares at this point,
> let's keep it. Handhelds will care. It's a "light" suspend state and we
> may even want to add several levels of STANDBY in the future. By having
> it defined here, the intend is made clear at least
I'd like to keep one event = SUSPEND. Level of suspension is
arbitrary; if driver does not enters deeper sleep state than you asked
it, you only loose some speed. That's why it should be selected by
flags. (Remeber, unknown event is fatal, unknown flag is
ignored. That's semantics we want).
> > Apm standby -- prepare for APM event. Theoretically, drivers do not
> > need to do anything. In practice, it is very good idea to quiesce
> > devices. event = FREEZE, flags = APM_STANDBY
>
> NO, it is NOT a good idea to put the HW in low power state. Some BIOSes
> will be very upset by that. It's ok to use that flag to deal with "known
> broken" BIOSes that fail to quiesce a known device and do it there, but
> the generic case is to NOT put the device into a low power state.
??? That is what I say. event is FREEZE, that means no low power state
is involved. I wonder why you read it like that.
> > System halt -- nothing is needed except in very rare cases. event
> > = ON, flags = SYSTEM_HALT.
>
> Check what kexec is using. Either that or reboot. It's good to quiesce
> the driver imho. Disk want to flush caches/spindown for safety.
If driver does not know how to freeze, I'd prefer it to do nothing for
halt. I see that freezing also makes sense... and yes we need to
spindown...
> > System fully on -- device is working normally; this is probably never
> > passed to suspend() method... event = ON, flags = 0
>
> Ok, looks good except for my few comments, _and_ I don't like your
> naming of the flags :) but that's a matter of taste... oh well...
Feel free to suggest better names for flags, this was just writeup.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
