Re: Performance of spi_mpc83xx.c sucks.

["Joakim Tjernlund" <Joakim.Tjernlund-SNLAxHN9vbcOP4wsBPIw7w@public.gmane.org>]

> -----Original Message-----
> From: Peter Korsgaard [mailto:jacmet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org] On Behalf Of Peter Korsgaard
> Sent: den 21 oktober 2008 20:14
> To: Joakim Tjernlund
> Cc: spi-devel-general
> Subject: Re: [spi-devel-general] Performance of spi_mpc83xx.c sucks.
> 
> >>>>> "Joakim" == Joakim Tjernlund <joakim.tjernlund-SNLAxHN9vbcOP4wsBPIw7w@public.gmane.org> writes:
> 
>  Joakim> We have noticed that the spi_mpc83xx.c driver is very slow, the gap
>  Joakim> between words are huge.
>  Joakim> So I started to optimise it and it still sucks.
>  Joakim> However, if I poll the SPIE_NF SPIE_NE bits instead it works MUCH
>  Joakim> better, like so:
> 
> Yes, I've noticed the same. I get around ~5 times higher throughput
> with a simple polled loop in U-Boot compared to under Linux (66MHz
> clock).
> 
> I've written it of as simply being a question of interrupt overhead
> (at 66MHz / 32bits we're talking over 2 million interrupts per
> second - E.G. only ~100 instructions between each!)
> 
> 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?
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?

 Jocke 


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