lp_events: an lternitive to suspend blocker user mode and kernel API

From 5061a182e18520da792760e2008c3f051f032426 Mon Sep 17 00:00:00 2001

Low Power Events is a possible alternative to suspend blocker / wake lock API used by Android.

Low Power Events is a possible alternative to suspend blocker / wake lock API used by Android.

Quoted 2 lines · On Sun, 30 May 2010 13:04:10 -0700 mark gross <[email protected]> wrote:

Low Power Events is a possible alternative to suspend blocker / wake lock API used by Android.

Here is how I see your proposal. It is of course possible that I misunderstood bits, so please correct me where I'm wrong.

1/ You have introduced a new mechanism for requesting a transition
to a low power state. This involves writing a number to /dev/lpe_enter. It is not clear to me from your text what the magic number really means. I think this parallels writing to /sys/power/state, but achieves the same result though a different mechanism and adds some extra checking.
So: I don't understand the numbers, and I don't see why we need a
second way to request a low power state. Probably I missed something important.

2/ Rather than tracking wake-events from the hardware up through possibly
several kernel modules, you go directly from hardware to user-space so each event is potentially presented to user-space twice: once as a "wake up from low power state" event and once following the normal path (maybe a key-press event, maybe a serial-port event, maybe a network receive event). I can see that this is a very tempting approach. It allows all those intermediate modules to remain unchanged and that is good. However it isn't clear to me that this would be easy for user-space to use correctly.
When an lpe event arrived it would need to wait around for the real event to arrive and then process that. I probably wouldn't wait long, but it would be an indeterminate wait, and it might not be trivial to determine if all events that would cause a wake-up have been consumed as a direct mapping from lpe event to normal event may not always be possible. Maybe this is more of a theoretical problem and in practice it would be easy to get it right - I don't have enough concrete experience to be sure.

So: I like the idea of leaving the intermediate layers unchanged, but I'm not convinced it would work.

Quoted 2 lines · On Sun, 30 May 2010 13:04:10 -0700 mark gross <[email protected]> wrote:

Low Power Events is a possible alternative to suspend blocker / wake lock API used by Android.

Here is how I see your proposal. It is of course possible that I misunderstood bits, so please correct me where I'm wrong.

1/ You have introduced a new mechanism for requesting a transition
to a low power state. This involves writing a number to /dev/lpe_enter. It is not clear to me from your text what the magic number really means. I think this parallels writing to /sys/power/state, but achieves the same result though a different mechanism and adds some extra checking.
So: I don't understand the numbers, and I don't see why we need a
second way to request a low power state. Probably I missed something important.

2/ Rather than tracking wake-events from the hardware up through possibly
several kernel modules, you go directly from hardware to user-space so each event is potentially presented to user-space twice: once as a "wake up from low power state" event and once following the normal path (maybe a key-press event, maybe a serial-port event, maybe a network receive event). I can see that this is a very tempting approach. It allows all those intermediate modules to remain unchanged and that is good. However it isn't clear to me that this would be easy for user-space to use correctly.
When an lpe event arrived it would need to wait around for the real event to arrive and then process that. I probably wouldn't wait long, but it would be an indeterminate wait, and it might not be trivial to determine if all events that would cause a wake-up have been consumed as a direct mapping from lpe event to normal event may not always be possible. Maybe this is more of a theoretical problem and in practice it would be easy to get it right - I don't have enough concrete experience to be sure.

So: I like the idea of leaving the intermediate layers unchanged, but I'm not convinced it would work.

Quoted 17 lines · On Mon, 31 May 2010 09:57:53 +1000 Neil Brown <[email protected]> wrote:

2/ Rather than tracking wake-events from the hardware up through possibly
several kernel modules, you go directly from hardware to user-space so each event is potentially presented to user-space twice: once as a "wake up from low power state" event and once following the normal path (maybe a key-press event, maybe a serial-port event, maybe a network receive event). I can see that this is a very tempting approach. It allows all those intermediate modules to remain unchanged and that is good. However it isn't clear to me that this would be easy for user-space to use correctly.
When an lpe event arrived it would need to wait around for the real event to arrive and then process that. I probably wouldn't wait long, but it would be an indeterminate wait, and it might not be trivial to determine if all events that would cause a wake-up have been consumed as a direct mapping from lpe event to normal event may not always be possible. Maybe this is more of a theoretical problem and in practice it would be easy to get it right - I don't have enough concrete experience to be sure.

Quoted 2 lines

So: I like the idea of leaving the intermediate layers unchanged, but I'm not convinced it would work.

To add to this: Is it a correct assumption
that all wake-up events that leave a driver trickle eventually up to userspace?

I think splitting the actual driver product (i.e. keypress or whatever) of a wake-up-event and it's corresponding wake-lock is not possible. Because you would have to _somehow_ map the block back to the product when you consume the product.

If you want to abstract the blocking from the kernel-code you probably have to introduce an abstract "driver-product" entity where you can do all your blocking associated with the product but hidden from the code that uses the product. (Which I don't think is feasible, because it increases overhead)

Or am I on the wrong track here?

Quoted 17 lines · On Mon, 31 May 2010 09:57:53 +1000 Neil Brown <[email protected]> wrote:

2/ Rather than tracking wake-events from the hardware up through possibly
several kernel modules, you go directly from hardware to user-space so each event is potentially presented to user-space twice: once as a "wake up from low power state" event and once following the normal path (maybe a key-press event, maybe a serial-port event, maybe a network receive event). I can see that this is a very tempting approach. It allows all those intermediate modules to remain unchanged and that is good. However it isn't clear to me that this would be easy for user-space to use correctly.
When an lpe event arrived it would need to wait around for the real event to arrive and then process that. I probably wouldn't wait long, but it would be an indeterminate wait, and it might not be trivial to determine if all events that would cause a wake-up have been consumed as a direct mapping from lpe event to normal event may not always be possible. Maybe this is more of a theoretical problem and in practice it would be easy to get it right - I don't have enough concrete experience to be sure.

Quoted 2 lines

So: I like the idea of leaving the intermediate layers unchanged, but I'm not convinced it would work.

To add to this: Is it a correct assumption
that all wake-up events that leave a driver trickle eventually up to userspace?

I think splitting the actual driver product (i.e. keypress or whatever) of a wake-up-event and it's corresponding wake-lock is not possible. Because you would have to _somehow_ map the block back to the product when you consume the product.

If you want to abstract the blocking from the kernel-code you probably have to introduce an abstract "driver-product" entity where you can do all your blocking associated with the product but hidden from the code that uses the product. (Which I don't think is feasible, because it increases overhead)

Or am I on the wrong track here?

Quoted 32 lines · On Mon, 31 May 2010 08:43:56 +0200 Florian Mickler <[email protected]> wrote:

Quoted 17 lines · On Mon, 31 May 2010 09:57:53 +1000 Neil Brown <[email protected]> wrote:

2/ Rather than tracking wake-events from the hardware up through possibly
several kernel modules, you go directly from hardware to user-space so each event is potentially presented to user-space twice: once as a "wake up from low power state" event and once following the normal path (maybe a key-press event, maybe a serial-port event, maybe a network receive event). I can see that this is a very tempting approach. It allows all those intermediate modules to remain unchanged and that is good. However it isn't clear to me that this would be easy for user-space to use correctly.
When an lpe event arrived it would need to wait around for the real event to arrive and then process that. I probably wouldn't wait long, but it would be an indeterminate wait, and it might not be trivial to determine if all events that would cause a wake-up have been consumed as a direct mapping from lpe event to normal event may not always be possible. Maybe this is more of a theoretical problem and in practice it would be easy to get it right - I don't have enough concrete experience to be sure.

Quoted 2 lines

So: I like the idea of leaving the intermediate layers unchanged, but I'm not convinced it would work.

To add to this: Is it a correct assumption
that all wake-up events that leave a driver trickle eventually up to userspace?

I think splitting the actual driver product (i.e. keypress or whatever) of a wake-up-event and it's corresponding wake-lock is not possible. Because you would have to _somehow_ map the block back to the product when you consume the product.

Quoted 7 lines

If you want to abstract the blocking from the kernel-code you probably have to introduce an abstract "driver-product" entity where you can do all your blocking associated with the product but hidden from the code that uses the product. (Which I don't think is feasible, because it increases overhead)

Or am I on the wrong track here?

I just realized, that you can cancel lpe_blocks via delete_lpe_block(), so this is not an issue at all.
They can be used just like suspend blockers.

Also the mapping of lpe_block to "wake event" is the same problem as with the suspend_blockers...

So I don't think this is a bad idea after all. It decouples the suspend_blockers from "suspend" quite nicely.
Although it still is only "block" or "no block" and not, as was suggested some sort of more fine grained requirement definition.

Cheers,
Flo

Quoted 32 lines · On Mon, 31 May 2010 08:43:56 +0200 Florian Mickler <[email protected]> wrote:

Quoted 17 lines · On Mon, 31 May 2010 09:57:53 +1000 Neil Brown <[email protected]> wrote:

2/ Rather than tracking wake-events from the hardware up through possibly
several kernel modules, you go directly from hardware to user-space so each event is potentially presented to user-space twice: once as a "wake up from low power state" event and once following the normal path (maybe a key-press event, maybe a serial-port event, maybe a network receive event). I can see that this is a very tempting approach. It allows all those intermediate modules to remain unchanged and that is good. However it isn't clear to me that this would be easy for user-space to use correctly.
When an lpe event arrived it would need to wait around for the real event to arrive and then process that. I probably wouldn't wait long, but it would be an indeterminate wait, and it might not be trivial to determine if all events that would cause a wake-up have been consumed as a direct mapping from lpe event to normal event may not always be possible. Maybe this is more of a theoretical problem and in practice it would be easy to get it right - I don't have enough concrete experience to be sure.

Quoted 2 lines

So: I like the idea of leaving the intermediate layers unchanged, but I'm not convinced it would work.

To add to this: Is it a correct assumption
that all wake-up events that leave a driver trickle eventually up to userspace?

I think splitting the actual driver product (i.e. keypress or whatever) of a wake-up-event and it's corresponding wake-lock is not possible. Because you would have to _somehow_ map the block back to the product when you consume the product.

Quoted 7 lines

If you want to abstract the blocking from the kernel-code you probably have to introduce an abstract "driver-product" entity where you can do all your blocking associated with the product but hidden from the code that uses the product. (Which I don't think is feasible, because it increases overhead)

Or am I on the wrong track here?

I just realized, that you can cancel lpe_blocks via delete_lpe_block(), so this is not an issue at all.
They can be used just like suspend blockers.

Also the mapping of lpe_block to "wake event" is the same problem as with the suspend_blockers...

So I don't think this is a bad idea after all. It decouples the suspend_blockers from "suspend" quite nicely.
Although it still is only "block" or "no block" and not, as was suggested some sort of more fine grained requirement definition.

Cheers,
Flo

Quoted 9 lines · On Mon, 31 May 2010 09:57:53 +1000 Neil Brown <[email protected]> wrote:

Quoted 2 lines · On Sun, 30 May 2010 13:04:10 -0700 mark gross <[email protected]> wrote:

Low Power Events is a possible alternative to suspend blocker / wake lock API used by Android.

Here is how I see your proposal. It is of course possible that I misunderstood bits, so please correct me where I'm wrong.

Quoted 8 lines

1/ You have introduced a new mechanism for requesting a transition
to a low power state. This involves writing a number to /dev/lpe_enter. It is not clear to me from your text what the magic number really means. I think this parallels writing to /sys/power/state, but achieves the same result though a different mechanism and adds some extra checking.
So: I don't understand the numbers, and I don't see why we need a
second way to request a low power state. Probably I missed something important.

I can only think for lpe to provide the levels and have userspace and platform code hook into there. Else you would have a dependency from userspace to platform code.

Quoted 18 lines

2/ Rather than tracking wake-events from the hardware up through possibly
several kernel modules, you go directly from hardware to user-space so each event is potentially presented to user-space twice: once as a "wake up from low power state" event and once following the normal path (maybe a key-press event, maybe a serial-port event, maybe a network receive event). I can see that this is a very tempting approach. It allows all those intermediate modules to remain unchanged and that is good. However it isn't clear to me that this would be easy for user-space to use correctly.
When an lpe event arrived it would need to wait around for the real event to arrive and then process that. I probably wouldn't wait long, but it would be an indeterminate wait, and it might not be trivial to determine if all events that would cause a wake-up have been consumed as a direct mapping from lpe event to normal event may not always be possible. Maybe this is more of a theoretical problem and in practice it would be easy to get it right - I don't have enough concrete experience to be sure.

Quoted 2 lines

So: I like the idea of leaving the intermediate layers unchanged, but I'm not convinced it would work.

To add to this: Is it a correct assumption
that all wake-up events that leave a driver trickle eventually up to userspace?

I think splitting the actual driver product (i.e. keypress or whatever) of a wake-up-event and it's corresponding wake-lock is not possible. Because you would have to _somehow_ map the block back to the product when you consume the product.

If you want to abstract the blocking from the kernel-code you probably have to introduce an abstract "driver-product" entity where you can do all your blocking associated with the product but hidden from the code that uses the product. (Which I don't think is feasible, because it increases overhead)

Or am I on the wrong track here?

cheers,
Flo

Quoted 9 lines · On Mon, 31 May 2010 09:57:53 +1000 Neil Brown <[email protected]> wrote:

Quoted 2 lines · On Sun, 30 May 2010 13:04:10 -0700 mark gross <[email protected]> wrote:

Low Power Events is a possible alternative to suspend blocker / wake lock API used by Android.

Here is how I see your proposal. It is of course possible that I misunderstood bits, so please correct me where I'm wrong.

Quoted 8 lines

1/ You have introduced a new mechanism for requesting a transition
to a low power state. This involves writing a number to /dev/lpe_enter. It is not clear to me from your text what the magic number really means. I think this parallels writing to /sys/power/state, but achieves the same result though a different mechanism and adds some extra checking.
So: I don't understand the numbers, and I don't see why we need a
second way to request a low power state. Probably I missed something important.

I can only think for lpe to provide the levels and have userspace and platform code hook into there. Else you would have a dependency from userspace to platform code.

Quoted 18 lines

2/ Rather than tracking wake-events from the hardware up through possibly
several kernel modules, you go directly from hardware to user-space so each event is potentially presented to user-space twice: once as a "wake up from low power state" event and once following the normal path (maybe a key-press event, maybe a serial-port event, maybe a network receive event). I can see that this is a very tempting approach. It allows all those intermediate modules to remain unchanged and that is good. However it isn't clear to me that this would be easy for user-space to use correctly.
When an lpe event arrived it would need to wait around for the real event to arrive and then process that. I probably wouldn't wait long, but it would be an indeterminate wait, and it might not be trivial to determine if all events that would cause a wake-up have been consumed as a direct mapping from lpe event to normal event may not always be possible. Maybe this is more of a theoretical problem and in practice it would be easy to get it right - I don't have enough concrete experience to be sure.

Quoted 2 lines

So: I like the idea of leaving the intermediate layers unchanged, but I'm not convinced it would work.

To add to this: Is it a correct assumption
that all wake-up events that leave a driver trickle eventually up to userspace?

I think splitting the actual driver product (i.e. keypress or whatever) of a wake-up-event and it's corresponding wake-lock is not possible. Because you would have to _somehow_ map the block back to the product when you consume the product.

If you want to abstract the blocking from the kernel-code you probably have to introduce an abstract "driver-product" entity where you can do all your blocking associated with the product but hidden from the code that uses the product. (Which I don't think is feasible, because it increases overhead)

Or am I on the wrong track here?

cheers,
Flo

Quoted 2 lines · On Sun, 30 May 2010 13:04:10 -0700 mark gross <[email protected]> wrote:

Low Power Events is a possible alternative to suspend blocker / wake lock API used by Android.

Here is how I see your proposal. It is of course possible that I misunderstood bits, so please correct me where I'm wrong.

1/ You have introduced a new mechanism for requesting a transition
to a low power state. This involves writing a number to /dev/lpe_enter. It is not clear to me from your text what the magic number really means. I think this parallels writing to /sys/power/state, but achieves the same result though a different mechanism and adds some extra checking.
So: I don't understand the numbers, and I don't see why we need a
second way to request a low power state. Probably I missed something important.

2/ Rather than tracking wake-events from the hardware up through possibly
several kernel modules, you go directly from hardware to user-space so each event is potentially presented to user-space twice: once as a "wake up from low power state" event and once following the normal path (maybe a key-press event, maybe a serial-port event, maybe a network receive event). I can see that this is a very tempting approach. It allows all those intermediate modules to remain unchanged and that is good. However it isn't clear to me that this would be easy for user-space to use correctly.

When an lpe event arrived it would need to wait around for the real event to arrive and then process that. I probably wouldn't wait long, but it would be an indeterminate wait, and it might not be trivial to determine if all events that would cause a wake-up have been consumed as a direct mapping from lpe event to normal event may not always be possible. Maybe this is more of a theoretical problem and in practice it would be easy to get it right - I don't have enough concrete experience to be sure.

So: I like the idea of leaving the intermediate layers unchanged, but I'm not convinced it would work.

3/ You have created a new mechanism for passing events to user-space. That
seems unnecessary. We already have the input subsystem which is pretty good at communication arbitrary events, and the events you are dealing with a very much like input events.

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.

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.

Thanks,
NeilBrown

On Mon, May 31, 2010 at 09:57:53AM +1000, Neil Brown wrote:

Quoted 5 lines

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.

Quoted 3 lines

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.

Quoted 1 line · mark gross

On Mon, May 31, 2010 at 09:57:53AM +1000, Neil Brown wrote:

...

Quoted 8 lines

Quoted 5 lines

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.

Quoted 5 lines

Quoted 3 lines

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?

Quoted 11 lines · Rafael J. Wysocki

Quoted 1 line · mark gross

On Mon, May 31, 2010 at 09:57:53AM +1000, Neil Brown wrote:

...

Quoted 8 lines

Quoted 5 lines

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.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

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.

Quoted 11 lines · Rafael J. Wysocki

Quoted 1 line · mark gross

On Mon, May 31, 2010 at 09:57:53AM +1000, Neil Brown wrote:

...

Quoted 8 lines

Quoted 5 lines

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.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

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.

Quoted 20 lines · mark gross

Quoted 11 lines · Rafael J. Wysocki

Quoted 1 line · mark gross

On Mon, May 31, 2010 at 09:57:53AM +1000, Neil Brown wrote:

...

Quoted 8 lines

Quoted 5 lines

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.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

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?

Quoted 8 lines

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.

Signature · 1 line

Arve Hjønnevåg

Quoted 30 lines · mark gross

Quoted 28 lines · Rafael J. Wysocki

Quoted 11 lines · mark gross

Quoted 1 line · Neil Brown

...

Quoted 8 lines

Quoted 5 lines

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.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

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.

Quoted 1 line

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.

Quoted 30 lines · mark gross

Quoted 28 lines · Rafael J. Wysocki

Quoted 11 lines · mark gross

Quoted 1 line · Neil Brown

...

Quoted 8 lines

Quoted 5 lines

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.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

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.

Quoted 1 line

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.

-----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]>:

Quoted 6 lines · Arve Hjønnevåg

Quoted 5 lines · mark gross

Quoted 4 lines · Rafael J. Wysocki

Quoted 3 lines · mark gross

Quoted 1 line · Neil Brown

...

approach?

Quoted 12 lines

Quoted 11 lines

Quoted 9 lines

Quoted 1 line

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.

Quoted 5 lines

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?

Quoted 5 lines

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]>:

Quoted 6 lines · Arve Hjønnevåg

Quoted 5 lines · mark gross

Quoted 4 lines · Rafael J. Wysocki

Quoted 3 lines · mark gross

Quoted 1 line · Neil Brown

...

approach?

Quoted 12 lines

Quoted 11 lines

Quoted 9 lines

Quoted 1 line

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.

Quoted 5 lines

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?

Quoted 5 lines

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

Quoted 12 lines

-----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

Quoted 7 lines

2010/6/1 mark gross <[email protected]>:

Quoted 6 lines · Arve Hjønnevåg

Quoted 5 lines · mark gross

Quoted 4 lines · Rafael J. Wysocki

Quoted 3 lines · mark gross

Quoted 1 line · Neil Brown

...

[mtg: ] snipping outlook bollixed formatting of history.

Quoted 19 lines

approach?

Quoted 17 lines

Quoted 11 lines

Quoted 9 lines

Quoted 1 line

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.

Quoted 2 lines

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.

Quoted 5 lines

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

Quoted 9 lines

Quoted 5 lines

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

Quoted 12 lines

-----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

Quoted 7 lines

2010/6/1 mark gross <[email protected]>:

Quoted 6 lines · Arve Hjønnevåg

Quoted 5 lines · mark gross

Quoted 4 lines · Rafael J. Wysocki

Quoted 3 lines · mark gross

Quoted 1 line · Neil Brown

...

[mtg: ] snipping outlook bollixed formatting of history.

Quoted 19 lines

approach?

Quoted 17 lines

Quoted 11 lines

Quoted 9 lines

Quoted 1 line

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.

Quoted 2 lines

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.

Quoted 5 lines

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

Quoted 9 lines

Quoted 5 lines

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

Quoted 20 lines · mark gross

Quoted 11 lines · Rafael J. Wysocki

Quoted 1 line · mark gross

On Mon, May 31, 2010 at 09:57:53AM +1000, Neil Brown wrote:

...

Quoted 8 lines

Quoted 5 lines

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.

Quoted 8 lines

Quoted 5 lines

Quoted 3 lines

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?

Quoted 8 lines

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.

Signature · 1 line

Arve Hjønnevåg

Quoted 1 line · mark gross

On Mon, May 31, 2010 at 09:57:53AM +1000, Neil Brown wrote:

...

Quoted 8 lines

Quoted 5 lines

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.

Quoted 5 lines

Quoted 3 lines

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?

On Mon, May 31, 2010 at 09:57:53AM +1000, Neil Brown wrote:

Quoted 5 lines

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.

Quoted 3 lines

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.

Quoted 2 lines · On Sun, 30 May 2010 13:04:10 -0700 mark gross <[email protected]> wrote:

Low Power Events is a possible alternative to suspend blocker / wake lock API used by Android.

Here is how I see your proposal. It is of course possible that I misunderstood bits, so please correct me where I'm wrong.

1/ You have introduced a new mechanism for requesting a transition
to a low power state. This involves writing a number to /dev/lpe_enter. It is not clear to me from your text what the magic number really means. I think this parallels writing to /sys/power/state, but achieves the same result though a different mechanism and adds some extra checking.
So: I don't understand the numbers, and I don't see why we need a
second way to request a low power state. Probably I missed something important.

2/ Rather than tracking wake-events from the hardware up through possibly
several kernel modules, you go directly from hardware to user-space so each event is potentially presented to user-space twice: once as a "wake up from low power state" event and once following the normal path (maybe a key-press event, maybe a serial-port event, maybe a network receive event). I can see that this is a very tempting approach. It allows all those intermediate modules to remain unchanged and that is good. However it isn't clear to me that this would be easy for user-space to use correctly.

When an lpe event arrived it would need to wait around for the real event to arrive and then process that. I probably wouldn't wait long, but it would be an indeterminate wait, and it might not be trivial to determine if all events that would cause a wake-up have been consumed as a direct mapping from lpe event to normal event may not always be possible. Maybe this is more of a theoretical problem and in practice it would be easy to get it right - I don't have enough concrete experience to be sure.

So: I like the idea of leaving the intermediate layers unchanged, but I'm not convinced it would work.

3/ You have created a new mechanism for passing events to user-space. That
seems unnecessary. We already have the input subsystem which is pretty good at communication arbitrary events, and the events you are dealing with a very much like input events.

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.

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.

Thanks,
NeilBrown

Low Power Events is a possible alternative to suspend blocker / wake lock API used by Android.

It provides comparable power state notification and kernel mode critical section definition.  It differs from suspend blocker in that:
1) it is a platform and device independent implementation.  Device specific code is register as lp_ops, similar to pm_ops.  Drivers use the platform independent functions.

2) it forces a user mode transition coming out of a LP state. Notification of wake up sources go to the user mode process managing the lp states.  Notification of blocked LP state entry is through an error return, and notification of un-blocking is through a file node as well.

I think the change need to the Google Android user mode power handling code can be limited to changes to _only_ "hardware/libhardware_legacy/power/power.c"

This code is still just a prototype of the platform independent code, and I'm implementing it on Eclair for the Intel Moorestown platform this weekend.  I'll have patches to eclair and updated kernel patches that enable this sometime Monday, after I bring it up on my target device. Hopefully by the end of next week I think I'll have it working well with Android.

At this time the following patch is only known to compile.  I send it to help with the discussion.

FWTW I do work on Android at Intel and I think I can make this work. (well, today I do.)

--mgross

Draft kernel patch :

Low Power Events is a possible alternative to suspend blocker / wake lock API used by Android.

It provides comparable power state notification and kernel mode critical section definition.  It differs from suspend blocker in that:
1) it is a platform and device independent implementation.  Device specific code is register as lp_ops, similar to pm_ops.  Drivers use the platform independent functions.

2) it forces a user mode transition coming out of a LP state. Notification of wake up sources go to the user mode process managing the lp states.  Notification of blocked LP state entry is through an error return, and notification of un-blocking is through a file node as well.

I think the change need to the Google Android user mode power handling code can be limited to changes to _only_ "hardware/libhardware_legacy/power/power.c"

This code is still just a prototype of the platform independent code, and I'm implementing it on Eclair for the Intel Moorestown platform this weekend.  I'll have patches to eclair and updated kernel patches that enable this sometime Monday, after I bring it up on my target device. Hopefully by the end of next week I think I'll have it working well with Android.

At this time the following patch is only known to compile.  I send it to help with the discussion.

FWTW I do work on Android at Intel and I think I can make this work. (well, today I do.)

--mgross

Draft kernel patch :

Quoted 9 lines · mark gross

Low Power Events is a possible alternative to suspend blocker / wake lock API used by Android.

It provides comparable power state notification and kernel mode critical section definition.  It differs from suspend blocker in that:
1) it is a platform and device independent implementation.  Device specific code is register as lp_ops, similar to pm_ops.  Drivers use the platform independent functions.

How is this more platform independent than suspend blockers?

Quoted 6 lines

2) it forces a user mode transition coming out of a LP state. Notification of wake up sources go to the user mode process managing the lp states.  Notification of blocked LP state entry is through an error return, and notification of un-blocking is through a file node as well.

If you want a user mode transition for every resume, you can easily get this with the opportunistic suspend patchset by sending an input event (or other a custom event with that blocks suspend) from a driver's resume hook.

Quoted 21 lines

I think the change need to the Google Android user mode power handling code can be limited to changes to _only_ "hardware/libhardware_legacy/power/power.c"

This code is still just a prototype of the platform independent code, and I'm implementing it on Eclair for the Intel Moorestown platform this weekend.  I'll have patches to eclair and updated kernel patches that enable this sometime Monday, after I bring it up on my target device. Hopefully by the end of next week I think I'll have it working well with Android.

At this time the following patch is only known to compile.  I send it to help with the discussion.

FWTW I do work on Android at Intel and I think I can make this work. (well, today I do.)

--mgross

Draft kernel patch :

...

Documentation/power/low_power_events_interface.txt line 34

Quoted 7 lines

Documentation/power/low_power_events_interface.txt new file +7 -0

+
+/dev/lpe_wake_event:
+reads from this returns a list of wake events that happened between entry
+into the LP state and the return from the read of the low_power_enter device
+node.  User mode is expected to do something with these events before
+re-trying to enter low power mode.
+

I don't think this will work very well. Multiple input events can be pending at the same time. If you register a single wake-event for an input device, you don't know if all the events have been read when you try to clear this wake-event.

Quoted 9 lines · mark gross

Low Power Events is a possible alternative to suspend blocker / wake lock API used by Android.

It provides comparable power state notification and kernel mode critical section definition.  It differs from suspend blocker in that:
1) it is a platform and device independent implementation.  Device specific code is register as lp_ops, similar to pm_ops.  Drivers use the platform independent functions.

