linux-kernel - RE: [PATCH 10/22] dt-bindings: display: renesas,rzg2l-du: Add support for RZ/G3E SoC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
 <TY3PR01MB113463EE3F22A0E0E6C97DC40868CA@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Thu, 15 Jan 2026 10:10:21 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: geert <geert@...ux-m68k.org>, laurent.pinchart
	<laurent.pinchart@...asonboard.com>
CC: Tommaso Merciai <tommaso.merciai.xr@...renesas.com>, Krzysztof Kozlowski
	<krzk@...nel.org>, Tommaso Merciai <tomm.merciai@...il.com>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	Andrzej Hajda <andrzej.hajda@...el.com>, Neil Armstrong
	<neil.armstrong@...aro.org>, Robert Foss <rfoss@...nel.org>, laurent.pinchart
	<laurent.pinchart@...asonboard.com>, Jonas Karlman <jonas@...boo.se>, Jernej
 Skrabec <jernej.skrabec@...il.com>, David Airlie <airlied@...il.com>, Simona
 Vetter <simona@...ll.ch>, Maarten Lankhorst
	<maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>, Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
	Michael Turquette <mturquette@...libre.com>, Stephen Boyd <sboyd@...nel.org>,
	magnus.damm <magnus.damm@...il.com>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-clk@...r.kernel.org"
	<linux-clk@...r.kernel.org>
Subject: RE: [PATCH 10/22] dt-bindings: display: renesas,rzg2l-du: Add support
 for RZ/G3E SoC

Hi Geert,

Thanks for the feedback.

> -----Original Message-----
> From: Geert Uytterhoeven <geert@...ux-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 <biju.das.jz@...renesas.com> wrote:
> > > From: Geert Uytterhoeven <geert@...ux-m68k.org> On Wed, 3 Dec 2025
> > > at 14:42, Tommaso Merciai <tommaso.merciai.xr@...renesas.com> wrote:
> > > > On Wed, Dec 03, 2025 at 09:23:53AM +0100, Krzysztof Kozlowski wrote:
> > > > > On Wed, Nov 26, 2025 at 03:07:22PM +0100, 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 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.

> 
> > Standalone LVDS and DSI the programming flow is same.
> 
> OK.
> 
> > > 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.

> 
> > 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


Cheers,
Biju