review of XO power management patches for upstream

[Daniel Drake]

Hi,

I've finished working on the power management code, ready for review
before I sent it upstream if anyone is interested.

The patches are here:
http://dev.laptop.org/~dsd/20110114/

The architecture is a bit different from before:

olpc-xo1-pm (previously olpc-xo1) is a driver for the core power
management functions - suspend/resume and poweroff.

olpc-xo1-sci is a driver for OLPC's usage of the CS5536 SCI interrupt
and its linkage with the EC GPE/SCI, providing features such as ebook
switch, lid switch, power supply events, etc.

olpc-xo1-pm is a child device of the new cs5535-mfd driver, and
olpc-xo1-sci is a child of olpc-xo1-pm


The interfaces have changed from the earlier olpc-pm code. Instead of
having our own custom /proc node to control wakeups, I tried to
integrate into the Linux driver model more. For example, to enable
keyboard/mouse wakeups, you now have to request wakeups from the
actual i8042 device. There is no longer a device node to read the
state of the lid/ebook switches; instead we will use ioctls to query
the state through evdev.
This will require userspace tweaks in powerd and so on, work that I'll
take on afterwards (I imagine the upstreaming process will cause
further changes to be made).

Patch 1 defines the interface for communication to the cs5536. We are
uncertain about how this will end up, Andres in the process of
proposing a new generic system for communication between MFD drivers
and child devices (yes, 19 patches):
[RFC] [PATCH 0/19] mfd sharing support
http://marc.info/?a=116780825000006&r=1&w=2

However, whatever the result is, only small changes are needed on the
other patches to change interface.

While that is being decided, I can start submitting some of the
independent patches: 2, 5, 6, 12, 14, 16

I'm not going to submit patch 11 (XO-1 wakeup source info), and also I
don't have code for wakeup source detection on XO-1.5. After getting
the other patches off my back, I plan to revisit this area with the
possibility of not needing to know what the wakeup source is, on the
basis that the relevant wakeup event (e.g. mouse move) would arrive at
userspace anyway. I think this is the direction that Linux's new
wakeup events architecture is taking us:

"My understanding (which probably isn't exactly the same as Rafael's) is
that a "wakeup event" is any event which should either prevent the
system from going to sleep or should wake up the system if it is
already asleep.  After all, these are the same events (user typing,
network packet arriving, alarm firing) -- the only difference is what
state the system is in when they occur."
context: http://www.spinics.net/lists/linux-pm/msg22764.html

Comments welcome!
Daniel