Slow spi_sync() on pxa2xx_spi

Slow spi_sync() on pxa2xx_spi

[Stefan Schmidt]

Hello.

I'm working on the Imote2 (pxa27x based) platform [1] which includes a
radio chip (cc2420, IEEE 802.15.4) connected over SPI [2].

The problem I'm facing is that the spi_sync() call of the driver to
write/read from the registers over the SPI bus takes up to 26 milli
seconds. The minimum I measured was 500 micro seconds for the call.

That creates a problem as the workflow to send a frame over the radio
includes to write to a spi register for sending out the frame from a
pre-filled FIFO. Then wait up to 320 micro seconds for a GPIO to raise
and polling a status register until a TX_ACTIVE bit is no longer set
afterwards.

But the first register write to initiate the sending already takes so
long that the GPIO is already low again and the TX_ACTIVE is also gone
when I come back from the spi_sync() call.

It really smells like I'm doing something seriously wrong here. For
the pxa2xx_spi driver I already tried various options without any
difference I could see. Enable/disbale DMA, different tx/rx
thresholds, different dma burst sizes, different timeout, etc.

I can only explain the long time with some sleeping in SPI while
other parts are scheduled. Is there a way to avoid this for SPI? Or
is there an API I did not found yet to cover my needs?

The measurement is done with getnstimeofday btw and I verified that a
basic operation like two multiplications are down in the 5 micro
seconds area which gives me faith that the measurements should be
correct:

getnstimeofday (&before);
ret = spi_sync(lp->spi, &msg);
getnstimeofday (&after);

result = timespec_sub(after, before);
printk("Strobe time: %lu secs and %lu nsecs (strobe %i)\n", (long)result.tv_sec, result.tv_nsec, addr);

I'm out of ideas what to change here. The only option, I want to
avoid, is trying to drive the SPI pins manually and see if I have
better results with bit-banging it myself.

regards
Stefan Schmidt

[1] Board: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-pxa/stargate2.c
[2] Driver:
http://linux-zigbee.git.sourceforge.net/git/gitweb.cgi?p=linux-zigbee/kernel;a=blob;f=drivers/ieee802154/cc2420.c;h=50761de6eb2d87014b6e43daa4ed642319d10567;hb=6a1a3375886ba69b1969ceb5df3007a4f1791d27

Slow spi_sync() on pxa2xx_spi

[Eric Miao]

On Thu, Jun 16, 2011 at 4:21 PM, Stefan Schmidt
<stefan@datenfreihafen.org> wrote:
> Hello.
>
> I'm working on the Imote2 (pxa27x based) platform [1] which includes a
> radio chip (cc2420, IEEE 802.15.4) connected over SPI [2].
>
> The problem I'm facing is that the spi_sync() call of the driver to
> write/read from the registers over the SPI bus takes up to 26 milli
> seconds. The minimum I measured was 500 micro seconds for the call.
>
> That creates a problem as the workflow to send a frame over the radio
> includes to write to a spi register for sending out the frame from a
> pre-filled FIFO. Then wait up to 320 micro seconds for a GPIO to raise
> and polling a status register until a TX_ACTIVE bit is no longer set
> afterwards.
>
> But the first register write to initiate the sending already takes so
> long that the GPIO is already low again and the TX_ACTIVE is also gone
> when I come back from the spi_sync() call.
>
> It really smells like I'm doing something seriously wrong here. For
> the pxa2xx_spi driver I already tried various options without any
> difference I could see. Enable/disbale DMA, different tx/rx
> thresholds, different dma burst sizes, different timeout, etc.
>
> I can only explain the long time with some sleeping in SPI while
> other parts are scheduled. Is there a way to avoid this for SPI? Or
> is there an API I did not found yet to cover my needs?
>
> The measurement is done with getnstimeofday btw and I verified that a
> basic operation like two multiplications are down in the 5 micro
> seconds area which gives me faith that the measurements should be
> correct:
>
> getnstimeofday (&before);
> ret = spi_sync(lp->spi, &msg);
> getnstimeofday (&after);
>
> result = timespec_sub(after, before);
> printk("Strobe time: %lu secs and %lu nsecs (strobe %i)\n", (long)result.tv_sec, result.tv_nsec, addr);
>
> I'm out of ideas what to change here. The only option, I want to
> avoid, is trying to drive the SPI pins manually and see if I have
> better results with bit-banging it myself.

What is the SPI frequency?

For PIO, the transfer actually happens in the interrupt handler so it's
supposed to be fast (did you enable threaded IRQ by the way?).

And since the transfer happens on message base, what is the size
of each of your message? And if it could be enlarged to big blocks.

>
> regards
> Stefan Schmidt
>
> [1] Board: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/mach-pxa/stargate2.c
> [2] Driver:
> http://linux-zigbee.git.sourceforge.net/git/gitweb.cgi?p=linux-zigbee/kernel;a=blob;f=drivers/ieee802154/cc2420.c;h=50761de6eb2d87014b6e43daa4ed642319d10567;hb=6a1a3375886ba69b1969ceb5df3007a4f1791d27
>

Slow spi_sync() on pxa2xx_spi

[Stefan Schmidt]

Hello.

On Thu, 2011-06-16 at 16:34, Eric Miao wrote:
> On Thu, Jun 16, 2011 at 4:21 PM, Stefan Schmidt
> <stefan@datenfreihafen.org> wrote:
> > Hello.
> >
> > I'm working on the Imote2 (pxa27x based) platform [1] which includes a
> > radio chip (cc2420, IEEE 802.15.4) connected over SPI [2].
> >
> > The problem I'm facing is that the spi_sync() call of the driver to
> > write/read from the registers over the SPI bus takes up to 26 milli
> > seconds. The minimum I measured was 500 micro seconds for the call.
> >
> > That creates a problem as the workflow to send a frame over the radio
> > includes to write to a spi register for sending out the frame from a
> > pre-filled FIFO. Then wait up to 320 micro seconds for a GPIO to raise
> > and polling a status register until a TX_ACTIVE bit is no longer set
> > afterwards.
> >
> > But the first register write to initiate the sending already takes so
> > long that the GPIO is already low again and the TX_ACTIVE is also gone
> > when I come back from the spi_sync() call.
> >
> > It really smells like I'm doing something seriously wrong here. For
> > the pxa2xx_spi driver I already tried various options without any
> > difference I could see. Enable/disbale DMA, different tx/rx
> > thresholds, different dma burst sizes, different timeout, etc.
> >
> > I can only explain the long time with some sleeping in SPI while
> > other parts are scheduled. Is there a way to avoid this for SPI? Or
> > is there an API I did not found yet to cover my needs?
> >
> > The measurement is done with getnstimeofday btw and I verified that a
> > basic operation like two multiplications are down in the 5 micro
> > seconds area which gives me faith that the measurements should be
> > correct:
> >
> > getnstimeofday (&before);
> > ret = spi_sync(lp->spi, &msg);
> > getnstimeofday (&after);
> >
> > result = timespec_sub(after, before);
> > printk("Strobe time: %lu secs and %lu nsecs (strobe %i)\n", (long)result.tv_sec, result.tv_nsec, addr);
> >
> > I'm out of ideas what to change here. The only option, I want to
> > avoid, is trying to drive the SPI pins manually and see if I have
> > better results with bit-banging it myself.
> 
> What is the SPI frequency?

I tried various settings in .max_speed_hz from the original 6.6 MHt to
10 MHz and 13MHz as maximum of the controller. Did also not change
anything for me.

That reminds me that after defining DEBUG in pxa2xx_spi it did always
report 13MHz to me. Need to have a look at it.

> For PIO, the transfer actually happens in the interrupt handler so it's
> supposed to be fast (did you enable threaded IRQ by the way?).

You mean with request_threaded_irq()? (Seems there is no config option
for it) No, I'm not using it neither did I modify the pxa2xx_spi
driver to use it.

Thanks for the informations about PIO happen in the interrupt handler.
We already suspected that DMA might come with some overhead and for
our smallish register access we did not need it. Sadly .enable_dma = 0
did not make any difference. Will have another look into this.

I'm on 2.6.38 here btw. But the pxa2xx_spi driver did not get mayn
updates since then. The only commit that may be interested  is this
one:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=850a28ecd8044ef36b2c7699d2e3736a410b4d0a

> And since the transfer happens on message base, what is the size
> of each of your message? And if it could be enlarged to big blocks.

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.

The FIFO reading and writing has no time critical elements here and
gets pre-filled.

regards
Stefan Schmidt

Slow spi_sync() on pxa2xx_spi

