[RFC v1 0/5] ARM: Initial support for Marvell Armada 1500

[RFC v1 0/5] ARM: Initial support for Marvell Armada 1500

[Sebastian Hesselbarth]

This is a RFC adding initial support for the Marvell Armada 1500
(88DE3100) found on various consumer devices (Chromecast, GoogleTV).

Actually, it is a two-fold RFC also raising discussions on mach-mvebu
cleanup roadmap to allow other SoCs to hop into it. While mach-mvebu
originally was created to add support for Armada 370/XP and merge
existing Marvell Orion familiy into it, I am not so sure about
Armada 1500 fits that well (the mbus has gone!).

If you are brave enough to try this on any GoogleTV, hit Google for
instructions on how to get a unlocked u-boot and void your warranty :)
The patches are based on v3.11-rc5 directly.

This cover letter and the separate patches have also been Cc'd to the
respective maintainers to clear up some questions before posting a real
patch set.

Sebastian Hesselbarth (5):
  irqchip: add Armada 1500 APB interrupt controller
  ARM: mvebu: add Armada 1500 to defconfig
  ARM: mvebu: add Armada 150 uart to lowlevel debug
  ARM: mvebu: add Armada 1500 and Sony NSZ-GS7 device tree files
  ARM: mvebu: add board init for Armada 1500

 arch/arm/boot/dts/Makefile                     |    3 +-
 arch/arm/boot/dts/armada-1500-sony-nsz-gs7.dts |   29 +++
 arch/arm/boot/dts/armada-1500.dtsi             |  225 ++++++++++++++++++++++++
 arch/arm/configs/mvebu_defconfig               |    1 +
 arch/arm/include/debug/mvebu.S                 |   26 +--
 arch/arm/mach-mvebu/Kconfig                    |   15 ++
 arch/arm/mach-mvebu/Makefile                   |   13 +-
 arch/arm/mach-mvebu/armada-1500.c              |   63 +++++++
 drivers/irqchip/Makefile                       |    1 +
 drivers/irqchip/irq-armada-1500-apb.c          |  108 ++++++++++++
 10 files changed, 467 insertions(+), 17 deletions(-)
 create mode 100644 arch/arm/boot/dts/armada-1500-sony-nsz-gs7.dts
 create mode 100644 arch/arm/boot/dts/armada-1500.dtsi
 create mode 100644 arch/arm/mach-mvebu/armada-1500.c
 create mode 100644 drivers/irqchip/irq-armada-1500-apb.c

---
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: devicetree at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
-- 
1.7.10.4

[RFC v1 3/5] ARM: mvebu: add Armada 150 uart to lowlevel debug

[Jason Cooper]

On Fri, Aug 16, 2013 at 09:41:36PM +0200, Sebastian Hesselbarth wrote:
> This adds UART0 as found on the Armada 1500 to the lowlevel debug of
> mach-mvebu. Unfortunately, default register base addresses for Armada
> 370/XP switched from 0xd000000 to 0xf100000. So, we finally end up
> in three different lowlevel setups:
> 
>  (a) Armada 1500 (possibly also Armada 1000, or MV88DE3xxx in general)
>  (b) Armada 370/XP with new bootloader mapping at 0xf1000000 and
>      the other Orion SoCs (Dove, Kirkwood, Orion5x, MV78xx0)
>  (c) Armada 370/XP with old bootloader mapping at 0xd0000000
> 
> Now, mach-mvebu has been a Armada 370/XP-only playground for a while
> but with great work of Thomas, Gregory, and the others we have moved
> almost all drivers to DT. I suggest to clean-up a little and find
> some meaningful names for the DEBUG_ Kconfigs.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  arch/arm/include/debug/mvebu.S |   26 ++++++++++++++++----------
>  1 file changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm/include/debug/mvebu.S b/arch/arm/include/debug/mvebu.S
> index 6517311..ca41c02 100644
> --- a/arch/arm/include/debug/mvebu.S
> +++ b/arch/arm/include/debug/mvebu.S
> @@ -11,19 +11,25 @@
>   * published by the Free Software Foundation.
>  */
>  
> -#ifdef CONFIG_DEBUG_MVEBU_UART_ALTERNATE
> -#define ARMADA_370_XP_REGS_PHYS_BASE	0xf1000000
> -#else
> -#define ARMADA_370_XP_REGS_PHYS_BASE	0xd0000000
> +#if defined(CONFIG_MACH_ARMADA_1500)
> +#define MVEBU_REGS_PHYS_BASE	0xf7f80000
> +#define MVEBU_REGS_VIRT_BASE	0xf7f80000
> +#define MVEBU_UART0_OFFSET	0x00049000


> +#elif defined(CONFIG_DEBUG_MVEBU_UART)
> +#define MVEBU_REGS_PHYS_BASE	0xd0000000
> +#define MVEBU_REGS_VIRT_BASE	0xfec00000
> +#define MVEBU_UART0_OFFSET	0x00012000
> +#else /* CONFIG_DEBUG_MVEBU_UART_ALTERNATE */
> +#define MVEBU_REGS_PHYS_BASE	0xf1000000
> +#define MVEBU_REGS_VIRT_BASE	0xfec00000
> +#define MVEBU_UART0_OFFSET	0x00012000
>  #endif

We should preserve the default like so:

+#elif defined(CONFIG_DEBUG_MVEBU_UART_ALTERNATE)
+#define MVEBU_REGS_PHYS_BASE	0xf1000000
+#define MVEBU_REGS_VIRT_BASE	0xfec00000
+#define MVEBU_UART0_OFFSET	0x00012000
+#else /* CONFIG_DEBUG_MVEBU_UART */
+#define MVEBU_REGS_PHYS_BASE	0xd0000000
+#define MVEBU_REGS_VIRT_BASE	0xfec00000
+#define MVEBU_UART0_OFFSET	0x00012000
 #endif

thx,

Jason.

[RFC v1 3/5] ARM: mvebu: add Armada 150 uart to lowlevel debug

[Arnd Bergmann]

On Friday 16 August 2013, Sebastian Hesselbarth wrote:
> 
> -#ifdef CONFIG_DEBUG_MVEBU_UART_ALTERNATE
> -#define ARMADA_370_XP_REGS_PHYS_BASE   0xf1000000
> -#else
> -#define ARMADA_370_XP_REGS_PHYS_BASE   0xd0000000
> +#if defined(CONFIG_MACH_ARMADA_1500)
> +#define MVEBU_REGS_PHYS_BASE   0xf7f80000
> +#define MVEBU_REGS_VIRT_BASE   0xf7f80000
> +#define MVEBU_UART0_OFFSET     0x00049000
> +#elif defined(CONFIG_DEBUG_MVEBU_UART)
> +#define MVEBU_REGS_PHYS_BASE   0xd0000000
> +#define MVEBU_REGS_VIRT_BASE   0xfec00000
> +#define MVEBU_UART0_OFFSET     0x00012000
> +#else /* CONFIG_DEBUG_MVEBU_UART_ALTERNATE */

It seems wrong to base this on CONFIG_MACH_ARMADA_1500. I think you need to
add a new config option just like we have for all other platforms. The above
makes it impossible to build a multiplatform kernel and select 
CONFIG_DEBUG_MVEBU_UART for debugging while keeping CONFIG_MACH_ARMADA_1500
enabled.

	Arnd

[RFC v1 1/5] irqchip: add Armada 1500 APB interrupt controller

[Sebastian Hesselbarth]

On 08/16/2013 09:41 PM, Sebastian Hesselbarth wrote:
> This adds irqchip drivers for the secondary interrupt controllers found
> on Armada 1500 APB and SYSMGT APB bus.
>
> I tried to find a compatible irqchip driver within v3.11-rc5, but there
> is no. I guess that it is a common IP core to buy for your SoC, so maybe
> one of the maintainers knows a better name for it. Could be DesignWare
> type-of as timers are DW, too.

 From a quick look into Synopsys DW ip library, it probably matches 
dw_apb_ictl best and should be named accordingly. Next round will
name the source dw_apb_ictl.c and corresponding compatible
"snps,dw-apb-ictl".

In addition, it looks like the ip can support up to 64 irqs. For orion
irq, I have used a "mavell,#interrupts" to allow to pass the number of
supported irqs. Above driver should also exploit a similar
snps-prefixed property.

Sebastian

[RFC v1 5/5] ARM: mvebu: add board init for Armada 1500

[Jason Cooper]

On Fri, Aug 16, 2013 at 09:41:38PM +0200, Sebastian Hesselbarth wrote:
> This adds initial setup for the Marvell Armada 1500 SoCs. The code
> is fairly straight-forward, but especially _timer_and_clk_init()
> can be simplified by using default arch hooks. I will have some time
> until mach-mvebu is prepared for other SoCs moving over, so I can
> catch up with latest machine simplifications.
> 
> I am not so sure about the .map_io but I didn't yet fully understand
> the mapping requirement. Anyway, it is required for iomap and friends
> to work and basically remaps physical register addressed onto the same
> virtual addresses.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  arch/arm/mach-mvebu/Kconfig       |   15 +++++++++
>  arch/arm/mach-mvebu/Makefile      |   13 ++++----
>  arch/arm/mach-mvebu/armada-1500.c |   63 +++++++++++++++++++++++++++++++++++++
>  3 files changed, 85 insertions(+), 6 deletions(-)
>  create mode 100644 arch/arm/mach-mvebu/armada-1500.c
> 
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index 9eb63d7..e2e93ed 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -36,6 +36,21 @@ config MACH_ARMADA_370
>  	  Say 'Y' here if you want your kernel to support boards based
>  	  on the Marvell Armada 370 SoC with device tree.
>  
> +config MACH_ARMADA_1500
> +	bool "Marvell Armada 1500 boards"
> +	select ARMADA_1500_CLK
> +	select ARM_GIC

nit, alpha.

> +	select CACHE_L2X0
> +	select CPU_PJ4B
> +	select DW_APB_TIMER_OF

> +	select LOCAL_TIMERS if SMP
> +	select HAVE_ARM_TWD if LOCAL_TIMERS

alpha.

> +	select HAVE_SMP
> +	select PINCTRL_ARMADA_1500
> +	help
> +	  Say 'Y' here if you want your kernel to support boards based
> +	  on the Marvell Armada 1500 SoC with device tree.
> +
>  config MACH_ARMADA_XP
>  	bool "Marvell Armada XP boards"
>  	select ARMADA_XP_CLK
> diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
> index 2d04f0e..2e10b4a 100644
> --- a/arch/arm/mach-mvebu/Makefile
> +++ b/arch/arm/mach-mvebu/Makefile
> @@ -1,10 +1,11 @@
>  ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
>  	-I$(srctree)/arch/arm/plat-orion/include
>  
> -AFLAGS_coherency_ll.o		:= -Wa,-march=armv7-a
> +AFLAGS_coherency_ll.o			:= -Wa,-march=armv7-a
>  
> -obj-y				 += system-controller.o
> -obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o
> -obj-$(CONFIG_ARCH_MVEBU)	 += coherency.o coherency_ll.o pmsu.o
> -obj-$(CONFIG_SMP)                += platsmp.o headsmp.o
> -obj-$(CONFIG_HOTPLUG_CPU)        += hotplug.o
> +obj-y					+= system-controller.o
> +obj-$(CONFIG_MACH_ARMADA_370_XP)	+= armada-370-xp.o
> +obj-$(CONFIG_MACH_ARMADA_1500)		+= armada-1500.o

guess what?  :)

I swear I had a more substantive comment when I started this.  But after
a suitable application of gray matter, these nits were all that were
left. :(

thx,

Jason.

> +obj-$(CONFIG_ARCH_MVEBU)		+= coherency.o coherency_ll.o pmsu.o
> +obj-$(CONFIG_SMP)			+= platsmp.o headsmp.o
> +obj-$(CONFIG_HOTPLUG_CPU)		+= hotplug.o
> diff --git a/arch/arm/mach-mvebu/armada-1500.c b/arch/arm/mach-mvebu/armada-1500.c
> new file mode 100644
> index 0000000..b7c556b
> --- /dev/null
> +++ b/arch/arm/mach-mvebu/armada-1500.c
> @@ -0,0 +1,63 @@
> +/*
> + * Device Tree support for Armada 1500 platforms.
> + *
> + * Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> + *
> + * 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 <linux/clk-provider.h>
> +#include <linux/clocksource.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/io.h>
> +#include <linux/of_platform.h>
> +#include <asm/hardware/cache-l2x0.h>
> +#include <asm/mach/arch.h>
> +#include <asm/mach/map.h>
> +#include <asm/mach/time.h>
> +#include "common.h"
> +#include "coherency.h"
> +
> +#define ARMADA_1500_REG_BASE_VIRT	0xf6000000
> +#define ARMADA_1500_REG_BASE_SIZE	0x03000000
> +
> +static struct map_desc armada_1500_io_desc[] __initdata = {
> +	{
> +		.virtual	= ARMADA_1500_REG_BASE_VIRT,
> +		.pfn		= __phys_to_pfn(ARMADA_1500_REG_BASE_VIRT),
> +		.length		= ARMADA_1500_REG_BASE_SIZE,
> +		.type		= MT_DEVICE,
> +	},
> +};
> +
> +static void __init armada_1500_map_io(void)
> +{
> +	iotable_init(armada_1500_io_desc, ARRAY_SIZE(armada_1500_io_desc));
> +}
> +
> +static void __init armada_1500_timer_and_clk_init(void)
> +{
> +	of_clk_init(NULL);
> +	clocksource_of_init();
> +}
> +
> +static void __init armada_1500_dt_init(void)
> +{
> +	l2x0_of_init(0x70c00000, 0xfeffffff);
> +	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
> +}
> +
> +static const char * const armada_1500_dt_compat[] = {
> +	"marvell,armada-1500",
> +	NULL,
> +};
> +
> +DT_MACHINE_START(ARMADA_1500_DT, "Marvell Armada 1500")
> +	.init_machine	= armada_1500_dt_init,
> +	.map_io		= armada_1500_map_io,
> +	.init_time	= armada_1500_timer_and_clk_init,
> +	.dt_compat	= armada_1500_dt_compat,
> +MACHINE_END
> -- 
> 1.7.10.4
> 

[RFC v1 5/5] ARM: mvebu: add board init for Armada 1500

[Sebastian Hesselbarth]

On 08/16/2013 10:48 PM, Jason Cooper wrote:
> On Fri, Aug 16, 2013 at 09:41:38PM +0200, Sebastian Hesselbarth wrote:
>> This adds initial setup for the Marvell Armada 1500 SoCs. The code
>> is fairly straight-forward, but especially _timer_and_clk_init()
>> can be simplified by using default arch hooks. I will have some time
>> until mach-mvebu is prepared for other SoCs moving over, so I can
>> catch up with latest machine simplifications.
>>
>> I am not so sure about the .map_io but I didn't yet fully understand
>> the mapping requirement. Anyway, it is required for iomap and friends
>> to work and basically remaps physical register addressed onto the same
>> virtual addresses.
>>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>> ---
[...]
>> +obj-$(CONFIG_MACH_ARMADA_1500)		+= armada-1500.o
>
> guess what?  :)
>
> I swear I had a more substantive comment when I started this.  But after
> a suitable application of gray matter, these nits were all that were
> left. :(

Jason,

thanks for teaching me the alphabet again :) Of course, all your 
comments will be fixed for a real patch set.

I hope Thomas and Gregory will have some time to comment on the
mach-mvebu integration soon which also affects Orion SoCs.

But its weekend, next merge window is far, above just fails to boot
into anything useful due to the lack of drivers - relax :)

Sebastian

[RFC v1 5/5] ARM: mvebu: add board init for Armada 1500

[Arnd Bergmann]

On Friday 16 August 2013, Jason Cooper wrote:
> > +
> > +#define ARMADA_1500_REG_BASE_VIRT	0xf6000000
> > +#define ARMADA_1500_REG_BASE_SIZE	0x03000000
> > +
> > +static struct map_desc armada_1500_io_desc[] __initdata = {
> > +	{
> > +		.virtual	= ARMADA_1500_REG_BASE_VIRT,
> > +		.pfn		= __phys_to_pfn(ARMADA_1500_REG_BASE_VIRT),
> > +		.length		= ARMADA_1500_REG_BASE_SIZE,
> > +		.type		= MT_DEVICE,
> > +	},
> > +};

You should really try to find out what driver uses this. If you have a requirement
that VIRT == PHYS here, the most likely explanation is that some driver accidentally
uses readl/writel on the physical address rather than on the result of ioremap.

You can try shrinking the area using bisection until you have found the offending
driver based on the address.

> > +static void __init armada_1500_timer_and_clk_init(void)
> > +{
> > +	of_clk_init(NULL);
> > +	clocksource_of_init();
> > +}
> > +
> > +static void __init armada_1500_dt_init(void)
> > +{
> > +	l2x0_of_init(0x70c00000, 0xfeffffff);

New platforms should call this as 'l2x0_of_init(0, 0);' and get the bits from DT.

Note that we should really change the common code to do both the of_clk_init()
and the l2x0_of_init() automatically, but that needs to be done with some care,
in order to not break any of the existing platforms. Would you be able to do
one of the two? We can then get the next person that wants to add a platform
to do the last one ;-)

	Arnd

[RFC v1 5/5] ARM: mvebu: add board init for Armada 1500

[Arnd Bergmann]

On Saturday 17 August 2013, Arnd Bergmann wrote:
> On Friday 16 August 2013, Jason Cooper wrote:
> > > +

> 
> You should really try to find out what driver uses this. If you have a requirement
> that VIRT == PHYS here, the most likely explanation is that some driver accidentally
> uses readl/writel on the physical address rather than on the result of ioremap.
> 
> You can try shrinking the area using bisection until you have found the offending
> driver based on the address.
> 

> > > +static void __init armada_1500_timer_and_clk_init(void)
> 
> New platforms should call this as 'l2x0_of_init(0, 0);' and get the bits from DT.
> 
> Note that we should really change the common code to do both the of_clk_init()
> and the l2x0_of_init() automatically, but that needs to be done with some care,
> in order to not break any of the existing platforms. Would you be able to do
> one of the two? We can then get the next person that wants to add a platform
> to do the last one ;-)


I replied to the wrong mail. My comments were obviously meant for Sebastian,
not for Jason.

	Arnd

[RFC v1 5/5] ARM: mvebu: add board init for Armada 1500

[Sebastian Hesselbarth]

On 08/17/2013 09:08 PM, Arnd Bergmann wrote:
> On Friday 16 August 2013, Jason Cooper wrote:
>>> +
>>> +#define ARMADA_1500_REG_BASE_VIRT	0xf6000000
>>> +#define ARMADA_1500_REG_BASE_SIZE	0x03000000
>>> +
>>> +static struct map_desc armada_1500_io_desc[] __initdata = {
>>> +	{
>>> +		.virtual	= ARMADA_1500_REG_BASE_VIRT,
>>> +		.pfn		= __phys_to_pfn(ARMADA_1500_REG_BASE_VIRT),
>>> +		.length		= ARMADA_1500_REG_BASE_SIZE,
>>> +		.type		= MT_DEVICE,
>>> +	},
>>> +};
>
> You should really try to find out what driver uses this. If you have a requirement
> that VIRT == PHYS here, the most likely explanation is that some driver accidentally
> uses readl/writel on the physical address rather than on the result of ioremap.
>
> You can try shrinking the area using bisection until you have found the offending
> driver based on the address.

While bringing up timer and irq, I had no luck without that mapping,
but I didn't try without later on. There is no driver requiring it,
as I either only use mainline drivers that never knew about A1500
before, or I have written it on my own (dw-apb-ictl).

I don't think it is required and will try to remove it, now that I
know I have set up core stuff correctly and it boots.

>>> +static void __init armada_1500_timer_and_clk_init(void)
>>> +{
>>> +	of_clk_init(NULL);
>>> +	clocksource_of_init();
>>> +}
>>> +
>>> +static void __init armada_1500_dt_init(void)
>>> +{
>>> +	l2x0_of_init(0x70c00000, 0xfeffffff);
>
> New platforms should call this as 'l2x0_of_init(0, 0);' and get the bits from DT.

Ok.

> Note that we should really change the common code to do both the of_clk_init()
> and the l2x0_of_init() automatically, but that needs to be done with some care,
> in order to not break any of the existing platforms. Would you be able to do
> one of the two? We can then get the next person that wants to add a platform
> to do the last one ;-)

Scary but that reduces armada-1500.c to MACH descriptor and DT
compatible only ;) I don't expect any weird hacks required for
it anyway.

Sebastian

[RFC v1 5/5] ARM: mvebu: add board init for Armada 1500

[Arnd Bergmann]

On Monday 19 August 2013, Sebastian Hesselbarth wrote:
> > Note that we should really change the common code to do both the of_clk_init()
> > and the l2x0_of_init() automatically, but that needs to be done with some care,
> > in order to not break any of the existing platforms. Would you be able to do
> > one of the two? We can then get the next person that wants to add a platform
> > to do the last one ;-)
> 
> Scary but that reduces armada-1500.c to MACH descriptor and DT
> compatible only ;) I don't expect any weird hacks required for
> it anyway.

You will need the .smp_ops pointer once you add SMP support. Other than that,
if your machine descriptor only has the pointer to the compatible strings,
you can actually build without a machine descriptor (as we do on arm64).
The string is used only in /proc/cpuinfo then.

	Arnd

[RFC v1 5/5] ARM: mvebu: add board init for Armada 1500

[Sebastian Hesselbarth]

On 08/17/13 21:08, Arnd Bergmann wrote:
> On Friday 16 August 2013, Jason Cooper wrote:
>>> +
>>> +#define ARMADA_1500_REG_BASE_VIRT	0xf6000000
>>> +#define ARMADA_1500_REG_BASE_SIZE	0x03000000
>>> +
>>> +static struct map_desc armada_1500_io_desc[] __initdata = {
>>> +	{
>>> +		.virtual	= ARMADA_1500_REG_BASE_VIRT,
>>> +		.pfn		= __phys_to_pfn(ARMADA_1500_REG_BASE_VIRT),
>>> +		.length		= ARMADA_1500_REG_BASE_SIZE,
>>> +		.type		= MT_DEVICE,
>>> +	},
>>> +};
>
> You should really try to find out what driver uses this. If you have a requirement
> that VIRT == PHYS here, the most likely explanation is that some driver accidentally
> uses readl/writel on the physical address rather than on the result of ioremap.
>
> You can try shrinking the area using bisection until you have found the offending
> driver based on the address.

I just removed the above and it still works. Must have been a placebo
for me to believe it made it working.

>>> +static void __init armada_1500_timer_and_clk_init(void)
>>> +{
>>> +	of_clk_init(NULL);
>>> +	clocksource_of_init();
>>> +}
>>> +
>>> +static void __init armada_1500_dt_init(void)
>>> +{
>>> +	l2x0_of_init(0x70c00000, 0xfeffffff);
>
> New platforms should call this as 'l2x0_of_init(0, 0);' and get the bits from DT.

Is there any work on "get the bits from DT" already? I looked in
arm-soc/for-next and for-next but couldn't find any parsing of
aux_*.

> Note that we should really change the common code to do both the of_clk_init()
> and the l2x0_of_init() automatically, but that needs to be done with some care,
> in order to not break any of the existing platforms. Would you be able to do
> one of the two? We can then get the next person that wants to add a platform
> to do the last one ;-)

Haven't had a look at cache init, but of_clk_init(NULL). Since most
platforms need clocks prior timer, I guess any initcall is too late?
Below init sequence guessing may be wrong, but that is what I read
from init/main.c and arm arch init.

Looking through arch/ there is arc, arm, arm64, and metag using
of_clk_init(NULL).

arch/arc/plat-tb10x and arch/arm64 call it right before
of_platform_populate which is after time_init() and too late for
us, arch/metag calls it within time_init().

On arch/arm of_clk_init(NULL) is heavily spread among mach- subdirs
with exynos, highbank, imx (all sub-machs), mvebu, nspire, rockchip,
sti, and vexpress calling it in .init_time; tegra calls it even
earlier in .init_irq, socfpga in .init_machine. With latest clocksource
driver for Orion, -dove, -orion5x, and -mv78xx0, will also need clocks
prior timer.

If we are going for an arch/arm specific call to of_clk_init(NULL),
we could also call it from time_init(); after asking the tegra guys
about the specific requirement to have them (and the drivers using
it) ready before timers have been initialized.

For the transition period, we should add a static bool to of_clk_init
to WARN_ON double registration attempts.

I could prepare some patches to convert existing arch/arm users to
get some noise on the corresponding mailing lists. Maybe one of the
tegra guys is also reading this and can comment on .init_irq before.

Sebastian

[RFC v1 5/5] ARM: mvebu: add board init for Armada 1500

[Arnd Bergmann]

On Monday 19 August 2013, Sebastian Hesselbarth wrote:
> On 08/17/13 21:08, Arnd Bergmann wrote:
> > On Friday 16 August 2013, Jason Cooper wrote:
>
> > You should really try to find out what driver uses this. If you have a requirement
> > that VIRT == PHYS here, the most likely explanation is that some driver accidentally
> > uses readl/writel on the physical address rather than on the result of ioremap.
> >
> > You can try shrinking the area using bisection until you have found the offending
> > driver based on the address.
> 
> I just removed the above and it still works. Must have been a placebo
> for me to believe it made it working.

Ah, good.

> >>> +static void __init armada_1500_timer_and_clk_init(void)
> >>> +{
> >>> +	of_clk_init(NULL);
> >>> +	clocksource_of_init();
> >>> +}
> >>> +
> >>> +static void __init armada_1500_dt_init(void)
> >>> +{
> >>> +	l2x0_of_init(0x70c00000, 0xfeffffff);
> >
> > New platforms should call this as 'l2x0_of_init(0, 0);' and get the bits from DT.
> 
> Is there any work on "get the bits from DT" already? I looked in
> arm-soc/for-next and for-next but couldn't find any parsing of
> aux_*.

Have a look at the pl310_of_setup() and aurora_of_setup() functions, they parse
the available properties and edit the mask. You might have to add further properties
in the same way.

> > Note that we should really change the common code to do both the of_clk_init()
> > and the l2x0_of_init() automatically, but that needs to be done with some care,
> > in order to not break any of the existing platforms. Would you be able to do
> > one of the two? We can then get the next person that wants to add a platform
> > to do the last one ;-)
> 
> Haven't had a look at cache init, but of_clk_init(NULL). Since most
> platforms need clocks prior timer, I guess any initcall is too late?

Right.

> Below init sequence guessing may be wrong, but that is what I read
> from init/main.c and arm arch init.
> 
> Looking through arch/ there is arc, arm, arm64, and metag using
> of_clk_init(NULL).
> 
> arch/arc/plat-tb10x and arch/arm64 call it right before
> of_platform_populate which is after time_init() and too late for
> us, arch/metag calls it within time_init().
> 
> On arch/arm of_clk_init(NULL) is heavily spread among mach- subdirs
> with exynos, highbank, imx (all sub-machs), mvebu, nspire, rockchip,
> sti, and vexpress calling it in .init_time; tegra calls it even
> earlier in .init_irq, socfpga in .init_machine. With latest clocksource
> driver for Orion, -dove, -orion5x, and -mv78xx0, will also need clocks
> prior timer.
>
> If we are going for an arch/arm specific call to of_clk_init(NULL),
> we could also call it from time_init(); after asking the tegra guys
> about the specific requirement to have them (and the drivers using
> it) ready before timers have been initialized.
> 
> For the transition period, we should add a static bool to of_clk_init
> to WARN_ON double registration attempts.
> 
> I could prepare some patches to convert existing arch/arm users to
> get some noise on the corresponding mailing lists. Maybe one of the
> tegra guys is also reading this and can comment on .init_irq before.

Sounds good. I think it can easily be done in a way that it's harmless
to call it multiple times with a NULL argument, which would take care
of platforms that might need it to be called earlier.

I've gone over the platforms with Mark Rutland before and we found
four other platforms that need a little work before the conversion
can work:

* arch/arm/mach-highbank/highbank.c needs to map sregs_base before
  calling of_clk_init().

* Similar code in drivers/clk/clk-vt8500.c and drivers/clk/zynq/clkc.c

* arch/arm/mach-imx/clk-imx51-imx53.c has a lot of interdependencies
  with other code.

One could either change those to not depend on a pointer outside of
the driver, which would be the cleaner approach but possibly more
work, or they could be changed back to using a non-NULL argument,
at least as an intermediate step, so calling of_clk_init(NULL) won't
actually initialize these.

	Arnd

[RFC v1 5/5] ARM: mvebu: add board init for Armada 1500

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Fri, 16 Aug 2013 21:41:38 +0200, Sebastian Hesselbarth wrote:

> I am not so sure about the .map_io but I didn't yet fully understand
> the mapping requirement. Anyway, it is required for iomap and friends
> to work and basically remaps physical register addressed onto the same
> virtual addresses.

You should normally be able to completely avoid the ->map_io() hook. If
you leave it set to NULL, it will automatically call
debug_ll_io_init(), which will setup the virt->phys mapping needed by
DEBUG_LL stuff. All the other mappings will be created dynamically with
ioremap().

The static mapping covering all registers is really no longer needed.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[RFC v1 5/5] ARM: mvebu: add board init for Armada 1500

[Arnd Bergmann]

On Friday 16 August 2013, Sebastian Hesselbarth wrote:
> +config MACH_ARMADA_1500
> +       bool "Marvell Armada 1500 boards"
> +       select ARMADA_1500_CLK
> +       select ARM_GIC
> +       select CACHE_L2X0
> +       select CPU_PJ4B
> +       select DW_APB_TIMER_OF
> +       select LOCAL_TIMERS if SMP
> +       select HAVE_ARM_TWD if LOCAL_TIMERS
> +       select HAVE_SMP
> +       select PINCTRL_ARMADA_1500

Hmm, I also noticed that this enables support for both the Cortex-A9
(using GIC and L2X0) and the PJ4 based variants of Armada 1500. I
wonder if we should have separate options for the two. E.g. if you
want to build a kernel for the Chromecast, there would be no need to
enabled PJ4 support.

I have not been able to find out which core is used in most of the
production Google TV boxes.

	Arnd

[RFC v1 5/5] ARM: mvebu: add board init for Armada 1500

[Sebastian Hesselbarth]

On 08/17/2013 09:12 PM, Arnd Bergmann wrote:
> On Friday 16 August 2013, Sebastian Hesselbarth wrote:
>> +config MACH_ARMADA_1500
>> +       bool "Marvell Armada 1500 boards"
>> +       select ARMADA_1500_CLK
>> +       select ARM_GIC
>> +       select CACHE_L2X0
>> +       select CPU_PJ4B
>> +       select DW_APB_TIMER_OF
>> +       select LOCAL_TIMERS if SMP
>> +       select HAVE_ARM_TWD if LOCAL_TIMERS
>> +       select HAVE_SMP
>> +       select PINCTRL_ARMADA_1500
>
> Hmm, I also noticed that this enables support for both the Cortex-A9
> (using GIC and L2X0) and the PJ4 based variants of Armada 1500. I
> wonder if we should have separate options for the two. E.g. if you
> want to build a kernel for the Chromecast, there would be no need to
> enabled PJ4 support.
>
> I have not been able to find out which core is used in most of the
> production Google TV boxes.

AFAIK, there is Armada 1500 (88de3100) used in every Google TV 2nd Gen
devices, some older multimedia boxes also used Armada 1000 (88de3010),
and Chromecast comprises Armada 1500-mini (88de3005).

We should be able to find out if it is PJ4B or Cortex-A9 by checking
any CPU register?

Sebastian

[RFC v1 5/5] ARM: mvebu: add board init for Armada 1500

[Arnd Bergmann]

On Monday 19 August 2013, Sebastian Hesselbarth wrote:
> AFAIK, there is Armada 1500 (88de3100) used in every Google TV 2nd Gen
> devices, some older multimedia boxes also used Armada 1000 (88de3010),
> and Chromecast comprises Armada 1500-mini (88de3005).

According to the chromecast kernel sources (which seem to have all the
gtv stuff in them), they changed the CPU core between minor versons
of the 88de3100:

PJ4 based:

- MV88DE3100_BG2_A0
- MV88DE3100_BG2_A1

Cortex-A5 or Cortex-A9 based:

- MV88DE3100_BG2_CD
- MV88DE3100_BG2_CZ
- MV88DE3100_BG3

Those are Kconfig strings, I don't know how those correspond to
chip identification registers or labels printed on the SoC package.

> We should be able to find out if it is PJ4B or Cortex-A9 by checking
> any CPU register?

/proc/cpuinfo will tell you what core you have, see
http://wiki.casthacks.com/index.php?title=Google_ChromeCast_Specs:

CPU implementer : 0x41     # 0x41 == ARM Ltd
CPU architecture: 7        # 0x07 == ARMv7
CPU variant     : 0x3      # 0x03 == Core revision r3
CPU part        : 0xc09    # 0xc0? == Cortex-A?, 0xc09 == A9
CPU revision    : 0        # 0x00 == minor revision r3p0

On http://forum.gtvhacker.com/star-vap430-f40/topic972.html, I found
this for a PJ4 based 88de3100:

CPU implementer : 0x56
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0x584
CPU revision    : 1

Comparing those to other bits I found on the web, it actually seems to
be a PJ4B rather than the original PJ4.

	Arnd

[RFC v1 4/5] ARM: mvebu: add Armada 1500 and Sony NSZ-GS7 device tree files

[Jason Cooper]

On Fri, Aug 16, 2013 at 09:41:37PM +0200, Sebastian Hesselbarth wrote:
> This adds very basic device tree files for the Marvell Armada 1500 SoC
> and the Sony NSZ-GS7 GoogleTV board. Currently, SoC only has nodes for
> cpus, some clocks, l2 cache controller, local timer, apb timers, uart,
> and interrupt controllers.
> 
> The clocks are fixed-clock placeholders until a real DT clock provider
> is available. Cache controller node may be wrong and was just guessed
> out of Armada 370 and GPL'd 1500 source. Timers except clocksource have
> not really been tested.
> 
> The separation into soc/apb and soc/sm-apb may be removed, but it looks
> like Armada 1500 has a separate peripheral bus for the System Manager
> core that can also been accessed by CPUs. (If you look closely on GTV
> boot logs, you can see SM and CPU fighting for UART ;) )
> 
> The Sony NSZ-GS7 is a GoogleTV consumer device comprising the SoC above.
> Since last week or so, there is a way to install a custom u-boot and
> boot stock, unsigned kernels easily. Just ask Google about it, if you
> are willing to void your warranty.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: devicetree at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  arch/arm/boot/dts/Makefile                     |    3 +-
>  arch/arm/boot/dts/armada-1500-sony-nsz-gs7.dts |   29 +++
>  arch/arm/boot/dts/armada-1500.dtsi             |  225 ++++++++++++++++++++++++
>  3 files changed, 256 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/armada-1500-sony-nsz-gs7.dts
>  create mode 100644 arch/arm/boot/dts/armada-1500.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 641b3c9..3186904 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -103,7 +103,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>  	armada-370-rd.dtb \
>  	armada-xp-db.dtb \
>  	armada-xp-gp.dtb \
> -	armada-xp-openblocks-ax3-4.dtb
> +	armada-xp-openblocks-ax3-4.dtb \
> +	armada-1500-sony-nsz-gs7.dtb

alphabetical.

And now I need to pick up a googleTV... 

thx,

Jason.

[RFC v1 4/5] ARM: mvebu: add Armada 1500 and Sony NSZ-GS7 device tree files

[Sebastian Hesselbarth]

On 08/16/2013 09:50 PM, Jason Cooper wrote:
> On Fri, Aug 16, 2013 at 09:41:37PM +0200, Sebastian Hesselbarth wrote:
>> This adds very basic device tree files for the Marvell Armada 1500 SoC
>> and the Sony NSZ-GS7 GoogleTV board. Currently, SoC only has nodes for
>> cpus, some clocks, l2 cache controller, local timer, apb timers, uart,
>> and interrupt controllers.
[...]
>> ---
>>   arch/arm/boot/dts/Makefile                     |    3 +-
>>   arch/arm/boot/dts/armada-1500-sony-nsz-gs7.dts |   29 +++
>>   arch/arm/boot/dts/armada-1500.dtsi             |  225 ++++++++++++++++++++++++
>>   3 files changed, 256 insertions(+), 1 deletion(-)
>>   create mode 100644 arch/arm/boot/dts/armada-1500-sony-nsz-gs7.dts
>>   create mode 100644 arch/arm/boot/dts/armada-1500.dtsi
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 641b3c9..3186904 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -103,7 +103,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>>   	armada-370-rd.dtb \
>>   	armada-xp-db.dtb \
>>   	armada-xp-gp.dtb \
>> -	armada-xp-openblocks-ax3-4.dtb
>> +	armada-xp-openblocks-ax3-4.dtb \
>> +	armada-1500-sony-nsz-gs7.dtb
>
> alphabetical.

Dammit, true! ;)

> And now I need to pick up a googleTV...

Jep, go shopping :)

Unfortunately, I (again) put too many people in Cc and all 5 patches
are stuck waiting for moderator approval. With 5 DT maintainers it isn't
easy to get those though to MLs.

Sebastian

[RFC v1 4/5] ARM: mvebu: add Armada 1500 and Sony NSZ-GS7 device tree files

[Jason Cooper]

On Fri, Aug 16, 2013 at 09:41:37PM +0200, Sebastian Hesselbarth wrote:
> This adds very basic device tree files for the Marvell Armada 1500 SoC
> and the Sony NSZ-GS7 GoogleTV board. Currently, SoC only has nodes for
> cpus, some clocks, l2 cache controller, local timer, apb timers, uart,
> and interrupt controllers.
> 
> The clocks are fixed-clock placeholders until a real DT clock provider
> is available. Cache controller node may be wrong and was just guessed
> out of Armada 370 and GPL'd 1500 source. Timers except clocksource have
> not really been tested.
> 
> The separation into soc/apb and soc/sm-apb may be removed, but it looks
> like Armada 1500 has a separate peripheral bus for the System Manager
> core that can also been accessed by CPUs. (If you look closely on GTV
> boot logs, you can see SM and CPU fighting for UART ;) )
> 
> The Sony NSZ-GS7 is a GoogleTV consumer device comprising the SoC above.
> Since last week or so, there is a way to install a custom u-boot and
> boot stock, unsigned kernels easily. Just ask Google about it, if you
> are willing to void your warranty.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: devicetree at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  arch/arm/boot/dts/Makefile                     |    3 +-
>  arch/arm/boot/dts/armada-1500-sony-nsz-gs7.dts |   29 +++
>  arch/arm/boot/dts/armada-1500.dtsi             |  225 ++++++++++++++++++++++++
>  3 files changed, 256 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/armada-1500-sony-nsz-gs7.dts
>  create mode 100644 arch/arm/boot/dts/armada-1500.dtsi

Also, binding docs?

thx,

Jason.

[RFC v1 4/5] ARM: mvebu: add Armada 1500 and Sony NSZ-GS7 device tree files

[Arnd Bergmann]

On Friday 16 August 2013, Sebastian Hesselbarth wrote:
> +               cpu at 0 {
> +                       compatible = "marvell,sheeva-v7";
> +                       device_type = "cpu";
> +                       next-level-cache = <&l2>;
> +                       reg = <0>;
> +               };
...
> +               l2: l2-cache-controller at 1ac0000 {
> +                       compatible = "marvell,aurora-outer-cache";
> +                       reg = <0x1ac0000 0x1000>;
> +                       cache-level = <2>;
> +               };
> +
> +               gic: interrupt-controller at 1ad0000 {
> +                       compatible = "arm,cortex-a9-gic";
> +                       reg = <0x1ad1000 0x1000
> +                              0x1ad0100 0x0100>;
> +                       interrupt-controller;
> +                       #interrupt-cells = <3>;
> +               };
> +
> +               local-timer at 1ad0600 {
> +                       compatible = "arm,cortex-a9-twd-timer";
> +                       reg = <0x1ad0600 0x20>;
> +                       interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>;
> +                       clocks = <&cpu0clk>;
> +               };

This seems like a strange combination. I would have expected either PJ4+Aurora+apbtimer
or A9+pl310+localtimer, based on what I found in the chromecast kernel source.
Do you have more information here about what is used on the two variants?

	Arnd

[RFC v1 4/5] ARM: mvebu: add Armada 1500 and Sony NSZ-GS7 device tree files

[Sebastian Hesselbarth]

On 08/17/2013 09:28 PM, Arnd Bergmann wrote:
> On Friday 16 August 2013, Sebastian Hesselbarth wrote:
>> +               cpu at 0 {
>> +                       compatible = "marvell,sheeva-v7";
>> +                       device_type = "cpu";
>> +                       next-level-cache = <&l2>;
>> +                       reg = <0>;
>> +               };
> ...
>> +               l2: l2-cache-controller at 1ac0000 {
>> +                       compatible = "marvell,aurora-outer-cache";
>> +                       reg = <0x1ac0000 0x1000>;
>> +                       cache-level = <2>;
>> +               };
>> +
>> +               gic: interrupt-controller at 1ad0000 {
>> +                       compatible = "arm,cortex-a9-gic";
>> +                       reg = <0x1ad1000 0x1000
>> +                              0x1ad0100 0x0100>;
>> +                       interrupt-controller;
>> +                       #interrupt-cells = <3>;
>> +               };
>> +
>> +               local-timer at 1ad0600 {
>> +                       compatible = "arm,cortex-a9-twd-timer";
>> +                       reg = <0x1ad0600 0x20>;
>> +                       interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>;
>> +                       clocks = <&cpu0clk>;
>> +               };
>
> This seems like a strange combination. I would have expected either PJ4+Aurora+apbtimer
> or A9+pl310+localtimer, based on what I found in the chromecast kernel source.
> Do you have more information here about what is used on the two variants?

I have no clue, what combination it really is. Unfortunately,
Marvell didn't release any open datasheets, of course.

I can only look at GPL'd Asus Cube kernel, I used for getting an idea
of what was required for initial support and reg offsets, irqs and
friends. They bring up twd as localtimer. Also, grep'ing the Cube
kernel sources in mach-mv88de3100 gives hits for CONFIG_PJ4 (note the
missing B), l2x0, smp_twd, apb_timer.

No hits for pl310, A9.

Sebastian

[RFC v1 4/5] ARM: mvebu: add Armada 1500 and Sony NSZ-GS7 device tree files

[Arnd Bergmann]

On Monday 19 August 2013, Sebastian Hesselbarth wrote:
> On 08/17/2013 09:28 PM, Arnd Bergmann wrote:
> > On Friday 16 August 2013, Sebastian Hesselbarth wrote:

> > This seems like a strange combination. I would have expected either PJ4+Aurora+apbtimer
> > or A9+pl310+localtimer, based on what I found in the chromecast kernel source.
> > Do you have more information here about what is used on the two variants?
> 
> I have no clue, what combination it really is. Unfortunately,
> Marvell didn't release any open datasheets, of course.
> 
> I can only look at GPL'd Asus Cube kernel, I used for getting an idea
> of what was required for initial support and reg offsets, irqs and
> friends. They bring up twd as localtimer. Also, grep'ing the Cube
> kernel sources in mach-mv88de3100 gives hits for CONFIG_PJ4 (note the
> missing B), l2x0, smp_twd, apb_timer.
> 
> No hits for pl310, A9.

I found this snippet in Kconfig for the Chromecast:

config ARCH_MV88DE3100_BG2
        bool "BG2 family"
        help
          Support for Marvell BG2 processors, based on the Marvell
          PJ4B CPU and the Marvell TAUROS3 L2 cache controller, or
          the ARM CortexA9 CPU and the ARM PL310 L2 cache controller

config ARCH_MV88DE3100_BG3
        bool "BG3 family"
        help
          Support for Marvell BG3 processors, based on the ARM
          CortexA9MP CPU and the ARM PL310 L2 cache controller


A9 will always work when CPU_V7 is set, it doesn't have a Kconfig option.
When CPU_PJ4 is set, it will work on both. Regarding the other options,
this is what I found from the defconfigs in chromecast:

$ git grep LOCAL_TIMER arch/arm/configs/*mv88*
arch/arm/configs/mv88de3100_ax_android_defconfig:CONFIG_LOCAL_TIMERS=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2:CONFIG_LOCAL_TIMERS=y
arch/arm/configs/mv88de3100_ax_emmc_android_defconfig:CONFIG_LOCAL_TIMERS=y
arch/arm/configs/mv88de3100_ax_linux_defconfig:CONFIG_LOCAL_TIMERS=y

$ git grep CONFIG_SMP= arch/arm/configs/*mv88*
arch/arm/configs/mv88de3100_ax_android_defconfig:CONFIG_SMP=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2:CONFIG_SMP=y
arch/arm/configs/mv88de3100_ax_emmc_android_defconfig:CONFIG_SMP=y
arch/arm/configs/mv88de3100_ax_linux_defconfig:CONFIG_SMP=y

$ git grep CPU_PJ4 arch/arm/configs/*mv88*
arch/arm/configs/eureka_mv88de31xx_defconfig:CONFIG_CPU_PJ4=y
arch/arm/configs/mv88de3100_ax_android_defconfig:CONFIG_CPU_PJ4=y
arch/arm/configs/mv88de3100_ax_bg2a0_rdkdmp_dongle_defconfig:CONFIG_CPU_PJ4=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2:CONFIG_CPU_PJ4=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dmp:CONFIG_CPU_PJ4=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dmp_nol2:CONFIG_CPU_PJ4=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dngle_256:CONFIG_CPU_PJ4=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dngle_nol2:CONFIG_CPU_PJ4=y
arch/arm/configs/mv88de3100_ax_emmc_android_defconfig:CONFIG_CPU_PJ4=y
arch/arm/configs/mv88de3100_ax_linux_defconfig:CONFIG_CPU_PJ4=y

$ git grep CACHE_TAUROS3= arch/arm/configs/*mv88*
arch/arm/configs/eureka_mv88de31xx_defconfig:CONFIG_CACHE_TAUROS3=y
arch/arm/configs/mv88de3100_ax_android_defconfig:CONFIG_CACHE_TAUROS3=y
arch/arm/configs/mv88de3100_ax_bg2a0_rdkdmp_dongle_defconfig:CONFIG_CACHE_TAUROS3=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2:CONFIG_CACHE_TAUROS3=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dmp:CONFIG_CACHE_TAUROS3=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dngle_256:CONFIG_CACHE_TAUROS3=y
arch/arm/configs/mv88de3100_ax_emmc_android_defconfig:CONFIG_CACHE_TAUROS3=y
arch/arm/configs/mv88de3100_ax_linux_defconfig:CONFIG_CACHE_TAUROS3=y

$ git grep CACHE_PL310 arch/arm/configs/*mv88*
arch/arm/configs/eureka_mv88de30xx_defconfig:CONFIG_CACHE_PL310=y

$ git grep L2X arch/arm/configs/*mv88*
arch/arm/configs/eureka_mv88de30xx_defconfig:CONFIG_CACHE_L2X0=y

$ git grep MV88DE3100_BG....= arch/arm/configs/*mv88*
arch/arm/configs/eureka_mv88de30xx_defconfig:CONFIG_MV88DE3100_BG2_CD=y
arch/arm/configs/eureka_mv88de31xx_defconfig:CONFIG_MV88DE3100_BG2_A0=y
arch/arm/configs/mv88de3100_ax_android_defconfig:CONFIG_MV88DE3100_BG2_A0=y
arch/arm/configs/mv88de3100_ax_bg2a0_rdkdmp_dongle_defconfig:CONFIG_MV88DE3100_BG2_A0=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2:CONFIG_MV88DE3100_BG2_A0=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dmp:CONFIG_MV88DE3100_BG2_A0=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dmp_nol2:CONFIG_MV88DE3100_BG2_A0=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dngle_256:CONFIG_MV88DE3100_BG2_A0=y
arch/arm/configs/mv88de3100_ax_defconfig.bg2cd_dngle_nol2:CONFIG_MV88DE3100_BG2_A0=y
arch/arm/configs/mv88de3100_ax_emmc_android_defconfig:CONFIG_MV88DE3100_BG2_A0=y
arch/arm/configs/mv88de3100_ax_linux_defconfig:CONFIG_MV88DE3100_BG2_A0=y

Evidently, the only defconfig that is for Cortex-A9 is eureka_mv88de30xx_defconfig,
which is used on the Chromecast and has version MV88DE3100_BG2_CD (presumably
renamed to product number de3005). LOCAL_TIMER is used exactly on those that have
SMP support here, which makes sense.

	Arnd

[RFC v1 0/5] ARM: Initial support for Marvell Armada 1500

[Arnd Bergmann]

On Friday 16 August 2013, Sebastian Hesselbarth wrote:
> This is a RFC adding initial support for the Marvell Armada 1500
> (88DE3100) found on various consumer devices (Chromecast, GoogleTV).
> 
> Actually, it is a two-fold RFC also raising discussions on mach-mvebu
> cleanup roadmap to allow other SoCs to hop into it. While mach-mvebu
> originally was created to add support for Armada 370/XP and merge
> existing Marvell Orion familiy into it, I am not so sure about
> Armada 1500 fits that well (the mbus has gone!).
> 
> If you are brave enough to try this on any GoogleTV, hit Google for
> instructions on how to get a unlocked u-boot and void your warranty :)
> The patches are based on v3.11-rc5 directly.
> 
> This cover letter and the separate patches have also been Cc'd to the
> respective maintainers to clear up some questions before posting a real
> patch set.

Great stuff!

Regarding the question about the directory, is there going to be any
shared code with the files present in mach-mvebu, e.g. the SMP support
that I assume is planned for a later point?

If there is shared code, it's probably best to have it in here. Otherwise
I don't care either way: We have precedent for fairly unrelated platforms
(ev2+shmobile, or the mach-bcm) being in the same directory for practical
reasons, and you can also create an almost empty directory now as we are
likely going to consolidate all "trivial" platforms in the future. Once
the l2x0 and clock init code as well as the early mapping has been
addressed, there won't be any platform code left.

	Arnd

[RFC v1 0/5] ARM: Initial support for Marvell Armada 1500

[Sebastian Hesselbarth]

On 08/17/2013 09:32 PM, Arnd Bergmann wrote:
> On Friday 16 August 2013, Sebastian Hesselbarth wrote:
>> This is a RFC adding initial support for the Marvell Armada 1500
>> (88DE3100) found on various consumer devices (Chromecast, GoogleTV).
>>
>> Actually, it is a two-fold RFC also raising discussions on mach-mvebu
>> cleanup roadmap to allow other SoCs to hop into it. While mach-mvebu
>> originally was created to add support for Armada 370/XP and merge
>> existing Marvell Orion familiy into it, I am not so sure about
>> Armada 1500 fits that well (the mbus has gone!).
>>
>> If you are brave enough to try this on any GoogleTV, hit Google for
>> instructions on how to get a unlocked u-boot and void your warranty :)
>> The patches are based on v3.11-rc5 directly.
>>
>> This cover letter and the separate patches have also been Cc'd to the
>> respective maintainers to clear up some questions before posting a real
>> patch set.
>
> Great stuff!

Thanks! I thought you'd be interested in this, so I Cc'd you :)

> Regarding the question about the directory, is there going to be any
> shared code with the files present in mach-mvebu, e.g. the SMP support
> that I assume is planned for a later point?

I must admit, I never had a close look at the gory early start-up
internals, so all of this is quite new to me. Of course, I plan to
use both cores and therefore add SMP.

> If there is shared code, it's probably best to have it in here. Otherwise
> I don't care either way: We have precedent for fairly unrelated platforms
> (ev2+shmobile, or the mach-bcm) being in the same directory for practical
> reasons, and you can also create an almost empty directory now as we are
> likely going to consolidate all "trivial" platforms in the future. Once
> the l2x0 and clock init code as well as the early mapping has been
> addressed, there won't be any platform code left.

As Thomas already mentioned, Armada 1500 doesn't fit mach-mvebu exactly
because it's from a different business unit within Marvell. And it is
kind of different from what I expected, most notably register addresses
are really different (see mvebu.S).

We either put it into mach-mvebu and pretend to consolidate Marvell SoCs
in there. Pro would be that it is close to other Armadas there, con is
that Armada is codename for virtually any Marvell SoC lately.

If we want a new mach- directory, I'd suggest either mach-berlin which
looks like some nickname for 88de3xxx SoCs or simply boring
mach-88de3xxx.

Sebastian

[RFC v1 0/5] ARM: Initial support for Marvell Armada 1500

[Arnd Bergmann]

On Monday 19 August 2013, Sebastian Hesselbarth wrote:
> We either put it into mach-mvebu and pretend to consolidate Marvell SoCs
> in there. Pro would be that it is close to other Armadas there, con is
> that Armada is codename for virtually any Marvell SoC lately.
> 
> If we want a new mach- directory, I'd suggest either mach-berlin which
> looks like some nickname for 88de3xxx SoCs or simply boring
> mach-88de3xxx.

As I said, either way is fine with me. If you use a new directory, I'd
suggest using the same mach-mv88de3100 name that Marvell uses, to give
them a "hint" about this when updating their own sources to a newer
version. They might get the idea and actually start using your code ;-)

	Arnd

[RFC v1 0/5] ARM: Initial support for Marvell Armada 1500

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Fri, 16 Aug 2013 21:41:33 +0200, Sebastian Hesselbarth wrote:
> This is a RFC adding initial support for the Marvell Armada 1500
> (88DE3100) found on various consumer devices (Chromecast, GoogleTV).

Nice!

> Actually, it is a two-fold RFC also raising discussions on mach-mvebu
> cleanup roadmap to allow other SoCs to hop into it. While mach-mvebu
> originally was created to add support for Armada 370/XP and merge
> existing Marvell Orion familiy into it, I am not so sure about
> Armada 1500 fits that well (the mbus has gone!).

Technically speaking, the Armada 1500 is not designed by the EBU
division of Marvell (that does the Orion, Kirkwood, Armada 370/XP SOCs),
so having it under mach-mvebu may sound a little bit strange. However,
I don't yet have a clear vision of how much different the platform code
will be, especially since the platform code tends to get smaller and
smaller due to the move of lots of code to drivers/.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[RFC v1 0/5] ARM: Initial support for Marvell Armada 1500

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Fri, 16 Aug 2013 21:41:33 +0200, Sebastian Hesselbarth wrote:
> This is a RFC adding initial support for the Marvell Armada 1500
> (88DE3100) found on various consumer devices (Chromecast, GoogleTV).
> 
> Actually, it is a two-fold RFC also raising discussions on mach-mvebu
> cleanup roadmap to allow other SoCs to hop into it. While mach-mvebu
> originally was created to add support for Armada 370/XP and merge
> existing Marvell Orion familiy into it, I am not so sure about
> Armada 1500 fits that well (the mbus has gone!).

After talking a bit with engineers within Marvell that work on this
SoC, I'm inclined to think that using mach-mvebu for this family of SoC
is not a good idea.

The reasons are:

 * This family of SoC is architecturally completely different from the
   family of Orion SoC: they use completely different hardware blocks
   (i.e none of the plat-orion stuff would apply, and none of the
   Orion device drivers would be useful), they don't use the MBus
   mechanism, etc. They are really a different family of SoC, almost as
   if they were coming from a different SoC company.

 * The SMP and power management code, as well as all the "glue"
   platform code that typically sits in mach-<foo> is going to be
   substantially, if not completely different from the one in
   mach-mvebu. I already believe doing all the "glue" platform code in
   mach-mvebu for all of Kirkwood, Dove, 370/XP, Orion5x and MV78xx0 is
   going to be a challenge, so I'd suggest to not add to this challenge
   a completely separate family of SOCs.

The codename used for those Armada 1500 SOCs is "Berlin", so a name
like mach-berlin, or mach-mvberlin (if we want to keep 'mv' to identify
the founder) seems like a good name.

Also, to help us understand the organization of the family of SOCs, I
asked a few informations to Marvell, and here is what I could collect:

"""
BGxname		CPU core	codename	L2 cache controller	internal name
BG2		PJ4B		Armada1500	Tauros3			MV88DE3100
BG2-CT		Cortex-A9	N/A		PL310			N/A
BG3		Cortex-A15	N/A		CA15 integrated		N/A
"""

As was told that the Armada X or MV88DEx names are not used during
development, and what Marvell is really using are the BGxx names.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[RFC v1 0/5] ARM: Initial support for Marvell Armada 1500

[Sebastian Hesselbarth]

On 08/27/13 16:19, Thomas Petazzoni wrote:
> On Fri, 16 Aug 2013 21:41:33 +0200, Sebastian Hesselbarth wrote:
>> This is a RFC adding initial support for the Marvell Armada 1500
>> (88DE3100) found on various consumer devices (Chromecast, GoogleTV).
>>
>> Actually, it is a two-fold RFC also raising discussions on mach-mvebu
>> cleanup roadmap to allow other SoCs to hop into it. While mach-mvebu
>> originally was created to add support for Armada 370/XP and merge
>> existing Marvell Orion familiy into it, I am not so sure about
>> Armada 1500 fits that well (the mbus has gone!).
>
> After talking a bit with engineers within Marvell that work on this
> SoC, I'm inclined to think that using mach-mvebu for this family of SoC
> is not a good idea.

Thomas,

thanks for the info below. Reading a little bit through the GPL'ed
source, I also quickly came to the same conclusion. It is more likely
we can reuse some stuff from other SoCs than Orion or Armada 370/XP.

> The reasons are:
>
>   * This family of SoC is architecturally completely different from the
>     family of Orion SoC: they use completely different hardware blocks
>     (i.e none of the plat-orion stuff would apply, and none of the
>     Orion device drivers would be useful), they don't use the MBus
>     mechanism, etc. They are really a different family of SoC, almost as
>     if they were coming from a different SoC company.
>
>   * The SMP and power management code, as well as all the "glue"
>     platform code that typically sits in mach-<foo> is going to be
>     substantially, if not completely different from the one in
>     mach-mvebu. I already believe doing all the "glue" platform code in
>     mach-mvebu for all of Kirkwood, Dove, 370/XP, Orion5x and MV78xx0 is
>     going to be a challenge, so I'd suggest to not add to this challenge
>     a completely separate family of SOCs.
>
> The codename used for those Armada 1500 SOCs is "Berlin", so a name
> like mach-berlin, or mach-mvberlin (if we want to keep 'mv' to identify
> the founder) seems like a good name.

I have already moved it under mach-mv88de3xxx as for now, all SoCs
Marvell is providing as DE (Digital Entertainment) fit in that. I like
mach-codename style more than plain numbers, maybe I rename the folder
to mach-berlin before posting.

Speaking of "berlin", they found a 2WW bomb in my home town center today
and are evacuating apartments. Mine too, so it looks like I'll have
some time to prepare v2 tonight..

> Also, to help us understand the organization of the family of SOCs, I
> asked a few informations to Marvell, and here is what I could collect:
>
> """
> BGxname		CPU core	codename	L2 cache controller	internal name
> BG2		PJ4B		Armada1500	Tauros3			MV88DE3100
> BG2-CT		Cortex-A9	N/A		PL310			N/A
> BG3		Cortex-A15	N/A		CA15 integrated		N/A
> """
>
> As was told that the Armada X or MV88DEx names are not used during
> development, and what Marvell is really using are the BGxx names.

Ok, I'll add that info to Marvell SoC documentation also.

Sebastian

[RFC v1 0/5] ARM: Initial support for Marvell Armada 1500

[Thomas Petazzoni]

Dear Sebastian Hesselbarth,

On Tue, 27 Aug 2013 18:45:45 +0200, Sebastian Hesselbarth wrote:

> > After talking a bit with engineers within Marvell that work on this
> > SoC, I'm inclined to think that using mach-mvebu for this family of SoC
> > is not a good idea.
> 
> Thomas,
> 
> thanks for the info below. Reading a little bit through the GPL'ed
> source, I also quickly came to the same conclusion. It is more likely
> we can reuse some stuff from other SoCs than Orion or Armada 370/XP.

Yes, many of the IP blocks are for example DesignWare IPs, or ARM IPs
in the case of the Cortex-A based variants.

> > The codename used for those Armada 1500 SOCs is "Berlin", so a name
> > like mach-berlin, or mach-mvberlin (if we want to keep 'mv' to identify
> > the founder) seems like a good name.
> 
> I have already moved it under mach-mv88de3xxx as for now, all SoCs
> Marvell is providing as DE (Digital Entertainment) fit in that. I like
> mach-codename style more than plain numbers, maybe I rename the folder
> to mach-berlin before posting.

I also like mach-berlin a bit more than mach-mve88de3xxx, for a very
silly reason: when during a discussion you have to say mach-mv88de3xxx,
it's pretty annoying. We already have the horrible mach-mv78xx0, let's
not add more of this :)

> Speaking of "berlin", they found a 2WW bomb in my home town center today
> and are evacuating apartments. Mine too, so it looks like I'll have
> some time to prepare v2 tonight..

Doh!

> > Also, to help us understand the organization of the family of SOCs, I
> > asked a few informations to Marvell, and here is what I could collect:
> >
> > """
> > BGxname		CPU core	codename	L2 cache controller	internal name
> > BG2		PJ4B		Armada1500	Tauros3			MV88DE3100
> > BG2-CT		Cortex-A9	N/A		PL310			N/A
> > BG3		Cortex-A15	N/A		CA15 integrated		N/A
> > """
> >
> > As was told that the Armada X or MV88DEx names are not used during
> > development, and what Marvell is really using are the BGxx names.
> 
> Ok, I'll add that info to Marvell SoC documentation also.

That'd be nice indeed.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[RFC v1 0/5] ARM: Initial support for Marvell Armada 1500

[Arnd Bergmann]

On Tuesday 27 August 2013 16:19:58 Thomas Petazzoni wrote:
> 
> Also, to help us understand the organization of the family of SOCs, I
> asked a few informations to Marvell, and here is what I could collect:
> 
> """
> BGxname         CPU core        codename        L2 cache controller     internal name
> BG2             PJ4B            Armada1500      Tauros3                 MV88DE3100
> BG2-CT          Cortex-A9       N/A             PL310                   N/A
> BG3             Cortex-A15      N/A             CA15 integrated         N/A
> """

My guess is that BG2-CT is Armada1500-mini aka MV88DE3005, i.e. the chip
used in the chromecast.
At least that is what gets used in the chromecast kernel sources, but it's
also possible that there are UP and SMP versions of BG2-CT and that
DE3005 is only the former.

	Arnd

[PATCH RFC v2 0/6] ARM: Initial support for Marvell Armada 1500

[Sebastian Hesselbarth]

This is the second RFC to add initial support for the Marvell Armada 1500
(88DE3100) found on various consumer devices. The changes compared to v1
have been quite fundamental, so I'll also summarize them in this cover letter.

I have addressed the following comments given during v1:
- moved to new mach-berlin subdir to reflect the difference from Armada 370/XP.
- removed redundant map_io hook and reduced DT soc range
- added SoC binding documentation
- added to Marvell SoC documentation
- have extra DEBUG_ Kconfig option for Marvell Berlin SoCs
- build with multi_v7_defconfig
- reorder things alphabetically

Comments I have not addressed:
- left .init_time hook as common arch clock init is currently under
  discussion in a separate patch set (comment added)
- left non-DT l2x0_of_init as I was allowed to choose only one cleanup
  out of the two prerequesites (comment added)

Also, I added copyright credits to the Asus Cube GPL'ed 2.6 kernel
source I was using as datasheet replacement. I have taken virtually
nothing out of it except register offsets, irq numbers, and clock
hierarchy. Actually, I would even put Marvell's direct copyright into
it just because I'd love to see them to continue their community efforts
they have started in the past. Anyway, I am not affiliated with Marvell,
so I cannot just make them resposible for the current, rudimentary SoC
skeleton patches.

This time the patches have been based on linux-next's next-20130827
tag, which better reflects the targeted 1 or 2 merge windows.

Sebastian Hesselbarth (6):
  irqchip: add DesignWare APB ICTL interrupt controller
  ARM: add Marvell Berlin SoC familiy to Marvell doc
  ARM: add Marvell Berlin and Armada 1500 to multi_v7_defconfig
  ARM: add Marvell Berlin UART0 lowlevel debug
  ARM: add Armada 1500 and Sony NSZ-GS7 device tree files
  ARM: add initial support for Marvell Berlin SoCs

 Documentation/arm/Marvell/README                   |   22 ++
 .../devicetree/bindings/arm/marvell,berlin.txt     |   23 ++
 .../interrupt-controller/snps,dw-apb-ictl.txt      |   29 +++
 arch/arm/Kconfig                                   |    2 +
 arch/arm/Kconfig.debug                             |   10 +
 arch/arm/Makefile                                  |    1 +
 arch/arm/boot/dts/Makefile                         |    2 +
 arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts      |   29 +++
 arch/arm/boot/dts/mv88de3100.dtsi                  |  222 ++++++++++++++++++++
 arch/arm/configs/multi_v7_defconfig                |    2 +
 arch/arm/mach-berlin/Kconfig                       |   24 ++
 arch/arm/mach-berlin/Makefile                      |    1 +
 arch/arm/mach-berlin/berlin.c                      |   49 +++++
 drivers/irqchip/Kconfig                            |    4 +
 drivers/irqchip/Makefile                           |    1 +
 drivers/irqchip/irq-dw-apb-ictl.c                  |  142 +++++++++++++
 16 files changed, 563 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell,berlin.txt
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
 create mode 100644 arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts
 create mode 100644 arch/arm/boot/dts/mv88de3100.dtsi
 create mode 100644 arch/arm/mach-berlin/Kconfig
 create mode 100644 arch/arm/mach-berlin/Makefile
 create mode 100644 arch/arm/mach-berlin/berlin.c
 create mode 100644 drivers/irqchip/irq-dw-apb-ictl.c

---
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
-- 
1.7.2.5

[PATCH RFC v2 1/6] irqchip: add DesignWare APB ICTL interrupt controller

[Sebastian Hesselbarth]

This adds an irqchip driver and corresponding devicetree binding for the
secondary interrupt controllers based on Synopsys DesignWare IP dw_apb_ictl.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Changelog:
v1->v2:
- added copyright reference

Note:
The driver has been sent as a separate patch before, I decided to take it
back into the RFC. There is no other platform using it yet and this way I
can track all changes. Sorry for the noise caused by the individual patch.

Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: devicetree at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 .../interrupt-controller/snps,dw-apb-ictl.txt      |   29 ++++
 drivers/irqchip/Kconfig                            |    4 +
 drivers/irqchip/Makefile                           |    1 +
 drivers/irqchip/irq-dw-apb-ictl.c                  |  142 ++++++++++++++++++++
 4 files changed, 176 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
 create mode 100644 drivers/irqchip/irq-dw-apb-ictl.c

diff --git a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
new file mode 100644
index 0000000..7ccd1ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
@@ -0,0 +1,29 @@
+Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
+
+Synopsys DesignWare provides interrupt controller IP for APB known as
+dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs with
+APB bus, e.g. Marvell Armada 1500.
+
+Required properties:
+- compatible: shall be "snps,dw-apb-ictl"
+- reg: base address of interrupt registers starting with ENABLE_LOW register
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: number of cells to encode an interrupt source, shall be 1
+- interrupts: interrupt reference to primary interrupt controller
+- interrupt-parent: (optional) reference specific primary interrupt controller
+
+The interrupt sources map to the corresponding bits in the interrupt
+registers, i.e.
+- 0 maps to bit 0 of low interrupts,
+- 1 maps to bit 1 of low interrupts,
+- 32 maps to bit 0 of high interrupts, and so on.
+
+Example:
+	aic: interrupt-controller at 3000 {
+		compatible = "snps,dw-apb-ictl";
+		reg = <0x3000 0xc00>;
+		interrupt-controller;
+		#interrupt-cells = <1>;
+		interrupt-parent = <&gic>;
+		interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+	};
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 3792a1a..940638d 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -30,6 +30,10 @@ config ARM_VIC_NR
 	  The maximum number of VICs available in the system, for
 	  power management.
 
+config DW_APB_ICTL
+	bool
+	select IRQ_DOMAIN
+
 config IMGPDC_IRQ
 	bool
 	select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 81e8cd4..e5bfb19 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_ARCH_SPEAR3XX)		+= spear-shirq.o
 obj-$(CONFIG_ARM_GIC)			+= irq-gic.o
 obj-$(CONFIG_ARM_NVIC)			+= irq-nvic.o
 obj-$(CONFIG_ARM_VIC)			+= irq-vic.o
+obj-$(CONFIG_DW_APB_ICTL)		+= irq-dw-apb-ictl.o
 obj-$(CONFIG_IMGPDC_IRQ)		+= irq-imgpdc.o
 obj-$(CONFIG_SIRF_IRQ)			+= irq-sirfsoc.o
 obj-$(CONFIG_RENESAS_INTC_IRQPIN)	+= irq-renesas-intc-irqpin.o
diff --git a/drivers/irqchip/irq-dw-apb-ictl.c b/drivers/irqchip/irq-dw-apb-ictl.c
new file mode 100644
index 0000000..bbcacee
--- /dev/null
+++ b/drivers/irqchip/irq-dw-apb-ictl.c
@@ -0,0 +1,142 @@
+/*
+ * Synopsys DW APB ICTL irqchip driver.
+ *
+ * Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+ *
+ * based on GPL'ed 2.6 kernel sources
+ *  (c) Marvell International Ltd.
+ *
+ * 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 <linux/io.h>
+#include <linux/irq.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+
+#include "irqchip.h"
+
+#define APB_INT_ENABLE_L	0x00
+#define APB_INT_ENABLE_H	0x04
+#define APB_INT_MASK_L		0x08
+#define APB_INT_MASK_H		0x0c
+#define APB_INT_FINALSTATUS_L	0x30
+#define APB_INT_FINALSTATUS_H	0x34
+
+static void dw_apb_ictl_handler(unsigned int irq, struct irq_desc *desc)
+{
+	struct irq_chip *chip = irq_get_chip(irq);
+	struct irq_chip_generic *gc = irq_get_handler_data(irq);
+	struct irq_domain *d = gc->private;
+	u32 stat;
+	int n;
+
+	chained_irq_enter(chip, desc);
+
+	for (n = 0; n < gc->num_ct; n++) {
+		stat = readl_relaxed(gc->reg_base +
+				     APB_INT_FINALSTATUS_L + 4 * n);
+		while (stat) {
+			u32 hwirq = ffs(stat) - 1;
+			generic_handle_irq(irq_find_mapping(d,
+					    gc->irq_base + hwirq + 32 * n));
+			stat &= ~(1 << hwirq);
+		}
+	}
+
+	chained_irq_exit(chip, desc);
+}
+
+static int __init dw_apb_ictl_init(struct device_node *np,
+				   struct device_node *parent)
+{
+	unsigned int clr = IRQ_NOREQUEST | IRQ_NOPROBE | IRQ_NOAUTOEN;
+	struct resource r;
+	struct irq_domain *domain;
+	struct irq_chip_generic *gc;
+	void __iomem *iobase;
+	int ret, nrirqs, irq;
+	u32 reg;
+
+	/* Map the parent interrupt for the chained handler */
+	irq = irq_of_parse_and_map(np, 0);
+	if (irq <= 0) {
+		pr_err("%s: unable to parse irq\n", np->name);
+		return -EINVAL;
+	}
+
+	ret = of_address_to_resource(np, 0, &r);
+	if (ret) {
+		pr_err("%s: unable to get resource\n", np->name);
+		return ret;
+	}
+
+	if (!request_mem_region(r.start, resource_size(&r), np->name)) {
+		pr_err("%s: unable to request mem region\n", np->name);
+		return -ENOMEM;
+	}
+
+	iobase = ioremap(r.start, resource_size(&r));
+	if (!iobase) {
+		pr_err("%s: unable to map resource\n", np->name);
+		return -ENOMEM;
+	}
+
+	/*
+	 * DW IP can be configured to allow 2-64 irqs. We can determine
+	 * the number of irqs supported by writing into enable register
+	 * and look for bits not set, as corresponding flip-flops will
+	 * have been removed by sythesis tool.
+	 */
+
+	/* mask and enable all interrupts */
+	writel(~0, iobase + APB_INT_MASK_L);
+	writel(~0, iobase + APB_INT_MASK_H);
+	writel(~0, iobase + APB_INT_ENABLE_L);
+	writel(~0, iobase + APB_INT_ENABLE_H);
+
+	reg = readl(iobase + APB_INT_ENABLE_H);
+	if (reg)
+		nrirqs = 32 + fls(reg);
+	else
+		nrirqs = fls(readl(iobase + APB_INT_ENABLE_L));
+
+	domain = irq_domain_add_linear(np, nrirqs,
+				       &irq_generic_chip_ops, NULL);
+	if (!domain) {
+		pr_err("%s: unable to add irq domain\n", np->name);
+		return -ENOMEM;
+	}
+
+	ret = irq_alloc_domain_generic_chips(domain, 32, (nrirqs > 32) ? 2 : 1,
+					     np->name, handle_level_irq, clr, 0,
+					     IRQ_GC_INIT_MASK_CACHE);
+	if (ret) {
+		pr_err("%s: unable to alloc irq domain gc\n", np->name);
+		return ret;
+	}
+
+	gc = irq_get_domain_generic_chip(domain, 0);
+	gc->private = domain;
+	gc->reg_base = iobase;
+
+	gc->chip_types[0].regs.mask = APB_INT_MASK_L;
+	gc->chip_types[0].chip.irq_mask = irq_gc_mask_set_bit;
+	gc->chip_types[0].chip.irq_unmask = irq_gc_mask_clr_bit;
+
+	if (nrirqs > 32) {
+		gc->chip_types[1].regs.mask = APB_INT_MASK_H;
+		gc->chip_types[1].chip.irq_mask = irq_gc_mask_set_bit;
+		gc->chip_types[1].chip.irq_unmask = irq_gc_mask_clr_bit;
+	}
+
+	irq_set_handler_data(irq, gc);
+	irq_set_chained_handler(irq, dw_apb_ictl_handler);
+
+	return 0;
+}
+IRQCHIP_DECLARE(dw_apb_ictl,
+		"snps,dw-apb-ictl", dw_apb_ictl_init);
-- 
1.7.2.5

