* [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20
@ 2018-10-02 12:31 ` Geert Uytterhoeven
0 siblings, 0 replies; 28+ messages in thread
From: Geert Uytterhoeven @ 2018-10-02 12:31 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20
2018-10-02 12:31 ` Geert Uytterhoeven
@ 2018-10-04 7:57 ` Geert Uytterhoeven
-1 siblings, 0 replies; 28+ messages in thread
From: Geert Uytterhoeven @ 2018-10-04 7:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Simon Horman, arm, Linux-Renesas, Olof Johansson, Kevin Hilman,
Linux ARM, Magnus Damm
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
^ permalink raw reply [flat|nested] 28+ messages in thread* [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20
@ 2018-10-04 7:57 ` Geert Uytterhoeven
0 siblings, 0 replies; 28+ messages in thread
From: Geert Uytterhoeven @ 2018-10-04 7:57 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20
2018-10-04 7:57 ` Geert Uytterhoeven
@ 2018-10-04 15:36 ` Arnd Bergmann
-1 siblings, 0 replies; 28+ messages in thread
From: Arnd Bergmann @ 2018-10-04 15:36 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, arm-soc, Linux-Renesas, Olof Johansson,
Kevin Hilman, Linux ARM, Magnus Damm
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
^ permalink raw reply [flat|nested] 28+ messages in thread* [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20
@ 2018-10-04 15:36 ` Arnd Bergmann
0 siblings, 0 replies; 28+ messages in thread
From: Arnd Bergmann @ 2018-10-04 15:36 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20
2018-10-04 15:36 ` Arnd Bergmann
@ 2018-10-08 7:31 ` Simon Horman
-1 siblings, 0 replies; 28+ messages in thread
From: Simon Horman @ 2018-10-08 7:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Geert Uytterhoeven, arm-soc, Linux-Renesas, Olof Johansson,
Kevin Hilman, Linux ARM, Magnus Damm
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!
^ permalink raw reply [flat|nested] 28+ messages in thread
* [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20
@ 2018-10-08 7:31 ` Simon Horman
0 siblings, 0 replies; 28+ messages in thread
From: Simon Horman @ 2018-10-08 7:31 UTC (permalink / raw)
To: linux-arm-kernel
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!
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20
2018-10-02 12:31 ` Geert Uytterhoeven
@ 2018-10-04 15:39 ` Geert Uytterhoeven
-1 siblings, 0 replies; 28+ messages in thread
From: Geert Uytterhoeven @ 2018-10-04 15:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Simon Horman, arm, Linux-Renesas, Olof Johansson, Kevin Hilman,
Linux ARM, Magnus Damm
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
^ permalink raw reply [flat|nested] 28+ messages in thread* [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20
@ 2018-10-04 15:39 ` Geert Uytterhoeven
0 siblings, 0 replies; 28+ messages in thread
From: Geert Uytterhoeven @ 2018-10-04 15:39 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20
2018-10-04 15:39 ` Geert Uytterhoeven
@ 2018-10-04 15:50 ` Arnd Bergmann
-1 siblings, 0 replies; 28+ messages in thread
From: Arnd Bergmann @ 2018-10-04 15:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Simon Horman, arm-soc, Linux-Renesas, Olof Johansson,
Kevin Hilman, Linux ARM, Magnus Damm
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
^ permalink raw reply [flat|nested] 28+ messages in thread* [GIT PULL] Renesas ARM64 Based SoC SoC Updates for v4.20
@ 2018-10-04 15:50 ` Arnd Bergmann
0 siblings, 0 replies; 28+ messages in thread
From: Arnd Bergmann @ 2018-10-04 15:50 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 28+ messages in thread