[PATCH 1/4] arm64: renesas: Remove the ARCH_SHMOBILE Kconfig symbol

[PATCH 1/4] arm64: renesas: Remove the ARCH_SHMOBILE Kconfig symbol

[Simon Horman]

From: Geert Uytterhoeven <geert+renesas@glider.be>

The Kconfig symbol for Renesas 64-bit ARM SoCs has always been
ARCH_RENESAS, with ARCH_SHMOBILE being selected to reuse drivers shared
with Renesas 32-bit ARM and/or Renesas SuperH SH-Mobile SoCs.

Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
started the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas
32-bit SoCs.  Now all drivers for Renesas ARM SoCs have gained proper
ARCH_RENESAS platform dependencies, there is no longer a need to select
ARCH_SHMOBILE.

With ARCH_SHMOBILE gone, move the ARCH_RENESAS section up, to restore
alphabetical sort order.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm64/Kconfig.platforms | 44 ++++++++++++++++++++------------------------
 1 file changed, 20 insertions(+), 24 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 393d2b524284..b3c4c66f8519 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -152,32 +152,8 @@ config ARCH_REALTEK
 	  This enables support for the ARMv8 based Realtek chipsets,
 	  like the RTD1295.
 
-config ARCH_ROCKCHIP
-	bool "Rockchip Platforms"
-	select ARCH_HAS_RESET_CONTROLLER
-	select GPIOLIB
-	select PINCTRL
-	select PINCTRL_ROCKCHIP
-	select PM
-	select ROCKCHIP_TIMER
-	help
-	  This enables support for the ARMv8 based Rockchip chipsets,
-	  like the RK3368.
-
-config ARCH_SEATTLE
-	bool "AMD Seattle SoC Family"
-	help
-	  This enables support for AMD Seattle SOC Family
-
-config ARCH_SHMOBILE
-	bool
-
-config ARCH_SYNQUACER
-	bool "Socionext SynQuacer SoC Family"
-
 config ARCH_RENESAS
 	bool "Renesas SoC Platforms"
-	select ARCH_SHMOBILE
 	select PINCTRL
 	select PM
 	select PM_GENERIC_DOMAINS
@@ -228,11 +204,31 @@ config ARCH_R8A77995
 	help
 	  This enables support for the Renesas R-Car D3 SoC.
 
+config ARCH_ROCKCHIP
+	bool "Rockchip Platforms"
+	select ARCH_HAS_RESET_CONTROLLER
+	select GPIOLIB
+	select PINCTRL
+	select PINCTRL_ROCKCHIP
+	select PM
+	select ROCKCHIP_TIMER
+	help
+	  This enables support for the ARMv8 based Rockchip chipsets,
+	  like the RK3368.
+
+config ARCH_SEATTLE
+	bool "AMD Seattle SoC Family"
+	help
+	  This enables support for AMD Seattle SOC Family
+
 config ARCH_STRATIX10
 	bool "Altera's Stratix 10 SoCFPGA Family"
 	help
 	  This enables support for Altera's Stratix 10 SoCFPGA Family.
 
+config ARCH_SYNQUACER
+	bool "Socionext SynQuacer SoC Family"
+
 config ARCH_TEGRA
 	bool "NVIDIA Tegra SoC Family"
 	select ARCH_HAS_RESET_CONTROLLER
-- 
2.11.0

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

[Simon Horman]

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM64 based SoC SoC updates for v4.20.


The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:

  Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-soc-for-v4.20

for you to fetch changes up to 692dce77dfb71b5eaf896d3cdc7ef72f70631b14:

  arm64: Add Renesas R8A774C0 support (2018-09-11 15:50:57 +0200)

----------------------------------------------------------------
Renesas ARM64 Based SoC SoC Updates for v4.20

* 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

----------------------------------------------------------------
Biju Das (1):
      arm64: Add Renesas R8A774A1 support

Fabrizio Castro (1):
      arm64: Add Renesas R8A774C0 support

Geert Uytterhoeven (1):
      arm64: renesas: Remove the ARCH_SHMOBILE Kconfig symbol

Sergei Shtylyov (1):
      arm64: enable CMT/TMU support for Renesas SoC

 arch/arm64/Kconfig.platforms | 58 ++++++++++++++++++++++++++------------------
 1 file changed, 34 insertions(+), 24 deletions(-)

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

