Message-ID: <20221118115415.gr2crvyhs7rcfbir@bogus>
Date:   Fri, 18 Nov 2022 11:54:15 +0000
From:   Sudeep Holla <sudeep.holla@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
        Sudeep Holla <sudeep.holla@....com>, andersson@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, rafael@...nel.org,
        robh+dt@...nel.org, johan@...nel.org, devicetree@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-pm@...r.kernel.org
Subject: Re: [PATCH v7 0/4] qcom-cpufreq-hw: Add CPU clock provider support

On Fri, Nov 18, 2022 at 11:27:30AM +0530, Viresh Kumar wrote:
> On 17-11-22, 12:01, Sudeep Holla wrote:
> > Thanks for the link. Sorry I still don't get the complete picture. Who are
> > the consumers of these clock nodes if not cpufreq itself.
> > 
> > I am going to guess, so other device(like inter-connect) with phandle into
> > CPU device perhaps ? Also I assume it will have phandle to non-CPU device
> > and hence we need generic device clock solution. Sorry for the noise, but
> > I still find having both clocks and qcom,freq-domain property is quite
> > confusing but I am fine as I understand it bit better now.
> 
> Lemme try to explain what the initial problem was, because of which I suggested
> the DT to be fixed, even if no one is going to use it as a client.
> 
> The OPP core provides two features:
> 
> - Parsing of the OPP table and provide the data to the client.
> - Ability to switch the OPPs, i.e. configuring all resources.
> 
> qcom-cpufreq-hw driver uses both of these, but in a tricky way (like Tegra30).
> It used the OPP core to parse the data, along with "opp-hz" property and switch
> the OPPs by calling dev_pm_opp_set_opp(). But it doesn't want
> dev_pm_opp_set_opp() to change the clock rate, but configure everything else.
> 
> Now the OPP core needs to distinguish platforms for valid and invalid
> configurations, to make sure something isn't broken. For example a developer
> wants to change the OPP along with frequency and passes a valid OPP table. But
> forgets to set the clock entry in device's node. This is an error and the OPP
> core needs to report it. There can be more of such issues with different
> configurations.
> 
> Also, as Mani explained, if the OPP core is required to switch the OPPs, then it
> needs to know the initial frequency of the device to see if we are going up or
> down the frequency graph. And so it will do a clk_get_rate() if there is
> "opp-hz" available.
> 
> 
> What we did in case of Tegra30 (commit 1b195626) is provide a .config_clks
> helper, which does nothing. So the OPP core doesn't need to know if frequency is
> programmed or not.
> 
> The same can not be done for Qcom right now as the CPU node doesn't have the clk
> property though it has "opp-hz".
> 
> Weather we have a user in kernel (OS) or not, shouldn't decide how the DT looks
> like. The DT should clearly define what the hardware looks like, irrespective of
> the users. The CPU has a clock and it should be mentioned. If the OPP core
> chooses to use that information, then it is a fine expectation to have.
> 
> And so we are here. Most likely no one will ever do clk_set_rate() on this new
> clock, which is fine, though OPP core will likely do clk_get_rate() here.
> 
> Hope I was able to clarify few things here.
> 

Thanks a ton for such detailed explanation. Ulf was trying to integrate
genpd + performance domains with SCMI. That is the reason for my interest
in this topic. Sorry for all the trouble.

-- 
Regards,
Sudeep

Powered by blists - more mailing lists