Re: Problems with PM_FREEZE

[Pavel Machek <pavel@ucw.cz>]

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

Hi!

> > Pavel is obviously right that the clean solution is to add a pm_message_t 
> > argument to resume().
> 
> I tend to disagree with that.  Changing every resume() method is
> not "clean", and it's more obvious to me that the pm_message
> semantics are (still) problematic.  Any argument to resume() would
> be encouraging fragile "if (came_from(X)) { ... }" style logic.

Alan wants to cut few miliseconds from suspend-to-disk. That's okay
with me, just add pm_message_t to resume(). If it is okay to use it in
specific driver is other question.

> Heck, there's still no way for drivers to know what the target
> system state is ... and THAT is a core issue here.
> 
> During FREEZE, the target system state is "something snapshottable".
> During SUSPEND, it's one of numerous variants of "low power" ... and
> device drivers can only guess which one it'll be.  (Is it an ACPI
> state?  S1, S3, S4?  Some non-ACPI platform state?)

Why does your driver need to know? Anyway, extending pm_message_t with
flags is okay with me.

> Case in point:  in some system low power states, drivers need to turn
> off certain clocks, and may not be able to support wakeup.  In others,
> drivers leave those clocks on, and can support wakeup.  But there is
> no way to figure out the target state given the pm_message ...

Eh? I do not see how knowing S1 vs. S3 vs. S4 help you here. It looks
more like "does user want to resume from that?" question.

								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

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