linux-kernel - Re: [PATCH] thermal: of: Allow selection of thermal governor in DT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 6 Mar 2018 11:08:18 +0530
From:   Amit Kucheria <amit.kucheria@...aro.org>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     DTML <devicetree@...r.kernel.org>,
        Ram Chandrasekar <rkumbako@...eaurora.org>,
        Lina Iyer <ilina@...eaurora.org>,
        Zhang Rui <rui.zhang@...el.com>,
        Eduardo Valentin <edubezval@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        Linux PM list <linux-pm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] thermal: of: Allow selection of thermal governor in DT

On Tue, Mar 6, 2018 at 1:38 AM, Rob Herring <robh+dt@...nel.org> wrote:
> On Mon, Mar 5, 2018 at 12:36 PM, Amit Kucheria <amit.kucheria@...aro.org> wrote:
>> From: Ram Chandrasekar <rkumbako@...eaurora.org>
>>
>> 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@...eaurora.org>
>> Signed-off-by: Amit Kucheria <amit.kucheria@...aro.org>
>> ---
>>  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