From: Vince Hsu <vinceh@nvidia.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Bill Huang <bilhuang@nvidia.com>,
dgreid@google.com, olofj@chromium.org
Subject: Re: [PATCH] cpufreq: respect the min/max settings from user space
Date: Tue, 28 Oct 2014 11:25:00 +0800 [thread overview]
Message-ID: <544F0C8C.3090003@nvidia.com> (raw)
In-Reply-To: <54321F90.2010103@nvidia.com>
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 <vinceh@nvidia.com> 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 <vinceh@nvidia.com>
>>> ---
>>> 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 <viresh.kumar@linaro.org>
>
> --
> 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
WARNING: multiple messages have this Message-ID (diff)
From: Vince Hsu <vinceh@nvidia.com>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Bill Huang <bilhuang@nvidia.com>, <dgreid@google.com>,
<olofj@chromium.org>
Subject: Re: [PATCH] cpufreq: respect the min/max settings from user space
Date: Tue, 28 Oct 2014 11:25:00 +0800 [thread overview]
Message-ID: <544F0C8C.3090003@nvidia.com> (raw)
In-Reply-To: <54321F90.2010103@nvidia.com>
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 <vinceh@nvidia.com> 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 <vinceh@nvidia.com>
>>> ---
>>> 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 <viresh.kumar@linaro.org>
>
> --
> 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
next prev parent reply other threads:[~2014-10-28 3:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-02 6:55 [PATCH] cpufreq: respect the min/max settings from user space Vince Hsu
2014-10-02 6:55 ` Vince Hsu
2014-10-06 4:45 ` Viresh Kumar
2014-10-06 4:50 ` Vince Hsu
2014-10-06 4:50 ` Vince Hsu
2014-10-06 4:55 ` Viresh Kumar
2014-10-28 3:25 ` Vince Hsu [this message]
2014-10-28 3:25 ` Vince Hsu
2014-11-10 5:09 ` Viresh Kumar
2014-11-10 6:18 ` Vince Hsu
2014-11-10 6:18 ` Vince Hsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=544F0C8C.3090003@nvidia.com \
--to=vinceh@nvidia.com \
--cc=bilhuang@nvidia.com \
--cc=dgreid@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=olofj@chromium.org \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.