On a custom board like a sabresd, a imx6qp drives a spi link with a mipi bridge (and other stuffs i2c, ...).
Previously, i used a 4.1.15 linux version and all worked fine. I update to 4.14.78 (sumo-4.14.78-1.0.0_ga) and obviously, there's a problem with spi. I use the basic dts configuration of imx6qpsabresd.
At boot, our spi driver is correctly launched, so chip select and spi pins are correct. But inside the driver, there's registers accesses to the bridge component and this is not good: the spi link seems to hang. I see nothing on the miso pin when reading and other signals (mosi, clk and cs) never stop. I can also see there's seemingly no conflict with other pins. So, i wonder why...
Is threre something particular to do with this linux release in order to have spi function ?
I realize the sdma could be the root cause. Il the kernel log, i have:
imx-sdma 20ec000.sdma: no iram assigned, using external mem
imx-sdma 20ec000.sdma: Falling back to user helper
So it seems sdma driver in not loaded, and so on, spi can't work.
I've read with 4.14.78, it would seem sdma driver needs to be loaded as module. It is really the case ? And then, how to have spi access during the kernel boot ?
Thanks in advance.
the image files of SDMA (e.g. sdma-imx6q.bin) available in the directory firmware/imx/sdma for 4.1 and 4.9 kernels. For 4.14 kernel, the sdma firmware is provided with the firmware-imx package and not in the kernel source tree.
for example, "
bitbake core-image-full-cmdline" build the rootfs may not include the firmware-imx. So, you can add
CORE_IMAGE_EXTRA_INSTALL += " firmware-imx-sdma" in local.conf.
Thank you for your response.
If i follow you, as sdma is in another package than kernel, it can't be launched during boot but only by module way. And consequently, spi driver can't be executed during boot. So, it is a major regression for boards that have critical spi drivers.