Uarta 3100000 dma mode

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
,
1

We found that UART A experiences data loss in loopback mode when the baud rate reaches 921600 without using hardware flow control (RTS/CTS). Therefore, I want to switch it to DMA mode instead of PIO. However, according to the article below,

UARTA DMA - Not enabled by default and doesn’t work in JP6 - Jetson Systems / Jetson Orin Nano - NVIDIA Developer Forums

Configure DMA with uarte(HSUART) on Jetson Orin with JetPack 6.2 - Jetson Systems / Jetson AGX Orin - NVIDIA Developer Forums

after I made the modification, DMA reported errors. I am using an Orin Industry custom board （jetpack 6.0). Could you please take a look? Thank you.

(base) root@tegra-ubuntu:/dev# dmesg | grep -E "3100000.*DMA"
[  139.068513] serial-tegra 3100000.serial: DMA channel alloc failed: -19
[  141.068037] serial-tegra 3100000.serial: DMA channel alloc failed: -19
4

I have modified the DMA phandle again, and now it no longer reports -19. However, I still don’t see any DMA allocation messages in dmesg, and no data is being received.

                uarta: serial@3100000 {
                        compatible = "nvidia,tegra234-uart", "nvidia,tegra20-uart";
                        reg = <0x0 0x03100000 0x0 0x10000>;
                        interrupts = <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH>;
                        clocks = <&bpmp TEGRA234_CLK_UARTA>;
                        resets = <&bpmp TEGRA234_RESET_UARTA>;
                        dmas = <0xe0 0x14 0xe0 0x14>;
                        dma-names = "rx", "tx";
                        iommus = <0x04 0x04>;
                        status = "disabled";
                };

tegra234-p3737-0000+p3701-0008-nv.dts.txt (310.6 KB)

dmesg.txt (63.5 KB)

5

Hi wpceswpces,

Could you also verify with the latest Jetpack 6.2.2 and specify the missing iommus property for DMA-based UART?

[    6.498454] serial-tegra 3100000.serial: Adding to iommu group 4
[    6.498539] 3100000.serial: ttyTHS1 at MMIO 0x3100000 (irq = 112, base_baud = 0) is a TEGRA_UART

From the dmesg you shared, it seems UART-A has been configured as DMA mode as there’s no PIO related message.

When you want to perform UART transaction with higher baudrate, enabling HW flow control is required for data intergrity.

6

Hi,KevinFFF

Upgrading to 6.2.2 seems to take a lot of time on a custom board. Didn’t you verify it on 6.0 before, or is there a specific part that’s not supported? We haven’t brought out hardware flow control, as we are using UART converted to RS-422, and there are no flow control signals on the other side.

7

Hi,KevinFFF

Also, in this thread, you mentioned that UART A was tested and working properly on the Nano. That was with Jetpack 6.0, so it seems that the issue is not related to 6.0.

UARTA DMA - Not enabled by default and doesn’t work in JP6 - Jetson Systems / Jetson Orin Nano - NVIDIA Developer Forums

8

Before Jetpack 6.2.2(r36.5), UART-A is working in PIO mode by default.
Is there any requirement you need to run it in DMA mode?
I suggest verifying the latest Jetpack release is to confirm that we are in the same page.

It seems you have wrong configuration for dma property for UART-A.
Please configure dmas = <0xed 0x8 0xed 0x8>; instead.

9

Hi,KevinFFF

I modified the device tree as dmas = <0xed 0x8 0xed 0x8>;, but I still cannot receive any data when performing a loopback test. Here are the updated device tree and the dmesg output. I didn’t find any abnormal error messages. Could you please advise how I can check the detailed DMA channel allocation and data transfer status for further analysis?

dmesg.new.txt (82.6 KB)

tegra234-p3737-0000+p3701-0008-nv.dts.txt (310.6 KB)

I only used the FDT to update the device tree under the kernel. The hardware flow control signals CTS and RTS are not physically routed. That shouldn’t affect DMA triggering, right? There is data available in PIO mode.

root@tegra-ubuntu:/mnt/rootfs# xxd /sys/firmware/devicetree/base/bus@0/serial@3100000/dmas
00000000: 0000 00e0 0000 0014 0000 00e0 0000 0014  ................
root@tegra-ubuntu:/mnt/rootfs#
root@tegra-ubuntu:/mnt/rootfs#
root@tegra-ubuntu:/mnt/rootfs#
root@tegra-ubuntu:/mnt/rootfs# dmesg | grep -i "dma pause\|gpcdma\|3100000"
[    6.559982] tegra-gpcdma 2600000.dma-controller: Adding to iommu group 4
[    6.560925] tegra-gpcdma 2600000.dma-controller: GPC DMA driver register 31 channels
[    6.561919] serial-tegra 3100000.serial: Adding to iommu group 4
[    6.561968] 3100000.serial: ttyTHS1 at MMIO 0x3100000 (irq = 112, base_baud = 0) is a TEGRA_UART
[   56.682634] tegra-gpcdma 2600000.dma-controller: DMA pause timed out
[  109.539525] tegra-gpcdma 2600000.dma-controller: DMA pause timed out

Does “DMA pause timed out” indicate a problem?

However, I seem to be able to receive data using this method:

root@tegra-ubuntu:/mnt/rootfs# stty -F /dev/ttyTHS1 921600 raw -echo
cat /dev/ttyTHS1 > /tmp/rx_out &
echo -n "ABCD" > /dev/ttyTHS1
sleep 1
kill %1
xxd /tmp/rx_out
[1] 1781
00000000: 4142 4344                                ABCD
[1]+  Terminated              cat /dev/ttyTHS1 > /tmp/rx_out
root@tegra-ubuntu:/mnt/rootfs#

But when I open two terminals—one in the foreground to cat and the other to echo—no data is received.

I also cannot receive data when sending it through a program.

root@tegra-ubuntu:/mnt/rootfs# cat /sys/kernel/debug/dmaengine/summary
dma0 (2600000.dma-controller): number of channels: 31
 dma0chan0    | 3210000.spi:rx
 dma0chan1    | 3210000.spi:tx
 dma0chan2    | 3230000.spi:rx
 dma0chan3    | 3230000.spi:tx
 dma0chan4    | 3160000.i2c:rx
 dma0chan5    | 3160000.i2c:tx
 dma0chan6    | 3180000.i2c:rx
 dma0chan7    | 3180000.i2c:tx
 dma0chan8    | 3190000.i2c:rx
 dma0chan9    | 3190000.i2c:tx
 dma0chan10   | 31b0000.i2c:rx
 dma0chan11   | 31b0000.i2c:tx
 dma0chan12   | 31c0000.i2c:rx
 dma0chan13   | 31c0000.i2c:tx
 dma0chan14   | 31e0000.i2c:rx
 dma0chan15   | 31e0000.i2c:tx
 dma0chan16   | c240000.i2c:rx
 dma0chan17   | c240000.i2c:tx
 dma0chan18   | c250000.i2c:rx
 dma0chan19   | c250000.i2c:tx

dma1 (2930000.dma-controller): number of channels: 32
root@tegra-ubuntu:/mnt/rootfs#

The DMA channels are visible when the serial port is opened.

root@tegra-ubuntu:~# cat /sys/kernel/debug/dmaengine/summary
dma0 (2600000.dma-controller): number of channels: 31
 dma0chan0    | 3210000.spi:rx
 dma0chan1    | 3210000.spi:tx
 dma0chan2    | 3230000.spi:rx
 dma0chan3    | 3230000.spi:tx
 dma0chan4    | 3160000.i2c:rx
 dma0chan5    | 3160000.i2c:tx
 dma0chan6    | 3180000.i2c:rx
 dma0chan7    | 3180000.i2c:tx
 dma0chan8    | 3190000.i2c:rx
 dma0chan9    | 3190000.i2c:tx
 dma0chan10   | 31b0000.i2c:rx
 dma0chan11   | 31b0000.i2c:tx
 dma0chan12   | 31c0000.i2c:rx
 dma0chan13   | 31c0000.i2c:tx
 dma0chan14   | 31e0000.i2c:rx
 dma0chan15   | 31e0000.i2c:tx
 dma0chan16   | c240000.i2c:rx
 dma0chan17   | c240000.i2c:tx
 dma0chan18   | c250000.i2c:rx
 dma0chan19   | c250000.i2c:tx
 dma0chan20   | 3100000.serial:tx
 dma0chan21   | 3100000.serial:rx

dma1 (2930000.dma-controller): number of channels: 32
root@tegra-ubuntu:~# dmesg | tail -10
[ 1085.306871] mttcan_controller_config: ctrlmode 0
[ 1085.306900] mttcan c310000.mttcan can0: Bitrate set
[ 1085.307917] mttcan_controller_config: ctrlmode 0
[ 1085.307939] mttcan c320000.mttcan can1: Bitrate set
[ 1085.309279] mttcan c310000.mttcan can0: Bitrate set
[ 1085.309592] mttcan_controller_config: ctrlmode 0
[ 1085.309612] mttcan c310000.mttcan can0: Bitrate set
[ 1085.310855] mttcan c320000.mttcan can1: Bitrate set
[ 1085.311052] mttcan_controller_config: ctrlmode 0
[ 1085.311071] mttcan c320000.mttcan can1: Bitrate set


root@tegra-ubuntu:~# dmesg | grep -i "smmu\|context fault\|iommu.*fault"
[    0.102580] iommu: Default domain type: Translated
[    0.209140] arm-smmu 8000000.iommu: probing hardware configuration...
[    0.209146] arm-smmu 8000000.iommu: SMMUv2 with:
[    0.209153] arm-smmu 8000000.iommu:  stage 1 translation
[    0.209155] arm-smmu 8000000.iommu:  stage 2 translation
[    0.209159] arm-smmu 8000000.iommu:  nested translation
[    0.209166] arm-smmu 8000000.iommu:  stream matching with 128 register groups
[    0.209170] arm-smmu 8000000.iommu:  128 context banks (0 stage-2 only)
[    0.209185] arm-smmu 8000000.iommu:  Supported page sizes: 0x61311000
[    0.209187] arm-smmu 8000000.iommu:  Stage-1: 48-bit VA -> 48-bit IPA
[    0.209188] arm-smmu 8000000.iommu:  Stage-2: 48-bit IPA -> 48-bit PA
[    0.210180] arm-smmu 10000000.iommu: probing hardware configuration...
[    0.210184] arm-smmu 10000000.iommu: SMMUv2 with:
[    0.210188] arm-smmu 10000000.iommu:         stage 1 translation
[    0.210192] arm-smmu 10000000.iommu:         stage 2 translation
[    0.210192] arm-smmu 10000000.iommu:         nested translation
[    0.210196] arm-smmu 10000000.iommu:         stream matching with 128 register groups
[    0.210202] arm-smmu 10000000.iommu:         128 context banks (0 stage-2 only)
[    0.210216] arm-smmu 10000000.iommu:         Supported page sizes: 0x61311000
[    0.210217] arm-smmu 10000000.iommu:         Stage-1: 48-bit VA -> 48-bit IPA
[    0.210218] arm-smmu 10000000.iommu:         Stage-2: 48-bit IPA -> 48-bit PA
[    0.210587] arm-smmu 12000000.iommu: probing hardware configuration...
[    0.210590] arm-smmu 12000000.iommu: SMMUv2 with:
[    0.210592] arm-smmu 12000000.iommu:         stage 1 translation
[    0.210592] arm-smmu 12000000.iommu:         stage 2 translation
[    0.210594] arm-smmu 12000000.iommu:         nested translation
[    0.210596] arm-smmu 12000000.iommu:         stream matching with 128 register groups
[    0.210600] arm-smmu 12000000.iommu:         128 context banks (0 stage-2 only)
[    0.210604] arm-smmu 12000000.iommu:         Supported page sizes: 0x61311000
[    0.210605] arm-smmu 12000000.iommu:         Stage-1: 48-bit VA -> 48-bit IPA
[    0.210606] arm-smmu 12000000.iommu:         Stage-2: 48-bit IPA -> 48-bit PA
[   25.658774] pva_iommu_context_dev 16000000.pva0:pva0_niso1_ctx0: initialized (streamid=18, iommu=smmu.0x0000000008000000)
[   25.685303] pva_iommu_context_dev 16000000.pva0:pva0_niso1_ctx1: initialized (streamid=19, iommu=smmu.0x0000000008000000)
[   25.709824] pva_iommu_context_dev 16000000.pva0:pva0_niso1_ctx2: initialized (streamid=20, iommu=smmu.0x0000000008000000)
[   25.730617] pva_iommu_context_dev 16000000.pva0:pva0_niso1_ctx3: initialized (streamid=21, iommu=smmu.0x0000000008000000)
[   25.734633] pva_iommu_context_dev 16000000.pva0:pva0_niso1_ctx4: initialized (streamid=22, iommu=smmu.0x0000000008000000)
[   25.751408] pva_iommu_context_dev 16000000.pva0:pva0_niso1_ctx5: initialized (streamid=23, iommu=smmu.0x0000000008000000)
[   25.776637] pva_iommu_context_dev 16000000.pva0:pva0_niso1_ctx6: initialized (streamid=24, iommu=smmu.0x0000000008000000)
[   25.796714] pva_iommu_context_dev 16000000.pva0:pva0_niso1_ctx7: initialized (streamid=25, iommu=smmu.0x0000000008000000)
10

