All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Schmidt <stefan@datenfreihafen.org>
To: spi-devel-general@lists.sourceforge.net
Cc: Eric Miao <eric.y.miao@gmail.com>, linux-arm-kernel@lists.infradead.org
Subject: Slow spi_sync() on pxa2xx_spi
Date: Thu, 16 Jun 2011 10:21:12 +0200	[thread overview]
Message-ID: <20110616082112.GA10075@excalibur.local> (raw)

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

WARNING: multiple messages have this Message-ID (diff)
From: stefan@datenfreihafen.org (Stefan Schmidt)
To: linux-arm-kernel@lists.infradead.org
Subject: Slow spi_sync() on pxa2xx_spi
Date: Thu, 16 Jun 2011 10:21:12 +0200	[thread overview]
Message-ID: <20110616082112.GA10075@excalibur.local> (raw)

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

             reply	other threads:[~2011-06-16  8:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-16  8:21 Stefan Schmidt [this message]
2011-06-16  8:21 ` Slow spi_sync() on pxa2xx_spi Stefan Schmidt
2011-06-16  8:34 ` Eric Miao
2011-06-16  8:34   ` Eric Miao
     [not found]   ` <BANLkTikuo_fHbw9FFMtorpg15vOnXMK-+g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-16  9:19     ` Stefan Schmidt
2011-06-16  9:19       ` Stefan Schmidt
2011-06-16  9:44       ` Eric Miao
2011-06-16  9:44         ` Eric Miao
2011-06-21 14:03         ` Stefan Schmidt
2011-06-21 14:03           ` Stefan Schmidt
2011-06-21 14:08           ` Eric Miao
2011-06-21 14:08             ` Eric Miao
2011-06-21 14:20             ` Stefan Schmidt
2011-06-21 14:20               ` Stefan Schmidt
2011-06-21 15:04               ` Eric Miao
2011-06-21 15:04                 ` Eric Miao
     [not found]                 ` <BANLkTi=+oNHYYL_=gYUCC+zFBfnkxZqJWA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-21 15:18                   ` Stefan Schmidt
2011-06-21 15:18                     ` Stefan Schmidt
2011-06-16  9:59       ` Stefan Schmidt
2011-06-16  9:59         ` Stefan Schmidt
2011-06-16 10:02         ` Eric Miao
2011-06-16 10:02           ` Eric Miao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110616082112.GA10075@excalibur.local \
    --to=stefan@datenfreihafen.org \
    --cc=eric.y.miao@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=spi-devel-general@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.