Hi again, On 5/16/2024 9:22 PM, Doug Brown wrote:
I'm hoping there is some kind of simple fix that can be made to the pxa driver to work around it with this new behavior. Can anyone think of a reason that this driver would not like this change? It seems counterintuitive to me -- the patch makes perfect sense.
After further experimentation, I've come to the conclusion that this is a bug in the pxa uart driver, and this patch simply exposed the bug. I'll submit a patch to fix the issue in the pxa driver. If anyone's interested in the details: basically, the pxa driver in its current state doesn't work correctly if it receives a TX interrupt when the circular buffer is empty. It handles it, but then gets stuck waiting for the next TX IRQ that will never happen because no characters were transmitted. The way stop_tx() was previously being called before the transmitter was empty, it prevented that situation from happening because toggling the TX interrupt enable flag off (with stop_tx) and back on (with the next start_tx) causes a new TX interrupt to fire and kickstarts the transmit process again. The 8250 driver, for example, isn't affected by this problem because it effectively does stop_tx() on its own if it detects an empty circular buffer in the TX interrupt handler. Adding similar logic to the pxa driver fixes it. Doug
