Hi Geert, On Tue, Aug 20, 2019 at 09:53:44AM +0200, Geert Uytterhoeven wrote: > Hi Jacopo, > > On Tue, Aug 20, 2019 at 9:47 AM Jacopo Mondi wrote: > > On Mon, Aug 19, 2019 at 03:45:54PM +0200, Geert Uytterhoeven wrote: > > > On Mon, Jul 8, 2019 at 9:58 AM Geert Uytterhoeven wrote: > > > > On Sat, Jul 6, 2019 at 4:07 PM Jacopo Mondi wrote: > > > > > Add device tree bindings documentation for the Renesas R-Car Display > > > > > Unit Color Management Module. > > > > > > > > > > CMM is the image enhancement module available on each R-Car DU video > > > > > channel on R-Car Gen2 and Gen3 SoCs (V3H and V3M excluded). > > > > > > > > > > Signed-off-by: Jacopo Mondi > > > > > Reviewed-by: Laurent Pinchart > > > > > > > > Thanks for your patch! > > > > > > > > > --- /dev/null > > > > > +++ b/Documentation/devicetree/bindings/display/renesas,cmm.txt > > > > > @@ -0,0 +1,25 @@ > > > > > +* Renesas R-Car Color Management Module (CMM) > > > > > + > > > > > +Renesas R-Car image enhancement module connected to R-Car DU video channels. > > > > > + > > > > > +Required properties: > > > > > + - compatible: shall be one of: > > > > > + - "renesas,rcar-gen3-cmm" > > > > > + - "renesas,rcar-gen2-cmm" > > > > > > > > Why do you think you do not need SoC-specific compatible values? > > > > What if you discover a different across the R-Car Gen3 line tomorrow? > > > > Does the IP block have a version register? > > > > > > Do you have an answer to these questions? > > > > It does not seem to me that CMM has any version register, nor there > > are differences between the different Gen3 SoCs.. > > > > However, even if we now define a single compatible property for > > gen3/gen2 and we later find out one of the SoC needs a soc-specific > > property we can safely add it and keep the generic gen3/gen2 one as > > fallback.. Does it work for you? > > Unfortunately that won't work, as the existing DTBs won't have the > soc-specific compatible value. Correct, existing dtbs won't have the soc-specific value... However, there are functional differences between different SoCs according to the datasheet, but if it's good practice to provide soc-specific compatibles "just in case" I'm fine doing that.. > You could still resort to soc_device_match(), but it is better to avoid that. I see... Also that function's documentation prescribes to go through DT first, so I guess it's our last resort... > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds