Re: Performance of spi_mpc83xx.c sucks.

[David Brownell <david-b-yBeKhBN/0LDR7s880joybQ@public.gmane.org>]

On Tuesday 21 October 2008, Joakim Tjernlund wrote:
> 
> > Maybe it indeed makes more sense to use polling for high bitrates.
> 
> The cpu can't keep up at ~10MHz for me, but even at much small Hz
> the poll is significantly faster, the IRQ overhead seems huge or is it 
> something else?

I'd guess IRQ-per-word is a bad design policy ... If you assume 10 MHz
SPI clock, and (keeping math simple) a 10-bit word, then a polling loop
of 1 MHz -- 1 usec/loop -- is needed to keep up.

Regardless of latency, per-IRQ overheads (save context, call handler,
do its work, return, restore) are not always below 1 usec...


> The question is if the poll code I sent is good, even for longer transfers?
> Perhaps some sort of LOWLAT flag could be used for transfers that really need them?

So long as you do the polling with IRQs enabled, I'd keep it simple and
just always poll.  YMMV of course, but most devices seem to prefer more
like 10 MHz clocks than 1 MHz ones.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/