From: Chanwoo Choi <cw00.choi@samsung.com>
To: Leonard Crestez <leonard.crestez@nxp.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
Saravana Kannan <saravanak@google.com>
Cc: "MyungJoo Ham" <myungjoo.ham@samsung.com>,
"Kyungmin Park" <kyungmin.park@samsung.com>,
"Artur Świgoń" <a.swigon@partner.samsung.com>,
"Krzysztof Kozlowski" <krzk@kernel.org>,
"Alexandre Bailon" <abailon@baylibre.com>,
"Georgi Djakov" <georgi.djakov@linaro.org>,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
"Lukasz Luba" <l.luba@partner.samsung.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"cpgs (cpgs@samsung.com)" <cpgs@samsung.com>
Subject: Re: [PATCHv2] PM / devfreq: Add dev_pm_qos support
Date: Wed, 14 Aug 2019 10:17:45 +0900 [thread overview]
Message-ID: <195bef25-5235-4c24-cc7a-48d368da3bbd@samsung.com> (raw)
In-Reply-To: <a9328230-96f3-6bab-826a-bb199de4ad48@samsung.com>
On 19. 8. 14. 오전 10:06, Chanwoo Choi wrote:
> Hi,
>
> On 19. 8. 13. 오후 8:27, Leonard Crestez wrote:
>> On 13.08.2019 09:10, Chanwoo Choi wrote:
>>> In case of cpufreq, cpufreq.c replace the body of store_min_freq()
>>> and store_max_freq() by using struct dev_pm_qos_request instancce
>>> with dev_pm_qos_update_request().
>>>
>>> If you use the new way with dev_pm_qos_update_request() for
>>> min_freq_store() and max_freq_store(), it doesn't need to
>>> get the final frequency from three candidate frequencies.
>>
>> Yes, I saw that but didn't implement the equivalent for devfreq because
>> it's not clear what there is to gain.
>
> I think that it is clear. Just use the dev_pm_qos_request interface
> for both user input through sysfs and device input with qos request.
> Already PM_QOS has the feature to get the final freuency among
> the multiple request. When use the dev_pm_qos request, the devfreq
> doesn't need to compare between user input and device input with qos.
> It make devfreq core more clear and simple
>
>>
>> Since dev_pm_qos is measured in khz it means that min_freq/max_req on
>> sysfq would lose 3 significant digits, however those digits are probably
>> useless anyway.
>
> I think that it doesn't matter. This patch already considers the this issue
> by using '* 1000'. We can get either KHz or MHz with additional operation.
> I think that it is not problem.
>
>>
>>> In result, We only consider the following two candidate frequencies
>>> as following:
>>> 1. "devfreq->scaling_min_freq" will contain the requirement
>>> from devfreq thermal throttling by OPP interface.
>>
>> It's a bit awkward that the OPPs enable/disable API is not obviously
>> specific to "thermal".
>
> driver/thermal/devfreq_cooling.c uses the OPP interface to enable/disable
> the OPP entries according to the thermal throttling policy.
>
>>
>>> 2. "devfreq->min_freq" will contain the requirements
>>> from both user input through sysfs and the dev_pm_qos_request.
>> According to a comment on a previous version it would be useful to have
>> a separate files for "constraint min/max freq" and "user min/max freq":
>>
>> https://patchwork.kernel.org/patch/11078475/#22805379
>
> Actually, I think that I want to use the only dev_pm_qos_request
> for all external request like devfreq cooling of thermal,
> user input through sysfs and device request with dev_pm_qos_request.
>
> Already, dev_pm_qos_request is designed to consider the multiple requirements.
> We don't need to use the various method (OPP interface, sysfs input, dev_pm_qos)
> because make it more simple and easy.
>
> I think that after finished the review of this patch, I will do refactor the devfreq_cooling.c
> by using the dev_pm_qos_request. Or, if there are some volunteeer,
Sorry, I would withdraw the this opinion about replacing
the OPP enable/disable interface with the dev_pm_qos_request
because even if devfreq-cooling.c needs the 'dev' instance
to use the dev_pm_qos_request method, it is not clear until now.
It needs how to get the device instance of devfreq on device-tree.
Keep discussing without it.
>
>>
>> Combining min/max requests from dev_pm_qos and sysfs would make this
>> harder to implement. I guess user_min_freq could be implemented by
>
> I think that it is not difficult. Just make the different dev_pm_qos_request
> instances. When qos has the multiple request from one more dev_pm_qos_request,
> just get the value by using dev_pm_qos_read_value().
> - a dev_pm_qos_request for user input
> - b dev_pm_qos_request for device request on other device driver
>
>
>> reading back the dev_pm_qos request but there would be no way to
>> implement a qos_min_freq entry.
>
> I don't understand. Just devfreq show the min freq from dev_pm_qos_request
> which contains the all requirement of minimum frequency.
>
> If there are no any request to dev_pm_qos_request, we can just
> get the minimum frequency from dev_pm_qos_request because
> the devfreq device would call the dev_pm_qos_update_request(..., min_freq)
> on the probe time.
>
> If I know the wrong information, please let me know.
>
>
>>
>>>> +static int devfreq_qos_min_notifier_call(struct notifier_block *nb, unsigned long val, void *ptr)
>>>
>>> Please keep the under 80 line if there are no any special reason.
>>
>> OK, will check.
>>
>>
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
next prev parent reply other threads:[~2019-08-14 1:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20190808143919epcas4p33c93a5a3d4df1032fa84ddad9110a160@epcas4p3.samsung.com>
2019-08-08 14:39 ` [PATCHv2] PM / devfreq: Add dev_pm_qos support Leonard Crestez
2019-08-13 6:14 ` Chanwoo Choi
2019-08-13 11:27 ` Leonard Crestez
2019-08-14 1:06 ` Chanwoo Choi
2019-08-14 1:17 ` Chanwoo Choi [this message]
2019-08-20 15:26 ` Leonard Crestez
2019-08-21 1:20 ` 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=195bef25-5235-4c24-cc7a-48d368da3bbd@samsung.com \
--to=cw00.choi@samsung.com \
--cc=a.swigon@partner.samsung.com \
--cc=abailon@baylibre.com \
--cc=cpgs@samsung.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-pm@vger.kernel.org \
--cc=myungjoo.ham@samsung.com \
--cc=rjw@rjwysocki.net \
--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).