Messages in this thread | | | Subject | Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms CLK_OF_DECLARE support | From | Scott Wood <> | Date | Fri, 29 Aug 2014 20:00:01 -0500 |
| |
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@linaro.org; linuxppc-dev@lists.ozlabs.org; linux- > >kernel@vger.kernel.org; linux-arm-kernel@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@linaro.org; linuxppc-dev@lists.ozlabs.org; linux- > >> >kernel@vger.kernel.org; linux-arm-kernel@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@linaro.org; linuxppc-dev@lists.ozlabs.org; linux- > >> >> >kernel@vger.kernel.org; linux-arm-kernel@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
| |