• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 1421 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

Linux/AM3359: am335x linux uart dma not working

Linux/AM3359: Data lost when am335x's uart working at baudrate 3686400

user4248043
Prodigy 210 points
Part Number: AM3359

Tool/software: Linux

Hi,

  I have two customized board, both have few changes made from 'am335x-boneblack'.

  I need to send data from one board to another, via one uart port, at baudrate 3686400.

  According to the manual, the baudrate 3686400 is the highest one it support.

 

  Two boards running with the same software version:

  ti-processor-sdk-linux-am335x-evm-05.02.00.10, the original kernel version is 4.14.79, later I updated it to the newest one from github, which kernel version  is 4.14.97.

  Then,  sending 2MBytes from one board to another one, via uart4 (on both sides).

  If receiving without DMA, 400Bytes ~ 10KBytes will lost.

  If receiving with DMA, 0 ~ 10KBytes of the 2MBytes will lost.

  It looks like the DMA can't improve the reliability of uart when it working at 3686400.

  By instructions "cat /proc/interrupts | grep dma" and "cat /proc/interrupts | serial", I can tell how many interrupts raised in the whole test duration.

  If receiving without DMA, there are about 18000 times of serial interrupts raised, no DMA interrupt.

  If receiving with DMA, there are about 35000 times of serial interrupts and 35000 times of dma interrupts raised.

  It looks like am335x will get heavier load without extra repay when the uart dma is enabled.

  So, do you have any test results about the uart of am335x when it working at baudrate 3686400?

  Can you explain the raised interrupts load when uart dma is enabled?

Best Regards,

  • 0
    TI__Guru**** 168721 points
    Hi, did you enable hw flow control for UART4 on both boards?
  • 0 in reply to Bin Liu
    Prodigy 210 points

    Not yet, hw rts/cts not connected.

  • 0 in reply to user4248043
    TI__Guru**** 168721 points
    The UART itself supports up to 3.6Mbps baud rate, but you might need to enable hw flow control to ensure there is no RX data lost.
  • 0 in reply to Bin Liu
    Prodigy 210 points
    And how about the interrupt number, why there are much more interrupts when dma is enabled?
  • 0 in reply to user4248043
    TI__Guru**** 168721 points
    Can you please provide the output of command "grep serial /proc/interrupts"? You may not look at the interrupt for UART4.
  • 0 in reply to Bin Liu
    Prodigy 210 points

    The hardware boards are already there, I have to enable uart dma to figure out if the new requirement of baudrate 3686400 could be implemented or not. So, I can't add HW flow control.

    Actually, I made the test with UART5, which interrupt number is 46.  The DMA is enabled or disabled by editting dts file.

    This is the screenshot when UART5 receiving without DMA. You can see that the serial interrupt raised about 30000 times, but DMA interrupt almost keep still.

    This is the screenshot when UART5 receiving with DMA. You can see serial interrupt raised 44000 times, more than that of the case without DMA. Also 43000 times of DMA interrupts were raised.

    That is why I said "More load with few repay".

    The two cases run with the same u-boot, same kernel, same send/receive program, but different dtb file (one enabled dma for uart5, another one disable it).

    During the test, all printk (I added in kernel) and dma log were disabled.

  • 0 in reply to user4248043
    Prodigy 210 points

    From the upper screenshots, you will see that uart receiving with dma has more interrupts raised than that without dma.

    I added some printk in 8250_omap.c to check and identify the interrupt numbers and types, I have some findouts.

    1. Receiving without DMA. Total 32725 serial interrupts consist of:

    3803 times of cc (IIR = 0xcc, Rx Timeout),

    54 times of c6 (IIR = 0xc6, Receive Line Status Error),

    28842 times of c4 (IIR = 0xc4, RHR),

    26 times of IT_PENDING (IIR & IT_PENDING = 1, no interrupt is pending).

    2. Receiving without DMA. Total 49179 serial interrupts consist of:

    4433 times of cc (IIR = 0xcc, Rx Timeout),

    28 times of c6 (IIR = 0xc6, Receive Line Status Error),

    8 times of c4 (IIR = 0xc4, RHR),

    44710 times of IT_PENDING (IIR & IT_PENDING = 1, no interrupt is pending).

     By enable DMA, the interrupt 'c4' cut down a lot, it indicates DMA does really work.

     The print 'xx' means "IIR & IT_PENDING = 1", it indicates no interrupt pending.

     Enter into ISR handler, found there was no interrupt. ISR in "8250_omap.c" did nothing but returned.

     But why there are so much interrupts with ''IT_PENDING = 1" when dma is enabled.

     These huge numbers of interrupts will give the system (am335x+linux) heavier load although nothing to be done in ISR. It will cancel the advantages of dma.

    Best Regards,

  • 0 in reply to user4248043
    Prodigy 210 points
    Sorry, the upper post case 2 need to be modified to '2. Receiving with DMA. Total 49179 serial interrupts consist of:'.
  • 0 in reply to user4248043
    TI__Guru**** 168721 points

    user4248043 said:
    The hardware boards are already there, I have to enable uart dma to figure out if the new requirement of baudrate 3686400 could be implemented or not. So, I can't add HW flow control.

    It is almost impossible to avoid rx data loss if HW flow control is not enabled.

  • 0 in reply to Bin Liu
    Prodigy 210 points

    But how about the interrupts, why are there so many interrupts with iir.it_pending=1 when dma is enable ?

  • 0 in reply to user4248043
    TI__Guru**** 168721 points

    Hi,

    That may be caused by the hardware of the UART controller but no software solution. The problem is not only on AM335x UART, it seems also happens on other vendor's UART. Please check the following discussion.

    lkml.org/.../588