All of lore.kernel.org
 help / color / mirror / Atom feed
From: kgunda@codeaurora.org
To: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <swboyd@chromium.org>,
	Andy Gross <agross@kernel.org>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Lee Jones <lee.jones@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org,
	linux-kernel@vger.kernel.org, rnayak@codeaurora.org,
	linux-arm-msm-owner@vger.kernel.org
Subject: Re: [PATCH V3 1/2] mfd: qcom-spmi-pmic: Convert bindings to .yaml format
Date: Fri, 07 Feb 2020 12:16:46 +0530	[thread overview]
Message-ID: <1d7e38197bcaec99dd4e669b5dc8e31c@codeaurora.org> (raw)
In-Reply-To: <20200206220638.GA28227@bogus>

On 2020-02-07 03:36, Rob Herring wrote:
> On Thu, Feb 06, 2020 at 11:06:55AM -0800, Stephen Boyd wrote:
>> Quoting Kiran Gunda (2020-02-06 05:55:26)
>> > Convert the bindings from .txt to .yaml format.
>> >
>> > Signed-off-by: Kiran Gunda <kgunda@codeaurora.org>
>> > ---
>> 
>> Did something change? Is there a cover letter?
>> 
>> > diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
>> > new file mode 100644
>> > index 0000000..affc169
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
>> > @@ -0,0 +1,115 @@
>> > +# SPDX-License-Identifier: GPL-2.0-only
>> > +%YAML 1.2
>> > +---
>> > +$id: http://devicetree.org/schemas/bindings/mfd/qcom,spmi-pmic.yaml#
>> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> > +
>> > +title: Qualcomm SPMI PMICs multi-function device bindings
>> > +
>> > +maintainers:
>> > +  - Lee Jones <lee.jones@linaro.org>
>> > +  - Stephen Boyd <sboyd@codeaurora.org>
>> 
>> Please change this to sboyd@kernel.org
> 
> Should be the h/w owner, not applier of changes.
> 
Ok.. I will remove it in next post.
>> 
>> > +
>> > +description: |
>> > +  The Qualcomm SPMI series presently includes PM8941, PM8841 and PMA8084
>> > +  PMICs.  These PMICs use a QPNP scheme through SPMI interface.
>> 
>> This first sentence will need continual updating. Please drop it.
>> 
>> > +  QPNP is effectively a partitioning scheme for dividing the SPMI extended
>> > +  register space up into logical pieces, and set of fixed register
>> > +  locations/definitions within these regions, with some of these regions
>> > +  specifically used for interrupt handling.
>> > +
>> > +  The QPNP PMICs are used with the Qualcomm Snapdragon series SoCs, and are
>> > +  interfaced to the chip via the SPMI (System Power Management Interface) bus.
>> > +  Support for multiple independent functions are implemented by splitting the
>> > +  16-bit SPMI slave address space into 256 smaller fixed-size regions, 256 bytes
>> > +  each. A function can consume one or more of these fixed-size register regions.
>> > +
>> > +properties:
>> > +  compatible:
>> > +    enum:
>> > +      - qcom,pm8941
>> > +      - qcom,pm8841
>> > +      - qcom,pma8084
>> > +      - qcom,pm8019
>> > +      - qcom,pm8226
>> > +      - qcom,pm8110
>> > +      - qcom,pma8084
>> > +      - qcom,pmi8962
>> > +      - qcom,pmd9635
>> > +      - qcom,pm8994
>> > +      - qcom,pmi8994
>> > +      - qcom,pm8916
>> > +      - qcom,pm8004
>> > +      - qcom,pm8909
>> > +      - qcom,pm8950
>> > +      - qcom,pmi8950
>> > +      - qcom,pm8998
>> > +      - qcom,pmi8998
>> > +      - qcom,pm8005
>> > +      - qcom,spmi-pmic
>> 
>> I think we want qcom,spmi-pmic to be there always. To do that we need 
>> it
>> to look like:
>> 
>>   compatible:
>>     items:
>>       enum:
>>         - qcom,pm8941
>>         ...
>>       enum:
>>         - qcom,spmi-pmic
> 
> Yes, but missing '-' before the enum's.
> 
Will add it in next post
>> 
>> > +
>> > +  reg:
>> > +    maxItems: 1
>> > +    description:
>> > +      Specifies the SPMI USID slave address for this device.
>> > +      For more information see Documentation/devicetree/bindings/spmi/spmi.txt
>> > +
>> > +patternProperties:
>> > +  "^.*@[0-9a-f]+$":
> 
> You are going to need to define the specific child nodes with the
> schemas for them, but a SPMI bus schema may be useful.
> 
Ok.. I will add it in next post.
>> > +    type: object
>> > +    description:
>> > +      Each child node of SPMI slave id represents a function of the PMIC. In the
>> > +      example below the rtc device node represents a peripheral of pm8941
>> > +      SID = 0. The regulator device node represents a peripheral of pm8941 SID = 1.
>> > +
>> > +    properties:
>> > +      compatible:
>> > +        description:
>> > +          Compatible of the PMIC device.
>> > +
>> > +      interrupts:
>> > +        maxItems: 2
>> > +        description:
>> > +          Interrupts are specified as a 4-tuple. For more information
>> > +          see Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
>> 
>> Just make this bindings/spmi/qcom,spmi-pmic-arb.txt so that  we don't
>> have to worry about it. Why is max items 2? Isn't it 4? Is this 
>> property
>> supposed to be specified at all?
>> 
>> > +
>> > +      interrupt-names:
>> > +        description:
>> > +          Corresponding interrupt name to the interrupts property
>> 
>> Does this need to be specified either?
>> 
>> > +
>> > +    required:
>> > +      - compatible
>> > +
>> > +required:
>> > +  - compatible
>> > +  - reg
>> > +
>> > +examples:
>> > +  - |
>> > +    spmi {
>> > +        compatible = "qcom,spmi-pmic-arb";
>> > +        #address-cells = <2>;
>> > +        #size-cells = <0>;
>> > +
>> > +       pm8941@0 {
>> 
>> pmic@0
>> 
>> > +         compatible = "qcom,pm8941";
>> > +         reg = <0x0 0x0>;
>> 
>> Why not include the header file to get the SPMI_USID macro?
>> 
>> > +
>> > +         rtc {
>> > +           compatible = "qcom,rtc";
>> > +           interrupts = <0x0 0x61 0x1 0x1>;
>> > +           interrupt-names = "alarm";
>> > +         };
>> > +       };
>> > +
>> > +       pm8941@1 {
>> 
>> pmic@1
>> 
>> > +         compatible = "qcom,pm8941";
>> > +         reg = <0x1 0x0>;
>> > +
>> > +         regulator {
>> > +           compatible = "qcom,regulator";
>> > +           regulator-name = "8941_boost";
>> > +         };
>> > +       };
>> > +    };
>> > +...
>> > --
>> > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> >  a Linux Foundation Collaborative Project

  reply	other threads:[~2020-02-07  6:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-06 13:55 [PATCH V3 1/2] mfd: qcom-spmi-pmic: Convert bindings to .yaml format Kiran Gunda
2020-02-06 13:55 ` [PATCH V3 2/2] mfd: qcom-spmi-pmic: Add support for pm6150 and pm6150l Kiran Gunda
2020-02-06 19:08   ` Stephen Boyd
2020-02-07  5:59     ` kgunda
2020-02-06 19:06 ` [PATCH V3 1/2] mfd: qcom-spmi-pmic: Convert bindings to .yaml format Stephen Boyd
2020-02-06 22:06   ` Rob Herring
2020-02-07  6:46     ` kgunda [this message]
2020-02-07  5:57   ` kgunda
2020-10-02 21:45     ` Stephen Boyd
2020-10-21 15:09       ` kgunda
2020-12-17 11:38 [PATCH V3 0/2] Convert qcom,spmi-pmic bindings from .txt to .yaml Kiran Gunda
2020-12-17 11:38 ` [PATCH V3 1/2] mfd: qcom-spmi-pmic: Convert bindings to .yaml format Kiran Gunda
2020-12-17 18:50   ` Rob Herring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1d7e38197bcaec99dd4e669b5dc8e31c@codeaurora.org \
    --to=kgunda@codeaurora.org \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-arm-msm-owner@vger.kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=rnayak@codeaurora.org \
    --cc=robh@kernel.org \
    --cc=swboyd@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.