[Simon Horman]

Hi Olof, Hi Kevin, Hi Arnd,

Please consider these Renesas ARM64 based SoC SoC updates for v4.20.


The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:

  Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-soc-for-v4.20

for you to fetch changes up to 692dce77dfb71b5eaf896d3cdc7ef72f70631b14:

  arm64: Add Renesas R8A774C0 support (2018-09-11 15:50:57 +0200)

----------------------------------------------------------------
Renesas ARM64 Based SoC SoC Updates for v4.20

* 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

----------------------------------------------------------------
Biju Das (1):
      arm64: Add Renesas R8A774A1 support

Fabrizio Castro (1):
      arm64: Add Renesas R8A774C0 support

Geert Uytterhoeven (1):
      arm64: renesas: Remove the ARCH_SHMOBILE Kconfig symbol

Sergei Shtylyov (1):
      arm64: enable CMT/TMU support for Renesas SoC

 arch/arm64/Kconfig.platforms | 58 ++++++++++++++++++++++++++------------------
 1 file changed, 34 insertions(+), 24 deletions(-)

[PATCH 1/4] arm64: renesas: Remove the ARCH_SHMOBILE Kconfig symbol

[Simon Horman]

From: Geert Uytterhoeven <geert+renesas@glider.be>

The Kconfig symbol for Renesas 64-bit ARM SoCs has always been
ARCH_RENESAS, with ARCH_SHMOBILE being selected to reuse drivers shared
with Renesas 32-bit ARM and/or Renesas SuperH SH-Mobile SoCs.

Commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
started the conversion from ARCH_SHMOBILE to ARCH_RENESAS for Renesas
32-bit SoCs.  Now all drivers for Renesas ARM SoCs have gained proper
ARCH_RENESAS platform dependencies, there is no longer a need to select
ARCH_SHMOBILE.

With ARCH_SHMOBILE gone, move the ARCH_RENESAS section up, to restore
alphabetical sort order.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm64/Kconfig.platforms | 44 ++++++++++++++++++++------------------------
 1 file changed, 20 insertions(+), 24 deletions(-)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 393d2b524284..b3c4c66f8519 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -152,32 +152,8 @@ config ARCH_REALTEK
 	  This enables support for the ARMv8 based Realtek chipsets,
 	  like the RTD1295.
 
-config ARCH_ROCKCHIP
-	bool "Rockchip Platforms"
-	select ARCH_HAS_RESET_CONTROLLER
-	select GPIOLIB
-	select PINCTRL
-	select PINCTRL_ROCKCHIP
-	select PM
-	select ROCKCHIP_TIMER
-	help
-	  This enables support for the ARMv8 based Rockchip chipsets,
-	  like the RK3368.
-
-config ARCH_SEATTLE
-	bool "AMD Seattle SoC Family"
-	help
-	  This enables support for AMD Seattle SOC Family
-
-config ARCH_SHMOBILE
-	bool
-
-config ARCH_SYNQUACER
-	bool "Socionext SynQuacer SoC Family"
-
 config ARCH_RENESAS
 	bool "Renesas SoC Platforms"
-	select ARCH_SHMOBILE
 	select PINCTRL
 	select PM
 	select PM_GENERIC_DOMAINS
@@ -228,11 +204,31 @@ config ARCH_R8A77995
 	help
 	  This enables support for the Renesas R-Car D3 SoC.
 
+config ARCH_ROCKCHIP
+	bool "Rockchip Platforms"
+	select ARCH_HAS_RESET_CONTROLLER
+	select GPIOLIB
+	select PINCTRL
+	select PINCTRL_ROCKCHIP
+	select PM
+	select ROCKCHIP_TIMER
+	help
+	  This enables support for the ARMv8 based Rockchip chipsets,
+	  like the RK3368.
+
+config ARCH_SEATTLE
+	bool "AMD Seattle SoC Family"
+	help
+	  This enables support for AMD Seattle SOC Family
+
 config ARCH_STRATIX10
 	bool "Altera's Stratix 10 SoCFPGA Family"
 	help
 	  This enables support for Altera's Stratix 10 SoCFPGA Family.
 
+config ARCH_SYNQUACER
+	bool "Socionext SynQuacer SoC Family"
+
 config ARCH_TEGRA
 	bool "NVIDIA Tegra SoC Family"
 	select ARCH_HAS_RESET_CONTROLLER
-- 
2.11.0

[PATCH 2/4] arm64: enable CMT/TMU support for Renesas SoC

[Simon Horman]

From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Renesas R-Car gen3 SoCs have both CMT and TMU timers, so we have to enable
building them in Kconfig.platforms (as they don't normally have the prompts
in Kconfig).

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm64/Kconfig.platforms | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index b3c4c66f8519..8d149e12c82d 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -159,6 +159,8 @@ config ARCH_RENESAS
 	select PM_GENERIC_DOMAINS
 	select RENESAS_IRQC
 	select SOC_BUS
+	select SYS_SUPPORTS_SH_CMT
+	select SYS_SUPPORTS_SH_TMU
 	help
 	  This enables support for the ARMv8 based Renesas SoCs.
 
-- 
2.11.0

[PATCH 2/4] arm64: enable CMT/TMU support for Renesas SoC

[Simon Horman]

From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>

Renesas R-Car gen3 SoCs have both CMT and TMU timers, so we have to enable
building them in Kconfig.platforms (as they don't normally have the prompts
in Kconfig).

Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm64/Kconfig.platforms | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index b3c4c66f8519..8d149e12c82d 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -159,6 +159,8 @@ config ARCH_RENESAS
 	select PM_GENERIC_DOMAINS
 	select RENESAS_IRQC
 	select SOC_BUS
+	select SYS_SUPPORTS_SH_CMT
+	select SYS_SUPPORTS_SH_TMU
 	help
 	  This enables support for the ARMv8 based Renesas SoCs.
 
-- 
2.11.0

[PATCH 3/4] arm64: Add Renesas R8A774A1 support

[Simon Horman]

From: Biju Das <biju.das@bp.renesas.com>

Add configuration option for the RZ/G2M (R8A774A1) SoC.

Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Chris Paterson <chris.paterson2@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 8d149e12c82d..b2e513e5960b 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -164,6 +164,12 @@ config ARCH_RENESAS
 	help
 	  This enables support for the ARMv8 based Renesas SoCs.
 
+config ARCH_R8A774A1
+	bool "Renesas RZ/G2M SoC Platform"
+	depends on ARCH_RENESAS
+	help
+	  This enables support for the Renesas RZ/G2M SoC.
+
 config ARCH_R8A7795
 	bool "Renesas R-Car H3 SoC Platform"
 	depends on ARCH_RENESAS
-- 
2.11.0

[PATCH 3/4] arm64: Add Renesas R8A774A1 support

[Simon Horman]

From: Biju Das <biju.das@bp.renesas.com>

Add configuration option for the RZ/G2M (R8A774A1) SoC.

Signed-off-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Chris Paterson <chris.paterson2@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 8d149e12c82d..b2e513e5960b 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -164,6 +164,12 @@ config ARCH_RENESAS
 	help
 	  This enables support for the ARMv8 based Renesas SoCs.
 
+config ARCH_R8A774A1
+	bool "Renesas RZ/G2M SoC Platform"
+	depends on ARCH_RENESAS
+	help
+	  This enables support for the Renesas RZ/G2M SoC.
+
 config ARCH_R8A7795
 	bool "Renesas R-Car H3 SoC Platform"
 	depends on ARCH_RENESAS
-- 
2.11.0

[PATCH 4/4] arm64: Add Renesas R8A774C0 support

[Simon Horman]

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

Add configuration option for the RZ/G2E (R8A774C0) SoC.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index b2e513e5960b..0b65c033c549 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -170,6 +170,12 @@ config ARCH_R8A774A1
 	help
 	  This enables support for the Renesas RZ/G2M SoC.
 
+config ARCH_R8A774C0
+	bool "Renesas RZ/G2E SoC Platform"
+	depends on ARCH_RENESAS
+	help
+	  This enables support for the Renesas RZ/G2E SoC.
+
 config ARCH_R8A7795
 	bool "Renesas R-Car H3 SoC Platform"
 	depends on ARCH_RENESAS
-- 
2.11.0

[PATCH 4/4] arm64: Add Renesas R8A774C0 support

[Simon Horman]

From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>

