I am running some tests on the 4.17 kernel, and notices the operating
frequency does not change the operating voltage.
The omap36xx.dtsi defines the operating points as follows:
cpus {
/* OMAP3630/OMAP37xx 'standard device' variants OPP50 to OPP130 */
cpu: cpu@0 {
operating-points = <
/* kHz uV */
300000 1012500
600000 1200000
800000 1325000
>;
clock-latency = <300000>; /* From legacy driver */
};
};
Because of this, I would expect the system to increase/decrease the
voltage when going between operating frequncies of 300MHz, 600MHz, and
800 MHz when we assign a proper regulator to the cpu.
In the device tree for the logicpd-torpedo SOM, we set the cpu0 supply to
cpus {
cpu@0 {
cpu0-supply = <&vcc>;
};
};
vcc is defined in twl4030.dtsi to be
vcc: regulator-vdd1 {
compatible = "ti,twl4030-vdd1";
regulator-min-microvolt = <600000>;
regulator-max-microvolt = <1450000>;
};
Based on the above info, I am reading
/sys/devices/platform/68000000.ocp/48070000.i2c/i2c-0/0-0048/48070000.i2c:twl@48:regulator-vdd1/regulator/regulator.11/microvolts
to read the operating voltage of vcc/vdd1 which I would expect to
change based on the the processor operating frequency.
When I set the scaling governor to userspace and then manually set the
frequencies to 300, 600 and 800 MHz, I would expect the voltages to
move between 1012500, 1200000, and 1325000 respectively.
Unfortunately, the regulator always returns a value of 1200000 microvolts.
I am going to go back and bisect, but before I spend the time, I
thought I'd ask if others have seen this or have any ideas on what I
might be doing wrong.
Thanks,
adam
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
