Re: Attempted summary of suspend-blockers LKML thread

From: Paul E. McKenney
Date: Fri Aug 06 2010 - 13:22:58 EST

On Fri, Aug 06, 2010 at 01:30:48PM +0100, Mark Brown wrote:
> On Thu, Aug 05, 2010 at 06:01:24PM -0700, david@xxxxxxx wrote:
> > On Thu, 5 Aug 2010, Brian Swetland wrote:
> >> Obviously not all clocks are stopped (the DSP and codec are powered
> >> and clocked, for example), but yeah we can clock gate and power gate
> >> the cpu and most other peripherals while audio is playing on a number
> >> of ARM SoC designs available today (and the past few years).
> > does this then mean that you have multiple variations of suspend?
> > for example, one where the audio stuff is left powered, and one where it
> > isn't?
> This was the core of the issue I was raising in the last thread about
> this (the one following the rename to suspend blockers). Essentially
> what happens in a mainline context is that some subsystems can with
> varying degress of optionality ignore some or all of the instruction to
> suspend and keep bits of the system alive during suspend.
> Those that stay alive will either have per subsystem handling or will be
> outside the direct control of the kernel entirely (the modem is a good
> example of the latter case in many systems - in terms of the software
> it's essentially a parallel computer that's sitting in the system rather
> than a perhiperal of the AP).

This underscores a basic difference between servers and these embedded
devices. When you suspend a server, it is doing nothing, because servers
rely very heavily on the CPUs. In contrast, many embedded devices can
perform useful work even when the CPUs are completely powered down.

Thanx, Paul
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at