[PATCH] kill mutex in lis

[Werner Almesberger]

Andy Green wrote:
> Uh oh whenever I see that formulation, I suspect I will be disagreeing
> with whatever comes next...

:-)

> Well thousands of folks paid for two, would probably be a bit grumpy if
> we "downgrade" them.

If the data produced by that accelerometer turns out to be useless,
they have every right to be grumpy about us putting that chip on the
device at all, but why throw even more good money after bad on making
the useless chip report it useless data more efficiently ?

There also the issue that we'll drop the second accelerometer in
future products anyway, so anyone whose application ends up using it
today will have a compatibility problem in the future.

Anyway, I guess what you're saying is that just ignoring the second
chip doesn't make things easier.

> Seems to me that deferring service to a workqueue in an ISR just because
> the API can't do it in the ISR might be a "bottleneck" (and add jitter
> under load).

A general remark about workqueues: while it's common practice to send
everything to the system's default workqueue, it's actually easy to
have your workqueue run in its own kernel thread. If you need low
latency, you can also raise that thread's scheduling priority.

These are techniques we may need for solving bottlenecks caused by
workqueues in other areas as well, so I thought I'd mention them.
I used them in a project to stream data from and to disk with very
low latency (that workqueue was only a small part of this, of
course):

http://abiss.sourceforge.net/doc/abiss-ols2005.ps

> Who exactly says that SPI subsystem is "meant to be" only used outside
> interrupts?  Only the current Linux implementation.

Sure, that's what I meant. Try the path of least resistence first :)

- Werner