Designware UART bug

From: Olliver Schinagl
Date: Wed May 03 2017 - 06:18:08 EST

Hey Jamie,

Several years ago you wrote the glue-code [0] for the DW 8250 IP. Over the years various 'fixes' have been applied to resolve certain 'weird' problems that Tim tried to fix with [1].

After going over the datasheets and code with a comb several times now, I think I may have found one (of a few others) reasons and would like both your and Tim's thoughts here.

The current (and original) code [2] uses the register offset 0x1f for the UART_USR register.

I searched far and wide, various datasheet of physical uarts (8250 - 16950) and some IP cores and none seem to have the USR (and specifically the USR[0] bit) register, so it seems to be specific to the DW_apb_uart. However looking at the only databook available to me [3] of the UART IP, I cannot seem to find anything at register offset 0x1f.

The platform I'm using uses the Allwinner A20 SoC, which also features the DW uart IP and also here, there is nothing at offset 0x1f.

The intended register IS however actually at 0x7c.

My question is thus twofold.

Why was 0x1f used? Is this specific to a certain (version) UART or is this a long uncaught typo.

Tim, assuming it is a typo, could this the cause which made you implement [1]? From what I understand, you keep writing the LCR until it takes.

Initially, the UART_IIR_BUSY check looked like this:
if (serial8250_handle_irq(p, iir)) {
return 1;
} else if ((iir & UART_IIR_BUSY) == UART_IIR_BUSY) {
/* Clear the USR and write the LCR again. */
(void)p->serial_in(p, d->usr_reg);
p->serial_out(p, UART_LCR, d->last_lcr);

return 1;

what I'm missing here is, that if UART_IIR_BUSY is set, we have:
* check the d->usr_reg (UART_USR) bit 0
* wait until it becomes cleared (do not allow new data to be pushed out, optionally force the data to be pushed out)
* write LCR register (and check if it took (and no longer loop over the LCR to see if the values stuck, in theory).
* if we never get un-busy, something is wrong?

All of this btw is currently moot anyway, as the only way to get into the (else) if, is if serial8250_handle_irq returns false. And from what I can see, this is only if iir == UART_IIR_NO_IRQ, in which case we never ever clear the USR and thus never ever clear the UART_IIR_BUSY flag.