Re: [PATCH/RFC 00/19] arm64: dts: renesas: Initial support for R-Car M3-W+

From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Magnus Damm <magnus.damm@gmail.com>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	Eugeniu Rosca <roscaeugeniu@gmail.com>
Subject: Re: [PATCH/RFC 00/19] arm64: dts: renesas: Initial support for R-Car M3-W+
Date: Wed, 16 Oct 2019 10:46:30 +0200	[thread overview]
Message-ID: <CAMuHMdWgeTfVnxhH2v_BSn8FWHH5CwjOinMvQxJa+3wVzgDZ3w@mail.gmail.com> (raw)
In-Reply-To: <20191014195842.GB10366@vmlxhi-102.adit-jv.com>

Hi Eugeniu,

On Mon, Oct 14, 2019 at 9:58 PM Eugeniu Rosca <erosca@de.adit-jv.com> wrote:
> On Mon, Oct 07, 2019 at 12:23:13PM +0200, Geert Uytterhoeven wrote:
> > This RFC patch series adds support for the R-Car M3-W+ (R8A77961) SoC
> > and the Salvator-XS board with R-Car M3-W+.  This SoC is a derivative of
> > R-Car M3-W (R8A77960), and also known as R-Car M3-W ES3.0.
> > As this is an RFC, I'm sending it to a limited audience.
> >
> > Based on experience with previous SoCs in the R-Car Gen3 family, the
> > following design decisions were made:
> >   - Use different compatible values (r8a77961-based),
>
> Given that a potentially incomplete list of M3-W compatible strings
> counts 40 occurrences [1] and this series adds only 7 [2], current RFC
> looks like the first step in a multi-phase approach. Do you plan to add
> the missing r8a77961 compatibles in the next revision or do you expect
> other people to contribute those later?

This is indeed a multi-phase approach.
I plan to add more later, and welcome other people in our team to do so, too.
However, as we currently have limited (remote) access, we cannot
add/test all other devices.
So if you have hardware access, any help is welcome.

> >   - Use different clock and SYSC DT binding definitions
> >     (R8A77961-based), but the same numerical values, to allow sharing
> >     drivers,
> >   - Share the pin control driver,
> >   - Share the clock driver,
> >   - Share the system controller driver.
> >
> > While the DT ABI is stable (hence we cannot s/r8a7796/r8a77960/ in DTS),
> > kernel source code and kernel config symbols can be changed at any
> > time.  As changing kernel config symbols impacts the user, they weren't
> > renamed yet.
> >
> > Questions:
> >   - What's the board part number of Salvator-XS with R-Car M3-W+?
>
> I guess my board is an exception, since it got the SiP simply upgraded
> from SoC ES1.x to ES3.0 by resoldering. IOW the board carries the same
> serial number as M3-ES1.1 Salvator-XS.

Yes, AFAIK, all Salvator-X and Salvator-XS boards have the same PCB
(modulo minor revision updates), and support all of H3/M3-W/M3-N SiPs
(except for H3 ES1.x, which is not supported by the -XS variant).
So upgraded boards retain their original part number.

> >   - Should the R8A77961 config symbols be dropped?
> >       - CONFIG_ARCH_R8A77961
> >       - CONFIG_CLK_R8A77961
> >       - CONFIG_PINCTRL_PFC_R8A77961
> >       - CONFIG_SYSC_R8A77961
> >
> >   - If not, should the R8A7796 config symbols be renamed?
> >       - CONFIG_ARCH_R8A7796 to CONFIG_ARCH_R8A77960?
> >       - CONFIG_CLK_R8A7796 to CONFIG_CLK_R8A77960?
> >       - CONFIG_PINCTRL_PFC_R8A7796 to CONFIG_PINCTRL_PFC_R8A77960?
> >       - CONFIG_SYSC_R8A7796 to CONFIG_SYSC_R8A77960?
> >     Due to dependencies on CONFIG_ARCH_R8A7796, this should be a single
> >     commit.
>
> [2 cents] Both adding CONFIG_*_R8A77961 and renaming CONFIG_*_R8A7796 to
> CONFIG_*_R8A77960 make sense to me.
>
> > Related questions for old R-Car H3 ES1.x support:
> >   - Should CONFIG_PINCTRL_PFC_R8A77950 be added, to allow compiling out
> >     R-Car H3 ES1.x pin control support?
>
> [2 cents] Adding CONFIG_*_R8A77950 makes sense in spite of the fact that
> R8A77950 is not documented in R-Car HW man. In fact, it is quite clear
> why R8A77950 is _not_ documented while R8A77960 _is_ documented. The
> former is obsolete (the community is nice by not obliterating its
> support) while the latter is expected to hit the market.
>
> >     If yes, should CONFIG_PINCTRL_PFC_R8A7795 be renamed to
> >     CONFIG_PINCTRL_PFC_R8A77951?
>
> In a perfect/ideal world, I would say yes.

Thanks for your feedback!

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