Re: Keystone Issue

[CodeWiz2280 <codewiz2280@xxxxxxxxx>]

On Tue, Jun 9, 2020 at 11:47 AM Julien Grall <julien@xxxxxxx> wrote:
>
>
>
> On 09/06/2020 16:28, Bertrand Marquis wrote:
> > Hi,
> >
> >> On 9 Jun 2020, at 15:33, CodeWiz2280 <codewiz2280@xxxxxxxxx> wrote:
> >>
> >> There does appear to be a secondary (CIC) controller that can forward
> >> events to the GIC-400 and EDMA controllers for the keystone 2 family.
> >> Admittedly, i'm not sure how it is being used with regards to the
> >> peripherals.  I only see mention of the GIC-400 parent for the devices
> >> in the device tree.  Maybe Bertrand has a better idea on whether any
> >> peripherals go through the CIC first?  I see that gic_interrupt ()
> >> fires once in Xen, which calls doIRQ to push out the virtual interrupt
> >> to the dom0 kernel.  The dom0 kernel then handles the interrupt and
> >> returns, but gic_interrupt() never fires again in Xen.
> >
> > I do not remember of any CIC but the behaviour definitely look like an 
> > interrupt acknowledge problem.
> >
> > Could you try the following:
> > --- a/xen/arch/arm/gic-v2.c
> > +++ b/xen/arch/arm/gic-v2.c
> > @@ -667,6 +667,9 @@ static void gicv2_guest_irq_end(struct irq_desc *desc)
> >       /* Lower the priority of the IRQ */
> >       gicv2_eoi_irq(desc);
> >       /* Deactivation happens in maintenance interrupt / via GICV */
> > +
> > +    /* Test for Keystone2 */
> > +    gicv2_dir_irq(desc);
> >   }
> >
> > I think the problem I had was related to the vgic not deactivating properly 
> > the interrupt.
>
This seemed to help with the edge triggered interrupts, e.g. UART

> Are you suggesting the guest EOI is not properly forwarded to the
> hardware when LR.HW is set? If so, this could possibly be workaround in
> Xen by raising a maintenance interrupt every time a guest EOI an interrupt.
>
> > This might make the interrupt fire indefinitely !!
>
> Most likely with level interrupt ;).
>
This is what's happening with the Ethernet driver which is level
triggered.  I had to temporarily disable it
to check the patch with the UART driver, otherwise the system would
hang processing the interrupt
repeatedly.
> Cheers,
>
> --
> Julien Grall