[ohm] Some thoughts on OHM

[Richard Purdie]

Hi,

I was at the Open Hardware Manager discussion at FOSDEM and whilst I
didn't say much at the time I have some thoughts you might be interested
in. Sorry for the length of this!

The Zaurus as an example
========================

The Zaurus got a few mentions during the discussion at FOSDEM, probably
as its a device which has run into some of these difficulties before.

As background, I am the lead developer on the Sharp Zaurus 2.6
kernel project. This has been going on for some time and has seen me
slowly trying to get good support for the Zaurus devices in mainline
Linux. There have been lots of barriers to this, particularly in the
areas of power management and the lack of good standardised support for
things like backlights and LEDs.

I have some examples of Zaurus specific problems which are probably
typical of those found on embedded devices and usually lead to adhoc
solutions:

1. The screen can rotate so the device can be configured in a portrait
mode (no keyboard) or a landscape mode (keyboard beneath the screen).
There are switches that detect the position.

2. It has a headphone socket can:
   * detect when something is plugged in (but not what was plugged in)
   * support headphones
   * support a head set (speaker + mic)
   * support just a mic
  (there is also an internal speaker)

3. The devices touchscreen matrix is bigger than the actual LCD and
there are some "softkeys" marked. These act as buttons when pressed with
the stylus.

4. The backlight is by far the biggest power consumer on the device.
When battery voltage gets low, the power draw from maximum backlight
brightness can cause the core voltages to fall too low causing the
device to crash. We therefore have to limit the backlight intensity at
low battery.

To make the Zaurus a useful device, there are several things that need
to happen:

* When it boots, the ALSA mixer needs to be configured
* When headphones are inserted, the ALSA mixer needs to be reconfigured
for headphones
* When a headset is inserted, the ALSA mixer needs to be reconfigured
for a headset
* When the user has the device as landscape, no onscreen keyboard is
needed
* When the device is portrait, we need an onscreen keyboard available
* When the lid is closed, the backlight can be off (like a laptop)
* When the lid is closed, the device can suspend
* The device shouldn't suspect if you were playing music and the lid was
closed but the screen should still be blanked (e.g. even if video was
playing). Ideally, we shouldn't be decoding the video any more, just
audio.
* The touchscreen buttons should be connected to something, preferably
configurable.

I don't claim to have solved all of the above problems but I did address
some of them with zaurusd[1]. Zaurusd was an experiment to specifically
make the zaurus a useful device but also to see how much of that could
be done more generically.

[1] http://svn.o-hand.com/view/misc/trunk/zaurusd/

Of the above, it addressed a lot of the issues:

* tskeys is a generic program that supports softkeys on a touchscreen.
It injects events back into the kernel so no specific userspace changes
are needed to handle them, you just have to run the daemon with an
appropriate config file.

* ALSA mixer setup was dealt with. Scripts are there to support the
different modes (headset, heaphone, mic, speaker) and there is a
callback which could launch a UI to ask the user what was plugged in.
The actual UI part hasn't been written.

* The hinge switches are processed and adjust the device depending on
the position of the screen, enabling/disabling the onscreen keyboard as
appropriate. Closing the lid suspends the device which isn't ideal but
better than nothing.

Once, zaurusd was nearly called devmand (device manager daemon) since it
includes machine definitions so you could build it for a specific
machine or machines and when you did that, it only included what was
needed for those specific machines. I think this was an important
concept since people only want things on their device they're going to
use.

I'm to first to admit some bits of zaurusd are ugly and maybe hack like
and not all the generic infrastructure was fixed to work 100% correctly
but I think there are some important ideas there that could be
considered with OHM. Does OHM aim to include functionality similar to
what I've done with zaurusd?


Kernel Interfaces
=================

On the kernel side of things, to support backlights and LEDs in mainline
Linux I've written (or in the case of backlights heavily influenced) two
class subsystems. These aim is to standardise the way the kernel
presents these two classes of devices whilst not constraining what you
can do with these devices. I have tried to keep them simple rather than
rushing in and adding lots of features. Its much easier to add things
later rather than the opposite.

Hopefully classes like these have been or are going to be of great use
to HAL since they present things in a simple easy to understand
structure. I believe there are several key classes that are still
currently missing, particularly batteries. It would be good if someone
could look at implementing functionality in the kernel where appropriate
to reduce HAL and OHM complexity. I think work will be needed on the
kernel as well as OHM.

sharpsl_pm.c is a collection of fairly zaurus specific code which
implements power management on the Zaurus in the kernel. It does various
things I'll not get into (unless anyone is interested) but its this code
which implements the limit on the backlight (corgi_bl.c in mainline) to
get around one of the hardware limitations I mentioned above. Also,
sharpsl_pm talks to the world through the ARM APM emulation at the
moment which I'd love to see replaced. Two things are needed:

1. A way of better handling suspend/resume between userspace and kernel
space. APM has some nice ideas about userspace being asked before a
suspend and being able to veto it but in practise the interface is ugly
and broken on ARM. The question of how you trigger an APM userspace
suspend request remains open. I currently hack the zaurus kernels to
wire input KEY_POWER events into APM but having a generic userspace
solution (which works even without a GUI present) would be good.

2. Somewhere to put battery information, charging information and AC
status. These should not be part of the suspend/resume handling but
should be in their own class. A proper sysfs battery class would address
this.

The sharp_pm code also has translation tables to convert ADC readings
into battery percentage remaining type values needed for APM. This
shouldn't really be done in kernel space but in userspace. The tables
are often device specific. I'm wondering if OHM has a role in this
somewhere.


ASoC
====

ASoC (ALSA System on Chip) is a good example of where a good
kernel/userspace split of functionality was found. Its just been merged
into mainline in 2.6.21-rc1.

ASoC does several good things for sound support including separation of
the code into layers such as machine specifics, codecs, platform (PXA,
OMAP etc.) and platform transports (i2c, ssp, i2s etc.). Of interest
from OHM's point of view is its DAPM (dynamic power management). With
ASoC's DAPM userspace doesn't really have to care about the power usage
of the sound subsystem. The mixer controls automatically power on/off
the different power domains within the sound chip depending on whether
they're being used. Mixer configuration is therefore all the userspace
need worry about (hence you can see why zaurusd handles the ALSA mixer).
Userspace has all the capability is needs but doesn't actually have to
worry about hardware details itself.


HAL
===

I still don't 100% like HAL. If someone had originally told me that HAL
was a dbus interface to sysfs, I think I would have liked it a lot more.
If in the long run HAL becomes more like that (when compiled for use
with Linux 2.6 which is one of its main use cases), then I will be a lot
happier with having it around. At present, as a kernel developer, I
still generally feel its a layer too many and therefore too inefficient.


FOSDEM Slide Comment
====================

The last thing I should mention, at FOSDEM you showed a slide that
mentioned simple keys with "brightness_ac" as an example. My work on the
kernel classes shows there is nothing as simple as that. 

All you need is a device to come along and want a different brightness
depending on whether its day or night regardless of whether AC is
plugged in (think of a PDA in a car connected to the car to charge).
Don't underestimate what different users will want and try to keep
things generic where at all possible.


Sorry if this rambles a bit, hopefully you can get some useful info from
it!

Regards,

Richard