On some cpufreq drivers we know the voltage associated with each
operating point but there is no explicit Linux "regulator" present. An
example is "qcom-cpufreq-hw.c". There the voltage is managed
automatically by the hardware but we still associate it with the OPP
table so we can do energy calculations for EAS.
The OPP framework handles this in general. In _opp_allocate() it can
be seen that we always allocate space for one supply even if
"regulator_count" is 0.
Let's handle this properly in debugfs.
NOTE: as a side effect of this a whole bunch of OPPs in the system may
get supply-related files exposed in debugfs that are mostly useless
(they'll just contain 0). I'd expect this to be OK but it's moderately
annoying. It seems better than trying to dynamically create debugfs
directories when the voltages are non-zero or adding extra complexity
in the code giving a hint to the OPP framework that voltages should be
exposed.
After this patch, on a sc7180-trogdor class device I can see voltages
for the CPU OPPs under /sys/kernel/debug/opp.
Fixes: dfbe4678d709 ("PM / OPP: Add infrastructure to manage multiple regulators")
Signed-off-by: Douglas Anderson <[email protected]>
---
drivers/opp/debugfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/opp/debugfs.c b/drivers/opp/debugfs.c
index 96a30a032c5f..65234da41063 100644
--- a/drivers/opp/debugfs.c
+++ b/drivers/opp/debugfs.c
@@ -96,10 +96,11 @@ static void opp_debug_create_supplies(struct dev_pm_opp *opp,
struct opp_table *opp_table,
struct dentry *pdentry)
{
+ int supply_count = max(opp_table->regulator_count, 1);
struct dentry *d;
int i;
- for (i = 0; i < opp_table->regulator_count; i++) {
+ for (i = 0; i < supply_count; i++) {
char name[15];
snprintf(name, sizeof(name), "supply-%d", i);
--
2.37.2.672.g94769d06f0-goog
On Fri, Aug 26, 2022 at 07:56:59AM -0700, Douglas Anderson wrote:
> On some cpufreq drivers we know the voltage associated with each
> operating point but there is no explicit Linux "regulator" present. An
> example is "qcom-cpufreq-hw.c". There the voltage is managed
> automatically by the hardware but we still associate it with the OPP
> table so we can do energy calculations for EAS.
>
> The OPP framework handles this in general. In _opp_allocate() it can
> be seen that we always allocate space for one supply even if
> "regulator_count" is 0.
>
> Let's handle this properly in debugfs.
>
> NOTE: as a side effect of this a whole bunch of OPPs in the system may
> get supply-related files exposed in debugfs that are mostly useless
> (they'll just contain 0). I'd expect this to be OK but it's moderately
> annoying. It seems better than trying to dynamically create debugfs
> directories when the voltages are non-zero or adding extra complexity
> in the code giving a hint to the OPP framework that voltages should be
> exposed.
>
> After this patch, on a sc7180-trogdor class device I can see voltages
> for the CPU OPPs under /sys/kernel/debug/opp.
>
> Fixes: dfbe4678d709 ("PM / OPP: Add infrastructure to manage multiple regulators")
> Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Matthias Kaehlcke <[email protected]>
On 26-08-22, 07:56, Douglas Anderson wrote:
> On some cpufreq drivers we know the voltage associated with each
> operating point but there is no explicit Linux "regulator" present. An
> example is "qcom-cpufreq-hw.c". There the voltage is managed
> automatically by the hardware but we still associate it with the OPP
> table so we can do energy calculations for EAS.
>
> The OPP framework handles this in general. In _opp_allocate() it can
> be seen that we always allocate space for one supply even if
> "regulator_count" is 0.
>
> Let's handle this properly in debugfs.
>
> NOTE: as a side effect of this a whole bunch of OPPs in the system may
> get supply-related files exposed in debugfs that are mostly useless
> (they'll just contain 0). I'd expect this to be OK but it's moderately
> annoying. It seems better than trying to dynamically create debugfs
> directories when the voltages are non-zero or adding extra complexity
> in the code giving a hint to the OPP framework that voltages should be
> exposed.
>
> After this patch, on a sc7180-trogdor class device I can see voltages
> for the CPU OPPs under /sys/kernel/debug/opp.
The OPP core already supports platforms which don't have a regulator
set for the CPU device, but the OPP table have an entry for microvolt.
This already works.
I looked at your DT and I understand why this isn't working for you.
The problem is that your DT doesn't have any of such values
(opp-microvolt) but the driver later calls dev_pm_opp_adjust_voltage()
to set voltage values.
IMO, this is wrong by design. This takes advantage of the fact that
the OPP core doesn't check if voltage has been previously set for the
device or not in dev_pm_opp_adjust_voltage() and it works by chance
currently.
I would suggest adding opp-microvolt property to the DT for this
platform, the values can be 0 with a comment mentioning that software
will fill them later, or if you know approximate values you can fill
them as well.
And then it will work just fine I hope.
--
viresh