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