On Fri, 04 Jun 2010 09:24:06 -0500 James Bottomley <[email protected]> wrote:
> On Fri, 2010-06-04 at 11:59 +0200, Ingo Molnar wrote: > > Anyway, i'm not pessimistic at all: _some_ sort of scheme appears to be > > crystalising out today. Everyone seems to agree now that the main usecases > > are > > indeed useful and need handling one way or another - the rest is really > > just > > technological discussions how to achieve the mostly-agreed-upon end goal. > > It's still not clear to me whether everyone's revolving around to using > the current suspend block API because it's orthogonal to all other > mechanisms and is therefore separate from the kernel (and can be > compiled out if you don't want it). Or whether re-expressing what the > android drivers want (minimum idle states and suspend block) in pm_qos > terms which others can use is the way to go. I think the latter, but > I'd like to know what other people think (because I'm not wedded to this > preference). I'd like to know that also. I have a patch to add pm_qos_add_request_nonblock function, so it is possible to register an pm_qos constraint by passing preallocated memory to it. Notifying should be possible to do from atomic contexts via async_schedule()? The scalability issues of pm_qos can be adressed by using plists for all pm_qos_class'es. Or by having the different pm_qos_class'es provide their own implementations for the update and get operations. Cheers, Flo > > James > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
