All of lore.kernel.org
 help / color / mirror / Atom feed
From: leroy christophe <christophe.leroy@c-s.fr>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Alan Cox <alan@linux.intel.com>,
	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: Thu, 16 Aug 2012 15:16:16 +0200	[thread overview]
Message-ID: <502CF2A0.8080109@c-s.fr> (raw)
In-Reply-To: <20120814155227.018988da@pyramind.ukuu.org.uk>


Le 14/08/2012 16:52, Alan Cox a écrit :
> On Tue, 14 Aug 2012 16:26:28 +0200
> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>
>> Hello,
>>
>> I'm not sure who to address this Patch to either
>>
>> It fixes a delay issue with CPM UART driver on Powerpc MPC8xx.
>> The problem is that with the actual code, the driver waits 32 IDLE patterns before returning the received data to the upper level. It means for instance about 1 second at 300 bauds.
>> This fix limits to one byte the waiting period.
> Take a look how the 8250 does it - I think you want to set the value
> based upon the data rate. Your patch will break it for everyone doing
> high seed I/O.
>
> Alan
>
I'm not sure I understand what you mean. As far as I can see 8250/16550 
is working a bit different, as it is based on a fifo and triggers an 
interrupt as soon as a given number of bytes is received. I also see 
that in case this amount is not reached, there is a receive-timeout 
which goes on after no byte is received for a duration of more than 4 bytes.

The PowerPC CPM is working differently. It doesn't use a fifo but 
buffers. Buffers are handed to the microprocessor only when they are 
full or after a timeout period which is adjustable. In the driver, the 
buffers are configured with a size of 32 bytes. And the timeout is set 
to the size of the buffer. That is this timeout that I'm reducing to 1 
byte in my proposed patch. I can't see what it would break for high 
speed I/O.

Christophe

WARNING: multiple messages have this Message-ID (diff)
From: leroy christophe <christophe.leroy@c-s.fr>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Marcelo Tosatti <marcelo@kvack.org>,
	linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, Alan Cox <alan@linux.intel.com>
Subject: Re: [PATCH] Powerpc 8xx CPM_UART delay in receive
Date: Thu, 16 Aug 2012 15:16:16 +0200	[thread overview]
Message-ID: <502CF2A0.8080109@c-s.fr> (raw)
In-Reply-To: <20120814155227.018988da@pyramind.ukuu.org.uk>


Le 14/08/2012 16:52, Alan Cox a écrit :
> On Tue, 14 Aug 2012 16:26:28 +0200
> Christophe Leroy <christophe.leroy@c-s.fr> wrote:
>
>> Hello,
>>
>> I'm not sure who to address this Patch to either
>>
>> It fixes a delay issue with CPM UART driver on Powerpc MPC8xx.
>> The problem is that with the actual code, the driver waits 32 IDLE patterns before returning the received data to the upper level. It means for instance about 1 second at 300 bauds.
>> This fix limits to one byte the waiting period.
> Take a look how the 8250 does it - I think you want to set the value
> based upon the data rate. Your patch will break it for everyone doing
> high seed I/O.
>
> Alan
>
I'm not sure I understand what you mean. As far as I can see 8250/16550 
is working a bit different, as it is based on a fifo and triggers an 
interrupt as soon as a given number of bytes is received. I also see 
that in case this amount is not reached, there is a receive-timeout 
which goes on after no byte is received for a duration of more than 4 bytes.

The PowerPC CPM is working differently. It doesn't use a fifo but 
buffers. Buffers are handed to the microprocessor only when they are 
full or after a timeout period which is adjustable. In the driver, the 
buffers are configured with a size of 32 bytes. And the timeout is set 
to the size of the buffer. That is this timeout that I'm reducing to 1 
byte in my proposed patch. I can't see what it would break for high 
speed I/O.

Christophe

  reply	other threads:[~2012-08-16 13:16 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 [this message]
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
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=502CF2A0.8080109@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 \
    --cc=vitb@kernel.crashing.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.