Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 29 Aug 2022 22:24:56 -0500
From:   Bjorn Andersson <andersson@kernel.org>
To:     Viresh Kumar <viresh.kumar@linaro.org>
Cc:     Manivannan Sadhasivam <mani@kernel.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Andy Gross <agross@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Johan Hovold <johan@kernel.org>, devicetree@vger.kernel.org,
        linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-pm@vger.kernel.org
Subject: Re: [RFC PATCH 0/4] cpufreq: qcom-hw: Move clocks to CPU node
Message-ID: <20220830032456.z4olnogsyg32vhiz@builder.lan>
References: <cover.1657695140.git.viresh.kumar@linaro.org>
 <20220715160933.GD12197@workstation>
 <20220718015742.uwskqo55qd67jx2w@vireshk-i7>
 <20220801023756.76jswkbwivuntqof@vireshk-i7>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220801023756.76jswkbwivuntqof@vireshk-i7>
Precedence: bulk

On Mon, Aug 01, 2022 at 08:07:56AM +0530, Viresh Kumar wrote:
> On 18-07-22, 07:27, Viresh Kumar wrote:
> > The OPP tables, which are part of the CPU nodes, mentions clock rates.
> > Are these values for the cxo/gpll clocks or the clock that reaches the
> > CPUs? I believe the latter. The DT is not really complete if the CPU
> > node mentions the frequency, but not the source clock. It works for
> > you because you don't want to do clk_set_rate() in this case, but then
> > it leaves other frameworks, like OPP, confused and rightly so.
> > 
> > Normally, there is always a difference in what the OPP table contains
> > as frequency value and what the hardware programs, mostly it is small
> > though. It shouldn't prevent us from having the hierarchy clearly
> > defined in the DT.
> > 
> > Based on your description, I think it would be better to make
> > cpufreq-hw a clock provider and CPUs the consumer of it. It would then
> > allow the OPP core to not carry the hack to make it all work.
> 
> Bjorn / Mani,
> 
> Can we please get this sorted out ? I don't want to carry an unnecessary hack in
> the OPP core for this.
> 

Conceptually, it sounds like a good idea to express the clock feeding
the CPU clusters, which is controlled by the OSM/EPSS.  But do you
expect the OPP framework to actually do something with the clock, or
just to ensure that the relationship is properly described?


FWIW, the possible discrepancy between the requested frequency and the
actual frequency comes from the fact that OSM/EPSS throttles the cluster
frequency based on a number of different factors (thermal, voltages
...).
This is reported back to the kernel using the thermal pressure
interface. It would be quite interesting to see some investigation in
how efficient the kernel is at making use of this feedback.

Regards,
Bjorn