Messages in this thread | | | Date | Mon, 21 Jun 2010 18:07:04 -0700 | From | mark gross <> | Subject | Re: [RFC][PATCH] PM: Avoid losing wakeup events during suspend |
| |
On Mon, Jun 21, 2010 at 08:10:58AM -0400, tytso@mit.edu 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
| |