From: Rob Herring <robherring2@gmail.com> To: Shawn Guo <shawn.guo@linaro.org> Cc: Shawn Guo <shawn.guo@freescale.com>, Mike Turquette <mturquette@linaro.org>, Grant Likely <grant.likely@secretlab.ca>, "arm@kernel.org" <arm@kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org> Subject: Re: [GIT PULL] DT clk binding support Date: Mon, 21 May 2012 18:52:37 -0500 [thread overview] Message-ID: <4FBAD545.7060803@gmail.com> (raw) In-Reply-To: <20120521232616.GF8140@S2101-09.ap.freescale.net> On 05/21/2012 06:26 PM, Shawn Guo wrote: > On Mon, May 21, 2012 at 01:30:59PM -0500, Rob Herring wrote: >>> With the bindings here, I need something like below in device tree to >>> replace the clk lookup registration that is currently done in imx6q >>> sabrelite specific setup code. However the problem here is I have cko >>> defined in clock driver, and thus I can not give phandle to cko in >>> device tree. What I suggest is for such cases, we could require >>> clock-names = "cko" than clocks = <&cko>, and of_clk_get() should also >>> be able to find the clock with looking for the clk name. >>> >>> imx6q-sabrelite.dts: >>> >>> codec: sgtl5000@0a { >>> compatible = "fsl,sgtl5000"; >>> reg = <0x0a>; >>> clocks = <&cko>; >>> }; >>> >>> mach-imx6q.c, imx6q_sabrelite_cko1_setup(): >>> >>> cko1 = clk_get_sys(NULL, "cko1"); >>> clk_register_clkdev(cko1, NULL, "0-000a"); >>> >> >> What!? This is a terrible abuse/hack of the clock binding and is in no >> way what was intended. You cannot use half of the clock binding. You >> have to have a provider. The primary binding is a phandle reference. >> clock-names is just auxiliary data. >> > Well, on conversation [1], it seems people agreed that for those huge > clock tree, only leaf clocks should be exposed in device tree. Then > please help me understand how we could do that with the current binding > design, considering those leaf clocks are consumers of their parent > clocks while being provider to the leaf clock the parent clock is not > exposed in device tree. You are mis-interpreting things. 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. By only exposing leaf nodes of the clocks, that means only exposing a single DT node for the SOC clocks with a whole bunch of outputs (i.e. the leaf clocks). In the imx case, this would be a single node for the CCM with the dozens clocks the CCM outputs. In this case you would not expose all the individual muxes, gates, and dividers of the CCM in the DT. You still have to describe the connection between the CCM and a h/w block. I'm not sure what you want here. Based on our prior conversations, I thought you wanted to break out every single clock as a separate DT node and have generic divider, mux, and gate bindings. Now you are arguing for the opposite. Rob > Regards, > Shawn > > [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/139414/focus=1216423
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: Mon, 21 May 2012 18:52:37 -0500 [thread overview] Message-ID: <4FBAD545.7060803@gmail.com> (raw) In-Reply-To: <20120521232616.GF8140@S2101-09.ap.freescale.net> On 05/21/2012 06:26 PM, Shawn Guo wrote: > On Mon, May 21, 2012 at 01:30:59PM -0500, Rob Herring wrote: >>> With the bindings here, I need something like below in device tree to >>> replace the clk lookup registration that is currently done in imx6q >>> sabrelite specific setup code. However the problem here is I have cko >>> defined in clock driver, and thus I can not give phandle to cko in >>> device tree. What I suggest is for such cases, we could require >>> clock-names = "cko" than clocks = <&cko>, and of_clk_get() should also >>> be able to find the clock with looking for the clk name. >>> >>> imx6q-sabrelite.dts: >>> >>> codec: sgtl5000 at 0a { >>> compatible = "fsl,sgtl5000"; >>> reg = <0x0a>; >>> clocks = <&cko>; >>> }; >>> >>> mach-imx6q.c, imx6q_sabrelite_cko1_setup(): >>> >>> cko1 = clk_get_sys(NULL, "cko1"); >>> clk_register_clkdev(cko1, NULL, "0-000a"); >>> >> >> What!? This is a terrible abuse/hack of the clock binding and is in no >> way what was intended. You cannot use half of the clock binding. You >> have to have a provider. The primary binding is a phandle reference. >> clock-names is just auxiliary data. >> > Well, on conversation [1], it seems people agreed that for those huge > clock tree, only leaf clocks should be exposed in device tree. Then > please help me understand how we could do that with the current binding > design, considering those leaf clocks are consumers of their parent > clocks while being provider to the leaf clock the parent clock is not > exposed in device tree. You are mis-interpreting things. 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. By only exposing leaf nodes of the clocks, that means only exposing a single DT node for the SOC clocks with a whole bunch of outputs (i.e. the leaf clocks). In the imx case, this would be a single node for the CCM with the dozens clocks the CCM outputs. In this case you would not expose all the individual muxes, gates, and dividers of the CCM in the DT. You still have to describe the connection between the CCM and a h/w block. I'm not sure what you want here. Based on our prior conversations, I thought you wanted to break out every single clock as a separate DT node and have generic divider, mux, and gate bindings. Now you are arguing for the opposite. Rob > Regards, > Shawn > > [1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/139414/focus=1216423
next prev parent reply other threads:[~2012-05-21 23: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 [this message] 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 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=4FBAD545.7060803@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=shawn.guo@freescale.com \ --cc=shawn.guo@linaro.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.