serial: amba-pl011: Fix RTS handling in RS485 mode

[pelwell]

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

Link: https://lore.kernel.org/r/20241221-amba-rts-v3-1-d3d444681419@faster.cz

[nbuchwitz]

hrtimer_init(&uap->trigger_start_tx, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
hrtimer_init(&uap->trigger_stop_tx, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
uap->trigger_start_tx.function = pl011_trigger_start_tx;
uap->trigger_stop_tx.function = pl011_trigger_stop_tx;

is missing in pl011_axi_probe() in order to make this work with rp1

[pelwell]

Like this?

[nbuchwitz]

Yes, that's the same as what I tested here.

There is still a significant performance regression (essentially unusable) with our RS485-based backplane driver. I would really appreciate holding off on the merge until we have investigated this further. Otherwise, we would need to revert this downstream.

[pelwell]

It's going nowhere for now.