UART FIFO Size & CTS Threshold

GoogleGroups
1

Hi all,

Been looking through the kernel source for 4.1 with Debian 8.1 and trying to work out some of the things on the UARTs, but I can’t seem to find the code!

  • What is the FIFO UART buffer size and is it configurable?
  • What is the FIFO trigger size for the CTS line to assert and is this configurable as well?
    Thanks!

Lee

2

Hi all,

Been looking through the kernel source for 4.1 with Debian 8.1 and trying to
work out some of the things on the UARTs, but I can't seem to find the code!

What is the FIFO UART buffer size and is it configurable?

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/8250/8250_omap.c#n1130

What is the FIFO trigger size for the CTS line to assert and is this
configurable as well?

Regards

3

Thanks Robert.

64 for the FIFO is what I suspected but couldn't see the CTS threshold. Was that 48?

Also these look pretty hard coded into the kernel. Anyone know a way of setting these after a compilation or how to compile in with other values?

Lee

4

Anyone know what the RTS/CTS thresholds are for the 8250_omap driver that I am pretty sure the BBB uses by default?

I can’t work it out! I know that the signalling of RTS is working as I see it go high on the scope but I need to know how many bytes it is safe to send before an overrun happens again!

5

Anyone know what the RTS/CTS thresholds are for the 8250_omap driver
that I am pretty sure the BBB uses by default?

I can't work it out! I know that the signalling of RTS is working as
I see it go high on the scope but I need to know how many bytes it is
safe to send before an overrun happens again!

The serial core + 8250_omap driver automatically prevent tx fifo
overflow; you don't have to worry about overrunning the fifo when
writing.

Are you observing overruns at the receiver with CRTSCTS on?
Is there a message or are you observing data corruption?
Is the receiver also a BBB or something else?
What baud rate are you using?

Regards,
Peter Hurley

6

Hi Peter,

It is on the RX side of things into the BBB and I am seeing the RTS signal goign across to our hardware. I think the threshold is 48 out of the 64 buffer from looking at and experimenting.

3Mbps is the baud rate and yes we were seeing an overrun and then corruption of the FIFO. RTS seems to be working now that we have worked it out that the throttling happens at 48.

Lee

7

Hi Lee,

Hi Peter,

It is on the RX side of things into the BBB and I am seeing the RTS
signal goign across to our hardware. I think the threshold is 48 out
of the 64 buffer from looking at and experimenting.

3Mbps is the baud rate and yes we were seeing an overrun and then
corruption of the FIFO. RTS seems to be working now that we have
worked it out that the throttling happens at 48.>
Lee

There are some issues at 3Mbaud, most likely related to dma.
Could be silicon. See here:

https://lkml.org/lkml/2015/12/3/442

8

Thanks Peter,

Yeah DMA mode was no go for us at this speed. That really did just create spurious data.

FIFO mode with hardware flow control seems to be stable right now.

Thanks for coming back to me!

Lee

9

Thanks Peter,

Yeah DMA mode was no go for us at this speed. That really did just create spurious data.

FIFO mode with hardware flow control seems to be stable right now.

Is the sender auto-CTS?

10

The other end is our own board and so signals cts all the time.

I think it is fine now that we have ascertained that the trigger is 48 out of 64