> I don't think the com(4) part of the diff is quite right. This busy > indicator feature seems to be specific to the Designware core. I > can't find the original NS16750 datasheet (was there ever one?), but > it isn't present on any of the true 16750 clones. So I think that > instead of adding a COM_HW_IIR_BUSY flag, we should add a > COM_UART_DWAPB type and use that to signal the presence of this > feature.
Patrick send me a newer version of the diff with better documentation. And that makes the same is clear to me. At least one of these flags should be changed to make sure it is narrowly specific to this particular defective chip implementation. > The comments should certainly not mention the NS16750. Right. In any case it is not a NS16750. It is a fresh piece of hardware, that mostly behaves like a NS16750, except in at least this way. (A whole generation of shitty chips are supersets of NS16750). > But I'd also like to look at the documentation to see if there way to > work around this issue. It seems that the interrupt handlers is > simply waiting for the FIFO to drain. It would really surprise me if > that is really necessary. I suspect the chip was implimented as a microcode, and they made a mistake, so they added a flag. It am guessing the interrupt stays asserted. Stalling in the interrupt handler seems odd. I'm going to guess this only happens once, at startup? That might match Mark's theory.
