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

[Joey Lu]

Icenowy Zheng 於 2026/9/10 下午 03:08 寫道:
在 2026-09-10四的 09:52 +0800，Joey Lu写道：
Icenowy Zheng 於 2026/9/9 下午 01:44 寫道:
在 2026-09-08二的 17:28 +0800，Joey Lu写道：
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.

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 <a0987203...@gmail.com>
---
   .../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.
Personally I think this is good, but maybe adding it as an additional
patch after merging isn't a big problem, because this just plays as
kind of a safety guard.

Well this depends on how DT binding maintainers think, but as Conor has
dropped his Ack, this shouldn't be a big issue.

Thanks,
Icenowy
I'll send the port@1: false restriction as a follow-up patch once this 
series lands.
Thanks!
Thanks.
+
   additionalProperties: false
   
   examples: