From: Richard Purdie <rpurdie@rpsys.net>
To: moreau francis <francis_moreau2000@yahoo.fr>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
linux-pm@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: Re : [HELP] Power management for embedded system
Date: Thu, 24 Aug 2006 11:12:05 +0100 [thread overview]
Message-ID: <1156414325.5555.11.camel@localhost.localdomain> (raw)
In-Reply-To: <20060824093739.5085.qmail@web25802.mail.ukl.yahoo.com>
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
next prev parent reply other threads:[~2006-08-24 10:12 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-24 8:44 [HELP] Power management for embedded system moreau francis
2006-08-24 9:04 ` Russell King
2006-08-24 9:37 ` Re : " moreau francis
2006-08-24 10:11 ` Russell King
2006-08-24 10:57 ` Re : " moreau francis
2006-08-24 21:56 ` Russell King
2006-08-25 13:39 ` Re : " moreau francis
2006-08-25 13:46 ` Russell King
2006-08-24 10:12 ` Richard Purdie [this message]
2006-08-24 14:42 ` moreau francis
2006-08-24 16:20 ` Matthew Garrett
2006-08-25 13:18 ` Re : " moreau francis
2006-08-25 13:29 ` Matthew Garrett
2006-09-04 21:56 ` Pavel Machek
2006-08-24 10:28 ` Ralf Baechle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1156414325.5555.11.camel@localhost.localdomain \
--to=rpurdie@rpsys.net \
--cc=francis_moreau2000@yahoo.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@lists.osdl.org \
--cc=rmk+lkml@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox