RE: [PATCH v3 09/10] DT: QCOM: Add cpufreq-dt to msm8996

[<ilialin@codeaurora.org>]

Understood, what you mean. I assumed that the cpufreq-dt is generic driver, and adding architecture specific code to it is no not correct from architectural point of view. Anyway, I'm considering adding a platform specific cpufreq driver, which will handle the efuse data as well.

Meanwhile this is the way to use the generic driver.

> -----Original Message-----
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: Tuesday, March 20, 2018 22:06
> To: ilialin@codeaurora.org; linux-arm-kernel@lists.infradead.org; linux-arm-
> msm@vger.kernel.org; linux-clk@vger.kernel.org; sboyd@codeaurora.org
> Cc: mark.rutland@arm.com; devicetree@vger.kernel.org;
> rnayak@codeaurora.org; robh@kernel.org; will.deacon@arm.com;
> amit.kucheria@linaro.org; tfinkel@codeaurora.org;
> nicolas.dechesne@linaro.org; celster@codeaurora.org
> Subject: RE: [PATCH v3 09/10] DT: QCOM: Add cpufreq-dt to msm8996
> 
> Quoting ilialin@codeaurora.org (2018-03-20 06:46:19)
> > > From: Stephen Boyd <sboyd@kernel.org> Quoting Ilia Lin (2018-02-14
> > > 05:59:51)
> > > > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
> > > > b/drivers/cpufreq/cpufreq-dt-platdev.c
> > > > index 3b585e4..b6cd0ae 100644
> > > > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> > > > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> > > > @@ -95,6 +95,9 @@
> > > >         { .compatible = "xlnx,zynq-7000", },
> > > >         { .compatible = "xlnx,zynqmp", },
> > > >
> > > > +       { .compatible = "qcom,msm8996", },
> > > > +       { .compatible = "qcom,apq8096", },
> > > > +
> > >
> > > Why can't we base it on the kryocc node being present?
> > This could be good idea, if I would writing a platform specific cpufreq driver,
> which may be a future option.
> 
> Well maybe cpufreq-dt can also look at the cpus nodes for a cpu with a
> certain type (in this case kryo). Then we can add cpufreq dt based on that
> CPU node being there.
> 
> > > Or even populate
> > > the cpufreq-dt from the kryocc driver?
> > There is a problem that during the clock probe the OPP table still doesn't
> exist.
> 
> The OPP table is in DT? Why doesn't it exist?