[GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20

Hi Arnd,

On Tue, Oct 2, 2018 at 2:31 PM Geert Uytterhoeven [off-list ref] wrote:

On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann [off-list ref] wrote:

quoted

On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven [off-list ref] wrote:

quoted

On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann [off-list ref] wrote:

quoted

On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
[off-list ref] wrote:

quoted

* Add support for RZ/G2E (r8a774c0) and RZ/G2M (r8a774a1) SoCs
* Enable Compare Match Timer (CMT) and Timer Unit (TMU)
  for Renesas SoCs
* Remove no longer needed ARCH_SHMOBILE Kconfig symbol

The ARCH_SHMOBILE removal and cleanup is fine, but I wonder about
the newly added symbols for specific SoCs. I see you already have a
couple of those, but the other manufacturers don't.

I think what happened here is that I tried to reject those additions
normally, but I never noticed yours. From what I see in drivers,
you have additional symbols depending on these in clk, pinctrl,
drivers/soc, and the dtb files, so at the very least we can't
just drop the config options, but I'd still like to see this work
more like other platforms.

The main motivation for SoC-specific controls is to avoid including pinctrl
and (to a lesser extent) clock tables for unused SoCs.  Each pinctrl driver
consumes a few tens of KiB, each clock driver a few KiB.
If we remove the SoC-specific ARCH_* controls, the user has to configure
both pinctrl and clock driver selections, thus trading one user-visible
symbol for two new user-visible symbols (except for RZ/A and RZ/N,
where the pinctrl symbols are already visible, to allow reducing kernel
size).
Perhaps that is acceptable?

It's definitely fine with me. I understand that this is less user friendly,
but it does address my concern about consistency between the platforms.

quoted

For the smaller parts in drivers/soc/, removing SoC-specific dependencies
may be viable for R-Car and RZ/G Socs, but not for e.g. RZ/A.  The latter
may be used without external RAM, and can run with a few MiB of internal
SRAM, and XIP (with a still out-of-tree patch).
So at least a family-specific dependency is worth to keep.  For now, RZ/A
is arm32 only, though.

Note that on arm64, there are no family-specific Kconfig symbols yet.
We just have ARCH_RENESAS, which is also set on arm32.
So either we introduce e.g. ARCH_RCAR_GEN3 (cfr. ARCH_RCAR_GEN1 and
ARCH_RCAR_GEN2 or arm32), or use "ARCH_RENESAS && ARM64" for e.g. RST_RCAR
in drivers/soc/renesas/Kconfig, which currently depends on all R-Car Gen3
(and RZ/G2) SoCs explicitly.
Choosing the latter option means we may need to migrate to the former option
later, once other families appear (e.g. RZ/A SoCs may start using
Cortex-A53 instead of Cortex-A9 cores).

Maybe introducing a hidden ARCH_RCAR_GEN3 makes sense here, and
that can start out with the same value as ARCH_RENESAS. I think
if we want to add 64-bit RZ/A support later, having a separate top-level
symbol for that is also reasonable: as you explained this is rather
sensitive to memory usage, and that is enough reason to deviate from
what we do elsewhere.

quoted

For the DTB files, I believe we can just remove the dependencies, and
always build all DTBs.

Yes, that seems best, and consistent with how we handle other
manufacturers.

OK, I'll put it on my list.

Given the current time in the cycle, we can no longer do this for v4.20.
Hence, can you please accept Simon's PR as-is, to enable us to move
forward?

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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