Messages in this thread | | | From | David Brownell <> | Subject | Re: [spi-devel-general] Re: [PATCH] spi: Added spi master driver for Freescale MPC83xx SPI controller | Date | Fri, 7 Apr 2006 18:25:06 -0700 |
| |
On Friday 07 April 2006 10:04 am, Kumar Gala wrote:
> > Well, not the _only_ way. The polling-type txrx_word() calls are > > also full duplex. My point is more that it's bad/inefficient to > > incur both IRQ _and_ task switch overheads per word, when it would > > be a lot simpler to just have the IRQ handler do its normal job.
Not that you actually _need_ an IRQ handler to be correct, in any case.
> > (And that's even true if you've turned hard IRQ handlers into threads > > for PREEMPT_RT or whatever. In that case the "IRQ overhead" is a > > task switch, but you're still saving _additional_ task switches.) > > This makes more sense about what I'm doing that is wasteful. > However, I'm not sure exactly where I should plug into things.
Only using interfaces below the line in spi_bitbang that says it's the "SECOND PART".
> I think you are saying to continue using spi_bitbang_transfer & > spi_bitbang_work, but have spi_bitbang_work call my own bitbang- > >txrx_bufs().
Yes. Consider several different ways to implement that I/O loop:
- Interrupt plus two context switches per byte (what you have now), no per-buffer context switch
- Interrupt per byte, plus one context switch pair per buffer (what I've described)
- pure PIO per byte, no context switches (as if you polled the registers rather than using an IRQ)
Any of them could be correct, but one of them is a lot worse in terms of CPU overhead when you aim at tranfer rates of even just a few MBytes per second. (It's the one with lots of needless context switching.)
That pure PIO model will sometimes be very appropriate; if the SPI clock is fast enough, it can be less overhead than the IRQ driven one.
- Dave
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |