Hi,
I'm currently working on a small embedded system based on a MIPS
processor. So far Linux works fine on it and I'd like to implement
power management on this system. For now I realize that APM and ACPI
are implemented by the kernel.
I don't think that ACPI is really suited for what I need. So I took a
look to APM implemetation which seems to be only implemented on i386,
arm and mips architectures. All of these implementations seem to be
based on i386 one. Mips one seems to be a copy and paste of arm one
and both of them have removed all APM bios stuff orginally part of
i386 implementation. It doesn't seem that APM is something really
stable and finished. So now I do not know from where to start...
Is there some other effort in the power management for _embedded_
systems ? I'd like to help in this area and it would be helpful to
know of certain projects that are working in this direction.
thanks
Francis
On Thu, Aug 24, 2006 at 08:44:25AM +0000, moreau francis wrote:
> Mips one seems to be a copy and paste of arm one and both of them
> have removed all APM bios stuff orginally part of i386 implementation.
The BIOS stuff makes no sense on ARM - there isn't a BIOS to do anything
with.
> 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.
The power management really comes from the Linux drivers themselves,
which are written to peripherals off when they're not in use. The other
power saving comes from things like cpufreq - again, nothing to do with
the magical "APM" or "ACPI" terms.
On embedded platforms, you shouldn't think about power management in
terms of the non-embedded PM technologies.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Hi,
Russell King wrote:
> On Thu, Aug 24, 2006 at 08:44:25AM +0000, moreau francis wrote:
>> Mips one seems to be a copy and paste of arm one and both of them
>> have removed all APM bios stuff orginally part of i386 implementation.
>
> The BIOS stuff makes no sense on ARM - there isn't a BIOS to do anything
> with.
I haven't said that it has been widely/wrongly removed...
>
>> 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.
I understand that ARM implementation has been the first one but maybe now
why not making it the common power management for embedded system that
could be used by all arches which need it ?
BTW, why has apm_cpu_idle() logic been removed from ARM implementation ?
> The power management really comes from the Linux drivers themselves,
> which are written to peripherals off when they're not in use. The other
> power saving comes from things like cpufreq - again, nothing to do with
> the magical "APM" or "ACPI" terms.
BTW why is it still called "APM" on ARM ?
thanks
Francis
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:
> >> Mips one seems to be a copy and paste of arm one and both of them
> >> have removed all APM bios stuff orginally part of i386 implementation.
> >
> > The BIOS stuff makes no sense on ARM - there isn't a BIOS to do anything
> > with.
>
> I haven't said that it has been widely/wrongly removed...
ROTFL! No, you were stating that the APM bios stuff was removed, and
I gave the reason for it. Why are you now objecting to my explaination?
> >> 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.
> I understand that ARM implementation has been the first one but maybe now
> 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.
> 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.
> > The power management really comes from the Linux drivers themselves,
> > which are written to peripherals off when they're not in use. The other
> > power saving comes from things like cpufreq - again, nothing to do with
> > the magical "APM" or "ACPI" terms.
>
> BTW why is it still called "APM" on ARM ?
That's what the userland interface is called on x86. We could've called it
apm_userland_interface_emulation_and_not_a_power_management_infrastructure.c
but although that clearly states what it is, it would've been far too long
a name. 8)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Thu, 2006-08-24 at 09:37 +0000, moreau francis wrote:
> 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.
> I understand that ARM implementation has been the first one but maybe now
> why not making it the common power management for embedded system that
> could be used by all arches which need it ?
>
> BTW, why has apm_cpu_idle() logic been removed from ARM implementation ?
>
> > The power management really comes from the Linux drivers themselves,
> > which are written to peripherals off when they're not in use. The other
> > power saving comes from things like cpufreq - again, nothing to do with
> > the magical "APM" or "ACPI" terms.
>
> BTW why is it still called "APM" on ARM ?
It provides an apm_bios device which behaves the same way as a "real"
APM bios on x86. The same apmd used on x86 can be used on ARM.
Its main purpose is to be to run suspend/resume events past userspace
before acting on them (and allow suspend/resume events to be triggered
from userspace). It also allows exporting of battery status information
to userspace in a rather broken way.
It would be nice to move that to some arch independent generic
implementation of these things and to leave the APM emulation behind.
The battery information should be a sysfs class (see the backlight/led
classes as examples of sysfs classes). The suspend/resume event handling
would be something new as far as I know and ideally should support
suspending/resuming individual sections of device hardware as well as
the whole system. The linux-pm mailing list might have more of an idea
of whether these things are being worked on and their current status.
Regards,
Richard
On Thu, Aug 24, 2006 at 08:44:25AM +0000, moreau francis wrote:
> I'm currently working on a small embedded system based on a MIPS
> processor. So far Linux works fine on it and I'd like to implement
> power management on this system. For now I realize that APM and ACPI
> are implemented by the kernel.
>
> I don't think that ACPI is really suited for what I need. So I took a
> look to APM implemetation which seems to be only implemented on i386,
> arm and mips architectures. All of these implementations seem to be
> based on i386 one. Mips one seems to be a copy and paste of arm one
> and both of them have removed all APM bios stuff orginally part of
> i386 implementation. It doesn't seem that APM is something really
> stable and finished. So now I do not know from where to start...
All the APM emulation on ARM and MIPS is really meant to is providing the
same interface to applications. It doesn't interface to an APM BIOS
because there is none and that's really excellent news.
> Is there some other effort in the power management for _embedded_
> systems ? I'd like to help in this area and it would be helpful to
> know of certain projects that are working in this direction.
Ralf
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:
>>>> Mips one seems to be a copy and paste of arm one and both of them
>>>> have removed all APM bios stuff orginally part of i386 implementation.
>>> The BIOS stuff makes no sense on ARM - there isn't a BIOS to do anything
>>> with.
>> I haven't said that it has been widely/wrongly removed...
>
> ROTFL! No, you were stating that the APM bios stuff was removed, and
> I gave the reason for it. Why are you now objecting to my explaination?
>
Take it easy ! I'm not objecting your explanation. Your explanation, which
was not asked, sounded to me like I said something wrong/bad on this
amputation. I have prefered to make things clear, no more.
>>>> 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 ?
>> I understand that ARM implementation has been the first one but maybe now
So does it make sense to you to have
linux/driver/apm
|-- apm_userland_interface_emulation_and_not_a_power_management_infrastructure.c
|-- idle.c
|-- core.c
linux/arch/arm/kernel/
|- apm_specific_to_arm_which_is_needed_by_generic_driver.c
| ...
for example ?
>> 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 ?
>> 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 ?
>>> The power management really comes from the Linux drivers themselves,
>>> which are written to peripherals off when they're not in use. The other
>>> power saving comes from things like cpufreq - again, nothing to do with
>>> the magical "APM" or "ACPI" terms.
>> BTW why is it still called "APM" on ARM ?
>
> That's what the userland interface is called on x86. We could've called it
> apm_userland_interface_emulation_and_not_a_power_management_infrastructure.c
> but although that clearly states what it is, it would've been far too long
> a name. 8)
>
Sure, but something that can reflect that it's a userland interface emulation
implementation would have been usefull. APM, despite it's already used by APM
BIOS terminology, is rather a name for a complete subsystem.
Francis
Richard Purdie wrote:
> It provides an apm_bios device which behaves the same way as a "real"
> APM bios on x86. The same apmd used on x86 can be used on ARM.
>
> Its main purpose is to be to run suspend/resume events past userspace
> before acting on them (and allow suspend/resume events to be triggered
> from userspace). It also allows exporting of battery status information
> to userspace in a rather broken way.
>
> It would be nice to move that to some arch independent generic
> implementation of these things and to leave the APM emulation behind.
Yes. Hence the generic code would deal with battery info, suspend/resume
events to userspace, cpu idle logic. And arches specific code would deal
with hardware to get status on battery for example. On i386 that would
lead to call the BIOS, on others arches, they would use whatever available
on the platform to report the status.
> The battery information should be a sysfs class (see the backlight/led
> classes as examples of sysfs classes). The suspend/resume event handling
> would be something new as far as I know and ideally should support
> suspending/resuming individual sections of device hardware as well as
Well, maybe the first step is to unify this APM for all arches hence
everybody could better improve it.
> the whole system. The linux-pm mailing list might have more of an idea
> of whether these things are being worked on and their current status.
>
That's actually this status I was trying to get when posting my initial
email.
Francis
On Thu, Aug 24, 2006 at 11:12:05AM +0100, Richard Purdie wrote:
> It would be nice to move that to some arch independent generic
> implementation of these things and to leave the APM emulation behind.
> The battery information should be a sysfs class (see the backlight/led
> classes as examples of sysfs classes). The suspend/resume event handling
> would be something new as far as I know and ideally should support
> suspending/resuming individual sections of device hardware as well as
> the whole system.
Triggering suspend/resume is already generic in the form of the
/sys/power/state interface. There's been discussion of producing a
generic battery class lately. There's some trend towards tying suspend
requests into the input layer, but how appropriate that is may depend on
the hardware in question. I think most of the pieces are in place to
provide an interface that isn't tied to looking like APM, and there's
certainly one or two moderately compelling reasons to avoid the APM
emulation limitations.
--
Matthew Garrett | [email protected]
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
Matthew Garrett wrote:
> Triggering suspend/resume is already generic in the form of the
> /sys/power/state interface. There's been discussion of producing a
> generic battery class lately. There's some trend towards tying suspend
> requests into the input layer, but how appropriate that is may depend on
> the hardware in question. I think most of the pieces are in place to
> provide an interface that isn't tied to looking like APM, and there's
what about suspend/resume event handling ? Is there something already in
place ?
Francis
On Fri, Aug 25, 2006 at 01:18:43PM +0000, moreau francis wrote:
> Matthew Garrett wrote:
> > Triggering suspend/resume is already generic in the form of the
> > /sys/power/state interface. There's been discussion of producing a
> > generic battery class lately. There's some trend towards tying suspend
> > requests into the input layer, but how appropriate that is may depend on
> > the hardware in question. I think most of the pieces are in place to
> > provide an interface that isn't tied to looking like APM, and there's
>
> what about suspend/resume event handling ? Is there something already in
> place ?
You mean passing those events out to userspace? Not that I know of.
--
Matthew Garrett | [email protected]
Russell King wrote:
> 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.
>
I'm not sure to understand why a daemon is needed. Could you explain ?
>> 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.
>
thanks for that.
Francis
On Fri, Aug 25, 2006 at 01:39:25PM +0000, moreau francis wrote:
> Russell King wrote:
> > 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.
> >
>
> I'm not sure to understand why a daemon is needed. Could you explain ?
Consider how you would make a connection between an interrupt being
triggered and a suspend occuring, bearing in mind that you require
a process context to perform a suspend.
You essentially have three options:
1. a kernel thread, to which you pass an event or trigger condition.
2. a userland daemon which waits for the interrupt via some special
kernel interface and triggers a suspend via normal userspace
channels.
3. some hotplug-triggered userspace method.
Note that both 2 and 3 have the same limitation - since they use normal
userspace channels which have no concept of "emergency suspend", it's
quite possible for (eg) a busy X server to inappropriately delay such a
suspend.
Therefore, I chose (1) as being the most appropriate solution.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
Hi!
> > It would be nice to move that to some arch independent generic
> > implementation of these things and to leave the APM emulation behind.
> > The battery information should be a sysfs class (see the backlight/led
> > classes as examples of sysfs classes). The suspend/resume event handling
> > would be something new as far as I know and ideally should support
> > suspending/resuming individual sections of device hardware as well as
> > the whole system.
>
> Triggering suspend/resume is already generic in the form of the
> /sys/power/state interface. There's been discussion of producing a
> generic battery class lately. There's some trend towards tying suspend
> requests into the input layer, but how appropriate that is may
> > depend on
suspend requests into input layer.. No, I do not think Dmitry will
allow us to do that.
Yes, we definitely want some kind of "generic battery" layer.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html