All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Magnus Damm <magnus.damm@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>
Subject: Re: [PATCH 01/14] dt-bindings: arm: renesas: Document R-Car H3e-2G and M3e-2G SoCs and boards
Date: Mon, 14 Jun 2021 21:24:56 +0300	[thread overview]
Message-ID: <YMee+GAOoKB2rlwK@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CAMuHMdXvB7dfcoCXOuE_oTCxaBqQyA8RVGm7SVy8iTmccvG95A@mail.gmail.com>

Hi Geert,

On Mon, Jun 14, 2021 at 01:25:49PM +0200, Geert Uytterhoeven wrote:
> On Sun, Jun 13, 2021 at 3:13 AM Laurent Pinchart wrote:
> > On Thu, Jun 10, 2021 at 11:37:14AM +0200, Geert Uytterhoeven wrote:
> > > Document the compatible values for the R-Car H3e-2G (R8A779M1) and
> > > M3e-2G (R8A779M3) SoCs.  These are different gradings of the R-Car H3
> > > ES3.0 (R8A77951) and M3-W+ (R8A77961) SoCs.
> > >
> > > All R-Car Gen3e on-SoC devices are identical to the devices on the
> > > corresponding R-Car Gen3 SoCs, and thus just use the compatible values
> > > for the latter.  The root compatible properties do gain an additional
> > > value, to sort out integration issues if they ever arise.
> > >
> > > Document the use of these SoCs on the Salvator-XS and ULCB (with and
> > > without Kingfisher) development boards.
> > >
> > > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> >
> > Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> 
> Thanks!
> 
> > I however wonder if we haven't messed up the board compatible strings
> > somehow (unrelated to this patch). Aren't compatible strings supposed to
> > be ordered from most specific to most generic, with a more specific
> > compatible string being a strict subset of a more generic string ?
> > Looking at, for example,
> >
> >         compatible = "renesas,salvator-xs", "renesas,r8a779m1", "renesas,r8a7795";
> >
> > the rule is upheld by renesas,r8a779m1 being a subset of the more
> > generic renesas,r8a7795, but that's not the case for
> > renesas,salvator-xs.
> 
> That's a very interesting comment.  Originally, we had lists like:
> 
>     compatible = "renesas,koelsch", "renesas,r8a7791";
> 
> with the Koelsch board indeed being a specialization of an R-Car
> M2-W-based system. Later, we reused that system for the Salvator-X
> board with an R-Car H3 SiP:
> 
>     compatible = "renesas,salvator-x", "renesas,r8a7795";
> 
> That scheme became "broken" with the introduction of the R-Car M3-W
> SiP, which was also mounted on a Salvator-X board, leading to:
> 
>     compatible = "renesas,salvator-x", "renesas,r8a7796";
> 
> Note that we did have a similar case for R-Car M2-W and R-Car M2-N on
> the Koelsch resp. Gose boards: from the schematics (I haven't seen
> a Gose), it looks identical to Koelsch, with parts not supported by
> R-Car M2-N (like the second SDRAM bank) marked "Do not stuff".
> But in this case the boards were assigned different names, thus
> leading to different compatible values.
> 
> With Salvator-X(S), it was easier to support multiple SoCs, as they
> are mounted on SiPs, with differences like the different number of
> memory channels hidden in the SiP, and handled at a different level
> (these days memory layout information flows from ATF to U-Boot to
> the DTB passed to the kernel).
> 
> Would you feel more comfortable if we had introduced more
> board-specific compatible values, like "renesas,r8a7796-salvator-x",
> and had used
> 
>     compatible = "renesas,r8a7795-salvator-x", "renesas,salvator-x",
> "renesas,r8a7795";
> 
> or
> 
>     compatible = "renesas,r8a7795-salvator-x", "renesas,r8a7795";
> 
> ?

I think I would prefer that, yes. The idea of specifying separate board
and an SoC identifiers is interesting and, I believe, useful, but it
seems to be a bit of an abuse of what the "compatible" property is meant
for.

All of this will probably never be handled by code not specific to
Renesas, so it's probably a theoretical issue only.

