[PATCH] kill mutex in lis

Andy Green andy at openmoko.com
Fri Oct 10 21:15:06 CEST 2008

Hash: SHA1

Werner Almesberger wrote:
> Andy Green wrote:
>> Shouldn't we be asking if we can batch input events in kernel and dump
>> them at less than 2 x 100Hz to reduce load at userspace, rather than how
>> can we conform to whatever upstream has (SPI API that insists on
>> interrupts) and never think outside that box?
> Well, there are problems at both ends: the SPI API that isn't great
> at this kind of task and user space that's operating in quite an
> inefficient mode as well.

Blocking on a device node using file semantics is perfectly efficient.
We can help out userspace by batching the events so it wakes at 10Hz or
whatever if we are worried about that side of things.

> It seems that, whatever you do, the low end won't get particularly
> efficient. If you busy-wait for the SPI hardware, you lose time,
> if you bitbang everything on your own, you're even slower (hmm,
> how fast can that chip actually go with SPI ?), if you wait for an
> interrupt, you lose a lot of cycles for that as well.

I don't see bitbang on a 400MHz CPU has to be "slower" than decoupling
it into a work queue just because the existing API can't do better --
it's way faster.  The only problem with bitbang outside the API is that
it's unlikely to chime with the upstream way.

> By the way, is there anything to be gained by just disabling the
> second accelerometer ? Easier selection or such ?

I don't think it's realistic to throw half the hardware off a cliff as a
solution.  If the existing APIs won't do an efficient job we should roll
our own, and batch the input event stuff, just issuing the reports every
n interrupts.

Maybe someone can leverage this problem into an opportunity for SPI API
improvement (just so it has option to do bitbang in interrupt context
will do), but I don't have the leisure for it.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list