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.

Reply via email to