Add configuration option for the RZ/G2E (R8A774C0) SoC.

Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
---
 arch/arm64/Kconfig.platforms | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index b2e513e5960b..0b65c033c549 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -170,6 +170,12 @@ config ARCH_R8A774A1
 	help
 	  This enables support for the Renesas RZ/G2M SoC.
 
+config ARCH_R8A774C0
+	bool "Renesas RZ/G2E SoC Platform"
+	depends on ARCH_RENESAS
+	help
+	  This enables support for the Renesas RZ/G2E SoC.
+
 config ARCH_R8A7795
 	bool "Renesas R-Car H3 SoC Platform"
 	depends on ARCH_RENESAS
-- 
2.11.0

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

[Arnd Bergmann]

On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
<horms+renesas@verge.net.au> wrote:
>
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM64 based SoC SoC updates for v4.20.
>
>
> The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
>
>   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
>
> are available in the git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-soc-for-v4.20
>
> for you to fetch changes up to 692dce77dfb71b5eaf896d3cdc7ef72f70631b14:
>
>   arm64: Add Renesas R8A774C0 support (2018-09-11 15:50:57 +0200)
>
> ----------------------------------------------------------------
> Renesas ARM64 Based SoC SoC Updates for v4.20
>
> * 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.

Any ideas what we can do here?

      Arnd

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

[Arnd Bergmann]

On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
<horms+renesas@verge.net.au> wrote:
>
> Hi Olof, Hi Kevin, Hi Arnd,
>
> Please consider these Renesas ARM64 based SoC SoC updates for v4.20.
>
>
> The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
>
>   Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
>
> are available in the git repository at:
>
>   https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git tags/renesas-arm64-soc-for-v4.20
>
> for you to fetch changes up to 692dce77dfb71b5eaf896d3cdc7ef72f70631b14:
>
>   arm64: Add Renesas R8A774C0 support (2018-09-11 15:50:57 +0200)
>
> ----------------------------------------------------------------
> Renesas ARM64 Based SoC SoC Updates for v4.20
>
> * 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.

Any ideas what we can do here?

      Arnd

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

[Geert Uytterhoeven]

Hi Arnd,

On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > * 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?

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).

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

What do you think?
Thanks!

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

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

[Geert Uytterhoeven]

Hi Arnd,

On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > * 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?

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).

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

What do you think?
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

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

[Arnd Bergmann]

On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Arnd,
>
> On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> > <horms+renesas@verge.net.au> wrote:
> > > * 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.

> 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.

> 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.

> What do you think?
> Thanks!

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

[Arnd Bergmann]

On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Arnd,
>
> On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> > <horms+renesas@verge.net.au> wrote:
> > > * 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.

> 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.

> 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.

> What do you think?
> Thanks!

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

[Geert Uytterhoeven]

Hi Arnd,

On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> > > <horms+renesas@verge.net.au> wrote:
> > > > * 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.
>
> > 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.
>
> > 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.

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

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

[Geert Uytterhoeven]

Hi Arnd,

On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann <arnd@arndb.de> wrote:
> On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> > > <horms+renesas@verge.net.au> wrote:
> > > > * 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.
>
> > 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.
>
> > 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.

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

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

[Geert Uytterhoeven]

Hi Arnd,

On Tue, Oct 2, 2018 at 2:31 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> > > > <horms+renesas@verge.net.au> wrote:
> > > > > * 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.
> >
> > > 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.
> >
> > > 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@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

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

[Geert Uytterhoeven]

Hi Arnd,

On Tue, Oct 2, 2018 at 2:31 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> > > > <horms+renesas@verge.net.au> wrote:
> > > > > * 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.
> >
> > > 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.
> >
> > > 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

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

[Arnd Bergmann]

On Thu, Oct 4, 2018 at 9:58 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Oct 2, 2018 at 2:31 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> > > > > <horms+renesas@verge.net.au> wrote:
> > > > > > * 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.
> > >
> > > > 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.
> > >
> > > > 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?

Fair enough, pulled into next/soc now.

      Arnd

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

[Arnd Bergmann]

On Thu, Oct 4, 2018 at 9:58 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Oct 2, 2018 at 2:31 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> > > > > <horms+renesas@verge.net.au> wrote:
> > > > > > * 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.
> > >
> > > > 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.
> > >
> > > > 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?

Fair enough, pulled into next/soc now.

      Arnd

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

[Geert Uytterhoeven]

Hi Arnd,

On Tue, Oct 2, 2018 at 2:31 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> > > > <horms+renesas@verge.net.au> wrote:
> > > > > * 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,

Upon closer look, the SoC-specific controls are also used to control compilation
of the SYSC (power domain) tables,  each consuming a few 100 bytes.
So either they become user-visible, too, or always compiled in (depending
on SoC family?).

> > but it does address my concern about consistency between the platforms.

I've just noticed Tegra also has SoC-specific controls, but they're located
in drivers/soc/tegra/Kconfig, not the main arch/arm64/Kconfig.platforms.
Do you consider that a viable alternative?

Thanks again!

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

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

[Geert Uytterhoeven]

Hi Arnd,

On Tue, Oct 2, 2018 at 2:31 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> > > > <horms+renesas@verge.net.au> wrote:
> > > > > * 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,

Upon closer look, the SoC-specific controls are also used to control compilation
of the SYSC (power domain) tables,  each consuming a few 100 bytes.
So either they become user-visible, too, or always compiled in (depending
on SoC family?).

> > but it does address my concern about consistency between the platforms.

I've just noticed Tegra also has SoC-specific controls, but they're located
in drivers/soc/tegra/Kconfig, not the main arch/arm64/Kconfig.platforms.
Do you consider that a viable alternative?

Thanks again!

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

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

[Arnd Bergmann]

On Thu, Oct 4, 2018 at 5:39 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Oct 2, 2018 at 2:31 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> > > > > <horms+renesas@verge.net.au> wrote:
> > > > > > * 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,
>
> Upon closer look, the SoC-specific controls are also used to control compilation
> of the SYSC (power domain) tables,  each consuming a few 100 bytes.
> So either they become user-visible, too, or always compiled in (depending
> on SoC family?).
>
> > > but it does address my concern about consistency between the platforms.
>
> I've just noticed Tegra also has SoC-specific controls, but they're located
> in drivers/soc/tegra/Kconfig, not the main arch/arm64/Kconfig.platforms.
> Do you consider that a viable alternative?

Yes, I think that would be ok as well.

      Arnd

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

[Arnd Bergmann]

On Thu, Oct 4, 2018 at 5:39 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Oct 2, 2018 at 2:31 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> > > > > <horms+renesas@verge.net.au> wrote:
> > > > > > * 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,
>
> Upon closer look, the SoC-specific controls are also used to control compilation
> of the SYSC (power domain) tables,  each consuming a few 100 bytes.
> So either they become user-visible, too, or always compiled in (depending
> on SoC family?).
>
> > > but it does address my concern about consistency between the platforms.
>
> I've just noticed Tegra also has SoC-specific controls, but they're located
> in drivers/soc/tegra/Kconfig, not the main arch/arm64/Kconfig.platforms.
> Do you consider that a viable alternative?

Yes, I think that would be ok as well.

      Arnd

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

[Simon Horman]

On Thu, Oct 04, 2018 at 05:36:15PM +0200, Arnd Bergmann wrote:
> On Thu, Oct 4, 2018 at 9:58 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, Oct 2, 2018 at 2:31 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > > On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> > > > > > <horms+renesas@verge.net.au> wrote:
> > > > > > > * 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.
> > > >
> > > > > 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.
> > > >
> > > > > 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?
> 
> Fair enough, pulled into next/soc now.

Thanks Arnd!

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

[Simon Horman]

On Thu, Oct 04, 2018 at 05:36:15PM +0200, Arnd Bergmann wrote:
> On Thu, Oct 4, 2018 at 9:58 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, Oct 2, 2018 at 2:31 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Tue, Oct 2, 2018 at 2:18 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > On Tue, Oct 2, 2018 at 10:31 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > > On Fri, Sep 28, 2018 at 10:10 PM Arnd Bergmann <arnd@arndb.de> wrote:
> > > > > > On Fri, Sep 28, 2018 at 12:21 PM Simon Horman
> > > > > > <horms+renesas@verge.net.au> wrote:
> > > > > > > * 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.
> > > >
> > > > > 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.
> > > >
> > > > > 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?
> 
> Fair enough, pulled into next/soc now.

Thanks Arnd!