[PATCH 0/3] ARM: brcmstb: Kconfig change and updates

[PATCH 0/3] ARM: brcmstb: Kconfig change and updates

[Florian Fainelli]

This patch series contains updates to arch/arm/mach-bcm/Kconfig to enable
a couple of missing options required by the BRCMSTB SoCs.

The last patch updates the earlyprintk debug stub with a new chip: 7260.

Al Cooper (1):
  ARM: brcmstb: Enable ZONE_DMA for non 64-bit capable peripherals

Danesh Petigara (1):
  ARM: brcmstb: Enable ARCH_HAS_HOLES_MEMORYMODEL

Florian Fainelli (1):
  ARM: brcmstb: Add entry for 7260

 arch/arm/include/debug/brcmstb.S | 18 ++++++++++--------
 arch/arm/mach-bcm/Kconfig        |  2 ++
 2 files changed, 12 insertions(+), 8 deletions(-)

-- 
2.9.3

[PATCH 1/3] ARM: brcmstb: Enable ZONE_DMA for non 64-bit capable peripherals

[Florian Fainelli]

From: Al Cooper <alcooperx@gmail.com>

Some Host Controller hardware blocks, like the OHCI, EHCI and SDIO
controllers, have hardware blocks that are not capable of doing 64 bit
DMA. These host controllers fail on boards with >3GB of memory because
the memory above 3GB is located physically >= 0x100000000 and can only
be accessed using 64 DMA. The way Linux is currently configured for
BRCMSTB systems, the memory given to drivers for DMA through functions
like dma_alloc_coherent() comes from CMA memory and CMA memory is taken
from the top of physical memory. When these drivers get a DMA buffer
with an address >=0x100000000, they end up dropping the upper 32 bit of
the address causing the hardware to DMA to incorrect memory, typically
BMEM (custom memory carveout). This issue was discovered on a
BCM97449SSV_DDR4 system with 4GB or memory.

The fix is to enable CONFIG_ZONE_DMA. On ARM systems this makes sure
that all DMA memory is located within the first 32 bits of address
space.

Signed-off-by: Al Cooper <alcooperx@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/mach-bcm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index a0e66d8200c5..403db76e3497 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -199,6 +199,7 @@ config ARCH_BRCMSTB
 	select BRCMSTB_L2_IRQ
 	select BCM7120_L2_IRQ
 	select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
+	select ZONE_DMA if ARM_LPAE
 	select SOC_BRCMSTB
 	select SOC_BUS
 	help
-- 
2.9.3

[PATCH 1/3] ARM: brcmstb: Enable ZONE_DMA for non 64-bit

[Florian Fainelli]

On Thu, 9 Mar 2017 10:51:18 -0800, Florian Fainelli <f.fainelli@gmail.com> wrote:
> From: Al Cooper <alcooperx@gmail.com>
>
> Some Host Controller hardware blocks, like the OHCI, EHCI and SDIO
> controllers, have hardware blocks that are not capable of doing 64 bit
> DMA. These host controllers fail on boards with >3GB of memory because
> the memory above 3GB is located physically >= 0x100000000 and can only
> be accessed using 64 DMA. The way Linux is currently configured for
> BRCMSTB systems, the memory given to drivers for DMA through functions
> like dma_alloc_coherent() comes from CMA memory and CMA memory is taken
> from the top of physical memory. When these drivers get a DMA buffer
> with an address >=0x100000000, they end up dropping the upper 32 bit of
> the address causing the hardware to DMA to incorrect memory, typically
> BMEM (custom memory carveout). This issue was discovered on a
> BCM97449SSV_DDR4 system with 4GB or memory.
>
> The fix is to enable CONFIG_ZONE_DMA. On ARM systems this makes sure
> that all DMA memory is located within the first 32 bits of address
> space.
>
> Signed-off-by: Al Cooper <alcooperx@gmail.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---

Applied, thanks!
--
Florian

[PATCH 2/3] ARM: brcmstb: Enable ARCH_HAS_HOLES_MEMORYMODEL

[Florian Fainelli]

From: Danesh Petigara <danesh.petigara@broadcom.com>

Due to the brcmstb SoC's memory map, we may have holes in the memory if
we don't populate the maximum amount of memory supported by e.g: the
first memory controller which spans either the first 1GiB or first 2GiB
of memory.

We need to select ARCH_HAS_HOLES_MEMORYMODEL in order to enable
CONFIG_HAVE_ARCH_PFN_VALID on platforms that have CONFIG_SPARSEMEM
enabled.

Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
[florian: Detailed commit message]
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/mach-bcm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index 403db76e3497..f9389c5910e7 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -198,6 +198,7 @@ config ARCH_BRCMSTB
 	select HAVE_ARM_ARCH_TIMER
 	select BRCMSTB_L2_IRQ
 	select BCM7120_L2_IRQ
+	select ARCH_HAS_HOLES_MEMORYMODEL
 	select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
 	select ZONE_DMA if ARM_LPAE
 	select SOC_BRCMSTB
-- 
2.9.3

[PATCH 2/3] ARM: brcmstb: Enable ARCH_HAS_HOLES_MEMORYMODEL

[Florian Fainelli]

On Thu, 9 Mar 2017 10:51:19 -0800, Florian Fainelli <f.fainelli@gmail.com> wrote:
> From: Danesh Petigara <danesh.petigara@broadcom.com>
>
> Due to the brcmstb SoC's memory map, we may have holes in the memory if
> we don't populate the maximum amount of memory supported by e.g: the
> first memory controller which spans either the first 1GiB or first 2GiB
> of memory.
>
> We need to select ARCH_HAS_HOLES_MEMORYMODEL in order to enable
> CONFIG_HAVE_ARCH_PFN_VALID on platforms that have CONFIG_SPARSEMEM
> enabled.
>
> Signed-off-by: Danesh Petigara <danesh.petigara@broadcom.com>
> [florian: Detailed commit message]
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---

Applied, thanks!
--
Florian

[PATCH 3/3] ARM: brcmstb: Add entry for 7260

[Florian Fainelli]

BCM7260 has the same UART base address as 7268, order the entries by
ascending chip number and alias the 7268 definition to the 7260
definition.

Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
 arch/arm/include/debug/brcmstb.S | 18 ++++++++++--------
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/arm/include/debug/brcmstb.S b/arch/arm/include/debug/brcmstb.S
index 9113d7b33ae0..52aaed2b936f 100644
--- a/arch/arm/include/debug/brcmstb.S
+++ b/arch/arm/include/debug/brcmstb.S
@@ -22,7 +22,8 @@
 
 #define UARTA_3390		REG_PHYS_ADDR(0x40a900)
 #define UARTA_7250		REG_PHYS_ADDR(0x40b400)
-#define UARTA_7268		REG_PHYS_ADDR(0x40c000)
+#define UARTA_7260		REG_PHYS_ADDR(0x40c000)
+#define UARTA_7268		UARTA_7260
 #define UARTA_7271		UARTA_7268
 #define UARTA_7364		REG_PHYS_ADDR(0x40b000)
 #define UARTA_7366		UARTA_7364
@@ -62,13 +63,14 @@
 		/* Chip specific detection starts here */
 20:		checkuart(\rp, \rv, 0x33900000, 3390)
 21:		checkuart(\rp, \rv, 0x72500000, 7250)
-22:		checkuart(\rp, \rv, 0x72680000, 7268)
-23:		checkuart(\rp, \rv, 0x72710000, 7271)
-24:		checkuart(\rp, \rv, 0x73640000, 7364)
-25:		checkuart(\rp, \rv, 0x73660000, 7366)
-26:		checkuart(\rp, \rv, 0x07437100, 74371)
-27:		checkuart(\rp, \rv, 0x74390000, 7439)
-28:		checkuart(\rp, \rv, 0x74450000, 7445)
+22:		checkuart(\rp, \rv, 0x72600000, 7260)
+23:		checkuart(\rp, \rv, 0x72680000, 7268)
+24:		checkuart(\rp, \rv, 0x72710000, 7271)
+25:		checkuart(\rp, \rv, 0x73640000, 7364)
+26:		checkuart(\rp, \rv, 0x73660000, 7366)
+27:		checkuart(\rp, \rv, 0x07437100, 74371)
+28:		checkuart(\rp, \rv, 0x74390000, 7439)
+29:		checkuart(\rp, \rv, 0x74450000, 7445)
 
 		/* No valid UART found */
 90:		mov	\rp, #0
-- 
2.9.3

[PATCH 3/3] ARM: brcmstb: Add entry for 7260

[Florian Fainelli]

On Thu, 9 Mar 2017 10:51:20 -0800, Florian Fainelli <f.fainelli@gmail.com> wrote:
> BCM7260 has the same UART base address as 7268, order the entries by
> ascending chip number and alias the 7268 definition to the 7260
> definition.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---

Applied, thanks!
--
Florian