On Tue, Mar 6, 2018 at 1:38 AM, Rob Herring <robh+dt@xxxxxxxxxx> wrote: > On Mon, Mar 5, 2018 at 12:36 PM, Amit Kucheria <amit.kucheria@xxxxxxxxxx> wrote: >> From: Ram Chandrasekar <rkumbako@xxxxxxxxxxxxxx> >> >> There is currently no way for the governor to be selected for each thermal >> zone in devicetree. This results in the default governor being used for all >> thermal zones even though no such restriction exists in the core code. >> >> Add support for specifying the thermal governor to be used for a thermal >> zone in the devicetree. The devicetree config should specify the governor >> name as a string that matches any available governors. If not specified, we >> maintain the current behaviour of using the default governor. >> >> Signed-off-by: Ram Chandrasekar <rkumbako@xxxxxxxxxxxxxx> >> Signed-off-by: Amit Kucheria <amit.kucheria@xxxxxxxxxx> >> --- >> Documentation/devicetree/bindings/thermal/thermal.txt | 8 ++++++++ >> drivers/thermal/of-thermal.c | 6 ++++++ >> 2 files changed, 14 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt >> index 1719d47..fced9d3 100644 >> --- a/Documentation/devicetree/bindings/thermal/thermal.txt >> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt >> @@ -168,6 +168,14 @@ Optional property: >> by means of sensor ID. Additional coefficients are >> interpreted as constant offset. >> >> +- thermal-governor: Thermal governor to be used for this thermal zone. >> + Expected values are: >> + "step_wise": Use step wise governor. >> + "fair_share": Use fair share governor. >> + "user_space": Use user space governor. >> + "power_allocator": Use power allocator governor. > > This looks pretty Linux specific. Not that we can't have Linux > specific properties, but we try to avoid them. > > What determines the selection? I'd imagine only certain governors make > sense for certain devices. We should perhaps describe those > characteristics which can then infer the best governor. Not really > sure though... I'm not sure if it would be easy to assign preferred governors to device classes. It is dependent on what devices are present on the system, what throttling knobs they expose and how the system designer decided to integrate it all. e.g. A GPU driver might be controlled in kernel or userspace depending on whether it exposes a devfreq knob or some more esoteric statistics to userspace. Bang Bang governor seems to be designed for Fans with a simple ON/OFF iterface. Userspace governor is designed to move thermal policy to userspace (e.g. through thermald). So backlight brightness, battery charging, GPU scaling, even cpu frequency scaling can be offloaded to userspace. On embedded platforms, modem control typically happens in userspace Power allocator governor is designed for a closed-loop system to keep the total TDP of the platform under control while allowing various devices (cpu, gpu, modem, etc.) to dynamically increase or decrease their individual budget depending on the usecase. Regards, Amit -- 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
