Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>, jslaby@suse.com,
        linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
        Gianluca Renzi <icjtqr@gmail.com>, dimka@embeddedalley.com,
        linux@rempel-privat.de
From:   gianluca <gianlucarenzi@eurek.it>
Subject: Serial data loss
Message-ID: <960c5054-48b0-fedc-4f3a-7246d84da832@eurek.it>
Date:   Tue, 7 Apr 2020 09:30:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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