LPSPI driver with DMA does not work on NXP RT platform

[decsny]

Discussed in #81007

^{Originally posted by ofirshe November 6, 2024}
Hi @DerekSnell and @decsny,

After rebasing to align with the latest fix in the LPSPI driver Fix NXP LPSPI native chip select when using synchronous API with DMA, I’m seeing some unexpected behavior. For reference, I’m working with the RT1060EVKB board and have the following project configuration flags:

CONFIG_SPI=y
CONFIG_SPI_MCUX_LPSPI_DMA=y
CONFIG_SPI_ASYNC=n

I also updated the device tree to enable SPI transactions with DMA on the LPSPI peripheral:

&lpspi1 {
	status = "okay";
	/* DMA channels 0 and 1, muxed to LPSPI1 RX and TX */
	dmas = <&edma0 0 13>, <&edma0 1 14>;
	dma-names = "rx", "tx";
	pinctrl-0 = <&pinmux_lpspi1>;
	pinctrl-names = "default";
	transfer-delay = <500>;
	si5402: spi-dev-si5402@0 {
		compatible = "skyworks,si5402";
		status = "okay";
		spi-max-frequency = <1000000>;
		reg = <0>;
	};
};

Here’s the code I’m using for the transaction:

uint8_t tx_data[2] = { 0 };
uint8_t rx_data[4]  = { 0 };
uint16_t rx_len;
uint16_t tx_len;

tx_data[0] = 0xD0;
tx_len = 1;
rx_len = 3;
const struct spi_buf tx_buf = { .buf = tx_data, .len = tx_len };
const struct spi_buf rx_buf = { .buf = rx_data, .len = rx_len };
const struct spi_buf_set tx = { .buffers = &tx_buf, .count = 1 };
const struct spi_buf_set rx = { .buffers = &rx_buf, .count = 1 };
return spi_transceive_dt(&cfg->bus, &tx, &rx);

SPI configured mode: SPI_WORD_SET(8) | SPI_OP_MODE_MASTER | SPI_TRANSFER_MSB

From the waveform output , I noticed some issues:

1. The clock line remains high throughout the transaction, which is unexpected, as I’ve configured it for 1 MHz.
2. The MOSI channel does not display the expected data (0xD0).

Additionally, spi_transceive_dt returns -116, with an error log indicating <err> spi_mcux_lpspi: Timeout waiting for transfer complete.

Best regards,
Ofir.

Extra info

What I found is that when I was making this change that broke this, I was testing on the FRDM_MCXN947 board, which does indeed still seem to work even with the dma spi change. But the change appears to break the RT parts, as mentioned in the discussion, which I confirmed.

[matt-wood-ct]

Excellent to see you working on this @decsny, big FYI I've been working with @DerekSnell on the SPI driver recently and there are serious issues with Coherency when using the DMA with DCache enabled, are you looking to implement a fix similar to STs (#71048) on this PR?
Most of the SPI device drivers do not guarantee the data in transactions is nocache, so you will find that sometimes the saleae will show that the SPI just sends junk and you will likely find that the data your drivers get back is also junk because the cached value of that memory location is inconsistent with the raw RAM values

[DerekSnell]

Hi @matt-wood-ct ,
Thank you for raising this. This Issue here is tracking a specific bug in the LPSPI driver introduced with a recent update. The fix for this bug will not include adding cache coherency to this driver. Cache coherency support would be an enhancement feature to this driver. And introducing that in this bug fix would likely slow down getting this bug fixed.

Today, the drivers on NXP MCUs using DMA do not manage cache coherency. If using DMA, the application is required to place the buffers for DMA in non-cached memory. The spi_loopback test is one example to reference how buffers can be placed in non-cached memory.

Best regards

[matt-wood-ct]

Hi @matt-wood-ct , Thank you for raising this. This Issue here is tracking a specific bug in the LPSPI driver introduced with a recent update. The fix for this bug will not include adding cache coherency to this driver. Cache coherency support would be an enhancement feature to this driver. And introducing that in this bug fix would likely slow down getting this bug fixed.

Today, the drivers on NXP MCUs using DMA do not manage cache coherency. If using DMA, the application is required to place the buffers for DMA in non-cached memory. The spi_loopback test is one example to reference how buffers can be placed in non-cached memory.

Best regards

Understood, I will raise a separate issue for this topic (#81125). I do not feel that a SPI driver have hold the policy of "the application must provide non-cached memory" as in practical terms this renders the LPSPI driver with DMA enabled incompatible will virtually all existing zephyr SPI device drivers

[decsny]

when this hotfix merges, i will either reopen this issue or make a new one to track the fact that the chip select is still broken on RT, or maybe just mention this on the other ticket about the chip select issues