From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755771Ab2AQUo1 (ORCPT ); Tue, 17 Jan 2012 15:44:27 -0500 Received: from hqemgate04.nvidia.com ([216.228.121.35]:6122 "EHLO hqemgate04.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751550Ab2AQUoZ convert rfc822-to-8bit (ORCPT ); Tue, 17 Jan 2012 15:44:25 -0500 X-PGP-Universal: processed; by hqnvupgp08.nvidia.com on Tue, 17 Jan 2012 12:44:24 -0800 From: Stephen Warren To: Grant Likely , "linux-kernel@vger.kernel.org" , "devicetree-discuss@lists.ozlabs.org" CC: Rob Herring , Sascha Hauer , Mike Turquette Date: Tue, 17 Jan 2012 12:44:23 -0800 Subject: RE: [RFC v2 4/9] of: add clock providers Thread-Topic: [RFC v2 4/9] of: add clock providers Thread-Index: Acy5Gc0JtX8kfBssSLG5wj/mG1HfDQcPaPCw Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF17801D2353@HQMAIL01.nvidia.com> References: <1323727329-4989-1-git-send-email-grant.likely@secretlab.ca> <1323727329-4989-4-git-send-email-grant.likely@secretlab.ca> In-Reply-To: <1323727329-4989-4-git-send-email-grant.likely@secretlab.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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