From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754673AbcBCNwm (ORCPT ); Wed, 3 Feb 2016 08:52:42 -0500 Received: from us01smtprelay-2.synopsys.com ([198.182.60.111]:59470 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752991AbcBCNwk (ORCPT ); Wed, 3 Feb 2016 08:52:40 -0500 From: Alexey Brodkin To: "mturquette@linaro.org" CC: "robh@kernel.org" , "linux-kernel@vger.kernel.org" , "daniel.lezcano@linaro.org" , "noamc@ezchip.com" , "Vineet Gupta" , "devicetree@vger.kernel.org" , "linux-snps-arc@lists.infradead.org" Subject: Re: [PATCH 2/9] ARC: [dts] Introduce Timer bindings Thread-Topic: [PATCH 2/9] ARC: [dts] Introduce Timer bindings Thread-Index: AQHRXajSbDjni/QM90q7NIDXuiLqPp8Yq24AgAAUnYCAABLEgIAAe0YAgAD3toCAAAHNAA== Date: Wed, 3 Feb 2016 13:50:28 +0000 Message-ID: <1454507428.3375.44.camel@synopsys.com> References: <1454410739-24444-1-git-send-email-vgupta@synopsys.com> <1454410739-24444-3-git-send-email-vgupta@synopsys.com> <1454418916.25997.18.camel@synopsys.com> <56B0BD2F.5080409@synopsys.com> <1454427373.25997.24.camel@synopsys.com> <1454453846.25997.31.camel@synopsys.com> <1454507041.3375.39.camel@synopsys.com> In-Reply-To: <1454507041.3375.39.camel@synopsys.com> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.121.8.171] Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u13DqkTJ029072 (re-sending because Mike's email @ti is no longer valid) Hi Mike, On Wed, 2016-02-03 at 01:57 +0300, Alexey Brodkin wrote: > Hi Vineet, > > On Tue, 2016-02-02 at 18:36 +0300, Alexey Brodkin wrote: > > Hi Vineet, > > > > On Tue, 2016-02-02 at 19:59 +0530, Vineet Gupta wrote: > > > Hi Alexey, > > > > > > On Tuesday 02 February 2016 06:45 PM, Alexey Brodkin wrote: > > > > Hi Vineet, > > > > > > > > On Tue, 2016-02-02 at 16:28 +0530, Vineet Gupta wrote: > > > > > + > > > > > +Required properties: > > > > > + > > > > > +- compatible : should be "snps,arc-timer0" > > > > > +- interrupts : single Interrupt going into parent intc > > > > > + (16 for ARCHS cores, 3 for ARC700 cores) > > > > > +- clocks : phandle to the source clock > > > > > > > > Actually we're not flexible here. > > > > See we have hard-coded "core_clk" in [PATCH 8/9]. > > > > We use it directly in show_cpuinfo() for reading clock speed > > > > as well as in axs103_early_init(). > > > > > > > > So "source clock" here MUST be "core_clk", otherwise > > > > /proc/cpuinfo will report junk instead of meaningful data at least. > > > > > > Using hardcoded DT names in generic code is total BS and I slap myself for missing > > > that in reviewing 8/9. Please fix it ! > > > > But the only other alternative to hard-coded name is use of some internal variable > > like "arc_timer_freq". > > > > I.e. we make "arc_timer_freq" global and use it for displaying core frequency. > > Well actually there's another possibility that is used on many other platforms > (ARM both 32 and 64-bit flavors is a good example) - just print bogomips instead > of additional core frequency. We're in the process of switching ARC to generic clk framework. One of the problems we're trying to solve now is how to obtain precise CPU frequency value for outputting it for example by /proc/cpuinfo. This precise (in terms of what value was set via Device Tree or extracted and decoded from CPU configuration registers) CPU frequency is very useful for example for benchmarking. In comparison bogomips might be misleading at times. Before moving to clk framework we used to have 2 ARC-specific calls arc_get_core_freq() and arc_set_core_freq() which were basically wrappers for one variable where we stored CPU frequency. I took a look at what other architectures do and so far saw these options: [1] Just print bogomips (ARM both 32- and 64-bit, m64k, Microblaze, Mips, mn10300, openrisc, s390, sh, um, unicore32, ) [2] Get frequency from some kind of architecture-specific structure or variable (Alpha, AVR32, c6x, nios2, powerpc, sparc, tile, xtensa) [3] Get frequency from cpufreq framework (ia64, x86) [4] Decode frequency from hardware registers (Blackfin) Any thoughts on what's the best way to get CPU frequency in run-time (preferably with use of clk framework so we'll need no arch-specific variables)? Regards, Alexey From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Brodkin Subject: Re: [PATCH 2/9] ARC: [dts] Introduce Timer bindings Date: Wed, 3 Feb 2016 13:50:28 +0000 Message-ID: <1454507428.3375.44.camel@synopsys.com> References: <1454410739-24444-1-git-send-email-vgupta@synopsys.com> <1454410739-24444-3-git-send-email-vgupta@synopsys.com> <1454418916.25997.18.camel@synopsys.com> <56B0BD2F.5080409@synopsys.com> <1454427373.25997.24.camel@synopsys.com> <1454453846.25997.31.camel@synopsys.com> <1454507041.3375.39.camel@synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <1454507041.3375.39.camel-HKixBCOQz3hWk0Htik3J/w@public.gmane.org> Content-Language: en-US Content-ID: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" Cc: "robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" , "noamc-d5a29ZRxExrQT0dZR+AlfA@public.gmane.org" , Vineet Gupta , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org" List-Id: devicetree@vger.kernel.org KHJlLXNlbmRpbmcgYmVjYXVzZSBNaWtlJ3MgZW1haWwgQHRpIGlzIG5vIGxvbmdlciB2YWxpZCkN Cg0KSGkgTWlrZSwNCg0KT24gV2VkLCAyMDE2LTAyLTAzIGF0IDAxOjU3ICswMzAwLCBBbGV4ZXkg QnJvZGtpbiB3cm90ZToNCj4gSGkgVmluZWV0LA0KPiANCj4gT24gVHVlLCAyMDE2LTAyLTAyIGF0 IDE4OjM2ICswMzAwLCBBbGV4ZXkgQnJvZGtpbiB3cm90ZToNCj4gPiBIaSBWaW5lZXQsDQo+ID4g DQo+ID4gT24gVHVlLCAyMDE2LTAyLTAyIGF0IDE5OjU5ICswNTMwLCBWaW5lZXQgR3VwdGEgd3Jv dGU6DQo+ID4gPiBIaSBBbGV4ZXksDQo+ID4gPiANCj4gPiA+IE9uIFR1ZXNkYXkgMDIgRmVicnVh cnkgMjAxNiAwNjo0NSBQTSwgQWxleGV5IEJyb2RraW4gd3JvdGU6DQo+ID4gPiA+IEhpIFZpbmVl dCwNCj4gPiA+ID4gDQo+ID4gPiA+IE9uIFR1ZSwgMjAxNi0wMi0wMiBhdCAxNjoyOCArMDUzMCwg VmluZWV0IEd1cHRhIHdyb3RlOg0KPiA+ID4gPiA+ICsNCj4gPiA+ID4gPiArUmVxdWlyZWQgcHJv cGVydGllczoNCj4gPiA+ID4gPiArDQo+ID4gPiA+ID4gKy0gY29tcGF0aWJsZSA6IHNob3VsZCBi ZSAic25wcyxhcmMtdGltZXIwIg0KPiA+ID4gPiA+ICstIGludGVycnVwdHMgOiBzaW5nbGUgSW50 ZXJydXB0IGdvaW5nIGludG8gcGFyZW50IGludGMNCj4gPiA+ID4gPiArICAgICAgICAgICAgKDE2 IGZvciBBUkNIUyBjb3JlcywgMyBmb3IgQVJDNzAwIGNvcmVzKQ0KPiA+ID4gPiA+ICstIGNsb2Nr cyAgICAgOiBwaGFuZGxlIHRvIHRoZSBzb3VyY2UgY2xvY2sNCj4gPiA+ID4gDQo+ID4gPiA+IEFj dHVhbGx5IHdlJ3JlIG5vdCBmbGV4aWJsZSBoZXJlLg0KPiA+ID4gPiBTZWUgd2UgaGF2ZSBoYXJk LWNvZGVkICJjb3JlX2NsayIgaW4gW1BBVENIIDgvOV0uDQo+ID4gPiA+IFdlIHVzZSBpdCBkaXJl Y3RseSBpbiBzaG93X2NwdWluZm8oKSBmb3IgcmVhZGluZyBjbG9jayBzcGVlZA0KPiA+ID4gPiBh cyB3ZWxsIGFzIGluIGF4czEwM19lYXJseV9pbml0KCkuDQo+ID4gPiA+IA0KPiA+ID4gPiBTbyAi c291cmNlIGNsb2NrIiBoZXJlIE1VU1QgYmUgImNvcmVfY2xrIiwgb3RoZXJ3aXNlDQo+ID4gPiA+ IC9wcm9jL2NwdWluZm8gd2lsbCByZXBvcnQganVuayBpbnN0ZWFkIG9mIG1lYW5pbmdmdWwgZGF0 YSBhdCBsZWFzdC4NCj4gPiA+IA0KPiA+ID4gVXNpbmcgaGFyZGNvZGVkIERUIG5hbWVzIGluIGdl bmVyaWMgY29kZSBpcyB0b3RhbCBCUyBhbmQgSSBzbGFwIG15c2VsZiBmb3IgbWlzc2luZw0KPiA+ ID4gdGhhdCBpbiByZXZpZXdpbmcgOC85LiBQbGVhc2UgZml4IGl0ICENCj4gPiANCj4gPiBCdXQg dGhlIG9ubHkgb3RoZXIgYWx0ZXJuYXRpdmUgdG8gaGFyZC1jb2RlZCBuYW1lIGlzIHVzZSBvZiBz b21lIGludGVybmFsIHZhcmlhYmxlDQo+ID4gbGlrZSAiYXJjX3RpbWVyX2ZyZXEiLg0KPiA+IA0K PiA+IEkuZS4gd2UgbWFrZSAiYXJjX3RpbWVyX2ZyZXEiIGdsb2JhbCBhbmQgdXNlIGl0IGZvciBk aXNwbGF5aW5nIGNvcmUgZnJlcXVlbmN5Lg0KPiANCj4gV2VsbCBhY3R1YWxseSB0aGVyZSdzIGFu b3RoZXIgcG9zc2liaWxpdHkgdGhhdCBpcyB1c2VkIG9uIG1hbnkgb3RoZXIgcGxhdGZvcm1zDQo+ IChBUk0gYm90aCAzMiBhbmQgNjQtYml0IGZsYXZvcnMgaXMgYSBnb29kIGV4YW1wbGUpIC0ganVz dCBwcmludCBib2dvbWlwcyBpbnN0ZWFkDQo+IG9mIGFkZGl0aW9uYWwgY29yZSBmcmVxdWVuY3ku DQoNCldlJ3JlIGluIHRoZSBwcm9jZXNzIG9mIHN3aXRjaGluZyBBUkMgdG8gZ2VuZXJpYyBjbGsg ZnJhbWV3b3JrLg0KDQpPbmUgb2YgdGhlIHByb2JsZW1zIHdlJ3JlIHRyeWluZyB0byBzb2x2ZSBu b3cgaXMgaG93IHRvIG9idGFpbg0KcHJlY2lzZSBDUFUgZnJlcXVlbmN5IHZhbHVlIGZvciBvdXRw dXR0aW5nIGl0IGZvciBleGFtcGxlIGJ5IC9wcm9jL2NwdWluZm8uDQoNClRoaXMgcHJlY2lzZSAo aW4gdGVybXMgb2Ygd2hhdCB2YWx1ZSB3YXMgc2V0IHZpYSBEZXZpY2UgVHJlZSBvciBleHRyYWN0 ZWQgYW5kIGRlY29kZWQNCmZyb20gQ1BVIGNvbmZpZ3VyYXRpb24gcmVnaXN0ZXJzKSBDUFUgZnJl cXVlbmN5IGlzIHZlcnkgdXNlZnVsIGZvciBleGFtcGxlIGZvcg0KYmVuY2htYXJraW5nLiBJbiBj b21wYXJpc29uIGJvZ29taXBzIG1pZ2h0IGJlIG1pc2xlYWRpbmcgYXQgdGltZXMuDQoNCkJlZm9y ZSBtb3ZpbmcgdG8gY2xrIGZyYW1ld29yayB3ZSB1c2VkIHRvIGhhdmUgMiBBUkMtc3BlY2lmaWMg Y2FsbHMNCmFyY19nZXRfY29yZV9mcmVxKCkgYW5kICBhcmNfc2V0X2NvcmVfZnJlcSgpIHdoaWNo IHdlcmUgYmFzaWNhbGx5IHdyYXBwZXJzIGZvcg0Kb25lIHZhcmlhYmxlIHdoZXJlIHdlIHN0b3Jl ZCBDUFUgZnJlcXVlbmN5Lg0KDQpJIHRvb2sgYSBsb29rIGF0IHdoYXQgb3RoZXIgYXJjaGl0ZWN0 dXJlcyBkbyBhbmQgc28gZmFyIHNhdyB0aGVzZSBvcHRpb25zOg0KIFsxXSBKdXN0IHByaW50IGJv Z29taXBzIChBUk0gYm90aCAzMi0gYW5kIDY0LWJpdCwgbTY0aywgTWljcm9ibGF6ZSwgTWlwcywN CiAgICAgICAgICAgICAgICAgICAgICAgICAgbW4xMDMwMCwgb3BlbnJpc2MsIHMzOTAsIHNoLCB1 bSwgdW5pY29yZTMyLCApDQogWzJdIEdldCBmcmVxdWVuY3kgZnJvbSBzb21lIGtpbmQgb2YgYXJj aGl0ZWN0dXJlLXNwZWNpZmljIHN0cnVjdHVyZSBvciB2YXJpYWJsZQ0KICAgICAoQWxwaGEsIEFW UjMyLCBjNngsIG5pb3MyLCBwb3dlcnBjLCBzcGFyYywgdGlsZSwgeHRlbnNhKSANCiBbM10gR2V0 IGZyZXF1ZW5jeSBmcm9tIGNwdWZyZXEgZnJhbWV3b3JrIChpYTY0LCB4ODYpDQogWzRdIERlY29k ZSBmcmVxdWVuY3kgZnJvbSBoYXJkd2FyZSByZWdpc3RlcnMgKEJsYWNrZmluKQ0KDQpBbnkgdGhv dWdodHMgb24gd2hhdCdzIHRoZSBiZXN0IHdheSB0byBnZXQgQ1BVIGZyZXF1ZW5jeSBpbiBydW4t dGltZQ0KKHByZWZlcmFibHkgd2l0aCB1c2Ugb2YgY2xrIGZyYW1ld29yayBzbyB3ZSdsbCBuZWVk IG5vIGFyY2gtc3BlY2lmaWMNCnZhcmlhYmxlcyk/DQoNClJlZ2FyZHMsDQpBbGV4ZXk= -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey.Brodkin@synopsys.com (Alexey Brodkin) Date: Wed, 3 Feb 2016 13:50:28 +0000 Subject: [PATCH 2/9] ARC: [dts] Introduce Timer bindings In-Reply-To: <1454507041.3375.39.camel@synopsys.com> References: <1454410739-24444-1-git-send-email-vgupta@synopsys.com> <1454410739-24444-3-git-send-email-vgupta@synopsys.com> <1454418916.25997.18.camel@synopsys.com> <56B0BD2F.5080409@synopsys.com> <1454427373.25997.24.camel@synopsys.com> <1454453846.25997.31.camel@synopsys.com> <1454507041.3375.39.camel@synopsys.com> List-ID: Message-ID: <1454507428.3375.44.camel@synopsys.com> To: linux-snps-arc@lists.infradead.org (re-sending because Mike's email @ti is no longer valid) Hi Mike, On Wed, 2016-02-03@01:57 +0300, Alexey Brodkin wrote: > Hi Vineet, > > On Tue, 2016-02-02@18:36 +0300, Alexey Brodkin wrote: > > Hi Vineet, > > > > On Tue, 2016-02-02@19:59 +0530, Vineet Gupta wrote: > > > Hi Alexey, > > > > > > On Tuesday 02 February 2016 06:45 PM, Alexey Brodkin wrote: > > > > Hi Vineet, > > > > > > > > On Tue, 2016-02-02@16:28 +0530, Vineet Gupta wrote: > > > > > + > > > > > +Required properties: > > > > > + > > > > > +- compatible : should be "snps,arc-timer0" > > > > > +- interrupts : single Interrupt going into parent intc > > > > > + (16 for ARCHS cores, 3 for ARC700 cores) > > > > > +- clocks : phandle to the source clock > > > > > > > > Actually we're not flexible here. > > > > See we have hard-coded "core_clk" in [PATCH 8/9]. > > > > We use it directly in show_cpuinfo() for reading clock speed > > > > as well as in axs103_early_init(). > > > > > > > > So "source clock" here MUST be "core_clk", otherwise > > > > /proc/cpuinfo will report junk instead of meaningful data at least. > > > > > > Using hardcoded DT names in generic code is total BS and I slap myself for missing > > > that in reviewing 8/9. Please fix it ! > > > > But the only other alternative to hard-coded name is use of some internal variable > > like "arc_timer_freq". > > > > I.e. we make "arc_timer_freq" global and use it for displaying core frequency. > > Well actually there's another possibility that is used on many other platforms > (ARM both 32 and 64-bit flavors is a good example) - just print bogomips instead > of additional core frequency. We're in the process of switching ARC to generic clk framework. One of the problems we're trying to solve now is how to obtain precise CPU frequency value for outputting it for example by /proc/cpuinfo. This precise (in terms of what value was set via Device Tree or extracted and decoded from CPU configuration registers) CPU frequency is very useful for example for benchmarking. In comparison bogomips might be misleading at times. Before moving to clk framework we used to have 2 ARC-specific calls arc_get_core_freq() and arc_set_core_freq() which were basically wrappers for one variable where we stored CPU frequency. I took a look at what other architectures do and so far saw these options: [1] Just print bogomips (ARM both 32- and 64-bit, m64k, Microblaze, Mips, mn10300, openrisc, s390, sh, um, unicore32, ) [2] Get frequency from some kind of architecture-specific structure or variable (Alpha, AVR32, c6x, nios2, powerpc, sparc, tile, xtensa) [3] Get frequency from cpufreq framework (ia64, x86) [4] Decode frequency from hardware registers (Blackfin) Any thoughts on what's the best way to get CPU frequency in run-time (preferably with use of clk framework so we'll need no arch-specific variables)? Regards, Alexey