On Mon, Jun 21, 2010 at 08:10:58AM -0400, tytso@xxxxxxx wrote: > So where are we at this point? The patches are in James Bottomly's tree. > Discussion had completely died down for a while, and it's picked up > again, but it's not clear to me that we're any closer to reaching > consensus. I thought we (linux community and Android) where ok with the plist / pm-qos implementation of the building blocks needed to implement the suspend blocker feature on top of a pm-qos request class (I think the name was "interactive") pretty much the exact same symantecs as the suspend blocker thing, just with pm-qos kernel api's. > There's been one proposal that we simply merge in a set of no-op > inline functions for suspend blockers, just so we can get let the > drivers go in (assuming that Greg K-H believes this is still a > problem), but with an automatical removal of N months (N to be > decided, say 9 or 12 or 18 months). I'd rather see the re-tooling of pmqos happen. > > My concern is that if we do that, we will have simply kicked the ball > down the road for N months. Another approach is to simply merge in > no-op functions and not leave any kind of deprecation schedule. > That's sort of an implicit admission of the fact that we may not reach > consensus on this issue. Or we could simply ship the patches as-is to > Linus after he gets back from vacation and ask him for a thumbs up or > thumbs down vote, which might settle things once and for all. > > How do we go forward from here? > put the pm_qos -plist update into linux-next? --mgross _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
