linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Hurley <peter@hurleysoftware.com>
To: Johannes Thumshirn <johannes.thumshirn@men.de>,
	linux-serial@vger.kernel.org
Cc: "Geißler Andreas" <Andreas.Geissler@men.de>
Subject: Re: Handling of automatic flow control in UART drivers
Date: Mon, 13 Oct 2014 13:13:21 -0400	[thread overview]
Message-ID: <543C0831.8000101@hurleysoftware.com> (raw)
In-Reply-To: <20141013144831.GA8409@jtlinux>

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().

Regards,
Peter Hurley

  parent reply	other threads:[~2014-10-13 17:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-13 14:48 Handling of automatic flow control in UART drivers Johannes Thumshirn
2014-10-13 17:09 ` Grant Edwards
2014-10-13 17:13 ` Peter Hurley [this message]
2014-10-14  9:22   ` Johannes Thumshirn
2014-10-14 11:18     ` Peter Hurley
2014-10-23  5:51       ` Johannes Thumshirn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=543C0831.8000101@hurleysoftware.com \
    --to=peter@hurleysoftware.com \
    --cc=Andreas.Geissler@men.de \
    --cc=johannes.thumshirn@men.de \
    --cc=linux-serial@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).