On Wed, Apr 27, 2016 at 04:34:53PM +0100, Jon Hunter wrote: > > On 22/04/16 12:22, Mark Rutland wrote: > > [snip] > > >>>> I am not sure if it will be popular to add Tegra specific clock names > >>>> to the GIC DT docs. However, in that case, then possibly the only > >>>> alternative is to move the Tegra AGIC driver into its own file and > >>>> expose the GIC APIs for it to use. Then we could add our own DT doc > >>>> for the Tegra AGIC as well (based upon the ARM GIC). > >>> > >>> The clock-names don't seem right to me, as they sound like provide names > >>> or global clock line names rather than consumer-side names ("clk" and > >>> "apb_pclk"). > >> > >> Yes that would be fine with me. > > > > Ok; if we model the apb_pclk as owned by the AXI switch (which it is), > > then there's no change for the GIC binding, short of the additional > > compatible string as an extension of "arm,gic-400", as we already model > > that clock in the GIC-400 binding. > > I have been re-working this based upon the feedback received. In the GIC > driver we have the following definitions ... > > IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init); > IRQCHIP_DECLARE(arm11mp_gic, "arm,arm11mp-gic", gic_of_init); > IRQCHIP_DECLARE(arm1176jzf_dc_gic, "arm,arm1176jzf-devchip-gic", gic_of_init); > IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init); > IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init); > IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init); > IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init); > IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init); > IRQCHIP_DECLARE(pl390, "arm,pl390", gic_of_init); > > > If I have something like the following in my dts ... > > agic: interrupt-controller@702f9000 { > compatible = "nvidia,tegra210-agic", "arm,gic-400"; > ... > }; > > The problem with this is that it tries to register the interrupt controller > early during of_irq_init() before the platform driver has chance to > initialise it. Probe order strikes again... > To avoid this I got rid of the "nvidia,tegra210-agic" string and added > the following for the platform driver ... > > static const struct of_device_id gic_match[] = { > { .compatible = "arm,arm11mp-gic-pm", .data = &arm11mp_gic_data }, > { .compatible = "arm,cortex-a15-gic-pm", .data = &cortexa15_gic_data }, > { .compatible = "arm,cortex-a9-gic-pm", .data = &cortexa9_gic_data }, > { .compatible = "arm,gic400-pm", .data = &gic400_data }, > { .compatible = "arm,pl390-pm", .data = &pl390_data }, > {}, > }; > > It is not ideal as now we have a *-pm variant of each compatible string :-( Yeah, that's a non-starter. :( > Another option would be to add some code in gic_of_init() to check for the > presence of a "clocks" node in the DT binding and bail out of the early > initialisation if found but may be that is a bit of a hack. I fear that someone may validly have a clocks property in their root GIC node, at which point things would fall apart. I was under the impression this was the case for some Renesas boards (though I didn't find an example in tree). So I suspect that using the clocks property in that way isn't going to work out well. > Mark, what are your thoughts on this? Collectively: "aargh", "oh no". We could instead explicitly match "nvidia,tegra210-agic", bailing out if we see that. Otherwise, if we can't handle it like a GIC-400, then we can just drop the GIC-400 compatible string from the fallback list. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html