[PATCH RFC v2 2/6] ARM: add Marvell Berlin SoC familiy to Marvell doc

[Sebastian Hesselbarth]

This adds known facts and rumors about the Marvell Berlin (88DE3xxx) SoC
family to the Marvell SoC documentation.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Changelog:
v1->v2:
- initial patch

Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-doc at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 Documentation/arm/Marvell/README |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index 8f08a86..dc0dfdd6 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -126,6 +126,28 @@ Dove family (application processor)
   Core: ARMv7 compatible
   Directory: arch/arm/mach-dove
 
+Berlin family (Digital Entertainment)
+-------------------------------------
+
+  Flavors:
+	88DE3005, Armada 1500-mini
+		Design name:	BG2-CT
+		Core:		ARM Cortex-A9, PL310 L2CC
+	88DE3010, Armada 1000
+		Design name:	unknown
+		Core:		Marvell Sheeva (possibly PJ4A/B, Tauros2/3)
+		Product Brief:	http://www.marvell.com/digital-entertainment/assets/armada_1000_pb.pdf
+	88DE3100, Armada 1500
+		Design name:	BG2
+		Core:		Marvell PJ4B (ARMv7), Tauros3 L2CC
+		Product Brief:	http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
+	88DE????
+		Design name:	BG3
+		Core:		ARM Cortex-A15, CA15 integrated L2CC
+
+  Homepage: http://www.marvell.com/digital-entertainment/
+  Directory: arch/arm/mach-berlin
+
 PXA 2xx/3xx/93x/95x family
 --------------------------
 
-- 
1.7.2.5

[PATCH RFC v2 3/6] ARM: add Marvell Berlin and Armada 1500 to multi_v7_defconfig

[Sebastian Hesselbarth]

This adds the Marvell Berlin (88DE3xxx) SoC family and Marvell Armada 1500
(88DE3100) to the multi_v7_defconfig.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Changelog:
v1->v2:
- initial patch due to separate mach- directory

Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/configs/multi_v7_defconfig |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 6e572c6..a017677 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -6,6 +6,8 @@ CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_XP=y
 CONFIG_ARCH_BCM=y
+CONFIG_ARCH_BERLIN=y
+CONFIG_MACH_MV88DE3100=y
 CONFIG_GPIO_PCA953X=y
 CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_KEYSTONE=y
-- 
1.7.2.5

[PATCH RFC v2 4/6] ARM: add Marvell Berlin UART0 lowlevel debug

[Sebastian Hesselbarth]

This adds UART0 as found on Marvell 88DE3xxx SoCs, e.g. Armada 1500
to the list of possible lowlevel debug options.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Changelog:
v1->v2:
- have separate DEBUG option due to separate mach- directory

Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/Kconfig.debug |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index f793599..89617d4 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -94,6 +94,14 @@ choice
 		depends on ARCH_BCM2835
 		select DEBUG_UART_PL01X
 
+	config DEBUG_BERLIN_UART
+		bool "Marvell Berlin (88DE3xxx) Debug UART"
+		depends on ARCH_BERLIN
+		select DEBUG_UART_8250
+		help
+		  Say Y here if you want kernel low-level debugging support
+		  on Marvell Berlin (88DE3xxx) based platforms.
+
 	config DEBUG_CLPS711X_UART1
 		bool "Kernel low-level debugging messages via UART1"
 		depends on ARCH_CLPS711X
@@ -957,6 +965,7 @@ config DEBUG_UART_PHYS
 	default 0xf1012000 if DEBUG_MVEBU_UART_ALTERNATE
 	default 0xf1012000 if ARCH_DOVE || ARCH_KIRKWOOD || ARCH_MV78XX0 || \
 				ARCH_ORION5X
+	default 0xf7fc9000 if DEBUG_BERLIN_UART
 	default 0xfe800000 if ARCH_IOP32X
 	default 0xffc02000 if DEBUG_SOCFPGA_UART
 	default 0xffd82340 if ARCH_IOP13XX
@@ -979,6 +988,7 @@ config DEBUG_UART_VIRT
 	default 0xf2100000 if DEBUG_PXA_UART1
 	default 0xf4090000 if ARCH_LPC32XX
 	default 0xf4200000 if ARCH_GEMINI
