[PATCH] kill mutex in lis

[Werner Almesberger]

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.

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.

Even DMA may not help all that much either, since you only transfer
six bytes each time, and S3C SPI has quite some overhead for DMA
operation. (The value of DMA depends on the maximum SCLK. If we
have to go really slow, DMA would help.)

That's just the hardware side, without considering what the stack
does or how it does what it does.

Towards userspace, we already have some limited batching if the
arrival rate of new samples exceeds the retrieval rate. This is
limited by the depth of the event buffer (64 entries). I don't
know how much the different accelerometer applications differ in
their timing needs. I suppose gesture recognition wouldn't mind
trading latency for efficiency, while deep buffering would lead
to early deaths in Duke Nukem.

I could imagine that a way to set the minimum latency of event
delivery could also be interesting in general.

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

- Werner