HI Lothar,
Hi,
On Tue, 3 Oct 2017 11:16:45 +0200 Lukasz Majewski wrote:
It may happen that the MXC serial IP block is performing some ongoing transmission (started at e.g. board_init()) when the "initr_serial" is called.
As a result the serial port IP block is reset, so transmitted data is corrupted:
I2C: ready DRAM: 1 GiB jSS('HH��SL_SDHC: 04 rev 0x0
This patch prevents from this situation, by waiting for transmission complete bit set (UART Status Register 2 (UARTx_USR2), bit TXDC):
I2C: ready DRAM: 1 GiB ID: unit type 0x4 rev 0x0
Signed-off-by: Lukasz Majewski lukma@denx.de
drivers/serial/serial_mxc.c | 7 +++++++ 1 file changed, 7 insertions(+)
diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c index cce80a8..ef4eb12 100644 --- a/drivers/serial/serial_mxc.c +++ b/drivers/serial/serial_mxc.c @@ -141,6 +141,13 @@ struct mxc_uart {
static void _mxc_serial_init(struct mxc_uart *base) {
- /*
* Wait for any ongoing transmission to finish - for example* from pre-relocation enabled UART*/- while (!(readl(&base->sr2) & USR2_TXDC))
;Loops that poll for HW activated bits should always have a timeout. Hardware will definitely break some day and deliver unexpected results. Software should cope with this as best as it can!
In principle yes.
Please find below rationale for this patch:
1. According to imx6q this bit shows emptiness of TxFIFO and Shift register [1]. It seems like a purely HW controlled bit.
2. Having timeout here would require first initialization of timer. However, this code is also used in a very early console initialization.
3. In Linux kernel [2] the same check is performed with:
while (!(readl(sport->port.membase + USR2) & USR2_TXDC)) barrier();
[1] - Transmitter Complete. Indicates that the transmit buffer (TxFIFO) and Shift Register is empty; therefore the transmission is complete. TXDC is cleared automatically when data is written to the TxFIFO.
[2] - http://elixir.free-electrons.com/linux/v4.2/source/drivers/tty/serial/imx.c#...
Lothar Waßmann