lkml.org 
[lkml]   [2019]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 01/19] dt-bindings: display: renesas,cmm: Add R-Car CMM documentation
    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 <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.

    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
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2019-08-20 10:04    [W:5.670 / U:0.420 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site