On Mar 27, 2012 7:07 PM, "Arnd Bergmann" <[email protected]> wrote: > > On Tuesday 27 March 2012, Viresh Kumar wrote: > > On 3/27/2012 4:45 PM, Arnd Bergmann wrote: > > > On Tuesday 27 March 2012, Viresh Kumar wrote: > > > The normal way is to turn around the logic so you don't have to include this test > > > at all. Just have one soc-specific init_machine and map_io function, that calls > > > both soc-specific and shared soc functions, e.g. > > > > But with that, i need multiple DT_MACHINE_START(). Isn't it? > > Is this advisable? > > Having one DT_MACHINE_START per soc is ok if it helps you. Of course if you > have multiple ones that are basically identical, it's simpler to just > combine them.
That's what i have done in V1. And then only i came to The first problem i mentioned. > > > In case of the clocks, I think you could already merge all the clk_lookup > > > arrays into one, which would result in a larger kernel image but should > > > do no harm otherwise. > > > > Actually we can't do it. :( > > If i boot 300 then i will also get clocks of 310 and 320 in my clock list. > > And once i go through this clock list to create clock tree (parent-child > > relationship), i will try to access hardware registers of 310 & 320, > > which are just not valid for 300. Kernel Crash!! > > Ok, I see. BTW, have you tried what I first recommended to you, which is > to check the compatible property of the clock node instead of the machine? I haven't. > Obviously that only works when you initialize the clocks from init_early() > instead of from map_io(), but I think that would be the cleanest choice > if you want to have single function with run-time dependencies. But then why not use machine_init() for doing this too. -- Viresh
_______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
