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-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
