On 10/14/2014 05:22 AM, Johannes Thumshirn wrote: > On Mon, Oct 13, 2014 at 01:13:21PM -0400, Peter Hurley wrote: >> On 10/13/2014 10:48 AM, Johannes Thumshirn wrote: >>> Hi, >>> >>> We have problem with automatic flow control (i.e. auto RTS/CTS handshaking) in >>> our uart driver (men_z135_uart.c). It's probably less a technical but a problem >>> with me understanding the API. >>> >>> I active the hardware auto flow control feature on the CRTSCTS flag in my >>> uart_ops->set_termios() function. But then the RTS flag is set on every call of >>> the uart_ops->set_mctrl() function, this seems to confuse the hardware. Is there >>> a way to tell the tty layer that flow control is handled solely by hardware? >>> I.e. is there a way of telling serial core to leave out the calls to >>> uart_set_mctrl()/uart_clear_mctrl() in uart_throttle()/uart_unthrottle(), or is >>> setting UPF_FLOW_HARD and then implementing a dummy port->ops->{un}throttle() >>> the correct way? >>> >>> Are there any drivers that use a hardware's automatic flow control feature I can >>> use as an example? A fast grep on AFE reveals some spots, but I can't really >>> find a difference to my implementation. >> >> uart_throttle()/uart_unthrottle() is essentially broken. >> >> If the RTS pin is driveable, then the UART driver must respond to TIOCM_RTS >> set and clear in the ->set_mctrl() handler, regardless of any mode selected >> in termios or other mode such as autoRTS. >> >> This requirement exists because both userspace and other kernel drivers may >> want to drive RTS for their own purposes. >> >> For example, a bluetooth UART HCI may allow the bluetooth module to sleep >> and wakes up the module by driving RTS low for a certain length of time; >> if autoRTS prevents MCR writes from driving RTS, then the wake up never >> happens. (see drivers/bluetooth/hci_ath.c : ath_wakeup_ar3k() for the >> equally broken workaround of turning off CRTSCTS via an internal >> tty core function which is going away soon). >> >> The reason why TI 16c750-based AFE doesn't have to bother with this is >> because, on that hardware, the MCR RTS bit overrides the autoRTS state; >> ie., RTS = MCR_RTS & autoRTS. >> >> If your hardware treats the two states orthogonally then you'll need >> to turn off autoRTS mode if TIOCM_RTS is being cleared. >> The amba-pl011.c driver does this; see drivers/tty/serial/amba-pl011.c: >> pl011_set_mctrl(). > > Thanks for the info. > > We've actually found the problem. When using auto flow control we need to > disable the modem status IRQs, in order to work. So the UART still raises modem status interrupts for DCTS when autoCTS is on? > The only problem that arises here is, when the modem status IRQs are disabled > the uart_ops->start_tx() isn't called anymore. But there should be work arounds > available. Almost certainly this is because ->hw_stopped has been set. The serial core does this in two places (besides uart_handle_cts_change()): uart_port_startup() after initializing the port and, in uart_set_termios(), which, if you set UPF_HARD_FLOW, the serial core will skip. Regards, Peter Hurley [Note: there's been some changes to flow control for 3.18; hw_stopped was moved to uart_port]. -- 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