Open ch-f opened 6 months ago
It seems to me that the RX DMA code in the PL011 driver is incompatible with break handling. The break indication is carried with the error flags in the top 4 bits of a 12-bit wide FIFO. The DMA RX code treats this as an 8-bit register, ignoring the flags, and hence ignoring/mishandling breaks. Disabling DMA (or at least in the RX path), something that can be achieved in DT - perhaps as a parameter - seems like the only sure way round this. Even if the DMA had a width of 16 or 32 bits, which would need post-processing to look for errors and extract the data, it's not clear if it would then work correctly.
if (ch & UART011_DR_BE)
flag = TTY_BREAK;
else if (ch & UART011_DR_PE)
flag = TTY_PARITY;
else if (ch & UART011_DR_FE)
flag = TTY_FRAME;
<snip>
uart_insert_char(&uap->port, ch, UART011_DR_OE, ch, flag);
@pelwell Are you referring to this handling here?
Doesn't 'ch' get intentionally truncated (so that the data byte becomes 0x00) while BREAK information is carried within the 8-bit 'flag'?
It would be nice to identify the root cause before considering introduction of a dts flag to disable RX DMA. Do you think this issue should be escalated mainline?
Yes, that's the non-DMA code that reads the full 12-bit values and looks at the flags. The DMA path just reads the lower 8 bits.
Describe the bug
UART (/dev/ttyAMBA0) erroneously receives only around 32 bytes of mostly incorrect data during transmissions containing long break signals.
Disabling DMA_ENGINE for amba-pl011 resolves the issue, ensuring accurate reception of all data (77 bytes).
Steps to reproduce the behaviour
Tx from host sending to Raspberry Pi 5:
long-break, 0x55, 0xe2, 0xf9, 0xf9, 0xf9, 0xf9, 0xf9, 0xf9, 0xf9, 0xf9, 0x30
Rx flowing into Raspberry Pi 5:
C test program for host to generate the Tx data (including long breaks):
Device (s)
Raspberry Pi 5
System
Tested on a Raspberry Pi 5 with kernel from current branch rpi-6.8.y (6.8.0-rc5 + Raspberry patches).
Logs
No response
Additional context
No response