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

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

[Jason]

The following changes since commit 759a45185ac0e4dfaf8bbfcb390ec73aca4b7a34:

  ARM: kirkwood: convert uart0 to devicetree. (2012-02-27 16:21:44 +0000)

are available in the git repository at:
  git://git.infradead.org/users/jcooper/linux-kirkwood.git kirkwood_dt_test

Jason Cooper (5):
      ARM: kirkwood: covert orion-spi to fdt.
      ARM: kirkwood: move var setting to correct location.
      ARM: kirkwood: fdt: absorb kirkwood_init()
      ARM: kirkwood: convert rtc-mv to fdt.
      ARM: kirkwood: convert orion-wdt to fdt.

 arch/arm/boot/dts/kirkwood-dreamplug.dts |   34 +++++++++++++++
 arch/arm/boot/dts/kirkwood.dtsi          |   12 +++++
 arch/arm/mach-kirkwood/board-dt.c        |   67 +++++++++++------------------
 arch/arm/mach-kirkwood/common.c          |   21 +++++++--
 arch/arm/mach-kirkwood/common.h          |    6 +++
 arch/arm/plat-orion/common.c             |    7 +++-
 drivers/rtc/rtc-mv.c                     |    7 +++
 drivers/spi/spi-orion.c                  |   37 +++++++++++++++--
 drivers/watchdog/orion_wdt.c             |   46 +++++++++++++++-----
 9 files changed, 174 insertions(+), 63 deletions(-)

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

[Arnd Bergmann]

On Friday 02 March 2012, Jason wrote:
> The following changes since commit 759a45185ac0e4dfaf8bbfcb390ec73aca4b7a34:
> 
>   ARM: kirkwood: convert uart0 to devicetree. (2012-02-27 16:21:44 +0000)
> 
> are available in the git repository at:
>   git://git.infradead.org/users/jcooper/linux-kirkwood.git kirkwood_dt_test
> 

Applied to next/dt branch.

Thanks,

	Arnd

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

[Arnd Bergmann]

On Friday 02 March 2012, Arnd Bergmann wrote:
> On Friday 02 March 2012, Jason wrote:
> > The following changes since commit 759a45185ac0e4dfaf8bbfcb390ec73aca4b7a34:
> > 
> >   ARM: kirkwood: convert uart0 to devicetree. (2012-02-27 16:21:44 +0000)
> > 
> > are available in the git repository at:
> >   git://git.infradead.org/users/jcooper/linux-kirkwood.git kirkwood_dt_test
> > 
> 
> Applied to next/dt branch.

On second thought, I should probably wait for the maintainer to comment
as well ;-)

Nico, does this look ok to you?

	Arnd

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

[Nicolas Pitre]

On Fri, 2 Mar 2012, Arnd Bergmann wrote:

> On Friday 02 March 2012, Arnd Bergmann wrote:
> > On Friday 02 March 2012, Jason wrote:
> > > The following changes since commit 759a45185ac0e4dfaf8bbfcb390ec73aca4b7a34:
> > > 
> > >   ARM: kirkwood: convert uart0 to devicetree. (2012-02-27 16:21:44 +0000)
> > > 
> > > are available in the git repository at:
> > >   git://git.infradead.org/users/jcooper/linux-kirkwood.git kirkwood_dt_test
> > > 
> > 
> > Applied to next/dt branch.
> 
> On second thought, I should probably wait for the maintainer to comment
> as well ;-)
> 
> Nico, does this look ok to you?

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().


Nicolas

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

[Jason]

On Mon, Mar 05, 2012 at 01:49:35PM -0500, Nicolas Pitre wrote:
> On Fri, 2 Mar 2012, Arnd Bergmann wrote:
> 
> > On Friday 02 March 2012, Arnd Bergmann wrote:
> > > On Friday 02 March 2012, Jason wrote:
> > > > The following changes since commit 759a45185ac0e4dfaf8bbfcb390ec73aca4b7a34:
> > > > 
> > > >   ARM: kirkwood: convert uart0 to devicetree. (2012-02-27 16:21:44 +0000)
> > > > 
> > > > are available in the git repository at:
> > > >   git://git.infradead.org/users/jcooper/linux-kirkwood.git kirkwood_dt_test
> > > > 
> > > 
> > > Applied to next/dt branch.
> > 
> > On second thought, I should probably wait for the maintainer to comment
> > as well ;-)
> > 
> > Nico, does this look ok to you?
> 
> 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?

One alternate idea I had was to have kirkwood-dreamplug.dts root hold

tclk: clock-frequency = <200000000>;

and then have the drivers ask for it.  afaict, tclk is constant per
board.

I'm fine with either way, but I'd rather have it in the dt.

thx,

Jason.

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

[Arnd Bergmann]

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.

> One alternate idea I had was to have kirkwood-dreamplug.dts root hold
> 
> tclk: clock-frequency = <200000000>;
> 
> and then have the drivers ask for it.  afaict, tclk is constant per
> board.
> 
> I'm fine with either way, but I'd rather have it in the dt.

IMHO it's best to leave any such hacks out of the device tree for
now, until we have the proper clk bindings in place for kirkwood,
and then we can just use those.

	Arnd

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

[Jason]

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.

> > One alternate idea I had was to have kirkwood-dreamplug.dts root hold
> > 
> > tclk: clock-frequency = <200000000>;
> > 
> > and then have the drivers ask for it.  afaict, tclk is constant per
> > board.
> > 
> > I'm fine with either way, but I'd rather have it in the dt.
> 
> IMHO it's best to leave any such hacks out of the device tree for
> now, until we have the proper clk bindings in place for kirkwood,
> and then we can just use those.

Ok.

thx,

Jason.

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

[Nicolas Pitre]

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.


Nicolas

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

[Jason]

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?

thx,

Jason.

btw - when I received your email I was in the middle of convincing
myself that I could hack together a common orion_find_tclk().  It was
rapidly becoming a bad idea.  :-)

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

[Nicolas Pitre]

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.


Nicolas

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

[Andrew Lunn]

> > 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.

Hi Jason

Maybe it is time to stop and consider a moment....

We have overlapping work going on. My adoption of Mike's generic clk
framework overlaps a lot with your DT tclk problems. If you introduce
orion_find_tclk() into all the drivers, we are probably going to rip
it all out again once my patches go in. Plus we are going to have
horrible merging conflicts between your code and my code

It seems more logical to get the clk code in first, then work on DT.

Could you task swap for a while? Maybe look at converting MPP to
pinmux and then add DT bindings for that. No tclk needed :-)

       Andrew

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

[Jason]

On Mon, Mar 05, 2012 at 10:41:26PM +0100, Andrew Lunn wrote:
> > > 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.

This is old, see Nico's reply and my response.

> We have overlapping work going on. My adoption of Mike's generic clk
> framework overlaps a lot with your DT tclk problems. If you introduce
> orion_find_tclk() into all the drivers, we are probably going to rip
> it all out again once my patches go in. Plus we are going to have
> horrible merging conflicts between your code and my code

I'd love to deconflict but I haven't seen your RFC patches, yet.

thx,

Jason.

Re: [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.