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 X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED 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 33392C4363D for ; Fri, 2 Oct 2020 15:48:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CC71420795 for ; Fri, 2 Oct 2020 15:48:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="NOBFHu51" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388030AbgJBPsM (ORCPT ); Fri, 2 Oct 2020 11:48:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38456 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387692AbgJBPsL (ORCPT ); Fri, 2 Oct 2020 11:48:11 -0400 Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 33F49C0613E2 for ; Fri, 2 Oct 2020 08:48:10 -0700 (PDT) Received: by mail-vs1-xe43.google.com with SMTP id y194so856181vsc.4 for ; Fri, 02 Oct 2020 08:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T1VBeMl6lnk6uGVYC4UMbcUFzllZv34qpogDPSQOP7M=; b=NOBFHu51EDHrcub6xy7AvFiSRurn1fHm20p6heYCzLvQA4DiSWLmItq04o64PqKZJL ON7UOtMwm7wOsHDwKznnfPF3yO5akXtBqmhN2CLd4iY6ZkbJCnZj4n4pPLQQJutstBul NQGnGObIukRPoeNo1cN9Buh0HQPiZDPQomocE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=T1VBeMl6lnk6uGVYC4UMbcUFzllZv34qpogDPSQOP7M=; b=CfwcSNAMR+eXG+HN5h2944GdGwA3AqM2HKVONqjihrdedIIHxsUmvdOfrbr9yGS2wG lSqXYnXxArLErJ5jUshkjifCMSTQGn1vmMnHiRv4jVT7PADdCLwwULvxOZaY49INVUoF znQlejRUfMJwxZN0jMtpul8+ShKJa0Hhjs6eTPG0vy20403tCYVom5SNM1qWBQk6ABtK NSg6Tq4e+5Z7BpyDO9bfnQ177LiMs6DeonLfTn0K48CD7PBDLbaQIdoFHki2+6n5V7kV CtQmyiK4eVxJ9d6Um2PhyGkCis+YJ74q4JP5ZGqzPrH6b5hRvKK86O4LVKPyABSFq8aG VskQ== X-Gm-Message-State: AOAM533E6fA34Huwpa6qWKkHdkGN3spq6WIi031wW4JH3yxBncvzWlGJ 7mvhqwmp6XBjgOcjjZgPkl6i5qNCy3beXA== X-Google-Smtp-Source: ABdhPJzBwUygkukA9t135DlKXnSDsnAJV+yqZvnrwWELfDlB70wefCXaj0DPWHwxho+enqSjtx6BMA== X-Received: by 2002:a67:f4c2:: with SMTP id s2mr1578226vsn.3.1601653688949; Fri, 02 Oct 2020 08:48:08 -0700 (PDT) Received: from mail-vk1-f181.google.com (mail-vk1-f181.google.com. [209.85.221.181]) by smtp.gmail.com with ESMTPSA id s8sm293908vke.48.2020.10.02.08.48.07 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 02 Oct 2020 08:48:08 -0700 (PDT) Received: by mail-vk1-f181.google.com with SMTP id n193so381357vkf.12 for ; Fri, 02 Oct 2020 08:48:07 -0700 (PDT) X-Received: by 2002:a1f:a905:: with SMTP id s5mr1631052vke.9.1601653687217; Fri, 02 Oct 2020 08:48:07 -0700 (PDT) MIME-Version: 1.0 References: <20201002114426.31277-1-lukasz.luba@arm.com> <20201002114426.31277-4-lukasz.luba@arm.com> In-Reply-To: From: Doug Anderson Date: Fri, 2 Oct 2020 08:47:55 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 3/3] dt-bindings: thermal: update sustainable-power with abstract scale To: Lukasz Luba 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" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org 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. > > 2. Is it worth adding some type of indication of what type of units > > "sustainable-power" is represented in? Maybe even a made up unit so > > that you could tell the difference between made up units in the same > > system? I'd envision something like: > > > > sustainable-power-units = "qualcomm,sc7180-bogoWatts" > > > > ...and on the dynamic-power-coefficient side, the same: > > > > dynamic-power-coefficient-units = "qualcomm,sc7180-bogoWatts" > > > > One could imagine someone even later (after devices are widely > > distributed) figuring out translations between these bogoWatts numbers > > and real Watts if someone could come up with a case where it matters. > > To figure this out we don't need a new binding. > I think a simple comment in the DT would be enough for this, even e.g.: > > sustainable-power = <100> /* bogoWatts */ There are some important differences: a) Your comment is gone when the device tree is compiled. If we actually add a string to the device tree then, in theory, we can add conversions in code (without touching the device tree) down the road. b) I believe there can be more than one abstract scale present in a single device tree, at least in theory. Adding a string allows you to know if you're comparing apples to apples or apples to organges. > Thank you for your comments. > BTW, I haven't put your 'Reviewed-by' because I have added this > sustainable-power new stuff in patch 1/3. I will grateful if you > have a look on that. I can if needed, but I'd kinda like to get the above resolved first since it feels like it could have an effect on the other patches? -Doug