Generic DT cpufreq driver

[jmcneill]

Summary

This is a driver for the "cpufreq-dt" binding to enable voltage and frequency scaling for cpu nodes that have "operating-points", "clocks", and "cpu-supply" properties.

[manu]

sys/dev/cpufreq/cpufreq_dt.c

234

Shouldn't we set back the regulator voltage to it's original value if we couldn't change the freq ?

240

Same question here for the freq

[jmcneill]

Try to restore previous voltage/CPU freq in error paths of cpufreq_dt_set()

[imp]

Nothing obviously horrible stands out in this code. It reads well. I'm not a CPU frequency expert, though, so I don't know if it would work :)

[andrew]

I don't think this should be a child of the cpu as the clock adjustment may affect multiple CPUs. It will need to keep a CPU_SET of which CPUs it will affect. On a change it will then need to update the pc_clock.

[jmcneill]

I don't think this should be a child of the cpu as the clock adjustment may affect multiple CPUs.

The dt node lives below cpu@0, how else can we attach it? Also there is prior art -- ichss(4) does the same thing.

[manu]

In D7741#161296, @jmcneill wrote:

I don't think this should be a child of the cpu as the clock adjustment may affect multiple CPUs.

The dt node lives below cpu@0, how else can we attach it? Also there is prior art -- ichss(4) does the same thing.

Also from the dt-bindings doc :
"Both required and optional properties listed below must be defined
under node /cpus/cpu@0.|

So there will never be multiple operating-points for multicore SoC, at least for operating-points v1 which this driver only support.
v2 support per operating-points,cpu-supply per core.

[andrew]

In D7741#161297, @manu wrote:

In D7741#161296, @jmcneill wrote:

I don't think this should be a child of the cpu as the clock adjustment may affect multiple CPUs.

The dt node lives below cpu@0, how else can we attach it? Also there is prior art -- ichss(4) does the same thing.

Also from the dt-bindings doc :
"Both required and optional properties listed below must be defined
under node /cpus/cpu@0.|

So there will never be multiple operating-points for multicore SoC, at least for operating-points v1 which this driver only support.
v2 support per operating-points,cpu-supply per core.

In arm_big_little_dt.txt it lists the properties at the start of each cluster. As far as I can tell this document is an extension on the generic cpufreq doc. To handle this we would need an instance per cluster.

In either case the driver would need to know which CPUs it's affecting. The algorithm for finding which CPUs will be affected is to take the current CPU, then search forward through the next CPUs adding them to the current set until operating-points is found or we run out of CPUs.

[jmcneill]

Add support for arm_big_little_dt bindings and update pc_clock for applicable CPUs at attach and when setting a new frequency.