Messages in this thread | | | Date | Fri, 28 Jul 2006 03:27:00 +0300 | From | "Shem Multinymous" <> | Subject | Re: Generic battery interface |
| |
Hi,
On 7/28/06, Vojtech Pavlik <vojtech@suse.cz> 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 again...
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 accelerometer.
Shem - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |