[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200407082454.GA299198@kroah.com>
Date: Tue, 7 Apr 2020 10:24:54 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: gianluca <gianlucarenzi@...ek.it>
Cc: jslaby@...e.com, linux-serial@...r.kernel.org,
linux-kernel@...r.kernel.org, Gianluca Renzi <icjtqr@...il.com>,
dimka@...eddedalley.com, linux@...pel-privat.de
Subject: Re: Serial data loss
On Tue, Apr 07, 2020 at 09:30:21AM +0200, gianluca wrote:
> I have a BIG trouble having dataloss when using two internal serial ports of
> my boards based on NXP/FreeScale iMX28 SoC ARMv5Te ARM920ej-s architecture.
>
> It runs at 454Mhz.
>
> Kernel used 4.9.x
That's a very old kernel, you are going to have to get support for that
from the vendor you bought it from :(
> When using my test case unit software between two serial ports connect each
> other by a null modem cable, it fails when the speed rate are different,
Of course, how would that work?
> and
> dataloss is increasing higher the speed rate.
What type of flow control are you using?
> I suppose to have overruns (now I am modifying my software to check them
> too), but I think it is due the way the ISR is called and all data are
> passed to the uart circular buffer within the interrupt routine.
Are you using flow control?
> I am talking about the high latency from the IRQ up to the service routine
> when flushing the FIFO and another IRQ is called by another uart in the same
> time at different speed.
>
> The code I was looking is: drivers/tty/serial/mxs-auart.c __but__ all other
> serial drivers are acting in the same way: they are reading one character at
> time from the FIFO (if it exists) and put it into the circular buffer so
> serial/tty driver can pass them to the user read routine.
>
> Each function call has some overhead and it is time-consuming, and if
> another interrupt is invoked by the same UART Core but from another serial
> port (different context) the continuos insertion done by hardware UART into
> the FIFO cannot be served fast enough to have an overrun. I think this can
> be applied __almost__ to every serial driver as they are written in the same
> way.
>
> And it is __NOT__ an issue because of the CPU and its speed! Using two
> serial converter (FTDI and Prolific PL2303 based) on each board, the problem
> does not appear at all even after 24 hours running at more than 115200!!!
usb-serial devices are totally different and send data to the host in a
completly different way.
Your hardware might just not be able to handle really high baud rates at
a continous stream, what baud rate were you using?
And again, this is what flow control was designed for, please use it.
> It does work fine if I am using two different serial devices: one internal
> uart (mxs-auart) and an external uart (ttyUSB).
Again, different interrupt and protocols being used for the USB stuff.
thanks,
greg k-h
Powered by blists - more mailing lists