Re: Problems after enabling rcv/xmit interrupts of ns16550 on OMAP5

[Ian Campbell <Ian.Campbell@citrix.com>]

> > > "restoring CPSR" refers to the instruction "msr CPSR_c, <reg>" which
> > > is from "local_irq_restore". And "cpsie i" is from the call to
> > > local_irq_enable".
> > 
> > Ah right. So in both cases you will immediately take any pending
> > interrupt. I think I would continue instrumenting starting from
> > gic_interrupt() and hopefully eventually into the ns16550 interrupt
> > handler.
> > 
> 
> I went through gic_interrupt() and thought got the points cause the stuck.

Please can you clarify exactly what you mean by "stuck". Previously you
thought it was stuck in ns16550_setup_postirq when in actual fact it was
taking an interrupt. Are you sure that you are taking multiple,
potentially nested interrupts and eventually blowing the hypervisor
stack? This seems like the most likely scenario to me.

> If I change the while(...) in ns16550_interrupt() into if(...) and comment
> either "GICC[GICC_EOIR] = irq;" or "GICC[GICC_DIR] = irq;" in
> git_host_irq_end(), it won't get stuck after enabling receive and transmit
> interrupts in ns16550_setup_postirq().

By removing the writes to either EOIR or DIR you are in effect never
unmasking the interrupt, so you avoid the nest interrupt problem.

If this is the case then real issue is perhaps that for whatever reason
ns16550_interrupt is not causing the hardware to deassert its interrupt
line.

The UART on the sunxi is compatible (in DTS terms) with
"snps,dw-apb-uart", which seems to be an 8250 variant, but one which
differs enough to warrant its own compatibility string -- perhaps Xen's
ns16550 driver isn't dealing with some quirk of this device?

It seems like the driver in Linux is drivers/tty/serial/8250/8250_dw.c.
dw8250_handle_irq looks interesting...

        struct dw8250_data *d = p->private_data;
        unsigned int iir = p->serial_in(p, UART_IIR);

        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, DW_UART_USR);
                p->serial_out(p, UART_LCR, d->last_lcr);

                return 1;
        }

        return 0;

In particular the fallback code there when the common 8250 handler
didn't deal with the issue...

Ian.