From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [GIT PULL] DT clk binding support
Date: Mon, 21 May 2012 21:17:17 -0700 [thread overview]
Message-ID: <4FBB134D.6050409@codeaurora.org> (raw)
In-Reply-To: <20120522021535.GG8140@S2101-09.ap.freescale.net>
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.
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.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2012-05-22 4:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-19 21:22 [GIT PULL] DT clk binding support Rob Herring
2012-05-20 3:06 ` Shawn Guo
2012-05-21 2:18 ` Rob Herring
2012-05-21 6:49 ` Shawn Guo
2012-05-21 18:30 ` Rob Herring
2012-05-21 23:26 ` Shawn Guo
2012-05-21 23:52 ` Rob Herring
2012-05-22 2:15 ` Shawn Guo
2012-05-22 4:17 ` Stephen Boyd [this message]
2012-05-22 13:52 ` Rob Herring
2012-05-23 1:38 ` Saravana Kannan
2012-05-23 13:59 ` Rob Herring
2012-05-24 21:16 ` Saravana Kannan
2012-05-24 21:54 ` Rob Herring
2012-05-25 3:33 ` Saravana Kannan
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=4FBB134D.6050409@codeaurora.org \
--to=sboyd@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).