From patchwork Sun Dec 6 12:37:53 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Lezcano X-Patchwork-Id: 338820 Delivered-To: patch@linaro.org Received: by 2002:a02:85a7:0:0:0:0:0 with SMTP id d36csp1985079jai; Sun, 6 Dec 2020 04:39:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJyX5CWuJEx04ALoKQYFFHmn0BiZQPP/yWAOljqN5ySRPyl0s8l7nQhLq/8EIbncqKgdC4Fd X-Received: by 2002:a17:906:6404:: with SMTP id d4mr14599810ejm.159.1607258389188; Sun, 06 Dec 2020 04:39:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1607258389; cv=none; d=google.com; s=arc-20160816; b=ls2nKxCBSE/DYo0Fz7yL833pMsNupLMqtGv2mzMBIYxKUQX5p4HtuVmJ3VH/dZ3aWE SX0MvpemqHSj+6tv6uy6stBe4fjijU/ToHQd8jExjsxoLx0AdByz03xTdCtkoUDImQlF h4SFiYCA4pk1EN8qd/pxJwMvzzBD9mNS3tVVwxf6ng44CAUzgE0uSo4CuTyqKZWeEs/M iM59R33BXG04WMnBHwXs5XVHPzKal2ixVxAq3d/Gw1QG07N5FDYWM54w3NpFK2MJC5/q uuBsJycDHHkmNkH7tYaVhYy5BLwpbdGjdqNZS8ufQs1GImFTjYnlgMQuvemcQQSG1X8s IdDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from :dkim-signature; bh=XptJK1kJZCCNiHTchuzcwvQbCAcodgoNqQmzzWdVmdo=; b=MdoEJSHKzcgR+ajc8+2SjXUFLm/2A1Xlz0JTHVAU1Jr2C0SFJWv/82voJiBMkgS9GN J9ZnCqC7CGBO1sgsiVkUSDGeIJRVOz4xmSTpLkhs5v1STNh+Ouk22R+/uUuYKFNTP9OJ 6jfuoZaQxA13k/pOL4RYpm2+G/JqvXf1HOP2i9EPP3pphRLKK0g6XISx7dG0SPNQuv73 klJCxp0VMmyPuriVdpxsSt9/f8mPlX89xqUrQpwuHqcJb4pFNIehewz7eiX3qMCpM+gs H59tkMWQOHqLYYx0PcJmwLk1C0H3Dn9aNIXTTC563ARycZWV0gU7pjbA6T4lvFyB/c3T P1/Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ouYefsCp; spf=pass (google.com: domain of linux-pm-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l11si5798310ejx.183.2020.12.06.04.39.48; Sun, 06 Dec 2020 04:39:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-pm-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=@linaro.org header.s=google header.b=ouYefsCp; spf=pass (google.com: domain of linux-pm-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-pm-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727716AbgLFMim (ORCPT + 8 others); Sun, 6 Dec 2020 07:38:42 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727395AbgLFMim (ORCPT ); Sun, 6 Dec 2020 07:38:42 -0500 Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9F2A3C0613D1 for ; Sun, 6 Dec 2020 04:38:01 -0800 (PST) Received: by mail-wr1-x441.google.com with SMTP id r3so9965200wrt.2 for ; Sun, 06 Dec 2020 04:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=XptJK1kJZCCNiHTchuzcwvQbCAcodgoNqQmzzWdVmdo=; b=ouYefsCpglGL2mE8NfS9LtSfpVgVSRPlT+WOB6HdXcmKvSZok0M4GFXimO6se6kA9W hodFaRZazQrAjhF6hS70NQ2WRCs7YEwxVAWfu3VsF3nlXjx33fN/cicjSFr3VVJM991A d/z3kah1juL0UTPW50/bmF1PDBJxzPzRe3hTbPooPyWASejsaBz3YorhZUJJ0W81Bz8+ 7JP9JnHo8qGugGde35nKeCFGRNrNoHaRAm0RHv3G8BLCvJ65Omx64VO8P3wP9o2zQ88L jtiRrxEaO0BZonhTrxASJivO4CZORkTAR1wzdVq3ttP9udPUxSeabX6XLOILzy2IVxma tDHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=XptJK1kJZCCNiHTchuzcwvQbCAcodgoNqQmzzWdVmdo=; b=J+cAZa28BRpHu0lxyn0naJ5sLvd14qNoAykRhihlrZWXyQciu9/jYXt1EYt34pW2k8 HuVL5fREPYxegdgyyjfMGXEndgjpLTQuEx/fbxp0/t1jnisFehnKn7dqJAxW5N44vhLA Kzt+vo2WGy9MQJz2We4GvaCVvB6saxBogRFdAyQgl2PodT6WvCLrxsv7RFOowliL49cO 5PB2bwz2Xkx7SLIBor24Px6FCQfQAfL+wRFvw6iD+srHAXKwI+Fmr/5zMGhSW06Ce7uH AE8HSWqBtBGrO+Hy9TDn+Q14exZBFBNu8juLuPFcR6K+nQr03l4LQ78hVqlhK3onGvcz ptSg== X-Gm-Message-State: AOAM5311D21hHaAmn1OYaSlwLRLUb4unV1Srtgl3989YpmO9YcVZqh+s xmBz/GwSMwum3W7UJ7uY5Jnn4g== X-Received: by 2002:a5d:4149:: with SMTP id c9mr5777775wrq.271.1607258280111; Sun, 06 Dec 2020 04:38:00 -0800 (PST) Received: from localhost.localdomain (lns-bzn-59-82-252-158-132.adsl.proxad.net. [82.252.158.132]) by smtp.gmail.com with ESMTPSA id l3sm11047356wrr.89.2020.12.06.04.37.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 06 Dec 2020 04:37:59 -0800 (PST) From: Daniel Lezcano To: daniel.lezcano@linaro.org Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Lukasz Luba , Kukjin Kim , Krzysztof Kozlowski , Zhang Rui , Thara Gopinath , Amit Kucheria , Len Brown Subject: [PATCH RFD] thermal: core: Browse the trip points in reverse order and exit Date: Sun, 6 Dec 2020 13:37:53 +0100 Message-Id: <20201206123753.28440-1-daniel.lezcano@linaro.org> X-Mailer: git-send-email 2.17.1 Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org When reading the code it is unclear if the loop is there to handle one trip point or all the trip points above a certain temperature. With the current code, the throttle function is called for every trip point crossed and it is ambiguous if that is made on purpose. Even digging into the history up to April, 16th 2015, the initial git import of the acpi implementation of the loop before being converted into a generic code, it is unclear if all trip points must be handled or not. When the code was intially written, was it assuming there can be only one passive or active trip point ? The cooling effect of the system will be very different depending on how this loop is considered. Even the IPA governor is filtering out multiple trip points to stick to one value. Was the code to accomodate with a bogus loop and based on the multiple non-critical trip points ? Another example: arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi defines 7 passive trip points, each of them mapped to the *same* cooling device but with different min-max states. That means the handle trip points loop will go through all these seven trip points and change the state of the cooling device seven times. On the other hand, a thermal zone can have two different cooling devices mapped to two trip points, shall we consider having both cooling devices acting together when the second trip point is crossed (eg. 1st trip point: cpufreq cooling device + 2nd trip point: fan), or the second cooling device takes over the first one ? IOW, combine the cooling effects or not ? Depending on the expected behavior, the loop can be done in the reverse order and exit after processing the highest trip point. Cc: Lukasz Luba Cc: Kukjin Kim Cc: Krzysztof Kozlowski Cc: Zhang Rui Cc: Thara Gopinath Cc: Amit Kucheria Cc: Len Brown Signed-off-by: Daniel Lezcano --- drivers/thermal/thermal_core.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.17.1 diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c index 9d6a7b7f8ab4..d745b62a63af 100644 --- a/drivers/thermal/thermal_core.c +++ b/drivers/thermal/thermal_core.c @@ -562,8 +562,9 @@ void thermal_zone_device_update(struct thermal_zone_device *tz, tz->notify_event = event; - for (count = 0; count < tz->trips; count++) - handle_thermal_trip(tz, count); + for (count = tz->trips - 1; count >= 0; count--) + if (handle_thermal_trip(tz, count)) + break; monitor_thermal_zone(tz); }