Re: [Xen-devel] Problems after enabling rcv/xmit interrupts of ns16550 on OMAP5

[Chen Baozi <baozich@xxxxxxxxx>]

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@xxxxxxxxxx> wrote:
> > 
> > > On Wed, 2013-07-17 at 16:02 +0800, Chen Baozi wrote:
> > >> On Jul 12, 2013, at 3:41 PM, Chen Baozi <baozich@xxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel