On Tue, 7 May 2013, Lorenzo Pieralisi wrote: > On Mon, May 06, 2013 at 04:05:28PM +0100, Nicolas Pitre wrote: > > When compiled in, module_init() is translated into device_initcall(). > > This is way too late for bringing up secondary CPUs during boot via the > > MCPM layer. That is not an issue as far as the code presented here is > > concerned since there is no integration with MCPM yet, but eventually > > we'd want the MCPM power_up_setup method to integrate with the port > > discovery performed here instead of having them hardcoded in the > > assembly code. This means it would have to become early_initcall() > > instead. And at that point the driver infrastructure isn't fully > > operational, meaning that driver_probe() won't be usable either (looking > > at what we did to the TC2 spc init code is a good example of what I mean > > here). > > Yes, I thought about that. This means that CCI driver should not rely on > platform device structs, and yes I can mirror SPC probing code to take care > of ordering issues. I am quite tempted to remove the platform device/driver > infrastructure altogether and just rely on the DT layer (as GIC, PL310 > do) to initialize CCI. What do you think ?
I think that's probably the best approach. That's what we ended up doing to the spc code for the same reasons. > I think I will leave the > platform driver infrastructure, and at probe it will check if data > structures have already been initialized by an exported function, say: > > cci_of_init() Please let's try to avoid propagating the "of" acronym further. We don't use Open Firmware here. Using "dt" is more appropriate IMHO. > if the data structures are already initialized basically the probe > function will do precious little and just succeeds otherwise it will > initialize the driver as it does now. > > Is there really a point in having the CCI driver represented as a > platform driver ? Not sure at all. I'm not sure either. Nicolas _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
