On 17.06.2022 16:01:56, Rasmus Villemoes wrote: > >>> Have you enabled DMA on SPI? > >> > >> Not explicitly, but nor have I done anything to disable/not enable it, > >> so I'm not really sure what the right answer is. Is that a CONFIG_ knob > >> or module/kernel parameter? > > > > You can use "/delete-property/ dmas;" and "/delete-property/ dma-names;" > > in your board dts on the &ecspi1 node, the module parameter "use_dma=0", > > or the kernel command line "spi-imx.use_dma=0" to disable DMA. > > > > The SPI host driver uses PIO for smaller transfers, but switches to DMA > > mode for bigger ones (IIRC > 64 bytes). The clearing of the memory > > definitely falls into the big transfer category. The SPI DMA mode is > > broken on various kernel variants (downstream, mainline), kernel > > versions, SoC variants and used SDMA firmware versions. For the > > mcp251xfd driver DMA is also slower. So switch of DMA and try again. > > Thanks! Disabling DMA did the trick, and I can now send traffic back and > forth between the two chips, and since the RAM now gets properly > initialized, I also don't get the ecc error interrupts. \o/ > There is still something to be looked at, since I see > > NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! Update to a newer kernel. In v5.15 this problem is fixed. > when I start the traffic test. And the dev_id reading still doesn't > work (though it's not really used for anything other than an > informative printk). What does it read on your board? But still that transfer should work. > But I'll have to get our hardware guys to help me do some soldering to > capture all four channels at once to see just exactly what is going on > there. Have a look at these: https://sensepeek.com/pcbite_20 regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Attachment:
signature.asc
Description: PGP signature