imx8mm - sdma issue with multi sai

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

imx8mm - sdma issue with multi sai

1,313 Views
antho
Contributor III

Hi,

I want to playback and capture simultaneously 32x2 audio channels on the imx8mm sai1 interface on its 8 TX and 8 RX lanes, carrying each 4 TDM slots (8x4 = 32 audio channels each way). TX and RX are linked. The sdma2 controller is configured to handle this data transfer in MULTI_SAI mode (as in imx8mm.dtsi), using one channel for each way. Here is the sai1 device tree node :


&sai1 {
compatible = "fsl,imx8mq-sai";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_sai1>;
assigned-clocks = <&clk IMX8MM_CLK_SAI1>;
assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>;
assigned-clock-rates = <49152000>;
clocks = <&clk IMX8MM_CLK_SAI1_IPG>, <&clk IMX8MM_CLK_DUMMY>,
<&clk IMX8MM_CLK_SAI1_ROOT>, <&clk IMX8MM_CLK_DUMMY>,
<&clk IMX8MM_CLK_DUMMY>, <&clk IMX8MM_AUDIO_PLL1_OUT>,
<&clk IMX8MM_AUDIO_PLL2_OUT>;
clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3", "pll8k", "pll11k";
fsl,sai-multi-lane;
fsl,dataline = <0 0xff 0xff>;
dmas = <&sdma2 0 25 0>, <&sdma2 1 25 0>; // MULTI_SAI
fsl,sai-synchronous-rx; //default
status = "okay";
};

It used to work in kernel 4.19. So a hardware bug is not an option. Now I have moved my project to yocto zeus and kernel 5.4 but it does not work anymore. SAI driver has not changed since 4.19 but the SDMA has changed a lot. Here is the problem :

I can capture only 2 SAI lanes = 8 channels (note that the 8 TX lanes are working fine).
Beyond that number of channels, the SDMA does not start emptying the RX samples of the SAI RX FIFOs, so eventually an overflow occurs.

Here are some debug kernel logs :

  • when it works with 8ch RX and TX (see attached sdma_sai_log_8ch_ok.txt
    We can see how RX sdma channel 4 is configured. Then RX starts receiving samples. Then Tx channel starts. The first fifo is being filled by SAI and emptied by sDMA. Its pointers are being updated in RFR0. And finally, sDMA handles the stream.

  • ok now, let's see when it fails with 9ch RX and TX (see attached sdma_sai_log_9ch_ko.txt) :
    RX stops immediatly when TX starts.

I have tried to tweak imx-sdma.c code to have the same behaviour as 4.19 version, reordering the configuration sequence. But I cannot find what's missing. sDMA registers seem to be identical.

Why is the sdma behaviour different with more than 8 channels ? Has anyone tested it with kernel 5.4 ?

thanks

Labels (1)
0 Kudos
4 Replies

1,176 Views
antho
Contributor III

Hi ceggers,

Thank you for your concern.

I have found the problem :
the sdma is actually well configured, but its clock rate is too low ! So it cannot achieve all the programmed audio SAI data transfers within the same amount of time (compared to kernel 4.19 implementation).

Between kernels 4.19 and 5.4, audio clocks configuration has been changed (why... ? t_t).
Here in drivers/clk/imx/clk-imx8mm.c :
- clk_set_parent(clks[IMX8MM_CLK_AUDIO_AHB], clks[IMX8MM_SYS_PLL1_800M]);
- clk_set_rate(clks[IMX8MM_CLK_AUDIO_AHB], 800000000);
- clk_set_rate(clks[IMX8MM_CLK_IPG_AUDIO_ROOT], 800000000);

Once reverted, the sdma SAI transfer works fine again, and can reach full speed !

949 Views
davidzielinski
Contributor I
Thanks a lot for posting this! Save me a lot of time. I have 2 SAI instances with single data line each, 16 channels/data line (32 total). One instance of SAI would work, but as soon as second one started, audio flow would stop on the the first. Neither would work.

Is 400 Mhz the target of that clock? See commit 8bd08b0e2540c6da0efd7b103f8c1acabdc0051e. 4.19 showed 400 Mhz too AFAIK.

Didn't see anything upstream yet that fixes this. I suspect that in the process of adopting the "composite" clock objects to simplify the clock tree, this fell through the cracks.
0 Kudos

1,171 Views
ceggers1
Contributor IV

Hi antho,

thanks for the update!

Christian

0 Kudos

1,280 Views
ceggers
Contributor V

Hi antho,

I assume that you use the same SDMA firmware with both kernels.

Please compare ```struct sdma_script_start_addrs``` between both kernel versions. That struct has been changed in an incompatible way several times in the past.

regards,
Christian

Tags (1)
0 Kudos