Hi,KewinFFF

I’d like to update you on my latest test results. I found that under DMA, if I send a relatively short number of bytes, the data can be received. However, when sending data beyond a certain length, it fails to be received. Moreover, once a long data transfer fails, even subsequent short transfers cannot be received. I noticed in the source code that there might be logic where short byte transfers still use PIO mode. Could you please help analyze this in more detail? Thank you.

define TEGRA_UART_MIN_DMA 16

 static void tegra_uart_start_next_tx(struct tegra_uart_port *tup)
{
        unsigned long tail;
        unsigned long count;
        struct circ_buf *xmit = &tup->uport.state->xmit;

        if (!tup->current_baud)
                return;

        tail = (unsigned long)&xmit->buf[xmit->tail];
        count = CIRC_CNT_TO_END(xmit->head, xmit->tail, UART_XMIT_SIZE);
        if (!count)
                return;

        if (tup->use_tx_pio || count < TEGRA_UART_MIN_DMA)
                tegra_uart_start_pio_tx(tup, count);
        else if (BYTES_TO_ALIGN(tail) > 0)
                tegra_uart_start_pio_tx(tup, BYTES_TO_ALIGN(tail)); 
        else
                tegra_uart_start_tx_dma(tup, count);
}

one terminal

root@tegra-ubuntu:/mnt/rootfs# stty -F /dev/ttyTHS1 raw -echo
root@tegra-ubuntu:/mnt/rootfs# cat /dev/ttyTHS1
e
e1
e2
e3
e4
e4
e4
e4
e4
e4
e4
e4
e43
e43
e43
e43
e43
e43
e43
e43
e43
e43
kerwq3
kerwq3
kerwq3
kerwq3
kerwq3
kerwq3

the other:

root@tegra-ubuntu:~# echo e > /dev/ttyTHS1
root@tegra-ubuntu:~# echo 123 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo 123456 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo 123456789 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo 1234567 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo 123456 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e1 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e2 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e3 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e4 > /dev/ttyTHS1
root@tegra-ubuntu:~#
root@tegra-ubuntu:~# echo e4 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e4 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e4 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e4 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e4 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e4 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e4 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo kerwq3 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo kerwq3 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo kerwq3 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo kerwq3 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo kerwq3 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo kerwq3 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo kerwq3dwer > /dev/ttyTHS1
root@tegra-ubuntu:~# echo kedwer > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e43 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e4 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e4 > /dev/ttyTHS1
root@tegra-ubuntu:~# echo e4 > /dev/ttyTHS1
root@tegra-ubuntu:~#

dmesg:

