On 08/05/16 13:25, Jon Hunter wrote: > Hi Geert, > > On 07/05/16 15:10, Geert Uytterhoeven wrote: >> Hi Jon, >> >> On Fri, May 6, 2016 at 10:32 AM, Jon Hunter <jonathanh@xxxxxxxxxx> wrote: >>>> The "nvidia,tegra210-agic" string can be taken as describing any >>>> Tegra-210 specific integration quirks, though I agree that's also not >>>> fantastic for extending PM support beyond Tegra 210 and variants >>>> thereof. >>>> >>>> So maybe the best approach is bailing out in the presence of clocks >>>> and/or power domains after all, on the assumption that nothing today has >>>> those properties, though I fear we may have problems with that later >>>> down the line if/when people describe those for the root GIC to describe >>>> those must be hogged, even if not explicitly managed. >>> >>> On further testing, by bailing out in the presence of clocks and/or >>> power-domains, the problem I now see is that although the primary gic-400 >>> has been registered, we still try to probe it again later as it matches >>> the platform driver. One way to avoid this would be ... >>> >>> diff --git a/drivers/of/irq.c b/drivers/of/irq.c >>> index e7bfc175b8e1..631da7ad0dbf 100644 >>> --- a/drivers/of/irq.c >>> +++ b/drivers/of/irq.c >>> @@ -556,6 +556,8 @@ void __init of_irq_init(const struct of_device_id *matches) >>> * its children can get processed in a subsequent pass. >>> */ >>> list_add_tail(&desc->list, &intc_parent_list); >>> + >>> + of_node_set_flag(desc->dev, OF_POPULATED); >>> } >> >> That sounds like the right thing to do to me... > > OK. The more I think about this, it does seem silly to create a device > and pdata for a device that has already been instantiated. > >>> If this is not appropriate then I guess I will just need to use >>> "tegra210-agic" for the compatibility flag. >> >> As I want this for plain gic-400, I'd be unhappy ;-) > > No problem. However, there is more work that would be needed to get this > to work for root controllers which I think that you want. All this brings the discussion back to the root of the problem: irqchips (and timers) are not first class devices, because we need them too early for that. I'd really like to solve this, but the kernel init is incredibly complicated, and the subsystem dependencies completely undocumented. It looks like we need the timer early because the we fork a thread for PID-1, and the scheduler is going to need some form of tick. So ideally, we'd be able to move the irq/timer stuff *after* the device framework (which itself requires devtmpfs to be up and running, hence dragging the whole VM and VFS), but before the scheduler is initialized. I'm sure there is plenty of other dependencies I haven't worked out yet. If anyone has some spare time and willing to help, please speak now! ;-) Thanks, M. -- Jazz is not dead. It just smells funny... -- 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
