Re: [PATCH v6 10/21] dt-bindings: display: renesas,rzg2l-du: Add support for RZ/G3E SoC
From: Tommaso Merciai
Date: Fri Apr 10 2026 - 09:29:02 EST
Hi Laurent,
On 4/9/26 15:24, Laurent Pinchart wrote:
On Thu, Apr 09, 2026 at 01:15:18PM +0200, Tommaso Merciai wrote:
On 4/8/26 17:00, Laurent Pinchart wrote:
On Wed, Apr 08, 2026 at 04:44:48PM +0200, Tommaso Merciai wrote:
On 4/8/26 16:16, Laurent Pinchart wrote:
On Wed, Apr 08, 2026 at 04:02:14PM +0200, Tommaso Merciai wrote:
On 4/8/26 14:24, Laurent Pinchart wrote:
On Wed, Apr 08, 2026 at 12:36:55PM +0200, Tommaso Merciai wrote:
The RZ/G3E SoC has 2 LCD controllers (LCDC), each containing a Frame
Compression Processor (FCPVD), a Video Signal Processor (VSPD), and a
Display Unit (DU).
- LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
- LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
Add a new SoC-specific compatible string 'renesas,r9a09g047-du'.
Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" to
allow up to four output ports, and explicitly disable port@2 and port@3
for existing SoCs that do not expose them.
Describe the four output ports of the RZ/G3E DU:
- port@0: DSI (available on both LCDC instances)
- port@1: DPAD / parallel RGB (LCDC1 only)
- port@2: LVDS channel 0 (LCDC0 only)
- port@3: LVDS channel 1 (available on both LCDC instances)
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@xxxxxxxxxxxxxx>
---
v5->v6:
- Extend patternProperties from "^port@[0-1]$" to "^port@[0-3]$" and
explicitly disable port@2 and port@3 for existing SoCs that do not expose
them.
- Reworked ports numbering + improved/fixed ports descriptions in the
bindings documentation.
- Improved commit body.
v4->v5:
- Dropped renesas,id property and updated bindings
accordingly.
v2->v3:
- No changes.
v2->v3:
- No changes.
v1->v2:
- Use single compatible string instead of multiple compatible strings
for the two DU instances, leveraging a 'renesas,id' property to
differentiate between DU0 and DU1.
- Updated commit message accordingly.
.../bindings/display/renesas,rzg2l-du.yaml | 30 ++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
index 5add3b832eab..32da0b5ec88c 100644
--- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
+++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
@@ -20,6 +20,7 @@ properties:
- enum:
- renesas,r9a07g043u-du # RZ/G2UL
- renesas,r9a07g044-du # RZ/G2{L,LC}
+ - renesas,r9a09g047-du # RZ/G3E
- renesas,r9a09g057-du # RZ/V2H(P)
- items:
- enum:
@@ -61,7 +62,7 @@ properties:
model-dependent. Each port shall have a single endpoint.
patternProperties:
- "^port@[0-1]$":
+ "^port@[0-3]$":
$ref: /schemas/graph.yaml#/properties/port
unevaluatedProperties: false
@@ -103,6 +104,8 @@ allOf:
port@0:
description: DPI
port@1: false
+ port@2: false
+ port@3: false
required:
- port@0
@@ -119,6 +122,8 @@ allOf:
description: DSI
port@1:
description: DPI
+ port@2: false
+ port@3: false
required:
- port@0
@@ -135,9 +140,32 @@ allOf:
port@0:
description: DSI
port@1: false
+ port@2: false
+ port@3: false
required:
- port@0
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: renesas,r9a09g047-du
+ then:
+ properties:
+ ports:
+ properties:
+ port@0:
+ description: DSI
+ port@1:
+ description: DPAD
+ port@2:
+ description: LVDS, Channel 0
+ port@3:
+ description: LVDS, Channel 1
+
+ required:
+ - port@0
+ - port@3
Why are ports 1 and 2 not required ?
About this we had a similar discussion on v5[0]
We are using the same compatible and:
- LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
|
--> then has:
port@0
port@2
port@3
- LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
|
--> then has:
port@0
port@1
port@3
Ah yes, I forget there are two LCDC instances with different output
configurations.
Something still looks a bit weird to me though. For LCDC1, which
supports a single LVDS channel, you use the port described as the second
LVDS channel. Is there a reason not to use port@2 ?
9.11 Low Voltage Differential Signaling (LVDS)
9.11.1.2 Block Diagram
Figure 9.11-1 shows a block diagram of LVDS.
LCDC1 is connected to LVDS, Channel 1
For this reason I'm using port@3.
Re-reading that, I think I've misinterpreted the hardware architecture.
Doesn't the DU have a single output, that is connected the multiple
encoders (LVDS and DSI for LCDC0 and LVDS, DSI and DPI for LCDC1) ? It
seems modelling it with a single port and multiple endpoints would
better match the device.
For LVDS in particular, I see a single LVDS encoder with two channels,
so there should not be two LVDS output ports in the DU. The two ports
should be on the output of the LVDS device.
You are suggesting the following dt architecture:
du0: display@16460000 {
compatible = "renesas,r9a09g047-du";
reg = <0 0x16460000 0 0x10000>;
interrupts = <GIC_SPI 882 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 0xed>,
<&cpg CPG_MOD 0xee>,
<&cpg CPG_MOD 0xef>;
clock-names = "aclk", "pclk", "vclk";
power-domains = <&cpg>;
resets = <&cpg 0xdc>;
renesas,vsps = <&vspd0 0>;
status = "disabled";
port {
du0_out_dsi: endpoint@0 {
reg = <0>;
};
du0_out_lvds0: endpoint@2 {
reg = <2>;
};
du0_out_lvds1: endpoint@3 {
reg = <3>;
};
}
};
du1: display@16490000 {
compatible = "renesas,r9a09g047-du";
reg = <0 0x16490000 0 0x10000>;
interrupts = <GIC_SPI 922 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 0x1a8>,
<&cpg CPG_MOD 0x1a9>,
<&cpg CPG_MOD 0x1aa>;
clock-names = "aclk", "pclk", "vclk";
power-domains = <&cpg>;
resets = <&cpg 0x11e>;
renesas,vsps = <&vspd1 0>;
status = "disabled";
port {
du1_out_dsi: endpoint@0 {
reg = <0>;
};
du1_out_rgb: endpoint@1 {
reg = <1>;
};
du1_out_lvds1: endpoint@3 {
reg = <3>;
};
}
};
Please correct me if I'm wrong.
That's right. It would match the hardware, or at least my understanding
of the hardware based on the documentation. As far as I can tell, each
DU has a single 24-bit output port connected to multiple encoders.
Thanks for the clarification.
I want to make sure I understand the intended architecture correctly,
because I see a potential conflict between your feedback on the two patches.
For [1], you confirmed the two separate DU nodes (DU0 and DU1) with the
single-port/multi-endpoint model. That maps to two separate platform devices, which means two separate DRM devices.
For [2], you suggested:
"you can have one DRM device that covers two LCDCs, with one CRTC each,
both connected to the same DSI encoder. Userspace then selects which
CRTC drives which connector."
Please correct me if I'm wrong but to me these two appear to be incompatible. With two separate DRM devices,the DSI encoder and its connector can only belong to one of them. Userspace cannot select between CRTCs across two DRM devices.
To support the single-DRM-device model you describe, both DU0 and DU1 would need to be managed by a single driver instance, similar to R-Car DU which aggregate multiple LCDC channels into one DRM device.
Using a single DRM device that spawn 2 crtc (1 du dt node ) this use case can be tested with the following cmds:
modetest -M rzg2l-du -s 58@55:800x600-56.25@XR24
modetest -M rzg2l-du -s 58@56:800x600-56.25@XR24
Could you clarify which architecture is the intended direction?
Option A: Two separate DRM devices (2 DU dt nodes, current approach),
with the DSI input selected via DT configuration.
The dynamic vclk selection I implemented still applies,
but runtime CRTC switching from userspace is not possible.
Option B: A single DRM device aggregating both DU instances (1 DU dt node),
with two CRTCs both connected to the DSI encoder.
[1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/8f814f22ff62dcde6153260e2c8c29a5415c9a89.1775636898.git.tommaso.merciai.xr@xxxxxxxxxxxxxx/
[2] https://patchwork.kernel.org/project/linux-renesas-soc/patch/9e0f64dd5e1efb0d27219416121c91a19da96ebd.1775636898.git.tommaso.merciai.xr@xxxxxxxxxxxxxx/
Kind Regards,
Tommaso
Then port@1 is required for DU1 but not for DU0.
Same port@2 is required for DU0 but not for DU1.
[0] https://patchwork.kernel.org/project/linux-renesas-soc/patch/ca022fdbba5236c36e0cb3095db4c31e8e0cb1b8.1770996493.git.tommaso.merciai.xr@xxxxxxxxxxxxxx/
examples:
# RZ/G2L DU