On 25-10-16, 16:13, Dave Gerlach wrote:
I think what you have shared below is a good safety check but if I rename the regulator properties in the DT for the cpu (to vdd and vbb, meaning cpufreq detects no regulator) and do *not* call dev_pm_opp_set_regulators before cpufreq-dt probes we fail before we even get to that point:
[16.946] cpu cpu0: opp_parse_supplies: Invalid number of elements in opp-microvolt property (6) with supplies (1) [16.967] cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22 [16.982] cpu cpu0: dev_pm_opp_get_opp_count: OPP table not found (-19) [16.982] cpu cpu0: OPP table is not ready, deferring probe
This failure is because opp_parse_supplies assumes a count of 1 regulator if no regulators at all are present and then hard fails if too many voltages have been passed for each OPP.
Exactly. And yes this is intentional.
It seems we need a check much earlier similar to what you suggested below to allow us to defer if an OPP has supplied voltages but no regulator has been registered with the system. I think this is reasonable even for the 1 regulator case, no?
No.
OPP core needs to know about regulators only if the user drivers want it to manage DVFS. It is still possible for cpufreq drivers to use OPP framework for managing the tables, but do the real DVFS stuff themselves. That's why it is not compulsory in the code to set regulator names.
And its only wrong if dev_pm_opp_set_rate() is called without first setting the regulators..
cpufreq-dt won't handle this properly as is, but now that the opp core is evolving perhaps it makes sense to modify the resources_available check slightly to rely on the OPP core rather than just a dummy regulator_get_optional to see if the regulator is ready.
I am not sure yet on what to change there. You mean regarding multiple regulators?