On Mon, Oct 04, 2010 at 01:04:09AM +0200, Rafael J. Wysocki wrote:
quoted text
> On Monday, October 04, 2010, mark gross wrote:
> > On Mon, Sep 20, 2010 at 07:57:40PM +0200, Rafael J. Wysocki wrote:
> > > Hi,
> > > 
> > > The following two patches are ready to go into linux-next from my point of
> > > view, so please let me know if there are any objections:
> > > 
> > > [1/2] - PM / Wakeup: Introduce wakeup source objects and event statistics (v3)
> > > 
> > > [2/2] - PM: Fix potential issue with failing asynchronous suspend
> > > 
> > > Thanks,
> > > Rafael
> > 
> > Sorry for the late response but, what user feed back will this provide
> > to the OS stack looking to put the system in a low power state?
> > 
> > There are 2 cases I can think of:
> > 1) system wakes from an event that user mode needs to handle (i.e. key
> > press or phone ring or alarm events)
> > 2) system wakes (or more likely, is blocked from suspending) by a
> > kernel critical section, say if USB-OTG is connected.
> > 
> > When wake's are of the type 1, then the power manager service could
> > simply wait for a user mode wake lock be taken and released from the
> > usermode before re-attempting to suspend.
> > 
> > When the wakes are of type 2, a power manager service thread would need
> > to do a select on a system file and be woken up to re-try the suspend
> > after the suspend-blocking is no longer needed.
> 
> IMO it is more convenient to implement that in a different way, but
> generally I think you're right.
> 
> > Do you think I should cobble together an android PM driver that plugs
> > into your code to expose an ABI for the 2 cases listed above?
> 
> Well, I'm not sure if I understand correctly, can you elaborate a bit, please?

Well, before I saw your patch I was thinking about implementing an
Android PM driver that would request a pm_qos active request that would
be notified and interface with your wake event code.  It would also
expose a misc /dev/susped_blocked node that would be signaled when the
pm_qos active request went to zero.

Now I'm sort of making things up as I go but, some sort of non-poling
mechanism to re-attempt the suspend, for type 2, is needed but I'm not
sure where to put it now.

Also, we may want to think about registering events that user mode will
handle, and all others are treated as type 2 events.


quoted text
> > Also, with this do we want to revisit a pm_qos class for "active"
> > systems?  Or do you think thats redundant now?
> 
> I don't really think the pm_qos for "active" systems is really necessary at
> this point.
>

I'm still studying the patch but, you are likely right.  I need to look
at how much overhead changing the suspend blocking/unblocking is
handled.  I expect that some drivers will be hitting it on hot code
paths.

--mark

quoted text
> Thanks,
> Rafael
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/