Re: [Minios-devel] [UNIKRAFT PATCHv2 6/7] plat/common: Add a platform API to get IRQ from device tree

[Marc Zyngier <marc.zyngier@xxxxxxx>]

On Fri, 28 Jun 2019 06:26:36 +0100,
Julien Grall <Julien.Grall@xxxxxxx> wrote:
> 
> (+ Marc Z.)
> 
> Hi,
> 
> On 28/06/2019 03:39, Jianyong Wu (Arm Technology China) wrote:
> >>> +
> >>> +int gic_get_irq_from_dtb(const void *fdt, int nodeoffset, int index)
> >>> +{
> >>> + fdt32_t *prop;
> >>> + int type, hwirq, size;
> >>> + int ret;
> >>> +
> >>> + ret = fdt_get_interrupt(fdt, nodeoffset, index, &size, &prop);
> >>> + if (ret < 0)
> >>> +         return -EINVAL;
> >>> +
> >>> + type = fdt32_to_cpu(prop[0]);
> >>> + hwirq = fdt32_to_cpu(prop[1]);
> >>> +
> >>> + return gic_irq_translate(type, hwirq); }
> >>>
> >>
> >> How do you plan to handle prop[3] (i.e level-sensitive, edge-triggered)?
> > 
> > Er, as far as I know, we can get irq number just by interrupt type and its 
> > hardware number in dt
> > And no need to care about its trigger type. So we neglect the prop[3] here.
> 
> Why don't you need to care about trigger type? Per the spec, the initial 
> value of GICD_ICFGRn is IMPLEMENTATION DEFINED. I am actually not 
> convinced the register will contain the correct value at boot.
> 
> At least in Xen (and Linux?) we are setting the type when setting the 
> IRQ up. Maybe Marc can confirm here?

Programming GICD_ICFGRn is definitely not optional. Nothing guarantees
that the register state matches the signalling used by the
end-point. How could the GIC know what is connected to it?

Thanks,

        M.

-- 
Jazz is not dead, it just smells funny.

_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel