> Date: Thu, 4 Aug 2016 13:47:36 +0200 > From: Marcus Glocker <mar...@nazgul.ch> > > 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.
The more I think about it, the more I think that using com(4) in this context is the wrong approach. The hardware probing and FIFO size probing that com(4) does is fairly undesirable. We should be able to determine the right parameters based on device tree properties. I also think that that when we attach the console on armv7 platforms we shouldn't have to reset the baudrate. This would remove the problem of hunting for the right clock rate. On top of that, the bus_space hack that we currently do to deal with the fact that most of these 16550-compatible uarts have registers that are 32 bits wide has its issues as well. That said, having a separate driver for subtly different type of almost 16550-compatible uart is undesirable as well. I think it makes sense to have a generic uart@fdt driver that doesn't have to deal with all the legacy stuff that com(4) deals with.
