Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp4008964ybg; Tue, 29 Oct 2019 00:21:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqy6WUPPCCrEtFMcAnx/o1meXqxKO6Jvu8j2cjZqk9IrILjKl4S2IVm0+DIdX4LemwzPwd7z X-Received: by 2002:aa7:d852:: with SMTP id f18mr23503181eds.110.1572333717228; Tue, 29 Oct 2019 00:21:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572333717; cv=none; d=google.com; s=arc-20160816; b=d9A/2Al4wI23oMnV/2gFxLlid5WLAaGZMHX9dTlGYpl5ftlGF78zCV1pfIWnLSkcWi r+a4u4QZYwvU1udj7KyJEFpUfW9umvhtywR3bNJcuDj1Z31YEXLxXrbHZyNUhlSWDwep cFQrg3CdOK98L+TRIZfRz9YNJ2mPTHzO5E4xwMtnzlv/GOmpKzNrn19yhUbzPYQbJDf8 O+q6KKpkrN7KZ49H9msOMtHf+W9vIXEGdhmTJC8clhQARflR3eK0ShDNmgbf1CkoskZT kfIAEZuetNQk+hD/BMQmD0QEIZW9RogvEj5eCMO3BNymqhj4Te1O8Ehr9OWV6pkiz+qZ CmPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=cUdKKEZxRPnFHu2QVFPMIhJT0tZzKagr6VomA8Jxo6Y=; b=SwfGxG0XmqIrKvaR47Devc7APAc4qDDHbrtD68z1flvBNfNP04IMZ6oGKKTEYt5/F0 Q8Y22OxP2LFqLuEf0Os7rAXy9cNKGLqMhSr2zGYEuuloVEF5p9jGDUK8+KhpXIH7Bspb FPrYGen1Qr0hpwjEsR1FYoEVwQpcrGp13xxlIR+z6jDDQVMG+x8ugxjDXDnvVJhH5Csv uKe+k5Faha3mKAHMEDTmu8vjXcZr0YKycVCpgKKEY0DJZktc/OVgshr6CZrWYbGR9UCK q43VidM0aiBpCnvu/nh1MYuTzhCEWnXSlycRKCMjfjwg6M+Kn3Bv30TBRjSodbV7z1J9 jPSQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id qc9si7848420ejb.265.2019.10.29.00.21.33; Tue, 29 Oct 2019 00:21:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729427AbfJ2Bgu (ORCPT + 99 others); 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-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: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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