headers
Neil Brown | 1 Jun 2010 01:00
Picon
Gravatar

Re: [PATCH 0/8] Suspend block api (version 8)

On Tue, 1 Jun 2010 00:05:19 +0200
"Rafael J. Wysocki" <rjw <at> sisk.pl> wrote:

> On Monday 31 May 2010, Neil Brown wrote:
> > On Thu, 27 May 2010 23:40:29 +0200 (CEST)
> > Thomas Gleixner <tglx <at> linutronix.de> wrote:
> > 
> > > On Thu, 27 May 2010, Rafael J. Wysocki wrote:
> > > 
> > > > On Thursday 27 May 2010, Thomas Gleixner wrote:
> > > > > On Thu, 27 May 2010, Alan Stern wrote:
> > > > > 
> > > > > > On Thu, 27 May 2010, Felipe Balbi wrote:
> > > > > > 
> > > > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> > > > > > > >If people don't mind, here is a greatly simplified summary of the
> > > > > > > >comments and objections I have seen so far on this thread:
> > > > > > > >
> > > > > > > >	The in-kernel suspend blocker implementation is okay, even
> > > > > > > >	beneficial.
> > > > > > > 
> > > > > > > I disagree here. I believe expressing that as QoS is much better. Let 
> > > > > > > the kernel decide which power state is better as long as I can say I 
> > > > > > > need 100us IRQ latency or 100ms wakeup latency.
> > > > > > 
> > > > > > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > > > > > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> > > > > 
> > > > > mem should be replaced by an idle suspend to ram mechanism
> > > >
(Continue reading)

Permalink | Reply | 74 comments |
headers
mark gross | 1 Jun 2010 01:03
Picon

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

On Mon, May 31, 2010 at 02:55:16AM -0700, Arve Hjønnevåg wrote:
> On Sun, May 30, 2010 at 1:04 PM, mark gross <640e9920 <at> gmail.com> wrote:
> > 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?

You don't have to do "suspend to ram" for the low power mode and one
could could entertain something different form S2R.

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

the input event thing looks like a way to go.

> > I think the change need to the Google Android user mode power handling
(Continue reading)

Permalink | Reply | 0 comments |
headers
mark gross | 1 Jun 2010 01:26
Picon

Re: [PATCH 0/8] Suspend block api (version 8)

On Mon, May 31, 2010 at 11:38:55PM +0200, Rafael J. Wysocki wrote:
> On Monday 31 May 2010, Arve Hjønnevåg wrote:
> > 2010/5/29 Alan Stern <stern <at> rowland.harvard.edu>:
> > > On Sat, 29 May 2010, Arve Hjønnevåg wrote:
> > >
> > >> > In place of in-kernel suspend blockers, there will be a new type of QoS
> > >> > constraint -- call it QOS_EVENTUALLY.  It's a very weak constraint,
> > >> > compatible with all cpuidle modes in which runnable threads are allowed
> > >> > to run (which is all of them), but not compatible with suspend.
> > >> >
> > >> This sound just like another API rename. It will work, but given that
> > >> suspend blockers was the name least objectionable last time around,
> > >> I'm not sure what this would solve.
> > >
> > > It's not just a rename.  By changing this into a QoS constraint, we
> > > make it more generally useful.  Instead of standing on its own, it
> > > becomes part of the PM-QOS framework.
> > >
> > 
> > We cannot use the existing pm-qos framework. It is not safe to call
> > from atomic context.
> 
> We've just merged a patch that fixed that if I'm not mistaken.  Mark, did your
> PM QoS update fix that?
>

I'm pretty sure it can be called in atomic context, and if its not I'm
sure we can fix that.  It can be called in atomic context.  I don't
think it was ever a problem to call it in atomic context.  The problem it
had was that crappy list of string compares.  Thats been fixed.
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Bottomley | 1 Jun 2010 01:47
Picon

Re: [PATCH 0/8] Suspend block api (version 8)

