Re: [PATCH v4 1/6] dt-bindings: display: verisilicon, dc: generalize for single-output variants

[Joey Lu]

On 6/18/2026 6:24 PM, Icenowy Zheng wrote:
在 2026-06-17三的 18:25 +0800，Joey Lu写道：
On 6/15/2026 4:19 PM, Icenowy Zheng wrote:
在 2026-06-15一的 14:49 +0800，Joey Lu写道：
The existing schema hard-codes the five-clock/three-reset/dual-
port
topology of the DC8200 IP block, preventing reuse for single-
output
variants such as the Verisilicon DCUltraLite used in the Nuvoton
MA35D1
SoC.

Rework the schema so that variant-specific constraints are
expressed
via
allOf/if blocks:

- Add nuvoton,ma35d1-dcu to the SoC-specific compatible enum.
The
    generic verisilicon,dc fallback remains the driver-binding
string.
- Move clock and reset items descriptions into the per-variant
allOf/if
    blocks; keep only minItems/maxItems at the top level so the
base
schema
    accepts all variants.
- Restore full items lists for clock-names and reset-names at the
top
    level with minItems so the names are validated against the
descriptions.
- Keep ports in the global required list and keep
additionalProperties: false.
- Add an allOf/if block for thead,th1520-dc8200: five-clock
(core,
axi,
    ahb, pix0, pix1), three-reset (core, axi, ahb), required
resets.
- Add an allOf/if block for nuvoton,ma35d1-dcu: two-clock (core,
pix0),
    one-reset (core), required resets.

Signed-off-by: Joey Lu <a0987203...@gmail.com>
---
   .../bindings/display/verisilicon,dc.yaml      | 80
+++++++++++++++++--
   1 file changed, 73 insertions(+), 7 deletions(-)

diff --git
a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
index 9dc35ab973f2..0c41286b8223 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,14 +27,12 @@ properties:
       maxItems: 1
   
     clocks:
-    items:
-      - description: DC Core clock
-      - description: DMA AXI bus clock
-      - description: Configuration AHB bus clock
-      - description: Pixel clock of output 0
-      - description: Pixel clock of output 1
Clock descriptions should still be in the global part instead of
the
per-compatible part.

In the per-compatible part, clock-names should be constraint for
SoCs.
I will move the `items:` clock descriptions back into the global
`clocks:` property, covering all five possible clocks. In the
per-compatible sections I will remove the description items and only
constrain `clocks: minItems/maxItems` and `clock-names:
minItems/maxItems`; for nuvoton,ma35d1-dcu I will additionally
override
`clock-names: items:` to the two names actually used (core, pix0).
Yes, this should be the correct practice, although I wonder whether the
minItems and maxItems properties are needed globally (because these two
seem to have default implicit value).

BTW the MA35D1 manual in fact shows 4 clocks for "DCUltra" in the clock
tree, maybe the DT binding needs to be reconsidered?

Thanks,
Icenowy
I will drop the global `minItems`/`maxItems` on `clocks` and 
`clock-names` in v5, as they are redundant with the implicit defaults.

Regarding the 4-clock question: the TRM clock tree diagram does show 
four paths reaching DCUltra (display core mux/gate, AXI ACLK, AHB HCLK, 
and the pixel clock divider). However, the MA35D1 hardware provides only 
one software-controllable enable bit (SYSCLK0[26]) that gates the core 
clock together with the AXI and AHB bus clocks through shared ICG cells; 
there are no separate register bits for the bus clocks alone. Due to 
this hardware design constraint, the `clk-ma35d1` driver is 
intentionally designed to register only three DCU-related CCF nodes: 
`dcu_mux` (ID 61, an internal routing mux), `dcu_gate` (ID 62, the 
single gate at SYSCLK0 bit 26), and `dcup_div` (ID 63, the pixel divider 
from VPLL at CLKDIV0[18:16]), with no independent AXI or AHB gate 
entries for DCU. Since the DT binding can only reference clock handles 
that the platform clock driver actually provides, the MA35D1 binding 
will remain at two clock entries: "core" mapped to `DCU_GATE` and "pix0" 
mapped to `DCUP_DIV`.

Thanks.


+    minItems: 2
+    maxItems: 5
   
     clock-names:
+    minItems: 2
+    maxItems: 5
       items:
         - const: core
         - const: axi