[PATCH v2 0/4] arm64, thunder: Enable Cavium Thunder SoC Family

[PATCH v2 0/4] arm64, thunder: Enable Cavium Thunder SoC Family

[Robert Richter]

From: Robert Richter <rrichter@cavium.com>

This initial patches enable Cavium Thunder SoC Family. The patches add
Kconfig and devicetree support and then add Thunder to the defconfig.

The Thunder system needs more enablement patches for subsystems and
devices, this includes network, ahci, gicv3/gicv3-its, pci, smmu, kvm.
We will send separate patch sets for these. All of them base on this
initial patches.

I sent a separate patch set independently that introduces support for
dts vendor subdirs. After both patch sets have been applied I will
send a patch in addition that moves the dts file into a subdirectory.

Patches are available here:

 git://git.kernel.org/pub/scm/linux/kernel/git/rric/linux.git thunder/init

v2 changes:
* rebased to 3.17
* placed commas between 32-bit portions of 64 bit addresses
* removed #address-cells and size-cells in gic node
* get rid of the clocks node
* changed to gpl/x11 dual license
* removed memreserve
* moved gic to bus node

Radha Mohan Chintakuntla (3):
  arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family
  arm64, thunder: Add initial dts for Cavium Thunder SoC
  arm64, thunder: Document devicetree bindings for Cavium Thunder SoC

Robert Richter (1):
  arm64, defconfig: Enable Cavium Thunder SoC in defconfig

 .../devicetree/bindings/arm/cavium-thunder.txt     |  10 +
 Documentation/devicetree/bindings/arm/cpus.txt     |   1 +
 arch/arm64/Kconfig                                 |   6 +
 arch/arm64/boot/dts/Makefile                       |   1 +
 arch/arm64/boot/dts/thunder-88xx.dts               | 414 +++++++++++++++++++++
 arch/arm64/configs/defconfig                       |   1 +
 6 files changed, 433 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/cavium-thunder.txt
 create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts

-- 
2.0.1

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Robert Richter]

From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>

Increase maximum numbers of cpus to 32. This relates to current
maximal possible cpu number. Increasing this to 64 cpus will be a
separate patch not part of this enablement patches.

Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
 arch/arm64/Kconfig | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index fd4e81a4e1ce..77fb82b0f684 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -134,6 +134,11 @@ source "kernel/Kconfig.freezer"
 
 menu "Platform selection"
 
+config ARCH_THUNDER
+	bool "Cavium Inc. Thunder SoC Family"
+	help
+	  This enables support for Cavium's Thunder Family of SoCs.
+
 config ARCH_VEXPRESS
 	bool "ARMv8 software model (Versatile Express)"
 	select ARCH_REQUIRE_GPIOLIB
@@ -256,6 +261,7 @@ config NR_CPUS
 	range 2 32
 	depends on SMP
 	# These have to remain sorted largest to smallest
+	default "32" if ARCH_THUNDER
 	default "8"
 
 config HOTPLUG_CPU
-- 
2.0.1

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Will Deacon]

On Fri, Sep 05, 2014 at 08:46:42AM +0100, Robert Richter wrote:
> From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> 
> Increase maximum numbers of cpus to 32. This relates to current
> maximal possible cpu number. Increasing this to 64 cpus will be a
> separate patch not part of this enablement patches.

Just out of interest, does raising the current maximum limit actually break
any existing code? If not, then doing this as two patches doesn't seem worth
it.

Will

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Robert Richter]

On 05.09.14 09:39:32, Will Deacon wrote:
> On Fri, Sep 05, 2014 at 08:46:42AM +0100, Robert Richter wrote:
> > From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > 
> > Increase maximum numbers of cpus to 32. This relates to current
> > maximal possible cpu number. Increasing this to 64 cpus will be a
> > separate patch not part of this enablement patches.
> 
> Just out of interest, does raising the current maximum limit actually break
> any existing code? If not, then doing this as two patches doesn't seem worth
> it.

Increasing to 64 should be fine from the perspective of cpu mask
implementation. Memory foot print should be the same already as this
uses long which is 64 bit. So this wouldn't hurt.

However, I felt a bit uncomfortable having a dependency here to
enabling 64 cpus and getting this patch set upstream. Support for more
than 32 cpus is not well tested yet and there still might be problems
with e.g. interrupt delivery or topology.

If increasing to 32 cpus as an intermediate step isn't the best
approach here, we can live with the current defaults too. I would then
just remove that change from the patch.

For follow on driver patch sets it would be good to have ARCH_THUNDER
upstream as this option will be shared between all drivers.

-Robert

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Will Deacon]

On Fri, Sep 05, 2014 at 10:21:35AM +0100, Robert Richter wrote:
> On 05.09.14 09:39:32, Will Deacon wrote:
> > On Fri, Sep 05, 2014 at 08:46:42AM +0100, Robert Richter wrote:
> > > From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > > 
> > > Increase maximum numbers of cpus to 32. This relates to current
> > > maximal possible cpu number. Increasing this to 64 cpus will be a
> > > separate patch not part of this enablement patches.
> > 
> > Just out of interest, does raising the current maximum limit actually break
> > any existing code? If not, then doing this as two patches doesn't seem worth
> > it.
> 
> Increasing to 64 should be fine from the perspective of cpu mask
> implementation. Memory foot print should be the same already as this
> uses long which is 64 bit. So this wouldn't hurt.
> 
> However, I felt a bit uncomfortable having a dependency here to
> enabling 64 cpus and getting this patch set upstream. Support for more
> than 32 cpus is not well tested yet and there still might be problems
> with e.g. interrupt delivery or topology.

All I mean is, if the kernel doesn't explode on existing systems by changing
the upper limit to 64, then we should do that. If you're not comfortable
that the Thunder code can handle that, then leave the thunder default as 32,
like you do in the current patch. It just seems odd not to change the
maximum number, since it's an arbitrary limit from my perspective.

Will

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Mark Rutland]

On Fri, Sep 05, 2014 at 10:25:08AM +0100, Will Deacon wrote:
> On Fri, Sep 05, 2014 at 10:21:35AM +0100, Robert Richter wrote:
> > On 05.09.14 09:39:32, Will Deacon wrote:
> > > On Fri, Sep 05, 2014 at 08:46:42AM +0100, Robert Richter wrote:
> > > > From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > > > 
> > > > Increase maximum numbers of cpus to 32. This relates to current
> > > > maximal possible cpu number. Increasing this to 64 cpus will be a
> > > > separate patch not part of this enablement patches.
> > > 
> > > Just out of interest, does raising the current maximum limit actually break
> > > any existing code? If not, then doing this as two patches doesn't seem worth
> > > it.
> > 
> > Increasing to 64 should be fine from the perspective of cpu mask
> > implementation. Memory foot print should be the same already as this
> > uses long which is 64 bit. So this wouldn't hurt.
> > 
> > However, I felt a bit uncomfortable having a dependency here to
> > enabling 64 cpus and getting this patch set upstream. Support for more
> > than 32 cpus is not well tested yet and there still might be problems
> > with e.g. interrupt delivery or topology.
> 
> All I mean is, if the kernel doesn't explode on existing systems by changing
> the upper limit to 64, then we should do that. If you're not comfortable
> that the Thunder code can handle that, then leave the thunder default as 32,
> like you do in the current patch. It just seems odd not to change the
> maximum number, since it's an arbitrary limit from my perspective.

FWIW my Juno happily boots with a NR_CPUS=64 kernel.

Mark.

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Robert Richter]

On 05.09.14 10:36:47, Mark Rutland wrote:
> On Fri, Sep 05, 2014 at 10:25:08AM +0100, Will Deacon wrote:
> > All I mean is, if the kernel doesn't explode on existing systems by changing
> > the upper limit to 64, then we should do that. If you're not comfortable
> > that the Thunder code can handle that, then leave the thunder default as 32,
> > like you do in the current patch. It just seems odd not to change the
> > maximum number, since it's an arbitrary limit from my perspective.
> 
> FWIW my Juno happily boots with a NR_CPUS=64 kernel.

It looks like if it's fine to set the general default to NR_CPUS=64
even if the kernel might not yet boot more than 32 cpus. Will make
this change separately and drop it in this patch.

See also my other reply to Russell in this thread.

-Robert

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Russell King - ARM Linux]

On Fri, Sep 05, 2014 at 09:46:42AM +0200, Robert Richter wrote:
> From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> 
> Increase maximum numbers of cpus to 32. This relates to current
> maximal possible cpu number. Increasing this to 64 cpus will be a
> separate patch not part of this enablement patches.
> 
> Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> Signed-off-by: Robert Richter <rrichter@cavium.com>
> ---
>  arch/arm64/Kconfig | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index fd4e81a4e1ce..77fb82b0f684 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -134,6 +134,11 @@ source "kernel/Kconfig.freezer"
>  
>  menu "Platform selection"
>  
> +config ARCH_THUNDER
> +	bool "Cavium Inc. Thunder SoC Family"
> +	help
> +	  This enables support for Cavium's Thunder Family of SoCs.
> +
>  config ARCH_VEXPRESS
>  	bool "ARMv8 software model (Versatile Express)"
>  	select ARCH_REQUIRE_GPIOLIB
> @@ -256,6 +261,7 @@ config NR_CPUS
>  	range 2 32
>  	depends on SMP
>  	# These have to remain sorted largest to smallest
> +	default "32" if ARCH_THUNDER
>  	default "8"

Why do you need ARCH_THUNDER?  If it's just to change this default,
please don't bother - we don't do this kind of thing on x86, so why
should it be done here?  Just ensure that NR_CPUS is appropriately
adjusted.  Alternatively, look at how x86 deals with this (with
X86_BIGSMP / MAXSMP).

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Robert Richter]

On 05.09.14 10:32:40, Russell King - ARM Linux wrote:
> On Fri, Sep 05, 2014 at 09:46:42AM +0200, Robert Richter wrote:
> > From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > 
> > Increase maximum numbers of cpus to 32. This relates to current
> > maximal possible cpu number. Increasing this to 64 cpus will be a
> > separate patch not part of this enablement patches.
> > 
> > Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > Signed-off-by: Robert Richter <rrichter@cavium.com>
> > ---
> >  arch/arm64/Kconfig | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index fd4e81a4e1ce..77fb82b0f684 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -134,6 +134,11 @@ source "kernel/Kconfig.freezer"
> >  
> >  menu "Platform selection"
> >  
> > +config ARCH_THUNDER
> > +	bool "Cavium Inc. Thunder SoC Family"
> > +	help
> > +	  This enables support for Cavium's Thunder Family of SoCs.
> > +
> >  config ARCH_VEXPRESS
> >  	bool "ARMv8 software model (Versatile Express)"
> >  	select ARCH_REQUIRE_GPIOLIB
> > @@ -256,6 +261,7 @@ config NR_CPUS
> >  	range 2 32
> >  	depends on SMP
> >  	# These have to remain sorted largest to smallest
> > +	default "32" if ARCH_THUNDER
> >  	default "8"
> 
> Why do you need ARCH_THUNDER?  If it's just to change this default,

No, we need it just to enable all our drivers on the SoC. We want to
enable the SoC by using defconfig + ARCH_THUNDER. As said in my other
mail, I put it here to be able to base all other thunder driver patch
sets on this initial base patch set. Otherwise this particular patch
and also the dtb patch need to be shipped with all other driver patch
sets. This might lead to duplicate submissions of the same patch.

With doing defconfig + ARCH_THUNDER we also want to enable the max
number of cpus that is currently supported. I only enable 32 cpus
since booting more cpus is untested. There might be problems at the 32
cpu boundary. Just setting it to 64 does not mean a kernel will
actually boot more than 32 cpus. But if it will be ack'ed, I would be
fine to set NR_CPUS to 32 or 64 in general and independent from
ARCH_THUNDER.

For simplicity I better drop setting NR_CPUS in this patch.

-Robert

> please don't bother - we don't do this kind of thing on x86, so why
> should it be done here?  Just ensure that NR_CPUS is appropriately
> adjusted.  Alternatively, look at how x86 deals with this (with
> X86_BIGSMP / MAXSMP).

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Russell King - ARM Linux]

On Fri, Sep 05, 2014 at 12:45:47PM +0200, Robert Richter wrote:
> On 05.09.14 10:32:40, Russell King - ARM Linux wrote:
> > On Fri, Sep 05, 2014 at 09:46:42AM +0200, Robert Richter wrote:
> > > From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > > 
> > > Increase maximum numbers of cpus to 32. This relates to current
> > > maximal possible cpu number. Increasing this to 64 cpus will be a
> > > separate patch not part of this enablement patches.
> > > 
> > > Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > > Signed-off-by: Robert Richter <rrichter@cavium.com>
> > > ---
> > >  arch/arm64/Kconfig | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index fd4e81a4e1ce..77fb82b0f684 100644
> > > --- a/arch/arm64/Kconfig
> > > +++ b/arch/arm64/Kconfig
> > > @@ -134,6 +134,11 @@ source "kernel/Kconfig.freezer"
> > >  
> > >  menu "Platform selection"
> > >  
> > > +config ARCH_THUNDER
> > > +	bool "Cavium Inc. Thunder SoC Family"
> > > +	help
> > > +	  This enables support for Cavium's Thunder Family of SoCs.
> > > +
> > >  config ARCH_VEXPRESS
> > >  	bool "ARMv8 software model (Versatile Express)"
> > >  	select ARCH_REQUIRE_GPIOLIB
> > > @@ -256,6 +261,7 @@ config NR_CPUS
> > >  	range 2 32
> > >  	depends on SMP
> > >  	# These have to remain sorted largest to smallest
> > > +	default "32" if ARCH_THUNDER
> > >  	default "8"
> > 
> > Why do you need ARCH_THUNDER?  If it's just to change this default,
> 
> No, we need it just to enable all our drivers on the SoC. We want to
> enable the SoC by using defconfig + ARCH_THUNDER. As said in my other
> mail, I put it here to be able to base all other thunder driver patch
> sets on this initial base patch set. Otherwise this particular patch
> and also the dtb patch need to be shipped with all other driver patch
> sets. This might lead to duplicate submissions of the same patch.
> 
> With doing defconfig + ARCH_THUNDER we also want to enable the max
> number of cpus that is currently supported. I only enable 32 cpus
> since booting more cpus is untested. There might be problems at the 32
> cpu boundary. Just setting it to 64 does not mean a kernel will
> actually boot more than 32 cpus. But if it will be ack'ed, I would be
> fine to set NR_CPUS to 32 or 64 in general and independent from
> ARCH_THUNDER.
> 
> For simplicity I better drop setting NR_CPUS in this patch.

So, ARM64 will get a big long list of "config ARCH_foo" options just
to stuff lots of broken select statements into the configuration.  Yes,
this may have been the norm with ARM, but it's turned out to be more
of a problem than a solution, especially as it keeps causing Kconfig
warnings when things change in the rest of the kernel tree.

The same is true with defconfigs - Linus threatened to delete all ARM
defconfigs except one at one point.

As I said below, this isn't how stuff is dealt with on x86.

What I'm questioning here is the entire ethos of "have an ARCH_foo
configuration which sets stuff up for platform foo".

> > please don't bother - we don't do this kind of thing on x86, so why
> > should it be done here?  Just ensure that NR_CPUS is appropriately
> > adjusted.  Alternatively, look at how x86 deals with this (with
> > X86_BIGSMP / MAXSMP).

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Mark Rutland]

On Fri, Sep 05, 2014 at 12:05:52PM +0100, Russell King - ARM Linux wrote:
> On Fri, Sep 05, 2014 at 12:45:47PM +0200, Robert Richter wrote:
> > On 05.09.14 10:32:40, Russell King - ARM Linux wrote:
> > > On Fri, Sep 05, 2014 at 09:46:42AM +0200, Robert Richter wrote:
> > > > From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > > > 
> > > > Increase maximum numbers of cpus to 32. This relates to current
> > > > maximal possible cpu number. Increasing this to 64 cpus will be a
> > > > separate patch not part of this enablement patches.
> > > > 
> > > > Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > > > Signed-off-by: Robert Richter <rrichter@cavium.com>
> > > > ---
> > > >  arch/arm64/Kconfig | 6 ++++++
> > > >  1 file changed, 6 insertions(+)
> > > > 
> > > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > > index fd4e81a4e1ce..77fb82b0f684 100644
> > > > --- a/arch/arm64/Kconfig
> > > > +++ b/arch/arm64/Kconfig
> > > > @@ -134,6 +134,11 @@ source "kernel/Kconfig.freezer"
> > > >  
> > > >  menu "Platform selection"
> > > >  
> > > > +config ARCH_THUNDER
> > > > +	bool "Cavium Inc. Thunder SoC Family"
> > > > +	help
> > > > +	  This enables support for Cavium's Thunder Family of SoCs.
> > > > +
> > > >  config ARCH_VEXPRESS
> > > >  	bool "ARMv8 software model (Versatile Express)"
> > > >  	select ARCH_REQUIRE_GPIOLIB
> > > > @@ -256,6 +261,7 @@ config NR_CPUS
> > > >  	range 2 32
> > > >  	depends on SMP
> > > >  	# These have to remain sorted largest to smallest
> > > > +	default "32" if ARCH_THUNDER
> > > >  	default "8"
> > > 
> > > Why do you need ARCH_THUNDER?  If it's just to change this default,
> > 
> > No, we need it just to enable all our drivers on the SoC. We want to
> > enable the SoC by using defconfig + ARCH_THUNDER. As said in my other
> > mail, I put it here to be able to base all other thunder driver patch
> > sets on this initial base patch set. Otherwise this particular patch
> > and also the dtb patch need to be shipped with all other driver patch
> > sets. This might lead to duplicate submissions of the same patch.
> > 
> > With doing defconfig + ARCH_THUNDER we also want to enable the max
> > number of cpus that is currently supported. I only enable 32 cpus
> > since booting more cpus is untested. There might be problems at the 32
> > cpu boundary. Just setting it to 64 does not mean a kernel will
> > actually boot more than 32 cpus. But if it will be ack'ed, I would be
> > fine to set NR_CPUS to 32 or 64 in general and independent from
> > ARCH_THUNDER.
> > 
> > For simplicity I better drop setting NR_CPUS in this patch.
> 
> So, ARM64 will get a big long list of "config ARCH_foo" options just
> to stuff lots of broken select statements into the configuration.  Yes,
> this may have been the norm with ARM, but it's turned out to be more
> of a problem than a solution, especially as it keeps causing Kconfig
> warnings when things change in the rest of the kernel tree.

Agreed; this seems more pain than it is worth.

> The same is true with defconfigs - Linus threatened to delete all ARM
> defconfigs except one at one point.

IMO we should continue doing what we've done so far and make the ARM64
defconfig work on everything it can by default, no ARCH_* necessary.
That's what most people will build and test and we shouldn't get
platform-specific code (well, drivers) breaking the single image.

For the extreme configurations (really tiny or really big) custom
configuration being necessary is fine. That doesn't have to involve
ARCH_* config options.

If you want to build a custom config then you should have an idea of
what you need. ARCH_* options are only necessary if someone wants a
kernel tuned for a specific SoC but doesn't know anything about that
SoC.

Mark.

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Arnd Bergmann]

On Friday 05 September 2014 13:51:47 Mark Rutland wrote:
> On Fri, Sep 05, 2014 at 12:05:52PM +0100, Russell King - ARM Linux wrote:
> > On Fri, Sep 05, 2014 at 12:45:47PM +0200, Robert Richter wrote:
> > > On 05.09.14 10:32:40, Russell King - ARM Linux wrote:
> > > No, we need it just to enable all our drivers on the SoC. We want to
> > > enable the SoC by using defconfig + ARCH_THUNDER. As said in my other
> > > mail, I put it here to be able to base all other thunder driver patch
> > > sets on this initial base patch set. Otherwise this particular patch
> > > and also the dtb patch need to be shipped with all other driver patch
> > > sets. This might lead to duplicate submissions of the same patch.
> > > 
> > > With doing defconfig + ARCH_THUNDER we also want to enable the max
> > > number of cpus that is currently supported. I only enable 32 cpus
> > > since booting more cpus is untested. There might be problems at the 32
> > > cpu boundary. Just setting it to 64 does not mean a kernel will
> > > actually boot more than 32 cpus. But if it will be ack'ed, I would be
> > > fine to set NR_CPUS to 32 or 64 in general and independent from
> > > ARCH_THUNDER.
> > > 
> > > For simplicity I better drop setting NR_CPUS in this patch.
> > 
> > So, ARM64 will get a big long list of "config ARCH_foo" options just
> > to stuff lots of broken select statements into the configuration.  Yes,
> > this may have been the norm with ARM, but it's turned out to be more
> > of a problem than a solution, especially as it keeps causing Kconfig
> > warnings when things change in the rest of the kernel tree.
> 
> Agreed; this seems more pain than it is worth.

Lots of select statements indeed would be a problem, but I don't think
that is what Robert was suggesting.

> > The same is true with defconfigs - Linus threatened to delete all ARM
> > defconfigs except one at one point.
> 
> IMO we should continue doing what we've done so far and make the ARM64
> defconfig work on everything it can by default, no ARCH_* necessary.
> That's what most people will build and test and we shouldn't get
> platform-specific code (well, drivers) breaking the single image.

Right.

> For the extreme configurations (really tiny or really big) custom
> configuration being necessary is fine. That doesn't have to involve
> ARCH_* config options.
> 
> If you want to build a custom config then you should have an idea of
> what you need. ARCH_* options are only necessary if someone wants a
> kernel tuned for a specific SoC but doesn't know anything about that
> SoC.

A common pattern these days is to do dependencies like

arch/*/Kconfig:
	config ARCH_FOO
	bool "Enable support for Foo platform"
	help
	  ...


drivers/*/Kconfig
	config SUBSYS_FOO
	bool "SUBSYS driver for Foo"
	depends on ARCH_FOO || COMPILE_TEST
	depends on OF && REGULATOR && GENERIC_PHY # or whatever

That way we can enable everything in the defconfig, but someone
who likes to build a more specialized kernel can disable the
other platforms and won't get the drivers that are specific to
those.

I personally think this is a bit more verbose than what we need, but
I don't strongly object doing it that way.

The code size really should not matter much on ARM64 though: it's
unlikely we will see a lot of systems with less than a few gigabytes
of memory, and I expect that a generic kernel would be e.g. 6 MB
instead of 4 MB for a platform specific kernel.

	Arnd

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Mark Rutland]

Hi Arnd,

[...]

> A common pattern these days is to do dependencies like
> 
> arch/*/Kconfig:
> 	config ARCH_FOO
> 	bool "Enable support for Foo platform"
> 	help
> 	  ...
> 
> 
> drivers/*/Kconfig
> 	config SUBSYS_FOO
> 	bool "SUBSYS driver for Foo"
> 	depends on ARCH_FOO || COMPILE_TEST
> 	depends on OF && REGULATOR && GENERIC_PHY # or whatever

Russell's comments w.r.t. Kconfig warnings when config names change
still holds regardless of select vs depends on.

> That way we can enable everything in the defconfig, but someone
> who likes to build a more specialized kernel can disable the
> other platforms and won't get the drivers that are specific to
> those.
> 
> I personally think this is a bit more verbose than what we need, but
> I don't strongly object doing it that way.

You'd still be able to do this without ARCH_FOO, though you would need
to know which drivers are necessary for a particular SoC. That seems to
be the way things are handled on x86; I don't recall having to select
support for specific machines there, just the individual drivers.

> The code size really should not matter much on ARM64 though: it's
> unlikely we will see a lot of systems with less than a few gigabytes
> of memory, and I expect that a generic kernel would be e.g. 6 MB
> instead of 4 MB for a platform specific kernel.

Agreed. If there kernel size begins looking unwieldy we either need to
be compiling more things as modules or a more drastic kernel weight loss
program.

Mark.

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Arnd Bergmann]

On Friday 05 September 2014 15:22:46 Mark Rutland wrote:
> 
> > A common pattern these days is to do dependencies like
> > 
> > arch/*/Kconfig:
> >       config ARCH_FOO
> >       bool "Enable support for Foo platform"
> >       help
> >         ...
> > 
> > 
> > drivers/*/Kconfig
> >       config SUBSYS_FOO
> >       bool "SUBSYS driver for Foo"
> >       depends on ARCH_FOO || COMPILE_TEST
> >       depends on OF && REGULATOR && GENERIC_PHY # or whatever
> 
> Russell's comments w.r.t. Kconfig warnings when config names change
> still holds regardless of select vs depends on.

Yes, that's what I wrote in my reply as well.

> > That way we can enable everything in the defconfig, but someone
> > who likes to build a more specialized kernel can disable the
> > other platforms and won't get the drivers that are specific to
> > those.
> > 
> > I personally think this is a bit more verbose than what we need, but
> > I don't strongly object doing it that way.
> 
> You'd still be able to do this without ARCH_FOO, though you would need
> to know which drivers are necessary for a particular SoC. That seems to
> be the way things are handled on x86; I don't recall having to select
> support for specific machines there, just the individual drivers.

The main difference is that there are very few drivers on x86 that are
specific to one of the two chip makers. Almost everything is a PCI
device that can actually be plugged in anywhere.

On ARM64 there is going to be a lot of stuff that really makes sense
only for one of the 50 licensees.

	Arnd

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Robert Richter]

On 05.09.14 18:25:35, Arnd Bergmann wrote:
> On Friday 05 September 2014 15:22:46 Mark Rutland wrote:
> > 
> > > A common pattern these days is to do dependencies like
> > > 
> > > arch/*/Kconfig:
> > >       config ARCH_FOO
> > >       bool "Enable support for Foo platform"
> > >       help
> > >         ...
> > > 
> > > 
> > > drivers/*/Kconfig
> > >       config SUBSYS_FOO
> > >       bool "SUBSYS driver for Foo"
> > >       depends on ARCH_FOO || COMPILE_TEST
> > >       depends on OF && REGULATOR && GENERIC_PHY # or whatever
> >
> > Russell's comments w.r.t. Kconfig warnings when config names change
> > still holds regardless of select vs depends on.
> 
> Yes, that's what I wrote in my reply as well.
> 
> > > That way we can enable everything in the defconfig, but someone
> > > who likes to build a more specialized kernel can disable the
> > > other platforms and won't get the drivers that are specific to
> > > those.
> > > 
> > > I personally think this is a bit more verbose than what we need, but
> > > I don't strongly object doing it that way.
> > 
> > You'd still be able to do this without ARCH_FOO, though you would need
> > to know which drivers are necessary for a particular SoC. That seems to
> > be the way things are handled on x86; I don't recall having to select
> > support for specific machines there, just the individual drivers.

This is well hidden on x86, but each vendor has a config option. For
AMD systems we have had our own option to disable vendor specific
code, see CPU_SUP_AMD for example. Disabling this will remove all AMD
specific code in the kernel. Of course this is enabled per default.

With ARCH_THUNDER I intended to do the same (you could name this also
SOC_SUP_CAVIUM or so but I kept the current naming scheme). In patch
4/4 I have added the option to defconfig. This enables this per
default and nobody has to deal with any option manually, just running
make defconfig is fine.

Also, at least to disable building the dtb file for foo, you will need
ARCH_FOO too. How else would you deal with dtb files then?

Having ARCH_FOO might not be necessary for drivers. One could enable
drivers manually, but this option is still a good reference for the
drivers needed by foo. At some point you will carry tons of enabled
drivers in your defconfig and you don't know which platform actually
is using it. For generic drivers this might be fine.  But in my point
of few, each soc specific driver should have an soc specific option
too. Then you easily can remove an soc from the defconfig.

-Robert

> The main difference is that there are very few drivers on x86 that are
> specific to one of the two chip makers. Almost everything is a PCI
> device that can actually be plugged in anywhere.
> 
> On ARM64 there is going to be a lot of stuff that really makes sense
> only for one of the 50 licensees.

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Arnd Bergmann]

On Monday 08 September 2014 13:01:31 Robert Richter wrote:
> This is well hidden on x86, but each vendor has a config option. For
> AMD systems we have had our own option to disable vendor specific
> code, see CPU_SUP_AMD for example. Disabling this will remove all AMD
> specific code in the kernel. Of course this is enabled per default.
> 
> With ARCH_THUNDER I intended to do the same (you could name this also
> SOC_SUP_CAVIUM or so but I kept the current naming scheme). In patch
> 4/4 I have added the option to defconfig. This enables this per
> default and nobody has to deal with any option manually, just running
> make defconfig is fine.
> 
> Also, at least to disable building the dtb file for foo, you will need
> ARCH_FOO too. How else would you deal with dtb files then?

The only alternative I see is to build them all.

> Having ARCH_FOO might not be necessary for drivers. One could enable
> drivers manually, but this option is still a good reference for the
> drivers needed by foo. At some point you will carry tons of enabled
> drivers in your defconfig and you don't know which platform actually
> is using it. For generic drivers this might be fine.  But in my point
> of few, each soc specific driver should have an soc specific option
> too. Then you easily can remove an soc from the defconfig.

Yes, that's what I had in my example.

	Arnd

[PATCH v2 1/4] arm64, thunder: Add Kconfig option for Cavium Thunder SoC Family

[Rob Herring]

On Mon, Sep 8, 2014 at 6:01 AM, Robert Richter <rric@kernel.org> wrote:
> On 05.09.14 18:25:35, Arnd Bergmann wrote:
>> On Friday 05 September 2014 15:22:46 Mark Rutland wrote:
>> >
>> > > A common pattern these days is to do dependencies like
>> > >
>> > > arch/*/Kconfig:
>> > >       config ARCH_FOO
>> > >       bool "Enable support for Foo platform"
>> > >       help
>> > >         ...
>> > >
>> > >
>> > > drivers/*/Kconfig
>> > >       config SUBSYS_FOO
>> > >       bool "SUBSYS driver for Foo"
>> > >       depends on ARCH_FOO || COMPILE_TEST
>> > >       depends on OF && REGULATOR && GENERIC_PHY # or whatever
>> >
>> > Russell's comments w.r.t. Kconfig warnings when config names change
>> > still holds regardless of select vs depends on.
>>
>> Yes, that's what I wrote in my reply as well.
>>
>> > > That way we can enable everything in the defconfig, but someone
>> > > who likes to build a more specialized kernel can disable the
>> > > other platforms and won't get the drivers that are specific to
>> > > those.
>> > >
>> > > I personally think this is a bit more verbose than what we need, but
>> > > I don't strongly object doing it that way.
>> >
>> > You'd still be able to do this without ARCH_FOO, though you would need
>> > to know which drivers are necessary for a particular SoC. That seems to
>> > be the way things are handled on x86; I don't recall having to select
>> > support for specific machines there, just the individual drivers.
>
> This is well hidden on x86, but each vendor has a config option. For
> AMD systems we have had our own option to disable vendor specific
> code, see CPU_SUP_AMD for example. Disabling this will remove all AMD
> specific code in the kernel. Of course this is enabled per default.
>
> With ARCH_THUNDER I intended to do the same (you could name this also
> SOC_SUP_CAVIUM or so but I kept the current naming scheme). In patch
> 4/4 I have added the option to defconfig. This enables this per
> default and nobody has to deal with any option manually, just running
> make defconfig is fine.
>
> Also, at least to disable building the dtb file for foo, you will need
> ARCH_FOO too. How else would you deal with dtb files then?

dtb builds are quick and don't affect the image size at all.
Personally, I would prefer to see all dtb's get built for the dtbs
rule. You can still specify the specific dtb you want in the case of
only caring about 1 platform.

Rob

[PATCH v2 2/4] arm64, thunder: Add initial dts for Cavium Thunder SoC

[Robert Richter]

From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>

Add initial device tree nodes for Cavium Thunder SoCs with support of
48 cores and gicv3. The dts file requires further changes, esp. for
pci, gicv3-its and smmu. This changes will be added later together
with the device drivers.

Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
 arch/arm64/boot/dts/Makefile         |   1 +
 arch/arm64/boot/dts/thunder-88xx.dts | 414 +++++++++++++++++++++++++++++++++++
 2 files changed, 415 insertions(+)
 create mode 100644 arch/arm64/boot/dts/thunder-88xx.dts

diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index c52bdb051f66..f8001a62029c 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,3 +1,4 @@
+dtb-$(CONFIG_ARCH_THUNDER) += thunder-88xx.dtb
 dtb-$(CONFIG_ARCH_VEXPRESS) += rtsm_ve-aemv8a.dtb foundation-v8.dtb
 dtb-$(CONFIG_ARCH_XGENE) += apm-mustang.dtb
 
