Hi,
I finished my analysis of the imx RS-485 DMA problem, we discussed on
the list before and which was fixed upstream with commit 514ab34dbad6
("serial: imx: Prevent TX buffer PIO write when a DMA has been started")
from Ian.
Open questions were:
1) Why did this only appear on SMP machines?
2) Why did this only affect RS-485?
Thanks to ftrace, I can now answer both:
1) When starting a new transmission, the following happens in
imx_start_tx:
After imx_port_rts_active to enable the external RS-485 transceiver,
the transmit-complete-interrupt is enabled (TCEN).
Then, imx_dma_tx is called and the DMA request is handed off.
Now, while sdma_prep_slave_sg and sdma_load_context are executing on one
CPU core, imx_int is called on another, because the previously enabled
interrupt asserted immediately (TXDC was active because both the TxFIFO
and the Shifter were empty) after enabling it. (50us on i.MX6Q SMP)
This leads to the transmit_buffer function (called from imx_int/imx_txint)
writing to UTXD which corrupts the ongoing DMA transmission and also leads to
xmit->tail getting double-incremented and jumping over xmit->head, so the whole
UART_XMIT_SIZE xmit buffer is sent out.
On non-SMP machines, the interrupt is handled later when
uart_circ_empty(xmit) is already true and transmit_buffer returns before
doing PIO. With a non-SMP kernel on an i.MX6Q, I measured 35ms until
imx_int/imx_txint and the function_graph trace showed
imx_txint()
imx_stop_tx()
(Instead of a trace_printk I added to the PIO loop in transmit_buffer)
2) The transmit-complete-interrupt (TCEN) is only used in RS-485 mode.
--
Cheers,
Clemens
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
