Hi Conor, On 2024-06-21 09:21:24 +0200, Geert Uytterhoeven wrote: > Hi Niklas, > > On Thu, Jun 20, 2024 at 7:22 PM Niklas Söderlund > <niklas.soderlund+renesas@xxxxxxxxxxxx> wrote: > > On 2024-06-20 17:27:00 +0100, Conor Dooley wrote: > > > > + - items: > > > > + - enum: > > > > - renesas,vin-r8a779g0 # R-Car V4H > > > > + - renesas,vin-r8a779h0 # R-Car V4M > > > > + - const: renesas,rcar-gen4-vin # Generic R-Car Gen4 > > > > > > > > If so I can see that working as I could still fix any issues that come > > > > from differences between V4H and V4M if needed. If so do you think it > > > > best to add this in two different patches? One to add the > > > > renesas,rcar-gen4-vin fallback (which will also need DTS updates to fix > > > > warnings from exciting users of V4H not listing the gen4 fallback) and > > > > one to add V4M? > > > > > > > > > I would just do: > > > diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml > > > index 5539d0f8e74d..22bbad42fc03 100644 > > > --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml > > > +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml > > > @@ -54,6 +54,9 @@ properties: > > > - renesas,vin-r8a77995 # R-Car D3 > > > - renesas,vin-r8a779a0 # R-Car V3U > > > - renesas,vin-r8a779g0 # R-Car V4H > > > + - items: > > > + - const: renesas,vin-r8a779h0 # R-Car V4L2 > > > + - const: renesas,vin-r8a779g0 # R-Car V4H > > > > @Geert: What do you think about this? This would be a first use-case for > > compatibles crossing SoC DTS files that I know of. I'm a bit uneasy > > going down this road. > > Me too ;-) > > > Would this not also effect the existing users of renesas,vin-r8a779g0 > > which would now need something similar to what you propose below with a > > list of SoC compatibles and a fallback. > > > > > > > > reg: > > > maxItems: 1 > > > > > > Which requires no driver or dts changes. That could become: > > > - items: > > > - enum: > > > - renesas,vin-r8a779h0 # R-Car V4L2 > > > - renesas,vin-r8a779i0 # R-Car R4P17 > > > - const: renesas,vin-r8a779g0 # R-Car V4H > > > > FWIW, on Gen2 where fallback es where useful compared to Gen3 we did > > this with "renesas,rcar-gen2-vin". > > We do know there are differences (albeit probably small) among the R-Car > Gen4 VIN implementations, so I am reluctant to add a family-specific > compatible value. Typically we only use a family-specific compatible > value if the IP cores are known (or better, assumed ;-) to be identical. > > And sometimes our assumptions turn out to be wrong... > See slides 25-33 (last two for the numbers) of my talk at ER2019 > https://embedded-recipes.org/2019/talks/herd-your-socs-become-a-matchmaker/ Do Geert's slides help to explain the R-Car perspective on why a family-specific fallback compatible might not be desirable, and why the SoC specific one is proposed? -- Kind Regards, Niklas Söderlund
