On 5/11/2026 5:59 PM, Icenowy Zheng wrote:
在 2026-05-11一的 15:51 +0800，Joey Lu写道：
Extend the verisilicon,dc base schema to accommodate the Nuvoton
MA35D1
DCUltra Lite (a previous generation of the DC8000 series) which has a
different clock topology, no reset control, and a single output.
- Replace the fixed clock/reset item lists with minItems/maxItems
ranges
so sub-schemas can enforce variant-specific constraints
- Add a 'port' property (single-port alias) alongside the existing
'ports'
for single-output variants
- Remove the mandatory 'ports' requirement from the base schema; sub-
schemas
shall enforce their own port topology
- Add a 'select' stanza so the validator matches any node whose
compatible
contains a known Verisilicon DC string, including SoC-specific glue
- Relax additionalProperties to allow unevaluatedProperties
enforcement in
sub-schemas
- Fix a minor whitespace issue in the port@0 description
Add nuvoton,ma35d1-dcu.yaml as a sub-schema for the Nuvoton MA35D1
DCUltra
Lite display controller:
The Nuvoton MA35D1 integrates the Verisilicon DCUltra Lite display
controller. It is a single-output display controller with a 32-bit
RGB (DPI) interface. Unlike the DC8000, it does not have discoverable
chip identity registers, does not support the CONFIG_EX commit path,
and uses dedicated IRQ status/enable registers at offsets
0x147C/0x1480.
The clock topology uses two clocks (bus gate and pixel divider) and
does not require explicit reset control from the driver.
Signed-off-by: Joey Lu <[email protected]>
---
.../bindings/display/nuvoton,ma35d1-dcu.yaml | 94
+++++++++++++++++++
.../bindings/display/verisilicon,dc.yaml | 64 +++++++------
2 files changed, 131 insertions(+), 27 deletions(-)
create mode 100644
Documentation/devicetree/bindings/display/nuvoton,ma35d1-dcu.yaml
diff --git
a/Documentation/devicetree/bindings/display/nuvoton,ma35d1-dcu.yaml
b/Documentation/devicetree/bindings/display/nuvoton,ma35d1-dcu.yaml
new file mode 100644
index 000000000000..9279004ae27c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/nuvoton,ma35d1-
dcu.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/nuvoton,ma35d1-dcu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nuvoton MA35D1 DCUltra Lite display controller
+
+maintainers:
+ - Joey Lu <[email protected]>
+
+description:
+ The Nuvoton MA35D1 integrates the Verisilicon DCUltra Lite display
+ controller. It is a single-output display controller with a 32-bit
+ RGB (DPI) interface.
You'd better write this in verisilicon,dc.yaml with if clauses. See
Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml for an
example for a generic IP with different integrations, and how it
constraints different SoC's integration.
Understood. I'll drop both the separate nuvoton,ma35d1-dcu.yaml
file and the `nuvoton,ma35d1-dcu` compatible string entirely. Since the
chip identity registers are present on the DCUltra Lite (model=0x0,
rev=0x5560, customer=0x305), the MA35D1 DT node will use
`compatible = "verisilicon,dc"` directly. The YAML will use a single
`if/then/else` block in `allOf:` keyed on whether `thead,th1520-dc8200`
is present in the compatible list: the `then` branch enforces DC8200
constraints (5 clocks, 3 resets, `ports` required), and the `else`
branch enforces DCUltra Lite / generic constraints (2 clocks, 1 reset,
`port` required, `ports` forbidden). The Nuvoton MA35D1 example will use
`compatible = "verisilicon,dc"` and fall into the `else` branch.
+
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nuvoton,ma35d1-dcu
+ required:
+ - compatible
+
+allOf:
+ - $ref: http://devicetree.org/schemas/display/verisilicon,dc.yaml#
+
+properties:
+ compatible:
+ const: nuvoton,ma35d1-dcu
+
+ reg:
+ maxItems: 1
+ description:
+ Register range of the DCUltra Lite controller. The address
space
+ is 0x2000 bytes.
Is it really 0x2000 bytes? The next peripherals in the address space,
the GC520L 2D GPU, is 0x20000 bytes away from the start of DCU
registers space.
Good point. The 0x2000 figure is the driver's `max_register`,
not the full hardware block size. I'll remove the description text
claiming "0x2000 bytes" and update the example to use `0x20000` to
match the actual hardware address space.
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Bus clock that gates register access (DCU_GATE)
+ - description: Pixel clock divider for display timing
(DCUP_DIV)
+
+ clock-names:
+ items:
+ - const: core
+ - const: pix0
+
+ resets:
+ maxItems: 1
+ description:
+ Optional reset for the display controller. The driver does not
+ assert or deassert this reset; it may be used by firmware or
+ boot loaders to bring the hardware to a clean state.
Why is there a reset in hardware but not toggled in the software?
The driver will handle the reset in v2. The probe path will call
`devm_reset_control_bulk_get_optional_shared()` unconditionally with all
three names ("core", "axi", "ahb"). Since the MA35D1 DT only provides a
single reset named "core", the "axi" and "ahb" entries will be no-op
handles — optional bulk reset lookup skips absent entries silently.
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output port to the downstream display device (e.g. RGB panel).
+ The DCUltra Lite supports a single parallel RGB output.
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - port
+
+unevaluatedProperties: false
+
+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";
+ reg = <0x40260000 0x2000>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk DCU_GATE>, <&clk DCUP_DIV>;
+ clock-names = "core", "pix0";
+ resets = <&sys MA35D1_RESET_DISP>;
+
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
diff --git
a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
index 9dc35ab973f2..00884529f8c1 100644
--- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
+++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
@@ -9,15 +9,34 @@ title: Verisilicon DC-series display controllers
maintainers:
- Icenowy Zheng <[email protected]>
+description:
+ Verisilicon DC-series display controllers.
+
+# Select any node whose compatible contains one of the known
Verisilicon DC
+# or DC-derived compatible strings, including SoC-specific glue
variants.
+select:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - verisilicon,dc
+ - thead,th1520-dc8200
+ - nuvoton,ma35d1-dcu
+ required:
+ - compatible
+
properties:
$nodename:
pattern: "^display@[0-9a-f]+$"
compatible:
- items:
- - enum:
- - thead,th1520-dc8200
- - const: verisilicon,dc # DC IPs have discoverable ID/revision
registers
+ # Enumerated in full so the schema validator can verify any
compatible
+ # string against this list, including those from child schemas.
+ contains:
+ enum:
+ - verisilicon,dc
+ - thead,th1520-dc8200
+ - nuvoton,ma35d1-dcu
reg:
maxItems: 1
@@ -26,32 +45,24 @@ 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
+ minItems: 2
+ maxItems: 5
clock-names:
- items:
- - const: core
- - const: axi
- - const: ahb
- - const: pix0
- - const: pix1
+ minItems: 2
+ maxItems: 5
resets:
- items:
- - description: DC Core reset
- - description: DMA AXI bus reset
- - description: Configuration AHB bus reset
+ minItems: 1
+ maxItems: 3
reset-names:
- items:
- - const: core
- - const: axi
- - const: ahb
+ minItems: 1
+ maxItems: 3
+
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Single video output port for single-output
variants.
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -59,7 +70,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.
@@ -75,9 +86,8 @@ required:
- interrupts
- clocks
- clock-names
- - ports
-additionalProperties: false
+additionalProperties: true
examples:
- |
