Message ID | 20221104142204.156333-2-angelogioacchino.delregno@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp435889wru; Fri, 4 Nov 2022 07:26:08 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5joGDkpsTmw54jF/v4DOHGACnLswjtkKSxRXNqHM3E80jOL39QIgqfJr/Sw7rPWsl9QITr X-Received: by 2002:a05:6402:5510:b0:459:5ea:9bc0 with SMTP id fi16-20020a056402551000b0045905ea9bc0mr9329962edb.152.1667571968519; Fri, 04 Nov 2022 07:26:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667571968; cv=none; d=google.com; s=arc-20160816; b=ZZGADl3RQWXXHn1hvI8lnv9rvn/VzGlVmHmbOAd08r6FV2PGJ9E1nS8sB86Tz9Iqza iW1Ycyohvp+yhkGVQyTvAZ7ZaMCTpdYXEnoY/f2R5muGCyWdbNYVZI16CnTGVWx7svB6 BFe19zVXbs9SI0vEbvDsuWZzFlpVyrBCeWO6C0K2dwIAY0cXbRCTd3D4i8Mg6Fv8TOHd rXtgD61X00Aeo/jrE6VWGgqTyqwkb3KUllQeG5JBMVsbSJMcm6XtK/UYDKYKy7LAwdyj WjuNDQ9pSf97IOS999DXd7EfYESU6irwyPTRCSZi0g9mS9/bICgzYrMtyz7KZqmd6E4a HJ5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=f8S3OSINsr7LjO9InCdLqczqCuD62DYIOZ5AL8G2Mk4=; b=XRmd8ABnmukpTMulsRi1p8sd5iL50Z0zqtMH7FzYo+chn50NeM7SOKevOa4lHAMaYd 9F90uKA3pGU9nBg7mpgJPvxFy7hIamTKXQx92b9zkwGNUl+YVN9o5FQuFzcym2DHxQ8z ZdqC7uKciTQAbeFJWWWD9e3X8z8Qa9oumtQcknZZOzQtFvkzXgAhHFllxmQ6nlhAWH3j gtaqgfge0ZyXUxwmwzcoKxm5EXe0rFVlfiFu0zsbds83ghJuskriwtCU6MDHnSfGlTJp Ci0rtMH9c4juRq9rxHDtlnIbR/5LWkzve+HBr5IyQgggFM+UNE4+4yiVbSYjbB4o+Pfq V56w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=Dp9gbgxE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v18-20020a1709061dd200b007803e371aedsi3813646ejh.161.2022.11.04.07.25.44; Fri, 04 Nov 2022 07:26:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=Dp9gbgxE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231975AbiKDOYR (ORCPT <rfc822;jimliu8233@gmail.com> + 99 others); Fri, 4 Nov 2022 10:24:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35064 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231920AbiKDOXw (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 4 Nov 2022 10:23:52 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AB77131340; Fri, 4 Nov 2022 07:22:18 -0700 (PDT) Received: from IcarusMOD.eternityproject.eu (2-237-20-237.ip236.fastwebnet.it [2.237.20.237]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madras.collabora.co.uk (Postfix) with ESMTPSA id CF3236600012; Fri, 4 Nov 2022 14:22:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1667571731; bh=qq6t8J/Ig42IfaE17J6TD3ULijHyJbRhy0OgubwHt8w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Dp9gbgxEE+SHXO+zz8iYwlnpnlblfS333c17CMM3wi2zQfOO5Le+UizE8cDwEr+4A JfCjec8JvSurLNZ939kZ12ISE+o8tJQ6cvLQ/mq+nHrthIi8u6Bwr7oTYvHnf5zs3v ReRKjnNyPTL0555DjreRG5fSkcfq61Fc87SFizzvYM++SnI54Hcpv9XpJbzGslCrPf i0EYRfl2yNYdIKhpTfWEYGhueZXjZXFyzqbgX4fpNoqdtZNCkIYrPGH9sKYd+HngMo 1KwRoOkuXV4psuSl2srspQgNPDGW0RD8UM/lwCpSrv686ES56OdFkTqLqhxmp5pE8o rmy+YP2YOJ5TA== From: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> To: agross@kernel.org Cc: andersson@kernel.org, konrad.dybcio@somainline.org, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, angelogioacchino.delregno@collabora.com, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, marijn.suijten@somainline.org, kernel@collabora.com Subject: [PATCH v2 1/2] dt-bindings: soc: qcom: Add bindings for Qualcomm Ramp Controller Date: Fri, 4 Nov 2022 15:22:03 +0100 Message-Id: <20221104142204.156333-2-angelogioacchino.delregno@collabora.com> X-Mailer: git-send-email 2.37.2 In-Reply-To: <20221104142204.156333-1-angelogioacchino.delregno@collabora.com> References: <20221104142204.156333-1-angelogioacchino.delregno@collabora.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1748575944342875519?= X-GMAIL-MSGID: =?utf-8?q?1748575944342875519?= |
Series |
Qualcomm Ramp Controller and MSM8976 config
|
|
Commit Message
AngeloGioacchino Del Regno
Nov. 4, 2022, 2:22 p.m. UTC
Document bindings for the Qualcomm Ramp Controller, found on various
legacy Qualcomm SoCs.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../qcom/qcom,msm8976-ramp-controller.yaml | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml
Comments
On 04/11/2022 10:22, AngeloGioacchino Del Regno wrote: > Document bindings for the Qualcomm Ramp Controller, found on various > legacy Qualcomm SoCs. Subject: drop second "bindings" word. One in prefix (dt-bindings) is enough. > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- With above: Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
On Fri, 04 Nov 2022 15:22:03 +0100, AngeloGioacchino Del Regno wrote: > Document bindings for the Qualcomm Ramp Controller, found on various > legacy Qualcomm SoCs. > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > .../qcom/qcom,msm8976-ramp-controller.yaml | 37 +++++++++++++++++++ > 1 file changed, 37 insertions(+) > create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: dtschema/dtc warnings/errors: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.example.dtb: power-controller@b014000: '#power-domain-cells' is a required property From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/power-domain.yaml doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/patch/ This check can fail if there are any dependencies. The base for a patch series is generally the most recent rc1. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit.
Il 04/11/22 18:54, Rob Herring ha scritto: > > On Fri, 04 Nov 2022 15:22:03 +0100, AngeloGioacchino Del Regno wrote: >> Document bindings for the Qualcomm Ramp Controller, found on various >> legacy Qualcomm SoCs. >> >> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> >> --- >> .../qcom/qcom,msm8976-ramp-controller.yaml | 37 +++++++++++++++++++ >> 1 file changed, 37 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml >> > > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' > on your patch (DT_CHECKER_FLAGS is new in v5.13): > > yamllint warnings/errors: > > dtschema/dtc warnings/errors: > /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.example.dtb: power-controller@b014000: '#power-domain-cells' is a required property > From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/power-domain.yaml > > doc reference errors (make refcheckdocs): > > See https://patchwork.ozlabs.org/patch/ > > This check can fail if there are any dependencies. The base for a patch > series is generally the most recent rc1. > > If you already ran 'make dt_binding_check' and didn't see the above > error(s), then make sure 'yamllint' is installed and dt-schema is up to > date: > > pip3 install dtschema --upgrade > > Please check and re-submit. > I'm unsure about what I should do about this one. This is a power-controller, but does *not* need any #power-domain-cells, as it is standalone and doesn't require being attached to anything. Any hints? Thanks, Angelo
On 11/11/2022 11:05, AngeloGioacchino Del Regno wrote: > Il 04/11/22 18:54, Rob Herring ha scritto: >> >> On Fri, 04 Nov 2022 15:22:03 +0100, AngeloGioacchino Del Regno wrote: >>> Document bindings for the Qualcomm Ramp Controller, found on various >>> legacy Qualcomm SoCs. >>> >>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> >>> --- >>> .../qcom/qcom,msm8976-ramp-controller.yaml | 37 +++++++++++++++++++ >>> 1 file changed, 37 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml >>> >> >> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' >> on your patch (DT_CHECKER_FLAGS is new in v5.13): >> >> yamllint warnings/errors: >> >> dtschema/dtc warnings/errors: >> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.example.dtb: power-controller@b014000: '#power-domain-cells' is a required property >> From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/power-domain.yaml >> >> doc reference errors (make refcheckdocs): >> >> See https://patchwork.ozlabs.org/patch/ >> >> This check can fail if there are any dependencies. The base for a patch >> series is generally the most recent rc1. >> >> If you already ran 'make dt_binding_check' and didn't see the above >> error(s), then make sure 'yamllint' is installed and dt-schema is up to >> date: >> >> pip3 install dtschema --upgrade >> >> Please check and re-submit. >> > > I'm unsure about what I should do about this one. > This is a power-controller, but does *not* need any #power-domain-cells, as it is > standalone and doesn't require being attached to anything. power-domain-cells are for power domain providers, not consumers. The generic binding expect that nodes called power-controller are exactly like that. Solutions could be: 1. Rename the node to something else. I cannot deduct the type of the device based on description. What is "sequence ID" and how is it even closely related to power control? 2. Narrow the node name in power-domain.yaml which would require changes in multiple DTS and bindings. 3. Do not require power-domain-cells for power-controllers, only for power-domains. Best regards, Krzysztof
Il 15/11/22 14:36, Krzysztof Kozlowski ha scritto: > On 11/11/2022 11:05, AngeloGioacchino Del Regno wrote: >> Il 04/11/22 18:54, Rob Herring ha scritto: >>> >>> On Fri, 04 Nov 2022 15:22:03 +0100, AngeloGioacchino Del Regno wrote: >>>> Document bindings for the Qualcomm Ramp Controller, found on various >>>> legacy Qualcomm SoCs. >>>> >>>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> >>>> --- >>>> .../qcom/qcom,msm8976-ramp-controller.yaml | 37 +++++++++++++++++++ >>>> 1 file changed, 37 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml >>>> >>> >>> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' >>> on your patch (DT_CHECKER_FLAGS is new in v5.13): >>> >>> yamllint warnings/errors: >>> >>> dtschema/dtc warnings/errors: >>> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.example.dtb: power-controller@b014000: '#power-domain-cells' is a required property >>> From schema: /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/power/power-domain.yaml >>> >>> doc reference errors (make refcheckdocs): >>> >>> See https://patchwork.ozlabs.org/patch/ >>> >>> This check can fail if there are any dependencies. The base for a patch >>> series is generally the most recent rc1. >>> >>> If you already ran 'make dt_binding_check' and didn't see the above >>> error(s), then make sure 'yamllint' is installed and dt-schema is up to >>> date: >>> >>> pip3 install dtschema --upgrade >>> >>> Please check and re-submit. >>> >> >> I'm unsure about what I should do about this one. >> This is a power-controller, but does *not* need any #power-domain-cells, as it is >> standalone and doesn't require being attached to anything. > > power-domain-cells are for power domain providers, not consumers. The > generic binding expect that nodes called power-controller are exactly > like that. > > Solutions could be: > 1. Rename the node to something else. I cannot deduct the type of the > device based on description. What is "sequence ID" and how is it even > closely related to power control? This uC is mainly controlling DCVS, automagically plays with voltages for each ramp up/down step and from what I understand also decides to shut down or bring up *power* to "certain clocks" before ungating (CPU related, mainly big cluster). This also interacts with LMH - setting the LMH part makes it possible to later use CPR (otherwise CPR errors out internally and won't start, as it requires this controller, SAW and LMH to be set up in order to work). What I've seen is that without it I can't bring up the big cluster at all, not even at minimum frequency, as the HF2PLL (a clock source for that cluster) will not power up. All it takes is to initialize these params and start the controller, then everything goes as it should. If you're wondering why my explanation may not be particularly satisfying, that's because downstream contains practically no information about this one, apart from a bunch of lines of code and because this controller is just a big black box. > > 2. Narrow the node name in power-domain.yaml which would require changes > in multiple DTS and bindings. > > 3. Do not require power-domain-cells for power-controllers, only for > power-domains. > Solutions 2 and 3... well, I don't think that this would be really feasible as I envision this being the one and only driver that will ever require that kind of thing. Also, this programming was later moved to bootloaders and the only SoCs that will ever require this are MSM8956/76, MSM8953 and.. I think MSM8952 as well, but nothing more. Even if I can imagine the answer, I'm still tempted to ask: can we eventually just name it ramp-controller@xxxx or qcom-rc@xxxx or something "special" like that to overcome to this binding issue? Regards, Angelo
On 15/11/2022 15:44, AngeloGioacchino Del Regno wrote: >>>> Please check and re-submit. >>>> >>> >>> I'm unsure about what I should do about this one. >>> This is a power-controller, but does *not* need any #power-domain-cells, as it is >>> standalone and doesn't require being attached to anything. >> >> power-domain-cells are for power domain providers, not consumers. The >> generic binding expect that nodes called power-controller are exactly >> like that. >> >> Solutions could be: >> 1. Rename the node to something else. I cannot deduct the type of the >> device based on description. What is "sequence ID" and how is it even >> closely related to power control? > > This uC is mainly controlling DCVS, automagically plays with voltages for > each ramp up/down step and from what I understand also decides to shut down > or bring up *power* to "certain clocks" before ungating (CPU related, mainly > big cluster). > This also interacts with LMH - setting the LMH part makes it possible to > later use CPR (otherwise CPR errors out internally and won't start, as it > requires this controller, SAW and LMH to be set up in order to work). > > What I've seen is that without it I can't bring up the big cluster at all, > not even at minimum frequency, as the HF2PLL (a clock source for that cluster) > will not power up. > All it takes is to initialize these params and start the controller, then > everything goes as it should. > > If you're wondering why my explanation may not be particularly satisfying, > that's because downstream contains practically no information about this > one, apart from a bunch of lines of code and because this controller is > just a big black box. > >> >> 2. Narrow the node name in power-domain.yaml which would require changes >> in multiple DTS and bindings. >> >> 3. Do not require power-domain-cells for power-controllers, only for >> power-domains. >> > > Solutions 2 and 3... well, I don't think that this would be really feasible > as I envision this being the one and only driver that will ever require > that kind of thing. > Also, this programming was later moved to bootloaders and the only SoCs that > will ever require this are MSM8956/76, MSM8953 and.. I think MSM8952 as well, > but nothing more. > > Even if I can imagine the answer, I'm still tempted to ask: can we eventually > just name it ramp-controller@xxxx or qcom-rc@xxxx or something "special" like > that to overcome to this binding issue? So maybe "cpu-power-controller"? This should already help for this warning. Best regards, Krzysztof
Il 15/11/22 16:16, Krzysztof Kozlowski ha scritto: > On 15/11/2022 15:44, AngeloGioacchino Del Regno wrote: > >>>>> Please check and re-submit. >>>>> >>>> >>>> I'm unsure about what I should do about this one. >>>> This is a power-controller, but does *not* need any #power-domain-cells, as it is >>>> standalone and doesn't require being attached to anything. >>> >>> power-domain-cells are for power domain providers, not consumers. The >>> generic binding expect that nodes called power-controller are exactly >>> like that. >>> >>> Solutions could be: >>> 1. Rename the node to something else. I cannot deduct the type of the >>> device based on description. What is "sequence ID" and how is it even >>> closely related to power control? >> >> This uC is mainly controlling DCVS, automagically plays with voltages for >> each ramp up/down step and from what I understand also decides to shut down >> or bring up *power* to "certain clocks" before ungating (CPU related, mainly >> big cluster). >> This also interacts with LMH - setting the LMH part makes it possible to >> later use CPR (otherwise CPR errors out internally and won't start, as it >> requires this controller, SAW and LMH to be set up in order to work). >> >> What I've seen is that without it I can't bring up the big cluster at all, >> not even at minimum frequency, as the HF2PLL (a clock source for that cluster) >> will not power up. >> All it takes is to initialize these params and start the controller, then >> everything goes as it should. >> >> If you're wondering why my explanation may not be particularly satisfying, >> that's because downstream contains practically no information about this >> one, apart from a bunch of lines of code and because this controller is >> just a big black box. >> >>> >>> 2. Narrow the node name in power-domain.yaml which would require changes >>> in multiple DTS and bindings. >>> >>> 3. Do not require power-domain-cells for power-controllers, only for >>> power-domains. >>> >> >> Solutions 2 and 3... well, I don't think that this would be really feasible >> as I envision this being the one and only driver that will ever require >> that kind of thing. >> Also, this programming was later moved to bootloaders and the only SoCs that >> will ever require this are MSM8956/76, MSM8953 and.. I think MSM8952 as well, >> but nothing more. >> >> Even if I can imagine the answer, I'm still tempted to ask: can we eventually >> just name it ramp-controller@xxxx or qcom-rc@xxxx or something "special" like >> that to overcome to this binding issue? > > So maybe "cpu-power-controller"? This should already help for this warning. > Agreed. Thanks for the advice! Sending a v3 asap!
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml new file mode 100644 index 000000000000..67f0bdf7d2da --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,msm8976-ramp-controller.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/qcom/qcom,msm8976-ramp-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Ramp Controller + +maintainers: + - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> + +description: + The Ramp Controller is used to program the sequence ID for pulse + swallowing, enable sequences and link Sequence IDs (SIDs) for the + CPU cores on some Qualcomm SoCs. + +properties: + compatible: + enum: + - qcom,msm8976-ramp-controller + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + power-controller@b014000 { + compatible = "qcom,msm8976-ramp-controller"; + reg = <0x0b014000 0x68>; + }; +