| Message ID | 1464934708-24769-5-git-send-email-kraxel@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Jun 03, 2016 at 08:18:23AM +0200, Gerd Hoffmann wrote: > diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > index 7ef1d05..ea88402 100644 > --- a/arch/arm64/Kconfig.platforms > +++ b/arch/arm64/Kconfig.platforms > @@ -13,6 +13,19 @@ config ARCH_ALPINE > This enables support for the Annapurna Labs Alpine > Soc family. > > +config ARCH_BCM2835 > + bool "Broadcom BCM2835 family" > + select ARCH_REQUIRE_GPIOLIB > + select CLKSRC_OF > + select PINCTRL > + select PINCTRL_BCM2835 > + select ARM_AMBA > + select ARM_TIMER_SP804 > + select HAVE_ARM_ARCH_TIMER > + help > + This enables support for the Broadcom BCM2837 SoC. > + This SoC is used in the Raspberry Pi 3 device. I thought we would just use ARCH_BCM, or is it too generic?
Catalin Marinas <catalin.marinas@arm.com> writes: > On Fri, Jun 03, 2016 at 08:18:23AM +0200, Gerd Hoffmann wrote: >> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms >> index 7ef1d05..ea88402 100644 >> --- a/arch/arm64/Kconfig.platforms >> +++ b/arch/arm64/Kconfig.platforms >> @@ -13,6 +13,19 @@ config ARCH_ALPINE >> This enables support for the Annapurna Labs Alpine >> Soc family. >> >> +config ARCH_BCM2835 >> + bool "Broadcom BCM2835 family" >> + select ARCH_REQUIRE_GPIOLIB >> + select CLKSRC_OF >> + select PINCTRL >> + select PINCTRL_BCM2835 >> + select ARM_AMBA >> + select ARM_TIMER_SP804 >> + select HAVE_ARM_ARCH_TIMER >> + help >> + This enables support for the Broadcom BCM2837 SoC. >> + This SoC is used in the Raspberry Pi 3 device. > > I thought we would just use ARCH_BCM, or is it too generic? Consensus last time around seemed to be to drop adding ARCH_BCM, in favor of patch 1 of the series.
On Sat, Jun 04, 2016 at 12:55:15PM -0700, Eric Anholt wrote: > Catalin Marinas <catalin.marinas@arm.com> writes: > > On Fri, Jun 03, 2016 at 08:18:23AM +0200, Gerd Hoffmann wrote: > >> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms > >> index 7ef1d05..ea88402 100644 > >> --- a/arch/arm64/Kconfig.platforms > >> +++ b/arch/arm64/Kconfig.platforms > >> @@ -13,6 +13,19 @@ config ARCH_ALPINE > >> This enables support for the Annapurna Labs Alpine > >> Soc family. > >> > >> +config ARCH_BCM2835 > >> + bool "Broadcom BCM2835 family" > >> + select ARCH_REQUIRE_GPIOLIB > >> + select CLKSRC_OF > >> + select PINCTRL > >> + select PINCTRL_BCM2835 > >> + select ARM_AMBA > >> + select ARM_TIMER_SP804 > >> + select HAVE_ARM_ARCH_TIMER > >> + help > >> + This enables support for the Broadcom BCM2837 SoC. Even the BCM number is inconsistent here. > >> + This SoC is used in the Raspberry Pi 3 device. > > > > I thought we would just use ARCH_BCM, or is it too generic? > > Consensus last time around seemed to be to drop adding ARCH_BCM, in > favor of patch 1 of the series. I may have missed that discussion. My point was about consistency with existing ARCH_* definitions in the arm64 Kconfig.platforms. I can see why it's easier for you since some drivers are built based on ARCH_BCM2835. Looking at drivers/clk/bcm/Makefile, there is an inconsistent mix of CLK_BCM_* and ARCH_BCM_*. I would rather have a new CLK_BCM2835 that's selected/enabled accordingly (maybe simply depending on ARCH_BCM).
Catalin Marinas <catalin.marinas@arm.com> writes: > On Sat, Jun 04, 2016 at 12:55:15PM -0700, Eric Anholt wrote: >> Catalin Marinas <catalin.marinas@arm.com> writes: >> > On Fri, Jun 03, 2016 at 08:18:23AM +0200, Gerd Hoffmann wrote: >> >> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms >> >> index 7ef1d05..ea88402 100644 >> >> --- a/arch/arm64/Kconfig.platforms >> >> +++ b/arch/arm64/Kconfig.platforms >> >> @@ -13,6 +13,19 @@ config ARCH_ALPINE >> >> This enables support for the Annapurna Labs Alpine >> >> Soc family. >> >> >> >> +config ARCH_BCM2835 >> >> + bool "Broadcom BCM2835 family" >> >> + select ARCH_REQUIRE_GPIOLIB >> >> + select CLKSRC_OF >> >> + select PINCTRL >> >> + select PINCTRL_BCM2835 >> >> + select ARM_AMBA >> >> + select ARM_TIMER_SP804 >> >> + select HAVE_ARM_ARCH_TIMER >> >> + help >> >> + This enables support for the Broadcom BCM2837 SoC. > > Even the BCM number is inconsistent here. Well, given the past chip numbers, we could call the family's Kconfig ARCH_BCM283X, and for now arm64 would only do the 2837 in the family. Back when I was doing 2836, other maintainers agreed that renaming all of the ARCH_BCM2835 in the tree to BCM283X was pointless thrashing. >> >> + This SoC is used in the Raspberry Pi 3 device. >> > >> > I thought we would just use ARCH_BCM, or is it too generic? >> >> Consensus last time around seemed to be to drop adding ARCH_BCM, in >> favor of patch 1 of the series. > > I may have missed that discussion. My point was about consistency with > existing ARCH_* definitions in the arm64 Kconfig.platforms. I can see > why it's easier for you since some drivers are built based on > ARCH_BCM2835. Looking at drivers/clk/bcm/Makefile, there is an > inconsistent mix of CLK_BCM_* and ARCH_BCM_*. I would rather have a new > CLK_BCM2835 that's selected/enabled accordingly (maybe simply depending > on ARCH_BCM). So I introduce a new ARCH_BCM here, that selects the just the 283x family's core drivers? That seems strange, but I'm willing if that's what you want.
On Thu, Jun 09, 2016 at 05:21:35PM -0700, Eric Anholt wrote: > Catalin Marinas <catalin.marinas@arm.com> writes: > > On Sat, Jun 04, 2016 at 12:55:15PM -0700, Eric Anholt wrote: > >> Catalin Marinas <catalin.marinas@arm.com> writes: > >> > On Fri, Jun 03, 2016 at 08:18:23AM +0200, Gerd Hoffmann wrote: > >> >> + This SoC is used in the Raspberry Pi 3 device. > >> > > >> > I thought we would just use ARCH_BCM, or is it too generic? > >> > >> Consensus last time around seemed to be to drop adding ARCH_BCM, in > >> favor of patch 1 of the series. > > > > I may have missed that discussion. My point was about consistency with > > existing ARCH_* definitions in the arm64 Kconfig.platforms. I can see > > why it's easier for you since some drivers are built based on > > ARCH_BCM2835. Looking at drivers/clk/bcm/Makefile, there is an > > inconsistent mix of CLK_BCM_* and ARCH_BCM_*. I would rather have a new > > CLK_BCM2835 that's selected/enabled accordingly (maybe simply depending > > on ARCH_BCM). > > So I introduce a new ARCH_BCM here, that selects the just the 283x > family's core drivers? That seems strange, but I'm willing if that's > what you want. I'll leave this decision to the arm-soc guys. What I want to avoid is another ARCH_BCM283[89] when some clock or other device changes in a future revision of this board (RPi4?). I also don't want fine-grained SoC configuration *within* the arch/arm64 Kconfigs but rather just a family ARCH_* entry with selectable individual drivers based on the SoC revision you target (in case you want to avoid single Image). We should in general try to give drivers their own Kconfig entries separate from ARCH_* ones (with a "depend on ARCH_*" and default y if you want it enabled).
Catalin Marinas <catalin.marinas@arm.com> writes: > On Thu, Jun 09, 2016 at 05:21:35PM -0700, Eric Anholt wrote: >> Catalin Marinas <catalin.marinas@arm.com> writes: >> > On Sat, Jun 04, 2016 at 12:55:15PM -0700, Eric Anholt wrote: >> >> Catalin Marinas <catalin.marinas@arm.com> writes: >> >> > On Fri, Jun 03, 2016 at 08:18:23AM +0200, Gerd Hoffmann wrote: >> >> >> + This SoC is used in the Raspberry Pi 3 device. >> >> > >> >> > I thought we would just use ARCH_BCM, or is it too generic? >> >> >> >> Consensus last time around seemed to be to drop adding ARCH_BCM, in >> >> favor of patch 1 of the series. >> > >> > I may have missed that discussion. My point was about consistency with >> > existing ARCH_* definitions in the arm64 Kconfig.platforms. I can see >> > why it's easier for you since some drivers are built based on >> > ARCH_BCM2835. Looking at drivers/clk/bcm/Makefile, there is an >> > inconsistent mix of CLK_BCM_* and ARCH_BCM_*. I would rather have a new >> > CLK_BCM2835 that's selected/enabled accordingly (maybe simply depending >> > on ARCH_BCM). >> >> So I introduce a new ARCH_BCM here, that selects the just the 283x >> family's core drivers? That seems strange, but I'm willing if that's >> what you want. > > I'll leave this decision to the arm-soc guys. What I want to avoid is > another ARCH_BCM283[89] when some clock or other device changes in a > future revision of this board (RPi4?). I also don't want fine-grained > SoC configuration *within* the arch/arm64 Kconfigs but rather just a > family ARCH_* entry with selectable individual drivers based on the SoC > revision you target (in case you want to avoid single Image). > > We should in general try to give drivers their own Kconfig entries > separate from ARCH_* ones (with a "depend on ARCH_*" and default y if > you want it enabled). OK, we haven't added separate ARCH_BCM283* for the 3 chip revs so far, so I think what you want is actually the status quo, and we're in serious agreement. The name for the family just happens to be ARCH_BCM2835. Any chance we could get an ack on this?
On Tue, Jun 14, 2016 at 11:48:54PM -0700, Eric Anholt wrote: > Catalin Marinas <catalin.marinas@arm.com> writes: > > > On Thu, Jun 09, 2016 at 05:21:35PM -0700, Eric Anholt wrote: > >> Catalin Marinas <catalin.marinas@arm.com> writes: > >> > On Sat, Jun 04, 2016 at 12:55:15PM -0700, Eric Anholt wrote: > >> >> Catalin Marinas <catalin.marinas@arm.com> writes: > >> >> > On Fri, Jun 03, 2016 at 08:18:23AM +0200, Gerd Hoffmann wrote: > >> >> >> + This SoC is used in the Raspberry Pi 3 device. > >> >> > > >> >> > I thought we would just use ARCH_BCM, or is it too generic? > >> >> > >> >> Consensus last time around seemed to be to drop adding ARCH_BCM, in > >> >> favor of patch 1 of the series. > >> > > >> > I may have missed that discussion. My point was about consistency with > >> > existing ARCH_* definitions in the arm64 Kconfig.platforms. I can see > >> > why it's easier for you since some drivers are built based on > >> > ARCH_BCM2835. Looking at drivers/clk/bcm/Makefile, there is an > >> > inconsistent mix of CLK_BCM_* and ARCH_BCM_*. I would rather have a new > >> > CLK_BCM2835 that's selected/enabled accordingly (maybe simply depending > >> > on ARCH_BCM). > >> > >> So I introduce a new ARCH_BCM here, that selects the just the 283x > >> family's core drivers? That seems strange, but I'm willing if that's > >> what you want. > > > > I'll leave this decision to the arm-soc guys. What I want to avoid is > > another ARCH_BCM283[89] when some clock or other device changes in a > > future revision of this board (RPi4?). I also don't want fine-grained > > SoC configuration *within* the arch/arm64 Kconfigs but rather just a > > family ARCH_* entry with selectable individual drivers based on the SoC > > revision you target (in case you want to avoid single Image). > > > > We should in general try to give drivers their own Kconfig entries > > separate from ARCH_* ones (with a "depend on ARCH_*" and default y if > > you want it enabled). > > OK, we haven't added separate ARCH_BCM283* for the 3 chip revs so far, > so I think what you want is actually the status quo, and we're in > serious agreement. The name for the family just happens to be > ARCH_BCM2835. > > Any chance we could get an ack on this? If you need one ;) (arm-soc is maintaining this file): Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Catalin Marinas <catalin.marinas@arm.com> writes: > On Tue, Jun 14, 2016 at 11:48:54PM -0700, Eric Anholt wrote: >> Catalin Marinas <catalin.marinas@arm.com> writes: >> >> > On Thu, Jun 09, 2016 at 05:21:35PM -0700, Eric Anholt wrote: >> >> Catalin Marinas <catalin.marinas@arm.com> writes: >> >> > On Sat, Jun 04, 2016 at 12:55:15PM -0700, Eric Anholt wrote: >> >> >> Catalin Marinas <catalin.marinas@arm.com> writes: >> >> >> > On Fri, Jun 03, 2016 at 08:18:23AM +0200, Gerd Hoffmann wrote: >> >> >> >> + This SoC is used in the Raspberry Pi 3 device. >> >> >> > >> >> >> > I thought we would just use ARCH_BCM, or is it too generic? >> >> >> >> >> >> Consensus last time around seemed to be to drop adding ARCH_BCM, in >> >> >> favor of patch 1 of the series. >> >> > >> >> > I may have missed that discussion. My point was about consistency with >> >> > existing ARCH_* definitions in the arm64 Kconfig.platforms. I can see >> >> > why it's easier for you since some drivers are built based on >> >> > ARCH_BCM2835. Looking at drivers/clk/bcm/Makefile, there is an >> >> > inconsistent mix of CLK_BCM_* and ARCH_BCM_*. I would rather have a new >> >> > CLK_BCM2835 that's selected/enabled accordingly (maybe simply depending >> >> > on ARCH_BCM). >> >> >> >> So I introduce a new ARCH_BCM here, that selects the just the 283x >> >> family's core drivers? That seems strange, but I'm willing if that's >> >> what you want. >> > >> > I'll leave this decision to the arm-soc guys. What I want to avoid is >> > another ARCH_BCM283[89] when some clock or other device changes in a >> > future revision of this board (RPi4?). I also don't want fine-grained >> > SoC configuration *within* the arch/arm64 Kconfigs but rather just a >> > family ARCH_* entry with selectable individual drivers based on the SoC >> > revision you target (in case you want to avoid single Image). >> > >> > We should in general try to give drivers their own Kconfig entries >> > separate from ARCH_* ones (with a "depend on ARCH_*" and default y if >> > you want it enabled). >> >> OK, we haven't added separate ARCH_BCM283* for the 3 chip revs so far, >> so I think what you want is actually the status quo, and we're in >> serious agreement. The name for the family just happens to be >> ARCH_BCM2835. >> >> Any chance we could get an ack on this? > > If you need one ;) (arm-soc is maintaining this file): > > Acked-by: Catalin Marinas <catalin.marinas@arm.com> It's in my for-next now. Thanks!
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms index 7ef1d05..ea88402 100644 --- a/arch/arm64/Kconfig.platforms +++ b/arch/arm64/Kconfig.platforms @@ -13,6 +13,19 @@ config ARCH_ALPINE This enables support for the Annapurna Labs Alpine Soc family. +config ARCH_BCM2835 + bool "Broadcom BCM2835 family" + select ARCH_REQUIRE_GPIOLIB + select CLKSRC_OF + select PINCTRL + select PINCTRL_BCM2835 + select ARM_AMBA + select ARM_TIMER_SP804 + select HAVE_ARM_ARCH_TIMER + help + This enables support for the Broadcom BCM2837 SoC. + This SoC is used in the Raspberry Pi 3 device. + config ARCH_BCM_IPROC bool "Broadcom iProc SoC Family" select COMMON_CLK_IPROC