Hi Geert, Thanks for the feedback.
> -----Original Message----- > From: Geert Uytterhoeven <[email protected]> > 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 <[email protected]> wrote: > > > From: Geert Uytterhoeven <[email protected]> On Thu, 15 Jan 2026 > > > at 08:48, Biju Das <[email protected]> wrote: > > > > > From: Geert Uytterhoeven <[email protected]> On Wed, 3 Dec > > > > > 2025 at 14:42, Tommaso Merciai <[email protected]> > > > > > 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
