Hi Geert,

Thanks for the feedback.

-----Original Message-----
From: Geert Uytterhoeven <geert@linux-m68k.org>
Sent: 15 January 2026 08:24
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 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.

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.

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

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

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

Yes.

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

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.

quoted

Display-id=1 {LVDS, DSI, DPI)

LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.

Not necessarily: if this is purely different SoC integration per instance, describing all possible
options is fine.

But I'd like to defer to Laurent for the details...

OK. Glad to hear from Laurent's input for this and [1]

[1] https://lore.kernel.org/linux-renesas-soc/cover.1764165783.git.tommaso.merciai.xr@bp.renesas.com/T/#m291f02a0ee074d5159705b19d2d29ffa41ef4eaa (local)


Cheers,
Biju