lkml.org 
[lkml]   [2020]   [Apr]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectSerial data loss
Date
Hello everybody!

I hope you are keeping safe against Covid-19 a.k.a. Coronavirus!

Now my issue:

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

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, and dataloss is increasing higher the speed rate.

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.

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!!!

It does work fine if I am using two different serial devices: one
internal uart (mxs-auart) and an external uart (ttyUSB).

So I can say it is related on how the harwdare is managing the interrupt
context and the FIFO/buffer small size.

Are those correct assuptions?

Will a shared FIQ driver over the UART solve the issue?

Regards,
--
Eurek s.r.l. |
Electronic Engineering | http://www.eurek.it
via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120
p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212

\
 
 \ /
  Last update: 2020-04-07 09:39    [W:0.053 / U:1.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site