Hi!

quoted text
> >> 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
--
unsubscribe notice
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/