root@tegra-ubuntu:~# dmesg |grep DMA
[    0.000000]   DMA      [mem 0x0000000080000000-0x00000000ffffffff]
[    0.000000]   DMA32    empty
[    0.069773] DMA: preallocated 8192 KiB GFP_KERNEL pool for atomic allocations
[    0.070192] DMA: preallocated 8192 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.070597] DMA: preallocated 8192 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[    0.102584] iommu: DMA domain TLB invalidation policy: strict mode
[    4.961754] tegra-gpcdma 2600000.dma-controller: GPC DMA driver register 31 channels
[    5.053177] mmc0: SDHCI controller on 3460000.mmc [3460000.mmc] using ADMA 64-bit
[    5.741591] mmc1: SDHCI controller on 3400000.mmc [3400000.mmc] using ADMA 64-bit
[   25.033926] xdma:xdma_mod_init: Xilinx XDMA Reference Driver xdma v2020.2.2
[   26.232297] nvethernet 2310000.ethernet: setting to default DMA bit mask
[   26.545798] nvethernet 2310000.ethernet: eth0 (HW ver: 53) created with 8 DMA channels
[   27.300467] tegra-adma 2930000.dma-controller: Tegra210 ADMA driver registered 32 channels
[  222.178329] tegra-gpcdma 2600000.dma-controller: DMA pause timed out
[  293.585066] tegra-gpcdma 2600000.dma-controller: DMA pause timed out
[  626.242169] tegra-gpcdma 2600000.dma-controller: DMA pause timed out
[  691.170564] tegra-gpcdma 2600000.dma-controller: DMA pause timed out
[  794.484776] tegra-gpcdma 2600000.dma-controller: DMA pause timed out
[ 1449.310201] tegra-gpcdma 2600000.dma-controller: DMA pause timed out
[ 1529.054681] tegra-gpcdma 2600000.dma-controller: DMA pause timed out
[ 1919.756239] tegra-gpcdma 2600000.dma-controller: DMA pause timed out
[ 2434.265293] tegra-gpcdma 2600000.dma-controller: DMA pause timed out
root@tegra-ubuntu:~#
11

You need to send longer data in one transfer so that it will work in DMA mode.
Please check if the transaction is successful if you disconnect the TX/RX from loopback.

Please also get a scope to check from signal.

As I mentioned above, it is still working in PIO mode if you send the data with short length.

It is not the expected result to me. It seems you didn’t update device tree successfully.
Could you run the following command on your board and share extracted_proc.dts for further check?

$ sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree
12

Hello,KevinFFF

extracted_proc.dts.txt (312.0 KB)

This is the device tree I exported from the device. Could you please take a look? Thank you.

13 
		serial@3100000 {
			iommus = <0x04 0x04>;
			resets = <0x03 0x64>;
			interrupts = <0x00 0x70 0x04>;
			clocks = <0x03 0x9b>;
			dma-names = "rx\0tx";
			compatible = "nvidia,tegra194-hsuart";
			status = "okay";
			reg = <0x00 0x3100000 0x00 0x10000>;
			phandle = <0x203>;
			dmas = <0xe0 0x14 0xe0 0x14>;
			reset-names = "serial";
		};

From the extracted device tree file, it is still dmas = <0xe0 0x14 0xe0 0x14>; which is not the expected result.

How do you apply the change for device tree?

Maybe you can check if FDT is specified in /boot/extlinux/extlinux.conf and decompile /boot/dtb/kernel_XXX.dtb to check the configuration inside.

14

Hi,KevinFFF

I just made some changes to the DTB on the device again and tried it out. Just like I mentioned at the very beginning of this thread, with this configuration, I encounter the “DMA channel alloc failed” issue.

dmesg_0417.txt (77.4 KB)

extracted_proc.dts.txt (312.0 KB)

