[RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms CLK_OF_DECLARE support

[Scott Wood]

On Fri, 2014-08-29 at 02:17 -0500, Lu Jingchang-B35083 wrote:
> >-----Original Message-----
> >From: Wood Scott-B07421
> >Sent: Friday, August 29, 2014 12:26 AM
> >To: Lu Jingchang-B35083
> >Cc: mturquette at linaro.org; linuxppc-dev at lists.ozlabs.org; linux-
> >kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> >Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms
> >CLK_OF_DECLARE support
> >
> >On Thu, 2014-08-28 at 05:05 -0500, Lu Jingchang-B35083 wrote:
> >> >-----Original Message-----
> >> >From: Wood Scott-B07421
> >> >Sent: Thursday, August 28, 2014 7:34 AM
> >> >To: Lu Jingchang-B35083
> >> >Cc: mturquette at linaro.org; linuxppc-dev at lists.ozlabs.org; linux-
> >> >kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> >> >Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based
> >> >platforms CLK_OF_DECLARE support
> >> >
> >> >On Tue, 2014-08-26 at 21:19 -0500, Lu Jingchang-B35083 wrote:
> >> >> >-----Original Message-----
> >> >> >From: Wood Scott-B07421
> >> >> >Sent: Wednesday, August 27, 2014 6:51 AM
> >> >> >To: Lu Jingchang-B35083
> >> >> >Cc: mturquette at linaro.org; linuxppc-dev at lists.ozlabs.org; linux-
> >> >> >kernel at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> >> >> >Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based
> >> >> >platforms CLK_OF_DECLARE support
> >> >> >
> >> >> >On Fri, 2014-08-22 at 17:34 +0800, Jingchang Lu wrote:
> >> >> >> +CLK_OF_DECLARE(ppc_core_pll_v1, "fsl,qoriq-core-pll-1.0",
> >> >> >core_pll_init);
> >> >> >> +CLK_OF_DECLARE(ppc_core_pll_v2, "fsl,qoriq-core-pll-2.0",
> >> >> >core_pll_init);
> >> >> >> +CLK_OF_DECLARE(ppc_core_mux_v1, "fsl,qoriq-core-mux-1.0",
> >> >> >core_mux_init);
> >> >> >> +CLK_OF_DECLARE(ppc_core_mux_v2, "fsl,qoriq-core-mux-2.0",
> >> >> >core_mux_init);
> >> >> >
> >> >> >What does this do that the existing platform driver and match
> >> >> >table don't?  Why is it needed for ARM when PPC didn't need it?
> >> >> >
> >> >> >-Scott
> >> >> >
> >> >> Common clk init on ARM platform is initialized earlier via
> >> >> of_clk_init() instead of driver probe method, the of_clk_init will
> >> >> walk a __clk_of_table to init each clk provider in the table, the
> >> >> CLK_OF_DECLARE() macro puts a supported clk in the __clk_of_table
> >> >> for it
> >> >initializing on starup, and the clk system has added some common clk
> >> >such as "fixed-clk"
> >> >> to this table already.
> >> >> So here I add our specific clk init declaration to consist this
> >> >> framework, and the driver probe function will not be needed on ARM.
> >> >
> >> >OK... Is there any reason why the new method won't work on PPC?
> >> >
> >> PPC has little dependence on the clock tree but frequency, it will
> >> work well if adopted I think.
> >
> >I'm just saying it seems redundant to have both.  Even on ARM, won't this
> >result in the clock getting registered twice (albeit with one of those
> >times being too late)?
> >
> >Regardless of what dependence PPC has on the clock tree, what stops this
> >method of enumeration from working on PPC?  Is there anything required
> >other than inserting a call to of_clk_init(NULL) in the arch init code?
> >
> >-Scott
> >
> The of_clk_init is an alternative way to the legacy driver. 
> Latest ARM standard support a default call to of_clk_init(NULL) in its time_init().
> So this is the general way for ARM-based platform.

Why are such things dependent on CPU architecture?

> The clk register layer can detect the twice registration of a same clk and
> avoid the duplicate registration. The dtb should select the compatible for either,
> but not both.

Either but not both of what?

> On LS1021A the driver probe method will not be triggered.
> And for support of of_clk_init on PPC, I think just add a call to it as ARM do
> in time_init()[arch/arm/kernel/time.c] would be ok.

I'd rather see this happen than have the driver have to register itself
differently on different architectures.

-Scott