[PATCH v2 1/9] pinctrl: walk into bcm subdir unconditionally

[PATCH v2 1/9] pinctrl: walk into bcm subdir unconditionally

[Gerd Hoffmann]

There is no ARCH_BCM on arm64, and we need pinctrl-bcm2835 for the rpi3.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 drivers/pinctrl/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index e4bc115..88586c0 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -35,7 +35,7 @@ obj-$(CONFIG_PINCTRL_TB10X)	+= pinctrl-tb10x.o
 obj-$(CONFIG_PINCTRL_ST) 	+= pinctrl-st.o
 obj-$(CONFIG_PINCTRL_ZYNQ)	+= pinctrl-zynq.o
 
-obj-$(CONFIG_ARCH_BCM)		+= bcm/
+obj-y				+= bcm/
 obj-$(CONFIG_PINCTRL_BERLIN)	+= berlin/
 obj-y				+= freescale/
 obj-$(CONFIG_X86)		+= intel/
-- 
1.8.3.1

Re: [PATCH v2 1/9] pinctrl: walk into bcm subdir unconditionally

[Linus Walleij]

On Fri, Jun 3, 2016 at 8:18 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:

> There is no ARCH_BCM on arm64, and we need pinctrl-bcm2835 for the rpi3.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  drivers/pinctrl/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
> index e4bc115..88586c0 100644
> --- a/drivers/pinctrl/Makefile
> +++ b/drivers/pinctrl/Makefile
> @@ -35,7 +35,7 @@ obj-$(CONFIG_PINCTRL_TB10X)   += pinctrl-tb10x.o
>  obj-$(CONFIG_PINCTRL_ST)       += pinctrl-st.o
>  obj-$(CONFIG_PINCTRL_ZYNQ)     += pinctrl-zynq.o
>
> -obj-$(CONFIG_ARCH_BCM)         += bcm/
> +obj-y                          += bcm/

Looks OK to me, but would like Stephen's or Eric's ACK?

Yours,
Linus Walleij

Re: [PATCH v2 1/9] pinctrl: walk into bcm subdir unconditionally

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

Linus Walleij <linus.walleij@linaro.org> writes:

> On Fri, Jun 3, 2016 at 8:18 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>> There is no ARCH_BCM on arm64, and we need pinctrl-bcm2835 for the rpi3.
>>
>> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>> ---
>>  drivers/pinctrl/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
>> index e4bc115..88586c0 100644
>> --- a/drivers/pinctrl/Makefile
>> +++ b/drivers/pinctrl/Makefile
>> @@ -35,7 +35,7 @@ obj-$(CONFIG_PINCTRL_TB10X)   += pinctrl-tb10x.o
>>  obj-$(CONFIG_PINCTRL_ST)       += pinctrl-st.o
>>  obj-$(CONFIG_PINCTRL_ZYNQ)     += pinctrl-zynq.o
>>
>> -obj-$(CONFIG_ARCH_BCM)         += bcm/
>> +obj-y                          += bcm/
>
> Looks OK to me, but would like Stephen's or Eric's ACK?

It looks like this is the only instance of filtering the directory on
CONFIG_ARCH_BCM, so regardless of the patch 4 resolution,

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: [PATCH v2 1/9] pinctrl: walk into bcm subdir unconditionally

[Linus Walleij]

On Fri, Jun 3, 2016 at 8:18 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:

> There is no ARCH_BCM on arm64, and we need pinctrl-bcm2835 for the rpi3.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

I see I got an identical patch from Florian Fainelli and applied it.
Sorry for my clashes, confusion and screwups... Added Eric's
ACK on the applied patch.

Yours,
Linus Walleij

Re: [PATCH v2 1/9] pinctrl: walk into bcm subdir unconditionally

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 509 bytes --]

Linus Walleij <linus.walleij@linaro.org> writes:

> On Fri, Jun 3, 2016 at 8:18 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
>> There is no ARCH_BCM on arm64, and we need pinctrl-bcm2835 for the rpi3.
>>
>> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
>
> I see I got an identical patch from Florian Fainelli and applied it.
> Sorry for my clashes, confusion and screwups... Added Eric's
> ACK on the applied patch.

Florian's had a nice commit message, and I'm just happy to see patches
land.  Thanks!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[PATCH v2 2/9] irqchip: bcm2835: Avoid arch/arm-specific handle_IRQ.

[Gerd Hoffmann]

From: Eric Anholt <eric@anholt.net>

This is equivalent and works for arm64 as well.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 drivers/irqchip/irq-bcm2835.c | 3 +--
 drivers/irqchip/irq-bcm2836.c | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-bcm2835.c b/drivers/irqchip/irq-bcm2835.c
index bf9cc5f..44d7c38 100644
--- a/drivers/irqchip/irq-bcm2835.c
+++ b/drivers/irqchip/irq-bcm2835.c
@@ -52,7 +52,6 @@
 #include <linux/irqdomain.h>
 
 #include <asm/exception.h>
-#include <asm/mach/irq.h>
 
 /* Put the bank and irq (32 bits) into the hwirq */
 #define MAKE_HWIRQ(b, n)	((b << 5) | (n))
@@ -242,7 +241,7 @@ static void __exception_irq_entry bcm2835_handle_irq(
 	u32 hwirq;
 
 	while ((hwirq = get_next_armctrl_hwirq()) != ~0)
-		handle_IRQ(irq_linear_revmap(intc.domain, hwirq), regs);
+		handle_domain_irq(intc.domain, hwirq, regs);
 }
 
 static void bcm2836_chained_handle_irq(struct irq_desc *desc)
diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index 72ff1d5..2787598 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -180,7 +180,7 @@ __exception_irq_entry bcm2836_arm_irqchip_handle_irq(struct pt_regs *regs)
 	} else if (stat) {
 		u32 hwirq = ffs(stat) - 1;
 
-		handle_IRQ(irq_linear_revmap(intc.domain, hwirq), regs);
+		handle_domain_irq(intc.domain, hwirq, regs);
 	}
 }
 
-- 
1.8.3.1

[PATCH v2 3/9] arm64: Allow for different DMA and CPU bus offsets

[Gerd Hoffmann]

From: Alexander Graf <agraf@suse.de>

On arm64, all SoCs we supported so far either have an IOMMU or have bus
addresses equal to CPU addresses.

However, with the Raspberry Pi 3 coming up, this is no longer true. To
allow DMA to work with an AArch64 kernel on those devices, let's allow
devices to have DMA offsets again.

Signed-off-by: Alexander Graf <agraf@suse.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm64/include/asm/dma-mapping.h | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/include/asm/dma-mapping.h b/arch/arm64/include/asm/dma-mapping.h
index 7dbea6c..ccea82c 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -66,12 +66,16 @@ static inline bool is_device_dma_coherent(struct device *dev)
 
 static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
 {
-	return (dma_addr_t)paddr;
+	dma_addr_t dev_addr = (dma_addr_t)paddr;
+
+	return dev_addr - ((dma_addr_t)dev->dma_pfn_offset << PAGE_SHIFT);
 }
 
 static inline phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dev_addr)
 {
-	return (phys_addr_t)dev_addr;
+	phys_addr_t paddr = (phys_addr_t)dev_addr;
+
+	return paddr + ((phys_addr_t)dev->dma_pfn_offset << PAGE_SHIFT);
 }
 
 static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
@@ -86,5 +90,14 @@ static inline void dma_mark_clean(void *addr, size_t size)
 {
 }
 
+/* Override for dma_max_pfn() */
+static inline unsigned long dma_max_pfn(struct device *dev)
+{
+	dma_addr_t dma_max = (dma_addr_t)*dev->dma_mask;
+
+	return (ulong)dma_to_phys(dev, dma_max) >> PAGE_SHIFT;
+}
+#define dma_max_pfn(dev) dma_max_pfn(dev)
+
 #endif	/* __KERNEL__ */
 #endif	/* __ASM_DMA_MAPPING_H */
-- 
1.8.3.1

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

[Gerd Hoffmann]

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

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

[Catalin Marinas]

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

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

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 983 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

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

[Catalin Marinas]

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

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

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 2119 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

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

[Catalin Marinas]

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

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

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]

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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

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

[Catalin Marinas]

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>

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

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 2538 bytes --]

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!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[PATCH v2 5/9] arm64: Add BCM2835 support to the defconfig.

[Gerd Hoffmann]

From: Eric Anholt <eric@anholt.net>

Made with make defconfig; make menuconfig (only saying Y to new
entries); make savedefconfig.

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

[ kraxel: quick+dirty rebase to 4.7 ]

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 arch/arm64/configs/defconfig | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index fd2d74d..03f246a 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -31,6 +31,7 @@ CONFIG_MODULE_UNLOAD=y
 # CONFIG_IOSCHED_DEADLINE is not set
 CONFIG_ARCH_SUNXI=y
 CONFIG_ARCH_ALPINE=y
+CONFIG_ARCH_BCM2835=y
 CONFIG_ARCH_BCM_IPROC=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_ARCH_EXYNOS=y
@@ -140,6 +141,9 @@ CONFIG_USB_NET_PLUSB=m
 CONFIG_USB_NET_MCS7830=m
 CONFIG_WL18XX=m
 CONFIG_WLCORE_SDIO=m
+CONFIG_USB_USBNET=y
+CONFIG_USB_NET_SMSC95XX=y
+# CONFIG_WLAN is not set
 CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_GPIO=y
 # CONFIG_SERIO_SERPORT is not set
@@ -147,6 +151,9 @@ CONFIG_SERIO_AMBAKMI=y
 CONFIG_LEGACY_PTY_COUNT=16
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_EXTENDED=y
+CONFIG_SERIAL_8250_SHARE_IRQ=y
+CONFIG_SERIAL_8250_BCM2835AUX=y
 CONFIG_SERIAL_8250_DW=y
 CONFIG_SERIAL_8250_MT6577=y
 CONFIG_SERIAL_8250_UNIPHIER=y
@@ -173,6 +180,7 @@ CONFIG_I2C_MUX=y
 CONFIG_I2C_MUX_PCA954x=y
 CONFIG_I2C_DESIGNWARE_PLATFORM=y
 CONFIG_I2C_IMX=y
+CONFIG_I2C_BCM2835=y
 CONFIG_I2C_MV64XXX=y
 CONFIG_I2C_QUP=y
 CONFIG_I2C_TEGRA=y
@@ -180,6 +188,8 @@ CONFIG_I2C_UNIPHIER_F=y
 CONFIG_I2C_RCAR=y
 CONFIG_SPI=y
 CONFIG_SPI_ORION=y
+CONFIG_SPI_BCM2835=y
+CONFIG_SPI_BCM2835AUX=y
 CONFIG_SPI_PL022=y
 CONFIG_SPI_QUP=y
 CONFIG_SPI_SPIDEV=m
@@ -206,20 +216,24 @@ CONFIG_MFD_SPMI_PMIC=y
 CONFIG_MFD_SEC_CORE=y
 CONFIG_MFD_HI655X_PMIC=y
 CONFIG_REGULATOR=y
+CONFIG_BCM2835_WDT=y
+CONFIG_MFD_SPMI_PMIC=y
+CONFIG_MFD_SEC_CORE=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_HI655X=y
 CONFIG_REGULATOR_QCOM_SMD_RPM=y
 CONFIG_REGULATOR_QCOM_SPMI=y
 CONFIG_REGULATOR_S2MPS11=y
-CONFIG_FB=y
+CONFIG_DRM=y
+CONFIG_DRM_VC4=y
 CONFIG_FB_ARMCLCD=y
-CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_LOGO=y
 # CONFIG_LOGO_LINUX_MONO is not set
 # CONFIG_LOGO_LINUX_VGA16 is not set
 CONFIG_SOUND=y
 CONFIG_SND=y
 CONFIG_SND_SOC=y
+CONFIG_SND_BCM2835_SOC_I2S=y
 CONFIG_SND_SOC_RCAR=y
 CONFIG_SND_SOC_AK4613=y
 CONFIG_USB=y
@@ -270,6 +284,7 @@ CONFIG_RTC_DRV_SUN6I=y
 CONFIG_RTC_DRV_XGENE=y
 CONFIG_DMADEVICES=y
 CONFIG_PL330_DMA=y
+CONFIG_DMA_BCM2835=y
 CONFIG_TEGRA20_APB_DMA=y
 CONFIG_QCOM_BAM_DMA=y
 CONFIG_RCAR_DMAC=y
@@ -289,7 +304,9 @@ CONFIG_HWSPINLOCK_QCOM=y
 CONFIG_MAILBOX=y
 CONFIG_ARM_MHU=y
 CONFIG_HI6220_MBOX=y
+CONFIG_BCM2835_MBOX=y
 CONFIG_ARM_SMMU=y
+CONFIG_RASPBERRYPI_POWER=y
 CONFIG_QCOM_SMEM=y
 CONFIG_QCOM_SMD=y
 CONFIG_QCOM_SMD_RPM=y
@@ -302,6 +319,7 @@ CONFIG_PHY_HI6220_USB=y
 CONFIG_PHY_XGENE=y
 CONFIG_ARM_SCPI_PROTOCOL=y
 CONFIG_ACPI=y
+CONFIG_RASPBERRYPI_FIRMWARE=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 CONFIG_FANOTIFY=y
@@ -311,7 +329,6 @@ CONFIG_AUTOFS4_FS=y
 CONFIG_FUSE_FS=y
 CONFIG_CUSE=y
 CONFIG_VFAT_FS=y
-CONFIG_TMPFS=y
 CONFIG_HUGETLBFS=y
 CONFIG_CONFIGFS_FS=y
 CONFIG_EFIVAR_FS=y
-- 
1.8.3.1

Re: [PATCH v2 5/9] arm64: Add BCM2835 support to the defconfig.

[Arnd Bergmann]

On Friday, June 3, 2016 8:18:24 AM CEST Gerd Hoffmann wrote:
> From: Eric Anholt <eric@anholt.net>
> 
> Made with make defconfig; make menuconfig (only saying Y to new
> entries); make savedefconfig.

Please try not to mix 'make savedefconfig' changes with your
own changes, it make it harder to review and can lead to more
conflicts.

> @@ -140,6 +141,9 @@ CONFIG_USB_NET_PLUSB=m
>  CONFIG_USB_NET_MCS7830=m
>  CONFIG_WL18XX=m
>  CONFIG_WLCORE_SDIO=m
> +CONFIG_USB_USBNET=y
> +CONFIG_USB_NET_SMSC95XX=y
> +# CONFIG_WLAN is not set
>  CONFIG_INPUT_EVDEV=y
>  CONFIG_KEYBOARD_GPIO=y

Can this be =m like the others?

> -CONFIG_FB=y
> -CONFIG_FRAMEBUFFER_CONSOLE=y

Is this intended?

> +CONFIG_DRM=y
> +CONFIG_DRM_VC4=y
>  CONFIG_FB_ARMCLCD=y
>  CONFIG_LOGO=y

Maybe modules?


>  # CONFIG_LOGO_LINUX_MONO is not set
>  # CONFIG_LOGO_LINUX_VGA16 is not set
>  CONFIG_SOUND=y
>  CONFIG_SND=y
>  CONFIG_SND_SOC=y
> +CONFIG_SND_BCM2835_SOC_I2S=y
>  CONFIG_SND_SOC_RCAR=y
>  CONFIG_SND_SOC_AK4613=y
>  CONFIG_USB=y

We probably want CONFIG_SND=m, but that should be a separate patch.

> @@ -270,6 +284,7 @@ CONFIG_RTC_DRV_SUN6I=y
>  CONFIG_RTC_DRV_XGENE=y
>  CONFIG_DMADEVICES=y
>  CONFIG_PL330_DMA=y
> +CONFIG_DMA_BCM2835=y
>  CONFIG_TEGRA20_APB_DMA=y
>  CONFIG_QCOM_BAM_DMA=y
>  CONFIG_RCAR_DMAC=y

Does any essential driver depend on this one?

> @@ -311,7 +329,6 @@ CONFIG_AUTOFS4_FS=y
>  CONFIG_FUSE_FS=y
>  CONFIG_CUSE=y
>  CONFIG_VFAT_FS=y
> -CONFIG_TMPFS=y
>  CONFIG_HUGETLBFS=y
>  CONFIG_CONFIGFS_FS=y
>  CONFIG_EFIVAR_FS=y

Why?

	Arnd

Re: [PATCH v2 5/9] arm64: Add BCM2835 support to the defconfig.

[Gerd Hoffmann]

On Fr, 2016-06-03 at 09:36 +0200, Arnd Bergmann wrote:
> On Friday, June 3, 2016 8:18:24 AM CEST Gerd Hoffmann wrote:
> > From: Eric Anholt <eric@anholt.net>
> > 
> > Made with make defconfig; make menuconfig (only saying Y to new
> > entries); make savedefconfig.
> 
> Please try not to mix 'make savedefconfig' changes with your
> own changes, it make it harder to review and can lead to more
> conflicts.

This is just conflicts resolved by hand after 4.6 -> 4.7-rc1 rebase,
latest version didn't actually ran through savedefconfig.  Probably some
unwanted changes made it in by accident this way.

Guess I better redo this from scratch.

What is the suggested procedure to generate defconfig patches?

cheers,
  Gerd

Re: [PATCH v2 5/9] arm64: Add BCM2835 support to the defconfig.

[Arnd Bergmann]

On Friday, June 3, 2016 10:50:16 AM CEST Gerd Hoffmann wrote:
> On Fr, 2016-06-03 at 09:36 +0200, Arnd Bergmann wrote:
> > On Friday, June 3, 2016 8:18:24 AM CEST Gerd Hoffmann wrote:
> > > From: Eric Anholt <eric@anholt.net>
> > > 
> > > Made with make defconfig; make menuconfig (only saying Y to new
> > > entries); make savedefconfig.
> > 
> > Please try not to mix 'make savedefconfig' changes with your
> > own changes, it make it harder to review and can lead to more
> > conflicts.
> 
> This is just conflicts resolved by hand after 4.6 -> 4.7-rc1 rebase,
> latest version didn't actually ran through savedefconfig.  Probably some
> unwanted changes made it in by accident this way.
> 
> Guess I better redo this from scratch.
> 
> What is the suggested procedure to generate defconfig patches?

I tend to just edit the files by hand, or use 'make savedefconfig' to
create an initial version, and then use 'vimdiff' to revert the changes
I don't want.

	Arnd

Re: [PATCH v2 5/9] arm64: Add BCM2835 support to the defconfig.

[Gerd Hoffmann]

  Hi,

> > @@ -311,7 +329,6 @@ CONFIG_AUTOFS4_FS=y
> >  CONFIG_FUSE_FS=y
> >  CONFIG_CUSE=y
> >  CONFIG_VFAT_FS=y
> > -CONFIG_TMPFS=y
> >  CONFIG_HUGETLBFS=y
> >  CONFIG_CONFIGFS_FS=y
> >  CONFIG_EFIVAR_FS=y
> 
> Why?

That seems to come from enabling drm+vc4, probably something does
"select TMPFS".

cheers,
  Gerd

Re: [PATCH v2 5/9] arm64: Add BCM2835 support to the defconfig.

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]

Arnd Bergmann <arnd@arndb.de> writes:

> On Friday, June 3, 2016 8:18:24 AM CEST Gerd Hoffmann wrote:
>> From: Eric Anholt <eric@anholt.net>
>> 
>> Made with make defconfig; make menuconfig (only saying Y to new
>> entries); make savedefconfig.
>
> Please try not to mix 'make savedefconfig' changes with your
> own changes, it make it harder to review and can lead to more
> conflicts.
>
>> @@ -140,6 +141,9 @@ CONFIG_USB_NET_PLUSB=m
>>  CONFIG_USB_NET_MCS7830=m
>>  CONFIG_WL18XX=m
>>  CONFIG_WLCORE_SDIO=m
>> +CONFIG_USB_USBNET=y
>> +CONFIG_USB_NET_SMSC95XX=y
>> +# CONFIG_WLAN is not set
>>  CONFIG_INPUT_EVDEV=y
>>  CONFIG_KEYBOARD_GPIO=y
>
> Can this be =m like the others?

I guess, but it's an on-board device and I was assuming =m was about
whether the device is always present on the board being added.

>> -CONFIG_FB=y
>> -CONFIG_FRAMEBUFFER_CONSOLE=y
>
> Is this intended?
>
>> +CONFIG_DRM=y
>> +CONFIG_DRM_VC4=y
>>  CONFIG_FB_ARMCLCD=y
>>  CONFIG_LOGO=y
>
> Maybe modules?

It looks like in multi_v7_defconfig we have CONFIG_DRM=y but
CONFIG_DRM_*=m, so should we be consistent with that?

>>  # CONFIG_LOGO_LINUX_MONO is not set
>>  # CONFIG_LOGO_LINUX_VGA16 is not set
>>  CONFIG_SOUND=y
>>  CONFIG_SND=y
>>  CONFIG_SND_SOC=y
>> +CONFIG_SND_BCM2835_SOC_I2S=y
>>  CONFIG_SND_SOC_RCAR=y
>>  CONFIG_SND_SOC_AK4613=y
>>  CONFIG_USB=y
>
> We probably want CONFIG_SND=m, but that should be a separate patch.
>
>> @@ -270,6 +284,7 @@ CONFIG_RTC_DRV_SUN6I=y
>>  CONFIG_RTC_DRV_XGENE=y
>>  CONFIG_DMADEVICES=y
>>  CONFIG_PL330_DMA=y
>> +CONFIG_DMA_BCM2835=y
>>  CONFIG_TEGRA20_APB_DMA=y
>>  CONFIG_QCOM_BAM_DMA=y
>>  CONFIG_RCAR_DMAC=y
>
> Does any essential driver depend on this one?

bcm2835-sdhost and vc4 will eventually.

>> @@ -311,7 +329,6 @@ CONFIG_AUTOFS4_FS=y
>>  CONFIG_FUSE_FS=y
>>  CONFIG_CUSE=y
>>  CONFIG_VFAT_FS=y
>> -CONFIG_TMPFS=y
>>  CONFIG_HUGETLBFS=y
>>  CONFIG_CONFIGFS_FS=y
>>  CONFIG_EFIVAR_FS=y
>
> Why?

DRM was selecting it, so savedefconfig dropped it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

[PATCH v2 6/9] dt-bindings: Add root properties for Raspberry Pi 3

[Gerd Hoffmann]

From: Eric Anholt <eric@anholt.net>

Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Acked-by: Rob Herring <robh@kernel.org>
---
 Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt
index 11d3056..6ffe087 100644
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm2835.txt
@@ -30,6 +30,10 @@ Raspberry Pi 2 Model B
 Required root node properties:
 compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
 
+Raspberry Pi 3 Model B
+Required root node properties:
+compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
+
 Raspberry Pi Compute Module
 Required root node properties:
 compatible = "raspberrypi,compute-module", "brcm,bcm2835";
-- 
1.8.3.1

[PATCH v2 7/9] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

[Gerd Hoffmann]

From: Eric Anholt <eric@anholt.net>

While this devicetree also works for booting in 32-bit mode, it's
placed in arm64 since it's a 64-bit CPU (as suggested by Arnd).

v2: Move to arm64/ instead of arm/

Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Stephen Warren <swarren@wwwdotorg.org> (v1)

[ kraxel: update bcm2837-rpi-3-b.dtb path in arm(32) Makefile ]

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 arch/arm/boot/dts/Makefile                       |  3 +-
 arch/arm64/boot/dts/broadcom/Makefile            |  1 +
 arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts | 29 ++++++++++
 arch/arm64/boot/dts/broadcom/bcm2837.dtsi        | 74 ++++++++++++++++++++++++
 4 files changed, 106 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
 create mode 100644 arch/arm64/boot/dts/broadcom/bcm2837.dtsi

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 06b6c2d..71e2d36 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -66,7 +66,8 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
 	bcm2835-rpi-b-rev2.dtb \
 	bcm2835-rpi-b-plus.dtb \
 	bcm2835-rpi-a-plus.dtb \
-	bcm2836-rpi-2-b.dtb
+	bcm2836-rpi-2-b.dtb \
+	../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb
 dtb-$(CONFIG_ARCH_BCM_5301X) += \
 	bcm4708-asus-rt-ac56u.dtb \
 	bcm4708-asus-rt-ac68u.dtb \
diff --git a/arch/arm64/boot/dts/broadcom/Makefile b/arch/arm64/boot/dts/broadcom/Makefile
index bec1f8b..05faf2a 100644
--- a/arch/arm64/boot/dts/broadcom/Makefile
+++ b/arch/arm64/boot/dts/broadcom/Makefile
@@ -1,3 +1,4 @@
+dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-3-b.dtb
 dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb
 dtb-$(CONFIG_ARCH_VULCAN) += vulcan-eval.dtb
 
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
new file mode 100644
index 0000000..223793d
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
@@ -0,0 +1,29 @@
+/dts-v1/;
+#include "bcm2837.dtsi"
+#include "../../../../arm/boot/dts/bcm2835-rpi.dtsi"
+
+/ {
+	compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
+	model = "Raspberry Pi 3 Model B";
+
+	memory {
+		reg = <0 0x40000000>;
+	};
+
+	leds {
+		act {
+			gpios = <&gpio 47 0>;
+		};
+
+		pwr {
+			label = "PWR";
+			gpios = <&gpio 35 0>;
+			default-state = "keep";
+			linux,default-trigger = "default-on";
+		};
+	};
+};
+
+&uart1 {
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
new file mode 100644
index 0000000..2320f8d
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/bcm2837.dtsi
@@ -0,0 +1,74 @@
+#include "../../../../arm/boot/dts/bcm283x.dtsi"
+
+/ {
+	compatible = "brcm,bcm2836";
+
+	soc {
+		ranges = <0x7e000000 0x3f000000 0x1000000>,
+			 <0x40000000 0x40000000 0x00001000>;
+		dma-ranges = <0xc0000000 0x00000000 0x3f000000>;
+
+		local_intc: local_intc {
+			compatible = "brcm,bcm2836-l1-intc";
+			reg = <0x40000000 0x100>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			interrupt-parent = <&local_intc>;
+		};
+	};
+
+	timer {
+		compatible = "arm,armv7-timer";
+		interrupt-parent = <&local_intc>;
+		interrupts = <0>, // PHYS_SECURE_PPI
+			     <1>, // PHYS_NONSECURE_PPI
+			     <3>, // VIRT_PPI
+			     <2>; // HYP_PPI
+		always-on;
+	};
+
+	cpus: cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu0: cpu@0 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53";
+			reg = <0>;
+		};
+
+		cpu1: cpu@1 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53";
+			reg = <1>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x0 0x000000e0>;
+		};
+
+		cpu2: cpu@2 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53";
+			reg = <2>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x0 0x000000e8>;
+		};
+
+		cpu3: cpu@3 {
+			device_type = "cpu";
+			compatible = "arm,cortex-a53";
+			reg = <3>;
+			enable-method = "spin-table";
+			cpu-release-addr = <0x0 0x000000f0>;
+		};
+	};
+};
+
+/* Make the BCM2835-style global interrupt controller be a child of the
+ * CPU-local interrupt controller.
+ */
+&intc {
+	compatible = "brcm,bcm2836-armctrl-ic";
+	reg = <0x7e00b200 0x200>;
+	interrupt-parent = <&local_intc>;
+	interrupts = <8>;
+};
-- 
1.8.3.1

Re: [PATCH v2 7/9] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

[Arnd Bergmann]

On Friday, June 3, 2016 8:18:26 AM CEST Gerd Hoffmann wrote:
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 06b6c2d..71e2d36 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -66,7 +66,8 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
>         bcm2835-rpi-b-rev2.dtb \
>         bcm2835-rpi-b-plus.dtb \
>         bcm2835-rpi-a-plus.dtb \
> -       bcm2836-rpi-2-b.dtb
> +       bcm2836-rpi-2-b.dtb \
> +       ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb
>  dtb-$(CONFIG_ARCH_BCM_5301X) += \
>         bcm4708-asus-rt-ac56u.dtb \
>         bcm4708-asus-rt-ac68u.dtb \

Let's make this hunk a separate patch so we can discuss it on its
own. I'm not really happy about the way it looks (in general, using ../../../
anywhere in the kernel looks hacky.

How about a separate

dtb-$(CONFIG_ARCH_BCM2835) +=
	../../../arm64/boot/dts/broadcom/

so at least we don't have to add each board on its own?

	Arnd

Re: [PATCH v2 7/9] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

[Gerd Hoffmann]

On Fr, 2016-06-03 at 09:38 +0200, Arnd Bergmann wrote:
> On Friday, June 3, 2016 8:18:26 AM CEST Gerd Hoffmann wrote:
> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > index 06b6c2d..71e2d36 100644
> > --- a/arch/arm/boot/dts/Makefile
> > +++ b/arch/arm/boot/dts/Makefile
> > @@ -66,7 +66,8 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
> >         bcm2835-rpi-b-rev2.dtb \
> >         bcm2835-rpi-b-plus.dtb \
> >         bcm2835-rpi-a-plus.dtb \
> > -       bcm2836-rpi-2-b.dtb
> > +       bcm2836-rpi-2-b.dtb \
> > +       ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb
> >  dtb-$(CONFIG_ARCH_BCM_5301X) += \
> >         bcm4708-asus-rt-ac56u.dtb \
> >         bcm4708-asus-rt-ac68u.dtb \
> 
> Let's make this hunk a separate patch so we can discuss it on its
> own.

Hmm, I through we where in agreement to do it this way ...

> I'm not really happy about the way it looks (in general, using ../../../
> anywhere in the kernel looks hacky.
> 
> How about a separate
> 
> dtb-$(CONFIG_ARCH_BCM2835) +=
> 	../../../arm64/boot/dts/broadcom/

Not working.

Tried "subdir-$(CONFIG_ARCH_BCM) += ...".  Didn't work either.
Same for "dts-dirs += ...".

Running out of ideas.  Guess I have to leave this to someone who knows
kbuild better than me.

cheers,
  Gerd

Re: [PATCH v2 7/9] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

[Arnd Bergmann]

On Friday, June 3, 2016 10:45:46 AM CEST Gerd Hoffmann wrote:
> On Fr, 2016-06-03 at 09:38 +0200, Arnd Bergmann wrote:
> > On Friday, June 3, 2016 8:18:26 AM CEST Gerd Hoffmann wrote:
> > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> > > index 06b6c2d..71e2d36 100644
> > > --- a/arch/arm/boot/dts/Makefile
> > > +++ b/arch/arm/boot/dts/Makefile
> > > @@ -66,7 +66,8 @@ dtb-$(CONFIG_ARCH_BCM2835) += \
> > >         bcm2835-rpi-b-rev2.dtb \
> > >         bcm2835-rpi-b-plus.dtb \
> > >         bcm2835-rpi-a-plus.dtb \
> > > -       bcm2836-rpi-2-b.dtb
> > > +       bcm2836-rpi-2-b.dtb \
> > > +       ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb
> > >  dtb-$(CONFIG_ARCH_BCM_5301X) += \
> > >         bcm4708-asus-rt-ac56u.dtb \
> > >         bcm4708-asus-rt-ac68u.dtb \
> > 
> > Let's make this hunk a separate patch so we can discuss it on its
> > own.
> 
> Hmm, I through we where in agreement to do it this way ...

I think it's ok in principle, this is about the specific syntax.

> > I'm not really happy about the way it looks (in general, using ../../../
> > anywhere in the kernel looks hacky.
> > 
> > How about a separate
> > 
> > dtb-$(CONFIG_ARCH_BCM2835) +=
> >       ../../../arm64/boot/dts/broadcom/
> 
> Not working.
> 
> Tried "subdir-$(CONFIG_ARCH_BCM) += ...".  Didn't work either.
> Same for "dts-dirs += ...".
> 
> Running out of ideas.  Guess I have to leave this to someone who knows
> kbuild better than me.

I tried

subdir-y += ../../../arm64/boot/dts/broadcom

and it seemed to work fine, I got

  DTC     arch/arm/boot/dts/../../../arm64/boot/dts/broadcom/ns2-svk.dtb

in an allmodconfig build, which also includes CONFIG_ARCH_BCM_IPROC.

	Arnd

Re: [PATCH v2 7/9] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

[Gerd Hoffmann]

  Hi,

> I tried
> 
> subdir-y += ../../../arm64/boot/dts/broadcom

Hmm, works for me too now, probably had a typo somewhere.

But it works for "make dtbs" only, "make dtbs_install" ignores it.

cheers,
  Gerd

Re: [PATCH v2 7/9] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

[Arnd Bergmann]

On Friday, June 3, 2016 12:39:15 PM CEST Gerd Hoffmann wrote:
>   Hi,
> 
> > I tried
> > 
> > subdir-y += ../../../arm64/boot/dts/broadcom
> 
> Hmm, works for me too now, probably had a typo somewhere.
> 
> But it works for "make dtbs" only, "make dtbs_install" ignores it.

Right: this is no good ;-)

make -f /git/arm-soc/scripts/Makefile.dtbinst obj=arch/arm/boot/dts/../../../arm64/boot/dts/broadcom
  mkdir -p /tmp/boot//dtbs/4.7.0-rc1-00345-gd2a060ee0c24-dirty/../../../arm64/boot/dts/broadcom; cp arch/arm/boot/dts/../../../arm64/boot/dts/broadcom/ns2-svk.dtb /tmp/boot//dtbs/4.7.0-rc1-00345-gd2a060ee0c24-dirty/../../../arm64/boot/dts/broadcom

Maybe we can have a symlink there? I've tried that without success too,
but it shouldn't be that hard to get right.

	Arnd

Re: [PATCH v2 7/9] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

[Rob Herring]

On Fri, Jun 3, 2016 at 5:39 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
>   Hi,
>
>> I tried
>>
>> subdir-y += ../../../arm64/boot/dts/broadcom
>
> Hmm, works for me too now, probably had a typo somewhere.

What directory does the dtb end up in? Because as it was, it ended up
in arch/arm64/boot/dts/broadcom. I'm not sure all this hackery is
worth it if the dtb doesn't end up in arch/arm/boot/dts/.

> But it works for "make dtbs" only, "make dtbs_install" ignores it.

That will be fun for users to debug...

Rob

Re: [PATCH v2 7/9] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

[Arnd Bergmann]

On Friday, June 3, 2016 11:17:51 AM CEST Rob Herring wrote:
> On Fri, Jun 3, 2016 at 5:39 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >   Hi,
> >
> >> I tried
> >>
> >> subdir-y += ../../../arm64/boot/dts/broadcom
> >
> > Hmm, works for me too now, probably had a typo somewhere.
> 
> What directory does the dtb end up in? Because as it was, it ended up
> in arch/arm64/boot/dts/broadcom. I'm not sure all this hackery is
> worth it if the dtb doesn't end up in arch/arm/boot/dts/.

I think having the dtb in $(objdir)arch/arm64/boot/dts/broadcom is fine, however
installing the  'make dtbs_install' rule copy it to
/boot/dts/../../../arm64/boot/dts/broadcom is not.

	Arnd

Re: [PATCH v2 7/9] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

[Gerd Hoffmann]

On Fr, 2016-06-03 at 11:17 -0500, Rob Herring wrote:
> On Fri, Jun 3, 2016 at 5:39 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> >   Hi,
> >
> >> I tried
> >>
> >> subdir-y += ../../../arm64/boot/dts/broadcom
> >
> > Hmm, works for me too now, probably had a typo somewhere.
> 
> What directory does the dtb end up in? Because as it was, it ended up
> in arch/arm64/boot/dts/broadcom. I'm not sure all this hackery is
> worth it if the dtb doesn't end up in arch/arm/boot/dts/.

With the 2/7 patch at the start of this subthread the dtb ends up in
arch/arm64/boot/dts/broadcom for both arm and arm64 builds.

make "dtbs_install" places it in /boot/dtbs/$version/ for arm builds and
in /boot/dtbs/$version/broadcom/ for arm64 builds.

cheers,
  Gerd

Re: [PATCH v2 7/9] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

[Arnd Bergmann]

On Monday, June 6, 2016 9:20:12 AM CEST Gerd Hoffmann wrote:
> On Fr, 2016-06-03 at 11:17 -0500, Rob Herring wrote:
> > On Fri, Jun 3, 2016 at 5:39 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> > >   Hi,
> > >
> > >> I tried
> > >>
> > >> subdir-y += ../../../arm64/boot/dts/broadcom
> > >
> > > Hmm, works for me too now, probably had a typo somewhere.
> > 
> > What directory does the dtb end up in? Because as it was, it ended up
> > in arch/arm64/boot/dts/broadcom. I'm not sure all this hackery is
> > worth it if the dtb doesn't end up in arch/arm/boot/dts/.
> 
> With the 2/7 patch at the start of this subthread the dtb ends up in
> arch/arm64/boot/dts/broadcom for both arm and arm64 builds.
> 
> make "dtbs_install" places it in /boot/dtbs/$version/ for arm builds and
> in /boot/dtbs/$version/broadcom/ for arm64 builds.

Ok, let's stay with that for now then, and solve it better when we
need to do more of the same. Are you aware of any other boards using
bcm2837?

	Arnd

Re: [PATCH v2 7/9] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

[Gerd Hoffmann]

  Hi,

> > With the 2/7 patch at the start of this subthread the dtb ends up in
> > arch/arm64/boot/dts/broadcom for both arm and arm64 builds.
> > 
> > make "dtbs_install" places it in /boot/dtbs/$version/ for arm builds and
> > in /boot/dtbs/$version/broadcom/ for arm64 builds.
> 
> Ok, let's stay with that for now then, and solve it better when we
> need to do more of the same. Are you aware of any other boards using
> bcm2837?

No.

As far I know it has been created specifically for the rpi foundation,
so I expect we might see new members of the rpi family using the bcm2837
too, but probably no other devices.

Maybe Eric Anholt knows more details.

cheers,
  Gerd

Re: [PATCH v2 7/9] ARM: bcm2835: Add devicetree for the Raspberry Pi 3.

[Stefan Wahren]

Hi,

Am 03.06.2016 um 08:18 schrieb Gerd Hoffmann:
> From: Eric Anholt <eric@anholt.net>
>
> While this devicetree also works for booting in 32-bit mode, it's
> placed in arm64 since it's a 64-bit CPU (as suggested by Arnd).

i'm currently working on a patch series to fix dtc warnings like

Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name

This a copy of affected parts ( look at memory, soc and local_intc node ).

So how should this be handled?

a) fix the issues here
b) extend my patch series after this patch has been applied

Stefan

[PATCH v2 8/9] ARM: bcm2835: dt: Add the ethernet to the device trees

[Gerd Hoffmann]

From: Lubomir Rintel <lkundrak@v3.sk>

The hub and the ethernet in its port 1 are hardwired on the board.

Compared to the adapters that can be plugged into the USB ports, this
one has no serial EEPROM to store its MAC. Nevertheless, the Raspberry Pi
has the MAC address for this adapter in its ROM, accessible from its
firmware.

U-Boot can read out the address and set the local-mac-address property of the
node with "ethernet" alias. Let's add the node so that U-Boot can do its
business.

Model B rev2 and Model B+ entries were verified by me, the hierarchy and
pid/vid pair for the Version 2 was provided by Peter Chen. Original
Model B is a blind shot, though very likely correct.

Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
---
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts    |  1 +
 arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts    |  1 +
 arch/arm/boot/dts/bcm2835-rpi-b.dts         |  1 +
 arch/arm/boot/dts/bcm2836-rpi-2-b.dts       |  1 +
 arch/arm/boot/dts/bcm283x-rpi-smsc9512.dtsi | 19 +++++++++++++++++++
 arch/arm/boot/dts/bcm283x-rpi-smsc9514.dtsi | 19 +++++++++++++++++++
 arch/arm/boot/dts/bcm283x.dtsi              |  2 ++
 7 files changed, 44 insertions(+)
 create mode 100644 arch/arm/boot/dts/bcm283x-rpi-smsc9512.dtsi
 create mode 100644 arch/arm/boot/dts/bcm283x-rpi-smsc9514.dtsi

diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index 57d313b..d5fdb8e 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -1,6 +1,7 @@
 /dts-v1/;
 #include "bcm2835.dtsi"
 #include "bcm2835-rpi.dtsi"
+#include "bcm283x-rpi-smsc9514.dtsi"
 
 / {
 	compatible = "raspberrypi,model-b-plus", "brcm,bcm2835";
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
index cf2774e..bfc4bd9 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts
@@ -1,6 +1,7 @@
 /dts-v1/;
 #include "bcm2835.dtsi"
 #include "bcm2835-rpi.dtsi"
+#include "bcm283x-rpi-smsc9512.dtsi"
 
 / {
 	compatible = "raspberrypi,model-b-rev2", "brcm,bcm2835";
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index 8b15f9c..0371bb7 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -1,6 +1,7 @@
 /dts-v1/;
 #include "bcm2835.dtsi"
 #include "bcm2835-rpi.dtsi"
+#include "bcm283x-rpi-smsc9512.dtsi"
 
 / {
 	compatible = "raspberrypi,model-b", "brcm,bcm2835";
diff --git a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
index c4743f4..29e1cfe 100644
--- a/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
+++ b/arch/arm/boot/dts/bcm2836-rpi-2-b.dts
@@ -1,6 +1,7 @@
 /dts-v1/;
 #include "bcm2836.dtsi"
 #include "bcm2835-rpi.dtsi"
+#include "bcm283x-rpi-smsc9514.dtsi"
 
 / {
 	compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
diff --git a/arch/arm/boot/dts/bcm283x-rpi-smsc9512.dtsi b/arch/arm/boot/dts/bcm283x-rpi-smsc9512.dtsi
new file mode 100644
index 0000000..12c981e
--- /dev/null
+++ b/arch/arm/boot/dts/bcm283x-rpi-smsc9512.dtsi
@@ -0,0 +1,19 @@
+/ {
+	aliases {
+		ethernet = &ethernet;
+	};
+};
+
+&usb {
+	usb1@1 {
+		compatible = "usb424,9512";
+		reg = <1>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethernet: usbether@1 {
+			compatible = "usb424,ec00";
+			reg = <1>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/bcm283x-rpi-smsc9514.dtsi b/arch/arm/boot/dts/bcm283x-rpi-smsc9514.dtsi
new file mode 100644
index 0000000..3f0a56e
--- /dev/null
+++ b/arch/arm/boot/dts/bcm283x-rpi-smsc9514.dtsi
@@ -0,0 +1,19 @@
+/ {
+	aliases {
+		ethernet = &ethernet;
+	};
+};
+
+&usb {
+	usb1@1 {
+		compatible = "usb424,9514";
+		reg = <1>;
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		ethernet: usbether@1 {
+			compatible = "usb424,ec00";
+			reg = <1>;
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 10b27b9..b982522 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -287,6 +287,8 @@
 			compatible = "brcm,bcm2835-usb";
 			reg = <0x7e980000 0x10000>;
 			interrupts = <1 9>;
+			#address-cells = <1>;
+			#size-cells = <0>;
 		};
 
 		v3d: v3d@7ec00000 {
-- 
1.8.3.1

[PATCH v2 9/9] ARM: bcm2837: dt: Add the ethernet to the device trees

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
index 223793d..6f47dd2 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
@@ -1,6 +1,7 @@
 /dts-v1/;
 #include "bcm2837.dtsi"
 #include "../../../../arm/boot/dts/bcm2835-rpi.dtsi"
+#include "../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi"
 
 / {
 	compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
-- 
1.8.3.1