public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
	akpm@osdl.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org
Subject: Re: [patch 3/4] new serial flow control
Date: Sun, 9 Oct 2005 12:17:18 +0100	[thread overview]
Message-ID: <20051009111718.GA13144@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20051009100909.GF5150@bouh.residence.ens-lyon.fr>

On Sun, Oct 09, 2005 at 12:09:09PM +0200, Samuel Thibault wrote:
> Russell King, le Sun 09 Oct 2005 09:37:24 +0100, a ?crit :
> > What I was thinking of was to use some of the spare termios cflag bits
> > to select the flow control.  You'd only want one flow control type at
> > one time though.  Eg: define two fields, each to select the signal.
> > 
> > 0 - RTS
> > 1 - DTR
> > 
> > 0 - CTS
> > 1 - DTR
> > 2 - DSR
> 
> It looks fine, but it might not be sufficient for expressing that:
> 
> - some flow control use RTS to indicate that DTE is ready to send data,
> - some other use it to indicate that DTE wants to send data. (and CTS is
> used for acknowledgment of this),

Agreed - and that's one extra bit of control information.

> - some other use it as a strobe for acknowledging characters, some other
> use it as a strobe for acknowledging frames (announced by CTS).

The last has no business being in the serial driver though - the driver
knows nothing about frames of characters.  It's more a userland (in
which case it's TIOCM* ioctls) or ldisc issue (tty_driver->tiocmset).

> > However, bear in mind that the majority of the more inteligent 8250-
> > compatible UARTs with large FIFOs only do hardware flow control on
> > RTS/CTS
> 
> Hardward flow control is usually performed in software. Can't their
> hardware implementation of hardware flow control be disabled when
> control method is not usual RTS/CTS?

You missed the point.  Of course the hardware flow control can be
disabled.  However, if you do have on-chip CTS flow control disabled
with UARTs with large FIFOs, and remote end says "stop sending", the
characters already in the FIFO will be sent, which may be up to
64 or even 128 characters instead of the usual 16 or so with the
16550A.  If the remote end only has room for 32 more characters,
you're into an overrun condition at every "stop sending" event.

Hence, people must expect a DTR/DSR software-based hardware flow
control to be less reliable than using RTS/CTS (with an adapter to
swap the RTS/CTS pins for DTR/DSR) with advanced 8250-based UARTs.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

  reply	other threads:[~2005-10-09 11:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200501052341.j05Nfod27823@mail.osdl.org>
     [not found] ` <20050105235301.B26633@flint.arm.linux.org.uk>
2005-10-08 22:27   ` [patch 3/4] new serial flow control Samuel Thibault
2005-10-08 22:58     ` Samuel Thibault
2005-10-09  0:01     ` Russell King
2005-10-09  0:21       ` Samuel Thibault
2005-10-09  8:37         ` Russell King
2005-10-09 10:09           ` Samuel Thibault
2005-10-09 11:17             ` Russell King [this message]
2005-10-09 11:33               ` Samuel Thibault
2005-10-09 11:44                 ` Samuel Thibault
2005-10-09 23:04                   ` Alan Cox
2005-10-09 13:29           ` Samuel Thibault

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=20051009111718.GA13144@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=akpm@osdl.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=samuel.thibault@ens-lyon.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