I want the use the ecspi2 hardware SPI bus in combination with 5 chip selects. Therefore i have changed the device tree. However accessing spidev1.4 does always fail with errors like:
[ 20.883602] spidev spi1.4: I/O Error in PIO
[ 20.887877] spidev spi1.4: SPI transfer failed: -110
[ 20.892945] spi_master spi1: failed to transfer one message from queue
I swapped the CS pins to figure out if the pins itself is faulty but it is always the fifth device which fails. There are some blogs reporting that the iMX6 supports at most 4 CS? Can you confirm such a limitation? Does the gpio-spi suffer from the same issue?
Are you sure none of your GPIO pins is used by some other driver? That what I thought first. But this “I/O Error in PIO” is not caused by GPIO, but by timeout in SPI driver. How high is your CPU load?
Here excerpt from spi-imx.c:
transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len);
timeout = wait_for_completion_timeout(&spi_imx->xfer_done,
transfer_timeout);
if (!timeout) {
dev_err(&spi->dev, "I/O Error in PIO\n");
spi_imx->devtype_data->reset(spi_imx);
return -ETIMEDOUT;
}
I double-checked that all GPIOs to be used as CS are not used anywhere else. When swapping the GPIOs for e.g. CS1 and CS4 than spidev1.1 is working but not spidev1.4. I found a mailing list with a discussion about the imx spi driver: [PATCH 0/3] spi: spi-imx: fix use of more than four chip selects.
Do you think that reconfiguring the HW SPI pins to be used as gpio-spi will fix my issue?
Well, you found another reason for SPI issues. There are numerous spi-imx.c versions. looking at driver, which comes with 5.4 kernel, it is not obvious to me how GPIO CS >=4 could fail. But driver in kernel 5.15 has such comment
/*
* Note the number of natively supported chip selects for MX51 is 4. Some
* devices may have less actual SS pins but the register map supports 4. When
* using gpio chip selects the cs values passed into the macros below can go
* outside the range 0 - 3. We therefore need to limit the cs value to avoid
* corrupting bits outside the allocated locations.
*
* The simplest way to do this is to just mask the cs bits to 2 bits. This
* still allows all 4 native chip selects to work as well as gpio chip selects
* (which can use any of the 4 chip select configurations).
*/
Of course, if it lets driver unconditionally write CS_no unconditionally shifted left to SPI register, then no wonder it may fail.
Regarding use of native (hardware) chip selects, it primarily depends on can you use those dedicated pads, which can be IOMUXed as SPI SSn, or indeed they are used for something else. Another question is, is particular spi-imx.c driver version usable with native SS or not. Some driver versions may pulse native CS between adjacent SPI transfer words (1/2/4 byte long word), when transfer length is above some limit.
Please disregard my first response, as it refers to the hardware CS, not the GPIO ones, as Edward pointed out.
From what you two discussed the issue might be related to the spi-imx driver, and I noticed you’re using BSP 2.8 (with kernel v4.9). Since we don’t actively support this release anymore, we recommend migrating to a more recent BSP ref. image release with newer kernel versions, like BSP 5 or 6.
@qojote can you try testing your SPI setup on a more recent BSP ref. image release (e.g. 5 or 6) and see if the issue happens there?
