Verisilicon has a series of display controllers prefixed with DC and
with self-identification facility like their GC series GPUs.
Add a device tree binding for it.
Depends on the specific DC model, it can have either one or two display
outputs, and each display output could be set to DPI signal or "DP"
signal (which seems to be some plain parallel bus to HDMI controllers).
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
---
.../bindings/display/verisilicon,dc.yaml | 127 ++++++++++++++++++
1 file changed, 127 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/verisilicon,dc.yaml
diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
new file mode 100644
index 0000000000000..2f71a811786aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
@@ -0,0 +1,127 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/verisilicon,dc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Verisilicon DC-series display controllers
+
+maintainers:
+ - Icenowy Zheng <uwu@icenowy.me>
+
+properties:
+ $nodename:
+ pattern: "^display@[0-9a-f]+$"
+
+ compatible:
+ const: verisilicon,dc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ 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: 4
+
+ clock-names:
+ items:
+ - const: core
+ - const: axi
+ - const: ahb
+ - const: pix0
+ - const: pix1
+ minItems: 4
+
+ resets:
+ items:
+ - description: DC Core reset
+ - description: DMA AXI bus reset
+ - description: Configuration AHB bus reset
+
+ reset-names:
+ items:
+ - const: core
+ - const: axi
+ - const: ahb
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: The first output channel, endpoint 0 should be
+ used for DPI format output and endpoint 1 should be used
+ for DP format output.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: The second output channel if the DC variant
+ supports and used. Follow the same endpoint addressing
+ rule with the first port.
+
+ required:
+ - port@0
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/thead,th1520-clk-ap.h>
+ #include <dt-bindings/reset/thead,th1520-reset.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ display@ffef600000 {
+ compatible = "verisilicon,dc";
+ reg = <0xff 0xef600000 0x0 0x100000>;
+ interrupts = <93 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk_vo CLK_DPU_CCLK>,
+ <&clk_vo CLK_DPU_ACLK>,
+ <&clk_vo CLK_DPU_HCLK>,
+ <&clk_vo CLK_DPU_PIXELCLK0>,
+ <&clk_vo CLK_DPU_PIXELCLK1>;
+ clock-names = "core", "axi", "ahb", "pix0", "pix1";
+ resets = <&rst TH1520_RESET_ID_DPU_CORE>,
+ <&rst TH1520_RESET_ID_DPU_AXI>,
+ <&rst TH1520_RESET_ID_DPU_AHB>;
+ reset-names = "core", "axi", "ahb";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port@0 {
+ reg = <0>;
+ };
+
+ port@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dpu_out_dp1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&hdmi_in>;
+ };
+ };
+ };
+ };
+ };
--
2.50.1On Fri, Aug 15, 2025 at 12:40:42AM +0800, Icenowy Zheng wrote:
> Verisilicon has a series of display controllers prefixed with DC and
> with self-identification facility like their GC series GPUs.
>
> Add a device tree binding for it.
>
> Depends on the specific DC model, it can have either one or two display
> outputs, and each display output could be set to DPI signal or "DP"
> signal (which seems to be some plain parallel bus to HDMI controllers).
>
> Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
> ---
> .../bindings/display/verisilicon,dc.yaml | 127 ++++++++++++++++++
> 1 file changed, 127 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/verisilicon,dc.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> new file mode 100644
> index 0000000000000..2f71a811786aa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> @@ -0,0 +1,127 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/verisilicon,dc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Verisilicon DC-series display controllers
> +
> +maintainers:
> + - Icenowy Zheng <uwu@icenowy.me>
> +
> +properties:
> + $nodename:
> + pattern: "^display@[0-9a-f]+$"
> +
> + compatible:
> + const: verisilicon,dc
If the clocks or resets varies by platform, then you need an SoC
specific compatible still. If these clocks/resets are straight from the
RTL and any other number of clocks/resets is wrong, then we can stick
with just this compatible.
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + 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: 4
Generally we put this before 'items'.
> +
> + clock-names:
> + items:
> + - const: core
> + - const: axi
> + - const: ahb
> + - const: pix0
> + - const: pix1
> + minItems: 4
> +
> + resets:
> + items:
> + - description: DC Core reset
> + - description: DMA AXI bus reset
> + - description: Configuration AHB bus reset
> +
> + reset-names:
> + items:
> + - const: core
> + - const: axi
> + - const: ahb
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: The first output channel, endpoint 0 should be
> + used for DPI format output and endpoint 1 should be used
> + for DP format output.
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description: The second output channel if the DC variant
> + supports and used. Follow the same endpoint addressing
> + rule with the first port.
> +
> + required:
> + - port@0
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/clock/thead,th1520-clk-ap.h>
> + #include <dt-bindings/reset/thead,th1520-reset.h>
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + display@ffef600000 {
> + compatible = "verisilicon,dc";
> + reg = <0xff 0xef600000 0x0 0x100000>;
> + interrupts = <93 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk_vo CLK_DPU_CCLK>,
> + <&clk_vo CLK_DPU_ACLK>,
> + <&clk_vo CLK_DPU_HCLK>,
> + <&clk_vo CLK_DPU_PIXELCLK0>,
> + <&clk_vo CLK_DPU_PIXELCLK1>;
> + clock-names = "core", "axi", "ahb", "pix0", "pix1";
> + resets = <&rst TH1520_RESET_ID_DPU_CORE>,
> + <&rst TH1520_RESET_ID_DPU_AXI>,
> + <&rst TH1520_RESET_ID_DPU_AHB>;
> + reset-names = "core", "axi", "ahb";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + port@0 {
> + reg = <0>;
> + };
> +
> + port@1 {
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dpu_out_dp1: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&hdmi_in>;
> + };
> + };
> + };
> + };
> + };
> --
> 2.50.1
>
On 15/08/2025 00:04, Rob Herring wrote:
>> +
>> +maintainers:
>> + - Icenowy Zheng <uwu@icenowy.me>
>> +
>> +properties:
>> + $nodename:
>> + pattern: "^display@[0-9a-f]+$"
>> +
>> + compatible:
>> + const: verisilicon,dc
>
> If the clocks or resets varies by platform, then you need an SoC
> specific compatible still. If these clocks/resets are straight from the
> RTL and any other number of clocks/resets is wrong, then we can stick
> with just this compatible.
Shouldn't we have here always SoC compatible? Can it be ever used alone,
outside of given SoC?
I could imagine now:
items:
- {}
- const: verisilicon,dc
Best regards,
Krzysztof
在 2025-08-15星期五的 11:09 +0200，Krzysztof Kozlowski写道：
> On 15/08/2025 00:04, Rob Herring wrote:
> > > +
> > > +maintainers:
> > > + - Icenowy Zheng <uwu@icenowy.me>
> > > +
> > > +properties:
> > > + $nodename:
> > > + pattern: "^display@[0-9a-f]+$"
> > > +
> > > + compatible:
> > > + const: verisilicon,dc
> >
> > If the clocks or resets varies by platform, then you need an SoC
> > specific compatible still. If these clocks/resets are straight from
> > the
> > RTL and any other number of clocks/resets is wrong, then we can
> > stick
> > with just this compatible.
>
> Shouldn't we have here always SoC compatible? Can it be ever used
> alone,
> outside of given SoC?
>
> I could imagine now:
>
> items:
> - {}
> - const: verisilicon,dc
I followed the `vivante,gc` situation here, because the registers
before 0x1400 (where real display-related things start) seems to follow
the same scheme with GC-series GPUs, including the identification
registers.
>
>
> Best regards,
> Krzysztof
在 2025-08-15星期五的 17:53 +0800，Icenowy Zheng写道：
> 在 2025-08-15星期五的 11:09 +0200，Krzysztof Kozlowski写道：
> > On 15/08/2025 00:04, Rob Herring wrote:
> > > > +
> > > > +maintainers:
> > > > + - Icenowy Zheng <uwu@icenowy.me>
> > > > +
> > > > +properties:
> > > > + $nodename:
> > > > + pattern: "^display@[0-9a-f]+$"
> > > > +
> > > > + compatible:
> > > > + const: verisilicon,dc
> > >
> > > If the clocks or resets varies by platform, then you need an SoC
> > > specific compatible still. If these clocks/resets are straight
> > > from
> > > the
> > > RTL and any other number of clocks/resets is wrong, then we can
> > > stick
> > > with just this compatible.
> >
> > Shouldn't we have here always SoC compatible? Can it be ever used
> > alone,
> > outside of given SoC?
> >
> > I could imagine now:
> >
> > items:
> > - {}
> > - const: verisilicon,dc
>
> I followed the `vivante,gc` situation here, because the registers
> before 0x1400 (where real display-related things start) seems to
> follow
> the same scheme with GC-series GPUs, including the identification
> registers.
An example here: the customer id (0x0030) register value read out on T-
Head TH1520 is 0x30a, but on StarFive JH6110 it's 0x30e instead.
(Both are DC8200 rev 5720, so the 0x0020 reg is 0x8200 and 0x0024 reg
is 0x5720.)
>
> >
> >
> > Best regards,
> > Krzysztof
>
在 2025-08-14星期四的 17:04 -0500，Rob Herring写道：
> On Fri, Aug 15, 2025 at 12:40:42AM +0800, Icenowy Zheng wrote:
> > Verisilicon has a series of display controllers prefixed with DC
> > and
> > with self-identification facility like their GC series GPUs.
> >
> > Add a device tree binding for it.
> >
> > Depends on the specific DC model, it can have either one or two
> > display
> > outputs, and each display output could be set to DPI signal or "DP"
> > signal (which seems to be some plain parallel bus to HDMI
> > controllers).
> >
> > Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
> > ---
> > .../bindings/display/verisilicon,dc.yaml | 127
> > ++++++++++++++++++
> > 1 file changed, 127 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > new file mode 100644
> > index 0000000000000..2f71a811786aa
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > @@ -0,0 +1,127 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/verisilicon,dc.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Verisilicon DC-series display controllers
> > +
> > +maintainers:
> > + - Icenowy Zheng <uwu@icenowy.me>
> > +
> > +properties:
> > + $nodename:
> > + pattern: "^display@[0-9a-f]+$"
> > +
> > + compatible:
> > + const: verisilicon,dc
>
> If the clocks or resets varies by platform, then you need an SoC
> specific compatible still. If these clocks/resets are straight from
> the
> RTL and any other number of clocks/resets is wrong, then we can stick
> with just this compatible.
I deduced this 5 clocks pattern based on block diagrams on two SoCs's
manual, see [1] page 528 and [2] page 7 (page 1 shown on the footer).
Well, ironically, neither of BSP device tree of these two SoCs ([3]
[4]) list 5 clocks in the dc8200 device tree node, but the extra clocks
mostly look nonsense (even things like JH7110_SYSCLK_NOC_BUS_DISP_AXI
appeared in [4]).
[1]
https://doc-en.rvspace.org/JH7110/PDF/JH7110_TRM_StarFive_Preliminary_V2.pdf
[2]
https://git.beagleboard.org/beaglev-ahead/beaglev-ahead/-/raw/main/docs/TH1520%20Video%20Output%20User%20Manual.pdf
[3]
https://github.com/revyos/th1520-linux-kernel/blob/th1520-lts/arch/riscv/boot/dts/thead/th1520.dtsi#L1702
[4]
https://github.com/starfive-tech/linux/blob/JH7110_VisionFive2_6.12.y_devel/arch/riscv/boot/dts/starfive/jh7110.dtsi#L1576
>
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + 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: 4
>
> Generally we put this before 'items'.
Sounds reasonable, although I might add explicit maxItems: 5 if put
before items.
>
> > +
> > + clock-names:
> > + items:
> > + - const: core
> > + - const: axi
> > + - const: ahb
> > + - const: pix0
> > + - const: pix1
> > + minItems: 4
> > +
> > + resets:
> > + items:
> > + - description: DC Core reset
> > + - description: DMA AXI bus reset
> > + - description: Configuration AHB bus reset
> > +
> > + reset-names:
> > + items:
> > + - const: core
> > + - const: axi
> > + - const: ahb
> > +
> > + ports:
> > + $ref: /schemas/graph.yaml#/properties/ports
> > +
> > + properties:
> > + port@0:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: The first output channel, endpoint 0 should
> > be
> > + used for DPI format output and endpoint 1 should be used
> > + for DP format output.
> > +
> > + port@1:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + description: The second output channel if the DC variant
> > + supports and used. Follow the same endpoint addressing
> > + rule with the first port.
> > +
> > + required:
> > + - port@0
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - clocks
> > + - clock-names
> > + - ports
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > + #include <dt-bindings/clock/thead,th1520-clk-ap.h>
> > + #include <dt-bindings/reset/thead,th1520-reset.h>
> > + soc {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + display@ffef600000 {
> > + compatible = "verisilicon,dc";
> > + reg = <0xff 0xef600000 0x0 0x100000>;
> > + interrupts = <93 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&clk_vo CLK_DPU_CCLK>,
> > + <&clk_vo CLK_DPU_ACLK>,
> > + <&clk_vo CLK_DPU_HCLK>,
> > + <&clk_vo CLK_DPU_PIXELCLK0>,
> > + <&clk_vo CLK_DPU_PIXELCLK1>;
> > + clock-names = "core", "axi", "ahb", "pix0", "pix1";
> > + resets = <&rst TH1520_RESET_ID_DPU_CORE>,
> > + <&rst TH1520_RESET_ID_DPU_AXI>,
> > + <&rst TH1520_RESET_ID_DPU_AHB>;
> > + reset-names = "core", "axi", "ahb";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + port@0 {
> > + reg = <0>;
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + dpu_out_dp1: endpoint@1 {
> > + reg = <1>;
> > + remote-endpoint = <&hdmi_in>;
> > + };
> > + };
> > + };
> > + };
> > + };
> > --
> > 2.50.1
> >
On Fri, 15 Aug 2025 00:40:42 +0800, Icenowy Zheng wrote: > Verisilicon has a series of display controllers prefixed with DC and > with self-identification facility like their GC series GPUs. > > Add a device tree binding for it. > > Depends on the specific DC model, it can have either one or two display > outputs, and each display output could be set to DPI signal or "DP" > signal (which seems to be some plain parallel bus to HDMI controllers). > > Signed-off-by: Icenowy Zheng <uwu@icenowy.me> > --- > .../bindings/display/verisilicon,dc.yaml | 127 ++++++++++++++++++ > 1 file changed, 127 insertions(+) > create mode 100644 Documentation/devicetree/bindings/display/verisilicon,dc.yaml > My bot found errors running 'make dt_binding_check' on your patch: yamllint warnings/errors: dtschema/dtc warnings/errors: Lexical error: Documentation/devicetree/bindings/display/verisilicon,dc.example.dts:41.28-52 Unexpected 'TH1520_RESET_ID_DPU_CORE' Lexical error: Documentation/devicetree/bindings/display/verisilicon,dc.example.dts:42.22-45 Unexpected 'TH1520_RESET_ID_DPU_AXI' Lexical error: Documentation/devicetree/bindings/display/verisilicon,dc.example.dts:43.22-45 Unexpected 'TH1520_RESET_ID_DPU_AHB' FATAL ERROR: Syntax error parsing input tree make[2]: *** [scripts/Makefile.dtbs:132: Documentation/devicetree/bindings/display/verisilicon,dc.example.dtb] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1527: dt_binding_check] Error 2 make: *** [Makefile:248: __sub-make] Error 2 doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20250814164048.2336043-3-uwu@icenowy.me The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema.
© 2016 - 2025 Red Hat, Inc.