[Eric Miao]

On Thu, Jun 16, 2011 at 5:19 PM, Stefan Schmidt
<stefan@datenfreihafen.org> wrote:
> Hello.
>
> On Thu, 2011-06-16 at 16:34, Eric Miao wrote:
>> On Thu, Jun 16, 2011 at 4:21 PM, Stefan Schmidt
>> <stefan@datenfreihafen.org> wrote:
>> > Hello.
>> >
>> > I'm working on the Imote2 (pxa27x based) platform [1] which includes a
>> > radio chip (cc2420, IEEE 802.15.4) connected over SPI [2].
>> >
>> > The problem I'm facing is that the spi_sync() call of the driver to
>> > write/read from the registers over the SPI bus takes up to 26 milli
>> > seconds. The minimum I measured was 500 micro seconds for the call.
>> >
>> > That creates a problem as the workflow to send a frame over the radio
>> > includes to write to a spi register for sending out the frame from a
>> > pre-filled FIFO. Then wait up to 320 micro seconds for a GPIO to raise
>> > and polling a status register until a TX_ACTIVE bit is no longer set
>> > afterwards.
>> >
>> > But the first register write to initiate the sending already takes so
>> > long that the GPIO is already low again and the TX_ACTIVE is also gone
>> > when I come back from the spi_sync() call.
>> >
>> > It really smells like I'm doing something seriously wrong here. For
>> > the pxa2xx_spi driver I already tried various options without any
>> > difference I could see. Enable/disbale DMA, different tx/rx
>> > thresholds, different dma burst sizes, different timeout, etc.
>> >
>> > I can only explain the long time with some sleeping in SPI while
>> > other parts are scheduled. Is there a way to avoid this for SPI? Or
>> > is there an API I did not found yet to cover my needs?
>> >
>> > The measurement is done with getnstimeofday btw and I verified that a
>> > basic operation like two multiplications are down in the 5 micro
>> > seconds area which gives me faith that the measurements should be
>> > correct:
>> >
>> > getnstimeofday (&before);
>> > ret = spi_sync(lp->spi, &msg);
>> > getnstimeofday (&after);
>> >
>> > result = timespec_sub(after, before);
>> > printk("Strobe time: %lu secs and %lu nsecs (strobe %i)\n", (long)result.tv_sec, result.tv_nsec, addr);
>> >
>> > I'm out of ideas what to change here. The only option, I want to
>> > avoid, is trying to drive the SPI pins manually and see if I have
>> > better results with bit-banging it myself.
>>
>> What is the SPI frequency?
>
> I tried various settings in .max_speed_hz from the original 6.6 MHt to
> 10 MHz and 13MHz as maximum of the controller. Did also not change
> anything for me.
>
> That reminds me that after defining DEBUG in pxa2xx_spi it did always
> report 13MHz to me. Need to have a look at it.
>
>> For PIO, the transfer actually happens in the interrupt handler so it's
>> supposed to be fast (did you enable threaded IRQ by the way?).
>
> You mean with request_threaded_irq()? (Seems there is no config option
> for it) No, I'm not using it neither did I modify the pxa2xx_spi
> driver to use it.
>
> Thanks for the informations about PIO happen in the interrupt handler.
> We already suspected that DMA might come with some overhead and for
> our smallish register access we did not need it. Sadly .enable_dma = 0
> did not make any difference. Will have another look into this.
>
> I'm on 2.6.38 here btw. But the pxa2xx_spi driver did not get mayn
> updates since then. The only commit that may be interested ?is this
> one:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=850a28ecd8044ef36b2c7699d2e3736a410b4d0a
>
>> And since the transfer happens on message base, what is the size
>> of each of your message? And if it could be enlarged to big blocks.
>
> 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?

>
> The FIFO reading and writing has no time critical elements here and
> gets pre-filled.
>
> regards
> Stefan Schmidt
>

Slow spi_sync() on pxa2xx_spi

[Stefan Schmidt]

Hello.

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.

Eric, thanks again for your fast and helpfull mails.

regards
Stefan Schmidt

Slow spi_sync() on pxa2xx_spi

[Eric Miao]

On Tue, Jun 21, 2011 at 10:03 PM, Stefan Schmidt
<stefan@datenfreihafen.org> wrote:
>
> Hello.
>
> 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.

>
> Eric, thanks again for your fast and helpfull mails.

No problem, most welcome.

>
> regards
> Stefan Schmidt

Slow spi_sync() on pxa2xx_spi

[Stefan Schmidt]

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

Slow spi_sync() on pxa2xx_spi

[Eric Miao]

On Tue, Jun 21, 2011 at 10:20 PM, Stefan Schmidt
<stefan@datenfreihafen.org> wrote:
> 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 mean just to have a small driver, configure the SPI controller with
hardcoded values, and try writing to the SSDR all by yourself, and
polling the SSSR status bits. Not something simulating SPI w/ GPIO,
that will be slow.

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

Slow spi_sync() on pxa2xx_spi

[Stefan Schmidt]

Hello.

On Tue, 2011-06-21 at 23:04, Eric Miao wrote:
> On Tue, Jun 21, 2011 at 10:20 PM, Stefan Schmidt
> <stefan@datenfreihafen.org> wrote:
> >
> > 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 mean just to have a small driver, configure the SPI controller with
> hardcoded values, and try writing to the SSDR all by yourself, and
> polling the SSSR status bits. Not something simulating SPI w/ GPIO,
> that will be slow.

Wow, that is something I like to avoid doing at all. :) Thanks for the
pointer though. Something to have in mind if everythings else fails.

regards
Stefan Schmidt

Slow spi_sync() on pxa2xx_spi

[Stefan Schmidt]

Hello.

On Thu, 2011-06-16 at 11:19, Stefan Schmidt wrote:
> 
> On Thu, 2011-06-16 at 16:34, Eric Miao wrote:
> > 
> > What is the SPI frequency?
> 
> I tried various settings in .max_speed_hz from the original 6.6 MHt to
> 10 MHz and 13MHz as maximum of the controller. Did also not change
> anything for me.
> 
> That reminds me that after defining DEBUG in pxa2xx_spi it did always
> report 13MHz to me. Need to have a look at it.

Either the debug statement or the setting is indeed wrong.

[    0.696759] spi spi1.0: 13000000 Hz actual, PIO
[    0.715760] spi spi3.0: 13000000 Hz actual, PIO

