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=-8.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 9F6D6CA9EC0 for ; Tue, 29 Oct 2019 01:36:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 69C6F20717 for ; Tue, 29 Oct 2019 01:36:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572313014; bh=UXJEiwLQLFYO5y3BIbyUux/VbYsr8k7i4t2/5U+zFS4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=u1Oplm1eC/qVTRv8dd+uK2GRFV/qbizOKUDb6kUOLJAp/J9b2JoVoRiYVSHhWxvje iwLFNqbBePVwqJBH5agmEmw6BGgs6ulaLTWAgGbjaJ5oJtUu+Gt4ztLxIEc0dkoZKZ OHSWfVXH33kSdbus1taa4r4HHNAaRtftz+em3Hi0= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728000AbfJ2Bgu (ORCPT ); Mon, 28 Oct 2019 21:36:50 -0400 Received: from mail-ot1-f67.google.com ([209.85.210.67]:34657 "EHLO mail-ot1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727703AbfJ2Bgu (ORCPT ); Mon, 28 Oct 2019 21:36:50 -0400 Received: by mail-ot1-f67.google.com with SMTP id m19so8432328otp.1; Mon, 28 Oct 2019 18:36:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=cUdKKEZxRPnFHu2QVFPMIhJT0tZzKagr6VomA8Jxo6Y=; b=RF8uAzXmfQbjN12wUWCrpaKS4OJClaip3oXx0EohDaWN5vPfUgWq/6ebBWU+JQ0giA R9dyBFFU9FirWgOjoFYvCnZdEPemQ+54XbAkEtdUKE7+Lp8xYkJm1vMLBck65l/ANzGE iEWSXop7qAKBXFMysDhcS3pkfIFtAgT1MA62t296QUI8PcMY4r+w6bxkZgZB9wPzXHi2 Jvcr5OPokbVjHkI/ziWjfiXDN2cFduH9utiq77SMBICiws+WDNImnYWqX/WPuyNQ2Kia HWVUZY9fKseQbq6H+UCHgLDBvTGmi3g8KGfpagq6fM3WRlA+gpq+QFGHX0lSwWDdJntL SG2A== X-Gm-Message-State: APjAAAXIldZGjYqKVl79gfsDkjixAkqhLlwMgAHiPDI1I+oBAflOBMfd O6fbh8f6lD5rmwmuYEcPBQ== X-Google-Smtp-Source: APXvYqwxn84pDfRZOnEp1z2t14ueJoGhKjtzuewBpLvrfQbeO2MKZOGKV9rs31NSOa3Nb7V+31MQrg== X-Received: by 2002:a9d:620c:: with SMTP id g12mr6225748otj.11.1572313009351; Mon, 28 Oct 2019 18:36:49 -0700 (PDT) Received: from localhost (24-155-109-49.dyn.grandenetworks.net. [24.155.109.49]) by smtp.gmail.com with ESMTPSA id s3sm3377053otq.76.2019.10.28.18.36.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Oct 2019 18:36:48 -0700 (PDT) Date: Mon, 28 Oct 2019 20:36:48 -0500 From: Rob Herring To: Thara Gopinath Cc: Ulf Hansson , Eduardo Valentin , Zhang Rui , Daniel Lezcano , Bjorn Andersson , Andy Gross , amit.kucheria@verdurent.com, Mark Rutland , "Rafael J. Wysocki" , Linux PM , DTML , linux-arm-msm , Linux Kernel Mailing List Subject: Re: [PATCH v3 6/7] dt-bindings: soc: qcom: Extend RPMh power controller binding to describe thermal warming device Message-ID: <20191029013648.GB27045@bogus> References: <1571254641-13626-1-git-send-email-thara.gopinath@linaro.org> <1571254641-13626-7-git-send-email-thara.gopinath@linaro.org> <5DA88892.5000408@linaro.org> <5DA89267.30806@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5DA89267.30806@linaro.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Thu, Oct 17, 2019 at 12:10:15PM -0400, Thara Gopinath wrote: > On 10/17/2019 11:43 AM, Ulf Hansson wrote: > > On Thu, 17 Oct 2019 at 17:28, Thara Gopinath wrote: > >> > >> Hello Ulf, > >> Thanks for the review! > >> > >> On 10/17/2019 05:04 AM, Ulf Hansson wrote: > >>> On Wed, 16 Oct 2019 at 21:37, Thara Gopinath wrote: > >>>> > >>>> RPMh power controller hosts mx domain that can be used as thermal > >>>> warming device. Add a sub-node to specify this. > >>>> > >>>> Signed-off-by: Thara Gopinath > >>>> --- > >>>> Documentation/devicetree/bindings/power/qcom,rpmpd.txt | 10 ++++++++++ > >>>> 1 file changed, 10 insertions(+) > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt > >>>> index eb35b22..fff695d 100644 > >>>> --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.txt > >>>> +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.txt > >>>> @@ -18,6 +18,16 @@ Required Properties: > >>>> Refer to for the level values for > >>>> various OPPs for different platforms as well as Power domain indexes > >>>> > >>>> += SUBNODES > >>>> +RPMh alsp hosts power domains that can behave as thermal warming device. > >>>> +These are expressed as subnodes of the RPMh. The name of the node is used > >>>> +to identify the power domain and must therefor be "mx". > >>>> + > >>>> +- #cooling-cells: > >>>> + Usage: optional > >>>> + Value type: > >>>> + Definition: must be 2 > >>>> + > >>> > >>> Just wanted to express a minor thought about this. In general we use > >>> subnodes of PM domain providers to represent the topology of PM > >>> domains (subdomains), this is something different, which I guess is > >>> fine. > >>> > >>> I assume the #cooling-cells is here tells us this is not a PM domain > >>> provider, but a "cooling device provider"? > >> Yep. > >>> > >>> Also, I wonder if it would be fine to specify "power-domains" here, > >>> rather than using "name" as I think that is kind of awkward!? > >> Do you mean "power-domain-names" ? I am using this to match against the > >> genpd names defined in the provider driver. > > > > No. If you are using "power-domains" it means that you allow to > > describe the specifier for the provider. > Yep. But won't this look funny in DT ? The provider node will have a sub > node with a power domain referencing to itself Like below: Is this ok ? > > rpmhpd: power-controller { > compatible = "qcom,sdm845-rpmhpd"; > #power-domain-cells = <1>; > > ... > ... > mx_cdev: mx { > #cooling-cells = <2>; > power-domains = <&rpmhpd SDM845_MX>; > }; > The whole concept here seems all wrong to me. Isn't it what's in the power domain that's the cooling device. A CPU power domain is not a cooling device, the CPU is. Or we wouldn't make a clock a cooling device, but what the clock drives. Rob