diff --git a/arch/arm64/boot/dts/thunder-88xx.dts b/arch/arm64/boot/dts/thunder-88xx.dts
new file mode 100644
index 000000000000..4cc1d059d2d9
--- /dev/null
+++ b/arch/arm64/boot/dts/thunder-88xx.dts
@@ -0,0 +1,414 @@
+/*
+ * Cavium Thunder DTS file
+ *
+ * Copyright (C) 2014, Cavium Inc.
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ *     modify it under the terms of the GNU General Public License as
+ *     published by the Free Software Foundation; either version 2 of the
+ *     License, or (at your option) any later version.
+ *
+ *     This library is distributed in the hope that it will be useful,
+ *     but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *     GNU General Public License for more details.
+ *
+ *     You should have received a copy of the GNU General Public
+ *     License along with this library; if not, write to the Free
+ *     Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ *     MA 02110-1301 USA
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ *     obtaining a copy of this software and associated documentation
+ *     files (the "Software"), to deal in the Software without
+ *     restriction, including without limitation the rights to use,
+ *     copy, modify, merge, publish, distribute, sublicense, and/or
+ *     sell copies of the Software, and to permit persons to whom the
+ *     Software is furnished to do so, subject to the following
+ *     conditions:
+ *
+ *     The above copyright notice and this permission notice shall be
+ *     included in all copies or substantial portions of the Software.
+ *
+ *     THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ *     EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ *     OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ *     NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ *     HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ *     WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ *     FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ *     OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+/ {
+	model = "Cavium ThunderX CN88XX Family";
+	compatible = "cavium,thunder-88xx";
+	interrupt-parent = <&gic0>;
+	#address-cells = <2>;
+	#size-cells = <2>;
+
+	aliases {
+		serial0 = &uaa0;
+		serial1 = &uaa1;
+	};
+
+	psci {
+		compatible = "arm,psci-0.2";
+		method = "smc";
+	};
+
+	cpus {
+		#address-cells = <2>;
+		#size-cells = <0>;
+
+		cpu at 000 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x000>;
+			enable-method = "psci";
+		};
+		cpu at 001 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x001>;
+			enable-method = "psci";
+		};
+		cpu at 002 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x002>;
+			enable-method = "psci";
+		};
+		cpu at 003 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x003>;
+			enable-method = "psci";
+		};
+		cpu at 004 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x004>;
+			enable-method = "psci";
+		};
+		cpu at 005 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x005>;
+			enable-method = "psci";
+		};
+		cpu at 006 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x006>;
+			enable-method = "psci";
+		};
+		cpu at 007 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x007>;
+			enable-method = "psci";
+		};
+		cpu at 008 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x008>;
+			enable-method = "psci";
+		};
+		cpu at 009 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x009>;
+			enable-method = "psci";
+		};
+		cpu at 00a {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x00a>;
+			enable-method = "psci";
+		};
+		cpu at 00b {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x00b>;
+			enable-method = "psci";
+		};
+		cpu at 00c {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x00c>;
+			enable-method = "psci";
+		};
+		cpu at 00d {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x00d>;
+			enable-method = "psci";
+		};
+		cpu at 00e {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x00e>;
+			enable-method = "psci";
+		};
+		cpu at 00f {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x00f>;
+			enable-method = "psci";
+		};
+		cpu at 100 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x100>;
+			enable-method = "psci";
+		};
+		cpu at 101 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x101>;
+			enable-method = "psci";
+		};
+		cpu at 102 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x102>;
+			enable-method = "psci";
+		};
+		cpu at 103 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x103>;
+			enable-method = "psci";
+		};
+		cpu at 104 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x104>;
+			enable-method = "psci";
+		};
+		cpu at 105 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x105>;
+			enable-method = "psci";
+		};
+		cpu at 106 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x106>;
+			enable-method = "psci";
+		};
+		cpu at 107 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x107>;
+			enable-method = "psci";
+		};
+		cpu at 108 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x108>;
+			enable-method = "psci";
+		};
+		cpu at 109 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x109>;
+			enable-method = "psci";
+		};
+		cpu at 10a {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10a>;
+			enable-method = "psci";
+		};
+		cpu at 10b {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10b>;
+			enable-method = "psci";
+		};
+		cpu at 10c {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10c>;
+			enable-method = "psci";
+		};
+		cpu at 10d {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10d>;
+			enable-method = "psci";
+		};
+		cpu at 10e {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10e>;
+			enable-method = "psci";
+		};
+		cpu at 10f {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x10f>;
+			enable-method = "psci";
+		};
+		cpu at 200 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x200>;
+			enable-method = "psci";
+		};
+		cpu at 201 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x201>;
+			enable-method = "psci";
+		};
+		cpu at 202 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x202>;
+			enable-method = "psci";
+		};
+		cpu at 203 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x203>;
+			enable-method = "psci";
+		};
+		cpu at 204 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x204>;
+			enable-method = "psci";
+		};
+		cpu at 205 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x205>;
+			enable-method = "psci";
+		};
+		cpu at 206 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x206>;
+			enable-method = "psci";
+		};
+		cpu at 207 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x207>;
+			enable-method = "psci";
+		};
+		cpu at 208 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x208>;
+			enable-method = "psci";
+		};
+		cpu at 209 {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x209>;
+			enable-method = "psci";
+		};
+		cpu at 20a {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x20a>;
+			enable-method = "psci";
+		};
+		cpu at 20b {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x20b>;
+			enable-method = "psci";
+		};
+		cpu at 20c {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x20c>;
+			enable-method = "psci";
+		};
+		cpu at 20d {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x20d>;
+			enable-method = "psci";
+		};
+		cpu at 20e {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x20e>;
+			enable-method = "psci";
+		};
+		cpu at 20f {
+			device_type = "cpu";
+			compatible = "cavium,thunder", "arm,armv8";
+			reg = <0x0 0x20f>;
+			enable-method = "psci";
+		};
+	};
+
+	memory at 00000000 {
+		device_type = "memory";
+		reg = <0x0 0x00000000 0x0 0x80000000>;
+	};
+
+	timer {
+		compatible = "arm,armv8-timer";
+		interrupts = <1 13 0xff01>,
+		             <1 14 0xff01>,
+		             <1 11 0xff01>,
+		             <1 10 0xff01>;
+	};
+
+	soc {
+		compatible = "simple-bus";
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		refclk50mhz: refclk50mhz {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <50000000>;
+			clock-output-names = "refclk50mhz";
+		};
+
+		gic0: interrupt-controller at 8010,00000000 {
+			compatible = "arm,gic-v3";
+			#interrupt-cells = <3>;
+			interrupt-controller;
+			reg = <0x8010 0x00000000 0x0 0x010000>, /* GICD */
+			      <0x8010 0x80000000 0x0 0x200000>; /* GICR */
+			interrupts = <1 9 0xf04>;
+		};
+
+		uaa0: serial at 87e0,24000000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x87e0 0x24000000 0x0 0x1000>;
+			interrupts = <1 21 4>;
+			clocks = <&refclk50mhz>;
+			clock-names = "apb_pclk";
+		};
+
+		uaa1: serial at 87e0,25000000 {
+			compatible = "arm,pl011", "arm,primecell";
+			reg = <0x87e0 0x25000000 0x0 0x1000>;
+			interrupts = <1 22 4>;
+			clocks = <&refclk50mhz>;
+			clock-names = "apb_pclk";
+		};
+	};
+};
-- 
2.0.1

[PATCH v2 2/4] arm64, thunder: Add initial dts for Cavium Thunder SoC

[Arnd Bergmann]

On Friday 05 September 2014 09:46:43 Robert Richter wrote:
> diff --git a/arch/arm64/boot/dts/thunder-88xx.dts b/arch/arm64/boot/dts/thunder-88xx.dts
> new file mode 100644
> index 000000000000..4cc1d059d2d9
> --- /dev/null
> +++ b/arch/arm64/boot/dts/thunder-88xx.dts

Most people end up having a soc.dtsi file and a board.dsi file including
the former and adding the machine-specific properties.

