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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
