From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755249AbcI0IqV (ORCPT ); Tue, 27 Sep 2016 04:46:21 -0400 Received: from regular1.263xmail.com ([211.150.99.141]:42611 "EHLO regular1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754998AbcI0IqM (ORCPT ); Tue, 27 Sep 2016 04:46:12 -0400 X-Greylist: delayed 388 seconds by postgrey-1.27 at vger.kernel.org; Tue, 27 Sep 2016 04:46:11 EDT X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED4: 1 X-RL-SENDER: xf@rock-chips.com X-FST-TO: lin.huang@rock-chips.com X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: xf@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH v2 4/4] PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs To: Heiko Stuebner , Viresh Kumar , Stephen Boyd References: <1471510341-63926-1-git-send-email-finley.xiao@rock-chips.com> <20160912215515.GF7243@codeaurora.org> <20160926035511.GG17336@vireshk-i7> <20776501.pZ2NDOzLK3@phil> Cc: srinivas.kandagatla@linaro.org, maxime.ripard@free-electrons.com, robh+dt@kernel.org, frowand.list@gmail.com, sre@kernel.org, dbaryshkov@gmail.com, dwmw2@infradead.org, mark.rutland@arm.com, khilman@kernel.org, nm@ti.com, rjw@rjwysocki.net, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, wxt@rock-chips.com, jay.xu@rock-chips.com, rocky.hao@rock-chips.com, tim.chen@rock-chips.com, tony.xie@rock-chips.com, ulysses.huang@rock-chips.com, lin.huang@rock-chips.com From: Finley Xiao Message-ID: Date: Tue, 27 Sep 2016 16:40:22 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20776501.pZ2NDOzLK3@phil> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2016/9/26 16:05, Heiko Stuebner 写道: > Am Montag, 26. September 2016, 09:25:11 CEST schrieb Viresh Kumar: >> On 12-09-16, 14:55, Stephen Boyd wrote: >>> On 08/29, Viresh Kumar wrote: >>>> On 18-08-16, 16:52, Finlye Xiao wrote: >>>>> +static int rockchip_adjust_opp_table(struct device *cpu_dev, >>>>> + struct cpufreq_frequency_table *table, >>>>> + int volt) >>>>> +{ >>>>> + struct opp_table *opp_table; >>>>> + struct cpufreq_frequency_table *pos; >>>>> + struct dev_pm_opp *opp; >>>>> + >>>>> + if (!volt) >>>>> + return 0; >>>>> + >>>>> + rcu_read_lock(); >>>>> + >>>>> + opp_table = _find_opp_table(cpu_dev); >>>>> + if (IS_ERR(opp_table)) { >>>>> + rcu_read_unlock(); >>>>> + return PTR_ERR(opp_table); >>>>> + } >>>>> + >>>>> + cpufreq_for_each_valid_entry(pos, table) { >>>>> + opp = dev_pm_opp_find_freq_exact(cpu_dev, pos->frequency * 1000, >>>>> + true); >>>>> + if (IS_ERR(opp)) >>>>> + continue; >>>>> + >>>>> + opp->u_volt += volt; >>>>> + opp->u_volt_min += volt; >>>>> + opp->u_volt_max += volt; >>>>> + } >>>>> + >>>>> + rcu_read_unlock(); >>>>> + >>>>> + return 0; >>>>> +} >>>> I wouldn't prefer altering the opp tables from individual drivers at >>>> all. At the least, it should be done via some helpers exposed by the >>>> core. >>>> >>>> But before that I would like to hear from Stephen a bit as I recall he >>>> was also working on something similar. >>> I had a patch to modify the voltage at runtime for the "current" >>> OPP. Now that we have regulator and clk control inside OPP that >>> became a little easier to do without having to do some notifier >>> from the OPP layer to the consumers. I haven't had time to revive >>> those patches though. Should we do that? >> Perhaps yes, we should have a common place for doing all that. >> >>> Does this need to modify >>> anything besides the OPP the device is currently running at? >> Finlye, can you please answer this ? > If I understand it correctly, depending on the leakage value stored in an > efuse, all opp voltages are reduced by a certain value. Right now the driver > does it in one go for the full opp table, but of course could also do it for > each new opp individually before it gets set. > Yes， it is necessary to modify all opp voltages and I agreed with Heiko. > -- Finley From mboxrd@z Thu Jan 1 00:00:00 1970 From: Finley Xiao Subject: Re: [PATCH v2 4/4] PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs Date: Tue, 27 Sep 2016 16:40:22 +0800 Message-ID: References: <1471510341-63926-1-git-send-email-finley.xiao@rock-chips.com> <20160912215515.GF7243@codeaurora.org> <20160926035511.GG17336@vireshk-i7> <20776501.pZ2NDOzLK3@phil> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20776501.pZ2NDOzLK3@phil> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-rockchip" Errors-To: linux-rockchip-bounces+glpar-linux-rockchip=m.gmane.org-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org To: Heiko Stuebner , Viresh Kumar , Stephen Boyd Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org, nm-l0cyMroinI0@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tony.xie-TNX95d0MmH7DzftRWevZcw@public.gmane.org, srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, tim.chen-TNX95d0MmH7DzftRWevZcw@public.gmane.org, khilman-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, dbaryshkov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, ulysses.huang-TNX95d0MmH7DzftRWevZcw@public.gmane.org, jay.xu-TNX95d0MmH7DzftRWevZcw@public.gmane.org, wxt-TNX95d0MmH7DzftRWevZcw@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, lin.huang-TNX95d0MmH7DzftRWevZcw@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, rocky.hao-TNX95d0MmH7DzftRWevZcw@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org, sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org List-Id: devicetree@vger.kernel.org CgrlnKggMjAxNi85LzI2IDE2OjA1LCBIZWlrbyBTdHVlYm5lciDlhpnpgZM6Cj4gQW0gTW9udGFn LCAyNi4gU2VwdGVtYmVyIDIwMTYsIDA5OjI1OjExIENFU1Qgc2NocmllYiBWaXJlc2ggS3VtYXI6 Cj4+IE9uIDEyLTA5LTE2LCAxNDo1NSwgU3RlcGhlbiBCb3lkIHdyb3RlOgo+Pj4gT24gMDgvMjks IFZpcmVzaCBLdW1hciB3cm90ZToKPj4+PiBPbiAxOC0wOC0xNiwgMTY6NTIsIEZpbmx5ZSBYaWFv IHdyb3RlOgo+Pj4+PiArc3RhdGljIGludCByb2NrY2hpcF9hZGp1c3Rfb3BwX3RhYmxlKHN0cnVj dCBkZXZpY2UgKmNwdV9kZXYsCj4+Pj4+ICsJCQkJICAgICBzdHJ1Y3QgY3B1ZnJlcV9mcmVxdWVu Y3lfdGFibGUgKnRhYmxlLAo+Pj4+PiArCQkJCSAgICAgaW50IHZvbHQpCj4+Pj4+ICt7Cj4+Pj4+ ICsJc3RydWN0IG9wcF90YWJsZSAqb3BwX3RhYmxlOwo+Pj4+PiArCXN0cnVjdCBjcHVmcmVxX2Zy ZXF1ZW5jeV90YWJsZSAqcG9zOwo+Pj4+PiArCXN0cnVjdCBkZXZfcG1fb3BwICpvcHA7Cj4+Pj4+ ICsKPj4+Pj4gKwlpZiAoIXZvbHQpCj4+Pj4+ICsJCXJldHVybiAwOwo+Pj4+PiArCj4+Pj4+ICsJ cmN1X3JlYWRfbG9jaygpOwo+Pj4+PiArCj4+Pj4+ICsJb3BwX3RhYmxlID0gX2ZpbmRfb3BwX3Rh YmxlKGNwdV9kZXYpOwo+Pj4+PiArCWlmIChJU19FUlIob3BwX3RhYmxlKSkgewo+Pj4+PiArCQly Y3VfcmVhZF91bmxvY2soKTsKPj4+Pj4gKwkJcmV0dXJuIFBUUl9FUlIob3BwX3RhYmxlKTsKPj4+ Pj4gKwl9Cj4+Pj4+ICsKPj4+Pj4gKwljcHVmcmVxX2Zvcl9lYWNoX3ZhbGlkX2VudHJ5KHBvcywg dGFibGUpIHsKPj4+Pj4gKwkJb3BwID0gZGV2X3BtX29wcF9maW5kX2ZyZXFfZXhhY3QoY3B1X2Rl diwgcG9zLT5mcmVxdWVuY3kgKiAxMDAwLAo+Pj4+PiArCQkJCQkJIHRydWUpOwo+Pj4+PiArCQlp ZiAoSVNfRVJSKG9wcCkpCj4+Pj4+ICsJCQljb250aW51ZTsKPj4+Pj4gKwo+Pj4+PiArCQlvcHAt PnVfdm9sdCArPSB2b2x0Owo+Pj4+PiArCQlvcHAtPnVfdm9sdF9taW4gKz0gdm9sdDsKPj4+Pj4g KwkJb3BwLT51X3ZvbHRfbWF4ICs9IHZvbHQ7Cj4+Pj4+ICsJfQo+Pj4+PiArCj4+Pj4+ICsJcmN1 X3JlYWRfdW5sb2NrKCk7Cj4+Pj4+ICsKPj4+Pj4gKwlyZXR1cm4gMDsKPj4+Pj4gK30KPj4+PiBJ IHdvdWxkbid0IHByZWZlciBhbHRlcmluZyB0aGUgb3BwIHRhYmxlcyBmcm9tIGluZGl2aWR1YWwg ZHJpdmVycyBhdAo+Pj4+IGFsbC4gQXQgdGhlIGxlYXN0LCBpdCBzaG91bGQgYmUgZG9uZSB2aWEg c29tZSBoZWxwZXJzIGV4cG9zZWQgYnkgdGhlCj4+Pj4gY29yZS4KPj4+Pgo+Pj4+IEJ1dCBiZWZv cmUgdGhhdCBJIHdvdWxkIGxpa2UgdG8gaGVhciBmcm9tIFN0ZXBoZW4gYSBiaXQgYXMgSSByZWNh bGwgaGUKPj4+PiB3YXMgYWxzbyB3b3JraW5nIG9uIHNvbWV0aGluZyBzaW1pbGFyLgo+Pj4gSSBo YWQgYSBwYXRjaCB0byBtb2RpZnkgdGhlIHZvbHRhZ2UgYXQgcnVudGltZSBmb3IgdGhlICJjdXJy ZW50Igo+Pj4gT1BQLiBOb3cgdGhhdCB3ZSBoYXZlIHJlZ3VsYXRvciBhbmQgY2xrIGNvbnRyb2wg aW5zaWRlIE9QUCB0aGF0Cj4+PiBiZWNhbWUgYSBsaXR0bGUgZWFzaWVyIHRvIGRvIHdpdGhvdXQg aGF2aW5nIHRvIGRvIHNvbWUgbm90aWZpZXIKPj4+IGZyb20gdGhlIE9QUCBsYXllciB0byB0aGUg Y29uc3VtZXJzLiBJIGhhdmVuJ3QgaGFkIHRpbWUgdG8gcmV2aXZlCj4+PiB0aG9zZSBwYXRjaGVz IHRob3VnaC4gU2hvdWxkIHdlIGRvIHRoYXQ/Cj4+IFBlcmhhcHMgeWVzLCB3ZSBzaG91bGQgaGF2 ZSBhIGNvbW1vbiBwbGFjZSBmb3IgZG9pbmcgYWxsIHRoYXQuCj4+Cj4+PiBEb2VzIHRoaXMgbmVl ZCB0byBtb2RpZnkKPj4+IGFueXRoaW5nIGJlc2lkZXMgdGhlIE9QUCB0aGUgZGV2aWNlIGlzIGN1 cnJlbnRseSBydW5uaW5nIGF0Pwo+PiBGaW5seWUsIGNhbiB5b3UgcGxlYXNlIGFuc3dlciB0aGlz ID8KPiBJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCBkZXBlbmRpbmcgb24gdGhlIGxlYWth Z2UgdmFsdWUgc3RvcmVkIGluIGFuCj4gZWZ1c2UsIGFsbCBvcHAgdm9sdGFnZXMgYXJlIHJlZHVj ZWQgYnkgYSBjZXJ0YWluIHZhbHVlLiBSaWdodCBub3cgdGhlIGRyaXZlcgo+IGRvZXMgaXQgaW4g b25lIGdvIGZvciB0aGUgZnVsbCBvcHAgdGFibGUsIGJ1dCBvZiBjb3Vyc2UgY291bGQgYWxzbyBk byBpdCBmb3IKPiBlYWNoIG5ldyBvcHAgaW5kaXZpZHVhbGx5IGJlZm9yZSBpdCBnZXRzIHNldC4K PgpZZXPvvIwgaXQgaXMgbmVjZXNzYXJ5IHRvIG1vZGlmeSBhbGwgb3BwIHZvbHRhZ2VzIGFuZCAg SSBhZ3JlZWQgd2l0aCBIZWlrby4KPgoKLS0gCkZpbmxleQoKCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpMaW51eC1yb2NrY2hpcCBtYWlsaW5nIGxpc3QK TGludXgtcm9ja2NoaXBAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LXJvY2tjaGlwCg== From mboxrd@z Thu Jan 1 00:00:00 1970 From: finley.xiao@rock-chips.com (Finley Xiao) Date: Tue, 27 Sep 2016 16:40:22 +0800 Subject: [PATCH v2 4/4] PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs In-Reply-To: <20776501.pZ2NDOzLK3@phil> References: <1471510341-63926-1-git-send-email-finley.xiao@rock-chips.com> <20160912215515.GF7243@codeaurora.org> <20160926035511.GG17336@vireshk-i7> <20776501.pZ2NDOzLK3@phil> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org ? 2016/9/26 16:05, Heiko Stuebner ??: > Am Montag, 26. September 2016, 09:25:11 CEST schrieb Viresh Kumar: >> On 12-09-16, 14:55, Stephen Boyd wrote: >>> On 08/29, Viresh Kumar wrote: >>>> On 18-08-16, 16:52, Finlye Xiao wrote: >>>>> +static int rockchip_adjust_opp_table(struct device *cpu_dev, >>>>> + struct cpufreq_frequency_table *table, >>>>> + int volt) >>>>> +{ >>>>> + struct opp_table *opp_table; >>>>> + struct cpufreq_frequency_table *pos; >>>>> + struct dev_pm_opp *opp; >>>>> + >>>>> + if (!volt) >>>>> + return 0; >>>>> + >>>>> + rcu_read_lock(); >>>>> + >>>>> + opp_table = _find_opp_table(cpu_dev); >>>>> + if (IS_ERR(opp_table)) { >>>>> + rcu_read_unlock(); >>>>> + return PTR_ERR(opp_table); >>>>> + } >>>>> + >>>>> + cpufreq_for_each_valid_entry(pos, table) { >>>>> + opp = dev_pm_opp_find_freq_exact(cpu_dev, pos->frequency * 1000, >>>>> + true); >>>>> + if (IS_ERR(opp)) >>>>> + continue; >>>>> + >>>>> + opp->u_volt += volt; >>>>> + opp->u_volt_min += volt; >>>>> + opp->u_volt_max += volt; >>>>> + } >>>>> + >>>>> + rcu_read_unlock(); >>>>> + >>>>> + return 0; >>>>> +} >>>> I wouldn't prefer altering the opp tables from individual drivers at >>>> all. At the least, it should be done via some helpers exposed by the >>>> core. >>>> >>>> But before that I would like to hear from Stephen a bit as I recall he >>>> was also working on something similar. >>> I had a patch to modify the voltage at runtime for the "current" >>> OPP. Now that we have regulator and clk control inside OPP that >>> became a little easier to do without having to do some notifier >>> from the OPP layer to the consumers. I haven't had time to revive >>> those patches though. Should we do that? >> Perhaps yes, we should have a common place for doing all that. >> >>> Does this need to modify >>> anything besides the OPP the device is currently running at? >> Finlye, can you please answer this ? > If I understand it correctly, depending on the leakage value stored in an > efuse, all opp voltages are reduced by a certain value. Right now the driver > does it in one go for the full opp table, but of course could also do it for > each new opp individually before it gets set. > Yes? it is necessary to modify all opp voltages and I agreed with Heiko. > -- Finley