Re: [PATCH v2 05/11] regulator: dt-bindings: mediatek: Add MT6366 PMIC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Il 23/08/23 10:07, Chen-Yu Tsai ha scritto:
On Wed, Aug 23, 2023 at 1:45 PM Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:

On 23/08/2023 06:20, Chen-Yu Tsai wrote:
On Wed, Aug 23, 2023 at 3:40 AM Krzysztof Kozlowski
<krzysztof.kozlowski@xxxxxxxxxx> wrote:

On 22/08/2023 21:39, Krzysztof Kozlowski wrote:
On 22/08/2023 10:45, Chen-Yu Tsai wrote:
From: Zhiyong Tao <zhiyong.tao@xxxxxxxxxxxx>

The MediaTek MT6366 PMIC is similar to the MT6358 PMIC. It is designed
to be paired with the MediaTek MT8186 SoC. It has 9 buck regulators and
29 LDO regulators, not counting ones that feed internally and basically
have no controls. The regulators are named after their intended usage
for the SoC and system design, thus not named generically as ldoX or
dcdcX, but as vcn33 or vgpu.

Add a binding document describing all the regulators and their supplies.

Signed-off-by: Zhiyong Tao <zhiyong.tao@xxxxxxxxxxxx>
[wens@xxxxxxxxxxxx: major rework and added commit message]
Signed-off-by: Chen-Yu Tsai <wenst@xxxxxxxxxxxx>
---
Changes since v1:
- Replaced underscores in supply names to hyphens
- Merged with MT6358 regulator binding
- Added MT6358 fallback compatible to MT6366 regulator

Changes since Zhiyong's last version (v4) [1]:
- simplified regulator names
- added descriptions to regulators
- removed bogus regulators (*_sshub)
- merged vcn33-wifi and vcn33-bt as vcn33
- added missing regulators (vm18, vmddr, vsram-core)
- cut down examples to a handful of cases and made them complete
- expanded commit message a lot

[1] https://lore.kernel.org/linux-arm-kernel/20220823123745.14061-1-zhiyong.tao@xxxxxxxxxxxx/
  .../regulator/mediatek,mt6358-regulator.yaml  | 227 +++++++++++++-----
  1 file changed, 168 insertions(+), 59 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml
index 82328fe17680..b350181f33ff 100644
--- a/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6358-regulator.yaml
@@ -16,14 +16,18 @@ description: |

  properties:
    compatible:
-    const: mediatek,mt6358-regulator
+    oneOf:
+      - const: mediatek,mt6358-regulator
+      - items:
+          - const: mediatek,mt6366-regulator
+          - const: mediatek,mt6358-regulator

    vsys-ldo1-supply:
      description: Supply for LDOs vfe28, vxo22, vcn28, vaux18, vaud28, vsim1, vusb, vbif28
    vsys-ldo2-supply:
-    description: Supply for LDOs vldo28, vio28, vmc, vmch, vsim2
+    description: Supply for LDOs vldo28 (MT6358 only), vio28, vmc, vmch, vsim2
    vsys-ldo3-supply:
-    description: Supply for LDOs vcn33, vcama1, vcama2, vemc, vibr
+    description: Supply for LDOs vcn33, vcama[12] (MT6358 only), vemc, vibr
    vsys-vcore-supply:
      description: Supply for buck regulator vcore
    vsys-vdram1-supply:
@@ -43,75 +47,138 @@ properties:
    vsys-vs2-supply:
      description: Supply for buck regulator vs2
    vs1-ldo1-supply:
-    description: Supply for LDOs vrf18, vefuse, vcn18, vcamio, vio18
+    description: Supply for LDOs vrf18, vefuse, vcn18, vcamio (MT6358 only), vio18
    vs2-ldo1-supply:
-    description: Supply for LDOs vdram2
+    description: Supply for LDOs vdram2, vmddr (MT6366 only)
    vs2-ldo2-supply:
      description: Supply for LDOs vrf12, va12
    vs2-ldo3-supply:
-    description: Supply for LDOs vsram-gpu, vsram-others, vsram-proc11, vsram-proc12
-  vs2-ldo4-supply:
-    description: Supply for LDO vcamd
-
-patternProperties:
-  "^buck_v(core|dram1|gpu|modem|pa|proc1[12]|s[12])$":
-    description: Buck regulators
-    type: object
-    $ref: regulator.yaml#
-    unevaluatedProperties: false
-
-  "^ldo_v(a|rf)12":
-    description: LDOs with fixed 1.2V output and 0~100/10mV tuning
-    type: object
-    $ref: regulator.yaml#
-    unevaluatedProperties: false
-
-  "^ldo_v((aux|cn|io|rf)18|camio)":
-    description: LDOs with fixed 1.8V output and 0~100/10mV tuning
-    type: object
-    $ref: regulator.yaml#
-    unevaluatedProperties: false
-
-  "^ldo_vxo22":
-    description: LDOs with fixed 2.2V output and 0~100/10mV tuning
-    type: object
-    $ref: regulator.yaml#
-    unevaluatedProperties: false
-
-  "^ldo_v(aud|bif|cn|fe|io)28":
-    description: LDOs with fixed 2.8V output and 0~100/10mV tuning
-    type: object
-    $ref: regulator.yaml#
-    unevaluatedProperties: false
-
-  "^ldo_vusb":
-    description: LDOs with fixed 3.0V output and 0~100/10mV tuning
-    type: object
-    $ref: regulator.yaml#
-    unevaluatedProperties: false
-
-  "^ldo_vsram_(gpu|others|proc1[12])$":
-    description: LDOs with variable output
-    type: object
-    $ref: regulator.yaml#
-    unevaluatedProperties: false
-
-  "^ldo_v(cama[12]|camd|cn33|dram2|efuse|emc|ibr|ldo28|mc|mch|sim[12])$":
-    description: LDOs with variable output and 0~100/10mV tuning
-    type: object
-    $ref: regulator.yaml#
-    unevaluatedProperties: false

I don't understand. You just added it and it is already wrong? Please,
do not add code which is clearly incorrect.

Sent too early - anyway properties cannot be defined in allOf:. That's
not the place for them and there is no single reason for it. From which
regulator binding you got this example?

None. It was simply a way I figured out when I was reading up on JSON
schema syntax. I wanted to split the definitions cleanly, since they
are very different. And with "unevaluatedProperties: false" in the base
schema it did seem to work, successfully evaluating existing device trees
and producing errors when extra properties were added, or if types didn't
match up.

If they are very different, this should not have been one binding. There
is little benefit of that.

But how would one handle sharing a common fallback compatible if it were
split? In v1 they were separate bindings, but then Angelo argued that they
were in fact very similar and the variants can be detected through hardware
registers.

Note that the vastly different regulator names here are done for aesthetic
reasons. The MT6358 had names with underscores and IMHO unneeded prefixes.
These can't be changed due to existing device trees using them. (Or we
could break the ABI.) With the MT6366 I chose to simplify them to match
the exact names from the datasheet, except for the underscores.

ChenYu

Now that you mention it, I suppose the preferred way to write it is to
have all the properties in the base schema, then negate the ones that
don't belong in the allOf: section? It just seems really repetitive given
the child node names for the chip variants are completely different. OOTH
I guess it would produce better error messages.


For regular cases yes, but not if devices differ so much.


Summarizing the important info:
- Chips are not "very different"
- Main changes in schema are just cosmetic

Blurb below... :-)

MT6358 and MT6366 have minimal differences from a driver perspective but then
bindings describe hardware, not drivers, that's a fact and there's nothing to
argue about that (and infact I won't argue about that).

I've been arguing about using the same driver and about that one not needing
any special compatible for MT6366 because (as ChenYu said) the only difference
- again, from a software perspective - is that the big list of regulators "swaps"
(permit me the term...) 3 regulators and drops one: everything is handled the
very same way anyway.

This brings us to this point, where ChenYu *rightfully* wants to rename the actual
regulator names, because we shouldn't see underscores in devicetrees for multiple
reasons (which I surely don't have to explain of course) - even though the "right"
name as stated in datasheets contain underscores instead of dashes.

And there we go: all those changes in bindings are just because cosmetic stuff.

That said.....
I think that the real issue here can be solved with one easy question to Krzysztof:

in this case, where we want to use a different name (s/_/-/g) for regulators,
should we create a new yaml file, or should we update mt6358-regulator.yaml (but
obviously keeping the old cosmetics for the existing devicetrees and new for new)?

And - In case the best option would be to create a new mt6366-regulator.yaml,
would it be advisable to use a new compatible, or can we reuse the
"mediatek,mt6358-regulator" compatible?

Clearly, in the latter case, our target would be to have a devicetree declaring

regulator {
	compatible = "mediatek,mt6366-regulator", "mediatek,mt6358-regulator";
	... everything else ...
}

Cheers,
Angelo




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux