Drivers: SPI: `nxp,imx-lpspi` DMA usage not cache coherent

[matt-wood-ct]

Is your enhancement proposal related to a problem? Please describe.
Yes, when using LPSPI with Zephyr SPI device drivers you cannot enable DMA as it does not manage coherency internally, the driver has the expectation the usage will manage cache coherency so in practice this means that virtually all mainstream SPI device drivers can/will misbehave in unusual and unpredictable manners.

I noticed this on a project which utilised and IMXRT1040 + a NRF52 series IC connected using zephyr,bt-hci-spi which is a very high traffic driver so thus is best implemented using DMA.
I also ran into the issues when using the worldsemi,ws2812-spi and jedec,spi-nor drivers.
Those are just the in-tree drivers I use in this project, but I would suspect this issue applies universally given the cause.

Describe the solution you'd like
I would like the nxp,imx-lpspi driver to implement a cache coherency scheme similar to what the existing STM32H series driver does which also had DCache issue where by if caching is enabled and the memory provided to the transact function is cacheable then it uses a small internal buffer for transactions to enforce coherency in all cases while enabling applications to provide large nocache buffers if their application requires it (see 0e72d63 and #71048)

Describe alternatives you've considered
It would be possible to do the opposite, say that all SPI device drivers need to account for coherency and make their buffers no cache, but this will likely cause significantly more work & problems.

Additional context
For my active project I have taking the nxp,imx-lpspi out of tree and added a bodge where in the transact function I flush the buffer locations then in the DMA callback I invalidate the cache over the RX buffer, this functionally works but is technically not thread safe (when the buffers are allocated from stack or 32byte aligned & rounded up it is safe).

[matt-wood-ct]

To clarify what I mean when I say "unusual and unpredictable manners". Generally this manifested as random junk data coming out of the SPI and the driver also receiving back bad data which does not match bus captures, all of which is inconsistent build to build as it depends on what uses adjacent memory areas. Many of instances showed 0xAA coming out of the SPI, which is not surprising as the unused memory is stuffed with 0xAA as part of the high water mark and memory protection schemes.

[Raymond0225]

I believe that this DMA coherency issue exists on all DMA related peripheral devices such like uart, i2c i2s spi, it is better we come up with a total solution for it.

[matt-wood-ct]

I believe that this DMA coherency issue exists on all DMA related peripheral devices such like uart, i2c i2s spi, it is better we come up with a total solution for it.

Agree but in a practical sense there is precedence to implement the fix at peripheral driver level and this should be done unless someone is actively working on a zephyr wide DMA memory management system.