Re: Power Mangement Interfaces

["Jordan Crouse" <jordan.crouse@amd.com>]

On 31/03/07 11:57 -0700, David Brownell wrote:
> The other part is the platform code.  On embedded hardware that's usually
> just calling device_init_wakeup() before registering the platform devices,
> and supporting enable_irq_wake().  On x86 that gets messy; ACPI is there,
> and PCI initialization can't set device_init_wakeup() because of conflicts
> with how PPC initializes PCI.

enable_irq_wake() looks like it integrates very well with the AT91, since
it seems that there is a 1:1 mapping of interrupts to wakeup sources.  The
story is much more muddled for x86 - there is no direct mapping of interrupts
to wakeup sources, and the PIC has nothing to do with handling wake events.

On the Geode, we have 17 possible wake sources, all of which are ORed
together to form the SCI interrupt. Some of the events, like the RTC,
UART, and USB wakeup sources are associated with devices that have their
own interrupts, but there is no correlation between the RTC interrupt, 
for example, and enabling it as a wakeup source.  It seems overly complex
to try to map these to individual interrupts, and certainly seems wasteful
to get the PIC involved in something it just doesn't understand.

> As in "echo enabled > /sys/devices/.../power/wakeup" (to get the default),
> or "echo disabled > ..." to disable it.  For PCs, with ACPI, that involves
> two patches I just posted to the RTC list (and CC'd Len on), and replacing
> the ancient/legacy/ACPI-only /proc/acpi/alarm interface.

The link is here for the interested:

http://groups.google.com/group/rtc-linux/browse_thread/thread/ae7fe3436e01e7fa

This looks very good, and is pretty close to what I was proposing.  
Replace the acpi_*_event() calls with a generic pm_ infrastructure, and
add hooks to the pm_ops for each individual PM system to handle the wakeups
in whatever way they see fit, and we're there.  It would be slightly more
complex for AT91 and friends to match this (since they have the advantage
of a 1:1 mapping right now), but in the long run, I think everybody would
benefit.

The only other issue then, is how we could define and manage wakeup events
for events that aren't associated with specific devices, like power button
and lid events.  We'll need some way to control those somewhere in sysfs -
if not in /sys/power/wakeup like I had proposed, then somewhere under the
platform or system hierarchy .

Jordan
-- 
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.
<www.amd.com/embeddedprocessors>