root@tegra-ubuntu:/mnt/rootfs# dmesg |grep 3100000
[    6.551404] serial-tegra 3100000.serial: Adding to iommu group 4
[    6.551537] 3100000.serial: ttyTHS1 at MMIO 0x3100000 (irq = 112, base_baud = 0) is a TEGRA_UART
[   23.215453] OF: /bus@0/serial@3100000: could not get #dma-cells for /bus@0/typec@8/connector@1/ports/port@1/endpoint
[   23.215486] serial-tegra 3100000.serial: DMA channel alloc failed: -19
[   23.215490] serial-tegra 3100000.serial: Tx Dma allocation failed, err = -19
[  153.663729] OF: /bus@0/serial@3100000: could not get #dma-cells for /bus@0/typec@8/connector@1/ports/port@1/endpoint
[  153.663764] serial-tegra 3100000.serial: DMA channel alloc failed: -19
[  153.663767] serial-tegra 3100000.serial: Tx Dma allocation failed, err = -19
15

For AGX Orin, it should be dmas = <0xee 0x08 0xee 0x08>; as following:

                serial@3100000 {
                        iommus = <0x04 0x04>;
                        resets = <0x03 0x64>;
                        interrupts = <0x00 0x70 0x04>;
                        clocks = <0x03 0x9b>;
                        dma-names = "rx\0tx";
                        compatible = "nvidia,tegra194-hsuart";
                        status = "okay";
                        reg = <0x00 0x3100000 0x00 0x10000>;
                        phandle = <0x230>;
                        dmas = <0xee 0x08 0xee 0x08>;
                        reset-names = "serial";
                };

Please update and give it another try.

16

Hi,KevinFFF

After I made the changes on my side, the situation remains the same. Attached are the corresponding dmesg logs and the device tree exported from the board. The DMA channel allocation still fails. I also noticed that the phandle of the @3100000 node in my device tree does not match the one you sent, Mine is 0x203, and yours is 0x230. This shouldn’t matter, it seems. but I am not sure if this is the reason why the DMA channel allocation fails and why the serial port cannot be opened properly. I am using JetPack 6.0.

dmesg.txt (63.2 KB)

extracted_proc.dts.txt (312.0 KB)

18 
[  432.843872] OF: /bus@0/serial@3100000: could not get #dma-cells for /bus@0/padctl@3520000
[  432.843901] serial-tegra 3100000.serial: DMA channel alloc failed: -19
[  432.843904] serial-tegra 3100000.serial: Tx Dma allocation failed, err = -19
[  595.189018] OF: /bus@0/serial@3100000: could not get #dma-cells for /bus@0/padctl@3520000
[  595.189046] serial-tegra 3100000.serial: DMA channel alloc failed: -19
[  595.189049] serial-tegra 3100000.serial: Tx Dma allocation failed, err = -19

Yes, it seems DMA allocation failed in your case.

Could you simply update to the latest Jetpack 6.2.2(r36.5) to verify if there’s the similar issue?

19

Hi,KevinFFF

Yes, I have tried updating to version 36.5 and found, as you mentioned, that DMA mode is the default, and it is indeed possible to receive data in loopback. I noticed that between versions 36.3 and 36.5, the UART driver underwent significant changes. Since we have been using 36.3 for a long time, we would prefer to switch modes based on the original version, as this would minimize modifications and have the least impact on other interfaces. Therefore, please confirm whether version 36.3 can properly support DMA for UARTA. Thank you again.

20

Could you download the kernel source of R36.5 and apply the following 2 changes to your R36.3?

1. drivers/tty/serial/serial-tegra.c:
NVIDIA: SAUCE: tty/serial: serial-tegra: DMA improvements

2. drivers/dma/tegra186-gpc-dma.c:
dmaengine: tegra186: Fix residual calculation
21

There are many changes, and the kernel versions are also different. I’m worried that directly syncing the code might introduce unpredictable issues that would be harder to debug. I want to know if you’ve tested whether the DMA for UARTA on your R36.3 works correctly.

22

In R36.3, the UART-A works in PIO mode by default.
Those 2 changes might help for your case but please note that we don’t verify it locally.

If you want to use the release which we have verified the UART-A with DMA, please update to the R36.5 release.

23

However, the two change files you mentioned above seem to be aimed at performance improvements and minor bug fixes. Right now, I am unable to successfully allocate any channels in alloc.In short, it seems that the DMA in R36.3 is not working properly. Can I understand it this way, since it hasn’t been officially validated.