From mboxrd@z Thu Jan 1 00:00:00 1970 From: mturquette@linaro.org (Mike Turquette) Date: Tue, 02 Apr 2013 17:34:50 -0700 Subject: RFC v2: Zynq Clock Controller In-Reply-To: <9b6821a5-8275-427e-a5aa-1bfd8e800d1b@TX2EHSMHS027.ehs.local> References: <27dae808-1d3a-4001-8eb2-b0a6e2a34b8f@AM1EHSMHS013.ehs.local> <515093B4.2090701@wwwdotorg.org> <8fd7278d-37c5-48ff-8d06-edc64d532a96@VA3EHSMHS037.ehs.local> <5150DEB6.7070208@wwwdotorg.org> <20130327021844.4014.43809@quantum> <9b6821a5-8275-427e-a5aa-1bfd8e800d1b@TX2EHSMHS027.ehs.local> Message-ID: <20130403003450.8177.2879@quantum> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Quoting S?ren Brinkmann (2013-03-29 15:36:18) > On Tue, Mar 26, 2013 at 07:18:44PM -0700, Mike Turquette wrote: > > As long as a key exists to link two clocks together then registration > > order shouldn't matter. Originally this key was an immutable clk name > > string. > > > > If clock parents are specified in DT then that should also suffice, in > > place of doing string comparisons. > > > > If no key to pair up clocks exists then yes we will have to rely purely > > on the struct clk *opaque_cookie and register clocks in order. > Okay, so I guess, the fundamental mechanisms should be in place. What is > needed, is changing the key from being the clk name to something else. > And preferably this something else is made up of something available > through DT, so a child can reference its parent w/o the parent to be > probed first. E.g. the provider's node name + the index of the clock > output? Right, order shouldn't matter in the sense that registering a child before a parent should not constitute an absolute failure from the clock framework point of view. Folks using DT today still rely on the parent string name to link things up. Grep around for usage of of_clk_get_parent_name to see how several platforms use that during registration. > You mentioned, something like this was supposed to happen anyway, right? > Do you already have something specific in mind/are working on a > solution? > I'm not looking at it currently. If no one else gets around to it then eventually I will. It would be nice to not have to use of_clk_get_parent_name and instead have a better way to establish parent-child relationships at clock registration-time for DT clocks. Regards, Mike > S?ren From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Turquette Subject: Re: RFC v2: Zynq Clock Controller Date: Tue, 02 Apr 2013 17:34:50 -0700 Message-ID: <20130403003450.8177.2879@quantum> References: <27dae808-1d3a-4001-8eb2-b0a6e2a34b8f@AM1EHSMHS013.ehs.local> <515093B4.2090701@wwwdotorg.org> <8fd7278d-37c5-48ff-8d06-edc64d532a96@VA3EHSMHS037.ehs.local> <5150DEB6.7070208@wwwdotorg.org> <20130327021844.4014.43809@quantum> <9b6821a5-8275-427e-a5aa-1bfd8e800d1b@TX2EHSMHS027.ehs.local> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <9b6821a5-8275-427e-a5aa-1bfd8e800d1b-8XeO8fnFoNFBP3niSOyP4rjjLBE8jN/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?q?S=C3=B6ren_Brinkmann?= Cc: Josh Cartwright , =?utf-8?q?Jan_L=C3=BCbbe?= , 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 UXVvdGluZyBTw7ZyZW4gQnJpbmttYW5uICgyMDEzLTAzLTI5IDE1OjM2OjE4KQo+IE9uIFR1ZSwg TWFyIDI2LCAyMDEzIGF0IDA3OjE4OjQ0UE0gLTA3MDAsIE1pa2UgVHVycXVldHRlIHdyb3RlOgo+ ID4gQXMgbG9uZyBhcyBhIGtleSBleGlzdHMgdG8gbGluayB0d28gY2xvY2tzIHRvZ2V0aGVyIHRo ZW4gcmVnaXN0cmF0aW9uCj4gPiBvcmRlciBzaG91bGRuJ3QgbWF0dGVyLiAgT3JpZ2luYWxseSB0 aGlzIGtleSB3YXMgYW4gaW1tdXRhYmxlIGNsayBuYW1lCj4gPiBzdHJpbmcuCj4gPiAKPiA+IElm IGNsb2NrIHBhcmVudHMgYXJlIHNwZWNpZmllZCBpbiBEVCB0aGVuIHRoYXQgc2hvdWxkIGFsc28g c3VmZmljZSwgaW4KPiA+IHBsYWNlIG9mIGRvaW5nIHN0cmluZyBjb21wYXJpc29ucy4KPiA+IAo+ ID4gSWYgbm8ga2V5IHRvIHBhaXIgdXAgY2xvY2tzIGV4aXN0cyB0aGVuIHllcyB3ZSB3aWxsIGhh dmUgdG8gcmVseSBwdXJlbHkKPiA+IG9uIHRoZSBzdHJ1Y3QgY2xrICpvcGFxdWVfY29va2llIGFu ZCByZWdpc3RlciBjbG9ja3MgaW4gb3JkZXIuCj4gT2theSwgc28gSSBndWVzcywgdGhlIGZ1bmRh bWVudGFsIG1lY2hhbmlzbXMgc2hvdWxkIGJlIGluIHBsYWNlLiBXaGF0IGlzCj4gbmVlZGVkLCBp cyBjaGFuZ2luZyB0aGUga2V5IGZyb20gYmVpbmcgdGhlIGNsayBuYW1lIHRvIHNvbWV0aGluZyBl bHNlLgo+IEFuZCBwcmVmZXJhYmx5IHRoaXMgc29tZXRoaW5nIGVsc2UgaXMgbWFkZSB1cCBvZiBz b21ldGhpbmcgYXZhaWxhYmxlCj4gdGhyb3VnaCBEVCwgc28gYSBjaGlsZCBjYW4gcmVmZXJlbmNl IGl0cyBwYXJlbnQgdy9vIHRoZSBwYXJlbnQgdG8gYmUKPiBwcm9iZWQgZmlyc3QuIEUuZy4gdGhl IHByb3ZpZGVyJ3Mgbm9kZSBuYW1lICsgdGhlIGluZGV4IG9mIHRoZSBjbG9jawo+IG91dHB1dD8K ClJpZ2h0LCBvcmRlciBzaG91bGRuJ3QgbWF0dGVyIGluIHRoZSBzZW5zZSB0aGF0IHJlZ2lzdGVy aW5nIGEgY2hpbGQKYmVmb3JlIGEgcGFyZW50IHNob3VsZCBub3QgY29uc3RpdHV0ZSBhbiBhYnNv bHV0ZSBmYWlsdXJlIGZyb20gdGhlIGNsb2NrCmZyYW1ld29yayBwb2ludCBvZiB2aWV3LgoKRm9s a3MgdXNpbmcgRFQgdG9kYXkgc3RpbGwgcmVseSBvbiB0aGUgcGFyZW50IHN0cmluZyBuYW1lIHRv IGxpbmsgdGhpbmdzCnVwLiAgR3JlcCBhcm91bmQgZm9yIHVzYWdlIG9mIG9mX2Nsa19nZXRfcGFy ZW50X25hbWUgdG8gc2VlIGhvdyBzZXZlcmFsCnBsYXRmb3JtcyB1c2UgdGhhdCBkdXJpbmcgcmVn aXN0cmF0aW9uLgoKPiBZb3UgbWVudGlvbmVkLCBzb21ldGhpbmcgbGlrZSB0aGlzIHdhcyBzdXBw b3NlZCB0byBoYXBwZW4gYW55d2F5LCByaWdodD8KPiBEbyB5b3UgYWxyZWFkeSBoYXZlIHNvbWV0 aGluZyBzcGVjaWZpYyBpbiBtaW5kL2FyZSB3b3JraW5nIG9uIGEKPiBzb2x1dGlvbj8KPiAKCkkn bSBub3QgbG9va2luZyBhdCBpdCBjdXJyZW50bHkuICBJZiBubyBvbmUgZWxzZSBnZXRzIGFyb3Vu ZCB0byBpdCB0aGVuCmV2ZW50dWFsbHkgSSB3aWxsLiAgSXQgd291bGQgYmUgbmljZSB0byBub3Qg aGF2ZSB0byB1c2UKb2ZfY2xrX2dldF9wYXJlbnRfbmFtZSBhbmQgaW5zdGVhZCBoYXZlIGEgYmV0 dGVyIHdheSB0byBlc3RhYmxpc2gKcGFyZW50LWNoaWxkIHJlbGF0aW9uc2hpcHMgYXQgY2xvY2sg cmVnaXN0cmF0aW9uLXRpbWUgZm9yIERUIGNsb2Nrcy4KClJlZ2FyZHMsCk1pa2UKCj4gICAgICAg ICBTw7ZyZW4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K ZGV2aWNldHJlZS1kaXNjdXNzIG1haWxpbmcgbGlzdApkZXZpY2V0cmVlLWRpc2N1c3NAbGlzdHMu b3psYWJzLm9yZwpodHRwczovL2xpc3RzLm96bGFicy5vcmcvbGlzdGluZm8vZGV2aWNldHJlZS1k aXNjdXNzCg==