From: Chanwoo Choi <cw00.choi@samsung.com>
To: "Leonard Crestez" <leonard.crestez@nxp.com>,
"Artur Świgoń" <a.swigon@partner.samsung.com>,
"georgi.djakov@linaro.org" <georgi.djakov@linaro.org>,
"Viresh Kumar" <viresh.kumar@linaro.org>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-samsung-soc@vger.kernel.org"
<linux-samsung-soc@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"krzk@kernel.org" <krzk@kernel.org>,
"myungjoo.ham@samsung.com" <myungjoo.ham@samsung.com>,
"inki.dae@samsung.com" <inki.dae@samsung.com>,
"sw0312.kim@samsung.com" <sw0312.kim@samsung.com>,
"m.szyprowski@samsung.com" <m.szyprowski@samsung.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Saravana Kannan <saravanak@google.com>,
Lukasz Luba <l.luba@partner.samsung.com>,
"cpgs (cpgs@samsung.com)" <cpgs@samsung.com>
Subject: Re: [RFC PATCH 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus
Date: Tue, 20 Aug 2019 08:44:05 +0900 [thread overview]
Message-ID: <08bd637a-2038-9f64-a189-682427ce5bfb@samsung.com> (raw)
In-Reply-To: <VI1PR04MB7023B5095F706635354C4C50EED70@VI1PR04MB7023.eurprd04.prod.outlook.com>
Hi Artur and Leonard,
On 19. 8. 9. 오전 12:00, Leonard Crestez wrote:
> On 29.07.2019 04:49, Chanwoo Choi wrote:
>> On 19. 7. 23. 오후 9:20, Artur Świgoń wrote:
>>> This patch adds interconnect functionality to the exynos-bus devfreq
>>> driver.
>>>
>>> The devfreq target() callback provided by exynos-bus now selects either the
>>> frequency calculated by the devfreq governor or the frequency requested via
>>> the interconnect API for the given node, whichever is higher.
>>
>> Basically, I agree to support the QoS requirement between devices.
>> But, I think that need to consider the multiple cases.
>>
>> 1. When changing the devfreq governor by user,
>> For example of the connection between bus_dmc/leftbus/display on patch8,
>> there are possible multiple cases with various devfreq governor
>> which is changed on the runtime by user through sysfs interface.
>>
>> If users changes the devfreq governor as following:
>> Before,
>> - bus_dmc (simple_ondemand, available frequency 100/200/300/400 MHz)
>> --> bus_leftbus(simple_ondemand, available frequency 100/200/300/400 MHz)
>> ----> bus_display(passive)
>>
>> After changed governor of bus_dmc,
>> if the min_freq by interconnect requirement is 400Mhz,
>> - bus_dmc (powersave) : min_freq and max_freq and cur_freq is 100MHz
>> --> bus_leftbus(simple_ondemand) : cur_freq is 400Mhz
>> ----> bus_display(passive)
>>
>> The final frequency is 400MHz of bus_dmc
>> even if the min_freq/max_freq/cur_freq is 100MHz.
>> It cannot show the correct min_freq/max_freq through
>> devfreq sysfs interface.
>>
>>
>> 2. When disabling the some frequency by devfreq-thermal throttling,
>> This patch checks the min_freq of interconnect requirement
>> in the exynos_bus_target() and exynos_bus_passive_target().
>> Also, it cannot show the correct min_freq/max_freq through
>> devfreq sysfs interface.
>>
>> For example of bus_dmc bus,
>> - The available frequencies are 100MHz, 200MHz, 300MHz, 400MHz
>> - Disable 400MHz by devfreq-thermal throttling
>> - min_freq is 100MHz
>> - max_freq is 300MHz
>> - min_freq of interconnect is 400MHz
>>
>> In result, the final frequency is 400MHz by exynos_bus_target()
>> There are no problem for working. But, the user cannot know
>> reason why cur_freq is 400MHz even if max_freq is 300MHz.
>>
>> Basically, update_devfreq() considers the all constraints
>> of min_freq/max_freq to decide the proper target frequency.
>
> I think that applying the interconnect min_freq via dev_pm_qos can help
> with many of these concerns: update_devfreq controls all the min/max
> handling, sysfs is accurate and better decisions can be made regarding
> thermal. Enforcing constraints in the core is definitely better.
>
> This wouldn't even be a very big change, you don't need to actually move
> the interconnect code outside of devfreq. Just make every devfreq/icc
> node register a dev_pm_qos_request for itself during registration and
> call dev_pm_qos_update_request inside exynos_bus_icc_set.
>
> See: https://patchwork.kernel.org/patch/11084279/
I agree this approach of Leonard. If we use the dev_pm_qos[1] feature,
it resolve the issue of my comment1/2.
In summary, when receive the minimum frequency requirement
from interconnect path, the each bus uses the dev_pm_qos interface
in order to inform the minimum frequency from interconnect to devfreq.
And then the devfreq core will execute the update_devfreq()
with all frequency requirements as following:
- the user input (min/max frequency though devfreq sysfs
- the target frequency provided by devfreq governor
- the minimum frequency from interconnect path
--
Best Regards,
Chanwoo Choi
Samsung Electronics
next prev parent reply other threads:[~2019-08-19 23:40 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20190723122022eucas1p2f568f74f981f9de9012eb693c3b446d5@eucas1p2.samsung.com>
2019-07-23 12:20 ` [RFC PATCH 00/11] Simple QoS for exynos-bus driver using interconnect Artur Świgoń
[not found] ` <CGME20190723122022eucas1p1266d90873d564894bd852c20140f8474@eucas1p1.samsung.com>
2019-07-23 12:20 ` [RFC PATCH 01/11] devfreq: exynos-bus: Extract exynos_bus_profile_init() Artur Świgoń
2019-07-24 19:07 ` Krzysztof Kozlowski
2019-07-31 13:00 ` Artur Świgoń
2019-08-05 9:56 ` Krzysztof Kozlowski
2019-07-25 12:43 ` Chanwoo Choi
2019-07-26 10:42 ` Krzysztof Kozlowski
2019-07-26 10:52 ` Chanwoo Choi
[not found] ` <CGME20190723122023eucas1p2ff56c00b60a676ed85d9fe159a1839f2@eucas1p2.samsung.com>
2019-07-23 12:20 ` [RFC PATCH 02/11] devfreq: exynos-bus: Extract exynos_bus_profile_init_passive() Artur Świgoń
2019-07-24 19:08 ` Krzysztof Kozlowski
2019-07-25 12:45 ` Chanwoo Choi
[not found] ` <CGME20190723122024eucas1p1ff060d072132bfbc8a8a1d10fa1f90f8@eucas1p1.samsung.com>
2019-07-23 12:20 ` [RFC PATCH 03/11] devfreq: exynos-bus: Change goto-based logic to if-else logic Artur Świgoń
2019-07-24 19:10 ` Krzysztof Kozlowski
2019-07-25 12:56 ` Chanwoo Choi
2019-07-25 13:02 ` Chanwoo Choi
[not found] ` <CGME20190723122024eucas1p25a480ccddaa69ee1d0f1a07960ca3f22@eucas1p2.samsung.com>
2019-07-23 12:20 ` [RFC PATCH 04/11] devfreq: exynos-bus: Clean up code Artur Świgoń
2019-07-24 19:14 ` Krzysztof Kozlowski
2019-07-25 12:50 ` Chanwoo Choi
2019-07-26 10:45 ` Krzysztof Kozlowski
2019-07-26 11:04 ` Chanwoo Choi
[not found] ` <CGME20190723122025eucas1p251df372451e0b27ad7f2e3c89df60b64@eucas1p2.samsung.com>
2019-07-23 12:20 ` [RFC PATCH 05/11] icc: Export of_icc_get_from_provider() Artur Świgoń
2019-07-24 19:15 ` Krzysztof Kozlowski
[not found] ` <CGME20190723122026eucas1p2acf705de2a47ba54f383d916f5383144@eucas1p2.samsung.com>
2019-07-23 12:20 ` [RFC PATCH 06/11] icc: Relax requirement in of_icc_get_from_provider() Artur Świgoń
2019-07-24 19:16 ` Krzysztof Kozlowski
[not found] ` <CGME20190723122027eucas1p124f44370a63b16dcb765585761d661a3@eucas1p1.samsung.com>
2019-07-23 12:20 ` [RFC PATCH 07/11] icc: Relax condition in apply_constraints() Artur Świgoń
[not found] ` <CGME20190723122027eucas1p24b1d76e3139f7cc52614d7613ff9ba98@eucas1p2.samsung.com>
2019-07-23 12:20 ` [RFC PATCH 08/11] arm: dts: exynos: Add parents and #interconnect-cells to Exynos4412 Artur Świgoń
2019-07-24 19:24 ` Krzysztof Kozlowski
2019-07-31 13:00 ` Artur Świgoń
2019-07-25 13:13 ` Chanwoo Choi
2019-07-26 12:02 ` Marek Szyprowski
2019-07-29 1:20 ` Chanwoo Choi
[not found] ` <CGME20190723122028eucas1p2eb75f35b810e71d6c590370aaff0997b@eucas1p2.samsung.com>
2019-07-23 12:20 ` [RFC PATCH 09/11] devfreq: exynos-bus: Add interconnect functionality to exynos-bus Artur Świgoń
2019-07-24 18:36 ` Krzysztof Kozlowski
2019-07-31 13:01 ` Artur Świgoń
2019-07-26 8:05 ` Georgi Djakov
2019-08-01 7:59 ` Artur Świgoń
2019-08-07 14:21 ` Georgi Djakov
2019-08-08 13:28 ` Artur Świgoń
2019-07-29 1:52 ` Chanwoo Choi
2019-08-08 13:18 ` Artur Świgoń
2019-08-09 2:17 ` Chanwoo Choi
2019-08-08 15:00 ` Leonard Crestez
2019-08-19 23:44 ` Chanwoo Choi [this message]
2019-08-06 13:41 ` Leonard Crestez
2019-08-08 13:19 ` Artur Świgoń
[not found] ` <CGME20190723122029eucas1p21e1a51e759f9b605d2c89daf659af7bb@eucas1p2.samsung.com>
2019-07-23 12:20 ` [RFC PATCH 10/11] arm: dts: exynos: Add interconnects to Exynos4412 mixer Artur Świgoń
[not found] ` <CGME20190723122029eucas1p2915f536d9ef43a7bd043a878a553439f@eucas1p2.samsung.com>
2019-07-23 12:20 ` [RFC PATCH 11/11] drm: exynos: mixer: Add interconnect support Artur Świgoń
2019-07-24 18:52 ` Krzysztof Kozlowski
2019-07-24 18:53 ` [RFC PATCH 00/11] Simple QoS for exynos-bus driver using interconnect Krzysztof Kozlowski
2019-08-13 6:17 ` Chanwoo Choi
2019-08-13 6:19 ` 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=08bd637a-2038-9f64-a189-682427ce5bfb@samsung.com \
--to=cw00.choi@samsung.com \
--cc=a.swigon@partner.samsung.com \
--cc=cpgs@samsung.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=georgi.djakov@linaro.org \
--cc=inki.dae@samsung.com \
--cc=krzk@kernel.org \
--cc=l.luba@partner.samsung.com \
--cc=leonard.crestez@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=myungjoo.ham@samsung.com \
--cc=rafael@kernel.org \
--cc=saravanak@google.com \
--cc=sw0312.kim@samsung.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).