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

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

On Wed, 2013-07-17 at 16:02 +0800, Chen Baozi wrote:
> On Jul 12, 2013, at 3:41 PM, Chen Baozi <baozich@gmail.com> wrote:
> 
> > This means you have neither registered the irq nor enabled the interrupts. If I turned both of these two blocks into:
> > 
> >    if ( uart->dt_irq.irq > )
> >    {
> >        ...
> >    }
> > 
> > There is the same phenomenon that I described in previous email. And If I comment either of these two blocks in my patch, my implementation works.
> > 
> > Any ideas?

Sorry for not replying to this, the answer was going to be "no, but I'll
see if I can reproduce" -- but I never got a chance.

> I inserted some codes in ns16550_setup_postirq to see what would cause
> the stuck. It seems that it will stuck while restoring CPSR or "cpsie
> i". But I'm not sure that these two cases are the only factors that
> will lead the phenomenons.

Does it get stuck or does it just immediately take another interrupt?
(Could indicate a level vs. edge misconfiguration perhaps?)

Is "restoring CPSR" this from arm32/entry.S:
        ENTRY(return_to_hypervisor)
                cpsid i
                ldr lr, [sp, #UREGS_lr]
                ldr r11, [sp, #UREGS_pc]
                msr ELR_hyp, r11
                ldr r11, [sp, #UREGS_cpsr]
                msr SPSR_hyp, r11
                pop {r0-r12}
                add sp, #(UREGS_SP_usr - UREGS_sp); /* SP, LR, SPSR, PC */
                eret
or elsewhere? If it is this one does changing SPSR_hyp into SPSR_cxsf change anything?

The "cpsie i" is from the call to local_irq_enable in gic_interrupt() or
somewhere else?

Ian.