From: Chanwoo Choi <cw00.choi@samsung.com>
To: Matthias Kaehlcke <mka@chromium.org>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Artur Świgoń" <a.swigon@partner.samsung.com>,
"Abel Vesa" <abel.vesa@nxp.com>,
"Saravana Kannan" <saravanak@google.com>,
linux-pm@vger.kernel.org, "NXP Linux Team" <linux-imx@nxp.com>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
"Lukasz Luba" <l.luba@partner.samsung.com>,
"Kyungmin Park" <kyungmin.park@samsung.com>,
"Alexandre Bailon" <abailon@baylibre.com>,
"Leonard Crestez" <leonard.crestez@nxp.com>,
"Georgi Djakov" <georgi.djakov@linaro.org>,
linux-arm-kernel@lists.infradead.org,
"Jacky Bai" <ping.bai@nxp.com>
Subject: Re: [PATCH v9 6/8] PM / devfreq: Introduce get_freq_range helper
Date: Thu, 31 Oct 2019 11:44:25 +0900 [thread overview]
Message-ID: <28744ca2-93c4-936c-e8fa-cfc96ddab3ca@samsung.com> (raw)
In-Reply-To: <20191011182907.GN87296@google.com>
On 19. 10. 12. 오전 3:29, Matthias Kaehlcke wrote:
> On Thu, Oct 03, 2019 at 11:19:38AM -0700, Matthias Kaehlcke wrote:
>> On Wed, Oct 02, 2019 at 10:25:09PM +0300, Leonard Crestez wrote:
>>> Moving handling of min/max freq to a single function and call it from
>>> update_devfreq and for printing min/max freq values in sysfs.
>>>
>>> This changes the behavior of out-of-range min_freq/max_freq: clamping
>>> is now done at evaluation time. This means that if an out-of-range
>>> constraint is imposed by sysfs and it later becomes valid then it will
>>> be enforced.
>>>
>>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>>> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
>>> ---
>>> drivers/devfreq/devfreq.c | 110 +++++++++++++++++++++-----------------
>>> 1 file changed, 62 insertions(+), 48 deletions(-)
>>>
>>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>>> index 87eff789ce24..2d63692903ff 100644
>>> --- a/drivers/devfreq/devfreq.c
>>> +++ b/drivers/devfreq/devfreq.c
>>>
>>> ...
>>>
>>> static ssize_t min_freq_show(struct device *dev, struct device_attribute *attr,
>>> char *buf)
>>> {
>>> struct devfreq *df = to_devfreq(dev);
>>> + unsigned long min_freq, max_freq;
>>>
>>> - return sprintf(buf, "%lu\n", max(df->scaling_min_freq, df->min_freq));
>>> + mutex_lock(&df->lock);
>>> + get_freq_range(df, &min_freq, &max_freq);
>>
>> With this min/max_freq shown aren't necessarily those set through sysfs,
>> but the aggregated PM QoS values (plus OPP constraints).
>>
>> I did some testing with a WIP patch that converts devfreq_cooling.c to
>> PM QoS. When reading sysfs min/max values to double check the limits
>> set earlier I found it utterly confusing to see the sysfs min/max values
>> fluctuating due to thermal throttling, and not being able to see the
>> configured values.
>>
>> Looks like cpufreq does the same, but I'm not convinced this is a good
>> idea. I think we want to display the values set by userspace, as done
>> before managing the limits through PM QoS. Viresh, was this change of
>> userspace visible behavior done intentionally for cpufreq?
>
> ping
>
> Viresh / devfreq maintainers:
>
> Do we really want to expose through sysfs the potentially constantly
> changing aggregate min/max values, instead of those set by userspace?
Until now, the devfreq core show the available min/max frequency
through sysfs interface. I think the available min/max frequency is proper
for sysfs.
> At least for cpufreq that's a divergence from previous behavior, and
> from a userspace perspective it seems odd that you can't reliably read
> back the limit set by userspace.
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-10-31 2:39 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-02 19:25 [PATCH v9 0/8] PM / devfreq: Add dev_pm_qos support Leonard Crestez
2019-10-02 19:25 ` [PATCH v9 1/8] PM / devfreq: Don't fail devfreq_dev_release if not in list Leonard Crestez
2019-10-02 19:25 ` [PATCH v9 2/8] PM / devfreq: Fix devfreq_notifier_call returning errno Leonard Crestez
2019-10-02 21:24 ` Matthias Kaehlcke
2019-10-02 23:47 ` Leonard Crestez
2019-10-31 2:29 ` Chanwoo Choi
2019-10-02 19:25 ` [PATCH v9 3/8] PM / devfreq: Set scaling_max_freq to max on OPP notifier error Leonard Crestez
2019-10-02 21:33 ` Matthias Kaehlcke
2019-10-31 2:21 ` Chanwoo Choi
2019-10-02 19:25 ` [PATCH v9 4/8] PM / devfreq: Move more initialization before registration Leonard Crestez
2019-10-31 3:15 ` Chanwoo Choi
2019-10-31 13:31 ` Leonard Crestez
2019-11-01 8:31 ` Chanwoo Choi
2019-11-01 14:36 ` Leonard Crestez
2019-10-02 19:25 ` [PATCH v9 5/8] PM / devfreq: Don't take lock in devfreq_add_device Leonard Crestez
2019-10-02 19:25 ` [PATCH v9 6/8] PM / devfreq: Introduce get_freq_range helper Leonard Crestez
2019-10-03 18:19 ` Matthias Kaehlcke
2019-10-03 19:16 ` Leonard Crestez
2019-10-03 19:36 ` Matthias Kaehlcke
2019-10-11 18:29 ` Matthias Kaehlcke
2019-10-31 2:44 ` Chanwoo Choi [this message]
2019-10-31 2:42 ` Chanwoo Choi
2019-10-31 13:12 ` Leonard Crestez
2019-10-02 19:25 ` [PATCH v9 7/8] PM / devfreq: Add PM QoS support Leonard Crestez
2019-10-02 22:22 ` Matthias Kaehlcke
2019-10-04 17:04 ` Matthias Kaehlcke
2019-10-31 3:01 ` Chanwoo Choi
2019-10-31 13:21 ` Leonard Crestez
2019-10-02 19:25 ` [PATCH v9 8/8] PM / devfreq: Use PM QoS for sysfs min/max_freq Leonard Crestez
2019-10-04 17:05 ` Matthias Kaehlcke
2019-10-31 3:10 ` Chanwoo Choi
2019-10-23 14:06 ` [PATCH v9 0/8] PM / devfreq: Add dev_pm_qos support Leonard Crestez
2019-10-23 16:34 ` Matthias Kaehlcke
2019-10-24 16:21 ` Leonard Crestez
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=28744ca2-93c4-936c-e8fa-cfc96ddab3ca@samsung.com \
--to=cw00.choi@samsung.com \
--cc=a.swigon@partner.samsung.com \
--cc=abailon@baylibre.com \
--cc=abel.vesa@nxp.com \
--cc=georgi.djakov@linaro.org \
--cc=krzk@kernel.org \
--cc=kyungmin.park@samsung.com \
--cc=l.luba@partner.samsung.com \
--cc=leonard.crestez@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-pm@vger.kernel.org \
--cc=mka@chromium.org \
--cc=myungjoo.ham@samsung.com \
--cc=ping.bai@nxp.com \
--cc=saravanak@google.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).