On Fri, 13 Dec 2024 at 23:35, Christian Marangi <ansuelsmth@xxxxxxxxx> 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@xxxxxxxxx> 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. 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. Viresh, do you have a better approach in mind? Kind regards Uffe
