Re: [PATCH 2/2] OPP: Disallow "opp-hz" property without a corresponding clk

From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Johan Hovold <johan@kernel.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>,
	Viresh Kumar <vireshk@kernel.org>, Nishanth Menon <nm@ti.com>,
	Stephen Boyd <sboyd@kernel.org>,
	linux-pm@vger.kernel.org,
	Vincent Guittot <vincent.guittot@linaro.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	andersson@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] OPP: Disallow "opp-hz" property without a corresponding clk
Date: Mon, 21 Nov 2022 13:09:46 +0530	[thread overview]
Message-ID: <20221121073946.GE11945@thinkpad> (raw)
In-Reply-To: <Y3snGQet8yc7HnJK@hovoldconsulting.com>

On Mon, Nov 21, 2022 at 08:22:01AM +0100, Johan Hovold wrote:
> On Mon, Nov 21, 2022 at 12:27:48PM +0530, Viresh Kumar wrote:
> > This removes the special code added by the commit 2083da24eb56 ("OPP:
> > Allow multiple clocks for a device"), to make it work for Qcom SoC.
> > 
> > In qcom-cpufreq-hw driver, we want to skip clk configuration that
> > happens via dev_pm_opp_set_opp(), but still want the OPP core to parse
> > the "opp-hz" property so we can use the freq based OPP helpers.
> > 
> > The DT for Qcom SoCs is fixed now and contain a valid clk entry, and we
> > no longer need the special handling of the same in the OPP core.
> 
> Didn't this affect also sc8280xp? Perhaps you can hold off with applying
> this one for a bit until the needed devicetree changes are in linux-next
> for all the affected platforms.
> 
> (It looks like Mani's series only updated sm8450 and I guess Bjorn
> hasn't picked up that one up yet either.)
> 

That's right. I have proposed to do the similar change to other SoCs as well
once the series was completely merged. I thought of doing so for 6.3.

Btw, there seems to be one more candidate:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/qcom/sm8250.dtsi#n2537

Looks like newer SoCs that has the GMU within the GPU block doesn't have clock
property. This is because, GMU is the one supplying clocks to the GPU unlike the
old SoCs where the clocks used to come from GCC itself.

But we do have a GMU devicetree node, so it should be a matter of adding the
clock provider support as done for cpufreq and represent it in devicetree.

I'll ping Rob Clark and see how to get it done.

Thanks,
Mani

> Johan

-- 
மணிவண்ணன் சதாசிவம்