Re: Performance of spi_mpc83xx.c sucks.

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

On Tuesday 02 December 2008, Joakim Tjernlund wrote:
> 
> > If you're only guessing about what's going on, you need to go
> > back and get solid data.  What does "as expected" mean?  Some
> > app developers have silly expectations.  If you were "playing"
> > the issue could more easily have been goofs in your code.
> 
> yeah, I know I need to investigate this further. I just want
> to put the "starving" issue out of my mind.

You won't be able to do that without solid data.  You're
still just speculating.


> I feel a bit 
> uneasy about the busy wait nature of polling for potentially long
> periods of time and that might slow down the rest of the system.

Yet $SUBJECT is about suckage with IRQ-driven transfers, slowing
down the system.  There is a common thread ...

A first-principles analysis would help.  What SPI clock rate is
involved, and how big are the data transfers?  It should be easy
to come up with a per-word instruction count ceiling for polling,
and compare that to the IRQ overhead.

Then remember that unless you've got DMA, you're stuck with some
CPU costs here.  So the question is only how/when you incur them:
in bursts giving adequate SPI throughput, or spread out over time
giving objectionably low throughput?


-------------------------------------------------------------------------
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=/