It is likely that you will end up needing the same, so you might want to
start that way.

> +/ {
> +	model = "Cavium ThunderX CN88XX Family";
> +	compatible = "cavium,thunder-88xx";

As mentioned by Mark already, you should not include 'xx' in the
compatible string, but instead use the real soc ID.

Normally, each SoC has some slight differences anyway, so you would
override these in the specialized dtsi file.

The "model" property should go into the board specific file.

> +	interrupt-parent = <&gic0>;
> +	#address-cells = <2>;
> +	#size-cells = <2>;
> +
> +	aliases {
> +		serial0 = &uaa0;
> +		serial1 = &uaa1;
> +	};
> +
> +	psci {
> +		compatible = "arm,psci-0.2";
> +		method = "smc";
> +	};

The aliases node should go into the board file as well, since it's
possible that e.g. the first uart is not connected and you need
something like

	aliases {
		serial0 = &uaa1;
	};

The psci node (according to a discussion we just had for the freescale
dts files) should ideally get filled out by the boot loader that
implements the psci code, to ensure the version matches.

> +
> +	memory at 00000000 {
> +		device_type = "memory";
> +		reg = <0x0 0x00000000 0x0 0x80000000>;
> +	};

memory should also go into the board specific file, or get filled by
the boot loader if it is detected at boot time and user serviceable.

I assume that your machines have NUMA properties, in that case it
makes sense to split up the memory device nodes by topology. I think
there are some standard properties to describe the topology further,
but I don't remember how it's done at the moment.

> +	soc {
> +		compatible = "simple-bus";
> +		#address-cells = <2>;
> +		#size-cells = <2>;
> +		ranges;
> +
> +		refclk50mhz: refclk50mhz {
> +			compatible = "fixed-clock";
> +			#clock-cells = <0>;
> +			clock-frequency = <50000000>;
> +			clock-output-names = "refclk50mhz";
> +		};

If the reference clock is generated outside of the SoC, I would put the device
node for it on the top level.

	Arnd

[PATCH v2 2/4] arm64, thunder: Add initial dts for Cavium Thunder SoC

[Robert Richter]

Arnd,

On 05.09.14 13:21:48, Arnd Bergmann wrote:
> On Friday 05 September 2014 09:46:43 Robert Richter wrote:
> > diff --git a/arch/arm64/boot/dts/thunder-88xx.dts b/arch/arm64/boot/dts/thunder-88xx.dts
> > new file mode 100644
> > index 000000000000..4cc1d059d2d9
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/thunder-88xx.dts
> 
> Most people end up having a soc.dtsi file and a board.dsi file including
> the former and adding the machine-specific properties.

thanks for your feedback on the dts file. I already included your
suggestion into the patches and split the files.

-Robert

[PATCH v2 3/4] arm64, thunder: Document devicetree bindings for Cavium Thunder SoC

[Robert Richter]

From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>

This patch adds documentation for the devicetree bindings used by the
DT files of Cavium Thunder SoC platforms.

Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
Signed-off-by: Robert Richter <rrichter@cavium.com>
---
 Documentation/devicetree/bindings/arm/cavium-thunder.txt | 10 ++++++++++
 Documentation/devicetree/bindings/arm/cpus.txt           |  1 +
 2 files changed, 11 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/cavium-thunder.txt

diff --git a/Documentation/devicetree/bindings/arm/cavium-thunder.txt b/Documentation/devicetree/bindings/arm/cavium-thunder.txt
new file mode 100644
index 000000000000..6f63a5866902
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cavium-thunder.txt
@@ -0,0 +1,10 @@
+Cavium Thunder platform device tree bindings
+--------------------------------------------
+
+Boards with Cavium's Thunder SoC shall have following properties.
+
+Root Node
+---------
+Required root node properties:
+
+  - compatible = "cavium,thunder-88xx";
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 298e2f6b33c6..578796a2cfa9 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -166,6 +166,7 @@ nodes to be present and contain the properties described below.
 			    "arm,cortex-r5"
 			    "arm,cortex-r7"
 			    "brcm,brahma-b15"
+			    "cavium,thunder"
 			    "faraday,fa526"
 			    "intel,sa110"
 			    "intel,sa1100"
-- 
2.0.1

[PATCH v2 3/4] arm64, thunder: Document devicetree bindings for Cavium Thunder SoC

[Will Deacon]

On Fri, Sep 05, 2014 at 08:46:44AM +0100, Robert Richter wrote:
> From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> 
> This patch adds documentation for the devicetree bindings used by the
> DT files of Cavium Thunder SoC platforms.
> 
> Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> Signed-off-by: Robert Richter <rrichter@cavium.com>
> ---
>  Documentation/devicetree/bindings/arm/cavium-thunder.txt | 10 ++++++++++
>  Documentation/devicetree/bindings/arm/cpus.txt           |  1 +
>  2 files changed, 11 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/cavium-thunder.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/cavium-thunder.txt b/Documentation/devicetree/bindings/arm/cavium-thunder.txt
> new file mode 100644
> index 000000000000..6f63a5866902
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/cavium-thunder.txt
> @@ -0,0 +1,10 @@
> +Cavium Thunder platform device tree bindings
> +--------------------------------------------
> +
> +Boards with Cavium's Thunder SoC shall have following properties.
> +
> +Root Node
> +---------
> +Required root node properties:
> +
> +  - compatible = "cavium,thunder-88xx";

Is this file necessary? We don't have one for xgene afaict.

Will

[PATCH v2 3/4] arm64, thunder: Document devicetree bindings for Cavium Thunder SoC

[Robert Richter]

On 05.09.14 09:42:00, Will Deacon wrote:
> On Fri, Sep 05, 2014 at 08:46:44AM +0100, Robert Richter wrote:
> > From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > 
> > This patch adds documentation for the devicetree bindings used by the
> > DT files of Cavium Thunder SoC platforms.
> > 
> > Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > Signed-off-by: Robert Richter <rrichter@cavium.com>
> > ---
> >  Documentation/devicetree/bindings/arm/cavium-thunder.txt | 10 ++++++++++
> >  Documentation/devicetree/bindings/arm/cpus.txt           |  1 +
> >  2 files changed, 11 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/arm/cavium-thunder.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/cavium-thunder.txt b/Documentation/devicetree/bindings/arm/cavium-thunder.txt
> > new file mode 100644
> > index 000000000000..6f63a5866902
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/cavium-thunder.txt
> > @@ -0,0 +1,10 @@
> > +Cavium Thunder platform device tree bindings
> > +--------------------------------------------
> > +
> > +Boards with Cavium's Thunder SoC shall have following properties.
> > +
> > +Root Node
> > +---------
> > +Required root node properties:
> > +
> > +  - compatible = "cavium,thunder-88xx";
> 
> Is this file necessary? We don't have one for xgene afaict.

Hmm, looking at Documentation/devicetree/bindings/arm/calxeda.txt
there is something similar.

I am fine with both, keeping or removing it.

Would leave this to the DT maintainers.

-Robert

[PATCH v2 3/4] arm64, thunder: Document devicetree bindings for Cavium Thunder SoC

[Mark Rutland]

On Fri, Sep 05, 2014 at 10:32:22AM +0100, Robert Richter wrote:
> On 05.09.14 09:42:00, Will Deacon wrote:
> > On Fri, Sep 05, 2014 at 08:46:44AM +0100, Robert Richter wrote:
> > > From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > > 
> > > This patch adds documentation for the devicetree bindings used by the
> > > DT files of Cavium Thunder SoC platforms.
> > > 
> > > Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > > Signed-off-by: Robert Richter <rrichter@cavium.com>
> > > ---
> > >  Documentation/devicetree/bindings/arm/cavium-thunder.txt | 10 ++++++++++
> > >  Documentation/devicetree/bindings/arm/cpus.txt           |  1 +
> > >  2 files changed, 11 insertions(+)
> > >  create mode 100644 Documentation/devicetree/bindings/arm/cavium-thunder.txt
> > > 
> > > diff --git a/Documentation/devicetree/bindings/arm/cavium-thunder.txt b/Documentation/devicetree/bindings/arm/cavium-thunder.txt
> > > new file mode 100644
> > > index 000000000000..6f63a5866902
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/arm/cavium-thunder.txt
> > > @@ -0,0 +1,10 @@
> > > +Cavium Thunder platform device tree bindings
> > > +--------------------------------------------
> > > +
> > > +Boards with Cavium's Thunder SoC shall have following properties.
> > > +
> > > +Root Node
> > > +---------
> > > +Required root node properties:
> > > +
> > > +  - compatible = "cavium,thunder-88xx";
> > 
> > Is this file necessary? We don't have one for xgene afaict.
> 
> Hmm, looking at Documentation/devicetree/bindings/arm/calxeda.txt
> there is something similar.
> 
> I am fine with both, keeping or removing it.
> 
> Would leave this to the DT maintainers.

Having a required root node compatible is fine, though I would only
expect it to be necessary for errata workarounds if we have no other way
of detecting things.

That said, compatible strings shouldn't have wildcards, so
"cavium,thunder-88xx" should be replaced with something more specific.
Later boards can claim compatibility with that (but should have their
own strings too).

Mark.

[PATCH v2 3/4] arm64, thunder: Document devicetree bindings for Cavium Thunder SoC

[Robert Richter]

On 05.09.14 10:39:33, Mark Rutland wrote:
> On Fri, Sep 05, 2014 at 10:32:22AM +0100, Robert Richter wrote:
> > On 05.09.14 09:42:00, Will Deacon wrote:
> > > On Fri, Sep 05, 2014 at 08:46:44AM +0100, Robert Richter wrote:
> > > > From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > > > 
> > > > This patch adds documentation for the devicetree bindings used by the
> > > > DT files of Cavium Thunder SoC platforms.
> > > > 
> > > > Signed-off-by: Radha Mohan Chintakuntla <rchintakuntla@cavium.com>
> > > > Signed-off-by: Robert Richter <rrichter@cavium.com>
> > > > ---
> > > >  Documentation/devicetree/bindings/arm/cavium-thunder.txt | 10 ++++++++++
> > > >  Documentation/devicetree/bindings/arm/cpus.txt           |  1 +
> > > >  2 files changed, 11 insertions(+)
> > > >  create mode 100644 Documentation/devicetree/bindings/arm/cavium-thunder.txt
> > > > 
> > > > diff --git a/Documentation/devicetree/bindings/arm/cavium-thunder.txt b/Documentation/devicetree/bindings/arm/cavium-thunder.txt
> > > > new file mode 100644
> > > > index 000000000000..6f63a5866902
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/arm/cavium-thunder.txt
> > > > @@ -0,0 +1,10 @@
> > > > +Cavium Thunder platform device tree bindings
> > > > +--------------------------------------------
> > > > +
> > > > +Boards with Cavium's Thunder SoC shall have following properties.
> > > > +
> > > > +Root Node
> > > > +---------
> > > > +Required root node properties:
> > > > +
> > > > +  - compatible = "cavium,thunder-88xx";
> > > 
> > > Is this file necessary? We don't have one for xgene afaict.
> > 
> > Hmm, looking at Documentation/devicetree/bindings/arm/calxeda.txt
> > there is something similar.
> > 
> > I am fine with both, keeping or removing it.
> > 
> > Would leave this to the DT maintainers.
> 
> Having a required root node compatible is fine, though I would only
> expect it to be necessary for errata workarounds if we have no other way
> of detecting things.

Ok, will keep the change.

> That said, compatible strings shouldn't have wildcards, so
> "cavium,thunder-88xx" should be replaced with something more specific.
> Later boards can claim compatibility with that (but should have their
> own strings too).

88xx is not a wildcard for chips, there are no chips named 8800 or
whatever, instead we have e.g. 87xx. That said, 88xx is the specific
name of the soc and the first reference board. If there will be other
boards with the same soc, it should have its own name but should be
compatible with cavium,thunder-88xx. Later soc revisions will get a
different name than thunder-88xx for differentiation.

-Robert

[PATCH v2 4/4] arm64, defconfig: Enable Cavium Thunder SoC in defconfig

[Robert Richter]

From: Robert Richter <rrichter@cavium.com>

This patch enables Thunder SoCs in the arm64 defconfig. This is
esp. useful to add Thunder platforms to automated builds based on
arm64 defconfig.

Signed-off-by: Robert Richter <rrichter@cavium.com>
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d92ef3c54161..9cd37de9aa8d 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -32,6 +32,7 @@ CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
 # CONFIG_BLK_DEV_BSG is not set
 # CONFIG_IOSCHED_DEADLINE is not set
+CONFIG_ARCH_THUNDER=y
 CONFIG_ARCH_VEXPRESS=y
 CONFIG_ARCH_XGENE=y
 CONFIG_SMP=y
-- 
2.0.1

[PATCH v2 0/4] arm64, thunder: Enable Cavium Thunder SoC Family

[Will Deacon]

On Fri, Sep 05, 2014 at 08:46:41AM +0100, Robert Richter wrote:
> From: Robert Richter <rrichter@cavium.com>
> 
> This initial patches enable Cavium Thunder SoC Family. The patches add
> Kconfig and devicetree support and then add Thunder to the defconfig.
> 
> The Thunder system needs more enablement patches for subsystems and
> devices, this includes network, ahci, gicv3/gicv3-its, pci, smmu, kvm.
> We will send separate patch sets for these. All of them base on this
> initial patches.
> 
> I sent a separate patch set independently that introduces support for
> dts vendor subdirs. After both patch sets have been applied I will
> send a patch in addition that moves the dts file into a subdirectory.
> 
> Patches are available here:

If you can get some acks for the DT bits, I'm happy to take this via the
arm64 tree for 3.18.

Will