Hello,
I am observing an interesting race condition on the i.MX53 ECSPI controller.
Here is how to reproduce it:
1) Use any i.MX53-based development kit
2) Connect logic analyzer or scope to ECSPI lines
- MISO, MOSI, SCLK, SS0, SS1 are of interest here
3) Use latest mainline kernel (happens on stable-3.10 as well)
4) Apply spidev-addition.diff patch (needs adjustment if different pinmux or
platform is used), here are the key points of the change:
- This patch binds two SPIDEV devices to single ECSPI bus
- Each SPIDEV uses different chipselect (in the patch, SS0 and SS1 are used)
- Each chipselect is driven as GPIO chipselect, as usual
- The SPIDEV devices are both operated at 1MHz
5) Enable CONFIG_SPI_SPIDEV in Linux kernel configuration
6) Build the kernel for your target platform
7) Boot the kernel on the target platorm
8) Build the test-tool.c which is attached on the target platform
9) Start the scope/logic-analyzer sampling
10) Execute the ./test-tool on the target
The test-tool causes the controller to constantly change clock line (SCK)
polarity as well as assert different chipselect (SSn) GPIOs to handle these two
SPIDEV devices. At some point (usually after a few transmissions), I see the
clock line polarity is changed after the GPIO for the particular device was
asserted. Note that nothing has to be connected on the SPI lines at all and the
issue will manifest itself.
I am attaching the result I see (ecspi-bug.png) on the analyzer.
The expected result would be that, when switching from SPI mode 2 (CPOL , clock
polarity inverted) to SPI mode 0 (clock polarity not inverted), the GPIO
chipselect (SS line) must be asserted AFTER the SCK line changes clock polarity
from HI (mode 2) to LO (mode 0). The same applies when switching from SPI mode
0
to SPI mode 2, the SS line must be asserted after SCK transitioned from LO to
HI. The ilustration for this situation is the top-right red line marker.
What I observe is that, when switching from SPI mode 2 (CPOL , clock polarity
inverted) to SPI mode 0 (clock polarity not inverted), the GPIO chipselect is
asserted earlier than the SCK line changes clock polarity from HI (mode 2) to
LO
(mode 0). I also observe this in case a MODE 0 to MODE 2 transition happens.
The
ilustration for this situation are the top-left and bottom-middle red line
markers.
I also noticed the delay between SS is asserted and CLK changes polarity --
that
is, in the incorrect order case -- is roughly 250-300 nS .
I believe this issue is already known due to the note in this patch for the
ECSPI controller, yet the resolution is not complete:
commit f020c39e51b1ef8389d5cf38190d32f55ff9d556
Author: Sascha Hauer <s.ha...@pengutronix.de>
Date: Tue Feb 8 21:08:59 2011 +0100
spi/imx: select master mode for all channels
The hardware seems to have a race condition when the inactive
channels are in slave mode. We support master mode only, so
we can just switch all channels to master mode.
Any ideas please?
Thank you!
Best regards,
Marek Vasut
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
spi-devel-general mailing list
spi-devel-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/spi-devel-general
