Hi!
> > > IMO it can be done in two different ways:
> > > 1) via a .suspend() argument
> > > 2) via a global variable that the drivers can read.
>
> For sufficiently small values of "two" that is.
>
> Other solutions that have been described on the PM list include
>
> 3) Providing accessors to the information actually needed
> in drivers ... e.g. say whether this clock or power domain
> will be available in that target state.
>
> 4) Act more like "current" ... there's a function returning
> whatever "state" struct is settled on. (But ideally
> without the pseudo-global.)
>
> I'm amused that nobody really reacted to the technical comments in
> my previous posts on this thread. That's unfortunate, since from
> where I sit it feels to me like everyone else is a johnny-come-lately
> on this issue, and is now grasping at the quickest and dirtiest ways
> to work around the issue instead of coming to grasp with the various
> underlying issues.
Well, rest of the word is still using PC here, so johny-come-lately
may not be completely unexpected.
Could you push framework for some embedded system you care about? OLPC
by chance?
> IMO #3 is strongly preferable.
3) actually looks ok to me. For acpi it would mean
int acpi_state_we_are_entering(void)
returning S1..S4, right?
> But I really thought the discussion on new PM methods, back a
> couple months now, was going to finally get rid of that.
Umm, well, when someone gets to implement that...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
