Re: [PATCH v6 1/6] dt-bindings: display: verisilicon,dc: add support for nuvoton,ma35d1-dcu

Icenowy Zheng 於 2026/9/9 下午 01:44 寫道:

在 2026-09-08二的 17:28 +0800，Joey Lu写道：

quoted

Add the Nuvoton MA35D1 DCUltraLite (nuvoton,ma35d1-dcu) to the
binding.
The DCUltraLite uses only four clocks (core, axi, ahb, pix0) and one
reset (core), with a single output port.

The MA35D1 clock controller gates the core, AXI and AHB clocks with a
single bit, but each remains a distinct clock line feeding the IP
with
its own rate constraints, so all four must still be listed
individually
in the devicetree; core, axi and ahb happen to share the same clock
phandle.

This is weird, but I must admit that we're limited by the Common Clock
Framework here, so I cannot give a better solution either.

Anyway let's settle with the current result.

quoted

Move the clocks/clock-names minItems to 4 and resets/reset-names
minItems to 1 at the top level, since that is the lowest count any
supported variant needs.  Add an allOf/if block that tightens the
constraint back up to the fixed 5-clock/3-reset topology required by
the existing thead,th1520-dc8200 compatible, and another one that
caps
the new nuvoton,ma35d1-dcu compatible at the 4-clock/1-reset count it
actually wires up.

Signed-off-by: Joey Lu <redacted>
---
  .../bindings/display/verisilicon,dc.yaml      | 44
+++++++++++++++++++
  1 file changed, 44 insertions(+)

diff --git
a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
index 919a900122012..773966677d0f4 100644

--- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
+++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml

@@ -17,6 +17,7 @@ properties:
      items:
        - enum:
            - thead,th1520-dc8200
+          - nuvoton,ma35d1-dcu
        - const: verisilicon,dc # DC IPs have discoverable ID/revision

registers
  
    reg:

@@ -26,6 +27,7 @@ properties:
      maxItems: 1
  
    clocks:
+    minItems: 4
      items:
        - description: DC Core clock
        - description: DMA AXI bus clock

@@ -34,6 +36,7 @@ properties:
        - description: Pixel clock of output 1
  
    clock-names:
+    minItems: 4
      items:
        - const: core
        - const: axi

@@ -42,12 +45,14 @@ properties:
        - const: pix1
  
    resets:
+    minItems: 1
      items:
        - description: DC Core reset
        - description: DMA AXI bus reset
        - description: Configuration AHB bus reset
  
    reset-names:
+    minItems: 1
      items:
        - const: core
        - const: axi

@@ -79,6 +84,45 @@ required:
    - reset-names
    - ports
  
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: thead,th1520-dc8200
+    then:
+      properties:
+        clocks:
+          minItems: 5
+
+        clock-names:
+          minItems: 5
+
+        resets:
+          minItems: 3
+
+        reset-names:
+          minItems: 3
+
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: nuvoton,ma35d1-dcu
+    then:
+      properties:
+        clocks:
+          maxItems: 4
+
+        clock-names:
+          maxItems: 4
+
+        resets:
+          maxItems: 1
+
+        reset-names:
+          maxItems: 1

Maybe it's reasonable to restrict max port count to 1 for MA35D1?
Although I am not sure about how to do this...

Thanks,
Icenowy

 I found the same kind of per-compatible port restriction already used upstream in renesas,du.yaml, e.g.:

        ports:
          properties:
            port@2: false
            port@3: false
          required:
            - port@0
            - port@1

Applied to our binding, that would look like:

        ports:
          properties:
            port@1: false
          required:
            - port@0

in the existing nuvoton,ma35d1-dcu allOf/if/then block, so schema checks would reject a port@1 node on this compatible instead of silently accepting it.

Happy to add it if you'd like the schema to enforce this, but wanted to check whether you consider it worth the extra lines given it doesn't reflect an actual bug in any DT today. Let me know which way you'd prefer and I'll fold it into the next version.

Thanks.

quoted

+
  additionalProperties: false
  
  examples: