From mboxrd@z Thu Jan 1 00:00:00 1970 From: swarren@wwwdotorg.org (Stephen Warren) Date: Mon, 25 Mar 2013 17:29:33 -0600 Subject: RFC v2: Zynq Clock Controller In-Reply-To: <128fc723-ace7-4f4c-95d9-971b42a52080@CH1EHSMHS028.ehs.local> References: <27dae808-1d3a-4001-8eb2-b0a6e2a34b8f@AM1EHSMHS013.ehs.local> <514B5254.50101@metafoo.de> <128fc723-ace7-4f4c-95d9-971b42a52080@CH1EHSMHS028.ehs.local> Message-ID: <5150DDDD.9010904@wwwdotorg.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 03/22/2013 04:41 PM, S?ren Brinkmann wrote: > Hi Lars, > > On Thu, Mar 21, 2013 at 07:32:52PM +0100, Lars-Peter Clausen wrote: >> On 03/21/2013 12:56 AM, 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) >>> - clock-output-names : List of strings used to name the clock outputs. Shall be a list of the outputs given below. >>> >>> Optional properties: >>> - clocks : as described in the clock bindings >>> - clock-names : as described in the clock bindings >>> >>> Clock inputs: >>> The following strings are optional parameters to the 'clock-names' property in >>> order to provide optional (E)MIO clock sources. >>> - swdt_ext_clk >>> - gem0_emio_clk >>> - gem1_emio_clk >>> - mio_clk_XX # with XX = 00..53 >>> >>> Example: >>> clkc: clkc { >>> #clock-cells = <1>; >>> compatible = "xlnx,ps7-clkc"; >>> ps-clk-frequency = <33333333>; >> >> The input frequency should be a clock as well. > > Again, monolithic vs split. I don't see a reason not to just internally > call clk_register_fixed_rate(). That way its children do not have to > cope with a variable name for the xtal. > Also, with my proposal 'clocks' and 'clock-names' would be purely > optional properties, only required if optional external inputs are > present. Having the xtal defined externally would add mandatory entries for > those props. But isn't the clock source board-specific? It's a completely separate object from Zynq's own clock controller HW, and as such should be represented by a separate DT node, right? The issue with parent clock names is simply a red herring. A solution is needed to registered clock with a parent clock object, rather than a parent clock name. Then, the parent names are completely irrelevant. 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 17:29:33 -0600 Message-ID: <5150DDDD.9010904@wwwdotorg.org> References: <27dae808-1d3a-4001-8eb2-b0a6e2a34b8f@AM1EHSMHS013.ehs.local> <514B5254.50101@metafoo.de> <128fc723-ace7-4f4c-95d9-971b42a52080@CH1EHSMHS028.ehs.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <128fc723-ace7-4f4c-95d9-971b42a52080-p/+QeVIcf1ANTaRkHJHP0bjjLBE8jN/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 T24gMDMvMjIvMjAxMyAwNDo0MSBQTSwgU8O2cmVuIEJyaW5rbWFubiB3cm90ZToKPiBIaSBMYXJz LAo+IAo+IE9uIFRodSwgTWFyIDIxLCAyMDEzIGF0IDA3OjMyOjUyUE0gKzAxMDAsIExhcnMtUGV0 ZXIgQ2xhdXNlbiB3cm90ZToKPj4gT24gMDMvMjEvMjAxMyAxMjo1NiBBTSwgU8O2cmVuIEJyaW5r bWFubiB3cm90ZToKPj4+IEhpLAo+Pj4KPj4+IEkgc3BlbnQgc29tZSB0aW1lIHdvcmtpbmcgb24g dGhpcyBhbmQgaW5jb3Jwb3JhdGluZyBmZWVkYmFjay4gSGVyZSdzIGFuIHVwZGF0ZWQgcHJvcG9z YWwgZm9yIGEgY2xvY2sgY29udHJvbGxlciBmb3IgWnlucToKPj4+Cj4+PiBSZXF1aXJlZCBwcm9w ZXJ0aWVzOgo+Pj4gIC0gI2Nsb2NrLWNlbGxzIDogTXVzdCBiZSAxCj4+PiAgLSBjb21wYXRpYmxl IDogInhsbngscHM3LWNsa2MiICAodGhpcyBtYXkgYmVjb21lICd4bG54LHp5bnEtY2xrYycgdGVy bWlub2xvZ3kgZGlmZmVycyBhIGJpdCBiZXR3ZWVuIFhpbGlueCBpbnRlcm5hbCBhbmQgbWFpbmxp bmUpCj4+PiAgLSBwcy1jbGstZnJlcXVlbmN5IDogRnJlcXVlbmN5IG9mIHRoZSBvc2NpbGxhdG9y IHByb3ZpZGluZyBwc19jbGsgaW4gSFoKPj4+ICAgICAgICAgICAgICAgICAgICAgICh1c3VhbGx5 IDMzIE1IeiBvc2NpbGxhdG9ycyBhcmUgdXNlZCBmb3IgWnlucSBwbGF0Zm9ybXMpCj4+PiAgLSBj bG9jay1vdXRwdXQtbmFtZXMgOiBMaXN0IG9mIHN0cmluZ3MgdXNlZCB0byBuYW1lIHRoZSBjbG9j ayBvdXRwdXRzLiBTaGFsbCBiZSBhIGxpc3Qgb2YgdGhlIG91dHB1dHMgZ2l2ZW4gYmVsb3cuCj4+ Pgo+Pj4gT3B0aW9uYWwgcHJvcGVydGllczoKPj4+ICAtIGNsb2NrcyA6IGFzIGRlc2NyaWJlZCBp biB0aGUgY2xvY2sgYmluZGluZ3MKPj4+ICAtIGNsb2NrLW5hbWVzIDogYXMgZGVzY3JpYmVkIGlu IHRoZSBjbG9jayBiaW5kaW5ncwo+Pj4KPj4+IENsb2NrIGlucHV0czoKPj4+IFRoZSBmb2xsb3dp bmcgc3RyaW5ncyBhcmUgb3B0aW9uYWwgcGFyYW1ldGVycyB0byB0aGUgJ2Nsb2NrLW5hbWVzJyBw cm9wZXJ0eSBpbgo+Pj4gb3JkZXIgdG8gcHJvdmlkZSBvcHRpb25hbCAoRSlNSU8gY2xvY2sgc291 cmNlcy4KPj4+ICAtIHN3ZHRfZXh0X2Nsawo+Pj4gIC0gZ2VtMF9lbWlvX2Nsawo+Pj4gIC0gZ2Vt MV9lbWlvX2Nsawo+Pj4gIC0gbWlvX2Nsa19YWCAgICAgICAgICAjIHdpdGggWFggPSAwMC4uNTMK Pj4+Cj4+PiBFeGFtcGxlOgo+Pj4gICAgICAgICBjbGtjOiBjbGtjIHsKPj4+ICAgICAgICAgICAg ICAgICAjY2xvY2stY2VsbHMgPSA8MT47Cj4+PiAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9 ICJ4bG54LHBzNy1jbGtjIjsKPj4+ICAgICAgICAgICAgICAgICBwcy1jbGstZnJlcXVlbmN5ID0g PDMzMzMzMzMzPjsKPj4KPj4gVGhlIGlucHV0IGZyZXF1ZW5jeSBzaG91bGQgYmUgYSBjbG9jayBh cyB3ZWxsLgo+Cj4gQWdhaW4sIG1vbm9saXRoaWMgdnMgc3BsaXQuIEkgZG9uJ3Qgc2VlIGEgcmVh c29uIG5vdCB0byBqdXN0IGludGVybmFsbHkKPiBjYWxsIGNsa19yZWdpc3Rlcl9maXhlZF9yYXRl KCkuIFRoYXQgd2F5IGl0cyBjaGlsZHJlbiBkbyBub3QgaGF2ZSB0bwo+IGNvcGUgd2l0aCBhIHZh cmlhYmxlIG5hbWUgZm9yIHRoZSB4dGFsLgo+IEFsc28sIHdpdGggbXkgcHJvcG9zYWwgJ2Nsb2Nr cycgYW5kICdjbG9jay1uYW1lcycgd291bGQgYmUgcHVyZWx5Cj4gb3B0aW9uYWwgcHJvcGVydGll cywgb25seSByZXF1aXJlZCBpZiBvcHRpb25hbCBleHRlcm5hbCBpbnB1dHMgYXJlCj4gcHJlc2Vu dC4gSGF2aW5nIHRoZSB4dGFsIGRlZmluZWQgZXh0ZXJuYWxseSB3b3VsZCBhZGQgbWFuZGF0b3J5 IGVudHJpZXMgZm9yCj4gdGhvc2UgcHJvcHMuCgpCdXQgaXNuJ3QgdGhlIGNsb2NrIHNvdXJjZSBi b2FyZC1zcGVjaWZpYz8gSXQncyBhIGNvbXBsZXRlbHkgc2VwYXJhdGUKb2JqZWN0IGZyb20gWnlu cSdzIG93biBjbG9jayBjb250cm9sbGVyIEhXLCBhbmQgYXMgc3VjaCBzaG91bGQgYmUKcmVwcmVz ZW50ZWQgYnkgYSBzZXBhcmF0ZSBEVCBub2RlLCByaWdodD8KClRoZSBpc3N1ZSB3aXRoIHBhcmVu dCBjbG9jayBuYW1lcyBpcyBzaW1wbHkgYSByZWQgaGVycmluZy4gQSBzb2x1dGlvbiBpcwpuZWVk ZWQgdG8gcmVnaXN0ZXJlZCBjbG9jayB3aXRoIGEgcGFyZW50IGNsb2NrIG9iamVjdCwgcmF0aGVy IHRoYW4gYQpwYXJlbnQgY2xvY2sgbmFtZS4gVGhlbiwgdGhlIHBhcmVudCBuYW1lcyBhcmUgY29t cGxldGVseSBpcnJlbGV2YW50LgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpkZXZpY2V0cmVlLWRpc2N1c3MgbWFpbGluZyBsaXN0CmRldmljZXRyZWUtZGlz Y3Vzc0BsaXN0cy5vemxhYnMub3JnCmh0dHBzOi8vbGlzdHMub3psYWJzLm9yZy9saXN0aW5mby9k ZXZpY2V0cmVlLWRpc2N1c3MK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759019Ab3CYX3s (ORCPT ); Mon, 25 Mar 2013 19:29:48 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:50332 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754925Ab3CYX3r (ORCPT ); Mon, 25 Mar 2013 19:29:47 -0400 Message-ID: <5150DDDD.9010904@wwwdotorg.org> Date: Mon, 25 Mar 2013 17:29:33 -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: Lars-Peter Clausen , Mike Turquette , Josh Cartwright , Michal Simek , Peter Crosthwaite , 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> <514B5254.50101@metafoo.de> <128fc723-ace7-4f4c-95d9-971b42a52080@CH1EHSMHS028.ehs.local> In-Reply-To: <128fc723-ace7-4f4c-95d9-971b42a52080@CH1EHSMHS028.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/22/2013 04:41 PM, Sören Brinkmann wrote: > Hi Lars, > > On Thu, Mar 21, 2013 at 07:32:52PM +0100, Lars-Peter Clausen wrote: >> On 03/21/2013 12:56 AM, 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) >>> - clock-output-names : List of strings used to name the clock outputs. Shall be a list of the outputs given below. >>> >>> Optional properties: >>> - clocks : as described in the clock bindings >>> - clock-names : as described in the clock bindings >>> >>> Clock inputs: >>> The following strings are optional parameters to the 'clock-names' property in >>> order to provide optional (E)MIO clock sources. >>> - swdt_ext_clk >>> - gem0_emio_clk >>> - gem1_emio_clk >>> - mio_clk_XX # with XX = 00..53 >>> >>> Example: >>> clkc: clkc { >>> #clock-cells = <1>; >>> compatible = "xlnx,ps7-clkc"; >>> ps-clk-frequency = <33333333>; >> >> The input frequency should be a clock as well. > > Again, monolithic vs split. I don't see a reason not to just internally > call clk_register_fixed_rate(). That way its children do not have to > cope with a variable name for the xtal. > Also, with my proposal 'clocks' and 'clock-names' would be purely > optional properties, only required if optional external inputs are > present. Having the xtal defined externally would add mandatory entries for > those props. But isn't the clock source board-specific? It's a completely separate object from Zynq's own clock controller HW, and as such should be represented by a separate DT node, right? The issue with parent clock names is simply a red herring. A solution is needed to registered clock with a parent clock object, rather than a parent clock name. Then, the parent names are completely irrelevant.