Message ID | 20230309135515.1232-1-di.shen@unisoc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp307592wrd; Thu, 9 Mar 2023 06:05:36 -0800 (PST) X-Google-Smtp-Source: AK7set+FfFGFwBpxxW15+pUGN0ap4oSFtUPhAczD/LJfd7q7djWUO05neKIo2OpFxibFuuYMoM+G X-Received: by 2002:a17:90b:3b51:b0:237:e1d2:c662 with SMTP id ot17-20020a17090b3b5100b00237e1d2c662mr22812760pjb.14.1678370736402; Thu, 09 Mar 2023 06:05:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1678370736; cv=none; d=google.com; s=arc-20160816; b=F07C7rcw935QEB6jAEoWEd/I7bUg7NAvWXUxVeK0VqzKzLddm8psKV+viyPNABY5zD f9+24ShjPVF0Tj+wifmh0Ugny4KeHh0cZHarittJRN9KDqGZn9L+eR22omtsRc0pRYC+ a1Wu08TsEySWsWpc4nP6JLD/KNTI9yJEZjYURnfKCef1acyxHLhyplEo/M0Kf0HFf0y9 tI9rHy8PJDcYp8Z5TyZAd8e5TNpA1i8PPK1euJyruiUxLCiLDsVyp6feA6oT9GP628ib m4kdz60YM4/PeROlfOIEC2Hl4s34QGhdqfVkAyP7Jp95DRUdidOlSU+FVjVHgE7CwR2h EbHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from; bh=nceUrTYYT5dLAjK+A7jIl+9tq3CrO5yx5UYdExAPLQY=; b=SVI9LN2ePmpnfg9NbID9KZRO03AvAlsERl1ORxfM1w04ygGlgHUbW6+qO02hX6j2h+ gMQgojplk7LCtR9FkAs1oVPCe8OHfZj/acxtaq37mYXZTT+6CRGYg4sWPSxEH9U2bZpM VFepYt6AdH5Hlo0PT6AvkP+KjoGya5skSZSoofNvzytqra/AZfNPLDiB/2uS9zuZ6f1y WeRxdfS9tQ2f0NHsiGBjR1N5rL2m4dcKXFDj3OWlHRkUtnHCZMN6Ak/5Qn5nmsYrhwnC 5QBN/wsp0Hfmhfmrfak2zGoz/QKDOilfZn1/ZwhyTCC+cwZiFOI3ryY7hr1k7iXXDJ9n QkMw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 8-20020a631548000000b0050362fc5348si17213256pgv.192.2023.03.09.06.05.23; Thu, 09 Mar 2023 06:05:36 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231389AbjCIN7Y (ORCPT <rfc822;carlos.wei.hk@gmail.com> + 99 others); Thu, 9 Mar 2023 08:59:24 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46738 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231438AbjCIN5V (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 9 Mar 2023 08:57:21 -0500 Received: from SHSQR01.spreadtrum.com (unknown [222.66.158.135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40DC115CBE; Thu, 9 Mar 2023 05:55:44 -0800 (PST) Received: from SHSend.spreadtrum.com (bjmbx01.spreadtrum.com [10.0.64.7]) by SHSQR01.spreadtrum.com with ESMTP id 329DtK86091946; Thu, 9 Mar 2023 21:55:20 +0800 (+08) (envelope-from Di.Shen@unisoc.com) Received: from bj10906pcu1.spreadtrum.com (10.0.74.67) by BJMBX01.spreadtrum.com (10.0.64.7) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Thu, 9 Mar 2023 21:55:19 +0800 From: Di Shen <di.shen@unisoc.com> To: <lukasz.luba@arm.com>, <rafael@kernel.org> CC: <daniel.lezcano@linaro.org>, <amitk@kernel.org>, <rui.zhang@intel.com>, <linux-pm@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <xuewen.yan@unisoc.com> Subject: [PATCH] thermal/core/power_allocator: avoid cdev->state can not be reset Date: Thu, 9 Mar 2023 21:55:15 +0800 Message-ID: <20230309135515.1232-1-di.shen@unisoc.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.0.74.67] X-ClientProxiedBy: SHCAS03.spreadtrum.com (10.0.1.207) To BJMBX01.spreadtrum.com (10.0.64.7) X-MAIL: SHSQR01.spreadtrum.com 329DtK86091946 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1759899273083380863?= X-GMAIL-MSGID: =?utf-8?q?1759899273083380863?= |
Series |
thermal/core/power_allocator: avoid cdev->state can not be reset
|
|
Commit Message
Di Shen
March 9, 2023, 1:55 p.m. UTC
Commit 0952177f2a1f (thermal/core/power_allocator: Update once cooling devices when temp is low)
add a update flag to update cooling device only once when temp is low.
But when the switch_on_temp is set to be a higher value, the cooling device state
may not be reset to max, because the last_temp is smaller than the switch_on_temp.
For example:
First:
swicth_on_temp=70 control_temp=85;
Then userspace change the trip_temp:
swicth_on_temp=45 control_temp=55 cur_temp=54
Then userspace reset the trip_temp:
swicth_on_temp=70 control_temp=85 cur_temp=57 last_temp=54
At this time, the cooling device state should be reset to be max.
However, because cur_temp(57) < switch_on_temp(70)
last_temp(54) < swicth_on_temp(70) --> update = false
When update is false, the cooling device state can not be reset.
So delete the update condition, so that the cooling device state
could be reset.
Fixes: 0952177f2a1f (thermal/core/power_allocator: Update once cooling devices when temp is low)
Signed-off-by: Di Shen <di.shen@unisoc.com>
---
drivers/thermal/gov_power_allocator.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
Comments
Hi all, any comments for this patch? Looking forward to your reply. Thank you.
Hi Di, On 3/9/23 13:55, Di Shen wrote: > Commit 0952177f2a1f (thermal/core/power_allocator: Update once cooling devices when temp is low) > add a update flag to update cooling device only once when temp is low. > But when the switch_on_temp is set to be a higher value, the cooling device state > may not be reset to max, because the last_temp is smaller than the switch_on_temp. > > For example: > First: > swicth_on_temp=70 control_temp=85; > > Then userspace change the trip_temp: > swicth_on_temp=45 control_temp=55 cur_temp=54 > > Then userspace reset the trip_temp: > swicth_on_temp=70 control_temp=85 cur_temp=57 last_temp=54 > > At this time, the cooling device state should be reset to be max. > However, because cur_temp(57) < switch_on_temp(70) > last_temp(54) < swicth_on_temp(70) --> update = false > When update is false, the cooling device state can not be reset. That's a tricky use case. How is that now possible, > > So delete the update condition, so that the cooling device state > could be reset. IMO this is not the desired solution. Daniel reported the issue that IPA triggers the event sent to user-space even when there is no need. That's the motivation for the 0952177f2a1f change. To address your scenario properly, we need an interface which allows to respond properly for such situation when someone from user-space writes a new value to something fundamental as trip point. You also have a kernel config enabled: CONFIG_THERMAL_WRITABLE_TRIPS which IMO is only for debug kernels for system integrator (according to the Kconfig description). When you disable this config in your deploy/product kernel than this issue would disappear. > > Fixes: 0952177f2a1f (thermal/core/power_allocator: Update once cooling devices when temp is low) > Signed-off-by: Di Shen <di.shen@unisoc.com> > --- > drivers/thermal/gov_power_allocator.c | 9 +++------ > 1 file changed, 3 insertions(+), 6 deletions(-) > That's why IMO this is not the solution. Regards, Lukasz
Hi Lukasz On Fri, Mar 10, 2023 at 11:56 PM Lukasz Luba <lukasz.luba@arm.com> wrote: > > Hi Di, > > On 3/9/23 13:55, Di Shen wrote: > > Commit 0952177f2a1f (thermal/core/power_allocator: Update once cooling devices when temp is low) > > add a update flag to update cooling device only once when temp is low. > > But when the switch_on_temp is set to be a higher value, the cooling device state > > may not be reset to max, because the last_temp is smaller than the switch_on_temp. > > > > For example: > > First: > > swicth_on_temp=70 control_temp=85; > > > > Then userspace change the trip_temp: > > swicth_on_temp=45 control_temp=55 cur_temp=54 > > > > Then userspace reset the trip_temp: > > swicth_on_temp=70 control_temp=85 cur_temp=57 last_temp=54 > > > > At this time, the cooling device state should be reset to be max. > > However, because cur_temp(57) < switch_on_temp(70) > > last_temp(54) < swicth_on_temp(70) --> update = false > > When update is false, the cooling device state can not be reset. > > That's a tricky use case. How is that now possible, We use the trip_temp in the Android System. Often, we set different control temperatures in different scenarios, and when we change the switch_on_temp from small to bigger, we find the power can not be reset to be max. > > > > So delete the update condition, so that the cooling device state > > could be reset. > > IMO this is not the desired solution. Daniel reported the issue that > IPA triggers the event sent to user-space even when there is no need. > That's the motivation for the 0952177f2a1f change. > > To address your scenario properly, we need an interface which allows > to respond properly for such situation when someone from user-space > writes a new value to something fundamental as trip point. > > You also have a kernel config enabled: > CONFIG_THERMAL_WRITABLE_TRIPS > which IMO is only for debug kernels for system integrator (according > to the Kconfig description). Yes, we use it to meet the temperature control needs of different scenarios. And now in android with google's GKI2.0, the config must be opened. > > When you disable this config in your deploy/product kernel > than this issue would disappear. > > > > > Fixes: 0952177f2a1f (thermal/core/power_allocator: Update once cooling devices when temp is low) > > Signed-off-by: Di Shen <di.shen@unisoc.com> > > --- > > drivers/thermal/gov_power_allocator.c | 9 +++------ > > 1 file changed, 3 insertions(+), 6 deletions(-) > > > > That's why IMO this is not the solution. Yes, but I think we should fix the bug, although the CONFIG_THERMAL_WRITABLE_TRIPS is just for debugging. How about record the last_trip_temp, and when the last_temp > last_trip_temp, set the update tobe true? Thanks! BR, xuewen > > Regards, > Lukasz
Hi Xuewen, On 3/13/23 01:40, Xuewen Yan wrote: > Hi Lukasz > > On Fri, Mar 10, 2023 at 11:56 PM Lukasz Luba <lukasz.luba@arm.com> wrote: >> >> Hi Di, >> >> On 3/9/23 13:55, Di Shen wrote: >>> Commit 0952177f2a1f (thermal/core/power_allocator: Update once cooling devices when temp is low) >>> add a update flag to update cooling device only once when temp is low. >>> But when the switch_on_temp is set to be a higher value, the cooling device state >>> may not be reset to max, because the last_temp is smaller than the switch_on_temp. >>> >>> For example: >>> First: >>> swicth_on_temp=70 control_temp=85; >>> >>> Then userspace change the trip_temp: >>> swicth_on_temp=45 control_temp=55 cur_temp=54 >>> >>> Then userspace reset the trip_temp: >>> swicth_on_temp=70 control_temp=85 cur_temp=57 last_temp=54 >>> >>> At this time, the cooling device state should be reset to be max. >>> However, because cur_temp(57) < switch_on_temp(70) >>> last_temp(54) < swicth_on_temp(70) --> update = false >>> When update is false, the cooling device state can not be reset. >> >> That's a tricky use case. How is that now possible, > > We use the trip_temp in the Android System. Often, we set different > control temperatures in different scenarios, > and when we change the switch_on_temp from small to bigger, we find > the power can not be reset to be max. I see, thanks for letting me know that this is Android. > > >>> >>> So delete the update condition, so that the cooling device state >>> could be reset. >> >> IMO this is not the desired solution. Daniel reported the issue that >> IPA triggers the event sent to user-space even when there is no need. >> That's the motivation for the 0952177f2a1f change. >> >> To address your scenario properly, we need an interface which allows >> to respond properly for such situation when someone from user-space >> writes a new value to something fundamental as trip point. >> >> You also have a kernel config enabled: >> CONFIG_THERMAL_WRITABLE_TRIPS >> which IMO is only for debug kernels for system integrator (according >> to the Kconfig description). > > Yes, we use it to meet the temperature control needs of different scenarios. > And now in android with google's GKI2.0, the config must be opened. OK > >> >> When you disable this config in your deploy/product kernel >> than this issue would disappear. >> >>> >>> Fixes: 0952177f2a1f (thermal/core/power_allocator: Update once cooling devices when temp is low) >>> Signed-off-by: Di Shen <di.shen@unisoc.com> >>> --- >>> drivers/thermal/gov_power_allocator.c | 9 +++------ >>> 1 file changed, 3 insertions(+), 6 deletions(-) >>> >> >> That's why IMO this is not the solution. > > Yes, but I think we should fix the bug, although the > CONFIG_THERMAL_WRITABLE_TRIPS is just for debugging. > How about record the last_trip_temp, and when the last_temp > > last_trip_temp, set the update tobe true? Yes, if that config is used in Android then we must fix it. That last_trip_temp makes sense (but maybe name it last_switch_on_temp). Please put that new field into the IPA local struct power_allocator_params. We should store the trip temp value there every time power_allocator_throttle() is called. That can be called due to a write from user-space w/ a new trip point value, so should be OK. Regards, Lukasz
Hi Lukasz On Mon, Mar 13, 2023 at 5:35 PM Lukasz Luba <lukasz.luba@arm.com> wrote: > > Hi Xuewen, > > On 3/13/23 01:40, Xuewen Yan wrote: > > Hi Lukasz > > > > On Fri, Mar 10, 2023 at 11:56 PM Lukasz Luba <lukasz.luba@arm.com> wrote: > >> > >> Hi Di, > >> > >> On 3/9/23 13:55, Di Shen wrote: > >>> Commit 0952177f2a1f (thermal/core/power_allocator: Update once cooling devices when temp is low) > >>> add a update flag to update cooling device only once when temp is low. > >>> But when the switch_on_temp is set to be a higher value, the cooling device state > >>> may not be reset to max, because the last_temp is smaller than the switch_on_temp. > >>> > >>> For example: > >>> First: > >>> swicth_on_temp=70 control_temp=85; > >>> > >>> Then userspace change the trip_temp: > >>> swicth_on_temp=45 control_temp=55 cur_temp=54 > >>> > >>> Then userspace reset the trip_temp: > >>> swicth_on_temp=70 control_temp=85 cur_temp=57 last_temp=54 > >>> > >>> At this time, the cooling device state should be reset to be max. > >>> However, because cur_temp(57) < switch_on_temp(70) > >>> last_temp(54) < swicth_on_temp(70) --> update = false > >>> When update is false, the cooling device state can not be reset. > >> > >> That's a tricky use case. How is that now possible, > > > > We use the trip_temp in the Android System. Often, we set different > > control temperatures in different scenarios, > > and when we change the switch_on_temp from small to bigger, we find > > the power can not be reset to be max. > > I see, thanks for letting me know that this is Android. > > > > > > >>> > >>> So delete the update condition, so that the cooling device state > >>> could be reset. > >> > >> IMO this is not the desired solution. Daniel reported the issue that > >> IPA triggers the event sent to user-space even when there is no need. > >> That's the motivation for the 0952177f2a1f change. > >> > >> To address your scenario properly, we need an interface which allows > >> to respond properly for such situation when someone from user-space > >> writes a new value to something fundamental as trip point. > >> > >> You also have a kernel config enabled: > >> CONFIG_THERMAL_WRITABLE_TRIPS > >> which IMO is only for debug kernels for system integrator (according > >> to the Kconfig description). > > > > Yes, we use it to meet the temperature control needs of different scenarios. > > And now in android with google's GKI2.0, the config must be opened. > > OK > > > > >> > >> When you disable this config in your deploy/product kernel > >> than this issue would disappear. > >> > >>> > >>> Fixes: 0952177f2a1f (thermal/core/power_allocator: Update once cooling devices when temp is low) > >>> Signed-off-by: Di Shen <di.shen@unisoc.com> > >>> --- > >>> drivers/thermal/gov_power_allocator.c | 9 +++------ > >>> 1 file changed, 3 insertions(+), 6 deletions(-) > >>> > >> > >> That's why IMO this is not the solution. > > > > Yes, but I think we should fix the bug, although the > > CONFIG_THERMAL_WRITABLE_TRIPS is just for debugging. > > How about record the last_trip_temp, and when the last_temp > > > last_trip_temp, set the update tobe true? > > Yes, if that config is used in Android then we must fix it. > > That last_trip_temp makes sense (but maybe name it last_switch_on_temp). > Please put that new field into the IPA local > struct power_allocator_params. We should store the trip temp > value there every time power_allocator_throttle() is called. > That can be called due to a write from user-space w/ a new trip point > value, so should be OK. Thanks for the suggestion. We would send the patch-v2 as soon as possible. Thanks! BR xuewen
On 3/13/23 11:10, Xuewen Yan wrote: > Hi Lukasz > > On Mon, Mar 13, 2023 at 5:35 PM Lukasz Luba <lukasz.luba@arm.com> wrote: >> >> Hi Xuewen, >> >> On 3/13/23 01:40, Xuewen Yan wrote: >>> Hi Lukasz >>> >>> On Fri, Mar 10, 2023 at 11:56 PM Lukasz Luba <lukasz.luba@arm.com> wrote: >>>> >>>> Hi Di, >>>> >>>> On 3/9/23 13:55, Di Shen wrote: >>>>> Commit 0952177f2a1f (thermal/core/power_allocator: Update once cooling devices when temp is low) >>>>> add a update flag to update cooling device only once when temp is low. >>>>> But when the switch_on_temp is set to be a higher value, the cooling device state >>>>> may not be reset to max, because the last_temp is smaller than the switch_on_temp. >>>>> >>>>> For example: >>>>> First: >>>>> swicth_on_temp=70 control_temp=85; >>>>> >>>>> Then userspace change the trip_temp: >>>>> swicth_on_temp=45 control_temp=55 cur_temp=54 >>>>> >>>>> Then userspace reset the trip_temp: >>>>> swicth_on_temp=70 control_temp=85 cur_temp=57 last_temp=54 >>>>> >>>>> At this time, the cooling device state should be reset to be max. >>>>> However, because cur_temp(57) < switch_on_temp(70) >>>>> last_temp(54) < swicth_on_temp(70) --> update = false >>>>> When update is false, the cooling device state can not be reset. >>>> >>>> That's a tricky use case. How is that now possible, >>> >>> We use the trip_temp in the Android System. Often, we set different >>> control temperatures in different scenarios, >>> and when we change the switch_on_temp from small to bigger, we find >>> the power can not be reset to be max. >> >> I see, thanks for letting me know that this is Android. >> >>> >>> >>>>> >>>>> So delete the update condition, so that the cooling device state >>>>> could be reset. >>>> >>>> IMO this is not the desired solution. Daniel reported the issue that >>>> IPA triggers the event sent to user-space even when there is no need. >>>> That's the motivation for the 0952177f2a1f change. >>>> >>>> To address your scenario properly, we need an interface which allows >>>> to respond properly for such situation when someone from user-space >>>> writes a new value to something fundamental as trip point. >>>> >>>> You also have a kernel config enabled: >>>> CONFIG_THERMAL_WRITABLE_TRIPS >>>> which IMO is only for debug kernels for system integrator (according >>>> to the Kconfig description). >>> >>> Yes, we use it to meet the temperature control needs of different scenarios. >>> And now in android with google's GKI2.0, the config must be opened. >> >> OK >> >>> >>>> >>>> When you disable this config in your deploy/product kernel >>>> than this issue would disappear. >>>> >>>>> >>>>> Fixes: 0952177f2a1f (thermal/core/power_allocator: Update once cooling devices when temp is low) >>>>> Signed-off-by: Di Shen <di.shen@unisoc.com> >>>>> --- >>>>> drivers/thermal/gov_power_allocator.c | 9 +++------ >>>>> 1 file changed, 3 insertions(+), 6 deletions(-) >>>>> >>>> >>>> That's why IMO this is not the solution. >>> >>> Yes, but I think we should fix the bug, although the >>> CONFIG_THERMAL_WRITABLE_TRIPS is just for debugging. >>> How about record the last_trip_temp, and when the last_temp > >>> last_trip_temp, set the update tobe true? >> >> Yes, if that config is used in Android then we must fix it. >> >> That last_trip_temp makes sense (but maybe name it last_switch_on_temp). >> Please put that new field into the IPA local >> struct power_allocator_params. We should store the trip temp >> value there every time power_allocator_throttle() is called. >> That can be called due to a write from user-space w/ a new trip point >> value, so should be OK. > > Thanks for the suggestion. We would send the patch-v2 as soon as possible. Thanks! I'll review that and check on my board. BTW, which board/device you use with this IPA? Maybe I can buy it and also test to capture such regression in future.
add Orson and lyra Hi Lukasz On Mon, Mar 13, 2023 at 7:18 PM Lukasz Luba <lukasz.luba@arm.com> wrote: > > > > On 3/13/23 11:10, Xuewen Yan wrote: > > Hi Lukasz > > > > On Mon, Mar 13, 2023 at 5:35 PM Lukasz Luba <lukasz.luba@arm.com> wrote: > >> > >> Hi Xuewen, > >> > >> On 3/13/23 01:40, Xuewen Yan wrote: > >>> Hi Lukasz > >>> > >>> On Fri, Mar 10, 2023 at 11:56 PM Lukasz Luba <lukasz.luba@arm.com> wrote: > >>>> > >>>> Hi Di, > >>>> > >>>> On 3/9/23 13:55, Di Shen wrote: > >>>>> Commit 0952177f2a1f (thermal/core/power_allocator: Update once cooling devices when temp is low) > >>>>> add a update flag to update cooling device only once when temp is low. > >>>>> But when the switch_on_temp is set to be a higher value, the cooling device state > >>>>> may not be reset to max, because the last_temp is smaller than the switch_on_temp. > >>>>> > >>>>> For example: > >>>>> First: > >>>>> swicth_on_temp=70 control_temp=85; > >>>>> > >>>>> Then userspace change the trip_temp: > >>>>> swicth_on_temp=45 control_temp=55 cur_temp=54 > >>>>> > >>>>> Then userspace reset the trip_temp: > >>>>> swicth_on_temp=70 control_temp=85 cur_temp=57 last_temp=54 > >>>>> > >>>>> At this time, the cooling device state should be reset to be max. > >>>>> However, because cur_temp(57) < switch_on_temp(70) > >>>>> last_temp(54) < swicth_on_temp(70) --> update = false > >>>>> When update is false, the cooling device state can not be reset. > >>>> > >>>> That's a tricky use case. How is that now possible, > >>> > >>> We use the trip_temp in the Android System. Often, we set different > >>> control temperatures in different scenarios, > >>> and when we change the switch_on_temp from small to bigger, we find > >>> the power can not be reset to be max. > >> > >> I see, thanks for letting me know that this is Android. > >> > >>> > >>> > >>>>> > >>>>> So delete the update condition, so that the cooling device state > >>>>> could be reset. > >>>> > >>>> IMO this is not the desired solution. Daniel reported the issue that > >>>> IPA triggers the event sent to user-space even when there is no need. > >>>> That's the motivation for the 0952177f2a1f change. > >>>> > >>>> To address your scenario properly, we need an interface which allows > >>>> to respond properly for such situation when someone from user-space > >>>> writes a new value to something fundamental as trip point. > >>>> > >>>> You also have a kernel config enabled: > >>>> CONFIG_THERMAL_WRITABLE_TRIPS > >>>> which IMO is only for debug kernels for system integrator (according > >>>> to the Kconfig description). > >>> > >>> Yes, we use it to meet the temperature control needs of different scenarios. > >>> And now in android with google's GKI2.0, the config must be opened. > >> > >> OK > >> > >>> > >>>> > >>>> When you disable this config in your deploy/product kernel > >>>> than this issue would disappear. > >>>> > >>>>> > >>>>> Fixes: 0952177f2a1f (thermal/core/power_allocator: Update once cooling devices when temp is low) > >>>>> Signed-off-by: Di Shen <di.shen@unisoc.com> > >>>>> --- > >>>>> drivers/thermal/gov_power_allocator.c | 9 +++------ > >>>>> 1 file changed, 3 insertions(+), 6 deletions(-) > >>>>> > >>>> > >>>> That's why IMO this is not the solution. > >>> > >>> Yes, but I think we should fix the bug, although the > >>> CONFIG_THERMAL_WRITABLE_TRIPS is just for debugging. > >>> How about record the last_trip_temp, and when the last_temp > > >>> last_trip_temp, set the update tobe true? > >> > >> Yes, if that config is used in Android then we must fix it. > >> > >> That last_trip_temp makes sense (but maybe name it last_switch_on_temp). > >> Please put that new field into the IPA local > >> struct power_allocator_params. We should store the trip temp > >> value there every time power_allocator_throttle() is called. > >> That can be called due to a write from user-space w/ a new trip point > >> value, so should be OK. > > > > Thanks for the suggestion. We would send the patch-v2 as soon as possible. > > Thanks! > I'll review that and check on my board. > BTW, which board/device you use with this IPA? Maybe I can buy it > and also test to capture such regression in future. We use our company(unisoc)'s mobile phone, and the development board with the same chip should be available in the market. And Orson would help and then reply to you. Thanks! BR xuewen
diff --git a/drivers/thermal/gov_power_allocator.c b/drivers/thermal/gov_power_allocator.c index 0eaf1527d3e3..153bf528b98c 100644 --- a/drivers/thermal/gov_power_allocator.c +++ b/drivers/thermal/gov_power_allocator.c @@ -560,7 +560,7 @@ static void reset_pid_controller(struct power_allocator_params *params) params->prev_err = 0; } -static void allow_maximum_power(struct thermal_zone_device *tz, bool update) +static void allow_maximum_power(struct thermal_zone_device *tz) { struct thermal_instance *instance; struct power_allocator_params *params = tz->governor_data; @@ -582,8 +582,7 @@ static void allow_maximum_power(struct thermal_zone_device *tz, bool update) */ cdev->ops->get_requested_power(cdev, &req_power); - if (update) - __thermal_cdev_update(instance->cdev); + __thermal_cdev_update(instance->cdev); mutex_unlock(&instance->cdev->lock); } @@ -697,7 +696,6 @@ static int power_allocator_throttle(struct thermal_zone_device *tz, int trip_id) struct power_allocator_params *params = tz->governor_data; struct thermal_trip trip; int ret; - bool update; lockdep_assert_held(&tz->lock); @@ -710,10 +708,9 @@ static int power_allocator_throttle(struct thermal_zone_device *tz, int trip_id) ret = __thermal_zone_get_trip(tz, params->trip_switch_on, &trip); if (!ret && (tz->temperature < trip.temperature)) { - update = (tz->last_temperature >= trip.temperature); tz->passive = 0; reset_pid_controller(params); - allow_maximum_power(tz, update); + allow_maximum_power(tz); return 0; }