| Message ID | 1445839312-8874-2-git-send-email-horms+renesas@verge.net.au (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Oct 26, 2015 at 7:01 AM, Simon Horman <horms+renesas@verge.net.au> wrote: > From: Gaku Inami <gaku.inami.xw@bp.renesas.com> > > Initial version of Renesas R-Car H3 support (V10) > > Signed-off-by: Gaku Inami <gaku.inami.xw@bp.renesas.com> > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> > Signed-off-by: Magnus Damm <damm+renesas@opensource.se> > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi > new file mode 100644 > index 000000000000..aa13115387a6 > --- /dev/null > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi > + extal_clk: extal { > + compatible = "fixed-clock"; > + #clock-cells = <0>; I would add the same override comment as for extalr here, too. > + clock-frequency = <0>; > + }; > + > + extalr_clk: extalr { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + /* This value must be overridden by the board */ > + clock-frequency = <0>; > + }; Nevertheless: Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> 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
On Mon, Oct 26, 2015 at 03:01:46PM +0900, Simon Horman wrote: > --- a/arch/arm64/Kconfig.platforms > +++ b/arch/arm64/Kconfig.platforms > @@ -66,6 +66,23 @@ config ARCH_SEATTLE > help > This enables support for AMD Seattle SOC Family > > +config ARCH_SHMOBILE > + bool > + > +config ARCH_RENESAS > + bool "Renesas SoC Platforms" > + select ARCH_SHMOBILE > + select PINCTRL > + select PM_GENERIC_DOMAINS if PM > + help > + This enables support for the ARMv8 based Renesas SoCs. > + > +config ARCH_R8A7795 > + bool "Renesas R-Car H3 SoC Platform" > + depends on ARCH_RENESAS > + help > + This enables support for the Renesas R-Car H3 SoC. Do you need such fine-grained configuration? I'd really like to avoid individual SoC Kconfig entries and only include SoC families (like ARCH_RENESAS). There are some which I didn't spot at the time (ARCH_FSL_LS2085A and ARCH_TEGRA_132_SOC) but we shouldn't continue this trend any further.
On Thu, Oct 29, 2015 at 3:45 AM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Mon, Oct 26, 2015 at 03:01:46PM +0900, Simon Horman wrote: >> --- a/arch/arm64/Kconfig.platforms >> +++ b/arch/arm64/Kconfig.platforms >> @@ -66,6 +66,23 @@ config ARCH_SEATTLE >> help >> This enables support for AMD Seattle SOC Family >> >> +config ARCH_SHMOBILE >> + bool >> + >> +config ARCH_RENESAS >> + bool "Renesas SoC Platforms" >> + select ARCH_SHMOBILE >> + select PINCTRL >> + select PM_GENERIC_DOMAINS if PM >> + help >> + This enables support for the ARMv8 based Renesas SoCs. >> + >> +config ARCH_R8A7795 >> + bool "Renesas R-Car H3 SoC Platform" >> + depends on ARCH_RENESAS >> + help >> + This enables support for the Renesas R-Car H3 SoC. > > Do you need such fine-grained configuration? I'd really like to avoid > individual SoC Kconfig entries and only include SoC families (like > ARCH_RENESAS). There are some which I didn't spot at the time > (ARCH_FSL_LS2085A and ARCH_TEGRA_132_SOC) but we shouldn't continue this > trend any further. I agree with you about coarse grained configuration in general. I am also wondering how to handle cases where IP varies with SoC version. =) The two most common cases with SoC-specific IP for Renesas SoCs tend to be Pinctrl which is using rather large tables to support the PFC hardware and also the clocks (CCF) that drives the SoC specific CPG hardware. For the PFC and CPG I think it makes sense to enable build based on SoC model like we do already, but for the Kconfig bits in arch/arm64 perhaps ARCH_RENESAS can simply select ARCH_R8A7795? Thanks, / magnus
On Wed, Oct 28, 2015 at 09:22:34AM +0100, Geert Uytterhoeven wrote: > On Mon, Oct 26, 2015 at 7:01 AM, Simon Horman > <horms+renesas@verge.net.au> wrote: > > From: Gaku Inami <gaku.inami.xw@bp.renesas.com> > > > > Initial version of Renesas R-Car H3 support (V10) > > > > Signed-off-by: Gaku Inami <gaku.inami.xw@bp.renesas.com> > > Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> > > Signed-off-by: Magnus Damm <damm+renesas@opensource.se> > > Signed-off-by: Simon Horman <horms+renesas@verge.net.au> > > > diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi > > new file mode 100644 > > index 000000000000..aa13115387a6 > > --- /dev/null > > +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi > > > + extal_clk: extal { > > + compatible = "fixed-clock"; > > + #clock-cells = <0>; > > I would add the same override comment as for extalr here, too. Thanks, I will fix that. > > + clock-frequency = <0>; > > + }; > > + > > + extalr_clk: extalr { > > + compatible = "fixed-clock"; > > + #clock-cells = <0>; > > + /* This value must be overridden by the board */ > > + clock-frequency = <0>; > > + }; > > Nevertheless: > > Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Thanks!
On Thu, Oct 29, 2015 at 02:15:19PM +0900, Magnus Damm wrote: > On Thu, Oct 29, 2015 at 3:45 AM, Catalin Marinas > <catalin.marinas@arm.com> wrote: > > On Mon, Oct 26, 2015 at 03:01:46PM +0900, Simon Horman wrote: > >> --- a/arch/arm64/Kconfig.platforms > >> +++ b/arch/arm64/Kconfig.platforms > >> @@ -66,6 +66,23 @@ config ARCH_SEATTLE > >> help > >> This enables support for AMD Seattle SOC Family > >> > >> +config ARCH_SHMOBILE > >> + bool > >> + > >> +config ARCH_RENESAS > >> + bool "Renesas SoC Platforms" > >> + select ARCH_SHMOBILE > >> + select PINCTRL > >> + select PM_GENERIC_DOMAINS if PM > >> + help > >> + This enables support for the ARMv8 based Renesas SoCs. > >> + > >> +config ARCH_R8A7795 > >> + bool "Renesas R-Car H3 SoC Platform" > >> + depends on ARCH_RENESAS > >> + help > >> + This enables support for the Renesas R-Car H3 SoC. > > > > Do you need such fine-grained configuration? I'd really like to avoid > > individual SoC Kconfig entries and only include SoC families (like > > ARCH_RENESAS). There are some which I didn't spot at the time > > (ARCH_FSL_LS2085A and ARCH_TEGRA_132_SOC) but we shouldn't continue this > > trend any further. > > I agree with you about coarse grained configuration in general. I am > also wondering how to handle cases where IP varies with SoC version. > =) The code should cope with multiple drivers built into the kernel anyway, single Image is a hard requirement. If you want to trim down an image for a specific SoC (production kernel), just use individual Kconfig entries for drivers that may depend on ARCH_RENESAS but not an ARCH_R8A7795 which is used in drivers/ Makefiles. > The two most common cases with SoC-specific IP for Renesas SoCs tend > to be Pinctrl which is using rather large tables to support the PFC > hardware and also the clocks (CCF) that drives the SoC specific CPG > hardware. For the PFC and CPG I think it makes sense to enable build > based on SoC model like we do already, but for the Kconfig bits in > arch/arm64 perhaps ARCH_RENESAS can simply select ARCH_R8A7795? I'm suggesting the other way around: CONFIG_PINCTRL_R8A7795 which depends on ARCH_RENESAS, default y. Similarly for clocks and other drivers.
Hi Catalin, On Fri, Oct 30, 2015 at 12:08 PM, Catalin Marinas <catalin.marinas@arm.com> wrote: > On Thu, Oct 29, 2015 at 02:15:19PM +0900, Magnus Damm wrote: >> On Thu, Oct 29, 2015 at 3:45 AM, Catalin Marinas >> <catalin.marinas@arm.com> wrote: >> > On Mon, Oct 26, 2015 at 03:01:46PM +0900, Simon Horman wrote: >> >> --- a/arch/arm64/Kconfig.platforms >> >> +++ b/arch/arm64/Kconfig.platforms >> >> @@ -66,6 +66,23 @@ config ARCH_SEATTLE >> >> help >> >> This enables support for AMD Seattle SOC Family >> >> >> >> +config ARCH_SHMOBILE >> >> + bool >> >> + >> >> +config ARCH_RENESAS >> >> + bool "Renesas SoC Platforms" >> >> + select ARCH_SHMOBILE >> >> + select PINCTRL >> >> + select PM_GENERIC_DOMAINS if PM >> >> + help >> >> + This enables support for the ARMv8 based Renesas SoCs. >> >> + >> >> +config ARCH_R8A7795 >> >> + bool "Renesas R-Car H3 SoC Platform" >> >> + depends on ARCH_RENESAS >> >> + help >> >> + This enables support for the Renesas R-Car H3 SoC. >> > >> > Do you need such fine-grained configuration? I'd really like to avoid >> > individual SoC Kconfig entries and only include SoC families (like >> > ARCH_RENESAS). There are some which I didn't spot at the time >> > (ARCH_FSL_LS2085A and ARCH_TEGRA_132_SOC) but we shouldn't continue this >> > trend any further. >> >> I agree with you about coarse grained configuration in general. I am >> also wondering how to handle cases where IP varies with SoC version. >> =) > > The code should cope with multiple drivers built into the kernel anyway, > single Image is a hard requirement. If you want to trim down an image > for a specific SoC (production kernel), just use individual Kconfig > entries for drivers that may depend on ARCH_RENESAS but not an > ARCH_R8A7795 which is used in drivers/ Makefiles. > >> The two most common cases with SoC-specific IP for Renesas SoCs tend >> to be Pinctrl which is using rather large tables to support the PFC >> hardware and also the clocks (CCF) that drives the SoC specific CPG >> hardware. For the PFC and CPG I think it makes sense to enable build >> based on SoC model like we do already, but for the Kconfig bits in >> arch/arm64 perhaps ARCH_RENESAS can simply select ARCH_R8A7795? > > I'm suggesting the other way around: CONFIG_PINCTRL_R8A7795 which > depends on ARCH_RENESAS, default y. Similarly for clocks and other > drivers. For drivers in general I agree. Pinctrl and clocks (and perhaps a few others we haven't implemented support for yet) are special, as they are core SoC-support: either you want all of it, or nothing. E.g. a kernel with CONFIG_PINCTRL_R8A7795=y but CONFIG_CLK_R8A7795=n won't get you far. 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
Hi Catalin, Hi Geert, On Fri, Oct 30, 2015 at 12:19:34PM +0100, Geert Uytterhoeven wrote: > Hi Catalin, > > On Fri, Oct 30, 2015 at 12:08 PM, Catalin Marinas > <catalin.marinas@arm.com> wrote: > > On Thu, Oct 29, 2015 at 02:15:19PM +0900, Magnus Damm wrote: > >> On Thu, Oct 29, 2015 at 3:45 AM, Catalin Marinas > >> <catalin.marinas@arm.com> wrote: > >> > On Mon, Oct 26, 2015 at 03:01:46PM +0900, Simon Horman wrote: > >> >> --- a/arch/arm64/Kconfig.platforms > >> >> +++ b/arch/arm64/Kconfig.platforms > >> >> @@ -66,6 +66,23 @@ config ARCH_SEATTLE > >> >> help > >> >> This enables support for AMD Seattle SOC Family > >> >> > >> >> +config ARCH_SHMOBILE > >> >> + bool > >> >> + > >> >> +config ARCH_RENESAS > >> >> + bool "Renesas SoC Platforms" > >> >> + select ARCH_SHMOBILE > >> >> + select PINCTRL > >> >> + select PM_GENERIC_DOMAINS if PM > >> >> + help > >> >> + This enables support for the ARMv8 based Renesas SoCs. > >> >> + > >> >> +config ARCH_R8A7795 > >> >> + bool "Renesas R-Car H3 SoC Platform" > >> >> + depends on ARCH_RENESAS > >> >> + help > >> >> + This enables support for the Renesas R-Car H3 SoC. > >> > > >> > Do you need such fine-grained configuration? I'd really like to avoid > >> > individual SoC Kconfig entries and only include SoC families (like > >> > ARCH_RENESAS). There are some which I didn't spot at the time > >> > (ARCH_FSL_LS2085A and ARCH_TEGRA_132_SOC) but we shouldn't continue this > >> > trend any further. > >> > >> I agree with you about coarse grained configuration in general. I am > >> also wondering how to handle cases where IP varies with SoC version. > >> =) > > > > The code should cope with multiple drivers built into the kernel anyway, > > single Image is a hard requirement. If you want to trim down an image > > for a specific SoC (production kernel), just use individual Kconfig > > entries for drivers that may depend on ARCH_RENESAS but not an > > ARCH_R8A7795 which is used in drivers/ Makefiles. > > > >> The two most common cases with SoC-specific IP for Renesas SoCs tend > >> to be Pinctrl which is using rather large tables to support the PFC > >> hardware and also the clocks (CCF) that drives the SoC specific CPG > >> hardware. For the PFC and CPG I think it makes sense to enable build > >> based on SoC model like we do already, but for the Kconfig bits in > >> arch/arm64 perhaps ARCH_RENESAS can simply select ARCH_R8A7795? > > > > I'm suggesting the other way around: CONFIG_PINCTRL_R8A7795 which > > depends on ARCH_RENESAS, default y. Similarly for clocks and other > > drivers. > > For drivers in general I agree. > > Pinctrl and clocks (and perhaps a few others we haven't implemented support > for yet) are special, as they are core SoC-support: either you want all of it, > or nothing. > > E.g. a kernel with CONFIG_PINCTRL_R8A7795=y but CONFIG_CLK_R8A7795=n > won't get you far. If I could be so bold as to summarise the concerns they are: * On the one hand there is a desire to make configuration as simple as possible. If I understand things correctly this is the main motivation for requesting the removal of ARCH_R8A7795. * On the other hand there is a desire to give users the flexibility to easily configure their kernel for a single Renesas SoC. In particular to make sure that the appropriate PFC (PINCTRL) and CPG (CLK) drivers are present. A key reason that users want such flexibility is to reduce the size of their kernels: in particular the PFC drives are rather large. With the above in mind I wonder if a good solution would be to keep ARCH_R8A7795 but to guard it with CONFIG_EXPERT. Non-expert users would get all Renesas SoCs if the Renesas family is selected: the simple configuration that I believe Catalin desires. While expert users would have an easy way to select specific SoCs once they have enabled EXPERT. Not a terrible burden for them in my opinion.
On Mon, Nov 09, 2015 at 11:13:04AM +0900, Simon Horman wrote: > On Fri, Oct 30, 2015 at 12:19:34PM +0100, Geert Uytterhoeven wrote: > > On Fri, Oct 30, 2015 at 12:08 PM, Catalin Marinas > > <catalin.marinas@arm.com> wrote: > > > On Thu, Oct 29, 2015 at 02:15:19PM +0900, Magnus Damm wrote: > > >> The two most common cases with SoC-specific IP for Renesas SoCs tend > > >> to be Pinctrl which is using rather large tables to support the PFC > > >> hardware and also the clocks (CCF) that drives the SoC specific CPG > > >> hardware. For the PFC and CPG I think it makes sense to enable build > > >> based on SoC model like we do already, but for the Kconfig bits in > > >> arch/arm64 perhaps ARCH_RENESAS can simply select ARCH_R8A7795? > > > > > > I'm suggesting the other way around: CONFIG_PINCTRL_R8A7795 which > > > depends on ARCH_RENESAS, default y. Similarly for clocks and other > > > drivers. > > > > For drivers in general I agree. > > > > Pinctrl and clocks (and perhaps a few others we haven't implemented support > > for yet) are special, as they are core SoC-support: either you want all of it, > > or nothing. > > > > E.g. a kernel with CONFIG_PINCTRL_R8A7795=y but CONFIG_CLK_R8A7795=n > > won't get you far. > > If I could be so bold as to summarise the concerns they are: > > * On the one hand there is a desire to make configuration as simple as > possible. If I understand things correctly this is the main motivation > for requesting the removal of ARCH_R8A7795. Yes. > * On the other hand there is a desire to give users the flexibility to > easily configure their kernel for a single Renesas SoC. In particular > to make sure that the appropriate PFC (PINCTRL) and CPG (CLK) drivers are > present. A key reason that users want such flexibility is to reduce > the size of their kernels: in particular the PFC drives are rather large. The flexibility would still be there with individual CONFIG_PINCTRL... but IIUC, what you want is to be able to easily select only ARCH_R8A7795. If you start from defconfig, there are a lot more things to disable already, so I don't see how ARCH_R8A7795 helps here. Unless you start from allnoconfig and build up your configuration which, again, requires considerable more work (not something I would call easy). > With the above in mind I wonder if a good solution would be to keep > ARCH_R8A7795 but to guard it with CONFIG_EXPERT. We either keep it or remove it altogether, I don't see much point in a dependency on EXPERT. > Non-expert users would get all Renesas SoCs if the Renesas family is > selected: the simple configuration that I believe Catalin desires. > While expert users would have an easy way to select specific SoCs once > they have enabled EXPERT. Not a terrible burden for them in my opinion. It's not about allowing "expert" users to select certain features but whether we want to continue the model of individual SoC support in arm64 vs. SoC _family_ with a possibility to trim down unwanted drivers (including pinctrl, clocks) which are not needed for a SoC-specific kernel. Anyway, I'll leave the decision to the arm-soc folk.
diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index c4f19b2e7dd9..8d696a0d62b3 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -27,6 +27,8 @@ SoCs: compatible = "renesas,r8a7793" - R-Car E2 (R8A77940) compatible = "renesas,r8a7794" + - R-Car H3 (R8A77950) + compatible = "renesas,r8a7795" Boards: diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 23800a19a7bc..04bf6de3b01a 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -66,6 +66,23 @@ config ARCH_SEATTLE help This enables support for AMD Seattle SOC Family +config ARCH_SHMOBILE + bool + +config ARCH_RENESAS + bool "Renesas SoC Platforms" + select ARCH_SHMOBILE + select PINCTRL + select PM_GENERIC_DOMAINS if PM + help + This enables support for the ARMv8 based Renesas SoCs. + +config ARCH_R8A7795 + bool "Renesas R-Car H3 SoC Platform" + depends on ARCH_RENESAS + help + This enables support for the Renesas R-Car H3 SoC. + config ARCH_TEGRA bool "NVIDIA Tegra SoC Family" select ARCH_HAS_RESET_CONTROLLER diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile index d9f88330e7b0..54e401119639 100644 --- a/arch/arm64/boot/dts/Makefile +++ b/arch/arm64/boot/dts/Makefile @@ -9,6 +9,7 @@ dts-dirs += hisilicon dts-dirs += marvell dts-dirs += mediatek dts-dirs += qcom +dts-dirs += renesas dts-dirs += rockchip dts-dirs += sprd dts-dirs += xilinx diff --git a/arch/arm64/boot/dts/renesas/Makefile b/arch/arm64/boot/dts/renesas/Makefile new file mode 100644 index 000000000000..fec69f46d65b --- /dev/null +++ b/arch/arm64/boot/dts/renesas/Makefile @@ -0,0 +1,2 @@ +always := $(dtb-y) +clean-files := *.dtb diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi new file mode 100644 index 000000000000..aa13115387a6 --- /dev/null +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -0,0 +1,82 @@ +/* + * Device Tree Source for the r8a7795 SoC + * + * Copyright (C) 2015 Renesas Electronics Corp. + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + */ + +#include <dt-bindings/interrupt-controller/arm-gic.h> + +/ { + compatible = "renesas,r8a7795"; + #address-cells = <2>; + #size-cells = <2>; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + /* 1core only at this point */ + a57_0: cpu@0 { + compatible = "arm,cortex-a57", "arm,armv8"; + reg = <0x0>; + device_type = "cpu"; + }; + }; + + extal_clk: extal { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <0>; + }; + + extalr_clk: extalr { + compatible = "fixed-clock"; + #clock-cells = <0>; + /* This value must be overridden by the board */ + clock-frequency = <0>; + }; + + soc { + compatible = "simple-bus"; + interrupt-parent = <&gic>; + #address-cells = <2>; + #size-cells = <2>; + ranges; + + gic: interrupt-controller@0xf1010000 { + compatible = "arm,gic-400"; + #interrupt-cells = <3>; + #address-cells = <0>; + interrupt-controller; + reg = <0x0 0xf1010000 0 0x1000>, + <0x0 0xf1020000 0 0x2000>; + interrupts = <GIC_PPI 9 + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>; + }; + + timer { + compatible = "arm,armv8-timer"; + interrupts = <GIC_PPI 13 + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 14 + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 11 + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>, + <GIC_PPI 10 + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_LOW)>; + }; + + cpg: clock-controller@e6150000 { + compatible = "renesas,r8a7795-cpg-mssr"; + reg = <0 0xe6150000 0 0x1000>; + clocks = <&extal_clk>, <&extalr_clk>; + clock-names = "extal", "extalr"; + #clock-cells = <2>; + #power-domain-cells = <0>; + }; + }; +};