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: 30666 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-oa0-f72.google.com (mail-oa0-f72.google.com [209.85.219.72]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 68BBA20369 for ; Fri, 23 May 2014 01:34:22 +0000 (UTC) Received: by mail-oa0-f72.google.com with SMTP id l6sf20098964oag.3 for ; Thu, 22 May 2014 18:34:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:mime-version:to:from:in-reply-to:cc :references:message-id:user-agent:subject:date:sender:precedence :list-id:x-original-sender:x-original-authentication-results :mailing-list:list-post:list-help:list-archive:list-unsubscribe :content-type:content-transfer-encoding; bh=ItecOlcxfEYIt7cCXoJLMHH8WFReB52uveh22CssWRk=; b=gl8/IOALrfQwoStwwssKIbILVQTbjbFaSmKZbNB5Tc2qBlyrDDaMf0QToW1JPq7Xwa cZXJGUlgmhrxqL/WMLagtJsF0m7C4wWvuZupa6arOxtrdUOnyvpUs5v/H+LHQ2yPhqhv bmEqEEOM7Mdz5mu/hdNe7PtS7LHXFtVlo0dU7gazZDY/Sm/ivvt9Wf/olW1b/UkvaGgI 8bXhD/StIxDRXEQkWM9iFxZ5gmHXAZJ3vq8QkqsDxF4FPVeUzlNaOOizIrM7Ty94sxS7 haJeKvpjWxaX8stSW3B6py9LaVqT2agQ0Yefs2kgvXJEWnleqpDP5AeRO2Fe1hqp5yla k5Zw== X-Gm-Message-State: ALoCoQkovjFgJpyNaFGSmrzDKnIF5EQlVOpgsbV+kB6P5vie1yeg8Z1ySQNWDW5eKXah737K6W0S X-Received: by 10.42.235.144 with SMTP id kg16mr718886icb.33.1400808861988; Thu, 22 May 2014 18:34:21 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.30.165 with SMTP id d34ls1489057qgd.25.gmail; Thu, 22 May 2014 18:34:21 -0700 (PDT) X-Received: by 10.220.159.4 with SMTP id h4mr1238764vcx.1.1400808861863; Thu, 22 May 2014 18:34:21 -0700 (PDT) Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by mx.google.com with ESMTPS id v1si835249vdd.63.2014.05.22.18.34.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 18:34:21 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.128.178 as permitted sender) client-ip=209.85.128.178; Received: by mail-ve0-f178.google.com with SMTP id sa20so5497771veb.37 for ; Thu, 22 May 2014 18:34:21 -0700 (PDT) X-Received: by 10.221.34.7 with SMTP id sq7mr1226429vcb.5.1400808861634; Thu, 22 May 2014 18:34:21 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.220.221.72 with SMTP id ib8csp245136vcb; Thu, 22 May 2014 18:34:20 -0700 (PDT) X-Received: by 10.66.161.69 with SMTP id xq5mr1745177pab.62.1400808859939; Thu, 22 May 2014 18:34:19 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id sm10si1725134pab.134.2014.05.22.18.34.19; Thu, 22 May 2014 18:34:19 -0700 (PDT) Received-SPF: none (google.com: devicetree-owner@vger.kernel.org does not designate permitted sender hosts) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751171AbaEWBeS (ORCPT + 8 others); Thu, 22 May 2014 21:34:18 -0400 Received: from mail-pa0-f41.google.com ([209.85.220.41]:55490 "EHLO mail-pa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750863AbaEWBeR convert rfc822-to-8bit (ORCPT ); Thu, 22 May 2014 21:34:17 -0400 Received: by mail-pa0-f41.google.com with SMTP id lj1so3295154pab.14 for ; Thu, 22 May 2014 18:34:17 -0700 (PDT) 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> Cc: "linux-arm-kernel@lists.infradead.org" , "devicetree@vger.kernel.org" , "Greg Kroah-Hartman" , "Russell King - ARM Linux" , "Rob Herring" , "Grant Likely" , "Mark Rutland" , "Kumar Gala" , "Laurent Pinchart" , "Sascha Hauer" , "Ben Dooks" , "Peter De Schrijver" , "Kyungmin Park" , "Tero Kristo" , sw0312.kim@samsung.com, "Marek Szyprowski" , "Tomasz Figa" , "linux-kernel@vger.kernel.org" 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 Sender: devicetree-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: devicetree@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: mturquette@linaro.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.128.178 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , 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 --- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.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 {