[PATCH 1/2] dt-bindings: display: verisilicon,dc: generalize for DCUltra Lite variant
Icenowy Zheng
zhengxingda at iscas.ac.cn
Mon May 11 02:59:55 PDT 2026
在 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 at 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 <a0987203069 at gmail.com>
> ---
> .../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 <yclu4 at nuvoton.com>
> +
> +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.
> +
> +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.
> +
> + 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?
> +
> + 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 at 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 <uwu at icenowy.me>
>
> +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 at 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:
> - |
More information about the linux-arm-kernel
mailing list