[PATCH 1/2] dt-bindings: display: verisilicon,dc: generalize for DCUltra Lite variant
Joey Lu
a0987203069 at gmail.com
Tue May 12 01:02:06 PDT 2026
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 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.
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 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