From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753192Ab2FSFea (ORCPT ); Tue, 19 Jun 2012 01:34:30 -0400 Received: from na3sys009aog121.obsmtp.com ([74.125.149.145]:44015 "EHLO na3sys009aog121.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752615Ab2FSFe3 (ORCPT ); Tue, 19 Jun 2012 01:34:29 -0400 From: Xiaoguang Chen To: "myungjoo.ham@samsung.com" , Xiaoguang Chen CC: "linux-kernel@vger.kernel.org" , =?ks_c_5601-1987?B?udqw5rnO?= , "linux-pm@lists.linux-foundation.org" , "myungjoo.ham@gmail.com" Date: Mon, 18 Jun 2012 22:30:30 -0700 Subject: RE: RE: Re: [PATCH 1/2] PM: devfreq: add freq table and available_freqs Thread-Topic: RE: Re: [PATCH 1/2] PM: devfreq: add freq table and available_freqs Thread-Index: Ac1N2RDiVycuxMCRR9ObB/DAvMByRgAA0FOQ Message-ID: <4737A960563B524DA805CA602BE04B3064CBDF740D@SC-VEXCH2.marvell.com> References: <9923093.588271340082284749.JavaMail.weblogic@epml24> In-Reply-To: <9923093.588271340082284749.JavaMail.weblogic@epml24> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: zh-CN, en-US Content-Type: text/plain; charset="ks_c_5601-1987" 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 nfs id q5J5YtYR026044 OK, I get it. Another question, do you guys ever want to add the devfreq governor dynamic change feature? I mean we can switch governors for one devfreq driver dynamically in devfreq framework. current framework only supports statically compile the governor and can't change it dynamically. Thanks Xiaoguang -----Original Message----- From: 함명주 [mailto:myungjoo.ham@samsung.com] Sent: 2012年6月19日 13:05 To: Xiaoguang Chen; Xiaoguang Chen Cc: linux-kernel@vger.kernel.org; 박경민; linux-pm@lists.linux-foundation.org; myungjoo.ham@gmail.com Subject: Re: RE: Re: [PATCH 1/2] PM: devfreq: add freq table and available_freqs > Hi, Myungjoo > > the API is optional, but I think one frequency table is better to have. > if user space want to see what is the supported frequencies for the specific devfreq driver, then where do you think we can see this interface? > do we have to go to OPP framework to get it ? or we can just add it in > our devfreq ? for example: > sys/class/devfreq/xxx-devfreq/available_freqs > I think it is best for us to see this in the same sysfs path. > > Thanks > Xiaoguang Hi Xiaoguang, First of all, both conceptually and practically, devfreq subsystem does not need to hold the list of available frequencies. Devfreq subsystem does not care whether a devfreq device has only two (or even one) frequencies available or several billions frequencies available, which is why OPP is dropped from devfreq subsystem and only helper functions are remaining. The available frequencies information may be in OPP, clock subsystem, or the device driver itself. The listing of available frequencies should be provided by the one who has the information at first. Anyway, except for the pure curiosity of users, why do we need to provide the list of available frequencies at the devfreq subsystem? If we are adding it in devfreq subsystem, we are adding an ABI and supporting data structure that are never used by the subsystem, but for printing out via ABI which only satisfies the curiosity of users that may already know what it would list up. There are even cases where the devfreq device driver itself also does not aware of avilable frequencies; when OPP is given outside. Cheers! MyungJoo. > > > -----Original Message----- > From: 함명주 [mailto:myungjoo.ham@samsung.com] > Sent: 2012年6月14日 12:44 > To: Xiaoguang Chen > Cc: Xiaoguang Chen; linux-kernel@vger.kernel.org; 박경민; > linux-pm@lists.linux-foundation.org > Subject: Re: Re: [PATCH 1/2] PM: devfreq: add freq table and > available_freqs > > > Hi, Myungjoo > > > > > > what's your opinion? > > Hello Xiaoguang, > > Still, I don't think we need additional API and ABI for a simple frequency table. Why a devfreq device driver would want to register a table in struct devfreq while it can hold one either with its dev-data, private data of devfreq, or even OPP. > > 1. Devfreq is not "combined" with OPP. OPP is optional. > > 2. I guess filling voltage column with some arbitrary values in OPP table won't hurt anything if the device does not care voltage values. (just a suggestion and speculation) Thus, you can still use OPP in your case as long as the frequency values are discrete and not too many. > > 3. Devfreq and its governors recommends the base frequency to devfreq drivers. Frequency table is only needed to be visible to devfreq drivers, not to governors or devfreq itself. The frequency table you've suggested is not need to be visible to devfreq subsystem. > > > I still object to adding a frequency table (which is already supported by OPP by not specifying voltage or specifying arbitrary voltage values). However, even if I don't, we won't need that API (devfreq_set_freq_table), which should've been added in device profile at devfreq_add_device() time. > > > Cheers! > MyungJoo. > > > > > > > Thanks > > Xiaoguang > > > > > > > 2012/6/13 Xiaoguang Chen > > > > > > I think Devfreq should not be combined with OPP, OPP framework > > > does contain one frequency table, but the frequency is combined with voltage. some platforms may don't want to use this but handling voltage seperately in their clock driver. > > > > > > > > > and some platforms don't use OPP, and they want a frequency list. > > > then this is necessary. also devfreq should contain a frequency list even without any other frameworks, don't you think so ? > > > > > > > > > Thanks > > > Xiaoguang > > > > > > > > > > > > 2012/6/13 MyungJoo Ham > > > > > > > > > Devfreq framework don't have a frequency table, add it for > > > > > easy use. > > > > > > > > > > Signed-off-by: Xiaoguang Chen > > > > > > > > > > > > If you need a predefined data structure to support frequency > > > > table, you can simply use OPP, which has helper functions > > > > implemented in devfreq subsystem. Is there any reason not to use > > > > OPP and to implement another data structure to store a frequency table attached to a device? > > > > > > > > > > > > Cheers! > > > > MyungJoo. > > > > > > > > > > > �淸�{.n�+돴윯돪�+%듚�깁負쪐w��{.n�+돴쪐{깸G쳺���{ay��뉅숇,j�줲＂톒쉹�곴�묎�z_溫(��쉸듶줷"얎�m������G쳺��◀?솳鈺�&ｘ�~뤳턨O뺞촾퇉v�^�m���� �띠�◀?뻀� From mboxrd@z Thu Jan 1 00:00:00 1970 From: Xiaoguang Chen Subject: RE: RE: Re: [PATCH 1/2] PM: devfreq: add freq table and available_freqs Date: Mon, 18 Jun 2012 22:30:30 -0700 Message-ID: <4737A960563B524DA805CA602BE04B3064CBDF740D@SC-VEXCH2.marvell.com> References: <9923093.588271340082284749.JavaMail.weblogic@epml24> Mime-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <9923093.588271340082284749.JavaMail.weblogic@epml24> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: "myungjoo.ham@samsung.com" , Xiaoguang Chen Cc: "linux-kernel@vger.kernel.org" , =?ks_c_5601-1987?B?udqw5rnO?= , "linux-pm@lists.linux-foundation.org" , "myungjoo.ham@gmail.com" List-Id: linux-pm@vger.kernel.org T0ssIEkgZ2V0IGl0Lg0KQW5vdGhlciBxdWVzdGlvbiwgZG8geW91IGd1eXMgZXZlciB3YW50IHRv IGFkZCB0aGUgZGV2ZnJlcSBnb3Zlcm5vciBkeW5hbWljIGNoYW5nZSBmZWF0dXJlPw0KDQpJIG1l YW4gd2UgY2FuIHN3aXRjaCBnb3Zlcm5vcnMgZm9yIG9uZSBkZXZmcmVxIGRyaXZlciBkeW5hbWlj YWxseSBpbiBkZXZmcmVxIGZyYW1ld29yay4gY3VycmVudCBmcmFtZXdvcmsgb25seSBzdXBwb3J0 cyBzdGF0aWNhbGx5IGNvbXBpbGUgdGhlIGdvdmVybm9yIGFuZCBjYW4ndCBjaGFuZ2UgaXQgZHlu YW1pY2FsbHkuIA0KDQpUaGFua3MNClhpYW9ndWFuZw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiDH1LjtwdYgW21haWx0bzpteXVuZ2pvby5oYW1Ac2Ftc3VuZy5jb21dIA0K U2VudDogMjAxMtK0NurFMTns7SAxMzowNQ0KVG86IFhpYW9ndWFuZyBDaGVuOyBYaWFvZ3Vhbmcg Q2hlbg0KQ2M6IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7ILnasOa5zjsgbGludXgtcG1A bGlzdHMubGludXgtZm91bmRhdGlvbi5vcmc7IG15dW5nam9vLmhhbUBnbWFpbC5jb20NClN1Ympl Y3Q6IFJlOiBSRTogUmU6IFtQQVRDSCAxLzJdIFBNOiBkZXZmcmVxOiBhZGQgZnJlcSB0YWJsZSBh bmQgYXZhaWxhYmxlX2ZyZXFzDQoNCj4gSGksIE15dW5nam9vDQo+IA0KPiB0aGUgQVBJIGlzIG9w dGlvbmFsLCBidXQgSSB0aGluayBvbmUgZnJlcXVlbmN5IHRhYmxlIGlzIGJldHRlciB0byBoYXZl Lg0KPiBpZiB1c2VyIHNwYWNlIHdhbnQgdG8gc2VlIHdoYXQgaXMgdGhlIHN1cHBvcnRlZCBmcmVx dWVuY2llcyBmb3IgdGhlIHNwZWNpZmljIGRldmZyZXEgZHJpdmVyLCB0aGVuIHdoZXJlIGRvIHlv dSB0aGluayB3ZSBjYW4gc2VlIHRoaXMgaW50ZXJmYWNlPw0KPiBkbyB3ZSBoYXZlIHRvIGdvIHRv IE9QUCBmcmFtZXdvcmsgdG8gZ2V0IGl0ID8gb3Igd2UgY2FuIGp1c3QgYWRkIGl0IGluIA0KPiBv dXIgZGV2ZnJlcSA/IGZvciBleGFtcGxlOiANCj4gc3lzL2NsYXNzL2RldmZyZXEveHh4LWRldmZy ZXEvYXZhaWxhYmxlX2ZyZXFzDQo+IEkgdGhpbmsgaXQgaXMgYmVzdCBmb3IgdXMgdG8gc2VlIHRo aXMgaW4gdGhlIHNhbWUgc3lzZnMgcGF0aC4NCj4gDQo+IFRoYW5rcw0KPiBYaWFvZ3VhbmcNCg0K SGkgWGlhb2d1YW5nLA0KDQpGaXJzdCBvZiBhbGwsIGJvdGggY29uY2VwdHVhbGx5IGFuZCBwcmFj dGljYWxseSwgZGV2ZnJlcSBzdWJzeXN0ZW0gZG9lcyBub3QgbmVlZCB0byBob2xkIHRoZSBsaXN0 IG9mIGF2YWlsYWJsZSBmcmVxdWVuY2llcy4gRGV2ZnJlcSBzdWJzeXN0ZW0gZG9lcyBub3QgY2Fy ZSB3aGV0aGVyIGEgZGV2ZnJlcSBkZXZpY2UgaGFzIG9ubHkgdHdvIChvciBldmVuIG9uZSkgZnJl cXVlbmNpZXMgYXZhaWxhYmxlIG9yIHNldmVyYWwgYmlsbGlvbnMgZnJlcXVlbmNpZXMgYXZhaWxh YmxlLCB3aGljaCBpcyB3aHkgT1BQIGlzIGRyb3BwZWQgZnJvbSBkZXZmcmVxIHN1YnN5c3RlbSBh bmQgb25seSBoZWxwZXIgZnVuY3Rpb25zIGFyZSByZW1haW5pbmcuDQoNClRoZSBhdmFpbGFibGUg ZnJlcXVlbmNpZXMgaW5mb3JtYXRpb24gbWF5IGJlIGluIE9QUCwgY2xvY2sgc3Vic3lzdGVtLCBv ciB0aGUgZGV2aWNlIGRyaXZlciBpdHNlbGYuIFRoZSBsaXN0aW5nIG9mIGF2YWlsYWJsZSBmcmVx dWVuY2llcyBzaG91bGQgYmUgcHJvdmlkZWQgYnkgdGhlIG9uZSB3aG8gaGFzIHRoZSBpbmZvcm1h dGlvbiBhdCBmaXJzdC4NCg0KQW55d2F5LCBleGNlcHQgZm9yIHRoZSBwdXJlIGN1cmlvc2l0eSBv ZiB1c2Vycywgd2h5IGRvIHdlIG5lZWQgdG8gcHJvdmlkZSB0aGUgbGlzdCBvZiBhdmFpbGFibGUg ZnJlcXVlbmNpZXMgYXQgdGhlIGRldmZyZXEgc3Vic3lzdGVtPyBJZiB3ZSBhcmUgYWRkaW5nIGl0 IGluIGRldmZyZXEgc3Vic3lzdGVtLCB3ZSBhcmUgYWRkaW5nIGFuIEFCSSBhbmQgc3VwcG9ydGlu ZyBkYXRhIHN0cnVjdHVyZSB0aGF0IGFyZSBuZXZlciB1c2VkIGJ5IHRoZSBzdWJzeXN0ZW0sIGJ1 dCBmb3IgcHJpbnRpbmcgb3V0IHZpYSBBQkkgd2hpY2ggb25seSBzYXRpc2ZpZXMgdGhlIGN1cmlv c2l0eSBvZiB1c2VycyB0aGF0IG1heSBhbHJlYWR5IGtub3cgd2hhdCBpdCB3b3VsZCBsaXN0IHVw LiBUaGVyZSBhcmUgZXZlbiBjYXNlcyB3aGVyZSB0aGUgZGV2ZnJlcSBkZXZpY2UgZHJpdmVyIGl0 c2VsZiBhbHNvIGRvZXMgbm90IGF3YXJlIG9mIGF2aWxhYmxlIGZyZXF1ZW5jaWVzOyB3aGVuIE9Q UCBpcyBnaXZlbiBvdXRzaWRlLg0KDQoNCkNoZWVycyENCk15dW5nSm9vLg0KDQo+IA0KPiANCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogx9S47cHWIFttYWlsdG86bXl1bmdq b28uaGFtQHNhbXN1bmcuY29tXQ0KPiBTZW50OiAyMDEy0rQ26sUxNOztIDEyOjQ0DQo+IFRvOiBY aWFvZ3VhbmcgQ2hlbg0KPiBDYzogWGlhb2d1YW5nIENoZW47IGxpbnV4LWtlcm5lbEB2Z2VyLmtl cm5lbC5vcmc7ILnasOa5zjsgDQo+IGxpbnV4LXBtQGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3Jn DQo+IFN1YmplY3Q6IFJlOiBSZTogW1BBVENIIDEvMl0gUE06IGRldmZyZXE6IGFkZCBmcmVxIHRh YmxlIGFuZCANCj4gYXZhaWxhYmxlX2ZyZXFzDQo+IA0KPiA+IEhpLCBNeXVuZ2pvbw0KPiA+IA0K PiA+IA0KPiA+IHdoYXQncyB5b3VyIG9waW5pb24/DQo+IA0KPiBIZWxsbyBYaWFvZ3VhbmcsDQo+ IA0KPiBTdGlsbCwgSSBkb24ndCB0aGluayB3ZSBuZWVkIGFkZGl0aW9uYWwgQVBJIGFuZCBBQkkg Zm9yIGEgc2ltcGxlIGZyZXF1ZW5jeSB0YWJsZS4gV2h5IGEgZGV2ZnJlcSBkZXZpY2UgZHJpdmVy IHdvdWxkIHdhbnQgdG8gcmVnaXN0ZXIgYSB0YWJsZSBpbiBzdHJ1Y3QgZGV2ZnJlcSB3aGlsZSBp dCBjYW4gaG9sZCBvbmUgZWl0aGVyIHdpdGggaXRzIGRldi1kYXRhLCBwcml2YXRlIGRhdGEgb2Yg ZGV2ZnJlcSwgb3IgZXZlbiBPUFAuDQo+IA0KPiAxLiBEZXZmcmVxIGlzIG5vdCAiY29tYmluZWQi IHdpdGggT1BQLiBPUFAgaXMgb3B0aW9uYWwuDQo+IA0KPiAyLiBJIGd1ZXNzIGZpbGxpbmcgdm9s dGFnZSBjb2x1bW4gd2l0aCBzb21lIGFyYml0cmFyeSB2YWx1ZXMgaW4gT1BQIHRhYmxlIHdvbid0 IGh1cnQgYW55dGhpbmcgaWYgdGhlIGRldmljZSBkb2VzIG5vdCBjYXJlIHZvbHRhZ2UgdmFsdWVz LiAoanVzdCBhIHN1Z2dlc3Rpb24gYW5kIHNwZWN1bGF0aW9uKSBUaHVzLCB5b3UgY2FuIHN0aWxs IHVzZSBPUFAgaW4geW91ciBjYXNlIGFzIGxvbmcgYXMgdGhlIGZyZXF1ZW5jeSB2YWx1ZXMgYXJl IGRpc2NyZXRlIGFuZCBub3QgdG9vIG1hbnkuDQo+IA0KPiAzLiBEZXZmcmVxIGFuZCBpdHMgZ292 ZXJub3JzIHJlY29tbWVuZHMgdGhlIGJhc2UgZnJlcXVlbmN5IHRvIGRldmZyZXEgZHJpdmVycy4g RnJlcXVlbmN5IHRhYmxlIGlzIG9ubHkgbmVlZGVkIHRvIGJlIHZpc2libGUgdG8gZGV2ZnJlcSBk cml2ZXJzLCBub3QgdG8gZ292ZXJub3JzIG9yIGRldmZyZXEgaXRzZWxmLiBUaGUgZnJlcXVlbmN5 IHRhYmxlIHlvdSd2ZSBzdWdnZXN0ZWQgaXMgbm90IG5lZWQgdG8gYmUgdmlzaWJsZSB0byBkZXZm cmVxIHN1YnN5c3RlbS4NCj4gDQo+IA0KPiBJIHN0aWxsIG9iamVjdCB0byBhZGRpbmcgYSBmcmVx dWVuY3kgdGFibGUgKHdoaWNoIGlzIGFscmVhZHkgc3VwcG9ydGVkIGJ5IE9QUCBieSBub3Qgc3Bl Y2lmeWluZyB2b2x0YWdlIG9yIHNwZWNpZnlpbmcgYXJiaXRyYXJ5IHZvbHRhZ2UgdmFsdWVzKS4g SG93ZXZlciwgZXZlbiBpZiBJIGRvbid0LCB3ZSB3b24ndCBuZWVkIHRoYXQgQVBJIChkZXZmcmVx X3NldF9mcmVxX3RhYmxlKSwgd2hpY2ggc2hvdWxkJ3ZlIGJlZW4gYWRkZWQgaW4gZGV2aWNlIHBy b2ZpbGUgYXQgZGV2ZnJlcV9hZGRfZGV2aWNlKCkgdGltZS4NCj4gDQo+IA0KPiBDaGVlcnMhDQo+ IE15dW5nSm9vLg0KPiANCj4gPiANCj4gPiANCj4gPiBUaGFua3MNCj4gPiBYaWFvZ3VhbmcNCj4g PiANCj4gPiANCj4gPiA+IDIwMTIvNi8xMyBYaWFvZ3VhbmcgQ2hlbiA8Y2hlbnhnLm1hcnZlbGxA Z21haWwuY29tPg0KPiA+ID4gDQo+ID4gPiBJIHRoaW5rIERldmZyZXEgc2hvdWxkIG5vdCBiZSBj b21iaW5lZCB3aXRoIE9QUCwgT1BQIGZyYW1ld29yayANCj4gPiA+IGRvZXMgY29udGFpbiBvbmUg ZnJlcXVlbmN5IHRhYmxlLCBidXQgdGhlIGZyZXF1ZW5jeSBpcyBjb21iaW5lZCB3aXRoIHZvbHRh Z2UuIHNvbWUgcGxhdGZvcm1zIG1heSBkb24ndCB3YW50IHRvIHVzZSB0aGlzIGJ1dCBoYW5kbGlu ZyB2b2x0YWdlIHNlcGVyYXRlbHkgaW4gdGhlaXIgY2xvY2sgZHJpdmVyLg0KPiA+ID4gDQo+ID4g PiANCj4gPiA+IGFuZCBzb21lIHBsYXRmb3JtcyBkb24ndCB1c2UgT1BQLCBhbmQgdGhleSB3YW50 IGEgZnJlcXVlbmN5IGxpc3QuDQo+ID4gPiB0aGVuIHRoaXMgaXMgbmVjZXNzYXJ5LiBhbHNvIGRl dmZyZXEgc2hvdWxkIGNvbnRhaW4gYSBmcmVxdWVuY3kgbGlzdCBldmVuIHdpdGhvdXQgYW55IG90 aGVyIGZyYW1ld29ya3MsIGRvbid0IHlvdSB0aGluayBzbyA/DQo+ID4gPiANCj4gPiA+IA0KPiA+ ID4gVGhhbmtzDQo+ID4gPiBYaWFvZ3VhbmcNCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+ IDIwMTIvNi8xMyBNeXVuZ0pvbyBIYW0gPG15dW5nam9vLmhhbUBzYW1zdW5nLmNvbT4NCj4gPiA+ ID4gDQo+ID4gPiA+ID4gRGV2ZnJlcSBmcmFtZXdvcmsgZG9uJ3QgaGF2ZSBhIGZyZXF1ZW5jeSB0 YWJsZSwgYWRkIGl0IGZvciANCj4gPiA+ID4gPiBlYXN5IHVzZS4NCj4gPiA+ID4gPg0KPiA+ID4g PiA+IFNpZ25lZC1vZmYtYnk6IFhpYW9ndWFuZyBDaGVuIDxjaGVueGdAbWFydmVsbC5jb20+DQo+ ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gSWYgeW91IG5lZWQgYSBwcmVkZWZpbmVkIGRhdGEg c3RydWN0dXJlIHRvIHN1cHBvcnQgZnJlcXVlbmN5IA0KPiA+ID4gPiB0YWJsZSwgeW91IGNhbiBz aW1wbHkgdXNlIE9QUCwgd2hpY2ggaGFzIGhlbHBlciBmdW5jdGlvbnMgDQo+ID4gPiA+IGltcGxl bWVudGVkIGluIGRldmZyZXEgc3Vic3lzdGVtLiBJcyB0aGVyZSBhbnkgcmVhc29uIG5vdCB0byB1 c2UgDQo+ID4gPiA+IE9QUCBhbmQgdG8gaW1wbGVtZW50IGFub3RoZXIgZGF0YSBzdHJ1Y3R1cmUg dG8gc3RvcmUgYSBmcmVxdWVuY3kgdGFibGUgYXR0YWNoZWQgdG8gYSBkZXZpY2U/DQo+ID4gPiA+ IA0KPiA+ID4gPiANCj4gPiA+ID4gQ2hlZXJzIQ0KPiA+ID4gPiBNeXVuZ0pvby4NCj4gPiA+ID4g DQo+IA0KPiANCj4gDQo+ICAgICAgICANCj4gICANCj4gICAgICAgICAgDQo+IA0K