Re: [PATCH v7 2/2] cpufreq: airoha: Add EN7581 CPUFreq SMCCC driver

[Christian Marangi <ansuelsmth@gmail.com>]

On Thu, Dec 19, 2024 at 04:23:52PM +0100, Ulf Hansson wrote:
> On Fri, 13 Dec 2024 at 23:35, Christian Marangi <ansuelsmth@gmail.com> wrote:
> >
> > On Fri, Dec 13, 2024 at 09:30:01AM +0530, Viresh Kumar wrote:
> > > On 12-12-24, 13:01, Ulf Hansson wrote:
> > > > On Fri, 6 Dec 2024 at 22:16, Christian Marangi <ansuelsmth@gmail.com> wrote:
> > > > Hmm, it looks like this needs to be moved and possibly split up.
> > > >
> > > > The provider part (for the clock and power-domain) belongs in
> > > > /drivers/pmdomain/*, along with the other power-domain providers.
> > > >
> > > > Other than that, I was really expecting the cpufreq-dt to take care of the rest.
> > > >
> > > > To me, the above code belongs in a power-domain provider driver. While
> > > > the below should be taken care of in cpufreq-dt, except for the device
> > > > registration of the cpufreq-dt device, I guess.
> > > >
> > > > Viresh, what's your view on this?
> > >
> > > Sure, no issues.. These are all cpufreq related, but don't necessarily belong in
> > > the cpufreq directory.
> > >
> >
> > Problem is really DT schema... I wonder if it's acceptable to push a
> > name-only driver in pmdomain just do detach from cpufreq. The cpufreq
> > driver would manually probe the pmdomain. Is it acceptable?
> >
> > Or do you have alternative solution for this?
> 
> The power-domain provider driver should use the compatible
> "airoha,en7581-cpufreq". This driver should be responsible for
> registering the genpd and the clock.

Is it ok to have clk provider in power-domain driver?

> 
> Potentially, the power-domain provider driver could also register the
> "cpufreq-dt" platform-device. To make this work, we also need to
> extend the cpufreq-dt driver (maybe extend its platform-data too?) to
> be capable of attaching the corresponding cpu-devices to their
> power(perf)-domains. For the moment, this isn't supported, but I think
> it would be nice if it could. Another option, would be to use an
> additional separate name-based cpufreq-driver, as in the
> qcom-cpufreq-nvmem.c, that then becomes responsible for registering
> the cpufreq-dt device.

Well a simple init/exit driver should be ok, we still need to have the
custom function for opp so a specific driver in cpufreq is needed
anyway.

> 
> Viresh, do you have a better approach in mind?
>

If both are ok with this approach I will:
- move pm domain and clock to pmdomain driver directory
- rework the cpufreq driver to an init/exit implementation (no
  compatible) and just register cpufreq-dt with the custom opp
  OPs.

This should work and make everything well organized.

-- 
	Ansuel