Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp347120pxu; Tue, 6 Oct 2020 07:50:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxIzr3p9gkl9QbRk0VaEOCWIYI6EOgZy7uEBgSy1EP7uB2rIcL1FZgeXEjG7UbqqfrUvLkL X-Received: by 2002:a05:6402:b27:: with SMTP id bo7mr6047432edb.202.1601995816875; Tue, 06 Oct 2020 07:50:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601995816; cv=none; d=google.com; s=arc-20160816; b=S5ZxfqRdyButKP75QV0rDCvOuXOUBicq8jCMA0+vdNcSoVAf7OJgaCpw10lwEnZv1s Hyi1kRPORgUP9Shn+0h8nmPyeeBss80Pkx9CybMtpqer5otaTGXImdAsZBNu9RQHyfJo ONb+QWPlG7unZ+LQEhTAuXZsU+wh/puQlN+8rzZgGwq1XKVlK6f8cS3FQ9NTHlDfwN2m MMenitpmdmdSOVSZ9YMOMnBcQpSFgBZ6P5p31SxgFC8WxcwhcHPiwvQnbOHyvkhgtubu U3ld2Xe86Fu7RzZR4j33ADA4qnw7t40v4dOmu67e9o2rYBW8AfjzVDFDs15q3yFHPyqj Qkzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:references:cc :to:from:subject; bh=bJbqbHDWllXmvTS7gePMf8+v3Yd3Qolqsq3W/Jk02zc=; b=pizd+I0vRpobNe/VSBzy/o0oOBMWMfr7L7kU/7pMOWy+A7oQsYJmkS2wssUgaONSAT pki0gahTwSMe2L8cMUVXHUmhPdL6E0jUdQ/R8BmG2HphxFtD9N6kem8a3DUr/HppNWCd odutNEDaTaj9bSmDLjmjnNjuDt1jIVPr9MmKcriaK6JsqG0M+ZrE8dXDhmUACcN0sjHW EIRCiVxl7obPEAM9sXXRw+wHOYjU3i7XJSieCjLLX9yK+uX524pRTvOktjudb5RrUswx KLmpOOosCmpICyh8xSJDPgiajHr/dzWcXp9bvt/0PX182h51mKW0gqqs4uDfW0pcEMqb Wyiw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o1si2340383eje.149.2020.10.06.07.49.52; Tue, 06 Oct 2020 07:50:16 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726181AbgJFOqv (ORCPT + 99 others); Tue, 6 Oct 2020 10:46:51 -0400 Received: from foss.arm.com ([217.140.110.172]:49124 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725946AbgJFOqv (ORCPT ); Tue, 6 Oct 2020 10:46:51 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 408791476; Tue, 6 Oct 2020 07:46:50 -0700 (PDT) Received: from [10.57.54.147] (unknown [10.57.54.147]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2B2433F71F; Tue, 6 Oct 2020 07:46:46 -0700 (PDT) Subject: Re: [PATCH] thermal: power_allocate: add upper and lower limits From: Lukasz Luba To: Michael Kao Cc: Zhang Rui , Eduardo Valentin , Daniel Lezcano , Rob Herring , Mark Rutland , Matthias Brugger , hsinyi@chromium.org, linux-pm@vger.kernel.org, srv_heupstream@mediatek.com, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org References: <20200424071601.2636-1-michael.kao@mediatek.com> <1588156776.3573.1.camel@mtksdccf07> <03286571-c110-7f5e-a911-24f8c3e4fd42@arm.com> <1598347775.16267.0.camel@mtksdccf07> <25cb2d5b-0d87-8a22-a881-a5b6e46307ec@arm.com> Message-ID: <77bd14bb-0318-332a-4ea1-f60a314ce3be@arm.com> Date: Tue, 6 Oct 2020 15:46:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <25cb2d5b-0d87-8a22-a881-a5b6e46307ec@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/6/20 3:39 PM, Lukasz Luba wrote: > Hi Michael, > > On 8/25/20 10:29 AM, Michael Kao wrote: >> On Wed, 2020-04-29 at 21:24 +0100, Lukasz Luba wrote: >>> >>> On 4/29/20 11:39 AM, Michael Kao wrote: >>>> On Fri, 2020-04-24 at 10:22 +0100, Lukasz Luba wrote: >>>>> Hi Michael, >>>>> >>>>> On 4/24/20 8:16 AM, Michael Kao wrote: >>>>>> The upper and lower limits of thermal throttle state in the >>>>>> device tree do not apply to the power_allocate governor. >>>>>> Add the upper and lower limits to the power_allocate governor. >>>>>> >>>>>> Signed-off-by: Michael Kao >>>>>> --- >>>>>>     drivers/thermal/thermal_core.c | 2 +- >>>>>>     1 file changed, 1 insertion(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/drivers/thermal/thermal_core.c >>>>>> b/drivers/thermal/thermal_core.c >>>>>> index 9a321dc548c8..f6feed2265bd 100644 >>>>>> --- a/drivers/thermal/thermal_core.c >>>>>> +++ b/drivers/thermal/thermal_core.c >>>>>> @@ -598,7 +598,7 @@ int power_actor_set_power(struct >>>>>> thermal_cooling_device *cdev, >>>>>>         if (ret) >>>>>>             return ret; >>>>>> -    instance->target = state; >>>>>> +    instance->target = clamp_val(state, instance->lower, >>>>>> instance->upper); >>>>>>         mutex_lock(&cdev->lock); >>>>>>         cdev->updated = false; >>>>>>         mutex_unlock(&cdev->lock); >>>>>> >>>>> >>>>> Thank you for the patch and having to look at it. I have some concerns >>>>> with this approach. Let's analyze it further. >>>>> >>>>> In default the cooling devices in the thermal zone which is used by >>>>> IPA >>>>> do not have this 'lower' and 'upper' limits. They are set to >>>>> THERMAL_NO_LIMIT in DT to give full control to IPA over the states. >>>>> >>>>> This the function 'power_actor_set_power' actually translates granted >>>>> power to the state that device will run for the next period. >>>>> The IPA algorithm has already split the power budget. >>>>> Now what happen when the 'lower' value will change the state to a >>>>> state >>>>> which consumes more power than was calculated in the IPA alg... It >>>>> will >>>>> became unstable. >>>>> >>>>> I would rather see a change which uses these 'lower' and 'upper' >>>>> limits >>>>> before the IPA do the calculation of the power budget. But this wasn't >>>>> a requirement and we assumed that IPA has full control over the >>>>> cooling >>>>> device (which I described above with this DT THERMAL_NO_LIMIT). >>>>> >>>>> Is there a problem with your platform that it has to provide some >>>>> minimal performance, so you tried to introduce this clamping? >>>>> >>>>> Regards, >>>>> Lukasz >>>> >>>> >>>> Hi Lukasz, >>>> >>>> I refer to the documentation settings of the thermal device tree >>>> (Documentation / devicetree / bindings / thermal / thermal.txt). >>>> >>>> It shows that cooling-device is a mandatory property, so max/min >>>> cooling >>>> state should be able to support in framework point of view. >>>> Otherwise, the limitation should be added in binding document. >>>> >>>> Different hardware mechanisms have different heat dissipation >>>> capabilities. >>>> Limiting the input heat source can slow down the heat accumulation and >>>> temperature burst. >>>> We want to reduce the accumulation of heat at high temperature by >>>> limiting the minimum gear of thermal throttle. >>> >>> I agree that these 'lower' and 'upper' limits shouldn't be just >>> ignored as is currently. This patch clamps the value at late stage, >>> though. >>> >>> Let me have a look how it could be taken into account in the early >>> stage, before the power calculation and split are done. Maybe there >>> is a clean way to inject this. >>> >>> Regards, >>> Lukasz >> Hi Lukasz, >> >> After the research, do you have any ideas or suggestions? >> >> Best Regards, >> Michael >> > > My apologies for the delay. I have done some experiments. > Could you resend the patch, please make sure it is not encoded in base64 > like this one. > > I am going to take your patch together with some other changes. > > Regards, > Lukasz Please change also the commit message to something like: thermal: core: add upper and lower limits to power_actor_set_power The upper and lower limits of thermal throttle state in the DT do not apply to the Intelligent Power Allocation (IPA) governor. Add the clamping for cooling device upper and lower limits in the power_actor_set_power() used by IPA. Regards, Lukasz