Messages in this thread | | | Date | Sat, 29 Jul 2006 01:48:34 +0300 | From | "Shem Multinymous" <> | Subject | Re: Generic battery interface |
| |
On 7/28/06, Vojtech Pavlik <vojtech@suse.cz> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |