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

[Leonard Crestez <leonard.crestez@nxp.com>]

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.

There aren't really that many devfreq implementations so perhaps it's 
not worth generalizing very much. I should rename this to "devfreq-imx" 
even if there's nothing imx-specific inside it yet.

--
Regards,
Leonard