Re: Slow spi_sync() on pxa2xx_spi

[Stefan Schmidt <stefan@datenfreihafen.org>]

Hello.

On Tue, 2011-06-21 at 22:08, Eric Miao wrote:
> On Tue, Jun 21, 2011 at 10:03 PM, Stefan Schmidt
> <stefan@datenfreihafen.org> wrote:
> > On Thu, 2011-06-16 at 17:44, Eric Miao wrote:
> > > On Thu, Jun 16, 2011 at 5:19 PM, Stefan Schmidt
> > > <stefan@datenfreihafen.org> wrote:
> > > >
> > > > Its either 8bit or 16bit for a message. The mentioned problem happens
> > > > on a 8 bit message. It does nothing else then writing to a defined
> > > > register address to trigger the hardware sending the data in the FIFO.
> > >
> > > This might get too much overhead. I didn't check the source code, but
> > > my guess is it's waiting for interrupt for each message, and once the
> > > interrupt of message being flushed out happens, it starts the next one
> > > waiting for the FIFO empty interrupt coming. Did you try stuff more
> > > bytes into a single message?
> >
> > Took me some time to implement and test al kind of different
> > scenarios. As you suggested I tried to stuff more bytes into a message
> > as well as testing all kind of combination with tx and rx thresholds,
> > timout, PIO and DMA, cs_change , etc. No change.
> >
> > I then bit the bullet and changed the board to use the spi_gpio driver
> > instead of pxa2xx. After some struggling (make sure you setup pin
> > config correctly :)) I got it working but with the same result.
> >
> > My last test block was around using spi_async() instead of spi_sync
> > and as well I was not able to reach my timing criteria. :(
> >
> > To me it seems right now as if it is just not possible to reach
> > something in the 100 usec range with the SPI framework. Obviuously I
> > would be loved to be proven wrong. :)
> >
> > As I'm running way out of time for this part of my project I'm back to
> > the driver now trying to find a solution that avoids the tight timing
> > criteria.
> 
> I think for a time budget like this, you may want to try a dedicated
> polling driver avoid all the interrupt/wait stuff, that's going to maximize
> the throughput. If that's even not possible, it might be HW limitations.

You mean like configuring the pins as plain GPIO and have some small
bitbang functions on my own without the SPI framework? Just trying to
understand in what direction you are pointing me. :)

I might have to try this if it turns out that wrokign around it in the
driver does not work (lets hope at least _something_ works). :)

regards
Stefan Schmidt