From mboxrd@z Thu Jan 1 00:00:00 1970 From: swarren@wwwdotorg.org (Stephen Warren) Date: Mon, 25 Mar 2013 12:13:08 -0600 Subject: RFC v2: Zynq Clock Controller In-Reply-To: <27dae808-1d3a-4001-8eb2-b0a6e2a34b8f@AM1EHSMHS013.ehs.local> References: <27dae808-1d3a-4001-8eb2-b0a6e2a34b8f@AM1EHSMHS013.ehs.local> Message-ID: <515093B4.2090701@wwwdotorg.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 03/20/2013 05:56 PM, S?ren Brinkmann wrote: > Hi, > > I spent some time working on this and incorporating feedback. Here's an updated proposal for a clock controller for Zynq: > > Required properties: > - #clock-cells : Must be 1 > - compatible : "xlnx,ps7-clkc" (this may become 'xlnx,zynq-clkc' terminology differs a bit between Xilinx internal and mainline) > - ps-clk-frequency : Frequency of the oscillator providing ps_clk in HZ > (usually 33 MHz oscillators are used for Zynq platforms) This may have been mentioned before, but shouldn't the input clock be represented as an actual clock in DT, and hence as an entry in this node's clocks property? The crystal/... itself can be represented in DT as a fixed-clock. > - clock-output-names : List of strings used to name the clock outputs. Shall be a list of the outputs given below. That shouldn't be required. > Optional properties: > - clocks : as described in the clock bindings > - clock-names : as described in the clock bindings I think clocks should be required, with at least the main crystal clock input always present, but perhaps having some optional entries for the (E)MIO feature you mention. > Example: > clkc: clkc { > #clock-cells = <1>; > compatible = "xlnx,ps7-clkc"; > ps-clk-frequency = <33333333>; > clock-output-names = "armpll", "ddrpll", "iopll", "cpu_6or4x", "cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x", "dci", "lqspi", "smc", "pcap", "gem0", "gem1", "fclk0", "fclk1", "fclk2", "fclk3", "can0", "can1", "sdio0", "sdio1", "uart0", "uart1", "spi0", "spi1", "dma", "usb0_aper", "usb1_aper", "gem0_aper", "gem1_aper", "sdio0_aper", "sdio1_aper", "spi0_aper", "spi1_aper", "can0_aper", "can1_aper", "i2c0_aper", "i2c1_aper", "uart0_aper", "uart1_aper", "gpio_aper", "lqspi_aper", "smc_aper", "swdt", "dbg_trc", "dbg_apb"; /* long list... explanation below */ > /* optional props */ > clocks = <&clkc 16>, <&clk_foo>; > clock-names = "gem1_emio_clk", "can_mio_clk_23"; > }; > > The downside of supporting this is, that I don't see a way around explicitly listing the clock output names in the DT. (Please wrap your emails to ~74 characters or so) As Mike mentioned off-list, one can create a new clk registration API that takes a struct clk* as parent rather than a char *clk_name. > This email and any attachments are intended for the sole use of the named recipient(s)... It's not good form to include that kind of disclaimer on public mailing list posts. That's why many people use their personal email when posting to mailing lists. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: RFC v2: Zynq Clock Controller Date: Mon, 25 Mar 2013 12:13:08 -0600 Message-ID: <515093B4.2090701@wwwdotorg.org> References: <27dae808-1d3a-4001-8eb2-b0a6e2a34b8f@AM1EHSMHS013.ehs.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <27dae808-1d3a-4001-8eb2-b0a6e2a34b8f-dAX9Bq04yCTT7m58JnLnSLjjLBE8jN/0@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: =?UTF-8?B?U8O2cmVuIEJyaW5rbWFubg==?= Cc: Josh Cartwright , Mike Turquette , =?UTF-8?B?SmFuIEzDvA==?= =?UTF-8?B?YmJl?= , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, Michal Simek , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Lars-Peter Clausen , git-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org, Peter Crosthwaite , Sascha Hauer , linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org T24gMDMvMjAvMjAxMyAwNTo1NiBQTSwgU8O2cmVuIEJyaW5rbWFubiB3cm90ZToKPiBIaSwKPiAK PiBJIHNwZW50IHNvbWUgdGltZSB3b3JraW5nIG9uIHRoaXMgYW5kIGluY29ycG9yYXRpbmcgZmVl ZGJhY2suIEhlcmUncyBhbiB1cGRhdGVkIHByb3Bvc2FsIGZvciBhIGNsb2NrIGNvbnRyb2xsZXIg Zm9yIFp5bnE6Cj4gCj4gUmVxdWlyZWQgcHJvcGVydGllczoKPiAgLSAjY2xvY2stY2VsbHMgOiBN dXN0IGJlIDEKPiAgLSBjb21wYXRpYmxlIDogInhsbngscHM3LWNsa2MiICAodGhpcyBtYXkgYmVj b21lICd4bG54LHp5bnEtY2xrYycgdGVybWlub2xvZ3kgZGlmZmVycyBhIGJpdCBiZXR3ZWVuIFhp bGlueCBpbnRlcm5hbCBhbmQgbWFpbmxpbmUpCj4gIC0gcHMtY2xrLWZyZXF1ZW5jeSA6IEZyZXF1 ZW5jeSBvZiB0aGUgb3NjaWxsYXRvciBwcm92aWRpbmcgcHNfY2xrIGluIEhaCj4gICAgICAgICAg ICAgICAgICAgICAgKHVzdWFsbHkgMzMgTUh6IG9zY2lsbGF0b3JzIGFyZSB1c2VkIGZvciBaeW5x IHBsYXRmb3JtcykKClRoaXMgbWF5IGhhdmUgYmVlbiBtZW50aW9uZWQgYmVmb3JlLCBidXQgc2hv dWxkbid0IHRoZSBpbnB1dCBjbG9jayBiZQpyZXByZXNlbnRlZCBhcyBhbiBhY3R1YWwgY2xvY2sg aW4gRFQsIGFuZCBoZW5jZSBhcyBhbiBlbnRyeSBpbiB0aGlzCm5vZGUncyBjbG9ja3MgcHJvcGVy dHk/IFRoZSBjcnlzdGFsLy4uLiBpdHNlbGYgY2FuIGJlIHJlcHJlc2VudGVkIGluIERUCmFzIGEg Zml4ZWQtY2xvY2suCgo+ICAtIGNsb2NrLW91dHB1dC1uYW1lcyA6IExpc3Qgb2Ygc3RyaW5ncyB1 c2VkIHRvIG5hbWUgdGhlIGNsb2NrIG91dHB1dHMuIFNoYWxsIGJlIGEgbGlzdCBvZiB0aGUgb3V0 cHV0cyBnaXZlbiBiZWxvdy4KClRoYXQgc2hvdWxkbid0IGJlIHJlcXVpcmVkLgoKPiBPcHRpb25h bCBwcm9wZXJ0aWVzOgo+ICAtIGNsb2NrcyA6IGFzIGRlc2NyaWJlZCBpbiB0aGUgY2xvY2sgYmlu ZGluZ3MKPiAgLSBjbG9jay1uYW1lcyA6IGFzIGRlc2NyaWJlZCBpbiB0aGUgY2xvY2sgYmluZGlu Z3MKCkkgdGhpbmsgY2xvY2tzIHNob3VsZCBiZSByZXF1aXJlZCwgd2l0aCBhdCBsZWFzdCB0aGUg bWFpbiBjcnlzdGFsIGNsb2NrCmlucHV0IGFsd2F5cyBwcmVzZW50LCBidXQgcGVyaGFwcyBoYXZp bmcgc29tZSBvcHRpb25hbCBlbnRyaWVzIGZvciB0aGUKKEUpTUlPIGZlYXR1cmUgeW91IG1lbnRp b24uCgo+IEV4YW1wbGU6Cj4gICAgICAgICBjbGtjOiBjbGtjIHsKPiAgICAgICAgICAgICAgICAg I2Nsb2NrLWNlbGxzID0gPDE+Owo+ICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gInhsbngs cHM3LWNsa2MiOwo+ICAgICAgICAgICAgICAgICBwcy1jbGstZnJlcXVlbmN5ID0gPDMzMzMzMzMz PjsKPiAgICAgICAgICAgICAgICAgY2xvY2stb3V0cHV0LW5hbWVzID0gImFybXBsbCIsICJkZHJw bGwiLCAiaW9wbGwiLCAiY3B1XzZvcjR4IiwgImNwdV8zb3IyeCIsICJjcHVfMngiLCAiY3B1XzF4 IiwgImRkcjJ4IiwgImRkcjN4IiwgImRjaSIsICJscXNwaSIsICJzbWMiLCAicGNhcCIsICJnZW0w IiwgImdlbTEiLCAiZmNsazAiLCAiZmNsazEiLCAiZmNsazIiLCAiZmNsazMiLCAiY2FuMCIsICJj YW4xIiwgInNkaW8wIiwgInNkaW8xIiwgInVhcnQwIiwgInVhcnQxIiwgInNwaTAiLCAic3BpMSIs ICJkbWEiLCAidXNiMF9hcGVyIiwgInVzYjFfYXBlciIsICJnZW0wX2FwZXIiLCAiZ2VtMV9hcGVy IiwgInNkaW8wX2FwZXIiLCAic2RpbzFfYXBlciIsICJzcGkwX2FwZXIiLCAic3BpMV9hcGVyIiwg ImNhbjBfYXBlciIsICJjYW4xX2FwZXIiLCAiaTJjMF9hcGVyIiwgImkyYzFfYXBlciIsICJ1YXJ0 MF9hcGVyIiwgInVhcnQxX2FwZXIiLCAiZ3Bpb19hcGVyIiwgImxxc3BpX2FwZXIiLCAic21jX2Fw ZXIiLCAic3dkdCIsICJkYmdfdHJjIiwgImRiZ19hcGIiOyAgLyogbG9uZyBsaXN0Li4uIGV4cGxh bmF0aW9uIGJlbG93ICovCj4gICAgICAgICAgICAgICAgIC8qIG9wdGlvbmFsIHByb3BzICovCj4g ICAgICAgICAgICAgICAgIGNsb2NrcyA9IDwmY2xrYyAxNj4sIDwmY2xrX2Zvbz47Cj4gICAgICAg ICAgICAgICAgIGNsb2NrLW5hbWVzID0gImdlbTFfZW1pb19jbGsiLCAiY2FuX21pb19jbGtfMjMi Owo+ICAgICAgICAgfTsKPiAKPiBUaGUgZG93bnNpZGUgb2Ygc3VwcG9ydGluZyB0aGlzIGlzLCB0 aGF0IEkgZG9uJ3Qgc2VlIGEgd2F5IGFyb3VuZCBleHBsaWNpdGx5IGxpc3RpbmcgdGhlIGNsb2Nr IG91dHB1dCBuYW1lcyBpbiB0aGUgRFQuCgooUGxlYXNlIHdyYXAgeW91ciBlbWFpbHMgdG8gfjc0 IGNoYXJhY3RlcnMgb3Igc28pCgpBcyBNaWtlIG1lbnRpb25lZCBvZmYtbGlzdCwgb25lIGNhbiBj cmVhdGUgYSBuZXcgY2xrIHJlZ2lzdHJhdGlvbiBBUEkKdGhhdCB0YWtlcyBhIHN0cnVjdCBjbGsq IGFzIHBhcmVudCByYXRoZXIgdGhhbiBhIGNoYXIgKmNsa19uYW1lLgoKPiBUaGlzIGVtYWlsIGFu ZCBhbnkgYXR0YWNobWVudHMgYXJlIGludGVuZGVkIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIG5h bWVkIHJlY2lwaWVudChzKS4uLgoKSXQncyBub3QgZ29vZCBmb3JtIHRvIGluY2x1ZGUgdGhhdCBr aW5kIG9mIGRpc2NsYWltZXIgb24gcHVibGljIG1haWxpbmcKbGlzdCBwb3N0cy4gVGhhdCdzIHdo eSBtYW55IHBlb3BsZSB1c2UgdGhlaXIgcGVyc29uYWwgZW1haWwgd2hlbiBwb3N0aW5nCnRvIG1h aWxpbmcgbGlzdHMuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCmRldmljZXRyZWUtZGlzY3VzcyBtYWlsaW5nIGxpc3QKZGV2aWNldHJlZS1kaXNjdXNzQGxp c3RzLm96bGFicy5vcmcKaHR0cHM6Ly9saXN0cy5vemxhYnMub3JnL2xpc3RpbmZvL2RldmljZXRy ZWUtZGlzY3Vzcwo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932715Ab3CYSNO (ORCPT ); Mon, 25 Mar 2013 14:13:14 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:52969 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932521Ab3CYSNM (ORCPT ); Mon, 25 Mar 2013 14:13:12 -0400 Message-ID: <515093B4.2090701@wwwdotorg.org> Date: Mon, 25 Mar 2013 12:13:08 -0600 From: Stephen Warren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: =?UTF-8?B?U8O2cmVuIEJyaW5rbWFubg==?= CC: Mike Turquette , Josh Cartwright , Michal Simek , Peter Crosthwaite , Lars-Peter Clausen , Prashant Gaikwad , devicetree-discuss@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, git@xilinx.com, =?UTF-8?B?SmFuIEzDvA==?= =?UTF-8?B?YmJl?= , Sascha Hauer , Peter De Schrijver Subject: Re: RFC v2: Zynq Clock Controller References: <27dae808-1d3a-4001-8eb2-b0a6e2a34b8f@AM1EHSMHS013.ehs.local> In-Reply-To: <27dae808-1d3a-4001-8eb2-b0a6e2a34b8f@AM1EHSMHS013.ehs.local> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/20/2013 05:56 PM, Sören Brinkmann wrote: > Hi, > > I spent some time working on this and incorporating feedback. Here's an updated proposal for a clock controller for Zynq: > > Required properties: > - #clock-cells : Must be 1 > - compatible : "xlnx,ps7-clkc" (this may become 'xlnx,zynq-clkc' terminology differs a bit between Xilinx internal and mainline) > - ps-clk-frequency : Frequency of the oscillator providing ps_clk in HZ > (usually 33 MHz oscillators are used for Zynq platforms) This may have been mentioned before, but shouldn't the input clock be represented as an actual clock in DT, and hence as an entry in this node's clocks property? The crystal/... itself can be represented in DT as a fixed-clock. > - clock-output-names : List of strings used to name the clock outputs. Shall be a list of the outputs given below. That shouldn't be required. > Optional properties: > - clocks : as described in the clock bindings > - clock-names : as described in the clock bindings I think clocks should be required, with at least the main crystal clock input always present, but perhaps having some optional entries for the (E)MIO feature you mention. > Example: > clkc: clkc { > #clock-cells = <1>; > compatible = "xlnx,ps7-clkc"; > ps-clk-frequency = <33333333>; > clock-output-names = "armpll", "ddrpll", "iopll", "cpu_6or4x", "cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x", "dci", "lqspi", "smc", "pcap", "gem0", "gem1", "fclk0", "fclk1", "fclk2", "fclk3", "can0", "can1", "sdio0", "sdio1", "uart0", "uart1", "spi0", "spi1", "dma", "usb0_aper", "usb1_aper", "gem0_aper", "gem1_aper", "sdio0_aper", "sdio1_aper", "spi0_aper", "spi1_aper", "can0_aper", "can1_aper", "i2c0_aper", "i2c1_aper", "uart0_aper", "uart1_aper", "gpio_aper", "lqspi_aper", "smc_aper", "swdt", "dbg_trc", "dbg_apb"; /* long list... explanation below */ > /* optional props */ > clocks = <&clkc 16>, <&clk_foo>; > clock-names = "gem1_emio_clk", "can_mio_clk_23"; > }; > > The downside of supporting this is, that I don't see a way around explicitly listing the clock output names in the DT. (Please wrap your emails to ~74 characters or so) As Mike mentioned off-list, one can create a new clk registration API that takes a struct clk* as parent rather than a char *clk_name. > This email and any attachments are intended for the sole use of the named recipient(s)... It's not good form to include that kind of disclaimer on public mailing list posts. That's why many people use their personal email when posting to mailing lists.