Generic battery interface

Generic battery interface

[Pavel Machek]

Hi!

(Vojtech and other thinkpad users: look at tp_smapi package; it
includes stuff like "do not charge battery unless it is below 90%",
which should make your battery last few more years).

(I'll still need to test it on x60, sorry).

Anyway, unlike acpi, tp_smapi uses some reasonably-nice
one-value-per-file sysfs interface. I have few objections:

0) it needs to move to /sys/class/battery/tp_smapi or something like
that
 
1) it probably should not include units in the files (hard to parse,
and someone may have great idea to choose different units)

2) some optional method for battery applets to avoid polling would be
nice (OTOH tp_smapi probably does not support notifications, so it is
not its fault)

3) some fields look almost too specialized, but if hardware supports
them, I guess we should export them, too...

...but otherwise it looks very good, certainly better than
alternatives. Perhaps we should make something like this "generic"
battery interface?

Good description is at
http://thinkwiki.org/wiki/Tp_smapi#Installation_from_source , and to
give you a quick example:

# cat /sys/devices/platform/smapi/BAT0/installed
# cat /sys/devices/platform/smapi/BAT0/state       # idle/charging/discharging
# cat /sys/devices/platform/smapi/BAT0/cycle_count 
# cat /sys/devices/platform/smapi/BAT0/current_now # instantaneous  current
# cat /sys/devices/platform/smapi/BAT0/current_avg # last minute average
# cat /sys/devices/platform/smapi/BAT0/power_now   # instantaneous  power
# cat /sys/devices/platform/smapi/BAT0/power_avg   # last minute  average
# cat /sys/devices/platform/smapi/BAT0/last_full_capacity
# cat /sys/devices/platform/smapi/BAT0/remaining_capacity
# cat /sys/devices/platform/smapi/BAT0/design_capacity
# cat /sys/devices/platform/smapi/BAT0/voltage
# cat /sys/devices/platform/smapi/BAT0/design_voltage
# cat /sys/devices/platform/smapi/BAT0/manufacturer
# cat /sys/devices/platform/smapi/BAT0/model
# cat /sys/devices/platform/smapi/BAT0/barcoding
# cat /sys/devices/platform/smapi/BAT0/chemistry
# cat /sys/devices/platform/smapi/BAT0/serial
# cat /sys/devices/platform/smapi/BAT0/manufacture_date
# cat /sys/devices/platform/smapi/BAT0/first_use_date
# cat /sys/devices/platform/smapi/ac_connected

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Generic battery interface

[Matthew Garrett]

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?

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Generic battery interface

[Shem Multinymous]

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

Re: Generic battery interface

[Matthew Garrett]

On Thu, Jul 27, 2006 at 05:39:06PM +0300, Shem Multinymous wrote:

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

Hmm. That's a good point.

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

Ignoring the multiple sources of information bit for the moment, we need 
to figure out the correct method of event notification anyway. There's a 
long-term plan to get rid of /proc/acpi, so acpi notifications need to 
be more more generic in any case.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Generic battery interface

[Pavel Machek]

Hi!

> >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?

Anything else would be crazy, I'd say.

> 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).

Well, in that case probably smapi driver should "hook into" acpi
driver.

> 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.

I hope such hardware will not be too common. Thinkpad is covered by
accident, and I do not know about any other problematic machine.

Worst case, we would get equivalent of

/sys/class/battery/system_battery_acpi/...
/sys/class/battery/system_battery_some_clever_vendor_hack/...

with some values common between both of them. I'd say it is still
better than having vendor_hack in /sys in one format while having acpi
battery in /proc/acpi in completely different format.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Generic battery interface

[Shem Multinymous]

On 7/27/06, Pavel Machek <pavel@suse.cz> wrote:
> Well, in that case probably smapi driver should "hook into" acpi
> driver.

That would be odd, the SMAPI driver has nothing to do with the ACPI
system. I don't think cross-system hooks are very popular...


> Worst case, we would get equivalent of
>
> /sys/class/battery/system_battery_acpi/...
> /sys/class/battery/system_battery_some_clever_vendor_hack/...
>
> with some values common between both of them. I'd say it is still
> better than having vendor_hack in /sys in one format while having acpi
> battery in /proc/acpi in completely different format.

Aye, we need for a consistent interface to common functionality.
How about /sys/class/battery/{acpi,apm,thinkpad}/BAT0?
So that for standard attributes, cat /sys/class/battery/*/BAT0/voltage
gives something reasonable.

  Shem

Re: [ltp] Re: Generic battery interface

[Henrique de Moraes Holschuh]

On Thu, 27 Jul 2006, Shem Multinymous wrote:
> 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?

No, we cannot.  This is not true on ThinkPads, for example.  We *can* make
it true, but AFAIK that means overriding the entire generic ACPI battery
driver, and greating a "glue" thinkpad_battery one that does:

	1. generic ACPI battery access when ACPI is available
	2. thinkpad specific ACPI battery access when ACPI is available
	3. thinkpad specific EC firmware battery access (not ACPI).

That requires the new driver to use functions from ibm_acpi and tp_smapi,
plus the stuff in the generic acpi battery access driver.

It might be the best way to go for ThinkPads, actually.  Some rework on
ibm_acpi ain't that bad, and tp_smapi is already undergoing major surgery.

> 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.

Yes.

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

Good question.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Generic battery interface

[Greg KH]

On Thu, Jul 27, 2006 at 03:44:52PM +0100, Matthew Garrett wrote:
> On Thu, Jul 27, 2006 at 05:39:06PM +0300, Shem Multinymous wrote:
> 
> > Can we really assume there's one driver providing all battery-related
> > attributes?
> 
> Hmm. That's a good point.
> 
> > So, if we insist on a standard battery device class name, how do we
> > cope with multiple sources of information and control functions?
> 
> Ignoring the multiple sources of information bit for the moment, we need 
> to figure out the correct method of event notification anyway. There's a 
> long-term plan to get rid of /proc/acpi, so acpi notifications need to 
> be more more generic in any case.

You can poll sysfs files to be notified when states change...

thanks,

greg k-h

Re: [ltp] Re: Generic battery interface

[Shem Multinymous]

Hi Micael,

I ask again: please do a Reply to All. This discussion is CCed on
several mailing lists, not just link-thinkpad.

On 8/1/06, Michael Olbrich <michael.olbrich@gmx.net> wrote:
> On Tue, Aug 01, 2006 at 01:45:27AM +0300, Shem Multinymous wrote:
> >>And keeping the latest readout for each app isn't that heavy. After all
> >>we already have to keep track of the timeouts for each app.
> >
> >The timeouts bookkeeping will normally be done by some infrastructure,
> >and can often be (in principle) be optimized to less than on value per
> >app. Also, it's just one timestamp. By contrast, what you're asking
> >for requires explicit handling by every driver, and the attribute
> >value may take significant amount of storage -- per app.
>
> If you are that concerned about storage why the complex timeout model?
> That can easily handled in userspace with just the blocking and
> nonblocking reads.

Please explain how this can be done  in a way that (a) works
transparently with both event-driven and query-based drivers, (b)
handles multiple clients efficiently, (c) minimizes hardware queries
in the case of query-based drivers, and (d) doesn't cause unnecessary
timer interrupts on tickless kernels.


> > The app can do this itself by polling and checking the value, with a
> > (not too) small value of dupeq.min_wait. In the case of a
> > polling-based data source, the resulting hardware queries and timer
> > interrupts are exactly the same as an in-kernel implementation which
> > does the polling and comparions itself. If the data source is
> > event-based then the comparison in userspace does have a drawback: the
> > comparions are done just dupeq.min_wait apart even if the event rate
> > happens to be higher. Can you think of a case where this matters?
>
> The problem I see is the overhead. Visual feedback that feels
> instantaneous would require dupeq.min_wait<50ms. And as far as I can
> tell each read requires to switch from userspace to kernelspace and
> back. When I look at the available variables I can easily imagine
> applications that would read >10 variables. That's not something I would
> want to do that often.

This is relevant only to query-based drivers, not event-based. How
expensive is a context switch compared to a typical hwmon hardware
query?

  Shem

Re: [ltp] Re: Generic battery interface

[Shem Multinymous]

Hi Michael,

Please do a Reply to All. I've restored the mailing list CCs.

On 7/31/06, Michael Olbrich <michael.olbrich@gmx.net> wrote:
> On Mon, Jul 31, 2006 at 06:18:12PM +0300, Shem Multinymous wrote:
> > On 7/31/06, Michael Olbrich <michael.olbrich@gmx.net> wrote:
> > >Hmmm, that looks good for most cases. But how would you handle
> > >starting/stoping laoding/draining the battery?
> > >That usually results in values jumping from/to 0. A gui would want to
> > >show such a change immediately while otherwise keeping a slow update
> > >rate. Maybe some kind of threshhold parameter? "send an input-ready
> > >immediatelly if the value changes by more than x%".
> >
> > Changes by more than x% compared to what?
> >
> > The value at the time of the ioctl()? This might completely miss a
> > change that happened between the previous read() and the ioctl().
> >
> > The value at the time of the last read()? Then the kernel
> > driver+infrastructure will need to keep track of the latest readout
> > done by each app. That's pretty heavy.
> >
> > So what semantics make sense?
>
> Well, the kernel is polling the hardware and caches the last value for
> O_NONBLOCKing anyway. So we already have two values to compare.

It's caching *one* value, not one value per polling app  (i.e., opened file).
Also, if querying the hardware is very cheap, the driver is at freedom
to do that instead of caching.


> And keeping the latest readout for each app isn't that heavy. After all
> we already have to keep track of the timeouts for each app.

The timeouts bookkeeping will normally be done by some infrastructure,
and can often be (in principle) be optimized to less than on value per
app. Also, it's just one timestamp. By contrast, what you're asking
for requires explicit handling by every driver, and the attribute
value may take significant amount of storage -- per app.


> Another way to handle this:
> A lot of applications are interrested in changes. It would be perfectly
> reasonable for a poll() to block for over 1 minute while the value
> fluctuates with changes less than e.g. 1%. As soon as the change
> (compared to the last readout) exceds this threshhold poll() returns
> immediatelly. This could of course be combined with the proposed
> timeouts.

The app can do this itself by polling and checking the value, with a
(not too) small value of dupeq.min_wait. In the case of a
polling-based data source, the resulting hardware queries and timer
interrupts are exactly the same as an in-kernel implementation which
does the polling and comparions itself. If the data source is
event-based then the comparison in userspace does have a drawback: the
comparions are done just dupeq.min_wait apart even if the event rate
happens to be higher. Can you think of a case where this matters?

  Shem

Re: [ltp] Re: Generic battery interface

[Shem Multinymous]

On 7/31/06, Michael Olbrich <michael.olbrich@gmx.net> wrote:
> On Sun, Jul 30, 2006 at 09:37:23PM +0300, Shem Multinymous wrote:
> >
> > Comments?
>
> Hmmm, that looks good for most cases. But how would you handle
> starting/stoping laoding/draining the battery?
> That usually results in values jumping from/to 0. A gui would want to
> show such a change immediately while otherwise keeping a slow update
> rate. Maybe some kind of threshhold parameter? "send an input-ready
> immediatelly if the value changes by more than x%".

Changes by more than x% compared to what?

The value at the time of the ioctl()? This might completely miss a
change that happened between the previous read() and the ioctl().

The value at the time of the last read()? Then the kernel
driver+infrastructure will need to keep track of the latest readout
done by each app. That's pretty heavy.

So what semantics make sense?

  Shem