On Wed, Aug 03, 2016 at 03:33:21PM -0600, Theo de Raadt wrote: > > 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.
In my case the sxiuart console works fine after startup until a certain situation happens. E.g. I can to 99% trigger the issue by starting top, and hit 's'. Afterwards sxiuart interrupts are stalled until the next reboot. Strange thing is that initially sxiuart can handle some busy interrupts. I don't know exactly what happens on top hit 's', maybe a lot of busy interrupts get triggered by then. I tried Patricks part of the diff which handles the busy interrupts directly in sxiuart, but the issue remains there.
