[PATCH] ARM: SPEAr600: Add device-tree support to SPEAr600 boards

[viresh kumar]

On Mar 27, 2012 7:07 PM, "Arnd Bergmann" <arnd at arndb.de> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20120327/b6b0484c/attachment-0001.html>