On Tue, Jun 1, 2010 at 8:24 PM, Gross, Mark <mark.gross@xxxxxxxxx> wrote: > > >>-----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. This depends on the hardware but if you can enable the wakeup event before you turn the interrupt off you don't have a race (msm works this way). On other hardware the interrupt controller is the wakeup source so by masking the interrupt during suspend instead or turning it off altogether you also don't have a 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. The 5 second timeout on keyevents are there to avoid blocking suspend forever if someone opens an input device and don't read from it. The suspend blocker patchset uses an ioctl to enable the suspend blocker so it does not have this timeout. Either way, the 5 second timeout is not how the system normally goes back to sleep after a key event. I do think timeouts are useful so a driver can keep the system awake for a while after passing an event to a subsystem that has not been modified to block suspend (tty, network etc) but I don't think we should force subsystems that can easily use overlapping constraints (like input events) to keep the system awake for longer than needed. > > --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 > -- Arve Hjønnevåg _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
