From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A19B9C43219 for ; Tue, 8 Feb 2022 01:07:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229522AbiBHBGn (ORCPT ); Mon, 7 Feb 2022 20:06:43 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1344256AbiBHAu1 (ORCPT ); Mon, 7 Feb 2022 19:50:27 -0500 Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8026FC0612A4 for ; Mon, 7 Feb 2022 16:50:25 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id i17so15967379pfq.13 for ; Mon, 07 Feb 2022 16:50:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=P4dVbEFdi/JUsP7B7tBGXHD+ETv7S+cY00xBr/7Gj+s=; b=kcpKAm4jzm1OsPMjGPrgkbvJS/LbWlj2YvFZdqf3Okn+ptsEFxEPILhJ07fEaQkCCS fxKQWER27n8E8CWkUIbx2aQ6znFoabJ/UgYrpQI0jgKeRF+9vG+j9s42cFGBK1Br/g0t qGS/Ay3ZMQcH6ko2T/B3L9IaD3Q8qDzeltD0s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=P4dVbEFdi/JUsP7B7tBGXHD+ETv7S+cY00xBr/7Gj+s=; b=Z4e5WBrHp1eQPJW22DZXSTtYcghlipYhxzlZJ774DMdLGPw7BBT+KZZDD+J26u46Ee t0p73kaBCXLPTcGArpbyklj5MS+seDevZ64N2ETkLkdR1ty9GihHsGYLTjHdAQ7DZNWG 3nUsqIE/iUBy2poAb/J1yFnCdz6cxdHJbS8R+ZOXnkI9rN7q7p7I2dhP2LFQvVapudA1 YrgpzFS81ubpRj9FQi+bpwyXJz59HIySsey6VzNtgwLom6QfqzfPXJmDwPzVpdxkKI4v RzPTcXsqE2YGkpggn+buVx59kEWz/HILryJlRsYlv2FM4y6U5THhAGqqIfA4vbCGUVSr u0kQ== X-Gm-Message-State: AOAM530jrgPrLparDO8agsYjPj5YuKOtrWt0IsPVwPaHyTcEaFRRn7HT meHSmLfYXQhZB2lfQcx+aZUWjQ== X-Google-Smtp-Source: ABdhPJyOItaFwB1a6V9pdWDOozh78FaEp+dooWqUDO7ZAS63J5y1+pQX1elO5BGpl/iyCEDyedzaaw== X-Received: by 2002:a05:6a00:1486:: with SMTP id v6mr1932729pfu.73.1644281424964; Mon, 07 Feb 2022 16:50:24 -0800 (PST) Received: from localhost ([2620:15c:202:201:45cc:a522:8718:fc78]) by smtp.gmail.com with UTF8SMTPSA id nv13sm515627pjb.18.2022.02.07.16.50.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Feb 2022 16:50:24 -0800 (PST) Date: Mon, 7 Feb 2022 16:50:22 -0800 From: Matthias Kaehlcke To: Lukasz Luba Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, amit.kachhap@gmail.com, daniel.lezcano@linaro.org, viresh.kumar@linaro.org, rafael@kernel.org, amitk@kernel.org, rui.zhang@intel.com, dietmar.eggemann@arm.com, Pierre.Gondois@arm.com, Douglas Anderson , Stephen Boyd , Rajendra Nayak , Bjorn Andersson Subject: Re: [PATCH 1/2] thermal: cooling: Check Energy Model type in cpufreq_cooling and devfreq_cooling Message-ID: References: <20220207073036.14901-1-lukasz.luba@arm.com> <20220207073036.14901-2-lukasz.luba@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220207073036.14901-2-lukasz.luba@arm.com> Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Mon, Feb 07, 2022 at 07:30:35AM +0000, Lukasz Luba wrote: > The Energy Model supports power values either in Watts or in some abstract > scale. When the 2nd option is in use, the thermal governor IPA should not > be allowed to operate, since the relation between cooling devices is not > properly defined. Thus, it might be possible that big GPU has lower power > values in abstract scale than a Little CPU. To mitigate a misbehaviour > of the thermal control algorithm, simply not register a cooling device > capable of working with IPA. Ugh, this would break thermal throttling for existing devices that are currently supported in the upstream kernel. Wasn't the conclusion that it is the responsability of the device tree owners to ensure that cooling devices with different scales aren't used in the same thermal zone? That's also what's currently specified in the power allocator documentation: Another important thing is the consistent scale of the power values provided by the cooling devices. All of the cooling devices in a single thermal zone should have power values reported either in milli-Watts or scaled to the same 'abstract scale'. Which was actually added by yourself: commit 5a64f775691647c242aa40d34f3512e7b179a921 Author: Lukasz Luba Date: Tue Nov 3 09:05:58 2020 +0000 PM: EM: Clarify abstract scale usage for power values in Energy Model The Energy Model (EM) can store power values in milli-Watts or in abstract scale. This might cause issues in the subsystems which use the EM for estimating the device power, such as: - mixing of different scales in a subsystem which uses multiple (cooling) devices (e.g. thermal Intelligent Power Allocation (IPA)) - assuming that energy [milli-Joules] can be derived from the EM power values which might not be possible since the power scale doesn't have to be in milli-Watts To avoid misconfiguration add the requisite documentation to the EM and related subsystems: EAS and IPA. Signed-off-by: Lukasz Luba Signed-off-by: Rafael J. Wysocki It's ugly to have the abstract scales in the first place, but that's unfortunately what we currently have for at least some cooling devices. IMO it would be preferable to stick to catching incompliant configurations in reviews, rather than breaking thermal throttling for existing devices with configurations that comply with the current documentation.