From: Rob Herring <robherring2@gmail.com> To: Stephen Boyd <sboyd@codeaurora.org> Cc: Shawn Guo <shawn.guo@linaro.org>, Mike Turquette <mturquette@linaro.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Grant Likely <grant.likely@secretlab.ca>, "arm@kernel.org" <arm@kernel.org>, Shawn Guo <shawn.guo@freescale.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Saravana Kannan <skannan@codeaurora.org> Subject: Re: [GIT PULL] DT clk binding support Date: Tue, 22 May 2012 08:52:08 -0500 [thread overview] Message-ID: <4FBB9A08.2050803@gmail.com> (raw) In-Reply-To: <4FBB134D.6050409@codeaurora.org> On 05/21/2012 11:17 PM, Stephen Boyd wrote: > On 05/21/12 19:15, Shawn Guo wrote: >> On Mon, May 21, 2012 at 06:52:37PM -0500, Rob Herring wrote: >>> As Grant states: "This proposed binding is only about one thing: >>> attaching clock providers to clock consumers." This means you have to >>> have at least a single provider and a single consumer defined in the DT. >>> >> I just read through Grant's comments over again. I agree with the >> statement which implicitly requires the clk provider defined in DT. >> However, for some case, this provider in DT is just a skeleton which >> is backed by clock driver where the provider is actually defined. >> >> Looking at Grant's comment below, the second option is also to match >> the clock in driver just using name. The only difference to my >> proposal is the name here is given by the argument of phandle pointing >> to that skeleton provider node. >> >> I'm fine with that. So go ahead with your bindings. >> > > Can we do what the regulator framework has done and have a common > binding of <connection_name>-clk = <&phandle>? Something like: > > core-clk = <&uart3_clk> > > and then have clk_get() use the of node of the device passed in to find > a property named %s-clk and find the clock with the matching phandle. Sigh... That is what we had in previous versions from over a year ago and we moved away from that approach. The current binding has been reviewed multiple times in the last 6 months... The current approach is aligned with how interrupts are handled (with the addition of a phandle). I think not having per clock property names is easier to parse and easier to document. > This looks like it's trying to cover both the end consumers (uart uses > uart3_clk) and the internal clock tree consumers (a crystal oscillator > connects to a PLL or a mux has multiple parents). We can certainly use > these bindings for muxes and internal parent-child relationships but I > would prefer we use different bindings for consumer bindings that match > what regulators do today. The binding supports either defining every last internal clock or just the leaf clocks. I took the former route on highbank since I don't have a lot of clocks. If I was doing imx or omap for example, I'd probably just define all the clock controller outputs. Rob
WARNING: multiple messages have this Message-ID (diff)
From: robherring2@gmail.com (Rob Herring) To: linux-arm-kernel@lists.infradead.org Subject: [GIT PULL] DT clk binding support Date: Tue, 22 May 2012 08:52:08 -0500 [thread overview] Message-ID: <4FBB9A08.2050803@gmail.com> (raw) In-Reply-To: <4FBB134D.6050409@codeaurora.org> On 05/21/2012 11:17 PM, Stephen Boyd wrote: > On 05/21/12 19:15, Shawn Guo wrote: >> On Mon, May 21, 2012 at 06:52:37PM -0500, Rob Herring wrote: >>> As Grant states: "This proposed binding is only about one thing: >>> attaching clock providers to clock consumers." This means you have to >>> have at least a single provider and a single consumer defined in the DT. >>> >> I just read through Grant's comments over again. I agree with the >> statement which implicitly requires the clk provider defined in DT. >> However, for some case, this provider in DT is just a skeleton which >> is backed by clock driver where the provider is actually defined. >> >> Looking at Grant's comment below, the second option is also to match >> the clock in driver just using name. The only difference to my >> proposal is the name here is given by the argument of phandle pointing >> to that skeleton provider node. >> >> I'm fine with that. So go ahead with your bindings. >> > > Can we do what the regulator framework has done and have a common > binding of <connection_name>-clk = <&phandle>? Something like: > > core-clk = <&uart3_clk> > > and then have clk_get() use the of node of the device passed in to find > a property named %s-clk and find the clock with the matching phandle. Sigh... That is what we had in previous versions from over a year ago and we moved away from that approach. The current binding has been reviewed multiple times in the last 6 months... The current approach is aligned with how interrupts are handled (with the addition of a phandle). I think not having per clock property names is easier to parse and easier to document. > This looks like it's trying to cover both the end consumers (uart uses > uart3_clk) and the internal clock tree consumers (a crystal oscillator > connects to a PLL or a mux has multiple parents). We can certainly use > these bindings for muxes and internal parent-child relationships but I > would prefer we use different bindings for consumer bindings that match > what regulators do today. The binding supports either defining every last internal clock or just the leaf clocks. I took the former route on highbank since I don't have a lot of clocks. If I was doing imx or omap for example, I'd probably just define all the clock controller outputs. Rob
next prev parent reply other threads:[~2012-05-22 13:52 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-05-19 21:22 [GIT PULL] DT clk binding support Rob Herring 2012-05-19 21:22 ` Rob Herring 2012-05-20 3:06 ` Shawn Guo 2012-05-20 3:06 ` Shawn Guo 2012-05-21 2:18 ` Rob Herring 2012-05-21 2:18 ` Rob Herring 2012-05-21 6:49 ` Shawn Guo 2012-05-21 6:49 ` Shawn Guo 2012-05-21 18:30 ` Rob Herring 2012-05-21 18:30 ` Rob Herring 2012-05-21 23:26 ` Shawn Guo 2012-05-21 23:26 ` Shawn Guo 2012-05-21 23:52 ` Rob Herring 2012-05-21 23:52 ` Rob Herring 2012-05-22 2:15 ` Shawn Guo 2012-05-22 2:15 ` Shawn Guo 2012-05-22 4:17 ` Stephen Boyd 2012-05-22 4:17 ` Stephen Boyd 2012-05-22 13:52 ` Rob Herring [this message] 2012-05-22 13:52 ` Rob Herring 2012-05-23 1:38 ` Saravana Kannan 2012-05-23 1:38 ` Saravana Kannan 2012-05-23 13:59 ` Rob Herring 2012-05-23 13:59 ` Rob Herring 2012-05-24 21:16 ` Saravana Kannan 2012-05-24 21:16 ` Saravana Kannan 2012-05-24 21:54 ` Rob Herring 2012-05-24 21:54 ` Rob Herring 2012-05-25 3:33 ` Saravana Kannan 2012-05-25 3:33 ` Saravana Kannan 2012-06-01 13:21 ` Rob Herring 2012-06-01 13:21 ` Rob Herring
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4FBB9A08.2050803@gmail.com \ --to=robherring2@gmail.com \ --cc=arm@kernel.org \ --cc=grant.likely@secretlab.ca \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mturquette@linaro.org \ --cc=sboyd@codeaurora.org \ --cc=shawn.guo@freescale.com \ --cc=shawn.guo@linaro.org \ --cc=skannan@codeaurora.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.