Re: Attempted summary of suspend-blockers LKML thread

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Fri, Aug 06, 2010 at 04:35:59PM -0700, david@lang.hm wrote:
> On Fri, 6 Aug 2010, Paul E. McKenney wrote:

Guys, please try to cut unneeded text from the quotes - it makes it much
easier to find the new text.

>>> Well, not really from the Linux point of view.  It's not massively
>>> different to something like keeping an ethernet controller sufficiently
>>> alive to allow it to provide wake on LAN functionality while the system

>> The wake-on-LAN and the lights-out management systems are indeed
>> interesting examples, and actually pretty good ones.  The reason I
>> excluded them is that they don't do any application processing -- their
>> only purpose is the care and feeding of the system itself.  In contrast,
>> the embedded processors are able to do significant applications processing
>> (e.g., play back music) while any CPUs are completely shut down and most
>> of the memory is powered down as well.

This isn't a particularly meaningful distinction, things like the LoM
systems on servers are generally at least as capable as things like the
DSPs doing tasks like offloaded MP3 decode and often provide useful
services in themselves (like system monitoring).  It's really just
semantics to treat them differently to something like a cellular modem -
at a high level they're both just independant processors ticking away
without the application processor.

> one other significant issue is that on the PC, things like wake-on-LAN,  
> lights out management cards, etc require nothing from the main system  
> other than power. If they do something, they are sending the signal to 
> the chipset, which then wakes the system up. they don't interact with the 
> main processor/memory/etc at all.

I don't see that it makes much difference what gets kept alive - at the
end of the day the point is that we're making a decision to keep bits of
the system alive over suspend.

> So as I see it, we need to do one of two things.

> 1. change the suspend definition to allow for some things to not be  
> suspended

This is essentially what's already happening.

> 2. change the sleep/low-power mode definition to have a more standardized 
> way of turning things off, and extend it to allow clocks to be turned off 
> as well (today we have things able to be turned off, drive spin-down for  
> example, but per comments in this thread it's all one-off methods)

Currently things like clock trees are frequently managed orthogonaly to
the system power state to at least some extent anyway - for example,
perfectly normal wake events like button presses will often require
clocks for things like debouncing.