Give the board CPU DVFS, capped at what its fixed rail allows

[MrMati]

The board had no /sys/devices/system/cpu/cpu0/cpufreq at all, and the CPU sat on whatever OPP U-Boot left behind. Three things were wrong, and the first one is the whole reason nothing worked.

CONFIG_ROCKCHIP_OPP was off. rockchip-cpufreq will not register the cpufreq-dt device until rockchip_init_opp_info() succeeds, and without that symbol it is a stub:

static inline int
rockchip_init_opp_info(struct device *dev, struct rockchip_opp_info *info,
		       char *clk_name, char *reg_name)
{
	return -EOPNOTSUPP;
}

That is the -95 the board reported. Nothing in Kconfig selects ROCKCHIP_OPP and rv1106_defconfig does not set it, although Luckfox's own 5.10 defconfig does.

vdd_arm described hardware that is not on this board. It was a pwm-regulator on PWM0, which is Rockchip's reference design; Luckfox fitted a fixed 0.9 V rail instead. It is now a regulator-fixed with min == max, because 6.6's of_get_fixed_voltage_config() rejects a fixed regulator with a voltage range ("Fixed regulator specified with variable voltages") — Luckfox's own 800000..1000000 node would not probe here.

A fixed rail has to be defended in the OPP table. The regulator core will not do it: regulator_set_voltage_triplet() falls back to the OPP's u_volt_min, which is 850 mV for every entry in rv1106.dtsi including the 1.608 GHz one, and a fixed 0.9 V regulator satisfies that request. So the part would have run its top bin undervolted. 1.2 GHz is the fastest OPP actually specified at 850 mV, so the table stops there, and the PVTPLL properties go with it since calibration exists to search for a voltage this board cannot change:

&cpu0_opp_table {
	/delete-property/ rockchip,pvtpll-avg-offset;
	/delete-property/ rockchip,pvtpll-min-rate;
	/delete-property/ rockchip,pvtpll-volt-step;

	/delete-node/ opp-1296000000;
	/delete-node/ opp-1416000000;
	/delete-node/ opp-1512000000;
	/delete-node/ opp-1608000000;
};

Lastly, rv1106.dtsi describes trip points but binds no cooling device to them, so the passive trips did nothing and the only thermal response was the critical trip at 115 C. cpu0 gets #cooling-cells = <2> and a cooling-maps entry on the 85 C trip, which step_wise (already this tree's default governor) drives.

Verified by building the kernel and decompiling the DTB: the OPP table ends at opp-1200000000 with no pvtpll properties, vdd_arm is fixed at 900000, cpu@0 carries #cooling-cells, and the cooling map points at it from trip-point-1. make check passes. Untested on hardware.

---

^{Need help on this PR? Tag @codesmith with what you need. Autofix is enabled.}