From: Rob Herring <robh@kernel.org>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linuxarm@huawei.com, mauro.chehab@huawei.com,
Lee Jones <lee.jones@linaro.org>, Stephen Boyd <sboyd@kernel.org>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v3 43/44] dt: document HiSilicon SPMI controller and mfd/regulator properties
Date: Mon, 17 Aug 2020 14:12:11 -0600 [thread overview]
Message-ID: <20200817201211.GA1437827@bogus> (raw)
In-Reply-To: <2f88fed96d67b05fc033356fdbb7e3227955ab34.1597647359.git.mchehab+huawei@kernel.org>
On Mon, Aug 17, 2020 at 09:11:02AM +0200, Mauro Carvalho Chehab wrote:
> Add documentation for the properties needed by the HiSilicon
> 6421v600 driver, and by the SPMI controller used to access
> the chipset.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> ---
> .../mfd/hisilicon,hi6421-spmi-pmic.yaml | 182 ++++++++++++++++++
> .../spmi/hisilicon,hisi-spmi-controller.yaml | 54 ++++++
> 2 files changed, 236 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
> create mode 100644 Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
>
> diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
> new file mode 100644
> index 000000000000..95494114554d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml
> @@ -0,0 +1,182 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mfd/hisilicon,hi6421-spmi-pmic.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HiSilicon 6421v600 SPMI PMIC
> +
> +maintainers:
> + - Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> +
> +description: |
> + HiSilicon 6421v600 uses a MIPI System Power Management (SPMI) bus in order
> + to provide interrupts and power supply.
> +
> + The GPIO and interrupt settings are represented as part of the top-level PMIC
> + node.
> +
> + The SPMI controller part is provided by
> + Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml.
> +
> +properties:
> + $nodename:
> + pattern: "pmic@[0-9a-f]"
> +
> + compatible:
> + const: hisilicon,hi6421-spmi-pmic
-spmi-pmic is redundant. Can the hi6421 be anything else?
> +
> + reg:
> + maxItems: 1
> +
> + spmi-channel:
> + description: number of the SPMI channel where the PMIC is connected
This looks like a common (to SPMI), but it's not something defined in
spmi.txt (which should ideally be converted to schema first). Minimally,
it needs a better explanation and determination if it should be common
or is HiSilicon specific.
> +
> + '#interrupt-cells':
> + const: 2
> +
> + interrupt-controller:
> + description:
> + Identify that the PMIC is capable of behaving as an interrupt controller.
No need to redefine common properties if nothing specific to this device
to say. Just:
interrupt-controller: true
> +
> + gpios:
> + maxItems: 1
> +
> + irq-num:
> + description: Interrupt request number
> +
> + 'irq-array':
> + description: Interrupt request array
> +
> + 'irq-mask-addr':
> + description: Address for the interrupt request mask
> +
> + 'irq-addr':
> + description: Address for the interrupt request
What's all these non-standard interrupt properties?
> +
> + regulators:
> + type: object
additionalProperties: false
> +
> + properties:
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + patternProperties:
> + '^ldo@[0-9]+$':
Unit-addresses are hex.
Also, doesn't match the example.
> + type: object
> +
> + $ref: "/schemas/regulator/regulator.yaml#"
> +
> + properties:
> + reg:
> + description: Enable register.
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
No child nodes, you don't need these.
> +
> + vsel-reg:
> + description: Voltage selector register.
'reg' can have multiple entries if you want.
> +
> + enable-mask:
> + description: Bitmask used to enable the regulator.
But if there's a shared enable reg, then you shouldn't have duplicate
addresses (same 'reg' value in multiple nodes).
These perhaps should be driver data rather than in DT as it's all fixed
for this chip. We don't try to parameterize everything in DT.
> +
> + voltage-table:
> + description: Table with the selector items for the voltage regulator.
> + minItems: 2
> + maxItems: 16
Needs a type $ref.
> +
> + off-on-delay-us:
> + description: Time required for changing state to enabled in microseconds.
> +
> + startup-delay-us:
> + description: Startup time in microseconds.
> +
> + idle-mode-mask:
> + description: Bitmask used to put the regulator on idle mode.
> +
> + eco-microamp:
> + description: Maximum current while on idle mode.
> +
> + required:
> + - reg
> + - vsel-reg
> + - enable-mask
> + - voltage-table
> + - off-on-delay-us
> + - startup-delay-us
> +
> +required:
> + - compatible
> + - reg
> + - regulators
Add:
additionalProperties: false
> +
> +examples:
> + - |
> + /* pmic properties */
> +
> + pmic: pmic@0 {
> + compatible = "hisilicon,hi6421-spmi-pmic";
> + slave_id = <0>;
Not documented. I believe this is part of 'reg'.
> + reg = <0 0>;
> +
> + #interrupt-cells = <2>;
> + interrupt-controller;
> + gpios = <&gpio28 0 0>;
> + irq-num = <16>;
> + irq-array = <2>;
> + irq-mask-addr = <0x202 2>;
> + irq-addr = <0x212 2>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + regulators {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ldo3: ldo3@16 {
> + reg = <0x16>;
> + vsel-reg = <0x51>;
> +
> + regulator-name = "ldo3";
> + regulator-min-microvolt = <1500000>;
> + regulator-max-microvolt = <2000000>;
> + regulator-boot-on;
> +
> + enable-mask = <0x01>;
> +
> + voltage-table = <1500000>, <1550000>, <1600000>, <1650000>,
> + <1700000>, <1725000>, <1750000>, <1775000>,
> + <1800000>, <1825000>, <1850000>, <1875000>,
> + <1900000>, <1925000>, <1950000>, <2000000>;
> + off-on-delay-us = <20000>;
> + startup-delay-us = <120>;
> + };
> +
> + ldo4: ldo4@17 { /* 40 PIN */
> + reg = <0x17>;
> + vsel-reg = <0x52>;
> +
> + regulator-name = "ldo4";
> + regulator-min-microvolt = <1725000>;
> + regulator-max-microvolt = <1900000>;
> + regulator-boot-on;
> +
> + enable-mask = <0x01>;
> + idle-mode-mask = <0x10>;
> + eco-microamp = <10000>;
> +
> + hi6421-vsel = <0x52 0x07>;
Not documented.
> + voltage-table = <1725000>, <1750000>, <1775000>, <1800000>,
> + <1825000>, <1850000>, <1875000>, <1900000>;
> + off-on-delay-us = <20000>;
> + startup-delay-us = <120>;
> + };
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml b/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
> new file mode 100644
> index 000000000000..5aeb2ae12024
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/spmi/hisilicon,hisi-spmi-controller.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: HiSilicon SPMI controller
> +
> +maintainers:
> + - Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> +
> +description: |
> + The HiSilicon SPMI controller is found on some Kirin-based designs.
> + It is a MIPI System Power Management (SPMI) controller.
> +
> + The PMIC part is provided by
> + Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml.
> +
> +properties:
> + $nodename:
> + pattern: "spmi@[0-9a-f]"
> +
> + compatible:
> + const: hisilicon,spmi-controller
Needs an SoC specific compatible.
> +
> + reg:
> + maxItems: 1
> +
> + "#address-cells":
> + const: 2
> +
> + "#size-cells":
> + const: 0
> +
> + spmi-channel:
> + description: number of the SPMI channel where the PMIC is connected
> +
> +patternProperties:
> + "^pmic@[0-9a-f]$":
> + $ref: "/schemas/mfd/hisilicon,hi6421-spmi-pmic.yaml#"
> +
> +examples:
> + - |
> + spmi: spmi@fff24000 {
> + compatible = "hisilicon,spmi-controller";
> + #address-cells = <2>;
> + #size-cells = <0>;
> + status = "ok";
> + reg = <0x0 0xfff24000 0x0 0x1000>;
> + spmi-channel = <2>;
Does this go in the SPMI controller or child (pmic)?
> +
> + /* pmic properties */
> +
> + };
> --
> 2.26.2
>
next prev parent reply other threads:[~2020-08-17 20:12 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-17 7:10 [PATCH v3 00/44] SPMI patches needed by Hikey 970 Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 01/44] staging: spmi: add Hikey 970 SPMI controller driver Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 02/44] staging: spmi: hisi-spmi-controller: coding style fixup Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 03/44] staging: spmi: hisi-spmi-controller: fix it to probe successfully Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 04/44] staging: spmi: hisi-spmi-controller: fix a typo Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 05/44] staging: spmi: hisi-spmi-controller: adjust whitespaces at defines Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 06/44] staging: spmi: hisi-spmi-controller: use le32 macros where needed Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 07/44] staging: spmi: hisi-spmi-controller: add debug when values are read/write Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 08/44] staging: spmi: hisi-spmi-controller: fix the dev_foo() logic Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 09/44] staging: spmi: hisi-spmi-controller: add it to the building system Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 10/44] staging: spmi: hisi-spmi-controller: do some code cleanups Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 11/44] staging: mfd: add a PMIC driver for HiSilicon 6421 SPMI version Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 12/44] staging: mfd: hi6421-spmi-pmic: get rid of unused code Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 13/44] staging: mfd: hi6421-spmi-pmic: deal with non-static functions Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 14/44] staging: mfd: hi6421-spmi-pmic: get rid of the static vars Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 15/44] staging: mfd: hi6421-spmi-pmic: cleanup hi6421-spmi-pmic.h header Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 16/44] staging: mfd: hi6421-spmi-pmic: change the binding logic Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 17/44] staging: mfd: hi6421-spmi-pmic: get rid of unused OF properties Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 18/44] staging: mfd: hi6421-spmi-pmic: cleanup " Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 19/44] staging: mfd: hi6421-spmi-pmic: change namespace on its functions Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 20/44] staging: mfd: hi6421-spmi-pmic: fix some coding style issues Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 21/44] staging: mfd: hi6421-spmi-pmic: add it to the building system Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 22/44] staging: mfd: hi6421-spmi-pmic: cleanup the code Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 23/44] staging: regulator: add a regulator driver for HiSilicon 6421v600 SPMI PMIC Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 24/44] staging: regulator: hi6421v600-regulator: get rid of unused code Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 25/44] staging: regulator: hi6421v600-regulator: port it to upstream Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 26/44] staging: regulator: hi6421v600-regulator: coding style fixups Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 27/44] staging: regulator: hi6421v600-regulator: change the binding logic Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 28/44] staging: regulator: hi6421v600-regulator: cleanup struct hisi_regulator Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 29/44] staging: regulator: hi6421v600-regulator: cleanup debug messages Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 30/44] staging: regulator: hi6421v600-regulator: use shorter names for OF properties Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 31/44] staging: regulator: hi6421v600-regulator: better handle modes Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 32/44] staging: regulator: hi6421v600-regulator: change namespace Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 33/44] staging: regulator: hi6421v600-regulator: convert to use get/set voltage_sel Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 34/44] staging: regulator: hi6421v600-regulator: don't use usleep_range for off_on_delay Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 35/44] staging: regulator: hi6421v600-regulator: add a driver-specific debug macro Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 36/44] staging: regulator: hi6421v600-regulator: initialize ramp_delay Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 37/44] staging: regulator: hi6421v600-regulator: cleanup DT settings Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 38/44] staging: regulator: hi6421v600-regulator: fix some coding style issues Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 39/44] staging: regulator: hi6421v600-regulator: add it to the building system Mauro Carvalho Chehab
2020-08-17 7:10 ` [PATCH v3 40/44] staging: regulator: hi6421v600-regulator: code cleanup Mauro Carvalho Chehab
2020-08-17 7:11 ` [PATCH v3 41/44] staging: hikey9xx: add a TODO list Mauro Carvalho Chehab
2020-08-17 7:11 ` [PATCH v3 42/44] MAINTAINERS: add an entry for HiSilicon 6421v600 drivers Mauro Carvalho Chehab
2020-08-18 14:18 ` Greg Kroah-Hartman
2020-08-17 7:11 ` [PATCH v3 43/44] dt: document HiSilicon SPMI controller and mfd/regulator properties Mauro Carvalho Chehab
2020-08-17 20:12 ` Rob Herring [this message]
2020-08-18 9:13 ` Mauro Carvalho Chehab
2020-08-18 10:37 ` Mauro Carvalho Chehab
2020-08-18 17:07 ` Rob Herring
2020-08-18 22:18 ` Mauro Carvalho Chehab
2020-08-19 20:48 ` Rob Herring
2020-08-18 11:10 ` [PATCH v3.1 " Mauro Carvalho Chehab
2020-08-18 14:19 ` Greg Kroah-Hartman
2020-08-17 7:11 ` [PATCH v3 44/44] dt: hisilicon: add support for the PMIC found on Hikey 970 Mauro Carvalho Chehab
2020-08-17 7:32 ` [PATCH v3 00/44] SPMI patches needed by " Greg Kroah-Hartman
2020-08-18 14:17 ` Greg Kroah-Hartman
2020-08-18 14:28 ` Mauro Carvalho Chehab
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=20200817201211.GA1437827@bogus \
--to=robh@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=lee.jones@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mauro.chehab@huawei.com \
--cc=mchehab+huawei@kernel.org \
--cc=sboyd@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox