[linux-pm] States we need to represent

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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.

I dislike the whole even=ON thing... It will force driver to actually
look at the flags, which I intended to be only an exceptional thing.

> 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).

Hrm... I don't agree here, but it doesn't really matter at this point,
we can always add new events later.

> > > 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.

"it is very good idea to quiesce devices" <-- I misparsed that. I don't
like all that rhetoric. Let's just say that it requires device
quiescing. But again, you put too much emphasis on the various
even/flags combinations, as if it was an important thing, possibly
encouraging drivers to actually look at the flags, which I think isn't
good. Those are details that should only concern a few drivers who need
special case. Let's keep the documentation clear about what the main
events are and what is required of them, and that most drivers shouldn't
need to look at the flags.

> > > 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.

Sure. No time at the moment, but I will later.

Ben.




[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux