Re: Generic battery interface

["Shem Multinymous" <multinymous@gmail.com>]

On 7/27/06, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> This would also be useful for the OLPC project - it's unlikely that
> it'll use ACPI, but a more feature-rich interface than /proc/apm would
> be massively helpful. This is just a matter of speccing out what
> information is needed and what format it should be presented in, and
> then adding a new device class, right?

Can we really assume there's one driver providing all battery-related
attributes?

For example, on a ThinkPad you want the ACPI battery module loaded so
that handles hande battery-related ACPI events, but on ACPI can't
doesn't provide all available attributes. For example, ACPI reports
the equvialent of
  /sys/devices/platform/smapi/BAT0/power_avg (last minute average)
but not
  /sys/devices/platform/smapi/BAT0/power_now (instantaneous average)
or
  /sys/devices/platform/smapi/BAT0/cycle_count
or control functions like
  /sys/devices/platform/smapi/BAT0/force_discharge
(see http://thinkwiki.org/wiki/tp_smapi for detials).

In this particular case we could split the ACPI module into two, one
module for events and one module for the sysfs interface, and load
only the first one on ThinkPads. But that's only because tp_smapi
happens to reproduce all of ACPI's attributes; there are probably
other cases whether neither method dominates the other.

So, if we insist on a standard battery device class name, how do we
cope with multiple sources of information and control functions?

  Shem