Prev: good-day
Next: linux-next: manual merge of the drbd tree with the block tree
From: Gross, Mark on 1 Jun 2010 23:30


>-----Original Message-----
>From: Arve Hj�nnev�g [mailto:arve(a)android.com]
>Sent: Tuesday, June 01, 2010 8:10 PM
>To: markgross(a)thegnar.org
>Cc: Rafael J. Wysocki; Gross, Mark; Neil Brown; Brian Swetland; linux-
>kernel(a)vger.kernel.org; Arve(a)smtp1.linux-foundation.org; Thomas Gleixner;
>linux-pm(a)lists.linux-foundation.org; Alan Cox
>Subject: Re: [linux-pm] [RFC] lp_events: an lternitive to suspend blocker
>user mode and kernel API
>
>2010/6/1 mark gross <640e9920(a)gmail.com>:
>> On Mon, May 31, 2010 at 10:24:30PM -0700, Arve Hj�nnev�g wrote:
>>> On Mon, May 31, 2010 at 10:09 PM, mark gross <640e9920(a)gmail.com> wrote:
>>> > On Tue, Jun 01, 2010 at 12:45:21AM +0200, Rafael J. Wysocki wrote:
>>> >> On Tuesday 01 June 2010, mark gross wrote:
>>> >> > On Mon, May 31, 2010 at 09:57:53AM +1000, Neil Brown wrote:
>>> >> ...
[mtg: ] snipping outlook bollixed formatting of history.

>approach?
>>> >>
>>> > I just saw Alan Stern's proposal, and have gotten some input form some
>>> > others. �I can't say my patch represents a better Idea than what Alan
>>> > proposed. �However; what Alan (and Thomas) are talking about is
>>> > effectively the same as the kenrel mode wakelock/suspend blocker thing,
>>> > and although it reuses existing infrastructure, it doesn't solve the
>>> > problem of needing overlapping blocking sections of code from ISR to
>>> > user mode.
>>> >
>>>
>>> I don't think your solution solves this either.
>>
>> Why? �my proposal effectively removes the overlapping kernel blocking
>> sections uppon wake up by forcing the user mode to ack the wake event
>> and re-issue the suspend request explicitly. �That pretty much solves
>> that problem.
>>
>
>How to you ack the wakeup event in a safe way. Another wakeup event
>can come in after you decided to ack the last event. Also when the
[mtg: ] um, by blocking? Ok, I see your point here. I need more care here.

How real is this race? At some point you turn off interrupts before programming the wake up sources anyway, and between turning off interrupts and the programming of the wake up events on the way into the platform suspend you have the same race.

>user-space power manager reads that there was a wakeup event, how does
>it know if the real event has been delivered to user-space, and if the
>user-space code that consumed this event has had a chance to block
>suspend?
[mtg: ] I suppose the same way the uevent.c wake_lock handling does. (that code grabs a 5 second timeout wake lock on key events, not pretty either...) I think the idea of getting the wake events passing through the input layer could help with this.

--mgross

>
>> We can talk about whether or not it can be used effectively with Android
>> user mode PM or not, which I still think it can, but I need to try the
>> mods to power.c.
>>
>
>
>--
>Arve Hj�nnev�g
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: good-day
Next: linux-next: manual merge of the drbd tree with the block tree