Strange i.MX6ULL SDMA behavior

[courk]

Hi,

I'm currently playing around with custom SDMA scripts using the i.MX6ULL. My software is based on official kernel 4.1.15_2.0.0.

I mainly based my work on resources available on the Reference Manual and on the following blog posts: Jonah's Blog by skrap 

I use the SDMA event SDMA_EXT_EVENT01 (event 15, lMX6UL_PAD_JTAG_TMS__SDMA_EXT_EVENT01) to make my custom SDMA channel eligible. From this channel, I use the eCSPI1 shared peripheral to read a burst of data. This data is then copied to the ARM main memory.

My issue seems to be linked with the detection of the SDMA_EXT_EVENT. My custom SDMA channel is only run at the right time when the main ARM CPU is loaded enough.

For instance, here is the observed (and correct) behavior while I'm running the stress -c 1 command on the ARM core.

When the stress command is not running, I observe a strange and inconsistent behavior. The SDMA script is sometimes run twice in a row and SDMA_EXT_EVENT01 is not correctly detected.

I know it's not advised to create custom SDMA scripts and that there is probably better ways to achieve the same results (by using the hardware SPI_RDY feature of the eCSPI peripheral for instance). Nevertheless I really don't understand this behavior.

How can it be explained? Can it be linked to what's described on section 47.4.6.1 Clock Gating and Low Power Modes of the reference Manual? Something to do with the SDMA scheduler (even though increasing my channel priority level doesn't improve the situation)?

Thanks!

[igorpadykov · Accepted solution]

Hi courk

you are right, this may be caused by low power modes, one can try to disable it

or use kernel boot parameter : enable_wait_mode=off

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[courk]

Hi Igor,

Thanks for the fast answer and for having pointed out low power / clock gating issues.

I indeed solved the issue by setting the CG0 field (ecspi1_clk_enable) of CCM_CCGR1 to 0b11 (Clock is on during all modes, except STOP mode).

Thanks again,