i.MX6S driving eCSPI causes S/PDIF glitches

[inovonicsjeremy]

Hi,

I'm driving audio out the S/PDIF port. This is working under most other conditions, but when accessing any of the SPI ports the S/PDIF data includes scattered duplicated samples on the left channel, and zeroed samples on the right channel, in sync. Is this a known silicon issue (I didn't see it in the errata), and is there any workaround? SPI is needed to drive several peripherals in this case, while audio should not be interrupted. I2S ports appear to be unaffected (and are needed to drive multiple DACs), and driving other serial controllers (including I2C and UART) does not cause any such glitch, only SPI. The same glitches occur when SPI is driven to a port not connected to the peripherals in question.

Thanks,

Jeremy

[inovonicsjeremy · Accepted solution]

We've gone ahead and implemented the product in question with an external transmitter attached via I2S, avoiding the silicon in question. No such glitches have surfaced with either ESAI or SSI output.

[art]

The issue you describe is not the known one. The most likely cause of the issue is that accessing SPI produces high amount of software overhead that leads to S/PDIF data underrun. Do you drive SPI purely in software or with SDMA? What i.MX6S-based hardware do you use? What software/OS runs on your hardware? Please specify.

Have a great day,
Artur

[inovonicsjeremy]

Apologies for the lack of detail, my current setup is a Variscite VAR-SOM-SOLO module, and the chips currently under test are an MCIMX6S5EVM10AB, and a similar MCIMX6S5EVM10AC. SPI has been tested with SDMA and PIO with expectations of PIO being more reliable given the amount of effort required to transform the mainline spi-imx driver's DMA support to enable 9-bit transfers, though it was tested using only 8-bit transfers and found to cause the same issue. S/PDIF is fed only by DMA using the driver found in mainline (fsl_spdif and imx-spdif). The kernel in question is currently from the linux-fslc tree.

After much analysis my conclusion was similar to yours, that the most likely option was that the "glitches" in question were the result of a resync (though emitting mismatched samples does not seem consistent with the chip documentation's description of a resync condition), however one would think that the high overhead issue would either affect or be affected by other systems... concurrent use of two I2S ports is unaffected during these issues, and the condition is not caused by heavy load on the Ethernet port (which can produce a large number of interrupts) nor aleviated by running small amounts of data through the SPI port or altering the SPI or S/PDIF clock rates.