Re: Generic battery interface

[Shem Multinymous]

On 7/28/06, Vojtech Pavlik <vojtech@xxxxxxx> 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).

Ack.


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

 Shem
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/