On Mon, 2010-05-31 at 23:41 +0200, Thomas Gleixner wrote:
> On Sat, 29 May 2010, James Bottomley wrote:
> > On Sat, 2010-05-29 at 10:10 +0200, Peter Zijlstra wrote:
> > > 
> > > Not using suspend is exactly the point. As Alan has argued, propagating
> > > suspend blockers up into all regions of userspace will take much longer
> > > than fixing the hardware.
> > 
> > Strange, that's not what I heard as the possible solution.  I thought he
> > was advocating expressing the kernel side of suspend blockers as QoS
> > constraints.  Once we have QoS constraints correctly done in the kernel,
> > userspace still has to express its requirements.  If the requirements
> > are static, then they can be done from policy files or in some other
> > static way but if they're dynamic, they'll still have to be in the
> > applications ... in about the same places the android wakelocks are.
> 
> That's wrong. You only need the explicit dynamic QoS constraints for
> applications which follow the scheme:
> 
>      while (1) {
>      	   if (event_available())
> 	      process_event();
> 	   else
> 	      do_useless_crap_which_consumes_power();
>      }	   
> 
> which need the following annotation:
> 
>      while (1) {
>      	   block_suspend();
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rafael J. Wysocki | 1 Jun 2010 02:32
Picon
Gravatar

Re: [PATCH 0/8] Suspend block api (version 8)

On Tuesday 01 June 2010, Neil Brown wrote:
> On Tue, 1 Jun 2010 00:05:19 +0200
> "Rafael J. Wysocki" <rjw <at> sisk.pl> wrote:
> 
> > On Monday 31 May 2010, Neil Brown wrote:
> > > On Thu, 27 May 2010 23:40:29 +0200 (CEST)
> > > Thomas Gleixner <tglx <at> linutronix.de> wrote:
> > > 
> > > > On Thu, 27 May 2010, Rafael J. Wysocki wrote:
> > > > 
> > > > > On Thursday 27 May 2010, Thomas Gleixner wrote:
> > > > > > On Thu, 27 May 2010, Alan Stern wrote:
> > > > > > 
> > > > > > > On Thu, 27 May 2010, Felipe Balbi wrote:
> > > > > > > 
> > > > > > > > On Thu, May 27, 2010 at 05:06:23PM +0200, ext Alan Stern wrote:
> > > > > > > > >If people don't mind, here is a greatly simplified summary of the
> > > > > > > > >comments and objections I have seen so far on this thread:
> > > > > > > > >
> > > > > > > > >	The in-kernel suspend blocker implementation is okay, even
> > > > > > > > >	beneficial.
> > > > > > > > 
> > > > > > > > I disagree here. I believe expressing that as QoS is much better. Let 
> > > > > > > > the kernel decide which power state is better as long as I can say I 
> > > > > > > > need 100us IRQ latency or 100ms wakeup latency.
> > > > > > > 
> > > > > > > Does this mean you believe "echo mem >/sys/power/state" is bad and
> > > > > > > should be removed?  Or "echo disk >/sys/power/state"?  They pay no
> > > > > > 
> > > > > > mem should be replaced by an idle suspend to ram mechanism
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marc Weber | 1 Jun 2010 02:37
Picon
Picon

Re: [Pm-utils] BIOS upgrade (was: cores offline after pm-suspend?)

Excerpts from Paul Menzel's message of Mon May 31 14:38:27 +0200 2010:
> You could try/use flashrom [1].

Summary: no success - I have to get a second drive.

which prints a big fat warning that its a risk to use it on laptops.
I've joined irc. My board / chip is not supported yet.

I've tried booting freedos. 
Illegal instrunction occured while running EC.bat which should be run
before flashing the bios according to the readme.

Installing Win7 from recovery dvds does work, but starting it does not.

Marc Weber
Permalink | Reply | 0 comments |
headers
Thomas Gleixner | 1 Jun 2010 02:54
Picon

Re: [PATCH 0/8] Suspend block api (version 8)

On Tue, 1 Jun 2010, Rafael J. Wysocki wrote:
> On Tuesday 01 June 2010, Neil Brown wrote:
> > My freerunner has a single core so without CONFIG_PREEMPT it may be that
> > there is no actual race-window - maybe the PRE_SUSPENDs will all run before a
> > soft_irq thread has a chance to finish handling of the interrupt (my
> > knowledge of these details is limits).  But on a muilti-core device I think
> > there would definitely be a race-window.
> 
> Yes, there always will be a race window.  The only thing we can do is to
> narrow it, but we cannot really close it (at least not on a PC, but I'm not
> really sure it can be closed at all).

It can be closed, when the state transition from normal event delivery
to wakeup mode is state safe, which it is on most platforms which are
designed for the mobile space.

Not so the current PC style x86 platforms, which are not relevant for
the problem at hand at all. Really, that stuff is going either to gain
sane properties or it's just going into the irrelevant realm.

Any attempt to solve the current x86/ACPI/BIOS/mess is waste of time
and is inevitably going to prevent progress.

> If you really want _all_ events to be delivered timely, the only way to go is
> to avoid using suspend (and use the idle framework for power management).

Amen.

	tglx
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neil Brown | 1 Jun 2010 03:33
Picon
Gravatar

Re: [PATCH 0/8] Suspend block api (version 8)

On Tue, 1 Jun 2010 02:32:20 +0200
"Rafael J. Wysocki" <rjw <at> sisk.pl> wrote:

> On Tuesday 01 June 2010, Neil Brown wrote:
> > I want to be able to turn my freerunner upside-down by which I tell it (via
> > the accelerometers) that I am done and want it to turn off.  If a TXT message
> > comes in just then, I don't want it to suspend, I want it to make an alert
> > noise.
> > I can put code in to ignore the accelerometer if a txt has just recently come
> > in, but if the TXT arrives just as the write to /sys/power/state starts, the
> > UART interrupt handler could have completed before it has the PRE_SUSPEND
> > method called.  So the suspend will complete and the wakeup from the UART
> > will have been "lost" in that the event didn't get all the way to its
> > destination: my ear.
> 
> As I said before, we generally can't prevent such things from happening,
> because even if we handle the particular race described above, it still is
> possible that the event will be "lost" if it arrives just a bit later (eg.
> during a suspend-toggle switch).  So the PRE_SUSPEND thing won't really
> solve the entire problem while increasing complexity.
> 
> > My freerunner has a single core so without CONFIG_PREEMPT it may be that
> > there is no actual race-window - maybe the PRE_SUSPENDs will all run before a
> > soft_irq thread has a chance to finish handling of the interrupt (my
> > knowledge of these details is limits).  But on a muilti-core device I think
> > there would definitely be a race-window.
> 
> Yes, there always will be a race window.  The only thing we can do is to
> narrow it, but we cannot really close it (at least not on a PC, but I'm not
> really sure it can be closed at all).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Gleixner | 1 Jun 2010 03:49
Picon

Re: [PATCH 0/8] Suspend block api (version 8)

On Tue, 1 Jun 2010, Neil Brown wrote:
> And if you are right that the race window cannot be closed, then the whole
> suspend-blocker infrastructure is pointless as the purpose of it is simply to
> close that window.  If it really does not and cannot work, then it would be
> best to reject it for that reason rather than for less concrete aesthetic
> arguments.
> But presumably it does work in practice on Android hardware so ..... confused.
> 
> Having just seen the email from Thomas, maybe you mean that it cannot be
> closed on devices using ACPI, but can on other devices.  I can sort-of
> imagine how that would be the case (I tried reading an ACPI spec once - my
> hat is of to those of you who understand it).
> That shouldn't prevent us from closing the race window on "sane" hardware
> that allows it.  This would, I think, be sufficient for Android's needs.
> 
> I'm hoping we can get agreement on:
>   - there is a race with suspend

That's a matter of how you define "suspend". 

If "suspend" is another deep idle state and the hardware is sane,
there is no race at all - assumed that the driver/platform developer
got it right. It's not rocket science to transition from "normal" irq
delivery to wakeup based delivery raceless (except for PC style x86
hardware of today)

If "suspend" is the thing we are used to via /sys/power/state then the
race will persist forever except for the suspend blocker workaround,
which we can express in QoS terms as well w/o adding another suspend
related user space API.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Stern | 1 Jun 2010 04:10
Picon
Favicon

Re: [PATCH 0/8] Suspend block api (version 8)

On Tue, 1 Jun 2010, Neil Brown wrote:

> > As I said before, we generally can't prevent such things from happening,
> > because even if we handle the particular race described above, it still is
> > possible that the event will be "lost" if it arrives just a bit later (eg.
> > during a suspend-toggle switch).  So the PRE_SUSPEND thing won't really
> > solve the entire problem while increasing complexity.
> > 
> > > My freerunner has a single core so without CONFIG_PREEMPT it may be that
> > > there is no actual race-window - maybe the PRE_SUSPENDs will all run before a
> > > soft_irq thread has a chance to finish handling of the interrupt (my
> > > knowledge of these details is limits).  But on a muilti-core device I think
> > > there would definitely be a race-window.
> > 
> > Yes, there always will be a race window.  The only thing we can do is to
> > narrow it, but we cannot really close it (at least not on a PC, but I'm not
> > really sure it can be closed at all).
> 
> Well you are the expert so I assume you are right, but I would really like to
> understand why this is.
> 
> I guess that if the event was delivered as an edge-triggered interrupt which
> the interrupt controller couldn't latch, then it might get lost.  Is that
> what happens?

You're barking up the wrong tree.  If I understand correctly, Rafael is
saying that there's a race involving events which are not _wakeup_
events.  If a non-wakeup event arrives shortly before a suspend, it can
have its normal effect.  If it arrives while a suspend is in progress,
its delivery may be delayed until the system resumes.  And if it
(Continue reading)

Permalink | Reply | 0 comments |

Gmane