Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH] thermal: imx8mm: Add get_trend ops
To:     Anson Huang <anson.huang@nxp.com>,
        "rui.zhang@intel.com" <rui.zhang@intel.com>,
        "amit.kucheria@verdurent.com" <amit.kucheria@verdurent.com>,
        "shawnguo@kernel.org" <shawnguo@kernel.org>,
        "s.hauer@pengutronix.de" <s.hauer@pengutronix.de>,
        "kernel@pengutronix.de" <kernel@pengutronix.de>,
        "festevam@gmail.com" <festevam@gmail.com>,
        "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc:     dl-linux-imx <linux-imx@nxp.com>
References: <1589338689-15700-1-git-send-email-Anson.Huang@nxp.com>
 <fccf4197-d0ca-f313-8f70-000ef4731033@linaro.org>
 <DB3PR0402MB3916B6D11328A036BD479D39F5B50@DB3PR0402MB3916.eurprd04.prod.outlook.com>
 <6a4d31e4-8a24-2e9f-aa49-bec8258ead4c@linaro.org>
 <DB3PR0402MB39167D71ED6979FC33D3747DF5B20@DB3PR0402MB3916.eurprd04.prod.outlook.com>
 <DB3PR0402MB39162E6A876BA54A80B0DCE2F5B30@DB3PR0402MB3916.eurprd04.prod.outlook.com>
From:   Daniel Lezcano <daniel.lezcano@linaro.org>
Message-ID: <dadf94db-8aa5-d1a7-5818-c56032a44ea4@linaro.org>
Date:   Mon, 25 May 2020 13:04:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <DB3PR0402MB39162E6A876BA54A80B0DCE2F5B30@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 25/05/2020 04:46, Anson Huang wrote:
> Hi, Daniel

[ ... ]

> I tried modifying the min/max to '2' in cooling map, it works that
> whenever cooling action is needed, the max cooling action will be
> applied. But I also noticed some behaviors which NOT as expected:
> 
> 1. to easy the test, I enable the " CONFIG_THERMAL_WRITABLE_TRIPS",
> and just modify the passive trip threshold to trigger the cooling
> action, this is much more easy then putting the board into an oven to
> increase the SoC temperature or running many high loading test to
> increase the temperature, but when I modify the passive trip
> threshold to be lower than current temperature, the cooling action is
> NOT triggered immediately, it is because the default step_wise
> governor will NOT trigger the cooling action when the trend is
> THERMAL_TREND_STABLE. But what expected is, when the temperature is
> exceed the passive trip threshold, the cooling action can be 
> triggered immediately no matter the trend is stable or raising.

You are right, what is expected is, when the temperature exceeds the
passive trip threshold, a cooling action happens, the trend is raising
in this case.

But in your test, it is not what is happening: the trip point is
changing, not the temperature.

Probably, the cpufreq driver is at its lowest OPP, so there is no room
for more cooling effect when changing the trip point.

IMO, the test is not right as the trip point is decreased to a
temperature where actually the SoC is not hot.

If you want to test it easily, I recommend to use dhrystone, something like:

 dhrystone -t 6 -l 10000

That will make your board to heat immediately.

> That
> means we have to implement our own .get_trend callback?

From my POV it must disappear, because it has little meaning. The
governor is the one which should be dealing with that and call the
corresponding cooling index.

> 2. No margin for releasing the cooling action, for example, if
> cooling action is triggered, when the temperature drops below the
> passive trip threshold, the cooling action will be cancelled
> immediately, if SoC keeps running at full performance, the
> temperature will increase very soon, which may cause the SoC keep
> triggering/cancelling the cooling action around the passive trip
> threshold. If there is a margin, the situation will be much better.
> 
> Do you have any idea/comment about them?

Yes, that is a good point. The hysteresis is supposed to do that. There
is a work done by Andrzej Pietrasiewicz to disable / enable the thermal
zones [1]. I think we should be able to fix that after the changes are done.

  -- Daniel

[1] https://www.spinics.net/lists/netdev/msg644762.html


-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog