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
