> > > 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.
Sorry; changing every driver in the whole tree is in my book
under "things to avoid unless there's a more significant win".
> > 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.
Well, I've always said that what we want _instead of_ a pm_message
is just an object describing the platform-specific target state.
And clean definitions of those states.
I don't quite see how to map those to "flags".
> > 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.
The "user" will _always_ want to resume. S1/S3/S4 is only an answer
for ACPI systems (that don't use swsusp/"shutdown"!), and ISTR "video
needs to use PCI_D2 in S1 and S3" was a common issue (since PCI_D3
tends to expect re-init, but Linux developers don't have chip specs
saying how to re-init). But non-ACPI systems have similar issues.
I've given examples before with USB controllers, where the 48 MHz clock
must be turned off to enter certain system states, but not others;
and turning the clock off has _significant drawbacks_ that make it
sub-optimal to always do it. (Drawbacks like resetting the controller,
which disconnects all devices, and not supporting wakeup.)
- Dave
