linux-kernel - RE: [RFC v2 4/9] of: add clock providers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 17 Jan 2012 12:44:23 -0800
From:	Stephen Warren <swarren@...dia.com>
To:	Grant Likely <grant.likely@...retlab.ca>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>
CC:	Rob Herring <rob.herring@...xeda.com>,
	Sascha Hauer <kernel@...gutronix.de>,
	Mike Turquette <mturquette@...com>
Subject: RE: [RFC v2 4/9] of: add clock providers

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@...00 {
> +        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@...0 {
> +        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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/