[PATCH] kill mutex in lis

[Werner Almesberger]

Simon Kagstrom wrote:
> I did some measurements after I posted my patch to do this (not
> realising that this is how it was done earlier). And there was
> significant difference from just reading the accelerometers. Workqueue
> numbers first:

Okay, that looks a bit nasty on the kernel side. (And even worse
for user space.) Thanks for the data !

BTW, "top" results can sometimes be misleading, because they may
mis-represent work in interrupts, time spent in context switches,
or even cache delays. It's often better to measure how much work
a low-priority process can get done while the test load is being
generated.

I think have such a tool somewhere ... I'll do some digging. I'll
need this myself for WLAN soonish anyway.

> However, I think the spi_async() method should do quite a bit better
> than this. Instead of basically doing 5 queue_work()s per interrupt
> (the interrupt itself, plus reading of status,x,y,z), it would do just
> one.

One technique MMC-SPI uses may be useful here: instead of doing N
individual operations, string them together in a single transaction
and pick the results from the byte stream returned.

E.g., if you have an interface where you send an address byte and
then the content of that address is returned in the next transfer,
you'd send one buffer with

<addr1> 0xff <addr2> 0xff ...

and receive a buffer with

??? <data1> ??? <data2>

You can also use speculative execution: if you already know that
almost all the transfers will need the current X/Y/Z force, you
just always retrieve them and don't worry about the rare cases
where you'll throw them away.

- Werner