[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1409360401.24184.41.camel@snotra.buserror.net>
Date: Fri, 29 Aug 2014 20:00:01 -0500
From: Scott Wood <scottwood@...escale.com>
To: Lu Jingchang-B35083 <jingchang.lu@...escale.com>
CC: "mturquette@...aro.org" <mturquette@...aro.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms
CLK_OF_DECLARE support
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@...aro.org; linuxppc-dev@...ts.ozlabs.org; linux-
> >kernel@...r.kernel.org; linux-arm-kernel@...ts.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@...aro.org; linuxppc-dev@...ts.ozlabs.org; linux-
> >> >kernel@...r.kernel.org; linux-arm-kernel@...ts.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@...aro.org; linuxppc-dev@...ts.ozlabs.org; linux-
> >> >> >kernel@...r.kernel.org; linux-arm-kernel@...ts.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists