Re: [PATCH v8 1/9] dt-bindings: display: renesas,rzg2l-du: Document RZ/G3E SoC
From: Tommaso Merciai
Date: Wed Sep 09 2026 - 13:01:36 EST
Hi Philipp,
Thanks for your feedback.
On Thu, Sep 03, 2026 at 10:17:23AM +0200, Philipp Zabel wrote:
> On Mi, 2026-09-02 at 17:11 +0200, Tommaso Merciai wrote:
> > On Wed, Sep 02, 2026 at 04:20:51PM +0200, Geert Uytterhoeven wrote:
> > > Hi all,
> > >
> > > On Wed, 2 Sept 2026 at 16:03, Tommaso Merciai
> > > <tommaso.merciai.xr@xxxxxxxxxxxxxx> wrote:
> > > > On Wed, Sep 02, 2026 at 08:37:06AM +0200, Krzysztof Kozlowski wrote:
> > > > > On Fri, Aug 28, 2026 at 02:21:04PM +0200, Tommaso Merciai wrote:
> > > > > > The RZ/G3E Soc has 2 LCD controller (LCDC), contain a Frame Compression
> > > > > > Processor (FCPVD), a Video Signal Processor (VSPD), Video Signal
> > > > > > Processor (VSPD), and Display Unit (DU).
> > > > > >
> > > > > > - LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
> > > > > > - LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
> > > > > >
> > > > > > Add new SoC-specific compatible string 'renesas,r9a09g047-du'.
> > > > > >
> > > > > > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@xxxxxxxxxxxxxx>
> > >
> > > > > > --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > > > > > +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml
> > > > > > @@ -21,6 +21,7 @@ properties:
> > > > > > - renesas,r9a07g043u-du # RZ/G2UL
> > > > > > - renesas,r9a07g044-du # RZ/G2{L,LC}
> > > > > > - renesas,r9a08g046-du # RZ/G3L
> > > > > > + - renesas,r9a09g047-du # RZ/G3E
> > > > > > - renesas,r9a09g057-du # RZ/V2H(P)
> > > > > > - renesas,r9a09g077-du # RZ/T2H
> > > > > > - items:
> > > > > > @@ -35,25 +36,51 @@ properties:
> > > > > > - const: renesas,r9a09g077-du # RZ/T2H fallback
> > > > > >
> > > > > > reg:
> > > > > > - maxItems: 1
> > > > > > + minItems: 1
> > > > > > + maxItems: 2
> > > > > > +
> > > > > > + reg-names:
> > > > > > + items:
> > > > > > + - const: du.0
> > > > > > + - const: du.1
> > > > >
> > > > > du is the name of the device, thus calling items "0" and "1" is pretty
> > > > > pointless - indices already define that. Please drop the reg-names.
> > > >
> > > > Will drop this in v8.
> > > >
> > > > > > interrupts:
> > > > > > - maxItems: 1
> > > > > > + minItems: 1
> > > > > > + maxItems: 2
> > > > > > +
> > > > > > + interrupt-names:
> > > > > > + items:
> > > > > > + - const: du.0
> > > > > > + - const: du.1
> > > > >
> > > > > Same here
> > > >
> > > > Same, thanks.
> > > >
> > > > >
> > > > > >
> > > > > > clocks:
> > > > > > + minItems: 3
> > > > > > items:
> > > > > > - description: Main clock
> > > > > > - description: Register access clock
> > > > > > - description: Video clock
> > > > > > + - description: Main clock for DU1
> > > > > > + - description: Register access clock for DU1
> > > > > > + - description: Video clock for DU1
> > > > > >
> > > > > > clock-names:
> > > > > > + minItems: 3
> > > > > > items:
> > > > > > - const: aclk
> > > > > > - const: pclk
> > > > > > - const: vclk
> > > > > > + - const: aclk1
> > > > > > + - const: pclk1
> > > > > > + - const: vclk1
> > > > > >
> > > > > > resets:
> > > > > > - maxItems: 1
> > > > > > + minItems: 1
> > > > > > + maxItems: 2
> > > > > > +
> > > > > > + reset-names:
> > > > > > + items:
> > > > > > + - const: resetn
> > > > > > + - const: resetn1
> > > > >
> > > > > Drop reset-names
> > > >
> > > > For reset-names, I got the the following comment from Philipp in v7 [1].
> > > >
> > > > Dropping reset-names would force the driver back to an index-based
> > > > lookup, which is what that comment explicitly asked me to avoid.
> > > >
> > > > [1] https://lore.kernel.org/all/8382e2b9fd07fb1132c26e228b3899336fc1fdd4.camel@xxxxxxxxxxxxxx/
> > > >
> > > > Philipp, Krzysztof, could you agree on which way you'd prefer?
> > > > I'll follow whatever you decide.
> > >
> > > Until we get a variant with a third interrupt (or reset or reg),
> > > which is not related to the number of channels...
> >
> > Right, IMHO names keep the driver flexible enough for such a variant,
> > indices don't.
>
> I would like to get rid of the reset_control_get_by_index() API
> altogether, if possible. Currently there are only users with index ==
> 0, so this would be the first and so far only valid user. I'd prefer if
> we could keep reset lookup aligned with clock lookup, with via clock-
> names as well.
>
> That being said, why are the two DU units represented as a single
> device tree node at all? Aren't they two completely separate instances
> of the same IP core?
They are, and maybe describing them as one node was the wrong call.
Let me explain what pushed me there, because it also settles the
reset-names question above.
RZ/G3E instantiates the LCDC twice, and some outputs can be driven by
either instance. DSI is wired to both and the LVDS channel 1 same.
For userspace to pick the source at runtime, the two CRTCs and that
output's encoder have to live in the same drm_device.
With one drm_device per DU node, an output reachable from both instances
can only be exposed on one card, and the other instance is unreachable for it.
So I merged the two instances into a single DT node to obtain that
single drm_device.
That solves a driver issue but maybe distorting the hardware description.
The right shape maybe can be the virtual subsystem node already used by
other DRM drivers:
- fsl,imx-display-subsystem [1]
- rockchip,display-subsystem [2]
- sprd,display-subsystem [3].
Maybe we can have:
display-subsystem {
compatible = "renesas,r9a09g047-display-subsystem";
ports = <&du0_ports>, <&du1_ports>;
};
with du0 and du1 nodes:
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";
du0_ports: ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
du0_out_dsi: endpoint {
};
};
port@2 {
reg = <2>;
du0_out_lvds0: endpoint {
};
};
port@3 {
reg = <3>;
du0_out_lvds1: endpoint {
};
};
};
};
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";
du1_ports: ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
du1_out_dsi: endpoint {
};
};
port@1 {
reg = <1>;
du1_out_rgb: endpoint {
};
};
port@3 {
reg = <3>;
du1_out_lvds1: endpoint {
};
};
};
};
Each node then carries a single reg, a single interrupt, three clocks
and a single reset.
With this solution reg-names, interrupt-names and reset-names all go away.
This will need one new binding:
Documentation/devicetree/bindings/display/renesas,r9a09g047-drm.yaml
For describint the "renesas,r9a09g047-display-subsystem", a virtual device
that groups the Display Unit instances comprising the graphics subsystem.
The existing renesas,rzg2l-du.yaml keeps describing a single DU instance
unchanged, which is what the v5 approach [4] already did.
What this buys at runtime, with both DU nodes enabled: the SoC DTS wires
DSI to both instances, so the DSI encoder ends up with both CRTCs in its
possible_crtcs mask and userspace can move the output between them:
e.g.
modetest -M rzg2l-du -s <dsi-connector-0>@<crtc0>:1920x1080-59.94@XR24
modetest -M rzg2l-du -s <dsi-connector-0>@<crtc1>:1920x1080-59.94@XR24
LVDS channel 1 is the same situation in hardware.
What do you think?
[1] https://elixir.bootlin.com/linux/v7.3-rc1/source/Documentation/devicetree/bindings/display/imx/fsl,imx-display-subsystem.yaml
[2] https://elixir.bootlin.com/linux/v7.3-rc1/source/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml
[3] https://elixir.bootlin.com/linux/v7.3-rc1/source/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml
[4] https://lore.kernel.org/all/ca022fdbba5236c36e0cb3095db4c31e8e0cb1b8.1770996493.git.tommaso.merciai.xr@xxxxxxxxxxxxxx/
Kind regards,
Tommaso
>
> regards
> Philipp