Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1412840 > unrolled thread

[PATCH v2 4/9] arm64: Add platform selection for BCM2835.

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH v2 4/9] arm64: Add platform selection for BCM2835. Gerd Hoffmann <kraxel@redhat.com> - 2016-06-03 08:30 +0200
    Re: [PATCH v2 4/9] arm64: Add platform selection for BCM2835. Catalin Marinas <catalin.marinas@arm.com> - 2016-06-03 13:30 +0200
      Re: [PATCH v2 4/9] arm64: Add platform selection for BCM2835. Eric Anholt <eric@anholt.net> - 2016-06-04 22:00 +0200
        Re: [PATCH v2 4/9] arm64: Add platform selection for BCM2835. Catalin Marinas <catalin.marinas@arm.com> - 2016-06-08 11:20 +0200
          Re: [PATCH v2 4/9] arm64: Add platform selection for BCM2835. Eric Anholt <eric@anholt.net> - 2016-06-10 02:30 +0200
            Re: [PATCH v2 4/9] arm64: Add platform selection for BCM2835. Catalin Marinas <catalin.marinas@arm.com> - 2016-06-10 12:00 +0200

#1412840 — [PATCH v2 4/9] arm64: Add platform selection for BCM2835.

From: Eric Anholt <eric@anholt.net>

Signed-off-by: Eric Anholt <eric@anholt.net>

[ kraxel: copy some selects from arm to arm64 ]

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 arch/arm64/Kconfig.platforms | 13 +++++++++++++
 1 file changed, 13 insertions(+)

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

[toc] | [next] | [standalone]

#1413141

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

[toc] | [prev] | [next] | [standalone]

#1413852

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#1417135

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

[toc] | [prev] | [next] | [standalone]

#1418961

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#1419182

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web