From patchwork Fri May 23 01:34:06 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Turquette X-Patchwork-Id: 4227711 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 3B1809F36A for ; Fri, 23 May 2014 01:36:59 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 3052120394 for ; Fri, 23 May 2014 01:36:58 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 196532037E for ; Fri, 23 May 2014 01:36:57 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WneNe-0006bB-4T; Fri, 23 May 2014 01:34:42 +0000 Received: from mail-pa0-f42.google.com ([209.85.220.42]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WneNb-0006Ym-Sc for linux-arm-kernel@lists.infradead.org; Fri, 23 May 2014 01:34:40 +0000 Received: by mail-pa0-f42.google.com with SMTP id rd3so3306764pab.15 for ; Thu, 22 May 2014 18:34:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version :content-transfer-encoding:to:from:in-reply-to:cc:references :message-id:user-agent:subject:date; bh=xjh11hJoikkh7n23nH3uRvLfzZ9hlioH+ShemsigPyQ=; b=msFVXIS9MlUsYRpMSeUKmRKStRMns40j0iCV9dALKHrCCqvjZk8N6ncq9sY8j14YZb gtusmNGfNGyGHnlgElcYCsRBkggZYjZwqWTJpNMXDi1c0iRe5JkxxRVGZW/nU0fONf0F 4oBPl3vAPtAy5/8871o5bvMbLjAbuoqySbywFhKvvaBoveB4dBQ08BlMw1wgfZvuIxTb YltstaKgOcOTPnCHeMRMs6l2BCTTI1EO0HozWJYju5VnhkTOXtdUVIeop0g37hevaLwy xuqVH2pdRdF+gXwY2eSk0iOySEcEL6ySmT81t5Y2Nm+R1mwWB0oeoR3MG3vY3GYIfSsQ hlSQ== X-Gm-Message-State: ALoCoQnPJ7PDcIZkXre7LPyQSQI0Za9+HLc/Bp8OQzb4rRgqI/AgDallKPVrBTc+W2+zlweqq7M5 X-Received: by 10.67.4.169 with SMTP id cf9mr1591239pad.45.1400808857230; Thu, 22 May 2014 18:34:17 -0700 (PDT) Received: from localhost ([2601:9:5900:1fe:ca60:ff:fe0a:8a36]) by mx.google.com with ESMTPSA id kj1sm1705559pbd.20.2014.05.22.18.34.15 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 22 May 2014 18:34:15 -0700 (PDT) MIME-Version: 1.0 To: Sylwester Nawrocki , "Rob Herring" From: Mike Turquette In-Reply-To: <5347DF4D.5000005@samsung.com> References: <1397042790-10636-1-git-send-email-s.nawrocki@samsung.com> <1397042790-10636-3-git-send-email-s.nawrocki@samsung.com> <5347DF4D.5000005@samsung.com> Message-ID: <20140523013406.9521.82891@quantum> User-Agent: alot/0.3.5 Subject: Re: [PATCH RFC v5 2/2] clk: Add handling of clk parent and rate assigned from DT Date: Thu, 22 May 2014 18:34:06 -0700 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140522_183439_964320_EE3F3EC8 X-CRM114-Status: GOOD ( 34.19 ) X-Spam-Score: -0.7 (/) Cc: Mark Rutland , "devicetree@vger.kernel.org" , Russell King - ARM Linux , Peter De Schrijver , Greg Kroah-Hartman , Sascha Hauer , sw0312.kim@samsung.com, "linux-kernel@vger.kernel.org" , Tero Kristo , Tomasz Figa , Kyungmin Park , Rob Herring , Laurent Pinchart , Kumar Gala , Grant Likely , Ben Dooks , "linux-arm-kernel@lists.infradead.org" , Marek Szyprowski X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Quoting Sylwester Nawrocki (2014-04-11 05:25:49) > >> +==Assigned clock parents and rates== > >> + > >> +Some platforms require static initial configuration of parts of the clocks > >> +controller. Such a configuration can be specified in a clock consumer node > >> +through clock-parents and clock-rates DT properties. The former should > >> +contain a list of parent clocks in form of phandle and clock specifier pairs, > >> +the latter the list of assigned clock frequency values (one cell each). > >> +To skip setting parent or rate of a clock its corresponding entry should be > >> +set to 0, or can be omitted if it is not followed by any non-zero entry. > >> + > >> + uart@a000 { > >> + compatible = "fsl,imx-uart"; > >> + reg = <0xa000 0x1000>; > >> + ... > >> + clocks = <&clkcon 0>, <&clkcon 3>; > >> + clock-names = "baud", "mux"; > >> + > >> + clock-parents = <0>, <&pll 1>; > >> + clock-rates = <460800>; > > > > Is this the input frequency or serial baud rate? Looks like a baud > > rate, but the clock framework needs input (to the uart) frequency. I > > would say this should be clock-frequency and specify the max baud rate > > as is being done with i2c bindings. The uart driver should know how to > > convert between input clock freq and baud rate. > > This UART example is not quite representative for the issues I have been > trying to address with this patch set. There is a need to set (an initial) > input clock frequency. E.g. in case of multimedia devices there may be > a need to set clock parent and frequency of an input clock to multiple IP > blocks, so they are clocked synchronously and data is carried properly > across a whole processing chain. Thus there may not be even clock output > in an IP block, but still input clock needs to be set. IIUC there is > similar issue with audio, where it is difficult to calculate the clock > frequencies/determine parent clocks in individual drivers algorithmically. > > >> + }; > >> + > >> +In this example the pll is set as parent of "mux" clock and frequency > >> of "baud" > >> +clock is specified as 460800 Hz. > > > > I don't really like clock-parents. The parent information is part of > > the clock source, not the consumer. > > I'm not sure we must always consider the parent information as property > of a clock source. If for example we expose a structure like below as > single clock object, supporting clock gating, parent and frequency > setting the parent setting is still accessible from within a device > driver. The design of the ccf implementation certainly allows one to hide individually addressable/configurable clock nodes within a single struct clk. But should we? I have always maintained that a clock driver should enumerate clocks in the same way that the data sheet or technical reference manual states. I did make a recent exception[1], but that is going to be rolled back after the coordinated clock rate changes land in mainline. > And clock parent selection may depend on a system configuration > not immediately obvious from within a single device driver perspective. > > MUX > ,-------. DIVIDER GATE > common clk source 1 -->|--. | ,--------. ,--------. > | \ | | | | | > common clk source 2 -->|- '--|-->| |-->| |--> consumer > ... | | | | | | > common clk source N -->|- | '--------' '--------' > '-------' > > > We've somewhat decided against having every single clock defined in DT > > and rather only describe a clock controller with leaf clocks to > > devices. That is not a hard rule, but for complex clock trees that is > > the norm. Doing something like this will require all levels of the > > clock tree to be described. You may have multiple layers of parents > > that have to be configured correctly. How are you configuring the rest > > of the tree? > > I believe even clock controllers where clocks are represented as flat > array often describe the clock tree entirely by parenthood, the tree > structure is just not obvious from the DT binding. > In addition, there seems to be appearing more and more clock controller > DT bindings describing their clocks individually. I've been discouraging these per-clock node bindings in favor of the per-controller node style. > > >> +Configuring a clock's parent and rate through the device node that uses > >> +the clock can be done only for clocks that have a single user. Specifying > >> +conflicting parent or rate configuration in multiple consumer nodes for > >> +a shared clock is forbidden. > >> + > >> +Configuration of common clocks, which affect multiple consumer devices > >> +can be specified in a dedicated 'assigned-clocks' subnode of a clock > >> +provider node, e.g.: > > > > This seems like a work-around due to having clock-parents in the > > consumer node. If (I'm not convinced we should) we have a binding for > > parent config, it needs to be a single binding that works for both > > cases. > > When this issue was first raised during an ARM kernel summit it was > proposed to add 'assigned' prefix to DT properties for such bindings. > Yes, I like the "assigned-" prefix. > How about separate properties for the default clock configuration, > e.g. assigned-clocks/assigned-clock-parents/assigned-clock-rates ? > So a clock provider would look like: > > clkcon { > ... > #clock-cells = <1>; > > assigned-clocks = <&clkcon 16>, <&clkcon 17>; > assigned-clock-parents = <0>, <&clkcon 1>; > assigned-clock-rates = <200000>; > }; > > And a consumer device node: > > uart@a000 { > compatible = "fsl,imx-uart"; > reg = <0xa000 0x1000>; > ... > clocks = <&clkcon 0>; > clock-names = "baud"; > > assigned-clocks = <&clkcon 3>, <&clkcon 0>; > assigned-clock-parents = <&pll 1>; > assigned-clock-rates = <0>, <460800>; > }; It looks like this idea was dropped for v6. Can we revisit it? Take a look at Tero's example implementation for OMAP using this binding: http://www.spinics.net/lists/linux-omap/msg104705.html There is a bogus "default-clocks" node made solely for storing this info within the OMAP PRCM clock provider node. This is basically faking a clock consumer. I think with the proposed solution above Tero could have avoided that node entirely and done the following: Tero, what do you think? Regards, Mike [1] http://www.spinics.net/lists/cpufreq/msg10071.html diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi index 649b5cd..e3ff1a7 100644 --- a/arch/arm/boot/dts/omap4.dtsi +++ b/arch/arm/boot/dts/omap4.dtsi @@ -145,6 +145,11 @@ cm2_clocks: clocks { #address-cells = <1>; #size-cells = <0>; + + assigned-clocks = <&abe_dpll_refclk_mux_ck>, + <&dpll_usb_ck>, <&dpll_abe_ck>; + assigned-clock-parents = <&sys_32k_ck>; + assigned-clock-rates = <0>, <960000000>, <98304000>; }; cm2_clockdomains: clockdomains {