Re: Serial Flow Control

Re: Serial Flow Control

[Rocker Dude]

Hi All,

I am using a powerpc8548e custom hardware and testing flow control on
it. I have cross-wired the RTS/CTS of the board with my host terminal.
I find that when I am reading from the powerpc, it does not change the
CTS signal when it is running out of buffers and hence it is dropping
bytes.

I referred to something similar at http://lkml.org/lkml/2007/7/26/46.

Can anyone please tell me if this flow control needs to be done by the SW?

thanx!
Sundar

Re: Serial Flow Control

[Alan Cox]

On Tue, 17 Mar 2009 11:04:36 +0530
Rocker Dude <life.does.rock@gmail.com> wrote:

> Hi All,
> 
> I am using a powerpc8548e custom hardware and testing flow control on
> it. I have cross-wired the RTS/CTS of the board with my host terminal.
> I find that when I am reading from the powerpc, it does not change the
> CTS signal when it is running out of buffers and hence it is dropping
> bytes.
> 
> I referred to something similar at http://lkml.org/lkml/2007/7/26/46.
> 
> Can anyone please tell me if this flow control needs to be done by the SW?

Flow control needs to be enabled by the user space software (if not
enabled already), managed by the line discipline and implemented by the
device driver (or automatically in hardware in some cases)

Basically; App "set CRTSCTS"
Ldisc: buffers full/not full logic for throttling
Driver: throttling events -> flow control, honour flow on write

Re: Serial Flow Control

[Rocker Dude]

Hi Alan,

Thank you very much for the prompt reply!

I debugged out the problem though. I will describe it, even if it
seems childish!

I was using the flow control on the console serial. As a result, any
data being sent to the powerpc from the x86 was also being read by the
console driver, and being responded to. As a result, many of times, my
actual serial read application would lose bytes and sit idle. I
changed the console port and observed data validity perfectly.

However, I have some few queires.

1. To prove flow control, I sleep for 5 seconds after every read.
Although my logic says that both the xmitter and the reciever in this
case should complete the process within a few time difference, I find
that my xmitter exits out after sending the chunk; while my receiver
keeps on receiving it for a few more time. And this time is almost a
minute or something. I did find out the xmitter 4K page buffers, but
it was too misleading for me to believe this!

Alan, I will once again go through the discipline drivers more before
I shoot may doubts!

Thanx a lot for the help and replies,

Thanx!
Sundar

On Tue, Mar 17, 2009 at 2:27 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Tue, 17 Mar 2009 11:04:36 +0530
> Rocker Dude <life.does.rock@gmail.com> wrote:
>
>> Hi All,
>>
>> I am using a powerpc8548e custom hardware and testing flow control on
>> it. I have cross-wired the RTS/CTS of the board with my host terminal.
>> I find that when I am reading from the powerpc, it does not change the
>> CTS signal when it is running out of buffers and hence it is dropping
>> bytes.
>>
>> I referred to something similar at http://lkml.org/lkml/2007/7/26/46.
>>
>> Can anyone please tell me if this flow control needs to be done by the SW?
>
> Flow control needs to be enabled by the user space software (if not
> enabled already), managed by the line discipline and implemented by the
> device driver (or automatically in hardware in some cases)
>
> Basically; App "set CRTSCTS"
> Ldisc: buffers full/not full logic for throttling
> Driver: throttling events -> flow control, honour flow on write
>