[lkml]   [2006]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Generic battery interface
    On 7/28/06, Vojtech Pavlik <> wrote:

    > Not that much. The difference then remains only on a tickless system.

    And even then, only when apps use excessive poll rates (way above
    1Hz), in which case the apps are broken; and broken apps can eat power
    in ways much worse than msleep(10) on a tickless system.

    > No I2C. LPC is so much faster than I2C (8 MHz 8-bit vs 100 kHz serial).


    > > >NOTE: I'm arguing event-based vs poll-based here. This is orthogonal to
    > > >the /dev vs /sys - both can supply or not supply events.
    > >
    > > > fd = open("/dev/bat0", O_RDONLY);
    > > > ioctl(fd, BATCGVOLTAGE, &voltage);
    > >
    > > So you *are* proposing polling fo rthe /dev interface too? I thought
    > > the main argument for the /dev
    > I'm not proposing polling. I'm proposing that there be a way how to read
    > the immediate values, in addition to the event notifications.
    > Yes, this means polling would be possible.

    So your /dev proposal is equivalent, functionality-wise, to sysfs +
    attribute change uevent, right? The only question is if we do it
    through /dev+ioctls or /sysfs+fscanf.

    > > And then we have to maintain both a kernel side and a userspace side.
    > > And what do I, poor author of tp_smapi, do if I want to add a
    > > non-standard attribute? Tell people to patch and overwrite their
    > > disto's batstate binary too?
    > How often do you plan to do that?

    With tp_smapi, I did it about 10 times over half a year. And there's
    probably more to come.

    > Anyway, the answer is yes, it's not a big deal to do.

    Practically, it's much messier. As a developer/tester you have two
    components to juggle instead of one, and it's a mess when they get out
    of sync.

    > As Dmitry pointed out, all the info (except for the events) is in sysfs,
    > too.

    And as I pointed out in reply, matching up devices in /sys and /dev is
    extremely cumbersome (and prone to race conditions).

    > > Meanwhile, here's another issue with the accelerometer input device
    > > (and by analogy, with batteries): client-specific event rate and fuzz.
    > > Neverball only needs "a big change has happened" events, maybe 10-20
    > > times per second. The disk parking daemon needs a perfectly accurate
    > > readouts at 50Hz or better, plus it needs to know whenever a sample is
    > > taken (even if it didn't change since the previous sample). How can
    > > this be handled without multiple input devices?
    > You need at least 50 Hz for reasonable game control, too. I remember
    > that analog joysticks sampled at 10 Hz were unusable.

    If you rattle your ThinkPad this badly, latency in Neverball is going
    to be the least of your problems. :-)

    The mainline hdaps driver does 20Hz, BTW.

    > The input layer was designed for input devices that control applications
    > by actions of the user. The fuzz filtering was designed with that in
    > mind and is expected to be set once at boot either by an educated guess
    > of a kernel driver or by the system administrator. Because it's designed
    > for input devices, it has these properties:
    > * It ignores minor noise
    > * It slowly reacts to continuous drift of the values
    > * It reacts immediately to large changes
    > This would be likely completely unsuitable for batteries and may be bad
    > for a drive parking daemon, too. If the daemon can't use it, it'll need
    > another interface.

    There's a pattern here. Maybe what we need is a generic scheme for
    publishing continuous readouts, that will work for both hdaps and
    batteries (despite a X100 difference in typical time magnitudes).
    Doubtless there are other uses for such a scheme. We want it to
    support clients with different desired rates, data sources with
    different update frequencies, use minimum CPU and avoid unnecesary
    timer interrupts on tickless kernels.

    Here's one approach: use a syscall (e.g., ioctl) saying "block until
    there's new data on this fd, or N milliseconds have passed, whichever
    is *later*". This way each client declares the update rate it wants
    and can change it on the fly. The driver sees all the requests and can
    perform the minimum hardware quering -- for example, it won't query
    the hardware at all if no client has submitted a request with
    parameter N more than N milliseconds go. And there's no excessive work
    or interrupts. Some (simple) kernel code infrastructure is needed to
    help drivers manage the pending requests.

    Extending this approach, we can have a call for "block until the
    readout has changed by M, or N milliseconds have passed, whichever is
    later". This may not reduce query rate for polling-based hardware, but
    will reduce the event rate.

    I suppose these calls should also have a (normal) timeout, for the
    usual reasons.

    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-29 00:51    [W:0.026 / U:127.208 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site