Skip to content

Conversation

@nbuchwitz
Copy link
Contributor

Follow up of #7180

(maybe better to pick the commit into the original PR, which contains the discussion)

miroslav-ondra and others added 3 commits January 23, 2026 14:45
commit 2c1fd53 upstream.

Data loss on serial line was observed during communication through
serial ports ttyAMA1 and ttyAMA2 interconnected via RS485 transcievers.
Both ports are in one BCM2711 (Compute Module CM40) and they share
the same interrupt line.

The problem is caused by long waiting for tx queue flush in the function
pl011_rs485_tx_stop. Udelay or mdelay are used to wait.
The function is called from the interrupt handler. If multiple devices
share a single interrupt line, late processing of pending interrupts
and data loss may occur. When operation of both devices are synchronous,
collisions are quite often.

This rework is based on the method used in tty/serial/imx.c
Use hrtimer instead of udelay and mdelay calls.
Replace simple bool variable rs485_tx_started by 4-state variable
rs485_tx_state.

Tested-by: Lino Sanfilippo <[email protected]>
Signed-off-by: Miroslav Ondra <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
pl011_axi_probe was missing the equivlent hrtimer initialisation
from commit 2c1fd53 ("serial: amba-pl011: Fix RTS handling in RS485 mode")
and commit 8cb4418 ("serial: amba-pl011: Switch to use hrtimer_setup()")
resulting in the kernel blowing up as soon as pl011_rs485_stop_tx
tried to use them.

Add the hrtimer initialisation.

Fixes: 120c89e ("serial: pl011: rp1 uart support")
Signed-off-by: Dave Stevenson <[email protected]>
The hrtimer-based TX drain introduced in commit 2c1fd53 ("serial:
amba-pl011: Fix RTS handling in RS485 mode") can cause RX errors in
fast request/response RS485 protocols. The hrtimer callback latency
(often 50-100µs per iteration) delays RX re-enable, causing the first
bytes of slave responses to be lost.

Add a configurable bounded polling mode that spins for TX completion
with a timeout, falling back to hrtimer only if the timeout is exceeded.
This is controlled by two new device tree properties:

  rs485-tx-drain-poll    - enable bounded polling mode
  rs485-tx-drain-timeout-us - explicit timeout in microseconds (optional)

When rs485-tx-drain-poll is set without an explicit timeout, the timeout
is auto-calculated as (fifo_size + 1) * character_time, accounting for
the FIFO depth plus one character in the shift register. This adapts
automatically to baud rate changes.

The default behavior (no DT properties) remains unchanged, preserving
the pure hrtimer approach for systems where shared IRQ latency is the
primary concern.

Signed-off-by: Nicolai Buchwitz <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants