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:
 <TY3PR01MB11346DB362955A62D2A2E828A868CA@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Thu, 15 Jan 2026 10:34:30 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: geert <geert@...ux-m68k.org>
CC: laurent.pinchart <laurent.pinchart@...asonboard.com>, 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>,
	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 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 <biju.das.jz@...renesas.com> wrote:
> > > From: Geert Uytterhoeven <geert@...ux-m68k.org> 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.
> 
> 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.

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

> 
> > > 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.
> 
> That's two ports for LVDS (i.e. "twice"), right?

Yes, you are correct.

Cheers,
Biju