The Allwinner D1 SoC contains two pairs of in-package LDOs. One pair is
for general purpose use. LDOA generally powers the board's 1.8 V rail.
LDOB generally powers the in-package DRAM, where applicable.
The other pair of LDOs powers the analog power domains inside the SoC,
including the audio codec, thermal sensor, and ADCs. These LDOs require
a 0.9 V bandgap voltage reference. The calibration value for the voltage
reference is stored in an eFuse, accessed via an NVMEM cell.
Neither LDO control register is in its own MMIO range; instead, each
regulator device relies on a regmap/syscon exported by its parent.
Signed-off-by: Samuel Holland <samuel@sholland.org>
---
Changes in v3:
- Add "reg" property to bindings
- Add "unevaluatedProperties: true" to regulator nodes
- Minor changes to regulator node name patterns
- Remove system-ldos example (now added in patch 3)
Changes in v2:
- Remove syscon property from bindings
- Update binding examples to fix warnings and provide context
.../allwinner,sun20i-d1-analog-ldos.yaml | 74 +++++++++++++++++++
.../allwinner,sun20i-d1-system-ldos.yaml | 37 ++++++++++
2 files changed, 111 insertions(+)
create mode 100644 Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml
create mode 100644 Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
diff --git a/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml
new file mode 100644
index 000000000000..d6964b44ef21
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/allwinner,sun20i-d1-analog-ldos.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner D1 Analog LDOs
+
+description:
+ Allwinner D1 contains a set of LDOs which are designed to supply analog power
+ inside and outside the SoC. They are controlled by a register within the audio
+ codec MMIO space, but which is not part of the audio codec clock/reset domain.
+
+maintainers:
+ - Samuel Holland <samuel@sholland.org>
+
+properties:
+ compatible:
+ enum:
+ - allwinner,sun20i-d1-analog-ldos
+
+ reg:
+ maxItems: 1
+
+ nvmem-cells:
+ items:
+ - description: NVMEM cell for the calibrated bandgap reference trim value
+
+ nvmem-cell-names:
+ items:
+ - const: bg_trim
+
+patternProperties:
+ "^(a|hp)ldo$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - nvmem-cells
+ - nvmem-cell-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ audio-codec@2030000 {
+ compatible = "simple-mfd", "syscon";
+ reg = <0x2030000 0x1000>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ regulators@2030348 {
+ compatible = "allwinner,sun20i-d1-analog-ldos";
+ reg = <0x2030348 0x4>;
+ nvmem-cells = <&bg_trim>;
+ nvmem-cell-names = "bg_trim";
+
+ reg_aldo: aldo {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ reg_hpldo: hpldo {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+ };
+ };
+
+...
diff --git a/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
new file mode 100644
index 000000000000..e3e2810fb3d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
@@ -0,0 +1,37 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/allwinner,sun20i-d1-system-ldos.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner D1 System LDOs
+
+description:
+ Allwinner D1 contains a pair of general-purpose LDOs which are designed to
+ supply power inside and outside the SoC. They are controlled by a register
+ within the system control MMIO space.
+
+maintainers:
+ - Samuel Holland <samuel@sholland.org>
+
+properties:
+ compatible:
+ enum:
+ - allwinner,sun20i-d1-system-ldos
+
+ reg:
+ maxItems: 1
+
+patternProperties:
+ "^ldo[ab]$":
+ type: object
+ $ref: regulator.yaml#
+ unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+...
--
2.35.1On 15/08/2022 07:34, Samuel Holland wrote: > + reg: > + maxItems: 1 > + > + nvmem-cells: > + items: > + - description: NVMEM cell for the calibrated bandgap reference trim value > + > + nvmem-cell-names: > + items: > + - const: bg_trim > + > +patternProperties: > + "^(a|hp)ldo$": > + type: object > + $ref: regulator.yaml# > + unevaluatedProperties: false > + > +required: > + - compatible > + - reg > + - nvmem-cells > + - nvmem-cell-names > + > +unevaluatedProperties: false one more: this must be additionalProperties:false, because you do not reference any other schema in top level. Same in second file. Best regards, Krzysztof
On 15/08/2022 07:34, Samuel Holland wrote:
> The Allwinner D1 SoC contains two pairs of in-package LDOs. One pair is
> for general purpose use. LDOA generally powers the board's 1.8 V rail.
> LDOB generally powers the in-package DRAM, where applicable.
>
> The other pair of LDOs powers the analog power domains inside the SoC,
> including the audio codec, thermal sensor, and ADCs. These LDOs require
> a 0.9 V bandgap voltage reference. The calibration value for the voltage
> reference is stored in an eFuse, accessed via an NVMEM cell.
>
> Neither LDO control register is in its own MMIO range; instead, each
> regulator device relies on a regmap/syscon exported by its parent.
>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
>
> Changes in v3:
> - Add "reg" property to bindings
> - Add "unevaluatedProperties: true" to regulator nodes
> - Minor changes to regulator node name patterns
> - Remove system-ldos example (now added in patch 3)
>
> Changes in v2:
> - Remove syscon property from bindings
> - Update binding examples to fix warnings and provide context
>
> .../allwinner,sun20i-d1-analog-ldos.yaml | 74 +++++++++++++++++++
> .../allwinner,sun20i-d1-system-ldos.yaml | 37 ++++++++++
> 2 files changed, 111 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml
> create mode 100644 Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
>
> diff --git a/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml
> new file mode 100644
> index 000000000000..d6964b44ef21
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/allwinner,sun20i-d1-analog-ldos.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Allwinner D1 Analog LDOs
> +
> +description:
> + Allwinner D1 contains a set of LDOs which are designed to supply analog power
> + inside and outside the SoC. They are controlled by a register within the audio
> + codec MMIO space, but which is not part of the audio codec clock/reset domain.
> +
> +maintainers:
> + - Samuel Holland <samuel@sholland.org>
Please follow the example schema. Order is: title, maintainers, description.
> +
> +properties:
> + compatible:
> + enum:
> + - allwinner,sun20i-d1-analog-ldos
> +
> + reg:
> + maxItems: 1
> +
> + nvmem-cells:
> + items:
> + - description: NVMEM cell for the calibrated bandgap reference trim value
> +
> + nvmem-cell-names:
> + items:
> + - const: bg_trim
> +
> +patternProperties:
> + "^(a|hp)ldo$":
> + type: object
> + $ref: regulator.yaml#
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - nvmem-cells
> + - nvmem-cell-names
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + audio-codec@2030000 {
> + compatible = "simple-mfd", "syscon";
This cannot be on its own. Both require device specific compatible.
> + reg = <0x2030000 0x1000>;
> + ranges;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + regulators@2030348 {
> + compatible = "allwinner,sun20i-d1-analog-ldos";
> + reg = <0x2030348 0x4>;
> + nvmem-cells = <&bg_trim>;
> + nvmem-cell-names = "bg_trim";
> +
> + reg_aldo: aldo {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + reg_hpldo: hpldo {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> + };
> + };
> +
> +...
> diff --git a/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
> new file mode 100644
> index 000000000000..e3e2810fb3d7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
> @@ -0,0 +1,37 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/allwinner,sun20i-d1-system-ldos.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Allwinner D1 System LDOs
> +
> +description:
> + Allwinner D1 contains a pair of general-purpose LDOs which are designed to
> + supply power inside and outside the SoC. They are controlled by a register
> + within the system control MMIO space.
Fix order.
> +
> +maintainers:
> + - Samuel Holland <samuel@sholland.org>
> +
> +properties:
> + compatible:
> + enum:
> + - allwinner,sun20i-d1-system-ldos
> +
> + reg:
> + maxItems: 1
> +
> +patternProperties:
> + "^ldo[ab]$":
> + type: object
> + $ref: regulator.yaml#
> + unevaluatedProperties: false
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
Example please.
Best regards,
Krzysztof
On 8/16/22 4:55 AM, Krzysztof Kozlowski wrote:
> On 15/08/2022 07:34, Samuel Holland wrote:
>> The Allwinner D1 SoC contains two pairs of in-package LDOs. One pair is
>> for general purpose use. LDOA generally powers the board's 1.8 V rail.
>> LDOB generally powers the in-package DRAM, where applicable.
>>
>> The other pair of LDOs powers the analog power domains inside the SoC,
>> including the audio codec, thermal sensor, and ADCs. These LDOs require
>> a 0.9 V bandgap voltage reference. The calibration value for the voltage
>> reference is stored in an eFuse, accessed via an NVMEM cell.
>>
>> Neither LDO control register is in its own MMIO range; instead, each
>> regulator device relies on a regmap/syscon exported by its parent.
>>
>> Signed-off-by: Samuel Holland <samuel@sholland.org>
>> ---
>>
>> Changes in v3:
>> - Add "reg" property to bindings
>> - Add "unevaluatedProperties: true" to regulator nodes
>> - Minor changes to regulator node name patterns
>> - Remove system-ldos example (now added in patch 3)
>>
>> Changes in v2:
>> - Remove syscon property from bindings
>> - Update binding examples to fix warnings and provide context
>>
>> .../allwinner,sun20i-d1-analog-ldos.yaml | 74 +++++++++++++++++++
>> .../allwinner,sun20i-d1-system-ldos.yaml | 37 ++++++++++
>> 2 files changed, 111 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml
>> create mode 100644 Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml
>> new file mode 100644
>> index 000000000000..d6964b44ef21
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml
>> @@ -0,0 +1,74 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/regulator/allwinner,sun20i-d1-analog-ldos.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Allwinner D1 Analog LDOs
>> +
>> +description:
>> + Allwinner D1 contains a set of LDOs which are designed to supply analog power
>> + inside and outside the SoC. They are controlled by a register within the audio
>> + codec MMIO space, but which is not part of the audio codec clock/reset domain.
>> +
>> +maintainers:
>> + - Samuel Holland <samuel@sholland.org>
>
> Please follow the example schema. Order is: title, maintainers, description.
>
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - allwinner,sun20i-d1-analog-ldos
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + nvmem-cells:
>> + items:
>> + - description: NVMEM cell for the calibrated bandgap reference trim value
>> +
>> + nvmem-cell-names:
>> + items:
>> + - const: bg_trim
>> +
>> +patternProperties:
>> + "^(a|hp)ldo$":
>> + type: object
>> + $ref: regulator.yaml#
>> + unevaluatedProperties: false
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - nvmem-cells
>> + - nvmem-cell-names
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + audio-codec@2030000 {
>> + compatible = "simple-mfd", "syscon";
>
> This cannot be on its own. Both require device specific compatible.
Again, the device-specific compatible does not exist, because the binding for
the audio codec has not been written (and it will be quite nontrivial).
So I can:
1) Leave the example as-is until the audio codec binding gets written,
and fill in the specific compatible at that time.
2) Remove the example, with the reasoning that the example really
belongs with the MFD parent (like for the other regulator). Then
there will be no example until the audio codec binding is written.
3) Drop the analog LDOs from this series entirely, and some parts
of the SoC (like thermal monitoring) cannot be added to the DTSI
until the audio codec binding is written.
What do you think?
The same question applies for the D1 SoC DTSI, where I use this same construct.
(And technically this does validate with the current schema.)
>> + reg = <0x2030000 0x1000>;
>> + ranges;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + regulators@2030348 {
>> + compatible = "allwinner,sun20i-d1-analog-ldos";
>> + reg = <0x2030348 0x4>;
>> + nvmem-cells = <&bg_trim>;
>> + nvmem-cell-names = "bg_trim";
>> +
>> + reg_aldo: aldo {
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + };
>> +
>> + reg_hpldo: hpldo {
>> + regulator-min-microvolt = <1800000>;
>> + regulator-max-microvolt = <1800000>;
>> + };
>> + };
>> + };
>> +
>> +...
>> diff --git a/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
>> new file mode 100644
>> index 000000000000..e3e2810fb3d7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
>> @@ -0,0 +1,37 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/regulator/allwinner,sun20i-d1-system-ldos.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Allwinner D1 System LDOs
>> +
>> +description:
>> + Allwinner D1 contains a pair of general-purpose LDOs which are designed to
>> + supply power inside and outside the SoC. They are controlled by a register
>> + within the system control MMIO space.
>
> Fix order.
>
>
>> +
>> +maintainers:
>> + - Samuel Holland <samuel@sholland.org>
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - allwinner,sun20i-d1-system-ldos
>> +
>> + reg:
>> + maxItems: 1
>> +
>> +patternProperties:
>> + "^ldo[ab]$":
>> + type: object
>> + $ref: regulator.yaml#
>> + unevaluatedProperties: false
>> +
>> +required:
>> + - compatible
>> + - reg
>> +
>> +unevaluatedProperties: false
>
>
> Example please.
Rob asked me to move the example to the parent binding, so I did. The example is
added in patch 3.
Regards,
Samuel
On 17/08/2022 11:15, Samuel Holland wrote:
>>> + audio-codec@2030000 {
>>> + compatible = "simple-mfd", "syscon";
>>
>> This cannot be on its own. Both require device specific compatible.
>
> Again, the device-specific compatible does not exist, because the binding for
> the audio codec has not been written (and it will be quite nontrivial).
>
> So I can:
> 1) Leave the example as-is until the audio codec binding gets written,
> and fill in the specific compatible at that time.
> 2) Remove the example, with the reasoning that the example really
> belongs with the MFD parent (like for the other regulator). Then
> there will be no example until the audio codec binding is written.
> 3) Drop the analog LDOs from this series entirely, and some parts
> of the SoC (like thermal monitoring) cannot be added to the DTSI
> until the audio codec binding is written.
>
> What do you think?
>
> The same question applies for the D1 SoC DTSI, where I use this same construct.
>
> (And technically this does validate with the current schema.)
BTW, it validates only because of limitation in DT schema. Such
combination is not allowed and I wonder if we can make the schema
stricter...
Best regards,
Krzysztof
On 17/08/2022 11:15, Samuel Holland wrote:
>>> +
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - allwinner,sun20i-d1-analog-ldos
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> + nvmem-cells:
>>> + items:
>>> + - description: NVMEM cell for the calibrated bandgap reference trim value
>>> +
>>> + nvmem-cell-names:
>>> + items:
>>> + - const: bg_trim
>>> +
>>> +patternProperties:
>>> + "^(a|hp)ldo$":
>>> + type: object
>>> + $ref: regulator.yaml#
>>> + unevaluatedProperties: false
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - nvmem-cells
>>> + - nvmem-cell-names
>>> +
>>> +unevaluatedProperties: false
>>> +
>>> +examples:
>>> + - |
>>> + audio-codec@2030000 {
>>> + compatible = "simple-mfd", "syscon";
>>
>> This cannot be on its own. Both require device specific compatible.
>
> Again, the device-specific compatible does not exist, because the binding for
> the audio codec has not been written (and it will be quite nontrivial).
>
> So I can:
> 1) Leave the example as-is until the audio codec binding gets written,
> and fill in the specific compatible at that time.
> 2) Remove the example, with the reasoning that the example really
> belongs with the MFD parent (like for the other regulator). Then
> there will be no example until the audio codec binding is written.
> 3) Drop the analog LDOs from this series entirely, and some parts
> of the SoC (like thermal monitoring) cannot be added to the DTSI
> until the audio codec binding is written.
>
> What do you think?
How about just removing the audio-codec node? The schema is about
regulators, not audio-codec.
OTOH, if you have parent device schema, you could put the example only
there. But as I understand, you don't have, right?
>
> The same question applies for the D1 SoC DTSI, where I use this same construct.
This is not correct and should be fixed. Either you add the schema with
compatible or please drop the device node from the DTSI.
>
> (And technically this does validate with the current schema.)
>
>>> + reg = <0x2030000 0x1000>;
>>> + ranges;
>>> + #address-cells = <1>;
>>> + #size-cells = <1>;
>>> +
>>> + regulators@2030348 {
>>> + compatible = "allwinner,sun20i-d1-analog-ldos";
>>> + reg = <0x2030348 0x4>;
>>> + nvmem-cells = <&bg_trim>;
>>> + nvmem-cell-names = "bg_trim";
>>> +
>>> + reg_aldo: aldo {
>>> + regulator-min-microvolt = <1800000>;
>>> + regulator-max-microvolt = <1800000>;
>>> + };
>>> +
>>> + reg_hpldo: hpldo {
>>> + regulator-min-microvolt = <1800000>;
>>> + regulator-max-microvolt = <1800000>;
>>> + };
>>> + };
>>> + };
>>> +
>>> +...
>>> diff --git a/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
>>> new file mode 100644
>>> index 000000000000..e3e2810fb3d7
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml
>>> @@ -0,0 +1,37 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/regulator/allwinner,sun20i-d1-system-ldos.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Allwinner D1 System LDOs
>>> +
>>> +description:
>>> + Allwinner D1 contains a pair of general-purpose LDOs which are designed to
>>> + supply power inside and outside the SoC. They are controlled by a register
>>> + within the system control MMIO space.
>>
>> Fix order.
>>
>>
>>> +
>>> +maintainers:
>>> + - Samuel Holland <samuel@sholland.org>
>>> +
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - allwinner,sun20i-d1-system-ldos
>>> +
>>> + reg:
>>> + maxItems: 1
>>> +
>>> +patternProperties:
>>> + "^ldo[ab]$":
>>> + type: object
>>> + $ref: regulator.yaml#
>>> + unevaluatedProperties: false
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> +
>>> +unevaluatedProperties: false
>>
>>
>> Example please.
>
> Rob asked me to move the example to the parent binding, so I did. The example is
> added in patch 3.
Yeah, I noticed it later. It's fine.
Best regards,
Krzysztof
On 8/17/22 3:27 AM, Krzysztof Kozlowski wrote:
> On 17/08/2022 11:15, Samuel Holland wrote:
>>>> +examples:
>>>> + - |
>>>> + audio-codec@2030000 {
>>>> + compatible = "simple-mfd", "syscon";
>>>
>>> This cannot be on its own. Both require device specific compatible.
>>
>> Again, the device-specific compatible does not exist, because the binding for
>> the audio codec has not been written (and it will be quite nontrivial).
>>
>> So I can:
>> 1) Leave the example as-is until the audio codec binding gets written,
>> and fill in the specific compatible at that time.
>> 2) Remove the example, with the reasoning that the example really
>> belongs with the MFD parent (like for the other regulator). Then
>> there will be no example until the audio codec binding is written.
>> 3) Drop the analog LDOs from this series entirely, and some parts
>> of the SoC (like thermal monitoring) cannot be added to the DTSI
>> until the audio codec binding is written.
>>
>> What do you think?
>
> How about just removing the audio-codec node? The schema is about
> regulators, not audio-codec.
That works for me. I put the extra node there to signify that this is a MFD
child and requires some parent node to work, but I suppose it is not that
helpful to have.
> OTOH, if you have parent device schema, you could put the example only
> there. But as I understand, you don't have, right?
Right.
>> The same question applies for the D1 SoC DTSI, where I use this same construct.
>
> This is not correct and should be fixed. Either you add the schema with
> compatible or please drop the device node from the DTSI.
That's what I was afraid of.
Regards,
Samuel
>> (And technically this does validate with the current schema.)
On 17/08/2022 11:39, Samuel Holland wrote: >>> The same question applies for the D1 SoC DTSI, where I use this same construct. >> >> This is not correct and should be fixed. Either you add the schema with >> compatible or please drop the device node from the DTSI. > > That's what I was afraid of. The bindings can grow, so you can add a bindings stub documenting compatibles (device + simple-mfd + syscon) and IO space, then later extend it. Of course it is preferred to add bindings as complete as possible, but incremental growing also works. Best regards, Krzysztof
Am Montag, 15. August 2022, 06:34:32 CEST schrieb Samuel Holland: > The Allwinner D1 SoC contains two pairs of in-package LDOs. One pair is > for general purpose use. LDOA generally powers the board's 1.8 V rail. > LDOB generally powers the in-package DRAM, where applicable. > > The other pair of LDOs powers the analog power domains inside the SoC, > including the audio codec, thermal sensor, and ADCs. These LDOs require > a 0.9 V bandgap voltage reference. The calibration value for the voltage > reference is stored in an eFuse, accessed via an NVMEM cell. > > Neither LDO control register is in its own MMIO range; instead, each > regulator device relies on a regmap/syscon exported by its parent. > > Signed-off-by: Samuel Holland <samuel@sholland.org> > --- > > Changes in v3: > - Add "reg" property to bindings > - Add "unevaluatedProperties: true" to regulator nodes > - Minor changes to regulator node name patterns > - Remove system-ldos example (now added in patch 3) > > Changes in v2: > - Remove syscon property from bindings > - Update binding examples to fix warnings and provide context > > .../allwinner,sun20i-d1-analog-ldos.yaml | 74 +++++++++++++++++++ > .../allwinner,sun20i-d1-system-ldos.yaml | 37 ++++++++++ > 2 files changed, 111 insertions(+) > create mode 100644 Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml > create mode 100644 Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml > > diff --git a/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml > new file mode 100644 > index 000000000000..d6964b44ef21 > --- /dev/null > +++ b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml > @@ -0,0 +1,74 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/regulator/allwinner,sun20i-d1-analog-ldos.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Allwinner D1 Analog LDOs > + > +description: > + Allwinner D1 contains a set of LDOs which are designed to supply analog power > + inside and outside the SoC. They are controlled by a register within the audio > + codec MMIO space, but which is not part of the audio codec clock/reset domain. > + > +maintainers: > + - Samuel Holland <samuel@sholland.org> > + > +properties: > + compatible: > + enum: > + - allwinner,sun20i-d1-analog-ldos > + > + reg: > + maxItems: 1 > + > + nvmem-cells: > + items: > + - description: NVMEM cell for the calibrated bandgap reference trim value > + > + nvmem-cell-names: > + items: > + - const: bg_trim aren't dashes "-" preferred over underscores "_" in string names? Maybe even make this "bandgap-trim" for a bit more explanatory naming? Heiko
On 15/08/2022 18:32, Heiko Stübner wrote: > Am Montag, 15. August 2022, 06:34:32 CEST schrieb Samuel Holland: >> The Allwinner D1 SoC contains two pairs of in-package LDOs. One pair is >> for general purpose use. LDOA generally powers the board's 1.8 V rail. >> LDOB generally powers the in-package DRAM, where applicable. >> >> The other pair of LDOs powers the analog power domains inside the SoC, >> including the audio codec, thermal sensor, and ADCs. These LDOs require >> a 0.9 V bandgap voltage reference. The calibration value for the voltage >> reference is stored in an eFuse, accessed via an NVMEM cell. >> >> Neither LDO control register is in its own MMIO range; instead, each >> regulator device relies on a regmap/syscon exported by its parent. >> >> Signed-off-by: Samuel Holland <samuel@sholland.org> >> --- >> >> Changes in v3: >> - Add "reg" property to bindings >> - Add "unevaluatedProperties: true" to regulator nodes >> - Minor changes to regulator node name patterns >> - Remove system-ldos example (now added in patch 3) >> >> Changes in v2: >> - Remove syscon property from bindings >> - Update binding examples to fix warnings and provide context >> >> .../allwinner,sun20i-d1-analog-ldos.yaml | 74 +++++++++++++++++++ >> .../allwinner,sun20i-d1-system-ldos.yaml | 37 ++++++++++ >> 2 files changed, 111 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml >> create mode 100644 Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-system-ldos.yaml >> >> diff --git a/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml >> new file mode 100644 >> index 000000000000..d6964b44ef21 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/regulator/allwinner,sun20i-d1-analog-ldos.yaml >> @@ -0,0 +1,74 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/regulator/allwinner,sun20i-d1-analog-ldos.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Allwinner D1 Analog LDOs >> + >> +description: >> + Allwinner D1 contains a set of LDOs which are designed to supply analog power >> + inside and outside the SoC. They are controlled by a register within the audio >> + codec MMIO space, but which is not part of the audio codec clock/reset domain. >> + >> +maintainers: >> + - Samuel Holland <samuel@sholland.org> >> + >> +properties: >> + compatible: >> + enum: >> + - allwinner,sun20i-d1-analog-ldos >> + >> + reg: >> + maxItems: 1 >> + >> + nvmem-cells: >> + items: >> + - description: NVMEM cell for the calibrated bandgap reference trim value >> + >> + nvmem-cell-names: >> + items: >> + - const: bg_trim > > aren't dashes "-" preferred over underscores "_" in > string names? > > Maybe even make this "bandgap-trim" for a bit more > explanatory naming? In node names yes. In strings, I think there is no preference. At least I am not aware of it. Best regards, Krzysztof
© 2016 - 2026 Red Hat, Inc.