All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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: link
Be 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.