Re: [RFC] devfreq: Add generic devfreq-dt driver

[Stephen Boyd <sboyd@kernel.org>]

Quoting Leonard Crestez (2019-06-10 15:13:19)
> On 6/6/2019 6:15 AM, Viresh Kumar wrote:
> > On 05-06-19, 15:31, Leonard Crestez wrote:
> >> +static const struct of_device_id devfreq_dt_of_match[] = {
> >> +    { .compatible = "generic-devfreq", },
> >> +    { /* sentinel */ },
> >> +};
> >> +MODULE_DEVICE_TABLE(of, devfreq_dt_of_match);
> > 
> > DT can't contain nodes for any virtual devices, this will have similar
> > problems to cpufreq-dt. How is this driver going to get probed ? Who
> > will create the device ?
> 
> CPUs are special devices, I'm not sure the same issues apply here.
> 
> If a SOC has multiple buses or frequency domains which can be scaled up 
> and down then those can be treated as "real" devices and probing them 
> from DT seems entirely reasonable. DT could look like this:
> 
> +       noc1 {
> +               compatible = "fsl,imx8mm-noc", "generic-devfreq";
> +               clocks = <&clk IMX8MM_CLK_NOC1>;
> +               operating-points-v2 = <&noc1_opp_table>;
> +       };
> +
> +       noc1_opp_table: noc1-opp-table {
> +               compatible = "operating-points-v2";
> +
> +               opp-150M {
> +                       opp-hz = /bits/ 64 <150000000>;
> +               };
> +               opp-750M {
> +                       opp-hz = /bits/ 64 <750000000>;
> +               };
> +       };
> 
> Instead of a "generic-devfreq" fallback the compatible list of 
> devfreq-dt could contain a large number of unrelated compat strings. 
> This would be vaguely similar to the white/black lists from cpufreq-dt-plat.

This still looks very much "virtual" because the NoC node doesn't have a
'reg' property. Is there anything the driver will do besides change the
frequency of the clk based on the OPP table? If not, then it still looks
like this is a node for the sake of making devfreq happy to probe via
DT.