linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@nvidia.com>
To: Grant Likely <grant.likely@secretlab.ca>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devicetree-discuss@lists.ozlabs.org" 
	<devicetree-discuss@lists.ozlabs.org>
Cc: Rob Herring <rob.herring@calxeda.com>,
	Sascha Hauer <kernel@pengutronix.de>,
	Mike Turquette <mturquette@ti.com>
Subject: RE: [RFC v2 4/9] of: add clock providers
Date: Tue, 17 Jan 2012 12:44:23 -0800	[thread overview]
Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF17801D2353@HQMAIL01.nvidia.com> (raw)
In-Reply-To: <1323727329-4989-4-git-send-email-grant.likely@secretlab.ca>

Grant Likely wrote at Monday, December 12, 2011 3:02 PM:
> Based on work by Ben Herrenschmidt and Jeremy Kerr, this patch adds an
> of_clk_get function to allow platforms to retrieve clock data from the
> device tree.
> 
> Platform register a provider through of_clk_add_provider, which will be
> called when a device references the provider's OF node for a clock
> reference.
...
> diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt
...
> +==Example==
> +
> +    /* external oscillator */
> +    osc: oscillator {
> +        compatible = "fixed-clock";
> +        #clock-cells = <1>;
> +        clock-frequency  = <32678>;
> +        clock-output-names = "osc";
> +    };
> +
> +    /* phase-locked-loop device, generates a higher frequency clock
> +     * from the external oscillator reference */
> +    pll: pll@4c000 {
> +        compatible = "vendor,some-pll-interface"
> +        #clock-cells = <1>;
> +        clocks = <&osc 0>;
> +        clock-names = "ref";
> +        reg = <0x4c000 0x1000>;
> +        clock-output-names = "pll", "pll-switched";
> +    };
> +
> +    /* UART, using the low frequency oscillator for the baud clock,
> +     * and the high frequency switched PLL output for register
> +     * clocking */
> +    uart@a000 {
> +        compatible = "fsl,imx-uart";
> +        reg = <0xa000 0x1000>;
> +        interrupts = <33>;
> +        clocks = <&osc 0>, <&pll 1>;
> +        clock-names = "baud", "register";
> +    };
> +
> +This DT fragment defines three devices: an external oscillator to provide a
> +low-frequency reference clock, a PLL device to generate a higher frequency
> +clock signal, and a UART.
> +
> +* The oscillator is fixed-frequency, and provides one clock output, named "osc".
> +* The PLL is both a clock provider and a clock consumer. It uses the clock
> +  signal generated by the external oscillator, and provides two output signals
> +  ("pll" and "pll-switched").
> +* The UART has its baud clock connected the external oscillator and its
> +  register clock connected to the PLL clock (the "pll-switched" signal)

In the example above, the UART's register clock's parent is the PLL, and
the PLL's parent is the OSC. Is the intention to have this parenting set
up automatically by the core OF clock code, or is this something that each
individual driver needs to set up itself.

In other words, does the UART driver need to do something like:

clk_reg = clk_get(dev, "register");
clk_parent = of_clk_get_by_name(np, "register);
clk_set_parent(clk_reg, clk_parent);

Or will that all happen transparently within just the of_clk_get_by_name
call?

(I suppose this question makes slightly more sense for the PLL itself,
since both the upstream and downstream clocks are represented in the PLL
node, whereas the UART's node only represents the clock consumer side,
so the above code isn't really possible automatically).

Somewhat related to this: How does dynamic reparenting interact with
the DT clock binding; is the DT just the default/initial clock setup,
and anything beyond that needs a custom binding and code in the consumer?

I'm thinking of say a system with 1 I2S controller, and both an internal
and external I2S clock source, where perhaps the internal source needs
to be used to capture from an I2S interface on one set of pins (e.g.
analog mic) but the other clock source needs to be used to capture from
I2S on another set of pins (e.g. digital baseband unit connection).
(This example is theoretical, but I'm sure there are other dynamic clock
cases in practice).

-- 
nvpublic


  parent reply	other threads:[~2012-01-17 20:44 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-12 22:02 [RFC v2 1/9] arm/versatile*: merge all versatile struct clk definitions Grant Likely
2011-12-12 22:02 ` [RFC v2 2/9] arm/versatile*: Consolidate clk_ops and setvco implementations Grant Likely
2011-12-12 22:02 ` [RFC v2 3/9] of: Add of_property_match_string() to find index into a string list Grant Likely
2011-12-12 22:02 ` [RFC v2 4/9] of: add clock providers Grant Likely
2011-12-12 23:29   ` Jamie Iles
2011-12-13 17:54     ` Grant Likely
2011-12-13 18:01       ` Rob Herring
2011-12-13 18:03         ` Grant Likely
2011-12-15 13:51       ` Shawn Guo
2011-12-15 14:23         ` Rob Herring
2011-12-15 15:13           ` Shawn Guo
2011-12-15 17:37             ` Grant Likely
2012-01-10 21:33   ` Jamie Iles
2012-01-12  4:46     ` Grant Likely
2012-01-12 10:07       ` Jamie Iles
2012-01-12 18:44         ` Turquette, Mike
2012-01-12 19:16           ` Grant Likely
2012-01-13 12:47       ` Shawn Guo
2012-01-14  4:30         ` Turquette, Mike
2012-01-14  5:40           ` Shawn Guo
2012-01-13 13:50   ` Shawn Guo
2012-01-13 14:05     ` Rob Herring
2012-01-13 14:38       ` Shawn Guo
2012-01-17 20:44   ` Stephen Warren [this message]
2012-01-17 22:47     ` Grant Likely
2012-01-17 23:37       ` Turquette, Mike
2012-01-17 23:49         ` Grant Likely
2012-01-18  0:05         ` Stephen Warren
2011-12-12 22:02 ` [RFC v2 5/9] dt/clock: Add handling for fixed clocks and a clock node setup iterator Grant Likely
2011-12-15 15:19   ` Shawn Guo
2011-12-12 22:02 ` [RFC v2 6/9] arm/dt: add devicetree support to sp804 timer support Grant Likely
2011-12-12 23:54   ` Rob Herring
2011-12-12 22:02 ` [RFC v2 7/9] arm/dt: Common plat-versatile support for icst and sp804 based system clocks Grant Likely
2012-01-17 21:05   ` Stephen Warren
2012-01-17 22:02     ` Rob Herring
2012-01-17 22:59     ` Grant Likely
2011-12-12 22:02 ` [RFC v2 8/9] dt/arm: versatile add clock parsing Grant Likely
2011-12-12 22:02 ` [RFC v2 9/9] arm/highbank: Use clock binding common support code Grant Likely

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=74CDBE0F657A3D45AFBB94109FB122FF17801D2353@HQMAIL01.nvidia.com \
    --to=swarren@nvidia.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@ti.com \
    --cc=rob.herring@calxeda.com \
    /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).