Théo Bueno

i.MX6 ecspi race condition with CPOL=1 and CS GPIO

Discussion created by Théo Bueno on Mar 21, 2019
Latest reply on Oct 23, 2019 by Kane Jiang

Hi,

 

I am having an issue with the imx-spi driver on linux imx branch 4.9.88.

 

On one of my ecspi channel (i.MX6 quad), I am connecting a SPI slave device that works in mode 3 (CPOL=1, CPHA=1). This device is software controlled by a Linux driver that exchange commands with device during probe.

 

It seems that just after reset of the ecspi controller, the default SCLK_CTL value (SCLK inactive state) is 0 (stay low) in the CONFIGREG. So by setting the control register CONREG to bring out the ecspi from reset state just before the CONFIGREG, my clock line goes from high to low, then back to high again as the correct SCLK_CTL value propagates in the controller.

 

As the GPIO chip select is asserted before executing mx51_ecspi_config in spi-imx.c, this counts as a valid clock tick for my SPI device, which sets in an unknown state that prevents its device driver to probe it correctly. This happens whatever device driver the SPI bus is bound to (spidev, custom driver, ...), as can be seen on this capture:

 

ecspi race condition just after reset

 

The first clock "tick" is the effect I described, which can be verified by adding an extra delay between in spi-imx driver between CONREG and CONFIGREG writes:

    /* CTRL register always go first to bring out controller from reset */
    writel(ctrl, spi_imx->base + MX51_ECSPI_CTRL);

    udelay(50);

    reg = readl(spi_imx->base + MX51_ECSPI_TESTREG);
    if (spi->mode & SPI_LOOP)
        reg |= MX51_ECSPI_TESTREG_LBC;
    else
        reg &= ~MX51_ECSPI_TESTREG_LBC;
    writel(reg, spi_imx->base + MX51_ECSPI_TESTREG);

    writel(cfg, spi_imx->base + MX51_ECSPI_CONFIG);

 

Trace with extra delay:

Extra delay between CONREG/CONFIGREG writes in driver

 

After this first transaction, ecspi controller works as expected and this "ghost" clock tick does not appear as the CONFIGREG already has the correct CPOL configuration. I believe this issue could appear again when dealing with multiple SPI slave devices on the same channel with different chip selects, which is not my case here.

 

Is this a known issue ? Is were a workaround to prevent this race condition  from happening ? I don't think the GPIO CS line can be asserted after the ecspi configuration in current driver implementation.

 

I'd also like to add that in linux-imx 4.9.88, the GPIO CS would not even work properly without me backporting these two [1] [2] patches from linux-imx 4.14.78.

 

Thanks for your help and best regards,

Théo Bueno.

Outcomes