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:
> ...
> > > So I would suggest modifying your proposal to simply create a new 'input'
> > > device. Any driver that supports wake-from-suspend queues an event to that
> > > device when a wakeup event occurs. If the device is open and has any queued
> > > events, then a suspend request such as 'echo mem > /sys/power/state' completes
> > > without going into full suspend.
> >
> > /me likes.
> >
> > > Then you just need to convince us that this mechanism can be used without any
> > > race problems. If it can, then it would certainly be a simple and
> > > unobtrusive approach.
> >
> > Lets find out.
>
> Simple question: how is that better than the Alan Stern's proposed 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.
(which to be fair, I seem to be the only one that feels thats a problem.
so perhaps I'm making that a bigger issue than it is...)
Also my current patch may be better in that it makes it explicit that we
need wake event notification up to user mode, where this Alan's leaves
it as an exercise for the integrator.
(wake events are not just key presses or lid events, there is modem,
UI, network, usb, block device insertion, RTC and likely a few other
wake events that need to be handled effectively before re-suspending.
so to answer your question: I'm not sure. I need to stub out what Alan
is proposing and hash it out with some folks. I'm sorry I can't be
decisive on this yet.
I'll stub out a new pm_qos class for "qos_eventually" (perhaps with a
better name.) some modes to the input event mechanism to see how that
feels.
--mgross
On Mon, May 31, 2010 at 10:09 PM, mark gross <[email protected]> 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:
>> ...
>> > > So I would suggest modifying your proposal to simply create a new 'input'
>> > > device. ?Any driver that supports wake-from-suspend queues an event to that
>> > > device when a wakeup event occurs. ?If the device is open and has any queued
>> > > events, then a suspend request such as 'echo mem > /sys/power/state' completes
>> > > without going into full suspend.
>> >
>> > /me likes.
>> >
>> > > Then you just need to convince us that this mechanism can be used without any
>> > > race problems. ?If it can, then it would certainly be a simple and
>> > > unobtrusive approach.
>> >
>> > Lets find out.
>>
>> Simple question: how is that better than the Alan Stern's proposed 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.
--
Arve Hj?nnev?g
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 <[email protected]> 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:
> >> ...
> >> > > So I would suggest modifying your proposal to simply create a new 'input'
> >> > > device. ?Any driver that supports wake-from-suspend queues an event to that
> >> > > device when a wakeup event occurs. ?If the device is open and has any queued
> >> > > events, then a suspend request such as 'echo mem > /sys/power/state' completes
> >> > > without going into full suspend.
> >> >
> >> > /me likes.
> >> >
> >> > > Then you just need to convince us that this mechanism can be used without any
> >> > > race problems. ?If it can, then it would certainly be a simple and
> >> > > unobtrusive approach.
> >> >
> >> > Lets find out.
> >>
> >> Simple question: how is that better than the Alan Stern's proposed 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.
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.
--mgross
> --
> Arve Hj?nnev?g
2010/6/1 mark gross <[email protected]>:
> 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 <[email protected]> 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:
>> >> ...
>> >> > > So I would suggest modifying your proposal to simply create a new 'input'
>> >> > > device. ?Any driver that supports wake-from-suspend queues an event to that
>> >> > > device when a wakeup event occurs. ?If the device is open and has any queued
>> >> > > events, then a suspend request such as 'echo mem > /sys/power/state' completes
>> >> > > without going into full suspend.
>> >> >
>> >> > /me likes.
>> >> >
>> >> > > Then you just need to convince us that this mechanism can be used without any
>> >> > > race problems. ?If it can, then it would certainly be a simple and
>> >> > > unobtrusive approach.
>> >> >
>> >> > Lets find out.
>> >>
>> >> Simple question: how is that better than the Alan Stern's proposed 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
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?
> 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
>-----Original Message-----
>From: Arve Hj?nnev?g [mailto:[email protected]]
>Sent: Tuesday, June 01, 2010 8:10 PM
>To: [email protected]
>Cc: Rafael J. Wysocki; Gross, Mark; Neil Brown; Brian Swetland; linux-
>[email protected]; [email protected]; Thomas Gleixner;
>[email protected]; Alan Cox
>Subject: Re: [linux-pm] [RFC] lp_events: an lternitive to suspend blocker
>user mode and kernel API
>
>2010/6/1 mark gross <[email protected]>:
>> 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 <[email protected]> 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
On Tue, Jun 1, 2010 at 8:24 PM, Gross, Mark <[email protected]> wrote:
>
>
>>-----Original Message-----
>>From: Arve Hj?nnev?g [mailto:[email protected]]
>>Sent: Tuesday, June 01, 2010 8:10 PM
>>To: [email protected]
>>Cc: Rafael J. Wysocki; Gross, Mark; Neil Brown; Brian Swetland; linux-
>>[email protected]; [email protected]; Thomas Gleixner;
>>[email protected]; Alan Cox
>>Subject: Re: [linux-pm] [RFC] lp_events: an lternitive to suspend blocker
>>user mode and kernel API
>>
>>2010/6/1 mark gross <[email protected]>:
>>> 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 <[email protected]> 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