Re: [RFC] lp_events: an lternitive to suspend blocker user mode and kernel API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




>-----Original Message-----
>From: Arve Hjønnevåg [mailto:arve@xxxxxxxxxxx]
>Sent: Tuesday, June 01, 2010 8:10 PM
>To: markgross@xxxxxxxxxxx
>Cc: Rafael J. Wysocki; Gross, Mark; Neil Brown; Brian Swetland; linux-
>kernel@xxxxxxxxxxxxxxx; Arve@xxxxxxxxxxxxxxxxxxxxxxxxxx; Thomas Gleixner;
>linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx; Alan Cox
>Subject: Re:  [RFC] lp_events: an lternitive to suspend blocker
>user mode and kernel API
>
>2010/6/1 mark gross <640e9920@xxxxxxxxx>:
>> 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@xxxxxxxxx> 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
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm



[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux