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:
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:
Trace with extra delay:
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.
Thanks for your help and best regards,