From: Stefan Schmidt <stefan@datenfreihafen.org>
To: Eric Miao <eric.y.miao@gmail.com>
Cc: spi-devel-general@lists.sourceforge.net,
linux-arm-kernel@lists.infradead.org,
Stefan Schmidt <stefan@datenfreihafen.org>
Subject: Re: Slow spi_sync() on pxa2xx_spi
Date: Tue, 21 Jun 2011 16:03:41 +0200 [thread overview]
Message-ID: <20110621140341.GK3652@excalibur.local> (raw)
In-Reply-To: <BANLkTinU+chEbZRpFSdRH_dPE2vhK_7pHg@mail.gmail.com>
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
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: Tue, 21 Jun 2011 16:03:41 +0200 [thread overview]
Message-ID: <20110621140341.GK3652@excalibur.local> (raw)
In-Reply-To: <BANLkTinU+chEbZRpFSdRH_dPE2vhK_7pHg@mail.gmail.com>
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
next prev parent reply other threads:[~2011-06-21 14:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-16 8:21 Slow spi_sync() on pxa2xx_spi Stefan Schmidt
2011-06-16 8:21 ` 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 [this message]
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=20110621140341.GK3652@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.