+	default 0xf7fc9000 if DEBUG_BERLIN_UART
 	default 0xf8009000 if DEBUG_VEXPRESS_UART0_CA9
 	default 0xf8090000 if DEBUG_VEXPRESS_UART0_RS1
 	default 0xfb009000 if DEBUG_REALVIEW_STD_PORT
-- 
1.7.2.5

[PATCH RFC v2 5/6] ARM: add Armada 1500 and Sony NSZ-GS7 device tree files

[Sebastian Hesselbarth]

This adds very basic device tree files for the Marvell Armada 1500 SoC
(88DE3100) and the Sony NSZ-GS7 GoogleTV board. Currently, SoC only has
nodes for cpus, some clocks, l2 cache controller, local timer, apb timers,
uart, and interrupt controllers. The Sony NSZ-GS7 is a GoogleTV consumer
device comprising the Armada 1500 SoC above.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Changelog:
v1->v2:
- add binding documentation (Reported by Jason Cooper)
- change l2cc from aurora to tauros3 (Reported by Thomas Petazzoni)
- add copyright reference
- adapt compatibles to mach-berlin instead of mach-mvebu

Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: devicetree at vger.kernel.org
Cc: linux-doc at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 .../devicetree/bindings/arm/marvell,berlin.txt     |   23 ++
 arch/arm/boot/dts/Makefile                         |    2 +
 arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts      |   29 +++
 arch/arm/boot/dts/mv88de3100.dtsi                  |  222 ++++++++++++++++++++
 4 files changed, 276 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/arm/marvell,berlin.txt
 create mode 100644 arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts
 create mode 100644 arch/arm/boot/dts/mv88de3100.dtsi

diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
new file mode 100644
index 0000000..a4c3056
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
@@ -0,0 +1,23 @@
+Marvell Berlin (88DE3xxx) family SoCs Device Tree Bindings
+---------------------------------------------------------------
+
+Boards with a SoC of the Marvell Berlin (88DE3xxx) family, e.g. Armada 1500
+shall have the following properties:
+
+* Required root node properties:
+compatible: must contain "marvell,berlin"
+
+In addition, the above compatible shall be extended with the specific
+SoC used, i.e.
+    "marvell,88de3100"	for Marvell 88DE3100 (Armada 1500),
+    "marvell,88de3010"	for Marvell 88DE3010 (Armada 1000),
+    "marvell,88de3005"	for Marvell 88DE3005 (Armada 1500-mini)
+
+* Example:
+
+/ {
+	model = "Sony NSZ-GS7";
+	compatible = "marvell,88de3100", "marvell,berlin";
+
+	...
+}
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d45058e..2989b51 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -43,6 +43,8 @@ dtb-$(CONFIG_ARCH_AT91)	+= sama5d35ek.dtb
 
 dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
 dtb-$(CONFIG_ARCH_BCM) += bcm11351-brt.dtb
+dtb-$(CONFIG_ARCH_BERLIN) += \
+	mv88de3100-sony-nsz-gs7.dtb
 dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
 	da850-evm.dtb
 dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
diff --git a/arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts b/arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts
new file mode 100644
index 0000000..1081bc1
--- /dev/null
+++ b/arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts
@@ -0,0 +1,29 @@
+/*
+ * Device Tree file for Sony NSZ-GS7
+ *
+ * Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+#include "mv88de3100.dtsi"
+
+/ {
+	model = "Sony NSZ-GS7";
+	compatible = "sony,nsz-gs7", "marvell,88de3100", "marvell,berlin";
+
+	chosen {
+		bootargs = "console=ttyS0,115200 earlyprintk verbose debug";
+	};
+
+	memory {
+		device_type = "memory";
+		reg = <0x00000000 0x40000000>; /* 1 GB */
+	};
+};
+
+&uart0 { status = "okay"; };
diff --git a/arch/arm/boot/dts/mv88de3100.dtsi b/arch/arm/boot/dts/mv88de3100.dtsi
new file mode 100644
index 0000000..04328a6
--- /dev/null
+++ b/arch/arm/boot/dts/mv88de3100.dtsi
@@ -0,0 +1,222 @@
+/*
+ * Device Tree Include file for Marvell 88DE3100 (Armada 1500) SoC
+ *
+ * Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+ *
+ * based on GPL'ed 2.6 kernel sources
+ *  (c) Marvell International Ltd.
+ *
+ * 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 "skeleton.dtsi"
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+	model = "Marvell 88DE3100 (Armada 1500) SoC";
+	compatible = "marvell,88de3100", "marvell,berlin";
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu at 0 {
+			compatible = "marvell,sheeva-v7";
+			device_type = "cpu";
+			next-level-cache = <&l2>;
+			reg = <0>;
+		};
+
+		cpu at 1 {
+			compatible = "marvell,sheeva-v7";
+			device_type = "cpu";
+			next-level-cache = <&l2>;
+			reg = <1>;
+		};
+	};
+
+	clocks {
+		/* 25MHz reference crystal */
+		ref25: oscillator {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <25000000>;
+		};
+
+		cfgclk: cfg-clock {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <100000000>;
+		};
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		interrupt-parent = <&gic>;
+
+		ranges = <0 0xf7000000 0x1000000>;
+
+		l2: l2-cache-controller at ac0000 {
+			compatible = "marvell,tauros3-cache";
+			reg = <0xac0000 0x1000>;
+			cache-unified;
+			cache-level = <2>;
+		};
+
+		gic: interrupt-controller at ad1000 {
+			compatible = "arm,cortex-a9-gic";
+			reg = <0xad1000 0x1000
+			       0xad0100 0x0100>;
+			interrupt-controller;
+			#interrupt-cells = <3>;
+		};
+
+		local-timer at ad0600 {
+			compatible = "arm,cortex-a9-twd-timer";
+			reg = <0xad0600 0x20>;
+			interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_HIGH>;
+		};
+
+		apb at e80000 {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			ranges = <0 0xe80000 0x10000>;
+			interrupt-parent = <&aic>;
+
+			timer0: timer at 2c00 {
+				compatible = "snps,dw-apb-timer-osc";
+				reg = <0x2c00 0x14>;
+				interrupts = <8>;
+				clocks = <&cfgclk>;
+				clock-names = "timer";
+				status = "okay";
+			};
+
+			timer1: timer at 2c14 {
+				compatible = "snps,dw-apb-timer-osc";
+				reg = <0x2c14 0x14>;
+				interrupts = <9>;
+				clocks = <&cfgclk>;
+				clock-names = "timer";
+				status = "okay";
+			};
+
+			timer2: timer at 2c28 {
+				compatible = "snps,dw-apb-timer-sp";
+				reg = <0x2c28 0x14>;
+				interrupts = <10>;
+				clocks = <&cfgclk>;
+				clock-names = "timer";
+				status = "okay";
+			};
+
+			timer3: timer at 2c3c {
+				compatible = "snps,dw-apb-timer-sp";
+				reg = <0x2c3c 0x14>;
+				interrupts = <11>;
+				clocks = <&cfgclk>;
+				clock-names = "timer";
+				status = "okay";
+			};
+
+			timer4: timer at 2c50 {
+				compatible = "snps,dw-apb-timer-sp";
+				reg = <0x2c50 0x14>;
+				interrupts = <12>;
+				clocks = <&cfgclk>;
+				clock-names = "timer";
+				status = "disabled";
+			};
+
+			timer5: timer at 2c64 {
+				compatible = "snps,dw-apb-timer-sp";
+				reg = <0x2c64 0x14>;
+				interrupts = <13>;
+				clocks = <&cfgclk>;
+				clock-names = "timer";
+				status = "disabled";
+			};
+
+			timer6: timer at 2c78 {
+				compatible = "snps,dw-apb-timer-sp";
+				reg = <0x2c78 0x14>;
+				interrupts = <14>;
+				clocks = <&cfgclk>;
+				clock-names = "timer";
+				status = "disabled";
+			};
+
+			timer7: timer at 2c8c {
+				compatible = "snps,dw-apb-timer-sp";
+				reg = <0x2c8c 0x14>;
+				interrupts = <15>;
+				clocks = <&cfgclk>;
+				clock-names = "timer";
+				status = "disabled";
+			};
+
+			aic: interrupt-controller at 3000 {
+				compatible = "snps,dw-apb-ictl";
+				reg = <0x3000 0xc00>;
+				interrupt-controller;
+				#interrupt-cells = <1>;
+				interrupt-parent = <&gic>;
+				interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+			};
+		};
+
+		apb at fc0000 {
+			compatible = "simple-bus";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			ranges = <0 0xfc0000 0x10000>;
+			interrupt-parent = <&sic>;
+
+			uart0: serial at 9000 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0x9000 0x100>;
+				reg-shift = <2>;
+				reg-io-width = <1>;
+				interrupts = <8>;
+				clock-frequency = <25000000>;
+				status = "disabled";
+			};
+
+			uart1: serial at a000 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0xa000 0x100>;
+				reg-shift = <2>;
+				reg-io-width = <1>;
+				interrupts = <9>;
+				clock-frequency = <25000000>;
+				status = "disabled";
+			};
+
+			uart2: serial at b000 {
+				compatible = "snps,dw-apb-uart";
+				reg = <0xb000 0x100>;
+				reg-shift = <2>;
+				reg-io-width = <1>;
+				interrupts = <10>;
+				clock-frequency = <25000000>;
+				status = "disabled";
+			};
+
+			sic: interrupt-controller at e000 {
+				compatible = "snps,dw-apb-ictl";
+				reg = <0xe000 0x400>;
+				interrupt-controller;
+				#interrupt-cells = <1>;
+				interrupt-parent = <&gic>;
+				interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH>;
+			};
+		};
+	};
+};
-- 
1.7.2.5

[PATCH RFC v2 5/6] ARM: add Armada 1500 and Sony NSZ-GS7 device tree files

[Jason Cooper]

On Wed, Aug 28, 2013 at 02:14:33AM +0200, Sebastian Hesselbarth wrote:
> This adds very basic device tree files for the Marvell Armada 1500 SoC
> (88DE3100) and the Sony NSZ-GS7 GoogleTV board. Currently, SoC only has
> nodes for cpus, some clocks, l2 cache controller, local timer, apb timers,
> uart, and interrupt controllers. The Sony NSZ-GS7 is a GoogleTV consumer
> device comprising the Armada 1500 SoC above.
> 
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Changelog:
> v1->v2:
> - add binding documentation (Reported by Jason Cooper)
> - change l2cc from aurora to tauros3 (Reported by Thomas Petazzoni)
> - add copyright reference
> - adapt compatibles to mach-berlin instead of mach-mvebu
> 
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: devicetree at vger.kernel.org
> Cc: linux-doc at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
> ---
>  .../devicetree/bindings/arm/marvell,berlin.txt     |   23 ++
>  arch/arm/boot/dts/Makefile                         |    2 +
>  arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts      |   29 +++
>  arch/arm/boot/dts/mv88de3100.dtsi                  |  222 ++++++++++++++++++++
>  4 files changed, 276 insertions(+), 0 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/arm/marvell,berlin.txt
>  create mode 100644 arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts
>  create mode 100644 arch/arm/boot/dts/mv88de3100.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
> new file mode 100644
> index 0000000..a4c3056
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
> @@ -0,0 +1,23 @@
> +Marvell Berlin (88DE3xxx) family SoCs Device Tree Bindings
> +---------------------------------------------------------------
> +
> +Boards with a SoC of the Marvell Berlin (88DE3xxx) family, e.g. Armada 1500
> +shall have the following properties:
> +
> +* Required root node properties:
> +compatible: must contain "marvell,berlin"
> +
> +In addition, the above compatible shall be extended with the specific
> +SoC used, i.e.
> +    "marvell,88de3100"	for Marvell 88DE3100 (Armada 1500),
> +    "marvell,88de3010"	for Marvell 88DE3010 (Armada 1000),
> +    "marvell,88de3005"	for Marvell 88DE3005 (Armada 1500-mini)
> +
> +* Example:
> +
> +/ {
> +	model = "Sony NSZ-GS7";
> +	compatible = "marvell,88de3100", "marvell,berlin";

I would make this:

	compatible = "sony,nsz-gs7", "marvell,88de3100", "marvell,berlin";

> +
> +	...
> +}
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d45058e..2989b51 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -43,6 +43,8 @@ dtb-$(CONFIG_ARCH_AT91)	+= sama5d35ek.dtb
>  
>  dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
>  dtb-$(CONFIG_ARCH_BCM) += bcm11351-brt.dtb
> +dtb-$(CONFIG_ARCH_BERLIN) += \
> +	mv88de3100-sony-nsz-gs7.dtb
>  dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
>  	da850-evm.dtb
>  dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
> diff --git a/arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts b/arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts
> new file mode 100644
> index 0000000..1081bc1
> --- /dev/null
> +++ b/arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts
> @@ -0,0 +1,29 @@
> +/*
> + * Device Tree file for Sony NSZ-GS7
> + *
> + * Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> + *
> + * 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.
> + */
> +
> +/dts-v1/;
> +
> +#include "mv88de3100.dtsi"
> +
> +/ {
> +	model = "Sony NSZ-GS7";
> +	compatible = "sony,nsz-gs7", "marvell,88de3100", "marvell,berlin";
> +
> +	chosen {
> +		bootargs = "console=ttyS0,115200 earlyprintk verbose debug";

I would remove 'verbose debug' before official submission, no point to
defaulting to log-spammer.

thx,

Jason.

[PATCH RFC v2 5/6] ARM: add Armada 1500 and Sony NSZ-GS7 device tree files

[Sebastian Hesselbarth]

On 08/28/13 14:14, Jason Cooper wrote:
> On Wed, Aug 28, 2013 at 02:14:33AM +0200, Sebastian Hesselbarth wrote:
>> This adds very basic device tree files for the Marvell Armada 1500 SoC
>> (88DE3100) and the Sony NSZ-GS7 GoogleTV board. Currently, SoC only has
>> nodes for cpus, some clocks, l2 cache controller, local timer, apb timers,
>> uart, and interrupt controllers. The Sony NSZ-GS7 is a GoogleTV consumer
>> device comprising the Armada 1500 SoC above.
>>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>> ---
>> Changelog:
>> v1->v2:
>> - add binding documentation (Reported by Jason Cooper)
>> - change l2cc from aurora to tauros3 (Reported by Thomas Petazzoni)
>> - add copyright reference
>> - adapt compatibles to mach-berlin instead of mach-mvebu
>>
>> Cc: Jason Cooper <jason@lakedaemon.net>
>> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>> Cc: Arnd Bergmann <arnd@arndb.de>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: devicetree at vger.kernel.org
>> Cc: linux-doc at vger.kernel.org
>> Cc: linux-arm-kernel at lists.infradead.org
>> Cc: linux-kernel at vger.kernel.org
>> ---
>>   .../devicetree/bindings/arm/marvell,berlin.txt     |   23 ++
>>   arch/arm/boot/dts/Makefile                         |    2 +
>>   arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts      |   29 +++
>>   arch/arm/boot/dts/mv88de3100.dtsi                  |  222 ++++++++++++++++++++
>>   4 files changed, 276 insertions(+), 0 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/arm/marvell,berlin.txt
>>   create mode 100644 arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts
>>   create mode 100644 arch/arm/boot/dts/mv88de3100.dtsi
>>
>> diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
>> new file mode 100644
>> index 0000000..a4c3056
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
>> @@ -0,0 +1,23 @@
>> +Marvell Berlin (88DE3xxx) family SoCs Device Tree Bindings
>> +---------------------------------------------------------------
>> +
>> +Boards with a SoC of the Marvell Berlin (88DE3xxx) family, e.g. Armada 1500
>> +shall have the following properties:
>> +
>> +* Required root node properties:
>> +compatible: must contain "marvell,berlin"
>> +
>> +In addition, the above compatible shall be extended with the specific
>> +SoC used, i.e.
>> +    "marvell,88de3100"	for Marvell 88DE3100 (Armada 1500),
>> +    "marvell,88de3010"	for Marvell 88DE3010 (Armada 1000),
>> +    "marvell,88de3005"	for Marvell 88DE3005 (Armada 1500-mini)
>> +
>> +* Example:
>> +
>> +/ {
>> +	model = "Sony NSZ-GS7";
>> +	compatible = "marvell,88de3100", "marvell,berlin";
>
> I would make this:
>
> 	compatible = "sony,nsz-gs7", "marvell,88de3100", "marvell,berlin";

Ok.

>> +
>> +	...
>> +}
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index d45058e..2989b51 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -43,6 +43,8 @@ dtb-$(CONFIG_ARCH_AT91)	+= sama5d35ek.dtb
>>
>>   dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
>>   dtb-$(CONFIG_ARCH_BCM) += bcm11351-brt.dtb
>> +dtb-$(CONFIG_ARCH_BERLIN) += \
>> +	mv88de3100-sony-nsz-gs7.dtb
>>   dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
>>   	da850-evm.dtb
>>   dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
>> diff --git a/arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts b/arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts
>> new file mode 100644
>> index 0000000..1081bc1
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/mv88de3100-sony-nsz-gs7.dts
>> @@ -0,0 +1,29 @@
>> +/*
>> + * Device Tree file for Sony NSZ-GS7
>> + *
>> + * Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>> + *
>> + * 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.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "mv88de3100.dtsi"
>> +
>> +/ {
>> +	model = "Sony NSZ-GS7";
>> +	compatible = "sony,nsz-gs7", "marvell,88de3100", "marvell,berlin";
>> +
>> +	chosen {
>> +		bootargs = "console=ttyS0,115200 earlyprintk verbose debug";
>
> I would remove 'verbose debug' before official submission, no point to
> defaulting to log-spammer.

Agree.

Maybe, for the next patches, I'll add some I/O device drivers that
allow you to actually boot into some rootfs. All those fooHCI IP
shouldn't be that hard - hopefully some quirks only.

I also had a look at I2C and SPI, both DW IP with mainline drivers
available. SPI needs a little DT tweaking and I did not carry out any
functional tests, yet.

Thanks for the constant reviews!

Sebastian

[PATCH RFC v2 6/6] ARM: add initial support for Marvell Berlin SoCs

[Sebastian Hesselbarth]

This adds initial support for the Marvell Berlin (88DE3xxx) SoC family
and basic machine setup for Armada 1500 (88DE3100) SoCs.

Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
---
Changelog:
v1->v2:
- nuke .map_io (Reported by Arnd Bergmann)
- add copyright reference
- switch to mach-berlin instead of mach-mvebu

Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
---
 arch/arm/Kconfig              |    2 +
 arch/arm/Makefile             |    1 +
 arch/arm/mach-berlin/Kconfig  |   24 ++++++++++++++++++++
 arch/arm/mach-berlin/Makefile |    1 +
 arch/arm/mach-berlin/berlin.c |   49 +++++++++++++++++++++++++++++++++++++++++
 5 files changed, 77 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-berlin/Kconfig
 create mode 100644 arch/arm/mach-berlin/Makefile
 create mode 100644 arch/arm/mach-berlin/berlin.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d41b122..329be50 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -930,6 +930,8 @@ source "arch/arm/mach-bcm/Kconfig"
 
 source "arch/arm/mach-bcm2835/Kconfig"
 
+source "arch/arm/mach-berlin/Kconfig"
+
 source "arch/arm/mach-clps711x/Kconfig"
 
 source "arch/arm/mach-cns3xxx/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index a37a50f..3ba332b 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -147,6 +147,7 @@ textofs-$(CONFIG_ARCH_MSM8960) := 0x00208000
 machine-$(CONFIG_ARCH_AT91)		+= at91
 machine-$(CONFIG_ARCH_BCM)		+= bcm
 machine-$(CONFIG_ARCH_BCM2835)		+= bcm2835
+machine-$(CONFIG_ARCH_BERLIN)		+= berlin
 machine-$(CONFIG_ARCH_CLPS711X)		+= clps711x
 machine-$(CONFIG_ARCH_CNS3XXX)		+= cns3xxx
 machine-$(CONFIG_ARCH_DAVINCI)		+= davinci
diff --git a/arch/arm/mach-berlin/Kconfig b/arch/arm/mach-berlin/Kconfig
new file mode 100644
index 0000000..56a671e
--- /dev/null
+++ b/arch/arm/mach-berlin/Kconfig
@@ -0,0 +1,24 @@
+config ARCH_BERLIN
+	bool "Marvell Berlin (88DE3xxx) SoCs" if ARCH_MULTI_V7
+	select GENERIC_CLOCKEVENTS
+	select GENERIC_IRQ_CHIP
+	select COMMON_CLK
+	select DW_APB_ICTL
+	select DW_APB_TIMER_OF
+
+if ARCH_BERLIN
+
+menu "Marvell Berlin (88DE3xxx) SoC variants"
+
+config MACH_MV88DE3100
+	bool "Marvell 88DE3100 (Armada 1500)"
+	select ARM_GIC
+	select CACHE_L2X0
+	select CPU_PJ4B
+	select HAVE_ARM_TWD if LOCAL_TIMERS
+	select HAVE_SMP
+	select LOCAL_TIMERS if SMP
+
+endmenu
+
+endif
diff --git a/arch/arm/mach-berlin/Makefile b/arch/arm/mach-berlin/Makefile
new file mode 100644
index 0000000..ab69fe9
--- /dev/null
+++ b/arch/arm/mach-berlin/Makefile
@@ -0,0 +1 @@
+obj-y += berlin.o
diff --git a/arch/arm/mach-berlin/berlin.c b/arch/arm/mach-berlin/berlin.c
new file mode 100644
index 0000000..8ed03c8
--- /dev/null
+++ b/arch/arm/mach-berlin/berlin.c
@@ -0,0 +1,49 @@
+/*
+ * Device Tree support for Marvell Berlin (88DE3xxx) platforms.
+ *
+ * Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+ *
+ * based on GPL'ed 2.6 kernel sources
+ *  (c) Marvell International Ltd.
+ *
+ * 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 <linux/clk-provider.h>
+#include <linux/clocksource.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of_platform.h>
+#include <asm/hardware/cache-l2x0.h>
+#include <asm/mach/arch.h>
+
+static void __init berlin_init_time(void)
+{
+	/* with arch-wide of_clk_init, .init_time can be removed */
+	of_clk_init(NULL);
+	clocksource_of_init();
+}
+
+static void __init berlin_init_machine(void)
+{
+	/*
+	 * with DT probing for Tauros L2CC, .init_machine can be removed
+	 * Note: 88DE3005 (Armada 1500-mini) uses pl310 l2cc
+	 */
+	l2x0_of_init(0x70c00000, 0xfeffffff);
+	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+}
+
+static const char * const berlin_dt_compat[] = {
+	"marvell,berlin",
+	NULL,
+};
+
+DT_MACHINE_START(BERLIN_DT, "Marvell Berlin")
+	.dt_compat      = berlin_dt_compat,
+	.init_machine   = berlin_init_machine,
+	.init_time	= berlin_init_time,
+MACHINE_END
-- 
1.7.2.5