linux8250串口驱动问题,linux – 如果超过256个字符待处理,为什么8250 UART驱动程序不会唤醒TTY？...

void serial8250_tx_chars(struct uart_8250_port * up)中这个if条件的动机是什么？

if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)

uart_write_wakeup(port);

自从Linux 1.1.13(1994年5月)以来,它一直存在并且在大多数UART驱动程序中重复.

背景：定制的Linux 3.4.91,ARMv7上的嵌入式系统,UART端口0配置为38400波特,16字节FIFO用于i / o.这些都不能在我们的设置中更改.

当通过UART在控制台上非常大量地打印时,内部4kB缓冲区(UART_XMIT_SIZE)会填满,然后停止用户空间进程,直到缓冲区被清空(这需要一秒钟在38400波特！).然后这种行为重复.这是因为函数n_tty_write()在缓冲区已满时进入休眠状态,并且由于上述可疑条件而未长时间被唤醒.

如果简单地删除这个检查,我会发现它更自然和有效.然后printfs会尽可能快地填充缓冲区,然后以缓冲区清空的速度继续,而不是我正在观察的突发处理.

它在我的环境中工作正常,但我肯定错过了或误解了一些东西.目前的实施必须有一个原因.如果我删除那个条件会有副作用吗？

作为一个侧面问题：是否有用于调整此行为的配置选项,例如：如果缓冲区已满,printf总是立即返回并丢弃输出？

解决方法:

这是一种效率措施. CPU的运行速度比串行端口快得多,如果内核允许用户空间进程每次在缓冲区中有一点空间时运行,它最终会向用户空间移动并返回每个字节的数据.这非常浪费CPU时间：

$time dd if=/dev/zero of=/dev/null bs=1 count=10000000

10000000+0 records