Re: [PATCH 2/2] serial: sc16is7xx: set TX FIFO trigger level to half FIFO to prevent underruns

[David Laight]

On Tue, 7 Jul 2026 17:03:44 +0200
Paul Mbewe <paultyson.mbewe@xxxxxxxxxxxxxx> 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