From: Chanwoo Choi <cw00.choi@samsung.com>
To: myungjoo.ham@gmail.com
Cc: "Kyungmin Park" <kyungmin.park@samsung.com>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
chanwoo@kernel.org, 대인기 <inki.dae@samsung.com>,
LKML <linux-kernel@vger.kernel.org>,
"Linux PM list" <linux-pm@vger.kernel.org>
Subject: Re: [PATCH v4 3/8] PM / devfreq: Use the available min/max frequency
Date: Wed, 18 Oct 2017 10:31:02 +0900 [thread overview]
Message-ID: <59E6AED6.70703@samsung.com> (raw)
In-Reply-To: <CAJ0PZbRarw8hSmkUZydn79czJj7HK1nc2G8egQdabDRVHE7W_w@mail.gmail.com>
Hi,
On 2017년 10월 17일 23:43, MyungJoo Ham wrote:
> On Fri, Oct 13, 2017 at 4:48 PM, Chanwoo Choi <cw00.choi@samsung.com> wrote:
>> The commit a76caf55e5b35 ("thermal: Add devfreq cooling") is able
>> to disable OPP as a cooling device. In result, both update_devfreq()
>> and {min|max}_freq_show() have to consider the 'opp->available'
>> status of each OPP.
>>
>> So, this patch adds the 'scaling_{min|max}_freq' to struct devfreq
>> in order to indicate the available mininum and maximum frequency
>> by adjusting OPP interface such as dev_pm_opp_{disable|enable}().
>> The 'scaling_{min|max}_freq' are used for on both update_devfreq()
>> and {min|max}_freq_show().
>>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> ---
>> drivers/devfreq/devfreq.c | 36 ++++++++++++++++++++++++++++--------
>> include/linux/devfreq.h | 4 ++++
>> 2 files changed, 32 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>> index b6ba24e5db0d..9de013ffeb67 100644
>> --- a/drivers/devfreq/devfreq.c
>> +++ b/drivers/devfreq/devfreq.c
> []
>> @@ -494,6 +499,19 @@ static int devfreq_notifier_call(struct notifier_block *nb, unsigned long type,
>> int ret;
>>
>> mutex_lock(&devfreq->lock);
>> +
>> + devfreq->scaling_min_freq = find_available_min_freq(devfreq);
>> + if (!devfreq->scaling_min_freq) {
>> + mutex_unlock(&devfreq->lock);
>> + return -EINVAL;
>> + }
>> +
>> + devfreq->scaling_max_freq = find_available_max_freq(devfreq);
>> + if (!devfreq->max_freq) {
>
> 1. s/max_freq/scaling/max_freq/ ??
My mistake. The scaling_max_freq is right. I'll fix it.
>
> 2. what if thermal is not active or has never triggered any event and
> the user has never stated max/min? (making scaling_*_freq zero)
The devfreq-cooling.c of tmu uses the OPP interface
and then OPP interface affect the scaling_min/max_freq of devfreq
through dev_pm_opp_disable/enable(). So, even if 'thermal is not active
or has never triggered any event', devfreq will use the OPP interface
as a mandatory.
In result, I think that devfreq should maintain the correct frequency
of scaling_min/max_freq indicating the 'limit minimum/maximum frequency
requested by OPP interface' instead of zero.
So, I'll change the description of scaling_min/max_freq as following:
(by devfreq-cooling -> by OPP interface)
On v4:
+ * @scaling_min_freq: Limit minimum frequency requested by devfreq-cooling
+ * @scaling_max_freq: Limit maximum frequency requested by devfreq-cooling
On v5:
+ * @scaling_min_freq: Limit minimum frequency requested by OPP interface
+ * @scaling_max_freq: Limit maximum frequency requested by OPP interface
And, this patch showed the wrong value of min/max_freq_show() by my mistake.
I showed the 'min/max_freq' directly through min/max_freq_show()
without comparing with scaling_min/max_freq. So, I'll fix this issue as following:
---------------
On v5:
static ssize_t min_freq_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
- return sprintf(buf, "%lu\n", to_devfreq(dev)->min_freq);
+ struct devfreq *df = to_devfreq(dev);
+
+ return sprintf(buf, "%lu\n", MAX(df->scaling_min_freq, df->min_freq));
}
static ssize_t max_freq_store(struct device *dev, struct device_attribute *attr,
@@ -1161,7 +1183,9 @@ static ssize_t max_freq_store(struct device *dev, struct device_attribute *attr,
static ssize_t max_freq_show(struct device *dev, struct device_attribute *attr,
char *buf)
{
- return sprintf(buf, "%lu\n", to_devfreq(dev)->max_freq);
+ struct devfreq *df = to_devfreq(dev);
+
+ return sprintf(buf, "%lu\n", MIN(df->scaling_max_freq, df->max_freq));
---------------
>
>> + mutex_unlock(&devfreq->lock);
>> + return -EINVAL;
>> + }
>> +
>> ret = update_devfreq(devfreq);
>> mutex_unlock(&devfreq->lock);
>>
>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
next prev parent reply other threads:[~2017-10-18 1:31 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20171013074831epcas2p28bc5c380fb339650234037e9cd24fe27@epcas2p2.samsung.com>
2017-10-13 7:48 ` [PATCH v4 0/8] PM / devfreq: Use OPP interface to handle the frequency Chanwoo Choi
2017-10-13 7:48 ` [PATCH v4 1/8] PM / devfreq: Set min/max_freq when adding the devfreq device Chanwoo Choi
2017-10-13 7:48 ` [PATCH v4 2/8] Revert "PM / devfreq: Add show_one macro to delete the duplicate code" Chanwoo Choi
2017-10-13 7:48 ` [PATCH v4 3/8] PM / devfreq: Use the available min/max frequency Chanwoo Choi
2017-10-17 14:43 ` MyungJoo Ham
2017-10-18 1:31 ` Chanwoo Choi [this message]
2017-10-18 2:12 ` Chanwoo Choi
2017-10-13 7:48 ` [PATCH v4 4/8] PM / devfreq: Change return type of devfreq_set_freq_table() Chanwoo Choi
2017-10-17 14:45 ` MyungJoo Ham
2017-10-13 7:48 ` [PATCH v4 5/8] PM / devfreq: Show the all available frequencies Chanwoo Choi
2017-10-17 14:50 ` MyungJoo Ham
2017-10-13 7:48 ` [PATCH v4 6/8] PM / devfreq: Remove unneeded conditional statement Chanwoo Choi
2017-10-17 14:59 ` MyungJoo Ham
2017-10-13 7:48 ` [PATCH v4 7/8] PM / devfreq: Define the constant governor name Chanwoo Choi
2017-10-13 7:48 ` Chanwoo Choi
2017-10-13 7:48 ` Chanwoo Choi
2017-10-17 15:02 ` MyungJoo Ham
2017-10-17 15:02 ` MyungJoo Ham
2017-10-13 7:48 ` [PATCH v4 8/8] PM / devfreq: exynos-bus: Register cooling device Chanwoo Choi
2017-10-13 7:48 ` Chanwoo Choi
2017-10-17 15:11 ` MyungJoo Ham
2017-10-17 15:11 ` MyungJoo Ham
2017-10-18 2:08 ` Chanwoo Choi
2017-10-18 2:08 ` Chanwoo Choi
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=59E6AED6.70703@samsung.com \
--to=cw00.choi@samsung.com \
--cc=chanwoo@kernel.org \
--cc=inki.dae@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=myungjoo.ham@gmail.com \
--cc=rafael.j.wysocki@intel.com \
/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.