All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Wolfram Sang <w.sang@pengutronix.de>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	"s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Valentin Longchamp <valentin.longchamp@epfl.ch>
Subject: Re: [PATCH] serial imx.c: fix CTS trigger level lower to avoid lost chars
Date: Fri, 22 Jan 2010 16:47:38 +0000	[thread overview]
Message-ID: <20100122164738.GB21907@shareable.org> (raw)
In-Reply-To: <20100122114934.GE4782@pengutronix.de>

Wolfram Sang wrote:
> > What you're assuming is that flow control was there to prevent overruns
> > on the hardware receiver.  That's not the way it works on these devices;
> > flow control is entirely managed in software - there is no hardware
> > assistance.
> > 
> > The flow control implemented for non-FIFO and non-hardware assisted
> > UARTs is purely to do with preventing the software buffer behind the
> > UART from overflowing - it can't prevent the device's receiver buffering
> > from overrunning.  (Non-FIFO devices have the shift register and a
> > buffer register - complete reception of a second character before the
> > first is read causes an overrun condition.)
> > 
> > If you have overruns on the receiver, that's an interrupt latency
> > problem and its an error that's reported to the receiver side only.
> > 
> > Yes, later devices have the ability in hardware to deassert RTS when
> > the receiver FIFO gets above a certain threshold to /help/ prevent
> > overruns occuring when there's high interrupt latency - but normal
> > system operation should still ensure that the FIFO is emptied in a
> > timely manner.
> > 
> > They also gained the ability to stop the transmitter once CTS is
> > deasserted, mainly because the transmitter FIFOs in these devices
> > is soo large (maybe 32 to 128 bytes deep.)
> 
> Russell, thanks for this explanation. Patch seems principally OK to me, then.

I agree.

-- Jamie

WARNING: multiple messages have this Message-ID (diff)
From: jamie@shareable.org (Jamie Lokier)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] serial imx.c: fix CTS trigger level lower to avoid lost chars
Date: Fri, 22 Jan 2010 16:47:38 +0000	[thread overview]
Message-ID: <20100122164738.GB21907@shareable.org> (raw)
In-Reply-To: <20100122114934.GE4782@pengutronix.de>

Wolfram Sang wrote:
> > What you're assuming is that flow control was there to prevent overruns
> > on the hardware receiver.  That's not the way it works on these devices;
> > flow control is entirely managed in software - there is no hardware
> > assistance.
> > 
> > The flow control implemented for non-FIFO and non-hardware assisted
> > UARTs is purely to do with preventing the software buffer behind the
> > UART from overflowing - it can't prevent the device's receiver buffering
> > from overrunning.  (Non-FIFO devices have the shift register and a
> > buffer register - complete reception of a second character before the
> > first is read causes an overrun condition.)
> > 
> > If you have overruns on the receiver, that's an interrupt latency
> > problem and its an error that's reported to the receiver side only.
> > 
> > Yes, later devices have the ability in hardware to deassert RTS when
> > the receiver FIFO gets above a certain threshold to /help/ prevent
> > overruns occuring when there's high interrupt latency - but normal
> > system operation should still ensure that the FIFO is emptied in a
> > timely manner.
> > 
> > They also gained the ability to stop the transmitter once CTS is
> > deasserted, mainly because the transmitter FIFOs in these devices
> > is soo large (maybe 32 to 128 bytes deep.)
> 
> Russell, thanks for this explanation. Patch seems principally OK to me, then.

I agree.

-- Jamie

  reply	other threads:[~2010-01-22 16:47 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-21 21:26 [PATCH] serial imx.c: fix CTS trigger level lower to avoid lost chars Valentin Longchamp
2010-01-21 22:06 ` Wolfram Sang
2010-01-21 22:06   ` Wolfram Sang
2010-01-21 22:11   ` Russell King - ARM Linux
2010-01-21 22:11     ` Russell King - ARM Linux
2010-01-22 10:14     ` Valentin Longchamp
2010-01-22 10:14       ` Valentin Longchamp
2010-01-22 11:07       ` Jamie Lokier
2010-01-22 11:07         ` Jamie Lokier
2010-01-22 11:31         ` Russell King - ARM Linux
2010-01-22 11:31           ` Russell King - ARM Linux
2010-01-22 11:49           ` Wolfram Sang
2010-01-22 11:49             ` Wolfram Sang
2010-01-22 16:47             ` Jamie Lokier [this message]
2010-01-22 16:47               ` Jamie Lokier
2010-01-22 16:47           ` Jamie Lokier
2010-01-22 16:47             ` Jamie Lokier
2010-01-22 16:57             ` Russell King - ARM Linux
2010-01-22 16:57               ` Russell King - ARM Linux
2010-01-22 11:58 ` Wolfram Sang
2010-01-22 11:58   ` Wolfram Sang
2010-01-24 10:48   ` Valentin Longchamp
2010-01-24 10:48     ` Valentin Longchamp
2010-05-05  9:47     ` Valentin Longchamp
2010-05-05 16:42       ` Greg KH
2010-05-05 23:48       ` patch serial-imx.c-fix-cts-trigger-level-lower-to-avoid-lost-chars.patch added to gregkh-2.6 tree gregkh

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=20100122164738.GB21907@shareable.org \
    --to=jamie@shareable.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=s.hauer@pengutronix.de \
    --cc=valentin.longchamp@epfl.ch \
    --cc=w.sang@pengutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.