From: leroy christophe <christophe.leroy@c-s.fr>
To: Alan Cox <alan@linux.intel.com>
Cc: Marcelo Tosatti <marcelo@kvack.org>,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH] Powerpc 8xx CPM_UART delay in receive
Date: Mon, 10 Sep 2012 09:09:32 +0200 [thread overview]
Message-ID: <504D922C.1030407@c-s.fr> (raw)
In-Reply-To: <20120816162136.059b64b4@bob.linux.org.uk>
Le 16/08/2012 17:21, Alan Cox a écrit :
>> MAX_IDL: Maximum idle characters. When a character is received, the
>> receiver begins counting idle characters. If MAX_IDL idle characters
>> are received before the next data character, an idle timeout occurs
>> and the buffer is closed,
>> generating a maskable interrupt request to the core to receive the
>> data from the buffer. Thus, MAX_IDL offers a way to demarcate frames.
>> To disable the feature, clear MAX_IDL. The bit length of an idle
>> character is calculated as follows: 1 + data length (5–9) + 1 (if
>> parity is used)
>> + number of stop bits (1–2). For 8 data bits, no parity, and 1 stop
>> bit, the character length is 10 bits
>
> So if you have slightly bursty high speed data as its quite typical
> before your change you would get one interrupt per buffer of 32 bytes,
> with it you'll get a lot more interrupts.
>
> You have two available hints about the way to set this - one of them is
> the baud rate (low baud rates mean the fifo isn't a big win and the
> latency is high), the other is the low_latency flag if the driver
> supports the low latency feature (and arguably you can still use a
> request for it as a hint even if you refuse the actual feature).
>
> So I think a reasonable approach would be set the idle timeout down for
> low baud rates or if low_latency is requested.
>
>> generated if there is at least one word in the FIFO and for a time
>> equivalent to the transmission of four characters
> Which is a bit more reasonable than one, although problematic at low
> speed (hence the fifo on/off).
>
What would then thing about:
* a value of 1 for all rates below 2400 (On 8250, fifo is set to 1 for
such rates)
* a value of 2 for 2400 and 4800
* a value of 4 for 9600 (which is the default on the 8250 for all rates
above 2400)
* a value of 8 for 19200
* a value of 16 for 38400 and above (on UCC_UART, maxidl is set to 16,
never 32)
Christophe
WARNING: multiple messages have this Message-ID (diff)
From: leroy christophe <christophe.leroy@c-s.fr>
To: Alan Cox <alan@linux.intel.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Vitaly Bordug <vitb@kernel.crashing.org>,
Marcelo Tosatti <marcelo@kvack.org>,
linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] Powerpc 8xx CPM_UART delay in receive
Date: Mon, 10 Sep 2012 09:09:32 +0200 [thread overview]
Message-ID: <504D922C.1030407@c-s.fr> (raw)
In-Reply-To: <20120816162136.059b64b4@bob.linux.org.uk>
Le 16/08/2012 17:21, Alan Cox a écrit :
>> MAX_IDL: Maximum idle characters. When a character is received, the
>> receiver begins counting idle characters. If MAX_IDL idle characters
>> are received before the next data character, an idle timeout occurs
>> and the buffer is closed,
>> generating a maskable interrupt request to the core to receive the
>> data from the buffer. Thus, MAX_IDL offers a way to demarcate frames.
>> To disable the feature, clear MAX_IDL. The bit length of an idle
>> character is calculated as follows: 1 + data length (5–9) + 1 (if
>> parity is used)
>> + number of stop bits (1–2). For 8 data bits, no parity, and 1 stop
>> bit, the character length is 10 bits
>
> So if you have slightly bursty high speed data as its quite typical
> before your change you would get one interrupt per buffer of 32 bytes,
> with it you'll get a lot more interrupts.
>
> You have two available hints about the way to set this - one of them is
> the baud rate (low baud rates mean the fifo isn't a big win and the
> latency is high), the other is the low_latency flag if the driver
> supports the low latency feature (and arguably you can still use a
> request for it as a hint even if you refuse the actual feature).
>
> So I think a reasonable approach would be set the idle timeout down for
> low baud rates or if low_latency is requested.
>
>> generated if there is at least one word in the FIFO and for a time
>> equivalent to the transmission of four characters
> Which is a bit more reasonable than one, although problematic at low
> speed (hence the fifo on/off).
>
What would then thing about:
* a value of 1 for all rates below 2400 (On 8250, fifo is set to 1 for
such rates)
* a value of 2 for 2400 and 4800
* a value of 4 for 9600 (which is the default on the 8250 for all rates
above 2400)
* a value of 8 for 19200
* a value of 16 for 38400 and above (on UCC_UART, maxidl is set to 16,
never 32)
Christophe
next prev parent reply other threads:[~2012-09-10 7:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-14 14:26 [PATCH] Powerpc 8xx CPM_UART delay in receive Christophe Leroy
2012-08-14 14:26 ` Christophe Leroy
2012-08-14 14:52 ` Alan Cox
2012-08-14 14:52 ` Alan Cox
2012-08-16 13:16 ` leroy christophe
2012-08-16 13:16 ` leroy christophe
2012-08-16 14:29 ` Alan Cox
2012-08-16 14:29 ` Alan Cox
2012-08-16 14:35 ` leroy christophe
2012-08-16 14:35 ` leroy christophe
2012-08-16 14:35 ` leroy christophe
2012-08-16 15:21 ` Alan Cox
2012-08-16 15:21 ` Alan Cox
2012-08-16 15:21 ` Alan Cox
2012-09-10 7:09 ` leroy christophe [this message]
2012-09-10 7:09 ` leroy christophe
2012-09-10 13:10 ` Alan Cox
2012-09-10 13:10 ` Alan Cox
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=504D922C.1030407@c-s.fr \
--to=christophe.leroy@c-s.fr \
--cc=alan@linux.intel.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=marcelo@kvack.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.