Hi! > >> 2. If we're gonna unify interface, how much can we unify the backend? > >> Some devices are based on polling, others interrupt. For polling, > >> is it better to delegate the whole polling to userland or is it > >> better to do some of it in kernel (tp_smapi seems to be doing > >> this)? > > > > The ThinkPad accelerometer needs to be polled at very regular > > intervals (max jitter on the order of 10ms), which sounds like a job > > for the kernel. > > Yes, I agree. > > > This is because in ThinkPads we actually have a 4-level pile: > > [hdapsd userspace] -> [hdaps kernel] -> [embedded controller] -> > > [accelerometer A2D] > > What the kernel polls is actually is the H8S embedded controller (EC) > > chip, which in turn does its own polling of the accelerometer A2D. > > Now, the EC has a tiny buffer and strange buffering semantics, and it > > has its own internal clock, so the software->EC polling should be very > > regular to minmize EC buffer overflows/underruns. > > So, I think the whole polling should be implemented inside the kernel > and the kernel should notify userland when new data is available, > which is about what the current joystick implementation does and can > be achieved using sysfs_notify_event(). I like joystick/input interface slightly better. In some cases, machines with accelerometers (openmoko) use them for input primarily. HP interface will be more specialized (but less useful); still userland daemon can handle the differences... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
