On Sat, May 02, 2026 at 11:17:22PM +0200, Marek Vasut wrote: > On 4/29/26 11:57 AM, Geert Uytterhoeven wrote: > > On Sun, 19 Apr 2026 at 21:37, Marek Vasut wrote: > >> Extend the Renesas DU display bindings to support the Renesas R-Car > >> R8A779MD M3Le SoC. This SoC is similar to R-Car R8A77965 M3-N SoC, > >> except the HDMI port@1 is not present. > > > > "and DU1 is unused." (whatever that may mean...) > > Fixed in V2. > > >> +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml > >> @@ -42,6 +42,7 @@ properties: > >> - renesas,du-r8a779a0 # for R-Car V3U compatible DU > >> - renesas,du-r8a779g0 # for R-Car V4H compatible DU > >> - renesas,du-r8a779h0 # for R-Car V4M compatible DU > >> + - renesas,du-r8a779md # for R-Car M3Le compatible DU > > > > I am not sure you need a new compatible value: is the DU really > > different than on R-Car M3-N, or does it just lack some wiring? ... > > It seems the DU is identical to the M3N one, so I will add another entry > to R8A77965 DU to handle the M3Le one, just like R8A774B1 and R8A774E1 > DUs . I hope that is acceptable, and also addresses the feedback on this > patch ? > > I dumped the VSP and FCP versions on M3N and M3Le and compared them, and > I also wrote and read-back the CMM registers to confirm CMM IPs are all > present on both M3N and M3Le: > > FCP is identical on M3N and M3Le: > fe950000.fcp FCP_VCR=0x106 > fe96f000.fcp FCP_VCR=0x106 > fe9af000.fcp FCP_VCR=0x106 > fea27000.fcp FCP_VCR=0x106 > fea2f000.fcp FCP_VCR=0x106 > > VSP is identical on M3N and M3Le: > fe960000.vsp IP_VERSION=0x01011504 > fe9a0000.vsp IP_VERSION=0x01011404 > fea20000.vsp IP_VERSION=0x01011904 > fea28000.vsp IP_VERSION=0x01011704 > > CMMs are present on M3N and M3Le, tested with write of bits 28 and 24 > into CM2_CLU_CTRL and then readback: > fea40000.cmm CM2_CLU_CTRL readback 0x11000000 > fea50000.cmm CM2_CLU_CTRL readback 0x11000000 > fea70000.cmm CM2_CLU_CTRL readback 0x11000000 > > And it does indeed look like we do have DOTCLKIN1 .
So the die seems to be the same as M3N, just with some signals not wired up. We could simply drop the HDMI output port in DT as Geert proposed. I'm however a bit concerned we would later find differences that require a specific compatible string. At this point, I think more testing is needed, with local access to the board, to check the display output. As that's hard to do right now, let's start by upstreaming board support without the DU, and add the DU on top. -- Regards, Laurent Pinchart
