Re: Re : Re : [HELP] Power management for embedded system

[Russell King <rmk+lkml@arm.linux.org.uk>]

On Thu, Aug 24, 2006 at 10:57:43AM +0000, moreau francis wrote:
> Russell King wrote:
> > On Thu, Aug 24, 2006 at 09:37:39AM +0000, moreau francis wrote:
> >> Russell King wrote:
> >>> On Thu, Aug 24, 2006 at 08:44:25AM +0000, moreau francis wrote:
> >>>> It doesn't seem that APM is something really stable and finished.
> >>> It's complete.  It's purpose is to provide the interface to userland so
> >>> that programs know about suspend/resume events, and can initiate suspends.
> >>> Eg, the X server.
> >>>
> >> Is there something specific to ARM in this implementation ? I don't think
> >> so and it's surely the reason why MIPS did copy it with almost no changes.
> > 
> > MIPS copied it because presumably it was useful for them.
> 
> Actually my point is that it could be usefull for _all_ embedded systems,
> whatever the arches it comes from, couldn't it ?

Yes, I agree, it should be.

> >> why not making it the common power management for embedded system that
> >> could be used by all arches which need it ?
> > 
> > It could well become a common interface.  But it is NOT power management
> > infrastructure.  It is merely a _userland_ interface.  Nothing more.  It
> > does not do anything other than that.
> 
> apm_queue_event() (and kapmd) doens't seem something usefull for user space.
> It seems to be designed to be used by the kernel no ?

We have some folk who want a method to trigger emergency suspends when
batteries got low, or if you move the battery cover, etc.  These are
events which require fast reactions from the system, and coding up some
additional interface to pass such events to userland, have some daemon
running to monitor for those events, and issue a PM event is completely
overkill and, actually, unreliable.

> >> BTW, why has apm_cpu_idle() logic been removed from ARM implementation ?
> > 
> > This APM is just a userland interface.  It has nothing to do with actual
> > power management.  CPU idling is handled entirely differently on ARM.
> 
> Could you point out where it is handled ?

It's both machine class and CPU specific.  I couldn't point you at
anything specific, except to say that different machines and ARM CPUs
handle it differently.

Some CPUs have "wait for interrupt" instructions, some don't.  Some
need special cache handling around this instruction, some don't.  Some
machines have a CPU capable of "wait for interrupt" but must not use it.

It's all handled by the CPU abstraction, and the machine class abstraction.

See arch_idle in include/asm-arm/arch-*/system.h as the starting point
for the "default" (== always used) idle implementations.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core