[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f33334e7-bd28-af82-b557-681a2b4132da@gmail.com>
Date: Fri, 22 Jan 2021 18:28:16 +0300
From: Dmitry Osipenko <digetx@...il.com>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: MyungJoo Ham <myungjoo.ham@...sung.com>,
Kyungmin Park <kyungmin.park@...sung.com>,
Chanwoo Choi <cw00.choi@...sung.com>,
Thierry Reding <thierry.reding@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
linux-pm@...r.kernel.org,
Vincent Guittot <vincent.guittot@...aro.org>,
Rafael Wysocki <rjw@...ysocki.net>,
Stephen Boyd <sboyd@...nel.org>, Nishanth Menon <nm@...com>,
Sibi Sankar <sibis@...eaurora.org>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-tegra@...r.kernel.org
Subject: Re: [PATCH 11/13] devfreq: tegra30: Migrate to dev_pm_opp_set_opp()
22.01.2021 09:26, Viresh Kumar пишет:
> On 22-01-21, 00:36, Dmitry Osipenko wrote:
>> 21.01.2021 14:17, Viresh Kumar пишет:
>>> dev_pm_opp_set_bw() is getting removed and dev_pm_opp_set_opp() should
>>> be used instead. Migrate to the new API.
>>>
>>> Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
>>> ---
>>> drivers/devfreq/tegra30-devfreq.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/devfreq/tegra30-devfreq.c b/drivers/devfreq/tegra30-devfreq.c
>>> index 117cad7968ab..d2477d7d1f66 100644
>>> --- a/drivers/devfreq/tegra30-devfreq.c
>>> +++ b/drivers/devfreq/tegra30-devfreq.c
>>> @@ -647,7 +647,7 @@ static int tegra_devfreq_target(struct device *dev, unsigned long *freq,
>>> return PTR_ERR(opp);
>>> }
>>>
>>> - ret = dev_pm_opp_set_bw(dev, opp);
>>> + ret = dev_pm_opp_set_opp(dev, opp);
>>> dev_pm_opp_put(opp);
>>>
>>> return ret;
>>>
>>
>> This patch introduces a very serious change that needs to be fixed.
>>
>> Now dev_pm_opp_set_opp() changes both clock rate and bandwidth, this is
>> unacceptable for this driver because it shall not touch the clock rate.
>>
>> I think dev_pm_opp_set_bw() can't be removed.
>
> I am wondering here on what would be a better solution, do what you
> said or introduce another helper like dev_pm_opp_clear_clk(), which
> will make sure the OPP core doesn't play with device's clk.
>
Either way will work, but maybe keeping the dev_pm_opp_set_bw() is a bit
more straightforward variant for now since it will avoid the code's
changes and it's probably a bit more obvious variant for the OPP users.
Powered by blists - more mailing lists