[PULL REQUEST v2] ARM: kirkwood: fdt: convert kirkwood init funcs to fdt

[Jason]

On Mon, Mar 05, 2012 at 04:27:27PM -0500, Nicolas Pitre wrote:
> On Mon, 5 Mar 2012, Jason wrote:
> 
> > On Mon, Mar 05, 2012 at 03:43:42PM -0500, Nicolas Pitre wrote:
> > > On Mon, 5 Mar 2012, Jason wrote:
> > > 
> > > > On Mon, Mar 05, 2012 at 08:16:26PM +0000, Arnd Bergmann wrote:
> > > > > On Monday 05 March 2012, Jason wrote:
> > > > > > > 
> > > > > > > The clock frequency part being hardcoded to 200000 in the common .dtsi 
> > > > > > > file looks wrong.  The clock may differ, and it used to (and should) be 
> > > > > > > probed at run time, please see kirkwood_find_tclk().
> > > > > > 
> > > > > > So, should I EXPORT_SYMBOL_GPL(kirkwood_find_tclk); and have each driver
> > > > > > call it?
> > > > > 
> > > > > If the drivers want to use it, I think it has to be orion_find_tclk for
> > > > > drivers that are shared between multiple plat-orion platforms.
> > > > 
> > > > That's pretty much all of them  :-)
> > > > 
> > > > I'll rename it and move it to plat-orion/common.c.  This'll be fun.
> > > 
> > > No no...  This is not a function which is generic at all.  The _result_ 
> > > i.e. core clock frequency value is a generic thing, not the method to 
> > > determine it.
> > 
> > How about this?  Export a global variable, orion_tclk, and a function to
> > read it.  Then, make sure each sub arch sets the global.  Does this
> > sound viable until common clk lands?
> 
> Yep, looks fine.

I just got a first look at Andrew's patches for using the generic clk
across plat/orion.  There's a lot of good stuff in there.  I'll start
building my series on top of his (and obviously Mike's clk series).

thx,

Jason.