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

[Chen Baozi <baozich@gmail.com>]

On Wed, Jul 17, 2013 at 10:21:52AM +0100, Ian Campbell wrote:
> On Wed, 2013-07-17 at 17:01 +0800, Chen Baozi wrote:
> > On Jul 17, 2013, at 4:21 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> > 
> > > 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?
> > 
> > No idea. It seems the UART's receive interrupt works well, because pressing "d" in the serial console could trigger dumping registers as normal. I'm going into these possibilities and trying to make it sure.
> > 
> > > (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
> > 
> > "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.

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().

Baozi