Which comes from this part of the driver (with #define DEBUG set):

        /* NOTE:  PXA25x_SSP _could_ use external clocking ... */
        if (!pxa25x_ssp_comp(drv_data))
                dev_dbg(&spi->dev, "%ld Hz actual, %s\n",
                        clk_get_rate(ssp->clk)
                                / (1 + ((chip->cr0 & SSCR0_SCR(0xfff)) >> 8)),
                        chip->enable_dma ? "DMA" : "PIO");
        else
                dev_dbg(&spi->dev, "%ld Hz actual, %s\n",
                        clk_get_rate(ssp->clk) / 2
                                / (1 + ((chip->cr0 & SSCR0_SCR(0x0ff)) >> 8)),
                        chip->enable_dma ? "DMA" : "PIO");

But the board file has this:

static struct spi_board_info spi_board_info[] __initdata = {
        {
                .modalias = "lis3l02dq",
                .max_speed_hz = 8000000,/* 8MHz max spi frequency at 3V */
                .bus_num = 1,
                .chip_select = 0,
                .controller_data = &staccel_chip_info,
                .irq = IRQ_GPIO(96),
        }, {
                .modalias = "cc2420",
//              .max_speed_hz = 6500000,
                .max_speed_hz = 10000000, /* 10MHz */
                .bus_num = 3,
                .chip_select = 0,
                .controller_data = &cc2420_info,
                .platform_data = &cc2420_pdata,

        },
};

Its neither 8MHz for spi1.0 nor 10MHz for spi3.0.

Adding some debug info shows me that the driver gets the data fine form the
platform data:
[    0.695770] spi spi1.0: chip->speed_hz: 8000000, spi->max_speed_hz: 8000000
[    0.695872] spi spi1.0: 13000000 Hz actual, PIO
[    0.714824] spi spi3.0: chip->speed_hz: 10000000, spi->max_speed_hz: 10000000
[    0.714929] spi spi3.0: 13000000 Hz actual, PIO

Thats directly above the chip->cr0 and chip->cr1 calculations. Is this just the
initial seeting and it gets overwritten before a transfer or is the speed
calculation wrong?

regards
Stefan Schmidt

Slow spi_sync() on pxa2xx_spi

[Eric Miao]

On Thu, Jun 16, 2011 at 5:59 PM, Stefan Schmidt
<stefan@datenfreihafen.org> wrote:
> Hello.
>
> On Thu, 2011-06-16 at 11:19, Stefan Schmidt wrote:
>>
>> On Thu, 2011-06-16 at 16:34, Eric Miao wrote:
>> >
>> > What is the SPI frequency?
>>
>> I tried various settings in .max_speed_hz from the original 6.6 MHt to
>> 10 MHz and 13MHz as maximum of the controller. Did also not change
>> anything for me.
>>
>> That reminds me that after defining DEBUG in pxa2xx_spi it did always
>> report 13MHz to me. Need to have a look at it.
>
> Either the debug statement or the setting is indeed wrong.
>
> [ ? ?0.696759] spi spi1.0: 13000000 Hz actual, PIO
> [ ? ?0.715760] spi spi3.0: 13000000 Hz actual, PIO
>
> Which comes from this part of the driver (with #define DEBUG set):
>
> ? ? ? ?/* NOTE: ?PXA25x_SSP _could_ use external clocking ... */
> ? ? ? ?if (!pxa25x_ssp_comp(drv_data))
> ? ? ? ? ? ? ? ?dev_dbg(&spi->dev, "%ld Hz actual, %s\n",
> ? ? ? ? ? ? ? ? ? ? ? ?clk_get_rate(ssp->clk)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/ (1 + ((chip->cr0 & SSCR0_SCR(0xfff)) >> 8)),
> ? ? ? ? ? ? ? ? ? ? ? ?chip->enable_dma ? "DMA" : "PIO");
> ? ? ? ?else
> ? ? ? ? ? ? ? ?dev_dbg(&spi->dev, "%ld Hz actual, %s\n",
> ? ? ? ? ? ? ? ? ? ? ? ?clk_get_rate(ssp->clk) / 2
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?/ (1 + ((chip->cr0 & SSCR0_SCR(0x0ff)) >> 8)),
> ? ? ? ? ? ? ? ? ? ? ? ?chip->enable_dma ? "DMA" : "PIO");
>
> But the board file has this:
>
> static struct spi_board_info spi_board_info[] __initdata = {
> ? ? ? ?{
> ? ? ? ? ? ? ? ?.modalias = "lis3l02dq",
> ? ? ? ? ? ? ? ?.max_speed_hz = 8000000,/* 8MHz max spi frequency at 3V */
> ? ? ? ? ? ? ? ?.bus_num = 1,
> ? ? ? ? ? ? ? ?.chip_select = 0,
> ? ? ? ? ? ? ? ?.controller_data = &staccel_chip_info,
> ? ? ? ? ? ? ? ?.irq = IRQ_GPIO(96),
> ? ? ? ?}, {
> ? ? ? ? ? ? ? ?.modalias = "cc2420",
> // ? ? ? ? ? ? ?.max_speed_hz = 6500000,
> ? ? ? ? ? ? ? ?.max_speed_hz = 10000000, /* 10MHz */
> ? ? ? ? ? ? ? ?.bus_num = 3,
> ? ? ? ? ? ? ? ?.chip_select = 0,
> ? ? ? ? ? ? ? ?.controller_data = &cc2420_info,
> ? ? ? ? ? ? ? ?.platform_data = &cc2420_pdata,
>
> ? ? ? ?},
> };
>
> Its neither 8MHz for spi1.0 nor 10MHz for spi3.0.
>
> Adding some debug info shows me that the driver gets the data fine form the
> platform data:
> [ ? ?0.695770] spi spi1.0: chip->speed_hz: 8000000, spi->max_speed_hz: 8000000
> [ ? ?0.695872] spi spi1.0: 13000000 Hz actual, PIO
> [ ? ?0.714824] spi spi3.0: chip->speed_hz: 10000000, spi->max_speed_hz: 10000000
> [ ? ?0.714929] spi spi3.0: 13000000 Hz actual, PIO
>
> Thats directly above the chip->cr0 and chip->cr1 calculations. Is this just the
> initial seeting and it gets overwritten before a transfer or is the speed
> calculation wrong?

Every SPI chip has a clock setting, so spi_setup() will be done before
every transfer, that's my understanding. Do check the resulting SCCR
register settings to confirm it's not setup correctly before each transfer.

>
> regards
> Stefan Schmidt
>