| Message ID | 1406732794-20920-3-git-send-email-rric@kernel.org |
|---|---|
| State | New |
| Headers | show |
Hi, On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert Richter wrote: > 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 | 387 +++++++++++++++++++++++++++++++++++ > 2 files changed, 388 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..4cf20ac9138b > --- /dev/null > +++ b/arch/arm64/boot/dts/thunder-88xx.dts > @@ -0,0 +1,387 @@ > +/* > + * Cavium Thunder DTS file > + * > + * Copyright (C) 2013, Cavium Inc. > + * > + * This program 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. > + */ > +/dts-v1/; > + > +/* Reserving first 12MB of DDR for firmware */ > +/memreserve/ 0x00000000 0x00c00000; What exactly is this memreserve intended to protect at runtime? The only item of runtime firmware I see in use below is PSCI on the secure side. How is the kernel booted on this platform? UEFI? > +/ { > + model = "Cavium ThunderX CN88XX Family"; > + compatible = "cavium,thunder-88xx"; Please don't use wildcards in compatible strings. Give this an absolute name, and override as necessary. > + interrupt-parent = <&gic0>; > + #address-cells = <2>; > + #size-cells = <2>; > + > + aliases { > + serial0 = &uaa0; > + serial1 = &uaa1; > + }; > + > + psci { > + compatible = "arm,psci-0.2"; > + method = "smc"; > + }; Nice! > + > + cpus { > + #address-cells = <2>; > + #size-cells = <0>; > + > + cpu@000 { > + device_type = "cpu"; > + compatible = "cavium,thunder", "arm,armv8"; > + reg = <0x0 0x000>; > + enable-method = "psci"; > + }; Just to check: both the SoC and CPU are called thunder? [...] > + > + memory@00000000 { > + device_type = "memory"; > + reg = <0x0 0x00000000 0x0 0x80000000>; > + }; > + > + gic0: interrupt-controller@801000000000 { To make this easier to read, please place a comma between 32-bit portions of the unit address (e.g. here have 8010,00000000). > + compatible = "arm,gic-v3"; > + #interrupt-cells = <3>; > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; This has no children, so why have ranges, #address-cells, and #size-cells? > + interrupt-controller; > + reg = <0x8010 0x00000000 0x0 0x010000>, /* GICD */ > + <0x8010 0x80000000 0x0 0x200000>; /* GICR */ > + interrupts = <1 9 0xf04>; > + }; > + > + 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; > + > + clocks { > + #address-cells = <2>; > + #size-cells = <2>; > + ranges; > + > + refclk50mhz: refclk50mhz { > + compatible = "fixed-clock"; > + #clock-cells = <0>; > + clock-frequency = <50000000>; > + clock-output-names = "refclk50mhz"; > + }; > + }; Please get rid of the clocks node and just put the clocks here. > + > + uaa0: serial@87e024000000 { > + compatible = "arm,pl011", "arm,primecell"; > + reg = <0x87e0 0x24000000 0x0 0x1000>; > + interrupts = <1 21 4>; > + clocks = <&refclk50mhz>; > + clock-names = "apb_pclk"; Is this actually the apb_pclk, or is the the uartclk? I assume it's the latter. > + }; > + > + uaa1: serial@87e025000000 { > + compatible = "arm,pl011", "arm,primecell"; > + reg = <0x87e0 0x25000000 0x0 0x1000>; > + interrupts = <1 22 4>; > + clocks = <&refclk50mhz>; > + clock-names = "apb_pclk"; Similarly? Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 30, 2014 at 10:46 AM, Mark Rutland <mark.rutland@arm.com> wrote: > Hi, > > On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert Richter wrote: >> 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 | 387 +++++++++++++++++++++++++++++++++++ >> 2 files changed, 388 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..4cf20ac9138b >> --- /dev/null >> +++ b/arch/arm64/boot/dts/thunder-88xx.dts >> @@ -0,0 +1,387 @@ >> +/* >> + * Cavium Thunder DTS file >> + * >> + * Copyright (C) 2013, Cavium Inc. >> + * >> + * This program 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. >> + */ You may want to reconsider if this should be BSD. >> +/dts-v1/; >> + >> +/* Reserving first 12MB of DDR for firmware */ >> +/memreserve/ 0x00000000 0x00c00000; > > What exactly is this memreserve intended to protect at runtime? > > The only item of runtime firmware I see in use below is PSCI on the > secure side. > > How is the kernel booted on this platform? UEFI? > >> +/ { >> + model = "Cavium ThunderX CN88XX Family"; >> + compatible = "cavium,thunder-88xx"; > > Please don't use wildcards in compatible strings. Give this an absolute > name, and override as necessary. > >> + interrupt-parent = <&gic0>; >> + #address-cells = <2>; >> + #size-cells = <2>; >> + >> + aliases { >> + serial0 = &uaa0; >> + serial1 = &uaa1; >> + }; >> + >> + psci { >> + compatible = "arm,psci-0.2"; >> + method = "smc"; >> + }; > > Nice! > >> + >> + cpus { >> + #address-cells = <2>; >> + #size-cells = <0>; >> + >> + cpu@000 { >> + device_type = "cpu"; >> + compatible = "cavium,thunder", "arm,armv8"; >> + reg = <0x0 0x000>; >> + enable-method = "psci"; >> + }; > > Just to check: both the SoC and CPU are called thunder? > > [...] > >> + >> + memory@00000000 { >> + device_type = "memory"; >> + reg = <0x0 0x00000000 0x0 0x80000000>; >> + }; >> + >> + gic0: interrupt-controller@801000000000 { > > To make this easier to read, please place a comma between 32-bit > portions of the unit address (e.g. here have 8010,00000000). Mark, perhaps a dtc or checkpatch.pl check for this? This should also be under a bus node. >> + compatible = "arm,gic-v3"; >> + #interrupt-cells = <3>; >> + #address-cells = <2>; >> + #size-cells = <2>; >> + ranges; > > This has no children, so why have ranges, #address-cells, and > #size-cells? > >> + interrupt-controller; >> + reg = <0x8010 0x00000000 0x0 0x010000>, /* GICD */ >> + <0x8010 0x80000000 0x0 0x200000>; /* GICR */ >> + interrupts = <1 9 0xf04>; >> + }; >> + >> + 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; >> + >> + clocks { >> + #address-cells = <2>; >> + #size-cells = <2>; >> + ranges; >> + >> + refclk50mhz: refclk50mhz { >> + compatible = "fixed-clock"; >> + #clock-cells = <0>; >> + clock-frequency = <50000000>; >> + clock-output-names = "refclk50mhz"; >> + }; >> + }; > > Please get rid of the clocks node and just put the clocks here. > >> + >> + uaa0: serial@87e024000000 { >> + compatible = "arm,pl011", "arm,primecell"; >> + reg = <0x87e0 0x24000000 0x0 0x1000>; >> + interrupts = <1 21 4>; >> + clocks = <&refclk50mhz>; >> + clock-names = "apb_pclk"; > > Is this actually the apb_pclk, or is the the uartclk? I assume it's the > latter. Shouldn't new bindings have both clocks here? A single clock was a mistake I think (mine in fact). Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 30, 2014 at 8:06 AM, Robert Richter <rric@kernel.org> wrote: > 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 | 387 +++++++++++++++++++++++++++++++++++ > 2 files changed, 388 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..4cf20ac9138b > --- /dev/null > +++ b/arch/arm64/boot/dts/thunder-88xx.dts > @@ -0,0 +1,387 @@ > +/* > + * Cavium Thunder DTS file > + * > + * Copyright (C) 2013, Cavium Inc. > + * > + * This program 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. > + */ > +/dts-v1/; > + > +/* Reserving first 12MB of DDR for firmware */ > +/memreserve/ 0x00000000 0x00c00000; > + > +/ { > + model = "Cavium ThunderX CN88XX Family"; > + compatible = "cavium,thunder-88xx"; Hmm. I take it this platform is compliant with some level of SBSA? We should probably have a compatible value for that so that platforms can communicate it. Mark, are there already plans for this? -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jul 30, 2014 at 8:06 AM, Robert Richter <rric@kernel.org> wrote: > 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 | 387 +++++++++++++++++++++++++++++++++++ > 2 files changed, 388 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 Oh, and: Let's fix the mistake we made on 32-bit here (that we can't undo unless we move all dts files now, which is too much churn), and put each SoC vendor in its own subdirectory. So, please add a arch/arm64/boot/dts/cavium/ directory, add a Makefile and the dts there. We should move vexpress under arm/ and xgene under apm/ too. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Wed, Jul 30, 2014 at 07:12:17PM +0100, Olof Johansson wrote: > On Wed, Jul 30, 2014 at 8:06 AM, Robert Richter <rric@kernel.org> wrote: > > 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 | 387 +++++++++++++++++++++++++++++++++++ > > 2 files changed, 388 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..4cf20ac9138b > > --- /dev/null > > +++ b/arch/arm64/boot/dts/thunder-88xx.dts > > @@ -0,0 +1,387 @@ > > +/* > > + * Cavium Thunder DTS file > > + * > > + * Copyright (C) 2013, Cavium Inc. > > + * > > + * This program 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. > > + */ > > +/dts-v1/; > > + > > +/* Reserving first 12MB of DDR for firmware */ > > +/memreserve/ 0x00000000 0x00c00000; > > + > > +/ { > > + model = "Cavium ThunderX CN88XX Family"; > > + compatible = "cavium,thunder-88xx"; > > Hmm. I take it this platform is compliant with some level of SBSA? We > should probably have a compatible value for that so that platforms can > communicate it. > > Mark, are there already plans for this? Not so far, but my monitor now has a sticky note telling me to look into it. :) Many of the useful properties provided by SBSA are already described elsewhere (e.g. page and ASID size can be found in ID registers), and hardware properties it mandates (e.g. PPI assignment for level 2 compliant systems) will be described elsewhere. I'll have to read the spec in more detail to figure out what we can derive from an SBSA compliance property. Regardless it probably makes sense to have a compatible string or other property on the root node; at worst it only costs us a few bytes. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday 30 July 2014, Robert Richter wrote: > +/* > + * Cavium Thunder DTS file > + * > + * Copyright (C) 2013, Cavium Inc. > + * > + * This program 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. > + */ I think it makes sense to use a permissive license for these files here, since board vendors may want to include a copy of the binary in their firmware, which isn't necessarily GPL compatible. What is Cavium's interest in making this GPL? Arnd -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Rob and Arnd, On 30.07.14 11:37:38, Rob Herring wrote: > >> +/* > >> + * Cavium Thunder DTS file > >> + * > >> + * Copyright (C) 2013, Cavium Inc. > >> + * > >> + * This program 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. > >> + */ > > You may want to reconsider if this should be BSD. I understand that this is an issue for the inclusion in firmware binaries. Though, we just followed common practice here which is gplv2. I looked through existing dts files in arch/arm*/dts/* and about 590 of 720 have a gplv2 statement in. The other files don't have any and thus following the COPYING file which is gplv2 too. It is my understanding that the kernel requires licensing under gplv2. So an option would be to dual license the dts file, e.g. with BSD. How is this typically handled? Are there other repositories where dts files are included with a different license model than gplv2? Thanks, -Robert -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 31.07.14 12:24:13, Arnd Bergmann wrote: > On Wednesday 30 July 2014, Robert Richter wrote: > > +/* > > + * Cavium Thunder DTS file > > + * > > + * Copyright (C) 2013, Cavium Inc. > > + * > > + * This program 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. > > + */ > > I think it makes sense to use a permissive license for these files here, > since board vendors may want to include a copy of the binary in their > firmware, which isn't necessarily GPL compatible. > > What is Cavium's interest in making this GPL? See my response to Rob's mail on this. -Robert -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 30.07.14 11:37:38, Rob Herring wrote: > On Wed, Jul 30, 2014 at 10:46 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert Richter wrote: > >> From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> > >> +/ { > >> + model = "Cavium ThunderX CN88XX Family"; > >> + compatible = "cavium,thunder-88xx"; > > > > Please don't use wildcards in compatible strings. Give this an absolute > > name, and override as necessary. The naming 88xx refers to the processor family and arn't actually wildcards. In the future we might need another dts file for 87xx, but so far all SoCs of 88xx family should use the same dts files. In this sense the naming is very specific. > >> + cpus { > >> + #address-cells = <2>; > >> + #size-cells = <0>; > >> + > >> + cpu@000 { > >> + device_type = "cpu"; > >> + compatible = "cavium,thunder", "arm,armv8"; > >> + reg = <0x0 0x000>; > >> + enable-method = "psci"; > >> + }; > > > > Just to check: both the SoC and CPU are called thunder? The soc is called thunder-88xx, the cpu thunder. E.g. an 87xx soc will have the same core in which is thunder. > >> + memory@00000000 { > >> + device_type = "memory"; > >> + reg = <0x0 0x00000000 0x0 0x80000000>; > >> + }; > >> + > >> + gic0: interrupt-controller@801000000000 { > > > > To make this easier to read, please place a comma between 32-bit > > portions of the unit address (e.g. here have 8010,00000000). Changed this. > > Mark, perhaps a dtc or checkpatch.pl check for this? > > This should also be under a bus node. Will do. > > >> + compatible = "arm,gic-v3"; > >> + #interrupt-cells = <3>; > >> + #address-cells = <2>; > >> + #size-cells = <2>; > >> + ranges; > > > > This has no children, so why have ranges, #address-cells, and > > #size-cells? Right, this is a leftover from a change in a follow on patch that introduces a child for its. Will remove #address-cells, #size-cells and ranges in this patch and move the change to the later patch. > > > >> + interrupt-controller; > >> + reg = <0x8010 0x00000000 0x0 0x010000>, /* GICD */ > >> + <0x8010 0x80000000 0x0 0x200000>; /* GICR */ > >> + interrupts = <1 9 0xf04>; > >> + }; > >> + clocks { > >> + #address-cells = <2>; > >> + #size-cells = <2>; > >> + ranges; > >> + > >> + refclk50mhz: refclk50mhz { > >> + compatible = "fixed-clock"; > >> + #clock-cells = <0>; > >> + clock-frequency = <50000000>; > >> + clock-output-names = "refclk50mhz"; > >> + }; > >> + }; > > > > Please get rid of the clocks node and just put the clocks here. Will do. > > > >> + > >> + uaa0: serial@87e024000000 { > >> + compatible = "arm,pl011", "arm,primecell"; > >> + reg = <0x87e0 0x24000000 0x0 0x1000>; > >> + interrupts = <1 21 4>; > >> + clocks = <&refclk50mhz>; > >> + clock-names = "apb_pclk"; > > > > Is this actually the apb_pclk, or is the the uartclk? I assume it's the > > latter. > > Shouldn't new bindings have both clocks here? A single clock was a > mistake I think (mine in fact). Do you mean clock-names = "uartclk", "apb_pclk"; here? Thanks, -Robert -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 31, 2014 at 7:34 AM, Robert Richter <rric@kernel.org> wrote: > On 30.07.14 11:37:38, Rob Herring wrote: >> On Wed, Jul 30, 2014 at 10:46 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> > On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert Richter wrote: >> >> From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> > >> >> +/ { >> >> + model = "Cavium ThunderX CN88XX Family"; >> >> + compatible = "cavium,thunder-88xx"; >> > >> > Please don't use wildcards in compatible strings. Give this an absolute >> > name, and override as necessary. > > The naming 88xx refers to the processor family and arn't actually > wildcards. In the future we might need another dts file for 87xx, but > so far all SoCs of 88xx family should use the same dts files. In this > sense the naming is very specific. Yes, but each implementation can have its own errata. You might not need to distinguish them now, but you could in the future. However, if the family is really all the same die and different parts are just marketing, then the name is fine. Or if you can easily probe the exact part and revision it's probably fine. > > >> >> + cpus { >> >> + #address-cells = <2>; >> >> + #size-cells = <0>; >> >> + >> >> + cpu@000 { >> >> + device_type = "cpu"; >> >> + compatible = "cavium,thunder", "arm,armv8"; >> >> + reg = <0x0 0x000>; >> >> + enable-method = "psci"; >> >> + }; >> > >> > Just to check: both the SoC and CPU are called thunder? > > The soc is called thunder-88xx, the cpu thunder. E.g. an 87xx soc will > have the same core in which is thunder. And the next version of the core would be called something else? thunder-v2? lightning? As long as they are distinguishable they should be fine. Rob > > >> >> + memory@00000000 { >> >> + device_type = "memory"; >> >> + reg = <0x0 0x00000000 0x0 0x80000000>; >> >> + }; >> >> + >> >> + gic0: interrupt-controller@801000000000 { >> > >> > To make this easier to read, please place a comma between 32-bit >> > portions of the unit address (e.g. here have 8010,00000000). > > Changed this. > >> >> Mark, perhaps a dtc or checkpatch.pl check for this? >> >> This should also be under a bus node. > > Will do. > >> >> >> + compatible = "arm,gic-v3"; >> >> + #interrupt-cells = <3>; >> >> + #address-cells = <2>; >> >> + #size-cells = <2>; >> >> + ranges; >> > >> > This has no children, so why have ranges, #address-cells, and >> > #size-cells? > > Right, this is a leftover from a change in a follow on patch that > introduces a child for its. Will remove #address-cells, #size-cells > and ranges in this patch and move the change to the later patch. > >> > >> >> + interrupt-controller; >> >> + reg = <0x8010 0x00000000 0x0 0x010000>, /* GICD */ >> >> + <0x8010 0x80000000 0x0 0x200000>; /* GICR */ >> >> + interrupts = <1 9 0xf04>; >> >> + }; > >> >> + clocks { >> >> + #address-cells = <2>; >> >> + #size-cells = <2>; >> >> + ranges; >> >> + >> >> + refclk50mhz: refclk50mhz { >> >> + compatible = "fixed-clock"; >> >> + #clock-cells = <0>; >> >> + clock-frequency = <50000000>; >> >> + clock-output-names = "refclk50mhz"; >> >> + }; >> >> + }; >> > >> > Please get rid of the clocks node and just put the clocks here. > > Will do. > >> > >> >> + >> >> + uaa0: serial@87e024000000 { >> >> + compatible = "arm,pl011", "arm,primecell"; >> >> + reg = <0x87e0 0x24000000 0x0 0x1000>; >> >> + interrupts = <1 21 4>; >> >> + clocks = <&refclk50mhz>; >> >> + clock-names = "apb_pclk"; >> > >> > Is this actually the apb_pclk, or is the the uartclk? I assume it's the >> > latter. >> >> Shouldn't new bindings have both clocks here? A single clock was a >> mistake I think (mine in fact). > > Do you mean > clock-names = "uartclk", "apb_pclk"; > here? Yes, but Mark said this change never happened so maybe it is fine. In any case, follow the pl011 binding documentation. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 31.07.14 10:22:19, Rob Herring wrote: > On Thu, Jul 31, 2014 at 7:34 AM, Robert Richter <rric@kernel.org> wrote: > > On 30.07.14 11:37:38, Rob Herring wrote: > >> On Wed, Jul 30, 2014 at 10:46 AM, Mark Rutland <mark.rutland@arm.com> wrote: > >> > On Wed, Jul 30, 2014 at 04:06:31PM +0100, Robert Richter wrote: > >> >> From: Radha Mohan Chintakuntla <rchintakuntla@cavium.com> > > > >> >> +/ { > >> >> + model = "Cavium ThunderX CN88XX Family"; > >> >> + compatible = "cavium,thunder-88xx"; > >> > > >> > Please don't use wildcards in compatible strings. Give this an absolute > >> > name, and override as necessary. > > > > The naming 88xx refers to the processor family and arn't actually > > wildcards. In the future we might need another dts file for 87xx, but > > so far all SoCs of 88xx family should use the same dts files. In this > > sense the naming is very specific. > > Yes, but each implementation can have its own errata. You might not > need to distinguish them now, but you could in the future. > > However, if the family is really all the same die and different parts > are just marketing, then the name is fine. Or if you can easily probe > the exact part and revision it's probably fine. Yes, this relates to the same soc. > > > > > > >> >> + cpus { > >> >> + #address-cells = <2>; > >> >> + #size-cells = <0>; > >> >> + > >> >> + cpu@000 { > >> >> + device_type = "cpu"; > >> >> + compatible = "cavium,thunder", "arm,armv8"; > >> >> + reg = <0x0 0x000>; > >> >> + enable-method = "psci"; > >> >> + }; > >> > > >> > Just to check: both the SoC and CPU are called thunder? > > > > The soc is called thunder-88xx, the cpu thunder. E.g. an 87xx soc will > > have the same core in which is thunder. > > And the next version of the core would be called something else? > thunder-v2? lightning? As long as they are distinguishable they should > be fine. Same here, the name relates to the same core. -Robert -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mark, On 30.07.14 16:46:26, Mark Rutland 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..4cf20ac9138b > > --- /dev/null > > +++ b/arch/arm64/boot/dts/thunder-88xx.dts > > @@ -0,0 +1,387 @@ > > +/* > > + * Cavium Thunder DTS file > > + * > > + * Copyright (C) 2013, Cavium Inc. > > + * > > + * This program 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. > > + */ > > +/dts-v1/; > > + > > +/* Reserving first 12MB of DDR for firmware */ > > +/memreserve/ 0x00000000 0x00c00000; > > What exactly is this memreserve intended to protect at runtime? > > The only item of runtime firmware I see in use below is PSCI on the > secure side. > > How is the kernel booted on this platform? UEFI? We checked this and it seems we don't need memreserve. Mem is either not visible to the kernel (ATF) or it is marked reserved by firmware (UEFI). At the moment we don't see any other use cases. We will remove this memreserve. Thanks, -Robert -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Olof, On 30.07.14 11:14:23, Olof Johansson wrote: > On Wed, Jul 30, 2014 at 8:06 AM, Robert Richter <rric@kernel.org> wrote: > > 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 | 387 +++++++++++++++++++++++++++++++++++ > > 2 files changed, 388 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 > > Oh, and: > > Let's fix the mistake we made on 32-bit here (that we can't undo > unless we move all dts files now, which is too much churn), and put > each SoC vendor in its own subdirectory. > > So, please add a arch/arm64/boot/dts/cavium/ directory, add a Makefile > and the dts there. > > We should move vexpress under arm/ and xgene under apm/ too. I well take a look at this. -Robert -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Olof, On 30.07.14 11:14:23, Olof Johansson wrote: > On Wed, Jul 30, 2014 at 8:06 AM, Robert Richter <rric@kernel.org> wrote: > > 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 | 387 +++++++++++++++++++++++++++++++++++ > > 2 files changed, 388 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 > > Oh, and: > > Let's fix the mistake we made on 32-bit here (that we can't undo > unless we move all dts files now, which is too much churn), and put > each SoC vendor in its own subdirectory. > > So, please add a arch/arm64/boot/dts/cavium/ directory, add a Makefile > and the dts there. > > We should move vexpress under arm/ and xgene under apm/ too. I was looking into this. It turned out that this would introduce more pain than it solves. The problem with introducing vendor subdirs for .dts files is that this will require also subdirs for .dtb files to avoid name conflicts. This means that dtb files are no longer in a single directory. Current build scripts and makefiles rely on this. E.g.: scripts/Makefile.lib:$(obj)/%.dtb.S: $(obj)/%.dtb Thus, the introduction of vendor subdirs is not easy to implement and may break existing workflows. Also, no other arch has vendor subdirs. A solution would be to have a naming scheme for dts files which requires the vendor in the file name, such as cavium-thunder-88xx.dtb. Though, these long names may look a bit ugly. Hmm... Any thoughts? Thanks, -Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Thu, Aug 28, 2014 at 05:15:56PM +0100, Robert Richter wrote: > Olof, > > On 30.07.14 11:14:23, Olof Johansson wrote: > > On Wed, Jul 30, 2014 at 8:06 AM, Robert Richter <rric@kernel.org> wrote: > > > 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 | 387 +++++++++++++++++++++++++++++++++++ > > > 2 files changed, 388 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 > > > > Oh, and: > > > > Let's fix the mistake we made on 32-bit here (that we can't undo > > unless we move all dts files now, which is too much churn), and put > > each SoC vendor in its own subdirectory. > > > > So, please add a arch/arm64/boot/dts/cavium/ directory, add a Makefile > > and the dts there. > > > > We should move vexpress under arm/ and xgene under apm/ too. > > I was looking into this. It turned out that this would introduce more > pain than it solves. The problem with introducing vendor subdirs for > .dts files is that this will require also subdirs for .dtb files to > avoid name conflicts. This means that dtb files are no longer in a > single directory. Current build scripts and makefiles rely on this. > E.g.: > > scripts/Makefile.lib:$(obj)/%.dtb.S: $(obj)/%.dtb > > Thus, the introduction of vendor subdirs is not easy to implement and > may break existing workflows. Also, no other arch has vendor subdirs. > > A solution would be to have a naming scheme for dts files which > requires the vendor in the file name, such as cavium-thunder-88xx.dtb. > Though, these long names may look a bit ugly. > > Hmm... Any thoughts? That would make it possible to search, but the number of files in one place might become somewhat overwelming (which I believe was Olof's concern). Olof, thoughts? Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Thu, Aug 28, 2014 at 9:25 AM, Mark Rutland <mark.rutland@arm.com> wrote: > On Thu, Aug 28, 2014 at 05:15:56PM +0100, Robert Richter wrote: >> Olof, >> >> On 30.07.14 11:14:23, Olof Johansson wrote: >> > On Wed, Jul 30, 2014 at 8:06 AM, Robert Richter <rric@kernel.org> wrote: >> > > 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 | 387 +++++++++++++++++++++++++++++++++++ >> > > 2 files changed, 388 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 >> > >> > Oh, and: >> > >> > Let's fix the mistake we made on 32-bit here (that we can't undo >> > unless we move all dts files now, which is too much churn), and put >> > each SoC vendor in its own subdirectory. >> > >> > So, please add a arch/arm64/boot/dts/cavium/ directory, add a Makefile >> > and the dts there. >> > >> > We should move vexpress under arm/ and xgene under apm/ too. >> >> I was looking into this. It turned out that this would introduce more >> pain than it solves. The problem with introducing vendor subdirs for >> .dts files is that this will require also subdirs for .dtb files to >> avoid name conflicts. This means that dtb files are no longer in a >> single directory. Current build scripts and makefiles rely on this. >> E.g.: >> >> scripts/Makefile.lib:$(obj)/%.dtb.S: $(obj)/%.dtb >> >> Thus, the introduction of vendor subdirs is not easy to implement and >> may break existing workflows. Also, no other arch has vendor subdirs. >> >> A solution would be to have a naming scheme for dts files which >> requires the vendor in the file name, such as cavium-thunder-88xx.dtb. >> Though, these long names may look a bit ugly. >> >> Hmm... Any thoughts? > > That would make it possible to search, but the number of files in one > place might become somewhat overwelming (which I believe was Olof's > concern). > > Olof, thoughts? Yeah, on 32 bit we've got an ever-growing and very large directory today that is becoming a headache. Carving it up in directories to reduce plain directory size would come a long way. I think we would catch name conflicts quickly with the automatic builders we have today -- and it's likely that the files will have a platform prefix anyway so it shouldn't be a big issue. I think we can live with that. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 28.08.14 09:31:43, Olof Johansson wrote: > On Thu, Aug 28, 2014 at 9:25 AM, Mark Rutland <mark.rutland@arm.com> wrote: > > On Thu, Aug 28, 2014 at 05:15:56PM +0100, Robert Richter wrote: > >> Olof, > >> > >> On 30.07.14 11:14:23, Olof Johansson wrote: > >> > On Wed, Jul 30, 2014 at 8:06 AM, Robert Richter <rric@kernel.org> wrote: > >> > > 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 | 387 +++++++++++++++++++++++++++++++++++ > >> > > 2 files changed, 388 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 > >> > > >> > Oh, and: > >> > > >> > Let's fix the mistake we made on 32-bit here (that we can't undo > >> > unless we move all dts files now, which is too much churn), and put > >> > each SoC vendor in its own subdirectory. > >> > > >> > So, please add a arch/arm64/boot/dts/cavium/ directory, add a Makefile > >> > and the dts there. > >> > > >> > We should move vexpress under arm/ and xgene under apm/ too. > >> > >> I was looking into this. It turned out that this would introduce more > >> pain than it solves. The problem with introducing vendor subdirs for > >> .dts files is that this will require also subdirs for .dtb files to > >> avoid name conflicts. This means that dtb files are no longer in a > >> single directory. Current build scripts and makefiles rely on this. > >> E.g.: > >> > >> scripts/Makefile.lib:$(obj)/%.dtb.S: $(obj)/%.dtb > >> > >> Thus, the introduction of vendor subdirs is not easy to implement and > >> may break existing workflows. Also, no other arch has vendor subdirs. > >> > >> A solution would be to have a naming scheme for dts files which > >> requires the vendor in the file name, such as cavium-thunder-88xx.dtb. > >> Though, these long names may look a bit ugly. > >> > >> Hmm... Any thoughts? > > > > That would make it possible to search, but the number of files in one > > place might become somewhat overwelming (which I believe was Olof's > > concern). > > > > Olof, thoughts? > > Yeah, on 32 bit we've got an ever-growing and very large directory > today that is becoming a headache. Carving it up in directories to > reduce plain directory size would come a long way. > > I think we would catch name conflicts quickly with the automatic > builders we have today -- and it's likely that the files will have a > platform prefix anyway so it shouldn't be a big issue. I think we can > live with that. So you mean, having the source files with subdirectories, but the dtb files in a single obj dir? -Robert -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Aug 28, 2014 at 11:14 AM, Robert Richter <rric@kernel.org> wrote: > On 28.08.14 09:31:43, Olof Johansson wrote: >> On Thu, Aug 28, 2014 at 9:25 AM, Mark Rutland <mark.rutland@arm.com> wrote: >> > On Thu, Aug 28, 2014 at 05:15:56PM +0100, Robert Richter wrote: >> >> Olof, >> >> >> >> On 30.07.14 11:14:23, Olof Johansson wrote: >> >> > On Wed, Jul 30, 2014 at 8:06 AM, Robert Richter <rric@kernel.org> wrote: >> >> > > 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 | 387 +++++++++++++++++++++++++++++++++++ >> >> > > 2 files changed, 388 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 >> >> > >> >> > Oh, and: >> >> > >> >> > Let's fix the mistake we made on 32-bit here (that we can't undo >> >> > unless we move all dts files now, which is too much churn), and put >> >> > each SoC vendor in its own subdirectory. >> >> > >> >> > So, please add a arch/arm64/boot/dts/cavium/ directory, add a Makefile >> >> > and the dts there. >> >> > >> >> > We should move vexpress under arm/ and xgene under apm/ too. >> >> >> >> I was looking into this. It turned out that this would introduce more >> >> pain than it solves. The problem with introducing vendor subdirs for >> >> .dts files is that this will require also subdirs for .dtb files to >> >> avoid name conflicts. This means that dtb files are no longer in a >> >> single directory. Current build scripts and makefiles rely on this. >> >> E.g.: >> >> >> >> scripts/Makefile.lib:$(obj)/%.dtb.S: $(obj)/%.dtb >> >> >> >> Thus, the introduction of vendor subdirs is not easy to implement and >> >> may break existing workflows. Also, no other arch has vendor subdirs. >> >> >> >> A solution would be to have a naming scheme for dts files which >> >> requires the vendor in the file name, such as cavium-thunder-88xx.dtb. >> >> Though, these long names may look a bit ugly. >> >> >> >> Hmm... Any thoughts? >> > >> > That would make it possible to search, but the number of files in one >> > place might become somewhat overwelming (which I believe was Olof's >> > concern). >> > >> > Olof, thoughts? >> >> Yeah, on 32 bit we've got an ever-growing and very large directory >> today that is becoming a headache. Carving it up in directories to >> reduce plain directory size would come a long way. >> >> I think we would catch name conflicts quickly with the automatic >> builders we have today -- and it's likely that the files will have a >> platform prefix anyway so it shouldn't be a big issue. I think we can >> live with that. > > So you mean, having the source files with subdirectories, but the dtb > files in a single obj dir? Thinking about it a bit more, the even more obvious solution that I for some reason didn't think of at the time, is to have the dtbs_install target create the appropriate subdirectories on the install side, so that the structure is preserved. That comes a bit closer to how modules are handled as well. -Olof -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 28.08.14 16:01:08, Olof Johansson wrote: > On Thu, Aug 28, 2014 at 11:14 AM, Robert Richter <rric@kernel.org> wrote: > > On 28.08.14 09:31:43, Olof Johansson wrote: > >> On Thu, Aug 28, 2014 at 9:25 AM, Mark Rutland <mark.rutland@arm.com> wrote: > >> > On Thu, Aug 28, 2014 at 05:15:56PM +0100, Robert Richter wrote: > >> >> Olof, > >> >> > >> >> On 30.07.14 11:14:23, Olof Johansson wrote: > >> >> > On Wed, Jul 30, 2014 at 8:06 AM, Robert Richter <rric@kernel.org> wrote: > >> >> > > 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 | 387 +++++++++++++++++++++++++++++++++++ > >> >> > > 2 files changed, 388 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 > >> >> > > >> >> > Oh, and: > >> >> > > >> >> > Let's fix the mistake we made on 32-bit here (that we can't undo > >> >> > unless we move all dts files now, which is too much churn), and put > >> >> > each SoC vendor in its own subdirectory. > >> >> > > >> >> > So, please add a arch/arm64/boot/dts/cavium/ directory, add a Makefile > >> >> > and the dts there. > >> >> > > >> >> > We should move vexpress under arm/ and xgene under apm/ too. > >> >> > >> >> I was looking into this. It turned out that this would introduce more > >> >> pain than it solves. The problem with introducing vendor subdirs for > >> >> .dts files is that this will require also subdirs for .dtb files to > >> >> avoid name conflicts. This means that dtb files are no longer in a > >> >> single directory. Current build scripts and makefiles rely on this. > >> >> E.g.: > >> >> > >> >> scripts/Makefile.lib:$(obj)/%.dtb.S: $(obj)/%.dtb > >> >> > >> >> Thus, the introduction of vendor subdirs is not easy to implement and > >> >> may break existing workflows. Also, no other arch has vendor subdirs. > >> >> > >> >> A solution would be to have a naming scheme for dts files which > >> >> requires the vendor in the file name, such as cavium-thunder-88xx.dtb. > >> >> Though, these long names may look a bit ugly. > >> >> > >> >> Hmm... Any thoughts? > >> > > >> > That would make it possible to search, but the number of files in one > >> > place might become somewhat overwelming (which I believe was Olof's > >> > concern). > >> > > >> > Olof, thoughts? > >> > >> Yeah, on 32 bit we've got an ever-growing and very large directory > >> today that is becoming a headache. Carving it up in directories to > >> reduce plain directory size would come a long way. > >> > >> I think we would catch name conflicts quickly with the automatic > >> builders we have today -- and it's likely that the files will have a > >> platform prefix anyway so it shouldn't be a big issue. I think we can > >> live with that. > > > > So you mean, having the source files with subdirectories, but the dtb > > files in a single obj dir? It seems it will be easier to have also subdirs for objs. > Thinking about it a bit more, the even more obvious solution that I > for some reason didn't think of at the time, is to have the > dtbs_install target create the appropriate subdirectories on the > install side, so that the structure is preserved. > > That comes a bit closer to how modules are handled as well. Yes, dtbs_install target would be useful. Will come with a solution for this too. -Robert -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Olof, On 29.08.14 15:49:42, Robert Richter wrote: > On 29.08.14 14:10:23, Robert Richter wrote: > > On 28.08.14 16:01:08, Olof Johansson wrote: > > > Thinking about it a bit more, the even more obvious solution that I > > > for some reason didn't think of at the time, is to have the > > > dtbs_install target create the appropriate subdirectories on the > > > install side, so that the structure is preserved. > > > > > > That comes a bit closer to how modules are handled as well. > > > > Yes, dtbs_install target would be useful. > > > > Will come with a solution for this too. > > below is a patch that adds the dtbs_install target to arm64. Taken > from arm where this was already implemented. please note that I sent a separate patch set with a complete implementation of this with the title: [PATCH 0/6] dts, kbuild: Implement support for dtb vendor subdirs this patch is included there too. -Robert -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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..4cf20ac9138b --- /dev/null +++ b/arch/arm64/boot/dts/thunder-88xx.dts @@ -0,0 +1,387 @@ +/* + * Cavium Thunder DTS file + * + * Copyright (C) 2013, Cavium Inc. + * + * This program 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. + */ +/dts-v1/; + +/* Reserving first 12MB of DDR for firmware */ +/memreserve/ 0x00000000 0x00c00000; + +/ { + 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@000 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x000>; + enable-method = "psci"; + }; + cpu@001 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x001>; + enable-method = "psci"; + }; + cpu@002 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x002>; + enable-method = "psci"; + }; + cpu@003 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x003>; + enable-method = "psci"; + }; + cpu@004 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x004>; + enable-method = "psci"; + }; + cpu@005 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x005>; + enable-method = "psci"; + }; + cpu@006 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x006>; + enable-method = "psci"; + }; + cpu@007 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x007>; + enable-method = "psci"; + }; + cpu@008 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x008>; + enable-method = "psci"; + }; + cpu@009 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x009>; + enable-method = "psci"; + }; + cpu@00a { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x00a>; + enable-method = "psci"; + }; + cpu@00b { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x00b>; + enable-method = "psci"; + }; + cpu@00c { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x00c>; + enable-method = "psci"; + }; + cpu@00d { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x00d>; + enable-method = "psci"; + }; + cpu@00e { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x00e>; + enable-method = "psci"; + }; + cpu@00f { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x00f>; + enable-method = "psci"; + }; + cpu@100 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x100>; + enable-method = "psci"; + }; + cpu@101 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x101>; + enable-method = "psci"; + }; + cpu@102 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x102>; + enable-method = "psci"; + }; + cpu@103 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x103>; + enable-method = "psci"; + }; + cpu@104 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x104>; + enable-method = "psci"; + }; + cpu@105 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x105>; + enable-method = "psci"; + }; + cpu@106 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x106>; + enable-method = "psci"; + }; + cpu@107 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x107>; + enable-method = "psci"; + }; + cpu@108 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x108>; + enable-method = "psci"; + }; + cpu@109 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x109>; + enable-method = "psci"; + }; + cpu@10a { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x10a>; + enable-method = "psci"; + }; + cpu@10b { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x10b>; + enable-method = "psci"; + }; + cpu@10c { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x10c>; + enable-method = "psci"; + }; + cpu@10d { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x10d>; + enable-method = "psci"; + }; + cpu@10e { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x10e>; + enable-method = "psci"; + }; + cpu@10f { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x10f>; + enable-method = "psci"; + }; + cpu@200 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x200>; + enable-method = "psci"; + }; + cpu@201 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x201>; + enable-method = "psci"; + }; + cpu@202 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x202>; + enable-method = "psci"; + }; + cpu@203 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x203>; + enable-method = "psci"; + }; + cpu@204 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x204>; + enable-method = "psci"; + }; + cpu@205 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x205>; + enable-method = "psci"; + }; + cpu@206 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x206>; + enable-method = "psci"; + }; + cpu@207 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x207>; + enable-method = "psci"; + }; + cpu@208 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x208>; + enable-method = "psci"; + }; + cpu@209 { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x209>; + enable-method = "psci"; + }; + cpu@20a { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x20a>; + enable-method = "psci"; + }; + cpu@20b { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x20b>; + enable-method = "psci"; + }; + cpu@20c { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x20c>; + enable-method = "psci"; + }; + cpu@20d { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x20d>; + enable-method = "psci"; + }; + cpu@20e { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x20e>; + enable-method = "psci"; + }; + cpu@20f { + device_type = "cpu"; + compatible = "cavium,thunder", "arm,armv8"; + reg = <0x0 0x20f>; + enable-method = "psci"; + }; + }; + + memory@00000000 { + device_type = "memory"; + reg = <0x0 0x00000000 0x0 0x80000000>; + }; + + gic0: interrupt-controller@801000000000 { + compatible = "arm,gic-v3"; + #interrupt-cells = <3>; + #address-cells = <2>; + #size-cells = <2>; + ranges; + interrupt-controller; + reg = <0x8010 0x00000000 0x0 0x010000>, /* GICD */ + <0x8010 0x80000000 0x0 0x200000>; /* GICR */ + interrupts = <1 9 0xf04>; + }; + + 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; + + clocks { + #address-cells = <2>; + #size-cells = <2>; + ranges; + + refclk50mhz: refclk50mhz { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <50000000>; + clock-output-names = "refclk50mhz"; + }; + }; + + uaa0: serial@87e024000000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x87e0 0x24000000 0x0 0x1000>; + interrupts = <1 21 4>; + clocks = <&refclk50mhz>; + clock-names = "apb_pclk"; + }; + + uaa1: serial@87e025000000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0x87e0 0x25000000 0x0 0x1000>; + interrupts = <1 22 4>; + clocks = <&refclk50mhz>; + clock-names = "apb_pclk"; + }; + }; +};