Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp4625124pxb; Tue, 25 Jan 2022 14:51:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJy1j/5XNB8R9fXvT+52bNXpUpXioZ57m6FoFIprBeWNF9i1gcbNu9zmighFJpHABgbHeEcA X-Received: by 2002:a17:902:a50f:b0:149:bc1a:2c98 with SMTP id s15-20020a170902a50f00b00149bc1a2c98mr20611198plq.35.1643151080106; Tue, 25 Jan 2022 14:51:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643151080; cv=none; d=google.com; s=arc-20160816; b=bBvOPvy7EaaS2AQfDCLSj+6d59sCNzICOHURun8x6382+Z/QaUZRiu0aomY3bU6EsS 4uxeS0smc8AZfUfsEZbciaHwIWOuQOS8WN/odkhhMTPMD9BRuF043rh/ksSXdu7wFQCa JcnHGwhUD76n/y0McJLqVF4w+QP7SuqzWYjWI04DedeJ1gHBIMFjGL6Py6B2i8NRpvsc ivyXDaLYG04K76Z3qNgqNqAzPUhUi2ZgoQysncx/Uf5NR4rEarIY+nCY3oUJpQS6UW8C YzUUpXubmWp29wtT2778LCM8w3QypkcjxC55hBaQ7cDbXv8+XRhHMl1kQy2jREE5oGRS ysVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:subject:user-agent:mime-version:date:message-id :dkim-signature; bh=uuU7P40JMh4ZEKpl+/QMPGzxGUUPCLs+4G9cP3BtI2U=; b=F9pxCcq9hxHNyIZj05o4jf56yvbavKSF4KM+/+q8XnZxdcA2d4gOnXArMhBf5jcxTo gg0WkZKObEhJvk2JhWmuOnsgKUSMY7yU0biRtDDvZCy0XkQnunxqRKUyliv0bTvoCpoj kN/Xqe11QRfN0vo8Z96K0S7cQEL49Uib/Hj77rsQS7vXn+ZrsZzMpLkzf0GAW/+d2Bru /pyAAnboEgmCuXHN7miH8tbHFUeLjrb+ynOsGQ4rek7r2BYs5245oUNNARRlOitss1kZ +k7Z5GbMmwSwsaxtXkfV5cjA351r0b+kMIZb0s9dZsrYm8Bg8VhlNNiKuVBEOs+9YvG4 p+Qw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=f1li3HJF; 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=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p3si115926pfh.144.2022.01.25.14.51.08; Tue, 25 Jan 2022 14:51:20 -0800 (PST) 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; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=f1li3HJF; 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=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345960AbiAYPuo (ORCPT + 99 others); Tue, 25 Jan 2022 10:50:44 -0500 Received: from alexa-out.qualcomm.com ([129.46.98.28]:46500 "EHLO alexa-out.qualcomm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1582494AbiAYPs7 (ORCPT ); Tue, 25 Jan 2022 10:48:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1643125739; x=1674661739; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=uuU7P40JMh4ZEKpl+/QMPGzxGUUPCLs+4G9cP3BtI2U=; b=f1li3HJFgUxgMB+frFACGtcVeOnZmUUBMgWNcs1Ig0wblm9egzrJl1vX EUEGJjc/7141J5gQDKrLqfVcvc58r0/1yX0M9AaoO/bpuIddcGfkiFuE3 5ZsRxDk9zvmEgIjH5j7c0YUxcPNd0lCEdx8ufwVxhd4oCJPX6muFmpdzI w=; Received: from ironmsg09-lv.qualcomm.com ([10.47.202.153]) by alexa-out.qualcomm.com with ESMTP; 25 Jan 2022 07:48:54 -0800 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg09-lv.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jan 2022 07:48:54 -0800 Received: from nalasex01b.na.qualcomm.com (10.47.209.197) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.19; Tue, 25 Jan 2022 07:48:53 -0800 Received: from [10.216.12.29] (10.80.80.8) by nalasex01b.na.qualcomm.com (10.47.209.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.19; Tue, 25 Jan 2022 07:48:47 -0800 Message-ID: Date: Tue, 25 Jan 2022 21:18:42 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: [PATCH v3] thermal/core: Clear all mitigation when thermal zone is disabled To: "Pandruvada, Srinivas" , "Zhang, Rui" , "thara.gopinath@linaro.org" , "mka@chromium.org" , "daniel.lezcano@linaro.org" , "rafael@kernel.org" , "amitk@kernel.org" CC: "linux-pm@vger.kernel.org" , "linux-kernel@vger.kernel.org" References: <1641581806-32550-1-git-send-email-quic_manafm@quicinc.com> <927aca29-fca7-bdf9-9ad6-2599125ca1b4@linaro.org> From: Manaf Meethalavalappu Pallikunhi In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) To nalasex01b.na.qualcomm.com (10.47.209.197) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org HI Daniel, On 1/24/2022 6:35 AM, Pandruvada, Srinivas wrote: > On Sun, 2022-01-23 at 21:51 +0100, Daniel Lezcano wrote: >> Hi Manaf, >> >> semantically speaking disabling a thermal zone would be to detach the >> thermal zone from its governor and stop the monitoring. >> >> May be add the functions >> >>  - thermal_governor_attach(struct thermal_zone_device *tzd) >>    { >>         ... >>         if (tz->governor && tz->governor->bind_to_tz) { >>                 if (tz->governor->bind_to_tz(tz)) { >>         } >>         ... >>    } >> >>  - thermal_governor_detach(struct thermal_zone_device *tzd) >>    { >>         ... >>         if (tz->governor && tz->governor->unbind_from_tz) >>                 tz->governor->unbind_from_tz(tz); >>         ... >>    } >> >> And add in the step_wise and power_allocator the reset of the >> governor's >> data as well as the cooling device instances in the unbind_from_tz() >> callback >> >> Then, thermal_zone_device_enable() attaches and >> thermal_zone_device_disable() detaches the governor. >> >> Does it make sense ? > This is better. > > Thanks, > Srinivas Yes, it makes sense. I will update it in v4 > >> >> On 07/01/2022 19:56, Manaf Meethalavalappu Pallikunhi wrote: >>> Whenever a thermal zone is in trip violated state, there is a >>> chance >>> that the same thermal zone mode can be disabled either via thermal >>> core API or via thermal zone sysfs. Once it is disabled, the >>> framework >>> bails out any re-evaluation of thermal zone. It leads to a case >>> where >>> if it is already in mitigation state, it will stay the same state >>> until it is re-enabled. >>> >>> To avoid above mentioned issue, on thermal zone disable request >>> reset thermal zone and clear mitigation for each trip explicitly. >>> >>> Signed-off-by: Manaf Meethalavalappu Pallikunhi >>> >>> --- >>>  drivers/thermal/thermal_core.c | 12 ++++++++++-- >>>  1 file changed, 10 insertions(+), 2 deletions(-) >>> >>> diff --git a/drivers/thermal/thermal_core.c >>> b/drivers/thermal/thermal_core.c >>> index 51374f4..e288c82 100644 >>> --- a/drivers/thermal/thermal_core.c >>> +++ b/drivers/thermal/thermal_core.c >>> @@ -447,10 +447,18 @@ static int >>> thermal_zone_device_set_mode(struct thermal_zone_device *tz, >>> >>>         thermal_zone_device_update(tz, THERMAL_EVENT_UNSPECIFIED); >>> >>> -       if (mode == THERMAL_DEVICE_ENABLED) >>> +       if (mode == THERMAL_DEVICE_ENABLED) { >>>                 thermal_notify_tz_enable(tz->id); >>> -       else >>> +       } else { >>> +               int trip; >>> + >>> +               /* make sure all previous throttlings are cleared >>> */ >>> +               thermal_zone_device_init(tz); >>> +               for (trip = 0; trip < tz->trips; trip++) >>> +                       handle_thermal_trip(tz, trip); >>> + >>>                 thermal_notify_tz_disable(tz->id); >>> +       } >>> >>>         return ret; >>>  } >>> >>