All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Elwell <phil-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
To: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>,
	Greg Kroah-Hartman
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	Andy Shevchenko
	<andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	Peter Hurley
	<peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org>,
	Yegor Yefremov
	<yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>,
	Jan Kiszka <jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org>,
	linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] serial: 8250: Fix THRE flag usage for CAP_MINI
Date: Mon, 26 Jun 2017 16:15:37 +0100	[thread overview]
Message-ID: <bf050731-6b05-9e35-8b50-ea9115b4197f@raspberrypi.org> (raw)
In-Reply-To: <627a530c-d78c-5338-5ddf-0b3f6a09c37e-eS4NqCHxEME@public.gmane.org>

Hi Stefan,

On 26/06/2017 16:05, Stefan Wahren wrote:
> Hi Phil,
> 
> Am 26.06.2017 um 15:59 schrieb Phil Elwell:
>> The BCM2835 MINI UART has non-standard THRE semantics. Conventionally
>> the bit means that the FIFO is empty (although there may still be a
>> byte in the transmit register), but on 2835 it indicates that the FIFO
>> is not full. This causes interrupts after every byte is transmitted,
>> with the FIFO providing some interrupt latency tolerance.
>>
>> A consequence of this difference is that the usual strategy of writing
>> multiple bytes into the TX FIFO after checking THRE once is unsafe.
>> In the worst case of 7 bytes in the FIFO, writing 8 bytes loses all
>> but the first since by then the FIFO is full.
>>
>> There is an HFIFO ("Hidden FIFO") capability that causes the transmit
>> loop to terminate when both THRE and TEMT are set, i.e. when the TX
>> block is completely idle. This is unnecessarily cautious, potentially
>> causing gaps in transmission.
>>
>> Add a new conditional to the transmit loop, predicated on CAP_MINI,
>> that exits when THRE is no longer set (the FIFO is full). This allows
>> the FIFO to fill quickly but subsequent writes are paced by the
>> transmission rate.
> 
> thanks for this good explanation.
> 
> But this looks like a bug / quirk than a capability?
> 
> It would be better to name this define more self-explaining.
> 
> Btw can't see the definition of UART_CAP_MINI?

The capability was added in d087e7a991f1f61ee2c07db1be7c5cc2aa373f5d, which
is in linux-next. Given that the "capability" already exists and the quirk
is likely to be unique to BCM2835 MINI UART, I don't think we should create
a new quirk.

Besides, the "HFIFO" capability looks a lot like quirk to me.

Thanks,

Phil

>>
>> Signed-off-by: Phil Elwell <phil-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
>> ---
>>  drivers/tty/serial/8250/8250_port.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
>> index 4c620be..a5fe0e6 100644
>> --- a/drivers/tty/serial/8250/8250_port.c
>> +++ b/drivers/tty/serial/8250/8250_port.c
>> @@ -1764,6 +1764,10 @@ void serial8250_tx_chars(struct uart_8250_port *up)
>>  		if ((up->capabilities & UART_CAP_HFIFO) &&
>>  		    (serial_in(up, UART_LSR) & BOTH_EMPTY) != BOTH_EMPTY)
>>  			break;
>> +		/* The BCM2835 MINI UART THRE bit is really a not-full bit. */
>> +		if ((up->capabilities & UART_CAP_MINI) &&
>> +		    !(serial_in(up, UART_LSR) & UART_LSR_THRE))
>> +			break;
>>  	} while (--count > 0);
>>  
>>  	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)

  parent reply	other threads:[~2017-06-26 15:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-26 13:59 [PATCH] serial: 8250: Fix THRE flag usage for CAP_MINI Phil Elwell
     [not found] ` <1498485581-72097-1-git-send-email-phil-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
2017-06-26 15:05   ` Stefan Wahren
     [not found]     ` <627a530c-d78c-5338-5ddf-0b3f6a09c37e-eS4NqCHxEME@public.gmane.org>
2017-06-26 15:15       ` Phil Elwell [this message]
     [not found]         ` <bf050731-6b05-9e35-8b50-ea9115b4197f-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
2017-06-27  9:15           ` Andy Shevchenko
     [not found]             ` <1498554936.22624.180.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-06-27 10:30               ` Phil Elwell
     [not found]                 ` <2669bcda-e1f5-ecb1-a986-99947658bac7-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
2017-06-27 17:52                   ` Andy Shevchenko
     [not found]                     ` <1498585950.22624.210.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-06-27 21:00                       ` Phil Elwell
     [not found]                         ` <aeee2737-623c-c45b-bb18-4ff488684d0c-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
2017-06-28  7:48                           ` Andy Shevchenko
     [not found]                             ` <1498636112.22624.212.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-06-28  8:09                               ` Phil Elwell
     [not found]                                 ` <9d796427-3a02-53a6-5426-633bbf6f9a85-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
2017-06-28  8:18                                   ` Andy Shevchenko
2017-06-27  9:18   ` Andy Shevchenko
     [not found]     ` <1498555113.22624.182.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-06-27  9:24       ` Phil Elwell
2017-06-27 22:36   ` Eric Anholt
2017-06-28  8:42 Phil Elwell
     [not found] ` <1498639379-143432-1-git-send-email-phil-FnsA7b+Nu9XbIbC87yuRow@public.gmane.org>
2017-06-28  8:54   ` Stefan Wahren
     [not found]     ` <af5786eb-786b-5a50-6b4d-f67b8daf1c8a-eS4NqCHxEME@public.gmane.org>
2017-06-28  9:17       ` Phil Elwell

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=bf050731-6b05-9e35-8b50-ea9115b4197f@raspberrypi.org \
    --to=phil-fnsa7b+nu9xbibc87yurow@public.gmane.org \
    --cc=andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org \
    --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=jan.kiszka-kv7WeFo6aLtBDgjK7y7TUQ@public.gmane.org \
    --cc=linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org \
    --cc=stefan.wahren-eS4NqCHxEME@public.gmane.org \
    --cc=yegorslists-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.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 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.