Hi Jacopo,
On Tue, Aug 20, 2019 at 9:47 AM Jacopo Mondi jacopo@jmondi.org 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 geert@linux-m68k.org wrote:
On Sat, Jul 6, 2019 at 4:07 PM Jacopo Mondi jacopo+renesas@jmondi.org 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 jacopo+renesas@jmondi.org Reviewed-by: Laurent Pinchart laurent.pinchart@ideasonboard.com
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. You could still resort to soc_device_match(), but it is better to avoid that.
Gr{oetje,eeting}s,
Geert