There are known issues with dma for the spi controller in the ls1021a. Specifically erratum A-011218 eDMA may not work with SPI. As a result, in linux I'm getting around 125k bytes/second transfer rate reading from nor flash memory and that's consuming 100% of one core.
The erratum offers a possible workaround using a second dummy dma channel.
Has anyone tried to implement this workaround for linux? There seems nothing in the kernel main line, which makes me wonder if it is realistic to do since kernel support is normally pretty good.
At the moment we are constrained to use the 4 series kernels and I have tried the latest version from 4.19.280. It appears there has been some further general development of spi in the 5 series so I'd also be interested to know if anyone is using the ls1021a with a 5 series kernel and if so whether the performance is any better.
A quick speed test would be "dd if=/dev/mtdxx of=/dev/null" and see what it says. I'm seeing over 500 seconds for 64M.
Thanks.
Hello,
You can do the same test with the latest LSDK and should have better performance.
Hi Oswalag,
Thanks. You say better, do you have any idea how much better?
It looks like the LDP is based on kernel 5.15, do you know if the improvement is just from the generic kernel changes or is there something specific to address the erratum directly?
The system we are working with is based on a module from TQ using the TQ yocto port. There is a lot of stuff built on top of that. Switching to the NXP LDP could be quite a large exercise. Before I embark on that it would help to have some idea of what is changed in the SPI.
Thanks
Unfortunately there are no plans to implement the workaround as an LSDK patch, thus the only way to see if the transfer rate has improved is testing by yourself and the mentioned improvement is from the generic kernel changes, from NXP side we only have the mentioned workaround.
Thanks Oswalag,
Not the answer I had hoped for, but it is helpful to know the situation.