How is this more platform independent than suspend blockers?

Quoted 6 lines

2) it forces a user mode transition coming out of a LP state. Notification of wake up sources go to the user mode process managing the lp states.  Notification of blocked LP state entry is through an error return, and notification of un-blocking is through a file node as well.

If you want a user mode transition for every resume, you can easily get this with the opportunistic suspend patchset by sending an input event (or other a custom event with that blocks suspend) from a driver's resume hook.

Quoted 21 lines

I think the change need to the Google Android user mode power handling code can be limited to changes to _only_ "hardware/libhardware_legacy/power/power.c"

This code is still just a prototype of the platform independent code, and I'm implementing it on Eclair for the Intel Moorestown platform this weekend.  I'll have patches to eclair and updated kernel patches that enable this sometime Monday, after I bring it up on my target device. Hopefully by the end of next week I think I'll have it working well with Android.

At this time the following patch is only known to compile.  I send it to help with the discussion.

FWTW I do work on Android at Intel and I think I can make this work. (well, today I do.)

--mgross

Draft kernel patch :

...

Documentation/power/low_power_events_interface.txt line 34

Quoted 7 lines

Documentation/power/low_power_events_interface.txt new file +7 -0

+
+/dev/lpe_wake_event:
+reads from this returns a list of wake events that happened between entry
+into the LP state and the return from the read of the low_power_enter device
+node.  User mode is expected to do something with these events before
+re-trying to enter low power mode.
+

I don't think this will work very well. Multiple input events can be pending at the same time. If you register a single wake-event for an input device, you don't know if all the events have been read when you try to clear this wake-event.