From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vince Hsu Subject: Re: [PATCH] cpufreq: respect the min/max settings from user space Date: Tue, 28 Oct 2014 11:25:00 +0800 Message-ID: <544F0C8C.3090003@nvidia.com> References: <1412232900-11238-1-git-send-email-vinceh@nvidia.com> <54321F90.2010103@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from hqemgate15.nvidia.com ([216.228.121.64]:9249 "EHLO hqemgate15.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752883AbaJ1DYx (ORCPT ); Mon, 27 Oct 2014 23:24:53 -0400 In-Reply-To: <54321F90.2010103@nvidia.com> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Viresh Kumar Cc: "Rafael J. Wysocki" , "linux-pm@vger.kernel.org" , Linux Kernel Mailing List , Bill Huang , dgreid@google.com, olofj@chromium.org Hi Viresh, Could you remind me where can I find this patch upstream? It seems this was missed? Thanks, Vince On 10/06/2014 12:50 PM, Vince Hsu wrote: > Hi Viresh, > > On 10/06/2014 12:45 PM, Viresh Kumar wrote: >> On 2 October 2014 12:25, Vince Hsu wrote: >>> When the user space tries to set scaling_(max|min)_freq through >>> sysfs, the cpufreq_set_policy() asks other driver's opinions >>> for the max/min frequencies. Some device drivers, like Tegra >>> CPU EDP which is not upstreamed yet though, may constrain the >>> CPU maximum frequency dynamically because of board design. >>> So if the user space access happens and some driver is capping >>> the cpu frequency at the same time, the user_policy->(max|min) >>> is overridden by the capped value, and that's not expected by >>> the user space. And if the user space is not invoked again, >>> the CPU will always be capped by the user_policy->(max|min) >>> even no drivers limit the CPU frequency any more. >>> >>> This patch preserves the user specified min/max settings, so that >>> every time the cpufreq policy is updated, the new max/min can >>> be re-evaluated correctly based on the user's expection and >>> the present device drivers' status. >>> >>> Signed-off-by: Vince Hsu >>> --- >>> Hi, >>> >>> I'm not sure if any platform that is supported mainlin might have this >>> issue, and this patch is complie tested only. >> Why only compiled tested? Why haven't you tested it on tegra? > I did test with Chrome kernel on Tegra platform. I can't do that with > mainline kernel because we haven't had the CPU EDP driver upstream yet. > > Thanks, > Vince > >> >>> drivers/cpufreq/cpufreq.c | 6 ++++-- >>> 1 file changed, 4 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c >>> index 24bf76fba141..c007cf2a3d2a 100644 >>> --- a/drivers/cpufreq/cpufreq.c >>> +++ b/drivers/cpufreq/cpufreq.c >>> @@ -524,7 +524,7 @@ static int cpufreq_set_policy(struct >>> cpufreq_policy *policy, >>> static ssize_t >>> store_##file_name \ >>> (struct cpufreq_policy *policy, const char *buf, size_t >>> count) \ >>> { \ >>> - int >>> ret; \ >>> + int ret, temp; \ >>> struct cpufreq_policy >>> new_policy; \ >>> \ >>> ret = cpufreq_get_policy(&new_policy, >>> policy->cpu); \ >>> @@ -535,8 +535,10 @@ static ssize_t >>> store_##file_name \ >>> if (ret != >>> 1) \ >>> return >>> -EINVAL; \ >>> \ >>> + temp = >>> new_policy.object; \ >>> ret = cpufreq_set_policy(policy, &new_policy); \ >>> - policy->user_policy.object = >>> policy->object; \ >>> + if >>> (!ret) \ >>> + policy->user_policy.object = >>> temp; \ >>> \ >>> return ret ? ret : >>> count; \ >>> } >> Looks fine otherwise. >> >> Acked-by: Viresh Kumar > > -- > To unsubscribe from this list: send the line "unsubscribe linux-pm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html