AM335X use uart dma and HW FIFO

processor AM3359

frequency is 720M

Appreciate your help and look forward to your reply

Hi yi li2,

May I ask why you prefer to use UART?  Did you consider using the McASP interface?

What type of audio device are you using? What types of data do you plan to send?  (all audio?)

I'm not sure why you are losing characters.

There is a way to enable the DMA for the omap-serial.c driver, but you still need to set up the EDMA yourself. 

You can enable the DMA for the serial driver in the file; $(KERNEL_ROOT_DIR)/arch/arm/mach-omap2/serial.c 

in struct omap_uart_port_info you can change .dma_enabled = false to .dma_enabled = true

hi,

    thanks for your reply, we 've tried UART DMA before by  change .dma_enabled = false to .dma_enabled = true,and it happens another errors. and we 'll try to enable the UART DMA later.

   we use uart to connect another special device to transfer sample data. it seems ok when the kernel is not busy. but when playing sound or plug in/out usb keyboard, we can test that the uart missing some characters

   another question. is the OMAP335x driver use UART HW FIFO to receive characters?

by the way, the link  https://e2e.ti.com/support/arm/sitara_arm/int_sitara_am335x/f/425/t/280396.aspx  can't connect, it shows 

Is there anyone looking at this question?

Hi yi li2,

Sorry the link I posted was an internal link only.  It was showing some difficulties using DMA with UART.

To answer your question: There are HW fifos for both send and receive,  Please see the AM335x TRM

Figure 19-3. UART/IrDA/CIR Functional Specification Block Diagram

hi Jeff L 

    thanks for your help.

   We've tested the uart driver again, it seems that when missing characters, the FIFO have received over max characters. we add codes in serial_omap_irq, to print "over run!" when lsr is UART_LSR_OE, unfortunately we got so many "over run!", so we can be sure that some overrun err occurs.

  We've also tested that the uart driver have already used HW FIFO to receive chars, by the trig level of 16 characters, we've changed the trig level to 56 60 characters, but the question still exist.

 you say that " It was showing some difficulties using DMA with UART." Does use DMA to receive uart can realize?

we are using UART4 to receive characters

Jeff or anyone else in TI:

Any further information on "It was showing some difficulties using DMA with UART" for that internal document?  Is this referring to problems with the driver or the chip?

I've attempted to enable DMA support with the UARTs, but the driver seems to have lots of problems with that.  Panics when enabled, unable to get the necessary DMA channels due to a conflict, attempts to use EDMA functions which the OMAP DMA wrapper indicate are not supported,...

I've worked through each of these problems, but I'd like to know the details of what sort of "difficulties" are known before continuing.

Thanks,

    Steve

Steve,

We have not looked into making the omap_serial.c TI Uart driver support EDMA since it is coupled with the TTY layer which works 1 byte at a time.  However another customer recentley used this example: http://processors.wiki.ti.com/index.php/EDMA_sample_test_application which is a memory to memory EDMA example and they adapted it to support EDMA + UART.  Their application was only half duplex, but this may be a good reference for you.  I'm giving you an early copy util I can go through it and put in with our wiki documentation. I hope it can help you:

https://dl.dropboxusercontent.com/u/30582490/edma-test.c

appreciate your help, I'll try it later

Hi Jeff.

For what it is worth, the UART is operating on more than 1 byte at a time.  That might be what you see when using the console.  However, I'm using a program to write 2048 bytes at a time to the tty.  The routine serial_omap_start_tx() sees all 2048 bytes pending on its next invocation.

Regards,

    Steve

Hi yi li2,

I face exactly same problem. Did you find solution? Please let me know.

Regards,

Gangadhar

Hi Folks,

we don't have a real solution until now,

as we have the other side under control, we use retransmits now.

I also see this behaviour with lower baudrates when the kernel is under heavy load.

Maybe TI can look into implementing EDMA for the omap-serial.c as we see that there are many customers with the same problem.
I would also help with that but I neither have experience with the EDMA nor with the Linux-Serial Stack to dig deep enough into this issue in time.

Regards Pascal

Gangadhar,

You can try out the 8250 UART driver by following instructions here:

http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_UART_-_Switching_to_8250_Driver

However, you will need to use the kernel (3.14.26) that is a part of AMSDK 8.0.

The new 8250 driver includes several features that are extremely useful for some users right now. The biggest new feature is support for DMA when using UART which significantly increases throughput and reliability while at the same time significantly decreasing CPU load. If you will be transferring alot of data via UART at a very high baud rate then it is recommend to use the 8250 driver.

There are a variety of issues with the current omap_serial driver that prevented adding DMA support. Increasing the FIFO trigger point really doesn’t solve the problem and there is a silicon bug that required a low trigger point to be used when not using DMA if suspend and resume are important.

Regards,
Mark

Gangadhar,

Enabling h/w flow control should eliminate the FIFO overflow issue since the trasmitter of data will not send data until the receiver of data asserts the sender's CTS signal; however, I think that you may still encounter dropped audio data samples, but maybe it's not that noticeable & it's better than losing audio all together from an overflowed FIFO.

Regards,
Mark