Thanks Peter,
On 2016-02-03 20:06, Peter Hurley wrote:
My understanding of the code is that this code
if (termios->c_cflag & CRTSCTS && up->port.flags &
UPF_HARD_FLOW) {
/* Enable AUTORTS and AUTOCTS */
up->efr |= UART_EFR_CTS | UART_EFR_RTS;
in serial_omap_set_termios() will mean that h/w flow control will
not be enabled unless requested via termios.
In fact, without the UPF_HARD_FLOW flag set in the up->port.flags,
it is not possible to enable h/w flow-control, and any request to do
so via termios will silently fail.
auto h/w flow control implies the remote must also have auto h/w flow
control. For example, throttling works by stopping rx receive.
However,
if the remote does not stop sending within the minimum time, the rx
fifo
will overflow.
Our experience is that without auto h/w flow control that a 3.5 MBit
stream over the UART will over-flow the RX buffer any time on a heavily
CPU loaded system that kernel space CPU load spikes. Even a 57,6000 bit
stream will lose data if you max the machines CPU and then trigger a
kernel space CPU spike (such as by inserting a USB key, triggering
kernal space diagnostics, or whatever).
That is what lead to me finding this issue.
With the RTS/CTS levels controlled by the kernel serial buffer code
rather than by the UART chip itself, overflows were guaranteed under
those conditions. The calling user can easily think that RTS/CTS is
enabled as 'cat /proc/tty/driver/OMAP-SERIAL' displays RTS|CTS . This
seems incorrect behaviour to me but I may well be mistaken there.
Also, auto soft flow control on OMAP is broken.
This I did not know, thank you.
ioctl(TIOCSERCONFIG)
Will that not require any application using the UART for data transfer
to make that call? If they do not then data will be lost from the
transfer during any kernel CPU load spikes. It also requires any such
caller to have CAP_SYS_ADMIN .
This doesn't seem like a suitable solution to me.
Would you have a suggestion that would address my concerns above, or
are they ill-founded?
Should I log this as a bug - it seems incorrect to me that data can so
easily be lost through this driver when termios suggests that h/w flow
control is on, even though the chip is capable of managing it through
hard-ware.
Thanks Peter,
Greg
Thanks,
Greg
On 2016-02-03 00:16, Peter Hurley wrote:
On 01/25/2016 04:00 AM, Greg Farrell wrote:
Enable the UPF_BOOT_AUTOCONF flag in serial_omap_probe().
This will cause serial_omap_config_port() to be run and
the hardware to correctly be flagged as supporting hardware
and software flow-control.
Without this, it is not possible to enable flow control.
Won't this turn on h/w flow control for designs where RTS/CTS
is unconnected?
Signed-off-by: Greg Farrell <greg@xxxxxxxxxxxxxxx>
---
drivers/tty/serial/omap-serial.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/omap-serial.c
b/drivers/tty/serial/omap-serial.c
index b645f92..5e82238 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1664,7 +1664,10 @@ static int serial_omap_probe(struct
platform_device *pdev)
sprintf(up->name, "OMAP UART%d", up->port.line);
up->port.mapbase = mem->start;
up->port.membase = base;
- up->port.flags = omap_up_info->flags;
+ /*
+ * Enable UPF_BOOT_AUTOCONF so that serial_omap_config_port
will execute
+ */
+ up->port.flags = omap_up_info->flags | UPF_BOOT_AUTOCONF;
up->port.uartclk = omap_up_info->uartclk;
up->port.rs485_config = serial_omap_config_rs485;
if (!up->port.uartclk) {
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
