On Tue, Nov 08, 2022 at 03:57:17PM +0000, Sudeep Holla wrote: > On Tue, Nov 08, 2022 at 09:10:37PM +0530, Manivannan Sadhasivam wrote: > > Qcom CPUFreq hardware (EPSS/OSM) controls clock and voltage to the CPU > > cores. But this relationship is not represented with the clk framework > > so far. > > > > So, let's make the qcom-cpufreq-hw driver a clock provider. This makes the > > clock producer/consumer relationship cleaner and is also useful for CPU > > related frameworks like OPP to know the frequency at which the CPUs are > > running. > > > > The clock frequency provided by the driver is for each frequency domain. > > We cannot get the frequency of each CPU core because, not all platforms > > support per-core DCVS feature. > > > > Also the frequency supplied by the driver is the actual frequency that > > comes out of the EPSS/OSM block after the DCVS operation. This frequency is > > not same as what the CPUFreq framework has set but it is the one that gets > > supplied to the CPUs after throttling by LMh. > > > > OK now I see more info here. How different is this value from the one > returned by qcom_cpufreq_hw_get() ? > qcom_cpufreq_hw_get() returns the frequency that got programmed by the cpufreq core. But that frequency is not necessarily the one that gets delivered to the CPU cores because the EPSS/OSM hardware block may vary the frequency after the DCVS operation. So this frequency is the final one that gets delivered to the CPU cores. Thanks, Mani > -- > Regards, > Sudeep -- மணிவண்ணன் சதாசிவம்
