From patchwork Fri Jan 10 10:16:05 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pascal Paillet X-Patchwork-Id: 213071 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34868C3F68F for ; Fri, 10 Jan 2020 10:16:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0814E20880 for ; Fri, 10 Jan 2020 10:16:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=st.com header.i=@st.com header.b="zpzL2mKR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727588AbgAJKQh (ORCPT ); Fri, 10 Jan 2020 05:16:37 -0500 Received: from mx07-00178001.pphosted.com ([62.209.51.94]:23052 "EHLO mx07-00178001.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727452AbgAJKQg (ORCPT ); Fri, 10 Jan 2020 05:16:36 -0500 Received: from pps.filterd (m0046668.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 00AAE3Yq031197; Fri, 10 Jan 2020 11:16:18 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=st.com; h=from : to : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=STMicroelectronics; bh=AAD/GToJl17SoA/ncPjv8bRydogH2ZBtCfUpPZ40ub0=; b=zpzL2mKRX3XGn9bOo1I7gmQD4k8aW36S5+loLQuhg/U2FX8Zy9tx3LU9PvGDkccAfS3L nMQyx8AO/LbrSHjrFvlp8s5SWocc15VluEjiN6j9OZM5WHGW81paA0Qtd4pUuiCn188w ZPsF7j0IWLJgh3SYnzlfDisKc0MG/+p6WSOnaHQNUpn0w+iEA2fiSm9dkvQowp1/1rMs GG6k3bPmUujVOdYPXcrvMOJhCC9cxc1lehVrKdV1k/GqRSZ7Krj9aCTtpBXy5kGcMs5t iSZR1hTQRBc1OphTho7YI3NKeg8ouiv6/FYHeH+pDuu/ky3AtbrGiWWtD47VNKC6eXoA 7g== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com with ESMTP id 2xepyt83ft-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Jan 2020 11:16:18 +0100 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id BFA92100038; Fri, 10 Jan 2020 11:16:12 +0100 (CET) Received: from Webmail-eu.st.com (sfhdag6node2.st.com [10.75.127.17]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id B1AFE2A7907; Fri, 10 Jan 2020 11:16:12 +0100 (CET) Received: from localhost (10.75.127.45) by SFHDAG6NODE2.st.com (10.75.127.17) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 10 Jan 2020 11:16:12 +0100 From: Pascal Paillet To: , , , , , , , , , , , , , Subject: [PATCH_V3 6/6] thermal: stm32: fix low threshold interrupt flood Date: Fri, 10 Jan 2020 11:16:05 +0100 Message-ID: <20200110101605.24984-7-p.paillet@st.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20200110101605.24984-1-p.paillet@st.com> References: <20200110101605.24984-1-p.paillet@st.com> MIME-Version: 1.0 X-Originating-IP: [10.75.127.45] X-ClientProxiedBy: SFHDAG5NODE1.st.com (10.75.127.13) To SFHDAG6NODE2.st.com (10.75.127.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-01-10_01:2020-01-10,2020-01-09 signatures=0 Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org With the STM32 thermal peripheral, it is not possible to dump the temperature that has caused the interrupt. When the temperature reaches the low threshold, we generally read a temperature that is a little bit higher than the low threshold. This maybe due to sampling precision, and also because the CPU becomes hotter when it quits WFI mode. In that case, the framework does not change the trip points. This leads to a lot of low threshold interrupts. The fix is to set the low threshold value 0.5 degrees Celsius below the actual request. The problem is not so frequent with the high threshold and it would no be a good idea to set the threshold value higher than the request. Signed-off-by: Pascal Paillet --- drivers/thermal/st/stm_thermal.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/thermal/st/stm_thermal.c b/drivers/thermal/st/stm_thermal.c index aaf25ca2f118..1cc5e6c5709e 100644 --- a/drivers/thermal/st/stm_thermal.c +++ b/drivers/thermal/st/stm_thermal.c @@ -321,7 +321,8 @@ static int stm_thermal_set_trips(void *data, int low, int high) if (low > -INT_MAX) { sensor->low_temp_enabled = 1; - ret = stm_thermal_calculate_threshold(sensor, low, &th); + /* add 0.5 of hysteresis due to measurement error */ + ret = stm_thermal_calculate_threshold(sensor, low - 500, &th); if (ret) return ret;