AM5748: UART running 12MBd in Linux pauses TX after reading RX

Hi Fredrik,

https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/termbits.h#L159

The max supported by Linux is 4M baud. 3M is most widely used and tested. Though hardware is capable of 12M
the Linux widely tried high baud is 3M.

12M is not supported in Linux. I confirmed this with our UART expert.

Best Regards,
Keerthy

Thank you for that insight.

Is it possible to run the UART in 12MBd from any of the co-processors instead?

Best regards,

Fredrik

When you say "12M is not supported in Linux. I confirmed this with our UART expert.", does that mean omap-serial driver does not support 12M?

I still think that 64 byte bursts should be fine if dma was acually enabled?
When I log the values of structs omap_uart_port_info and uart_omap_dma that concerns dma, everything i 0, event though dma is configured in device tree. This indicates that dma is not fully implemented in omap-serial driver. Correct?

If Linux is the bottleneck, dma should be the solution, because then the dma handles the readout of the UART FIFO instead of Linux.

Whether Linux can set 12MBd via termios or not is irrelevant to my use case.

Hi,

omap serial never supported DMA. UART DMA is only recommended with 8250-omap on 6.03 SDK i.e 4.19 Linux kernel.
In any case Linux drivers were never tested at 12M.

Best Regards,
Keerthy

Hi,


I modified the 8250-omap kernel module to use the 192MHz clock and set 12MBd in termios when probing.

In device tree I guess 8250-omap has these bindings: www.kernel.org/.../8250.yaml instead of www.kernel.org/.../omap_serial.txt

I suspect I need to configure the device better in the device tree. Do you have an example of a am57xx UART being configured for 8250-omap driver?


When testing with the modified 8250-omap changes, we get the following results:

The pause has moved, so now we get 64 bytes through before pausing.


An example of a device tree entry for this particular UART would be much appreciated!


Best regards,

Fredrik Wigert

Most threads around on this subject point towards this broken link: http://processors.wiki.ti.com/index.php/Sitara_Linux_UART_-_Switching_to_8250_Driver

Has it moved?

Best regards,

Fredrik

Hi Fredrik,

Yes it has moved. I am checking internally on this. I will revert back as soon as i get the working link.

Regards,
Keerthy

Hi Fredrik,

I have attached the PDF of the document here./cfs-file/__key/communityserver-discussions-components-files/791/Sitara-Linux-UART-_2D00_-Switching-to-8250-Driver-_2D00_-Texas-Instruments-Wiki.pdf

This document was missed out during the mgiration, and we will have it addressed soon.

Regards

Karthik

Hi,

I can confirm that dma routines are used by logging in omap_8250_rx_dma() & omap_8250_tx_dma() functions, but still pause in tx.

I noticed that most device tree settings are ignored in this driver, so I tested changing tx_loadsz to 32 instead of 64 and got this behavior:

What is happening for 50µs? Why does the UART TX stop when dma pushes data to its fifo?

We even tried splitting TX and RX to two separate UARTs (running the old omap-serial driver on both however). Still the same pause.

I'm running out of ideas.

Best regards,

Fredrik

Any news on this issue?

Best regards,

Fredrik

Hi Fredrik,

Could you share your DT node for the omap-8250?
How are you setting the divider 8250 driver to 12M as driver by default won't support.

This is untested unexplored. So not much inputs from our side as well.

Best Regards,
Keerthy

Hello,

Here is my patch to the 8520_omap.c:

diff --git a/drivers/tty/serial/8250/8250_omap.c b/drivers/tty/serial/8250/8250_omap.c
index 8c86d1b2f..ecc03f671 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -34,7 +33,7 @@
 
 #include "8250.h"
 
-#define DEFAULT_CLK_SPEED	48000000
+#define DEFAULT_CLK_SPEED	192000000 /* 192Mhz */
 
 #define UART_ERRATA_i202_MDR1_ACCESS	(1 << 0)
 #define OMAP_UART_WER_HAS_TX_WAKEUP	(1 << 1)
@@ -343,6 +342,22 @@ static void omap8250_restore_regs(struct uart_8250_port *up)
 	up->port.ops->set_mctrl(&up->port, up->port.mctrl);
 }
 
+static void
+omap_8250_set_192MHz_clock(struct uart_8250_port *up) 
+{
+	struct clk *uart_fck, *uart_parent;
+	char buffer[20];
+	
+
+	snprintf(buffer, 20, "uart%u_gfclk_mux", up->port.line + 1); // inconsistency in uart numbering...
+        printk("Selecting 192MHz clock via mux: %s.\n", buffer);
+	uart_parent = clk_get_sys(NULL, "dpll_per_m2x2_ck");
+	uart_fck = clk_get_sys(NULL, buffer);
+	if (clk_set_parent(uart_fck, uart_parent)) {
+		dev_err(up->port.dev, "Failed changing clock!");
+	} 
+}
+
 /*
  * OMAP can use "CLK / (16 or 13) / div" for baud rate. And then we have have
  * some differences in how we want to handle flow control.
@@ -381,6 +396,12 @@ static void omap_8250_set_termios(struct uart_port *port,
 	if (termios->c_cflag & CMSPAR)
 		cval |= UART_LCR_SPAR;
 
+    /* There seems to be no linux terminals that actually support custom baud rates, so force it to 12MHz */
+	termios->c_cflag &= ~CBAUD;
+	termios->c_cflag |= BOTHER;
+	termios->c_ispeed = 12000000;
+	termios->c_ospeed = 12000000;
+
 	/*
 	 * Ask the core to calculate the divisor for us.
 	 */
@@ -389,6 +410,13 @@ static void omap_8250_set_termios(struct uart_port *port,
 				  port->uartclk / 13);
 	omap_8250_get_divisor(port, baud, priv);
 
+    printk("Baud: %u, c_ispeed: %u\n", baud, termios->c_ispeed);
+
+	/* Reparent the UART clock to the 192MHz clock if device tree says so */
+	if (port->uartclk == 192000000) {
+		omap_8250_set_192MHz_clock(up);
+	}	
+

Here is my device tree node:

 uart5: serial@0 {
		compatible = "ti,dra742-uart", "ti,omap4-uart";
		reg = <0x0 0x100>;
		interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>;
		clock-frequency = <192000000>;
		status = "ok";
		fifo-size = <64>;
		reg-io-width = <4>;
		reg-shift = <2>;
		tx-threshold = <40>; // No impact at all, ignored by driver
		current-speed = <12000000>;
};

Have a nice weekend!

Best regards,

Fredrik

Fredrik,

I am getting this reviewed by our UART expert but this is untested and unsupported. We can support this beyond reviewing.

Best Regards,
Keerthy

Hi Fredrik,

What is the status of flow control lines? Are they asserted?
Also please run serialstats in the background before starting your test. Information on how to run:

http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Foundational_Components/Kernel/Kernel_Drivers/UART.html

topic: Testing UART communication with HW flow control

Best Regards,
Keerthy

Hi,

Sorry for not specifying our pinmuxing: the uart is configured with software flow control. We then set it up as a raw tty.

I will have a look at serialstats, thank you very much!

Best regards,

Fredrik