I am enabling an uart device that is attached to UART6 on Linux 5.4.70. But long packet(250 bytes) cannot be received completely sometimes, the serdev receiver callback found it is called when there are 1 bytes ready, tens of bytes ready, more than 100 bytes ready. Sometimes I can see serdev receiver callback is called for a complete packet ready, not for most of times.
So I am trying to enable SDMA to have a check. But I see 1024 bytes are received for 4 times in very short time as below, while UART is in 9600 rate. I see similiar issue in below link [a] and new sdma firmware is suggested. I have tried 2 version firmware from branch master and nxp_mc in link [b], but there is no difference for this issue.
DTS file for machine is in bottom.
Question 1: Any suggestion for data missing bug non-DMA mode?
Question 2: What firmware shall I use?
[ 300.163808] imx_uart_startup: (port)->cons->index 0 (port)->line 5
[ 300.163861] imx-sdma 30bd0000.sdma: Allocing channel..
[ 300.163873] imx-sdma 30bd0000.sdma: Allocing channel with pri 3, ret 0
[ 300.163898] imx-sdma 30bd0000.sdma: Allocing channel..
[ 300.163908] imx-sdma 30bd0000.sdma: Allocing channel with pri 3, ret 0
[ 300.163969] imx-uart 30a80000.serial: RX: prepare for the DMA.
[ 300.164017] imx-uart 30a80000.serial: We get 1024 bytes.
[ 300.164037] imx-uart 30a80000.serial: We get 1024 bytes.
[ 300.164054] imx-uart 30a80000.serial: We get 1024 bytes.
[ 300.164072] imx-uart 30a80000.serial: We get 1024 bytes.
assigned-clocks = <&clks IMX7D_UART6_ROOT_SRC>;
assigned-clock-parents = <&clks IMX7D_OSC_24M_CLK>;
status = "okay";
/* compatible and pinctrl */
Solved! Go to Solution.
it may be recommended to use CTS/RTS hardware flow control for DMA mode.
For me (and probably others), the main reason for using (S)DMA is not requiring hardware flow control. DMA usually offers much shorter latencies than interrupts (serviced by the CPU, probably running a non-realtime OS).
It is not reasonable to receive so much data in less than 1ms, even without hardware flow control. Is this a known bug to introduce this issue? Because the log in the link of previous post shows the identical issue. Where can I find latest firmware?
Please post the full uart6 section(s) of your device tree (and of the .dtsi files you have included). I would like to check whether you SDMA channels and events are assigned correctly.
perhaps the problem concerns the fact, that SDMA provides bursts for data
transfer. If data buffer length is not multiple of burst length some data will
wait the next burst.
It is 4 * 1024 bytes received in less than 100us with 9600 baudrate and DMA is just enabled. Even the burst size is 1024, it takes 2.56 seconds to receive 3*1024 bytes. So the only conclusion is that SDMA is not working as expected.
The WiFi bug in below link also show the identical issue, which is resolved with new UART SDMA firmware. So please help point out where is the latest SDMA firmware. Thanks!
the SDMA firmware under
is version 3.3. In the linux-firmware repository, you can find version 3.5:
although your problems seems to be solved, I made some investigations on this because ...
I compared different version of the i.MX7 SDMA firmware and probably found out the reason for your problem:
If my explanation doesn't fit, I've a second one:
The format of the SDMA firmware header has been changed in a incompatible way for several times (e.g. , , , ...). So it's likely that you installed a combination of SDMA firmware and Linux kernel where the layout of struct sdma_script_start_addrs does not match.
The UART SDMA routines itself never changed between the different versions of the SDMA firmware.
Have a nice weekend