[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <88b0c110-78fb-cbb0-dd2b-5c4ffb5bc930@marek.ca>
Date: Wed, 17 Feb 2021 08:29:43 -0500
From: Jonathan Marek <jonathan@...ek.ca>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: linux-arm-msm@...r.kernel.org, Viresh Kumar <vireshk@...nel.org>,
Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>,
"open list:OPERATING PERFORMANCE POINTS (OPP)"
<linux-pm@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] opp: fix dev_pm_opp_set_rate for different frequency at
the same opp level
On 2/16/21 11:53 PM, Viresh Kumar wrote:
> On 16-02-21, 15:10, Jonathan Marek wrote:
>> There is not "nothing to do" when the opp is the same. The frequency can
>> be different from opp->rate.
>
> I am sorry but I am not sure what are you trying to fix here and what exactly is
> broken here. Can you provide a usecase for your platform where this doesn't work
> like it used to ?
>
The specific case is this opp table:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/sm8250.dtsi#n439
It does not define every possible clock frequency, it only defines the
rates at which a higher rpmhpd level must be used. Which is the intended
use of opp.
Your change broke this completely: the clock rate change can be silently
ignored because the opp level is the same. In particular it breaks
bluetooth for this platform.
>> Fixes: 81c4d8a3c414 ("opp: Keep track of currently programmed OPP")
>> Signed-off-by: Jonathan Marek <jonathan@...ek.ca>
>> ---
>> drivers/opp/core.c | 7 +++++--
>> drivers/opp/opp.h | 1 +
>> 2 files changed, 6 insertions(+), 2 deletions(-)
>
Powered by blists - more mailing lists