Page MenuHomeFreeBSD

Generic DT cpufreq driver
ClosedPublic

Authored by jmcneill on Sep 1 2016, 10:49 AM.

Details

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.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

jmcneill updated this revision to Diff 19924.Sep 1 2016, 10:49 AM
jmcneill retitled this revision from to Generic DT cpufreq driver.
jmcneill updated this object.
jmcneill edited the test plan for this revision. (Show Details)
jmcneill added a reviewer: ARM.
jmcneill set the repository for this revision to rS FreeBSD src repository.
jmcneill added projects: ARM, arm64.
manu added a subscriber: manu.Sep 3 2016, 1:05 PM
manu added inline comments.
sys/dev/cpufreq/cpufreq_dt.c
234 ↗(On Diff #19924)

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

240 ↗(On Diff #19924)

Same question here for the freq

jmcneill updated this revision to Diff 20022.Sep 3 2016, 3:43 PM

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

jmcneill marked 2 inline comments as done.Sep 3 2016, 3:43 PM
imp accepted this revision.Sep 3 2016, 4:23 PM
imp added a reviewer: 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 :)

This revision is now accepted and ready to land.Sep 3 2016, 4:23 PM
andrew added a subscriber: andrew.Sep 3 2016, 4:52 PM

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.

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 added a comment.Sep 3 2016, 5:36 PM

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 added a comment.Sep 3 2016, 6:00 PM
In D7741#161297, @manu 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 updated this revision to Diff 20023.Sep 3 2016, 6:48 PM
jmcneill edited edge metadata.

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

This revision now requires review to proceed.Sep 3 2016, 6:48 PM
andrew accepted this revision.Sep 6 2016, 12:34 PM
andrew edited edge metadata.
This revision is now accepted and ready to land.Sep 6 2016, 12:34 PM
This revision was automatically updated to reflect the committed changes.