Re: [spi-devel-general] Re: [PATCH] spi: Added spi master driver for Freescale MPC83xx SPI controller

[David Brownell <david-b@pacbell.net>]

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