Re: [PATCH v6 1/6] dt-bindings: display: verisilicon,dc: add support for nuvoton,ma35d1-dcu
From: Joey Lu
Date: Mon Sep 14 2026 - 04:21:05 EST
Icenowy Zheng 於 2026/9/10 下午 03:08 寫道:
在 2026-09-10四的 09:52 +0800,Joey Lu写道:I'll send the port@1: false restriction as a follow-up patch once this series lands.
Icenowy Zheng 於 2026/9/9 下午 01:44 寫道:Personally I think this is good, but maybe adding it as an additional
在 2026-09-08二的 17:28 +0800,Joey Lu写道:I found the same kind of per-compatible port restriction already
Add the Nuvoton MA35D1 DCUltraLite (nuvoton,ma35d1-dcu) to theThis is weird, but I must admit that we're limited by the Common
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.
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-namesMaybe it's reasonable to restrict max port count to 1 for MA35D1?
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 <a0987203069@xxxxxxxxx>
---
.../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
Although I am not sure about how to do this...
Thanks,
Icenowy
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.
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
Thanks!
Thanks.
+
additionalProperties: false
examples: