[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210616070948.2oaxc54p5uxknw36@vireshk-i7>
Date: Wed, 16 Jun 2021 12:39:48 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Hsin-Yi Wang <hsinyi@...omium.org>
Cc: "Viresh Kumar )" <vireshk@...nel.org>,
Chanwoo Choi <cw00.choi@...sung.com>,
Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>,
Linux PM <linux-pm@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
"andrew-sh . cheng" <andrew-sh.cheng@...iatek.com>
Subject: Re: [PATCH] opp: of: Allow lazy-linking of required-opps to non genpd
On 16-06-21, 14:25, Hsin-Yi Wang wrote:
> When cpufreq changes, the (cpufreq based) passive governor will
> calculate a target devfreq based on that, and the device governor
> (mt8183-cci-devfreq) will change the actual opp of the device.
>
> The required-opp is set in the cpufreq table:
>
> cpufreq_opp_table: opp_table0 {
> compatible = "operating-points-v2";
> opp-shared;
> ...
> opp0_01 {
> opp-hz = /bits/ 64 <910000000>;
> opp-microvolt = <687500>;
> required-opps = <&opp2_01>;
> };
> ...
> };
>
> devfreq_opp_table: opp_table2 {
> compatible = "operating-points-v2";
> opp-shared;
> ...
> opp2_01: opp-338000000 {
> opp-hz = /bits/ 64 <338000000>;
> opp-microvolt = <687500>;
> };
> ...
> };
Ah, you aren't using dev_pm_opp_set_opp() or dev_pm_opp_set_rate()
interfaces.
Looks okay then.
--
viresh
Powered by blists - more mailing lists