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
