Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp253691pxu; Wed, 7 Oct 2020 02:05:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxcyWa/QHoB4LSmJF/yOv4At5Jxu8oIBTrjNnMI0f0igAvMNpV8LwOnPCATADPV83f6oXj2 X-Received: by 2002:a05:6402:c12:: with SMTP id co18mr2527386edb.162.1602061533161; Wed, 07 Oct 2020 02:05:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602061533; cv=none; d=google.com; s=arc-20160816; b=dYSV6JVykRRbxZ5/NuVa9BoJK4AHtk5gku8GGH6Qt9UW2urFA4h1T1jPwb/JmYb5fe K+v7yPDLJlb6B8rXs+E1QzT6ep1Mb/a+jT0dJMrL97rRf0rTO9kiqGxjH60bnLMlUdI0 aI5/De7sbHk4gMDPV67UD90glJtU9M+ql1JX4XsY909RBjPQtAS7UPtuRESGiJ2n+79B XfeZd853xbVA6DkNdq09UuE8+LE91tgITDhddBBdQ6+k+0RPOY/YY2ycPqqAP1rn+Bdj qXHoNEcI55TcuLtciMRD6thQMhOaiOjvJtaIdPPhZvbjHIt6xjKeEM7zuFrGTshVb1FK 49Xw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=SL/5CAd4U1o/QJLLDYvUSn6bK2bMcW7zLNA0OwWni6A=; b=T/joX30BAEI14yQW8wT/ogLyU/aCb2+mJ/9Nyua/l2NpTm9/npNLtaaK4YeO8s/v77 lDKNAwK4Bswr5HU7KQUesL5eINouI1s6j4HYpp2WO481H9/x6nMY5kpCm8YWBOPx93tS bATBJgpsQDckczRm720vex7hzKKj36WopAs8m/E7wR+EvacxkFqUvBuEML/bb1+SAqaj +AM6oFXv82kaANgOFZItzsPfDz6pfNaf0aWAyx6WTZTA1qFMqKHHDmet8cu1qdhIlros tmunlxQcSJiwJeCwV7um2d69xiZApLUA0DtcFkYjOjLsns68RN2OQB+UHgPTODaLdTcK vJMA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t17si996823eje.331.2020.10.07.02.05.01; Wed, 07 Oct 2020 02:05:33 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726463AbgJGJDj (ORCPT + 99 others); Wed, 7 Oct 2020 05:03:39 -0400 Received: from foss.arm.com ([217.140.110.172]:40512 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726269AbgJGJDi (ORCPT ); Wed, 7 Oct 2020 05:03:38 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 887C0113E; Wed, 7 Oct 2020 02:03:37 -0700 (PDT) Received: from [10.57.52.96] (unknown [10.57.52.96]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7C9A63F71F; Wed, 7 Oct 2020 02:03:34 -0700 (PDT) Subject: Re: [PATCH v2 3/3] dt-bindings: thermal: update sustainable-power with abstract scale To: Doug Anderson Cc: LKML , Linux PM , linux-doc@vger.kernel.org, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Rob Herring , amitk@kernel.org, Jonathan Corbet , Daniel Lezcano , Dietmar.Eggemann@arm.com, Quentin Perret , Matthias Kaehlcke , Rajendra Nayak , "Rafael J. Wysocki" References: <20201002114426.31277-1-lukasz.luba@arm.com> <20201002114426.31277-4-lukasz.luba@arm.com> From: Lukasz Luba Message-ID: Date: Wed, 7 Oct 2020 10:03:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Doug, On 10/2/20 4:47 PM, Doug Anderson wrote: > Hi, > > On Fri, Oct 2, 2020 at 8:13 AM Lukasz Luba wrote: >> >> Hi Doug, >> >> On 10/2/20 3:31 PM, Doug Anderson wrote: >>> Hi, >>> >>> On Fri, Oct 2, 2020 at 4:45 AM Lukasz Luba wrote: >>>> >>>> Update the documentation for the binding 'sustainable-power' and allow >>>> to provide values in an abstract scale. It is required when the cooling >>>> devices use an abstract scale for their power values. >>>> >>>> Signed-off-by: Lukasz Luba >>>> --- >>>> .../devicetree/bindings/thermal/thermal-zones.yaml | 13 +++++++++---- >>>> 1 file changed, 9 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml >>>> index 3ec9cc87ec50..4d8f2e37d1e6 100644 >>>> --- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml >>>> +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml >>>> @@ -99,10 +99,15 @@ patternProperties: >>>> sustainable-power: >>>> $ref: /schemas/types.yaml#/definitions/uint32 >>>> description: >>>> - An estimate of the sustainable power (in mW) that this thermal zone >>>> - can dissipate at the desired control temperature. For reference, the >>>> - sustainable power of a 4-inch phone is typically 2000mW, while on a >>>> - 10-inch tablet is around 4500mW. >>>> + An estimate of the sustainable power (in mW or in an abstract scale) >>>> + that this thermal zone can dissipate at the desired control >>>> + temperature. For reference, the sustainable power of a 4-inch phone >>>> + is typically 2000mW, while on a 10-inch tablet is around 4500mW. >>>> + >>>> + It is possible to express the sustainable power in an abstract >>>> + scale. This is the case when the related cooling devices use also >>>> + abstract scale to express their power usage. The scale must be >>>> + consistent. >>> >>> Two thoughts: >>> >>> 1. If we're going to allow "sustainable-power" to be in abstract >>> scale, why not allow "dynamic-power-coefficient" to be in abstract >>> scale too? I assume that the whole reason against that originally was >>> the idea of device tree purity, but if we're allowing the abstract >>> scale here then there seems no reason not to allow it for >>> "dynamic-power-coefficient". >> >> With this binding it's a bit more tricky. >> I also have to discuss a few things internally. This requirement of >> uW/MHz/V^2 makes the code easier also for potential drivers >> like GPU (which are going to register the devfreq cooling with EM). >> >> Let me think about it, but for now I would just update these bits. >> These are required to proper IPA operation, the dyn.-pow.-coef. is a >> nice to have and possible next step. > > I guess the problem is that Rajendra is currently planning to remove > all the "dynamic-power-coefficient" values from device tree right now > and move them to the source code because the numbers we currently have > in the device tree _are_ in abstract scale and thus violate the > bindings. Moving this to source code won't help us get to more real > power numbers (since it'll still be abstract scale), it'll just be > pure churn. If we're OK with the abstract scale in general then we > should allow it everywhere and not add churn for no reason. > > I just want to notify you that I had internal conversation about this 'dynamic-power-coefficient' binding and abstract scale. We would change it as well, similarly to 'sustainable-power'. It must pass internal review and I will send the v3 of this series. Regards, Lukasz