> If the need ever arises, Linux can still identify the exact combination
> by checking for both the board- and the SoC-specific values.
> So far we didn't have that need for Salvator-X(S) yet (we do have
> board-specific checks in
> arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c).
> 
> > > --- a/Documentation/devicetree/bindings/arm/renesas.yaml
> > > +++ b/Documentation/devicetree/bindings/arm/renesas.yaml
> > > @@ -238,17 +238,29 @@ properties:
> > >            - const: renesas,r8a77961
> > >
> > >        - description: Kingfisher (SBEV-RCAR-KF-M03)
> > > -        items:
> > > -          - const: shimafuji,kingfisher
> > > -          - enum:
> > > -              - renesas,h3ulcb
> > > -              - renesas,m3ulcb
> > > -              - renesas,m3nulcb
> > > -          - enum:
> > > -              - renesas,r8a7795
> > > -              - renesas,r8a7796
> > > -              - renesas,r8a77961
> > > -              - renesas,r8a77965
> > > +        oneOf:
> > > +          - items:
> > > +              - const: shimafuji,kingfisher
> > > +              - enum:
> > > +                  - renesas,h3ulcb
> > > +                  - renesas,m3ulcb
> > > +                  - renesas,m3nulcb
> > > +              - enum:
> > > +                  - renesas,r8a7795
> > > +                  - renesas,r8a7796
> > > +                  - renesas,r8a77961
> > > +                  - renesas,r8a77965
> > > +          - items:
> > > +              - const: shimafuji,kingfisher
> > > +              - enum:
> > > +                  - renesas,h3ulcb
> > > +                  - renesas,m3ulcb
> > > +              - enum:
> > > +                  - renesas,r8a779m1
> > > +                  - renesas,r8a779m3
> > > +              - enum:
> > > +                  - renesas,r8a7795
> > > +                  - renesas,r8a77961
> > >
> > >        - description: R-Car M3-N (R8A77965)
> > >          items:
> > > @@ -296,6 +308,22 @@ properties:
> > >            - const: renesas,falcon-cpu
> > >            - const: renesas,r8a779a0
> > >
> > > +      - description: R-Car H3e-2G (R8A779M1)
> > > +        items:
> > > +          - enum:
> > > +              - renesas,h3ulcb      # H3ULCB (R-Car Starter Kit Premier)
> > > +              - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
> > > +          - const: renesas,r8a779m1
> > > +          - const: renesas,r8a7795
> > > +
> > > +      - description: R-Car M3e-2G (R8A779M3)
> > > +        items:
> > > +          - enum:
> > > +              - renesas,m3ulcb      # M3ULCB (R-Car Starter Kit Pro)
> > > +              - renesas,salvator-xs # Salvator-XS (Salvator-X 2nd version)
> > > +          - const: renesas,r8a779m3
> > > +          - const: renesas,r8a77961
> > > +
> > >        - description: RZ/N1D (R9A06G032)
> > >          items:
> > >            - enum:

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2021-06-14 18:25 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-10  9:37 [PATCH 00/14] arm64: renesas: Add support for R Car H3e 2G-and M3e-2G Geert Uytterhoeven
2021-06-10  9:37 ` [PATCH 01/14] dt-bindings: arm: renesas: Document R-Car H3e-2G and M3e-2G SoCs and boards Geert Uytterhoeven
2021-06-13  1:13   ` Laurent Pinchart
2021-06-14 11:25     ` Geert Uytterhoeven
2021-06-14 18:24       ` Laurent Pinchart [this message]
2021-06-16 17:56   ` Rob Herring
2021-06-23 10:01   ` Yoshihiro Shimoda
2021-06-10  9:37 ` [PATCH 02/14] soc: renesas: Identify R-Car H3e-2G and M3e-2G Geert Uytterhoeven
2021-06-14 18:31   ` Laurent Pinchart
2021-06-23 10:13     ` Yoshihiro Shimoda
2021-06-10  9:37 ` [PATCH 03/14] pinctrl: renesas: Fix pin control matching on R-Car H3e-2G Geert Uytterhoeven
2021-06-14 18:38   ` Laurent Pinchart
2021-06-14 19:16     ` Geert Uytterhoeven
2021-06-23 10:34   ` Yoshihiro Shimoda
2021-06-10  9:37 ` [PATCH 04/14] mmc: renesas_sdhi: Add support for R-Car H3e-2G and M3e-2G Geert Uytterhoeven
2021-06-14 18:42   ` Laurent Pinchart
2021-06-14 19:32     ` Geert Uytterhoeven
2021-06-24  2:25       ` Yoshihiro Shimoda
2021-06-24  6:14         ` Wolfram Sang
2021-06-24 10:54           ` Yoshihiro Shimoda
2021-06-24 15:19             ` Wolfram Sang
2021-06-25  4:54               ` Yoshihiro Shimoda
2021-06-10  9:37 ` [PATCH 05/14] arm64: dts: renesas: Add Renesas R8A779M1 SoC support Geert Uytterhoeven
2021-06-14 18:43   ` Laurent Pinchart
2021-06-24  4:56   ` Yoshihiro Shimoda
2021-06-10  9:37 ` [PATCH 06/14] arm64: dts: renesas: Add Renesas R8A779M3 " Geert Uytterhoeven
2021-06-24  5:08   ` Yoshihiro Shimoda
2021-06-10  9:37 ` [PATCH 07/14] arm64: dts: renesas: Add support for Salvator-XS with R-Car H3e-2G Geert Uytterhoeven
2021-06-14 18:45   ` Laurent Pinchart
2021-06-14 19:34     ` Geert Uytterhoeven
2021-06-24  5:27       ` Yoshihiro Shimoda
2021-06-10  9:37 ` [PATCH 08/14] arm64: dts: renesas: Add support for H3ULCB " Geert Uytterhoeven
2021-06-14 18:46   ` Laurent Pinchart
2021-06-10  9:37 ` [PATCH 09/14] arm64: dts: renesas: Add support for H3ULCB+Kingfisher " Geert Uytterhoeven
2021-06-14 18:46   ` Laurent Pinchart
2021-06-10  9:37 ` [PATCH 10/14] arm64: dts: renesas: Add support for Salvator-XS with R-Car M3e-2G Geert Uytterhoeven
2021-06-14 18:48   ` Laurent Pinchart
2021-06-10  9:37 ` [PATCH 11/14] arm64: dts: renesas: Add support for M3ULCB " Geert Uytterhoeven
2021-06-14 18:48   ` Laurent Pinchart
2021-06-10  9:37 ` [PATCH 12/14] arm64: dts: renesas: Add support for M3ULCB+Kingfisher " Geert Uytterhoeven
2021-06-14 18:48   ` Laurent Pinchart
2021-06-10  9:37 ` [PATCH/RFC 13/14] arm64: dts: renesas: r8a779m1: Add Cortex-A57 2 GHz opp Geert Uytterhoeven
2021-06-16 11:25   ` Yoshihiro Shimoda
2021-06-10  9:37 ` [PATCH/RFC 14/14] arm64: dts: renesas: r8a779m3: " Geert Uytterhoeven
2021-06-16 11:27   ` Yoshihiro Shimoda

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YMee+GAOoKB2rlwK@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.