[lkml]   [2006]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Generic battery interface

On 7/28/06, Vojtech Pavlik <> wrote:
> > Battery polling is already used extensively, and its overhead is
> > completely negligible.
> You're joking, right? On quite a number of laptops, it takes quite a
> while to read the battery, spent in BIOS through SMI, polling the I2C
> bus while talking to the battery. The less often this is done, the
> better.

Yes, I know -- tp_smapi does that too. And it's still negligible,
usually a few microseconds.

Heck, the hdaps driver polls that same I2C bus 50 times per seconds
and still doesn't tickle the load average.

> > I'm yet to see any deployed userspace code
> > trying to query battery status more than once per second.
> The applets that were doing it (yes, up to 100 times per second)
> corrected their ways pretty quickly, because some machines became
> unusable with the applet enabled.

Exactly -- and they've been working merrily ever since.
And if you don't want to trust applet developers, cache the latest
reads and refresh them only if X jiffies have passed.

> You could, trivially, mirror the behavior of current applets: Not report
> the changes to the battery status more often than each N seconds, except
> for critical events.

You're taking a polling-based hardware, exposing it as an event-based
interface, and then and kludging it so that it behaves like polling

So, in this scheme, how many lines of code does is the equivalent of
"cat /sys/devices/platform/smapi/BAT0/voltage"?

> > And you'll need to identify devices in a useful way, a problem that's
> > not yet solved even for input devices... You see where it's going.
> May you be more specific here? I'm not aware of any problems in this
> area. This may be my fault: What needs to be fixed there?

"Generic interface for accelerometers (AMS, HDAPS, ...)" on LKML, a
few weeks ago, about moving accelerator-based hard disk parking from
sysfs polling to the the input infrastructure. One unresolved issue
was how to find which input device happens to be the relevant

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-07-28 02:29    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean