[PATCH 0/4] Rework hw-assisted flow control
Peter Hurley
peter at hurleysoftware.com
Sun Jan 25 11:44:50 PST 2015
Hi Greg,
This patch series re-implements hw-assisted flow control support,
(aka autoRTS, autoCTS and auto XON/XOFF) in the serial core.
Out-of-tree driver maintainers please note this changes the UART
driver interface for flow control steering.
This series separates mode handling from the capabilities flags.
UPF_HARD_FLOW and UPF_SOFT_FLOW continue to indicate the hardware
is capable of hw-assisted flow control; in addition, UPF_HARD_FLOW
is split into separate capabilities (UPF_AUTO_CTS and UPF_AUTO_RTS)
should the driver require the distinction.
However, the serial core only checks UPF_SOFT_FLOW (to determine
if the UART driver is capable of auto XON/XOFF flow control and
thus needs its set_termios() method called).
Flow control steering in the serial core is now determined by
the uart_port::status field, and the newly introduced
UPSTAT_AUTOCTS, UPSTAT_AUTORTS and UPSTAT_AUTOXOFF for
autoCTS tx flow control, autoRTS rx flow control and auto
IXOFF flow control respectively. [Core support for auto IXON did
not seem necessary, as core intervention does not seem required --
please let me know if that's not the case.]
Typically, the driver should set or reset these flags in their
set_termios() method (in the port lock critical section, if
port lock is used), depending on the hardware capabilities and
requirement.
All drivers which enable hardware autoCTS mode MUST set UPSTAT_AUTOCTS
to prevent the serial core from inadvertently disabling tx. In this
mode, hw_stopped = 0 and uart_handle_cts_change() perform no action
(other than bumping the cts stat for diagnostic purposes).
For hardware which does not automatically disable autoRTS mode
when RTS is lowered or otherwise desires to implement
throttle()/unthrottle() methods, the driver MUST set UPSTAT_AUTORTS.
In this mode, the uart driver throttle()/unthrottle() methods
are called, rather than lowering RTS via set_mctrl().
UPSTAT_AUTORTS _must not_ be set for drivers which do not implement
throttle()/unthrottle() methods; in this case, set_mctrl() is still used
to control the RTS pin.
Even for drivers using UPSTAT_AUTORTS, the driver is still responsible
for properly implementing RTS handling in set_mctrl(), regardless of
current termios settings or hardware mode. That is, if the hardware
is capable of driving the RTS pin, the driver's set_mctrl() method
must lower RTS if !TIOCM_RTS. If that requires disabling autoRTS mode,
then that shall be done. The serial core and userspace must be able to
manually flow control with RTS.
When handling set_mctrl(), the driver may check the uart_port::status
UPSTAT_AUTORTS bit to determine if it set autoRTS mode at set_termios(),
and thus whether to restore its autoRTS mode when RTS is raised. In other
words, the driver does not need to set/check its own private state.
All drivers which enable hardware auto IXOFF flow control mode
MUST set UPSTAT_AUTOXOFF. As with UPSTAT_AUTORTS, throttle()/unthrottle()
methods are required. When this mode is set, the core will _not_ send
START/STOP, and expects the driver/hardware to do so.
This patch series converts in-tree drivers to this 'new' interface.
The last patch rips out a private interface hack being used by a
bluetooth host controller driver to tickle RTS for device wakeup;
this is no longer required now that the offending in-tree driver,
omap-serial, properly drives RTS in autoRTS mode.
Regards,
Peter Hurley (4):
serial: core: Rework hw-assisted flow control support
serial: 8250_omap: Use UPSTAT_AUTORTS for RTS handling
serial: omap: Fix RTS handling
tty: Remove external interface for tty_set_termios()
drivers/bluetooth/hci_ath.c | 15 +-------
drivers/tty/serial/8250/8250_omap.c | 23 ++++++-----
drivers/tty/serial/omap-serial.c | 29 +++++++++-----
drivers/tty/serial/serial_core.c | 76 ++++++++++++++-----------------------
drivers/tty/tty_ioctl.c | 3 +-
include/linux/serial_core.h | 21 ++++++++--
include/linux/tty.h | 1 -
7 files changed, 83 insertions(+), 85 deletions(-)
--
2.2.2
More information about the linux-arm-kernel
mailing list