lkml.org 
[lkml]   [2006]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2006-07-28 02:29    [W:0.047 / U:32.340 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site