Hi Geert,

Thanks for the feedback.

-----Original Message-----
From: Geert Uytterhoeven <geert@linux-m68k.org>
Sent: 15 January 2026 10:22
Subject: Re: [PATCH 10/22] dt-bindings: display: renesas,rzg2l-du: Add support for RZ/G3E SoC

Hi Biju,

On Thu, 15 Jan 2026 at 11:10, Biju Das [off-list ref] wrote:

quoted

quoted

From: Geert Uytterhoeven <geert@linux-m68k.org> On Thu, 15 Jan 2026
at 08:48, Biju Das [off-list ref] wrote:

quoted

quoted

From: Geert Uytterhoeven <geert@linux-m68k.org> On Wed, 3 Dec
2025 at 14:42, Tommaso Merciai [off-list ref] wrote:

quoted

On Wed, Dec 03, 2025 at 09:23:53AM +0100, Krzysztof Kozlowski wrote:

quoted

On Wed, Nov 26, 2025 at 03:07:22PM +0100, Tommaso Merciai wrote:

quoted

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 then two new SoC-specific compatible strings 'renesas,r9a09g047-du0'
and 'renesas,r9a09g047-du1'.

LCDC0/1 but compatibles du0/du1...

What are the differences between DU0 and DU1? Just different
outputs? Is the programming model the same?

The hardware configurations are different: these are two distinct hardware blocks.

Based on the block diagrams shown in Figures 9.4-2 (LCDC1) and
9.4-1 (LCDC0), the only difference concerns the output, but
this variation is internal to the hardware blocks themselves.
Therefore, LCDC0 and LCDC1 are not identical blocks, and their
programming models differ as a result.

In summary, although most of the internal functions are the
same, the two blocks have output signals connected to different components within the SoC.
This requires different hardware configurations and inevitably
leads to different programming models for LCDC0 and LCDC1.

Isn't that merely an SoC integration issue?
Are there any differences in programming LCDC0 or LCDC1 for the
common output types supported by both (single channel LVDS and 4-lane MIPI-DSI)?

Dual LVDS case, dot clock from LCDC0 is used in both LCDC's.

For the single dual-channel LVDS output on LCDC0, or for using two
independent LVDS outputs on both instances? How is this handled?

Dual-channel LVDS output on LCDC0, we use the data from LCDC0.

That's the "dual-link" case below? But that case doesn't use LCDC1 at all, so how can "dot clock from
LCDC0 is used in both LCDC's" be true?

That is a typo. Sorry for that.

What am I missing?

Dual-link case, LVDS_TOP_CLK_CH0, LVDS_TOP_CLK_DOT_CH0 used to drive both the LVDS channels.
In this case, the clks LVDS_TOP_CLK_CH1, LVDS_TOP_CLK_DOT_CH1 are not used.

quoted

We have the following use cases:

Single-link(ch0 only):
  This mode outputs the image data of LCDC0 to LVDS (ch0). In this mode,
  LVDS (ch1) is not used.

Single-link(ch1 only):
  This mode outputs the image data of LCDC1 to LVDS (ch1).
  In this mode, LVDS (ch0) is not used.

Single-link(2ch):
  In this mode, the image data of LCDC0 is output to LVDS (ch0) and the
  image data of LCDC1 is output to LVDS (ch1).
  Since LVDS (ch0) and LVDS (ch1) are not synchronously related, they
  can be output in different image formats and can be operated asynchronously.

Single-link(Multi)
  In this mode, the image data of LCDC0 is output to both LVDS (ch0) and
  LVDS (ch1). LVDS (ch0) and LVDS (ch1) operate synchronously.

Dual-link:
  In this mode, the input image data from LCDC0 is separated into Even pixels and
  Odd pixels, and the output is distributed to LVDS ch0 and ch1.

quoted

Don't you need a companion property to link them together?

Yes, We use companion property for Dual channel LVDS(Dual-Link) use case.

quoted

Is this similar to dual-channel LVDS on R-Car E3 and RZ/G2E?

Yes.

OK, "companion" is in the renesas,lvds bindings, which are not yet updated for RZ/G3E? Do you need it
in "renesas,rzg2l-du", too?

Not required. Without that it works like RZ/G2E.

quoted

quoted

On these SoCs we have a single combined device node for all DU
instances (which comes with its own set of issues, e.g. Runtime PM and Clock Domain handling).

But in our case, it has 2 separate independent LCDC IP's to allow all the possible outputs as

mentioned above.

quoted

quoted

quoted

Standalone LVDS and DSI the programming flow is same.

OK.

quoted

quoted

Of there are no such differences, both instances should use the same compatible value.

Then we need to use a property called display-id, to describe the
supported output types in bindings, right??

Display-id=0 {LVDS, DSI)

LVDS twice?

LCDC0 supports DSI and LVDS (single or dual-channel) outputs.

That's two ports for LVDS (i.e. "twice"), right?

Yes, you are correct.

Cheers,
Biju