WIP: pl011 with bounded polling for TX drain#7221
Draft
nbuchwitz wants to merge 3 commits intoraspberrypi:rpi-6.12.yfrom
Draft
WIP: pl011 with bounded polling for TX drain#7221nbuchwitz wants to merge 3 commits intoraspberrypi:rpi-6.12.yfrom
nbuchwitz wants to merge 3 commits intoraspberrypi:rpi-6.12.yfrom
Conversation
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 <l.sanfilippo@kunbus.com> Signed-off-by: Miroslav Ondra <ondra@faster.cz> Link: https://lore.kernel.org/r/20241221-amba-rts-v3-1-d3d444681419@faster.cz Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <dave.stevenson@raspberrypi.com>
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 <n.buchwitz@kunbus.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow up of #7180
(maybe better to pick the commit into the original PR, which contains the discussion)