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 <a0987203069@xxxxxxxxx>
> > > > ---
> > > >    .../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