On Feb 12, 2008 2:24 PM, Ned Forrester <[EMAIL PROTECTED]> wrote: > > I thought it was generally considered good practice...
Yes, it probably is good practice. Unfortunately the tasklet seemed to be causing performance issues which made the driver essentially unusable for my application. I'm working with a serial chip which requires large numbers of small SPI transfers (several register reads etc. via SPI on each interrupt). If each of these transfers takes a millisecond it becomes impossible to service even a single fairly slow serial connection. I have to service 8 relatively fast serial ports so I can't put up with 99% SPI unavailability. I'm using an earlier kernel (2.6.16) which I've back-ported the latest SPI code so it's possible that tasklets work better in more recent kernels. Anyone know if that might be true? > I assume that "removing the tasklet" means calling pump_transfers() > directly from the interrupt service routines, rather than having the > ISRs schedule a tasklet to make that call. Right? Not exactly. pump_transfers() is called from pump_messages() and a few other places, all of which run in a workqueue. So it's not called from interrupt context but from a workqueue. > I believe tasklets will never run later than the next timer > tick, which I believe is 1ms on most moder processors (but which can be > changed). Thus 1ms should be the maximum latency; I would expect better > than 1ms most of the time. I seem to be seeing 1ms consistently on a Compulab cm-x270 - or at least I did until I made this change. Cheers, Zik ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
