On Wed, May 06, 2026 at 01:22:00AM +0300, Laurent Pinchart wrote: > 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.
For the record, a useful test would be to disconnect the two VSPD instances from the DU and expose them to userspace (setting the uapi flag to true in the driver), and see if they pass the VSP test suite. That would tell us if all three VSP channels are operational. Then I would try to operate all 3 DU outputs and see if we get interrupts from all of them. I think the DU channel that outputs towards the HDMI encoder does not get any feedback from the HDMI IP, so it should happily output data, ignoring there's no HDMI output. And we could even try to wire the HDMI encoder in DT to see if it's there. Lots of interesting hacks to experiment with. I'm of course not expecting you to do all that, I can also give it a try (even if it would be nicer to get local access to the board to see what signals are actually output). -- Regards, Laurent Pinchart
