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

On Tue, 2010-06-01 at 21:41 -0700, Arve Hjønnevåg wrote:

2010/6/1 James Bottomley [off-list ref]:

quoted

On Tue, 2010-06-01 at 18:10 -0700, Arve Hjønnevåg wrote:

quoted

On Tue, Jun 1, 2010 at 3:36 PM, James Bottomley [off-list ref] wrote:

quoted

On Wed, 2010-06-02 at 00:24 +0200, Rafael J. Wysocki wrote:

quoted

On Tuesday 01 June 2010, James Bottomley wrote:

quoted

On Tue, 2010-06-01 at 14:51 +0100, Matthew Garrett wrote:

quoted

On Mon, May 31, 2010 at 04:21:09PM -0500, James Bottomley wrote:

quoted

You're the one mentioning x86, not me.  I already explained that some
MSM hardware (the G1 for example) has lower power consumption in S3
(which I'm using as an ACPI shorthand for suspend to ram) than any
suspend from idle C state.  The fact that current x86 hardware has the
same problem may be true, but it's not entirely relevant.

As long as you can set a wakeup timer, an S state is just a C state with
side effects. The significant one is that entering an S state stops the
process scheduler and any in-kernel timers. I don't think Google care at
all about whether suspend is entered through an explicit transition or
something hooked into cpuidle - the relevant issue is that they want to
be able to express a set of constraints that lets them control whether
or not the scheduler keeps on scheduling, and which doesn't let them
lose wakeup events in the process.

Exactly, so my understanding of where we currently are is:

Thanks for the recap.

quoted

     1. pm_qos will be updated to be able to express the android suspend
        blockers as interactivity constraints (exact name TBD, but
        probably /dev/cpu_interactivity)

I think that's not been decided yet precisely enough.  I saw a few ideas
here and there in the thread, but which of them are we going to follow?

Well, android only needs two states (block and don't block), so that
gets translated as 2 s32 values (say 0 and INT_MAX).  I've seen defines
like QOS_INTERACTIVE and QOS_NONE (or QOS_DRECKLY or QOS_MANANA) to
describe these, but if all we're arguing over is the define name, that's
progress.

I think we need separate state constraints for suspend and idle low
power modes. On the msm platform only a subset of the interrupts can
wake up from the low power mode, so we block the use if the low power
mode from idle while other interrupts are enabled. We do not block
suspend however if those interrupts are not marked as wakeup
interrupts. Most constraints that prevent suspend are not hardware
specific and should not prevent entering low power modes from idle. In
other words we may need to prevent low power idle modes while allowing
suspend, and we may need to prevent suspend while allowing low power
idle modes.

Well, as I said, pm_qos is s32 ... it's easy to make the constraint
ternary instead of binary.

No, they have to be two separate constraints, otherwise a constraint
to block suspend would override a constraint to block a low power idle
mode or the other way around.

Depends.  If you block the system from going into low power idle, does
that mean you still want it to be fully suspended?

If yes, then we do have independent constraints.  If not, they have a
hierarchy:

      * Fully Interactive (no low power idle or suspend)
      * Partially Interactive (may go into low power idle but not
        suspend)
      * None (may go into low power idle or suspend)

Which is expressable as a ternary constraint.

James


_______________________________________________
linux-pm mailing list
linux-pm@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/linux-pm