Re: [PATCH v3 1/5] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Date: 2026-06-08 06:32:55
Also in:
dri-devel, linux-devicetree, lkml
在 2026-06-08一的 10:32 +0800,Joey Lu写道:
quoted hunk ↗ jump to hunk
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. - Relax the top-level clocks/resets definitions to minItems ranges so the base schema accepts both variants. - Keep ports in the global required list and keep additionalProperties tightened to unevaluatedProperties. - Add an allOf/if block for thead,th1520-dc8200: five-clock (core, axi, ahb, pix0, pix1), three-reset (core, axi, ahb). - Add an allOf/if block for nuvoton,ma35d1-dcu: two-clock (core, pix0), one-reset (core). - Fix a stray space in the port@0 description. - Add a DT example for the Nuvoton MA35D1 DCU Lite using ports/port@0. Signed-off-by: Joey Lu <redacted> --- .../bindings/display/verisilicon,dc.yaml | 103 +++++++++++++++- -- 1 file changed, 90 insertions(+), 13 deletions(-) diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml index 9dc35ab973f2..db0260d874c5 100644--- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml@@ -17,7 +17,8 @@ properties:items: - enum: - thead,th1520-dc8200 - - const: verisilicon,dc # DC IPs have discoverable ID/revision registers + - nuvoton,ma35d1-dcu + - const: verisilicon,dc # DC IPs have discoverable ID/revision registers
Ah is an extra space added here, which leads to this hunk looking strange?
quoted hunk ↗ jump to hunk
reg: maxItems: 1@@ -26,6 +27,7 @@ properties:maxItems: 1 clocks: + minItems: 2
Maybe restrictions about the clock count shouldn't be inserted here, and technically it's possible that only the pixel clock is controllable by Linux (all other clocks are in a fixed configuration).
quoted hunk ↗ jump to hunk
items: - description: DC Core clock - description: DMA AXI bus clock@@ -34,24 +36,19 @@ properties:- description: Pixel clock of output 1 clock-names: - items: - - const: core - - const: axi - - const: ahb - - const: pix0 - - const: pix1
Ah I think the total list should still appear here, and they should be corresponding to the descriptions above?
+ minItems: 2 + maxItems: 5 resets: + minItems: 1 items: - description: DC Core reset - description: DMA AXI bus reset - description: Configuration AHB bus reset reset-names: - items: - - const: core - - const: axi - - const: ahb
Ditto here.
quoted hunk ↗ jump to hunk
+ minItems: 1 + maxItems: 3 ports: $ref: /schemas/graph.yaml#/properties/ports@@ -59,7 +56,7 @@ properties:properties: port@0: $ref: /schemas/graph.yaml#/properties/port - description: The first output channel , endpoint 0 should be + description: The first output channel, endpoint 0 should be used for DPI format output and endpoint 1 should be used for DP format output.@@ -77,7 +74,60 @@ required:- clock-names - ports -additionalProperties: false +allOf: + - if: + properties: + compatible: + contains: + const: thead,th1520-dc8200 + then: + properties: + clocks: + minItems: 5 + maxItems: 5 + + clock-names: + items: + - const: core + - const: axi + - const: ahb + - const: pix0 + - const: pix1 + + resets: + minItems: 3 + maxItems: 3 + + reset-names: + items: + - const: core + - const: axi + - const: ahb + + - if: + properties: + compatible: + contains: + const: nuvoton,ma35d1-dcu + then: + properties: + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: core + - const: pix0 + + resets:
Do we have minItems: 1 here? (The DT schema validator always has some quirks that I fail to remember, so I am not sure.)
+ maxItems: 1 + + reset-names: + items: + - const: core +
I think resets should be described as required in both device-specific bindings. Thanks, Icenowy
quoted hunk ↗ jump to hunk
+unevaluatedProperties: false examples: - |@@ -120,3 +170,30 @@ examples:}; }; }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h> + #include <dt-bindings/reset/nuvoton,ma35d1-reset.h> + + display@40260000 { + compatible = "nuvoton,ma35d1-dcu", "verisilicon,dc"; + reg = <0x40260000 0x20000>; + interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk DCU_GATE>, <&clk DCUP_DIV>; + clock-names = "core", "pix0"; + resets = <&sys MA35D1_RESET_DISP>; + reset-names = "core"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpi_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + };