The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Paul Mbewe <paultyson.mbewe@ziehl-abegg.de>
Cc: <Maarten.Brock@sttls.nl>, <crescentcy.hsieh@moxa.com>,
	<linux-serial@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<gregkh@linuxfoundation.org>, <jirislaby@kernel.org>,
	<hvilleneuve@dimonoff.com>, <tobias.gannert@ziehl-abegg.de>,
	<joachim.knorr@ziehl-abegg.de>
Subject: Re: [PATCH 2/2] serial: sc16is7xx: set TX FIFO trigger level to half FIFO to prevent underruns
Date: Tue, 7 Jul 2026 18:50:25 +0100	[thread overview]
Message-ID: <20260707185025.2645b7b4@pumpkin> (raw)
In-Reply-To: <20260707150344.353068-1-paultyson.mbewe@ziehl-abegg.de>

On Tue, 7 Jul 2026 17:03:44 +0200
Paul Mbewe <paultyson.mbewe@ziehl-abegg.de> wrote:

> Hi David, Maarten,
> 
> Thanks, I double-checked this with finer TXLVL instrumentation, and the
> root cause is clearer now: the failures are stale-TXLVL under-fills, not a
> separate THRI re-arm issue.
> 
> > You need the refill path to be much faster then the drain path.
> 
> Agreed. The issue is that sc16is7xx reads TXLVL once and sizes the FIFO
> write from that value. On this SPI-backed path, hardirq/softirq activity,
> RT scheduling and the synchronous SPI transfer wait can delay the refill
> while the UART continues draining. So the TXLVL value can become stale
> before the write completes.
> 
> One failing example:
> 
>   tx_start       txlvl=9  txlvl_read_us=580
>   tx_pre_write   sent=9   pre_write_us=16
>   tx_segment     sent=9   seg_us=364
>   tx_post_write  txlvl_before=9 sent=9 txlvl_after=12 pending_after=29
>                  post_gap_us=12 post_txlvl_us=130
> 
> Here TXLVL is free space, and the trigger is 8 free spaces. The driver
> read 9 free spaces and wrote 9 bytes, but the post-write read still saw
> 12 free spaces with data pending. Even allowing for the post-write read
> window, the FIFO was not reliably pushed below the trigger, so no new
> threshold crossing was expected. All failing samples I have checked show
> the same pattern.

That now makes sense.

One extra thing you might check.
Does filling the tx buffer clear the IER bit?
If it does you can save a slow read by doing the tx-refill first (when
there it tc data pending).

You might also be able to leave the tx interrupt permanently enabled.
It seems to be triggered by crossing the threshold rather than being
based on space in the fifo.

Did you try putting the second scope channel of the spi clock/data
to get the scope to show you the pattern of transfers and the latencies?

	David

  reply	other threads:[~2026-07-07 17:50 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-23 11:22 [PATCH 0/2] serial: sc16is7xx: fix TX inter-frame gaps on SPI UARTs Paul Mbewe
2026-06-23 11:22 ` [PATCH 1/2] serial: sc16is7xx: fix TX gap caused by kfifo circular buffer wrap-around Paul Mbewe
2026-06-23 11:22 ` [PATCH 2/2] serial: sc16is7xx: set TX FIFO trigger level to half FIFO to prevent underruns Paul Mbewe
2026-06-23 12:45   ` David Laight
2026-06-23 14:01     ` Paul Mbewe
2026-06-23 15:07       ` David Laight
2026-06-23 17:13         ` Paul Mbewe
2026-06-23 18:42           ` David Laight
2026-06-25 12:59             ` Maarten Brock
2026-07-01 16:40               ` Paul Mbewe
2026-07-01 17:41                 ` David Laight
2026-07-02 12:17                   ` Maarten Brock
2026-07-02 21:24                     ` David Laight
2026-07-03 18:19                       ` Paul Mbewe
2026-07-03 20:36                         ` David Laight
2026-07-07 15:03                           ` Paul Mbewe
2026-07-07 17:50                             ` David Laight [this message]
2026-07-10 12:43                               ` Paul Mbewe
2026-07-10 12:11 ` [PATCH 0/2] serial: sc16is7xx: fix TX inter-frame gaps on SPI UARTs Greg KH

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=20260707185025.2645b7b4@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=Maarten.Brock@sttls.nl \
    --cc=crescentcy.hsieh@moxa.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hvilleneuve@dimonoff.com \
    --cc=jirislaby@kernel.org \
    --cc=joachim.knorr@ziehl-abegg.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=paultyson.mbewe@ziehl-abegg.de \
    --cc=tobias.gannert@ziehl-abegg.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox