On 07-02-18, 11:04, Daniel Lezcano wrote:
> Yeah, this is a bit fuzzy. There are still cooling-{min|max}-*state*
> definitions in the DTs
>
> Documentation/devicetree/bindings/hwmon/pwm-fan.txt:
> cooling-min-state = <0>;
> arch/arm/boot/dts/exynos4412-odroidu3.dts:
> cooling-min-state = <0>;
> arch/arm/boot/dts/exynos5410-odroidxu.dts:
> cooling-min-state = <0>;
> arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi:
> cooling-min-state = <0>;
> arch/arm64/boot/dts/rockchip/rk3399-puma.dtsi:
> cooling-min-state = <0>;
>
>
> IIUC, the cooling-device in the mapping defines the min and max states
> which are the values used in the thermal zone binding.
>
> And the cooling-[min|max]-level are the hardware limits:
>
> cooling-min-level <= cooling-device min|max state <= cooling-max-level
>
> For example on the hikey6220:
>
> The DT specifies for CPU0:
>
> operating-points-v2 = <&cpu_opp_table>;
> cooling-min-level = <4>;
> cooling-max-level = <0>;
> #cooling-cells = <2>; /* min followed by max */
>
> and for the cooling device for map0
>
> cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
>
> So if my understanding is correct, the optional property
> cooling-[min|max]-level is used to make sure the cooling device min
> state and max state are in the hardware boundaries. And the thermal
> framework misses to do the consistency check at init.
>
> I'm not sure how useful are cooling-{min|max}-*state* bindings.
Okay, but we aren't validating it this way in code. Isn't it ?
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
