Re: [PATCH v7 0/4] qcom-cpufreq-hw: Add CPU clock provider support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Nov 17, 2022 at 05:28:07PM +0530, Manivannan Sadhasivam wrote:
> On Thu, Nov 17, 2022 at 11:52:03AM +0000, Sudeep Holla wrote:
> > On Thu, Nov 17, 2022 at 04:42:07PM +0530, Manivannan Sadhasivam wrote:
> > > On Thu, Nov 17, 2022 at 10:19:03AM +0000, Sudeep Holla wrote:
> > > > 
> > > > Why do you need the above 3 changes if the below(4/4) will ensure
> > > > cpufreq_get(cpu) returns the clock frequency. I was expecting to drop the
> > > > whole "confusing" clock bindings and the unnecessary clock provider.
> > > > 
> > > > Can't we just use cpufreq_get(cpu) ?
> > > > 
> > > 
> > > This can be possible for OPP implementations for the CPUs but not for other
> > > peripherals making use of OPP framework like GPU etc... Moreover this may end
> > > up with different code path for CPUs and other peripherals inside OPP framework.
> > > 
> > 
> > Fair enough, you can use this for non-CPU devices. But you are adding this for
> > CPUs here. Is the consumer unaware that this is a CPU or non-CPU device ?
> > If so, make sense. Otherwise, it is unnecessary to go through the clk
> > framework to get CPU frequency.
> > 
> 
> The consumer here is the OPP framework and yes it doesn't have the knowledge of
> the device it is dealing with (for this context).

Ah OK, I thought it is something else. Does this mean OPP is tied with clk
framework or clock bindings ? Is this for some specific feature ? Or is it
compulsory for all the devices using OPP ? Just wondering how this affects
SCMI which doesn't use or provide clocks yet.

-- 
Regards,
Sudeep



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux