* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 16:11 ` Jason Cooper
0 siblings, 0 replies; 36+ messages in thread
From: Jason Cooper @ 2014-05-27 16:11 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Andrew Lunn, Gregory Clement, devicetree,
linux-arm-kernel, linux-kernel
On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
> As Mainlining effort for SolidRun CuBox has been carried out on the
> Engineering Sample, the board DTS was reflecting this. Actually,
> SolidRun CuBox comes in three different variants: Engineering Sample (ES),
> production with 1GB RAM (1G), and production with 2GB RAM (2G).
>
> Therefore, we split the current dove-cubox.dts into a common board include
> and one board dts for each of the above variants.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> ---
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
> Cc: Kumar Gala <galak@codeaurora.org>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/boot/dts/Makefile | 4 +++-
> arch/arm/boot/dts/dove-cubox-1g.dts | 17 ++++++++++++++++
> arch/arm/boot/dts/dove-cubox-2g.dts | 17 ++++++++++++++++
> arch/arm/boot/dts/dove-cubox-es.dts | 23 ++++++++++++++++++++++
> .../boot/dts/{dove-cubox.dts => dove-cubox.dtsi} | 17 ----------------
> 5 files changed, 60 insertions(+), 18 deletions(-)
> create mode 100644 arch/arm/boot/dts/dove-cubox-1g.dts
> create mode 100644 arch/arm/boot/dts/dove-cubox-2g.dts
> create mode 100644 arch/arm/boot/dts/dove-cubox-es.dts
> rename arch/arm/boot/dts/{dove-cubox.dts => dove-cubox.dtsi} (86%)
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 35c146f31e46..40a008539c0c 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -404,7 +404,9 @@ dtb-$(CONFIG_MACH_ARMADA_XP) += \
> armada-xp-matrix.dtb \
> armada-xp-openblocks-ax3-4.dtb
> dtb-$(CONFIG_MACH_DOVE) += dove-cm-a510.dtb \
> - dove-cubox.dtb \
> + dove-cubox-1g.dtb \
> + dove-cubox-2g.dtb \
> + dove-cubox-es.dtb \
> dove-d2plug.dtb \
> dove-d3plug.dtb \
> dove-dove-db.dtb
> diff --git a/arch/arm/boot/dts/dove-cubox-1g.dts b/arch/arm/boot/dts/dove-cubox-1g.dts
> new file mode 100644
> index 000000000000..eebd3f7ca7e6
> --- /dev/null
> +++ b/arch/arm/boot/dts/dove-cubox-1g.dts
> @@ -0,0 +1,17 @@
> +/dts-v1/;
> +
> +#include "dove-cubox.dtsi"
> +
> +/ {
> + model = "SolidRun CuBox (1G)";
> + compatible = "solidrun,cubox-1g", "solidrun,cubox", "marvell,dove";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0x40000000>;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200n8 earlyprintk";
> + };
> +};
> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts b/arch/arm/boot/dts/dove-cubox-2g.dts
> new file mode 100644
> index 000000000000..513b6a68eba3
> --- /dev/null
> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
> @@ -0,0 +1,17 @@
> +/dts-v1/;
> +
> +#include "dove-cubox.dtsi"
> +
> +/ {
> + model = "SolidRun CuBox (2G)";
> + compatible = "solidrun,cubox-2g", "solidrun,cubox", "marvell,dove";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0x80000000>;
Do you anticipate any other differences between the 1G and the 2G?
Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
should be setting the amount of RAM at boottime anyway.
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200n8 earlyprintk";
> + };
> +};
> diff --git a/arch/arm/boot/dts/dove-cubox-es.dts b/arch/arm/boot/dts/dove-cubox-es.dts
> new file mode 100644
> index 000000000000..5fc17ce34c98
> --- /dev/null
> +++ b/arch/arm/boot/dts/dove-cubox-es.dts
> @@ -0,0 +1,23 @@
> +/dts-v1/;
> +
> +#include "dove-cubox.dtsi"
> +
> +/ {
> + model = "SolidRun CuBox (ES)";
"Engineering Sample" ?
thx,
Jason.
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 16:11 ` Jason Cooper
0 siblings, 0 replies; 36+ messages in thread
From: Jason Cooper @ 2014-05-27 16:11 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Andrew Lunn, Gregory Clement,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
> As Mainlining effort for SolidRun CuBox has been carried out on the
> Engineering Sample, the board DTS was reflecting this. Actually,
> SolidRun CuBox comes in three different variants: Engineering Sample (ES),
> production with 1GB RAM (1G), and production with 2GB RAM (2G).
>
> Therefore, we split the current dove-cubox.dts into a common board include
> and one board dts for each of the above variants.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> Cc: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
> Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> Cc: Gregory Clement <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> ---
> arch/arm/boot/dts/Makefile | 4 +++-
> arch/arm/boot/dts/dove-cubox-1g.dts | 17 ++++++++++++++++
> arch/arm/boot/dts/dove-cubox-2g.dts | 17 ++++++++++++++++
> arch/arm/boot/dts/dove-cubox-es.dts | 23 ++++++++++++++++++++++
> .../boot/dts/{dove-cubox.dts => dove-cubox.dtsi} | 17 ----------------
> 5 files changed, 60 insertions(+), 18 deletions(-)
> create mode 100644 arch/arm/boot/dts/dove-cubox-1g.dts
> create mode 100644 arch/arm/boot/dts/dove-cubox-2g.dts
> create mode 100644 arch/arm/boot/dts/dove-cubox-es.dts
> rename arch/arm/boot/dts/{dove-cubox.dts => dove-cubox.dtsi} (86%)
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 35c146f31e46..40a008539c0c 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -404,7 +404,9 @@ dtb-$(CONFIG_MACH_ARMADA_XP) += \
> armada-xp-matrix.dtb \
> armada-xp-openblocks-ax3-4.dtb
> dtb-$(CONFIG_MACH_DOVE) += dove-cm-a510.dtb \
> - dove-cubox.dtb \
> + dove-cubox-1g.dtb \
> + dove-cubox-2g.dtb \
> + dove-cubox-es.dtb \
> dove-d2plug.dtb \
> dove-d3plug.dtb \
> dove-dove-db.dtb
> diff --git a/arch/arm/boot/dts/dove-cubox-1g.dts b/arch/arm/boot/dts/dove-cubox-1g.dts
> new file mode 100644
> index 000000000000..eebd3f7ca7e6
> --- /dev/null
> +++ b/arch/arm/boot/dts/dove-cubox-1g.dts
> @@ -0,0 +1,17 @@
> +/dts-v1/;
> +
> +#include "dove-cubox.dtsi"
> +
> +/ {
> + model = "SolidRun CuBox (1G)";
> + compatible = "solidrun,cubox-1g", "solidrun,cubox", "marvell,dove";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0x40000000>;
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200n8 earlyprintk";
> + };
> +};
> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts b/arch/arm/boot/dts/dove-cubox-2g.dts
> new file mode 100644
> index 000000000000..513b6a68eba3
> --- /dev/null
> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
> @@ -0,0 +1,17 @@
> +/dts-v1/;
> +
> +#include "dove-cubox.dtsi"
> +
> +/ {
> + model = "SolidRun CuBox (2G)";
> + compatible = "solidrun,cubox-2g", "solidrun,cubox", "marvell,dove";
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00000000 0x80000000>;
Do you anticipate any other differences between the 1G and the 2G?
Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
should be setting the amount of RAM at boottime anyway.
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200n8 earlyprintk";
> + };
> +};
> diff --git a/arch/arm/boot/dts/dove-cubox-es.dts b/arch/arm/boot/dts/dove-cubox-es.dts
> new file mode 100644
> index 000000000000..5fc17ce34c98
> --- /dev/null
> +++ b/arch/arm/boot/dts/dove-cubox-es.dts
> @@ -0,0 +1,23 @@
> +/dts-v1/;
> +
> +#include "dove-cubox.dtsi"
> +
> +/ {
> + model = "SolidRun CuBox (ES)";
"Engineering Sample" ?
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
2014-05-27 16:11 ` Jason Cooper
@ 2014-05-27 16:30 ` Sebastian Hesselbarth
-1 siblings, 0 replies; 36+ messages in thread
From: Sebastian Hesselbarth @ 2014-05-27 16:30 UTC (permalink / raw)
To: linux-arm-kernel
On 05/27/2014 06:11 PM, Jason Cooper wrote:
> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
>> As Mainlining effort for SolidRun CuBox has been carried out on the
>> Engineering Sample, the board DTS was reflecting this. Actually,
>> SolidRun CuBox comes in three different variants: Engineering Sample (ES),
>> production with 1GB RAM (1G), and production with 2GB RAM (2G).
>>
>> Therefore, we split the current dove-cubox.dts into a common board include
>> and one board dts for each of the above variants.
>>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>> ---
[...]
>> diff --git a/arch/arm/boot/dts/dove-cubox-1g.dts b/arch/arm/boot/dts/dove-cubox-1g.dts
>> new file mode 100644
>> index 000000000000..eebd3f7ca7e6
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/dove-cubox-1g.dts
>> @@ -0,0 +1,17 @@
>> +/dts-v1/;
>> +
>> +#include "dove-cubox.dtsi"
>> +
>> +/ {
>> + model = "SolidRun CuBox (1G)";
>> + compatible = "solidrun,cubox-1g", "solidrun,cubox", "marvell,dove";
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x00000000 0x40000000>;
>> + };
>> +
>> + chosen {
>> + bootargs = "console=ttyS0,115200n8 earlyprintk";
>> + };
>> +};
>> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts b/arch/arm/boot/dts/dove-cubox-2g.dts
>> new file mode 100644
>> index 000000000000..513b6a68eba3
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
>> @@ -0,0 +1,17 @@
>> +/dts-v1/;
>> +
>> +#include "dove-cubox.dtsi"
>> +
>> +/ {
>> + model = "SolidRun CuBox (2G)";
>> + compatible = "solidrun,cubox-2g", "solidrun,cubox", "marvell,dove";
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x00000000 0x80000000>;
>
> Do you anticipate any other differences between the 1G and the 2G?
> Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
> should be setting the amount of RAM at boottime anyway.
No, there is no known difference between 1G and 2G except doubled RAM.
I'll squash the two back into a single non-ES dts.
About the board specific compatibles, I am not so sure if we should
keep them at all. "solidrun,cubox" for all three variants should be
enough. checkpatch is already choking on every unknown compatible it
sees and documenting each individual board clearly doesn't scale well.
>> + };
>> +
>> + chosen {
>> + bootargs = "console=ttyS0,115200n8 earlyprintk";
>> + };
>> +};
>> diff --git a/arch/arm/boot/dts/dove-cubox-es.dts b/arch/arm/boot/dts/dove-cubox-es.dts
>> new file mode 100644
>> index 000000000000..5fc17ce34c98
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/dove-cubox-es.dts
>> @@ -0,0 +1,23 @@
>> +/dts-v1/;
>> +
>> +#include "dove-cubox.dtsi"
>> +
>> +/ {
>> + model = "SolidRun CuBox (ES)";
>
> "Engineering Sample" ?
Hmm, I guess those who have it know about ES=="Engineering Sample" but
as I have to do a v2 anyway, I'll fix it up.
Thanks!
Sebastian
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 16:30 ` Sebastian Hesselbarth
0 siblings, 0 replies; 36+ messages in thread
From: Sebastian Hesselbarth @ 2014-05-27 16:30 UTC (permalink / raw)
To: Jason Cooper
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Andrew Lunn, Gregory Clement, devicetree,
linux-arm-kernel, linux-kernel
On 05/27/2014 06:11 PM, Jason Cooper wrote:
> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
>> As Mainlining effort for SolidRun CuBox has been carried out on the
>> Engineering Sample, the board DTS was reflecting this. Actually,
>> SolidRun CuBox comes in three different variants: Engineering Sample (ES),
>> production with 1GB RAM (1G), and production with 2GB RAM (2G).
>>
>> Therefore, we split the current dove-cubox.dts into a common board include
>> and one board dts for each of the above variants.
>>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>> ---
[...]
>> diff --git a/arch/arm/boot/dts/dove-cubox-1g.dts b/arch/arm/boot/dts/dove-cubox-1g.dts
>> new file mode 100644
>> index 000000000000..eebd3f7ca7e6
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/dove-cubox-1g.dts
>> @@ -0,0 +1,17 @@
>> +/dts-v1/;
>> +
>> +#include "dove-cubox.dtsi"
>> +
>> +/ {
>> + model = "SolidRun CuBox (1G)";
>> + compatible = "solidrun,cubox-1g", "solidrun,cubox", "marvell,dove";
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x00000000 0x40000000>;
>> + };
>> +
>> + chosen {
>> + bootargs = "console=ttyS0,115200n8 earlyprintk";
>> + };
>> +};
>> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts b/arch/arm/boot/dts/dove-cubox-2g.dts
>> new file mode 100644
>> index 000000000000..513b6a68eba3
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
>> @@ -0,0 +1,17 @@
>> +/dts-v1/;
>> +
>> +#include "dove-cubox.dtsi"
>> +
>> +/ {
>> + model = "SolidRun CuBox (2G)";
>> + compatible = "solidrun,cubox-2g", "solidrun,cubox", "marvell,dove";
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x00000000 0x80000000>;
>
> Do you anticipate any other differences between the 1G and the 2G?
> Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
> should be setting the amount of RAM at boottime anyway.
No, there is no known difference between 1G and 2G except doubled RAM.
I'll squash the two back into a single non-ES dts.
About the board specific compatibles, I am not so sure if we should
keep them at all. "solidrun,cubox" for all three variants should be
enough. checkpatch is already choking on every unknown compatible it
sees and documenting each individual board clearly doesn't scale well.
>> + };
>> +
>> + chosen {
>> + bootargs = "console=ttyS0,115200n8 earlyprintk";
>> + };
>> +};
>> diff --git a/arch/arm/boot/dts/dove-cubox-es.dts b/arch/arm/boot/dts/dove-cubox-es.dts
>> new file mode 100644
>> index 000000000000..5fc17ce34c98
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/dove-cubox-es.dts
>> @@ -0,0 +1,23 @@
>> +/dts-v1/;
>> +
>> +#include "dove-cubox.dtsi"
>> +
>> +/ {
>> + model = "SolidRun CuBox (ES)";
>
> "Engineering Sample" ?
Hmm, I guess those who have it know about ES=="Engineering Sample" but
as I have to do a v2 anyway, I'll fix it up.
Thanks!
Sebastian
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
2014-05-27 16:30 ` Sebastian Hesselbarth
@ 2014-05-27 16:38 ` Jason Cooper
-1 siblings, 0 replies; 36+ messages in thread
From: Jason Cooper @ 2014-05-27 16:38 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 27, 2014 at 06:30:41PM +0200, Sebastian Hesselbarth wrote:
...
> About the board specific compatibles, I am not so sure if we should
> keep them at all. "solidrun,cubox" for all three variants should be
> enough. checkpatch is already choking on every unknown compatible it
> sees and documenting each individual board clearly doesn't scale well.
Yeah, I saw that conversation. I'm inclined to keep the board
compatible strings because they are a useful human readable globally
unique board identifier. I suggest we fix checkpatch to not barf on the
board compatible strings.
thx,
Jason.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 16:38 ` Jason Cooper
0 siblings, 0 replies; 36+ messages in thread
From: Jason Cooper @ 2014-05-27 16:38 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Andrew Lunn, Gregory Clement, devicetree,
linux-arm-kernel, linux-kernel
On Tue, May 27, 2014 at 06:30:41PM +0200, Sebastian Hesselbarth wrote:
...
> About the board specific compatibles, I am not so sure if we should
> keep them at all. "solidrun,cubox" for all three variants should be
> enough. checkpatch is already choking on every unknown compatible it
> sees and documenting each individual board clearly doesn't scale well.
Yeah, I saw that conversation. I'm inclined to keep the board
compatible strings because they are a useful human readable globally
unique board identifier. I suggest we fix checkpatch to not barf on the
board compatible strings.
thx,
Jason.
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 17:02 ` Olof Johansson
0 siblings, 0 replies; 36+ messages in thread
From: Olof Johansson @ 2014-05-27 17:02 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 27, 2014 at 9:30 AM, Sebastian Hesselbarth
<sebastian.hesselbarth@gmail.com> wrote:
> On 05/27/2014 06:11 PM, Jason Cooper wrote:
>>
>> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
>>>
>>> As Mainlining effort for SolidRun CuBox has been carried out on the
>>> Engineering Sample, the board DTS was reflecting this. Actually,
>>> SolidRun CuBox comes in three different variants: Engineering Sample
>>> (ES),
>>> production with 1GB RAM (1G), and production with 2GB RAM (2G).
>>>
>>> Therefore, we split the current dove-cubox.dts into a common board
>>> include
>>> and one board dts for each of the above variants.
>>>
>>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>>> ---
>
> [...]
>
>>> diff --git a/arch/arm/boot/dts/dove-cubox-1g.dts
>>> b/arch/arm/boot/dts/dove-cubox-1g.dts
>>> new file mode 100644
>>> index 000000000000..eebd3f7ca7e6
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/dove-cubox-1g.dts
>>> @@ -0,0 +1,17 @@
>>> +/dts-v1/;
>>> +
>>> +#include "dove-cubox.dtsi"
>>> +
>>> +/ {
>>> + model = "SolidRun CuBox (1G)";
>>> + compatible = "solidrun,cubox-1g", "solidrun,cubox",
>>> "marvell,dove";
>>> +
>>> + memory {
>>> + device_type = "memory";
>>> + reg = <0x00000000 0x40000000>;
>>> + };
>>> +
>>> + chosen {
>>> + bootargs = "console=ttyS0,115200n8 earlyprintk";
>>> + };
>>> +};
>>> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts
>>> b/arch/arm/boot/dts/dove-cubox-2g.dts
>>> new file mode 100644
>>> index 000000000000..513b6a68eba3
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
>>> @@ -0,0 +1,17 @@
>>> +/dts-v1/;
>>> +
>>> +#include "dove-cubox.dtsi"
>>> +
>>> +/ {
>>> + model = "SolidRun CuBox (2G)";
>>> + compatible = "solidrun,cubox-2g", "solidrun,cubox",
>>> "marvell,dove";
>>> +
>>> + memory {
>>> + device_type = "memory";
>>> + reg = <0x00000000 0x80000000>;
>>
>>
>> Do you anticipate any other differences between the 1G and the 2G?
>> Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
>> should be setting the amount of RAM at boottime anyway.
>
>
> No, there is no known difference between 1G and 2G except doubled RAM.
> I'll squash the two back into a single non-ES dts.
>
> About the board specific compatibles, I am not so sure if we should
> keep them at all. "solidrun,cubox" for all three variants should be
> enough. checkpatch is already choking on every unknown compatible it
> sees and documenting each individual board clearly doesn't scale well.
Yeah, I agree -- but I'd say the scaling problem is with checkpatch.
It's silly to require every single small board variant to be
documented, especially in cases where the dts is self-documenting such
as this. If anything, there should be a script that can be used to
scrape this info and build the docs from compat+model info.
It's not a bad idea to add a more specific compatible. if you think
you want a separate model string, then you should probably have a
separate compatible (but keep lower-order ones so that there's no
difference from the kernel point of view which will just match the
more generic one).
-Olof
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 17:02 ` Olof Johansson
0 siblings, 0 replies; 36+ messages in thread
From: Olof Johansson @ 2014-05-27 17:02 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Jason Cooper, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Russell King, Andrew Lunn, Gregory Clement,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
On Tue, May 27, 2014 at 9:30 AM, Sebastian Hesselbarth
<sebastian.hesselbarth@gmail.com> wrote:
> On 05/27/2014 06:11 PM, Jason Cooper wrote:
>>
>> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
>>>
>>> As Mainlining effort for SolidRun CuBox has been carried out on the
>>> Engineering Sample, the board DTS was reflecting this. Actually,
>>> SolidRun CuBox comes in three different variants: Engineering Sample
>>> (ES),
>>> production with 1GB RAM (1G), and production with 2GB RAM (2G).
>>>
>>> Therefore, we split the current dove-cubox.dts into a common board
>>> include
>>> and one board dts for each of the above variants.
>>>
>>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>>> ---
>
> [...]
>
>>> diff --git a/arch/arm/boot/dts/dove-cubox-1g.dts
>>> b/arch/arm/boot/dts/dove-cubox-1g.dts
>>> new file mode 100644
>>> index 000000000000..eebd3f7ca7e6
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/dove-cubox-1g.dts
>>> @@ -0,0 +1,17 @@
>>> +/dts-v1/;
>>> +
>>> +#include "dove-cubox.dtsi"
>>> +
>>> +/ {
>>> + model = "SolidRun CuBox (1G)";
>>> + compatible = "solidrun,cubox-1g", "solidrun,cubox",
>>> "marvell,dove";
>>> +
>>> + memory {
>>> + device_type = "memory";
>>> + reg = <0x00000000 0x40000000>;
>>> + };
>>> +
>>> + chosen {
>>> + bootargs = "console=ttyS0,115200n8 earlyprintk";
>>> + };
>>> +};
>>> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts
>>> b/arch/arm/boot/dts/dove-cubox-2g.dts
>>> new file mode 100644
>>> index 000000000000..513b6a68eba3
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
>>> @@ -0,0 +1,17 @@
>>> +/dts-v1/;
>>> +
>>> +#include "dove-cubox.dtsi"
>>> +
>>> +/ {
>>> + model = "SolidRun CuBox (2G)";
>>> + compatible = "solidrun,cubox-2g", "solidrun,cubox",
>>> "marvell,dove";
>>> +
>>> + memory {
>>> + device_type = "memory";
>>> + reg = <0x00000000 0x80000000>;
>>
>>
>> Do you anticipate any other differences between the 1G and the 2G?
>> Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
>> should be setting the amount of RAM at boottime anyway.
>
>
> No, there is no known difference between 1G and 2G except doubled RAM.
> I'll squash the two back into a single non-ES dts.
>
> About the board specific compatibles, I am not so sure if we should
> keep them at all. "solidrun,cubox" for all three variants should be
> enough. checkpatch is already choking on every unknown compatible it
> sees and documenting each individual board clearly doesn't scale well.
Yeah, I agree -- but I'd say the scaling problem is with checkpatch.
It's silly to require every single small board variant to be
documented, especially in cases where the dts is self-documenting such
as this. If anything, there should be a script that can be used to
scrape this info and build the docs from compat+model info.
It's not a bad idea to add a more specific compatible. if you think
you want a separate model string, then you should probably have a
separate compatible (but keep lower-order ones so that there's no
difference from the kernel point of view which will just match the
more generic one).
-Olof
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 17:02 ` Olof Johansson
0 siblings, 0 replies; 36+ messages in thread
From: Olof Johansson @ 2014-05-27 17:02 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Jason Cooper, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Russell King, Andrew Lunn, Gregory Clement,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
On Tue, May 27, 2014 at 9:30 AM, Sebastian Hesselbarth
<sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 05/27/2014 06:11 PM, Jason Cooper wrote:
>>
>> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
>>>
>>> As Mainlining effort for SolidRun CuBox has been carried out on the
>>> Engineering Sample, the board DTS was reflecting this. Actually,
>>> SolidRun CuBox comes in three different variants: Engineering Sample
>>> (ES),
>>> production with 1GB RAM (1G), and production with 2GB RAM (2G).
>>>
>>> Therefore, we split the current dove-cubox.dts into a common board
>>> include
>>> and one board dts for each of the above variants.
>>>
>>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> ---
>
> [...]
>
>>> diff --git a/arch/arm/boot/dts/dove-cubox-1g.dts
>>> b/arch/arm/boot/dts/dove-cubox-1g.dts
>>> new file mode 100644
>>> index 000000000000..eebd3f7ca7e6
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/dove-cubox-1g.dts
>>> @@ -0,0 +1,17 @@
>>> +/dts-v1/;
>>> +
>>> +#include "dove-cubox.dtsi"
>>> +
>>> +/ {
>>> + model = "SolidRun CuBox (1G)";
>>> + compatible = "solidrun,cubox-1g", "solidrun,cubox",
>>> "marvell,dove";
>>> +
>>> + memory {
>>> + device_type = "memory";
>>> + reg = <0x00000000 0x40000000>;
>>> + };
>>> +
>>> + chosen {
>>> + bootargs = "console=ttyS0,115200n8 earlyprintk";
>>> + };
>>> +};
>>> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts
>>> b/arch/arm/boot/dts/dove-cubox-2g.dts
>>> new file mode 100644
>>> index 000000000000..513b6a68eba3
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
>>> @@ -0,0 +1,17 @@
>>> +/dts-v1/;
>>> +
>>> +#include "dove-cubox.dtsi"
>>> +
>>> +/ {
>>> + model = "SolidRun CuBox (2G)";
>>> + compatible = "solidrun,cubox-2g", "solidrun,cubox",
>>> "marvell,dove";
>>> +
>>> + memory {
>>> + device_type = "memory";
>>> + reg = <0x00000000 0x80000000>;
>>
>>
>> Do you anticipate any other differences between the 1G and the 2G?
>> Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
>> should be setting the amount of RAM at boottime anyway.
>
>
> No, there is no known difference between 1G and 2G except doubled RAM.
> I'll squash the two back into a single non-ES dts.
>
> About the board specific compatibles, I am not so sure if we should
> keep them at all. "solidrun,cubox" for all three variants should be
> enough. checkpatch is already choking on every unknown compatible it
> sees and documenting each individual board clearly doesn't scale well.
Yeah, I agree -- but I'd say the scaling problem is with checkpatch.
It's silly to require every single small board variant to be
documented, especially in cases where the dts is self-documenting such
as this. If anything, there should be a script that can be used to
scrape this info and build the docs from compat+model info.
It's not a bad idea to add a more specific compatible. if you think
you want a separate model string, then you should probably have a
separate compatible (but keep lower-order ones so that there's no
difference from the kernel point of view which will just match the
more generic one).
-Olof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
2014-05-27 16:11 ` Jason Cooper
@ 2014-05-27 17:28 ` Sebastian Hesselbarth
-1 siblings, 0 replies; 36+ messages in thread
From: Sebastian Hesselbarth @ 2014-05-27 17:28 UTC (permalink / raw)
To: linux-arm-kernel
On 05/27/2014 06:11 PM, Jason Cooper wrote:
> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
>> As Mainlining effort for SolidRun CuBox has been carried out on the
>> Engineering Sample, the board DTS was reflecting this. Actually,
>> SolidRun CuBox comes in three different variants: Engineering Sample (ES),
>> production with 1GB RAM (1G), and production with 2GB RAM (2G).
>>
>> Therefore, we split the current dove-cubox.dts into a common board include
>> and one board dts for each of the above variants.
>>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>> ---
[...]
>> ---
>> arch/arm/boot/dts/Makefile | 4 +++-
>> arch/arm/boot/dts/dove-cubox-1g.dts | 17 ++++++++++++++++
>> arch/arm/boot/dts/dove-cubox-2g.dts | 17 ++++++++++++++++
>> arch/arm/boot/dts/dove-cubox-es.dts | 23 ++++++++++++++++++++++
>> .../boot/dts/{dove-cubox.dts => dove-cubox.dtsi} | 17 ----------------
>> 5 files changed, 60 insertions(+), 18 deletions(-)
>> create mode 100644 arch/arm/boot/dts/dove-cubox-1g.dts
>> create mode 100644 arch/arm/boot/dts/dove-cubox-2g.dts
>> create mode 100644 arch/arm/boot/dts/dove-cubox-es.dts
>> rename arch/arm/boot/dts/{dove-cubox.dts => dove-cubox.dtsi} (86%)
>>
[...]
>> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts b/arch/arm/boot/dts/dove-cubox-2g.dts
>> new file mode 100644
>> index 000000000000..513b6a68eba3
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
>> @@ -0,0 +1,17 @@
>> +/dts-v1/;
>> +
>> +#include "dove-cubox.dtsi"
>> +
>> +/ {
>> + model = "SolidRun CuBox (2G)";
>> + compatible = "solidrun,cubox-2g", "solidrun,cubox", "marvell,dove";
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x00000000 0x80000000>;
>
> Do you anticipate any other differences between the 1G and the 2G?
> Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
> should be setting the amount of RAM at boottime anyway.
Given the minor differences between ES and production, instead of
dove-cubox-common.dtsi
+--> dove-cubox.dts (production)
+--> dove-cubos-es.dts (engineering sample)
we could also just have an "overlay" for the ES like
dove-cubox.dts (production)
+--> dove-cubox-es.dts (engineering sample)
It is not used commonly until now, maybe just a matter of taste.
Is there any version you prefer?
Sebastian
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 17:28 ` Sebastian Hesselbarth
0 siblings, 0 replies; 36+ messages in thread
From: Sebastian Hesselbarth @ 2014-05-27 17:28 UTC (permalink / raw)
To: Jason Cooper
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Andrew Lunn, Gregory Clement, devicetree,
linux-arm-kernel, linux-kernel
On 05/27/2014 06:11 PM, Jason Cooper wrote:
> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
>> As Mainlining effort for SolidRun CuBox has been carried out on the
>> Engineering Sample, the board DTS was reflecting this. Actually,
>> SolidRun CuBox comes in three different variants: Engineering Sample (ES),
>> production with 1GB RAM (1G), and production with 2GB RAM (2G).
>>
>> Therefore, we split the current dove-cubox.dts into a common board include
>> and one board dts for each of the above variants.
>>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>> ---
[...]
>> ---
>> arch/arm/boot/dts/Makefile | 4 +++-
>> arch/arm/boot/dts/dove-cubox-1g.dts | 17 ++++++++++++++++
>> arch/arm/boot/dts/dove-cubox-2g.dts | 17 ++++++++++++++++
>> arch/arm/boot/dts/dove-cubox-es.dts | 23 ++++++++++++++++++++++
>> .../boot/dts/{dove-cubox.dts => dove-cubox.dtsi} | 17 ----------------
>> 5 files changed, 60 insertions(+), 18 deletions(-)
>> create mode 100644 arch/arm/boot/dts/dove-cubox-1g.dts
>> create mode 100644 arch/arm/boot/dts/dove-cubox-2g.dts
>> create mode 100644 arch/arm/boot/dts/dove-cubox-es.dts
>> rename arch/arm/boot/dts/{dove-cubox.dts => dove-cubox.dtsi} (86%)
>>
[...]
>> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts b/arch/arm/boot/dts/dove-cubox-2g.dts
>> new file mode 100644
>> index 000000000000..513b6a68eba3
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
>> @@ -0,0 +1,17 @@
>> +/dts-v1/;
>> +
>> +#include "dove-cubox.dtsi"
>> +
>> +/ {
>> + model = "SolidRun CuBox (2G)";
>> + compatible = "solidrun,cubox-2g", "solidrun,cubox", "marvell,dove";
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x00000000 0x80000000>;
>
> Do you anticipate any other differences between the 1G and the 2G?
> Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
> should be setting the amount of RAM at boottime anyway.
Given the minor differences between ES and production, instead of
dove-cubox-common.dtsi
+--> dove-cubox.dts (production)
+--> dove-cubos-es.dts (engineering sample)
we could also just have an "overlay" for the ES like
dove-cubox.dts (production)
+--> dove-cubox-es.dts (engineering sample)
It is not used commonly until now, maybe just a matter of taste.
Is there any version you prefer?
Sebastian
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 21:35 ` Jason Cooper
0 siblings, 0 replies; 36+ messages in thread
From: Jason Cooper @ 2014-05-27 21:35 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 27, 2014 at 07:28:09PM +0200, Sebastian Hesselbarth wrote:
> On 05/27/2014 06:11 PM, Jason Cooper wrote:
> > On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
> >> As Mainlining effort for SolidRun CuBox has been carried out on the
> >> Engineering Sample, the board DTS was reflecting this. Actually,
> >> SolidRun CuBox comes in three different variants: Engineering Sample (ES),
> >> production with 1GB RAM (1G), and production with 2GB RAM (2G).
> >>
> >> Therefore, we split the current dove-cubox.dts into a common board include
> >> and one board dts for each of the above variants.
> >>
> >> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> >> ---
> [...]
> >> ---
> >> arch/arm/boot/dts/Makefile | 4 +++-
> >> arch/arm/boot/dts/dove-cubox-1g.dts | 17 ++++++++++++++++
> >> arch/arm/boot/dts/dove-cubox-2g.dts | 17 ++++++++++++++++
> >> arch/arm/boot/dts/dove-cubox-es.dts | 23 ++++++++++++++++++++++
> >> .../boot/dts/{dove-cubox.dts => dove-cubox.dtsi} | 17 ----------------
> >> 5 files changed, 60 insertions(+), 18 deletions(-)
> >> create mode 100644 arch/arm/boot/dts/dove-cubox-1g.dts
> >> create mode 100644 arch/arm/boot/dts/dove-cubox-2g.dts
> >> create mode 100644 arch/arm/boot/dts/dove-cubox-es.dts
> >> rename arch/arm/boot/dts/{dove-cubox.dts => dove-cubox.dtsi} (86%)
> >>
> [...]
> >> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts b/arch/arm/boot/dts/dove-cubox-2g.dts
> >> new file mode 100644
> >> index 000000000000..513b6a68eba3
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
> >> @@ -0,0 +1,17 @@
> >> +/dts-v1/;
> >> +
> >> +#include "dove-cubox.dtsi"
> >> +
> >> +/ {
> >> + model = "SolidRun CuBox (2G)";
> >> + compatible = "solidrun,cubox-2g", "solidrun,cubox", "marvell,dove";
> >> +
> >> + memory {
> >> + device_type = "memory";
> >> + reg = <0x00000000 0x80000000>;
> >
> > Do you anticipate any other differences between the 1G and the 2G?
> > Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
> > should be setting the amount of RAM at boottime anyway.
>
> Given the minor differences between ES and production, instead of
>
> dove-cubox-common.dtsi
> +--> dove-cubox.dts (production)
> +--> dove-cubos-es.dts (engineering sample)
>
> we could also just have an "overlay" for the ES like
>
> dove-cubox.dts (production)
> +--> dove-cubox-es.dts (engineering sample)
>
> It is not used commonly until now, maybe just a matter of taste.
>
> Is there any version you prefer?
iiuc, overlays were intended for daughterboard (capes, etc) specific
info. It may be useful here, but I'd like to hear from the DT
maintainers how they want it used. eg: most popular first, like you
have it, or oldest first
dove-cubox-es.dts
+--> dove-cubox.dts
There's also what to do with the older files using #include...
In short, I'd prefer to stick to the old method until we have a good
reason to move to overlays and a recommended way to execute that.*
thx,
Jason.
* There's also the distinct possibility this was decided/announced and I
missed it...
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 21:35 ` Jason Cooper
0 siblings, 0 replies; 36+ messages in thread
From: Jason Cooper @ 2014-05-27 21:35 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Andrew Lunn, Gregory Clement, devicetree,
linux-arm-kernel, linux-kernel
On Tue, May 27, 2014 at 07:28:09PM +0200, Sebastian Hesselbarth wrote:
> On 05/27/2014 06:11 PM, Jason Cooper wrote:
> > On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
> >> As Mainlining effort for SolidRun CuBox has been carried out on the
> >> Engineering Sample, the board DTS was reflecting this. Actually,
> >> SolidRun CuBox comes in three different variants: Engineering Sample (ES),
> >> production with 1GB RAM (1G), and production with 2GB RAM (2G).
> >>
> >> Therefore, we split the current dove-cubox.dts into a common board include
> >> and one board dts for each of the above variants.
> >>
> >> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> >> ---
> [...]
> >> ---
> >> arch/arm/boot/dts/Makefile | 4 +++-
> >> arch/arm/boot/dts/dove-cubox-1g.dts | 17 ++++++++++++++++
> >> arch/arm/boot/dts/dove-cubox-2g.dts | 17 ++++++++++++++++
> >> arch/arm/boot/dts/dove-cubox-es.dts | 23 ++++++++++++++++++++++
> >> .../boot/dts/{dove-cubox.dts => dove-cubox.dtsi} | 17 ----------------
> >> 5 files changed, 60 insertions(+), 18 deletions(-)
> >> create mode 100644 arch/arm/boot/dts/dove-cubox-1g.dts
> >> create mode 100644 arch/arm/boot/dts/dove-cubox-2g.dts
> >> create mode 100644 arch/arm/boot/dts/dove-cubox-es.dts
> >> rename arch/arm/boot/dts/{dove-cubox.dts => dove-cubox.dtsi} (86%)
> >>
> [...]
> >> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts b/arch/arm/boot/dts/dove-cubox-2g.dts
> >> new file mode 100644
> >> index 000000000000..513b6a68eba3
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
> >> @@ -0,0 +1,17 @@
> >> +/dts-v1/;
> >> +
> >> +#include "dove-cubox.dtsi"
> >> +
> >> +/ {
> >> + model = "SolidRun CuBox (2G)";
> >> + compatible = "solidrun,cubox-2g", "solidrun,cubox", "marvell,dove";
> >> +
> >> + memory {
> >> + device_type = "memory";
> >> + reg = <0x00000000 0x80000000>;
> >
> > Do you anticipate any other differences between the 1G and the 2G?
> > Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
> > should be setting the amount of RAM at boottime anyway.
>
> Given the minor differences between ES and production, instead of
>
> dove-cubox-common.dtsi
> +--> dove-cubox.dts (production)
> +--> dove-cubos-es.dts (engineering sample)
>
> we could also just have an "overlay" for the ES like
>
> dove-cubox.dts (production)
> +--> dove-cubox-es.dts (engineering sample)
>
> It is not used commonly until now, maybe just a matter of taste.
>
> Is there any version you prefer?
iiuc, overlays were intended for daughterboard (capes, etc) specific
info. It may be useful here, but I'd like to hear from the DT
maintainers how they want it used. eg: most popular first, like you
have it, or oldest first
dove-cubox-es.dts
+--> dove-cubox.dts
There's also what to do with the older files using #include...
In short, I'd prefer to stick to the old method until we have a good
reason to move to overlays and a recommended way to execute that.*
thx,
Jason.
* There's also the distinct possibility this was decided/announced and I
missed it...
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 21:35 ` Jason Cooper
0 siblings, 0 replies; 36+ messages in thread
From: Jason Cooper @ 2014-05-27 21:35 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Andrew Lunn, Gregory Clement,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On Tue, May 27, 2014 at 07:28:09PM +0200, Sebastian Hesselbarth wrote:
> On 05/27/2014 06:11 PM, Jason Cooper wrote:
> > On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
> >> As Mainlining effort for SolidRun CuBox has been carried out on the
> >> Engineering Sample, the board DTS was reflecting this. Actually,
> >> SolidRun CuBox comes in three different variants: Engineering Sample (ES),
> >> production with 1GB RAM (1G), and production with 2GB RAM (2G).
> >>
> >> Therefore, we split the current dove-cubox.dts into a common board include
> >> and one board dts for each of the above variants.
> >>
> >> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> ---
> [...]
> >> ---
> >> arch/arm/boot/dts/Makefile | 4 +++-
> >> arch/arm/boot/dts/dove-cubox-1g.dts | 17 ++++++++++++++++
> >> arch/arm/boot/dts/dove-cubox-2g.dts | 17 ++++++++++++++++
> >> arch/arm/boot/dts/dove-cubox-es.dts | 23 ++++++++++++++++++++++
> >> .../boot/dts/{dove-cubox.dts => dove-cubox.dtsi} | 17 ----------------
> >> 5 files changed, 60 insertions(+), 18 deletions(-)
> >> create mode 100644 arch/arm/boot/dts/dove-cubox-1g.dts
> >> create mode 100644 arch/arm/boot/dts/dove-cubox-2g.dts
> >> create mode 100644 arch/arm/boot/dts/dove-cubox-es.dts
> >> rename arch/arm/boot/dts/{dove-cubox.dts => dove-cubox.dtsi} (86%)
> >>
> [...]
> >> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts b/arch/arm/boot/dts/dove-cubox-2g.dts
> >> new file mode 100644
> >> index 000000000000..513b6a68eba3
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
> >> @@ -0,0 +1,17 @@
> >> +/dts-v1/;
> >> +
> >> +#include "dove-cubox.dtsi"
> >> +
> >> +/ {
> >> + model = "SolidRun CuBox (2G)";
> >> + compatible = "solidrun,cubox-2g", "solidrun,cubox", "marvell,dove";
> >> +
> >> + memory {
> >> + device_type = "memory";
> >> + reg = <0x00000000 0x80000000>;
> >
> > Do you anticipate any other differences between the 1G and the 2G?
> > Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
> > should be setting the amount of RAM at boottime anyway.
>
> Given the minor differences between ES and production, instead of
>
> dove-cubox-common.dtsi
> +--> dove-cubox.dts (production)
> +--> dove-cubos-es.dts (engineering sample)
>
> we could also just have an "overlay" for the ES like
>
> dove-cubox.dts (production)
> +--> dove-cubox-es.dts (engineering sample)
>
> It is not used commonly until now, maybe just a matter of taste.
>
> Is there any version you prefer?
iiuc, overlays were intended for daughterboard (capes, etc) specific
info. It may be useful here, but I'd like to hear from the DT
maintainers how they want it used. eg: most popular first, like you
have it, or oldest first
dove-cubox-es.dts
+--> dove-cubox.dts
There's also what to do with the older files using #include...
In short, I'd prefer to stick to the old method until we have a good
reason to move to overlays and a recommended way to execute that.*
thx,
Jason.
* There's also the distinct possibility this was decided/announced and I
missed it...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 21:50 ` Sebastian Hesselbarth
0 siblings, 0 replies; 36+ messages in thread
From: Sebastian Hesselbarth @ 2014-05-27 21:50 UTC (permalink / raw)
To: linux-arm-kernel
On 05/27/2014 11:35 PM, Jason Cooper wrote:
> On Tue, May 27, 2014 at 07:28:09PM +0200, Sebastian Hesselbarth wrote:
>> On 05/27/2014 06:11 PM, Jason Cooper wrote:
>>> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
>>>> As Mainlining effort for SolidRun CuBox has been carried out on the
>>>> Engineering Sample, the board DTS was reflecting this. Actually,
>>>> SolidRun CuBox comes in three different variants: Engineering Sample (ES),
>>>> production with 1GB RAM (1G), and production with 2GB RAM (2G).
>>>>
>>>> Therefore, we split the current dove-cubox.dts into a common board include
>>>> and one board dts for each of the above variants.
>>>>
>>>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>>>> ---
>> [...]
>>>> ---
>>>> arch/arm/boot/dts/Makefile | 4 +++-
>>>> arch/arm/boot/dts/dove-cubox-1g.dts | 17 ++++++++++++++++
>>>> arch/arm/boot/dts/dove-cubox-2g.dts | 17 ++++++++++++++++
>>>> arch/arm/boot/dts/dove-cubox-es.dts | 23 ++++++++++++++++++++++
>>>> .../boot/dts/{dove-cubox.dts => dove-cubox.dtsi} | 17 ----------------
>>>> 5 files changed, 60 insertions(+), 18 deletions(-)
>>>> create mode 100644 arch/arm/boot/dts/dove-cubox-1g.dts
>>>> create mode 100644 arch/arm/boot/dts/dove-cubox-2g.dts
>>>> create mode 100644 arch/arm/boot/dts/dove-cubox-es.dts
>>>> rename arch/arm/boot/dts/{dove-cubox.dts => dove-cubox.dtsi} (86%)
>>>>
>> [...]
>>>> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts b/arch/arm/boot/dts/dove-cubox-2g.dts
>>>> new file mode 100644
>>>> index 000000000000..513b6a68eba3
>>>> --- /dev/null
>>>> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
>>>> @@ -0,0 +1,17 @@
>>>> +/dts-v1/;
>>>> +
>>>> +#include "dove-cubox.dtsi"
>>>> +
>>>> +/ {
>>>> + model = "SolidRun CuBox (2G)";
>>>> + compatible = "solidrun,cubox-2g", "solidrun,cubox", "marvell,dove";
>>>> +
>>>> + memory {
>>>> + device_type = "memory";
>>>> + reg = <0x00000000 0x80000000>;
>>>
>>> Do you anticipate any other differences between the 1G and the 2G?
>>> Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
>>> should be setting the amount of RAM at boottime anyway.
>>
>> Given the minor differences between ES and production, instead of
>>
>> dove-cubox-common.dtsi
>> +--> dove-cubox.dts (production)
>> +--> dove-cubos-es.dts (engineering sample)
>>
>> we could also just have an "overlay" for the ES like
>>
>> dove-cubox.dts (production)
>> +--> dove-cubox-es.dts (engineering sample)
>>
>> It is not used commonly until now, maybe just a matter of taste.
>>
>> Is there any version you prefer?
>
> iiuc, overlays were intended for daughterboard (capes, etc) specific
Oh, ok. I guess "overlay" was misleading here. I did not mean dynamic
loading/unloading of dtb but including a dts from another dts.
> info. It may be useful here, but I'd like to hear from the DT
> maintainers how they want it used. eg: most popular first, like you
> have it, or oldest first
>
> dove-cubox-es.dts
> +--> dove-cubox.dts
In the cubox case, this is not possible. ES has a misrouted
card-detection for sdhci, this requires an additional property.
There is no way to remove a property once it is written down in
any of the files included. But you know about that already.
> There's also what to do with the older files using #include...
>
> In short, I'd prefer to stick to the old method until we have a good
> reason to move to overlays and a recommended way to execute that.*
Ok, the old method is straight forward and I keep that in mind. I'll
send a v2 of this using the approach we just talked about to eliminate
any misinterpretations. Just have a look and feel free to request an
"old-method" v3 immediately :P
Sebastian
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 21:50 ` Sebastian Hesselbarth
0 siblings, 0 replies; 36+ messages in thread
From: Sebastian Hesselbarth @ 2014-05-27 21:50 UTC (permalink / raw)
To: Jason Cooper
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Andrew Lunn, Gregory Clement, devicetree,
linux-arm-kernel, linux-kernel
On 05/27/2014 11:35 PM, Jason Cooper wrote:
> On Tue, May 27, 2014 at 07:28:09PM +0200, Sebastian Hesselbarth wrote:
>> On 05/27/2014 06:11 PM, Jason Cooper wrote:
>>> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
>>>> As Mainlining effort for SolidRun CuBox has been carried out on the
>>>> Engineering Sample, the board DTS was reflecting this. Actually,
>>>> SolidRun CuBox comes in three different variants: Engineering Sample (ES),
>>>> production with 1GB RAM (1G), and production with 2GB RAM (2G).
>>>>
>>>> Therefore, we split the current dove-cubox.dts into a common board include
>>>> and one board dts for each of the above variants.
>>>>
>>>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
>>>> ---
>> [...]
>>>> ---
>>>> arch/arm/boot/dts/Makefile | 4 +++-
>>>> arch/arm/boot/dts/dove-cubox-1g.dts | 17 ++++++++++++++++
>>>> arch/arm/boot/dts/dove-cubox-2g.dts | 17 ++++++++++++++++
>>>> arch/arm/boot/dts/dove-cubox-es.dts | 23 ++++++++++++++++++++++
>>>> .../boot/dts/{dove-cubox.dts => dove-cubox.dtsi} | 17 ----------------
>>>> 5 files changed, 60 insertions(+), 18 deletions(-)
>>>> create mode 100644 arch/arm/boot/dts/dove-cubox-1g.dts
>>>> create mode 100644 arch/arm/boot/dts/dove-cubox-2g.dts
>>>> create mode 100644 arch/arm/boot/dts/dove-cubox-es.dts
>>>> rename arch/arm/boot/dts/{dove-cubox.dts => dove-cubox.dtsi} (86%)
>>>>
>> [...]
>>>> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts b/arch/arm/boot/dts/dove-cubox-2g.dts
>>>> new file mode 100644
>>>> index 000000000000..513b6a68eba3
>>>> --- /dev/null
>>>> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
>>>> @@ -0,0 +1,17 @@
>>>> +/dts-v1/;
>>>> +
>>>> +#include "dove-cubox.dtsi"
>>>> +
>>>> +/ {
>>>> + model = "SolidRun CuBox (2G)";
>>>> + compatible = "solidrun,cubox-2g", "solidrun,cubox", "marvell,dove";
>>>> +
>>>> + memory {
>>>> + device_type = "memory";
>>>> + reg = <0x00000000 0x80000000>;
>>>
>>> Do you anticipate any other differences between the 1G and the 2G?
>>> Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
>>> should be setting the amount of RAM at boottime anyway.
>>
>> Given the minor differences between ES and production, instead of
>>
>> dove-cubox-common.dtsi
>> +--> dove-cubox.dts (production)
>> +--> dove-cubos-es.dts (engineering sample)
>>
>> we could also just have an "overlay" for the ES like
>>
>> dove-cubox.dts (production)
>> +--> dove-cubox-es.dts (engineering sample)
>>
>> It is not used commonly until now, maybe just a matter of taste.
>>
>> Is there any version you prefer?
>
> iiuc, overlays were intended for daughterboard (capes, etc) specific
Oh, ok. I guess "overlay" was misleading here. I did not mean dynamic
loading/unloading of dtb but including a dts from another dts.
> info. It may be useful here, but I'd like to hear from the DT
> maintainers how they want it used. eg: most popular first, like you
> have it, or oldest first
>
> dove-cubox-es.dts
> +--> dove-cubox.dts
In the cubox case, this is not possible. ES has a misrouted
card-detection for sdhci, this requires an additional property.
There is no way to remove a property once it is written down in
any of the files included. But you know about that already.
> There's also what to do with the older files using #include...
>
> In short, I'd prefer to stick to the old method until we have a good
> reason to move to overlays and a recommended way to execute that.*
Ok, the old method is straight forward and I keep that in mind. I'll
send a v2 of this using the approach we just talked about to eliminate
any misinterpretations. Just have a look and feel free to request an
"old-method" v3 immediately :P
Sebastian
^ permalink raw reply [flat|nested] 36+ messages in thread* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 21:50 ` Sebastian Hesselbarth
0 siblings, 0 replies; 36+ messages in thread
From: Sebastian Hesselbarth @ 2014-05-27 21:50 UTC (permalink / raw)
To: Jason Cooper
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Andrew Lunn, Gregory Clement,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On 05/27/2014 11:35 PM, Jason Cooper wrote:
> On Tue, May 27, 2014 at 07:28:09PM +0200, Sebastian Hesselbarth wrote:
>> On 05/27/2014 06:11 PM, Jason Cooper wrote:
>>> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
>>>> As Mainlining effort for SolidRun CuBox has been carried out on the
>>>> Engineering Sample, the board DTS was reflecting this. Actually,
>>>> SolidRun CuBox comes in three different variants: Engineering Sample (ES),
>>>> production with 1GB RAM (1G), and production with 2GB RAM (2G).
>>>>
>>>> Therefore, we split the current dove-cubox.dts into a common board include
>>>> and one board dts for each of the above variants.
>>>>
>>>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> ---
>> [...]
>>>> ---
>>>> arch/arm/boot/dts/Makefile | 4 +++-
>>>> arch/arm/boot/dts/dove-cubox-1g.dts | 17 ++++++++++++++++
>>>> arch/arm/boot/dts/dove-cubox-2g.dts | 17 ++++++++++++++++
>>>> arch/arm/boot/dts/dove-cubox-es.dts | 23 ++++++++++++++++++++++
>>>> .../boot/dts/{dove-cubox.dts => dove-cubox.dtsi} | 17 ----------------
>>>> 5 files changed, 60 insertions(+), 18 deletions(-)
>>>> create mode 100644 arch/arm/boot/dts/dove-cubox-1g.dts
>>>> create mode 100644 arch/arm/boot/dts/dove-cubox-2g.dts
>>>> create mode 100644 arch/arm/boot/dts/dove-cubox-es.dts
>>>> rename arch/arm/boot/dts/{dove-cubox.dts => dove-cubox.dtsi} (86%)
>>>>
>> [...]
>>>> diff --git a/arch/arm/boot/dts/dove-cubox-2g.dts b/arch/arm/boot/dts/dove-cubox-2g.dts
>>>> new file mode 100644
>>>> index 000000000000..513b6a68eba3
>>>> --- /dev/null
>>>> +++ b/arch/arm/boot/dts/dove-cubox-2g.dts
>>>> @@ -0,0 +1,17 @@
>>>> +/dts-v1/;
>>>> +
>>>> +#include "dove-cubox.dtsi"
>>>> +
>>>> +/ {
>>>> + model = "SolidRun CuBox (2G)";
>>>> + compatible = "solidrun,cubox-2g", "solidrun,cubox", "marvell,dove";
>>>> +
>>>> + memory {
>>>> + device_type = "memory";
>>>> + reg = <0x00000000 0x80000000>;
>>>
>>> Do you anticipate any other differences between the 1G and the 2G?
>>> Otherwise, I'm inclined to just have a "solidrun,cubox". The bootloader
>>> should be setting the amount of RAM at boottime anyway.
>>
>> Given the minor differences between ES and production, instead of
>>
>> dove-cubox-common.dtsi
>> +--> dove-cubox.dts (production)
>> +--> dove-cubos-es.dts (engineering sample)
>>
>> we could also just have an "overlay" for the ES like
>>
>> dove-cubox.dts (production)
>> +--> dove-cubox-es.dts (engineering sample)
>>
>> It is not used commonly until now, maybe just a matter of taste.
>>
>> Is there any version you prefer?
>
> iiuc, overlays were intended for daughterboard (capes, etc) specific
Oh, ok. I guess "overlay" was misleading here. I did not mean dynamic
loading/unloading of dtb but including a dts from another dts.
> info. It may be useful here, but I'd like to hear from the DT
> maintainers how they want it used. eg: most popular first, like you
> have it, or oldest first
>
> dove-cubox-es.dts
> +--> dove-cubox.dts
In the cubox case, this is not possible. ES has a misrouted
card-detection for sdhci, this requires an additional property.
There is no way to remove a property once it is written down in
any of the files included. But you know about that already.
> There's also what to do with the older files using #include...
>
> In short, I'd prefer to stick to the old method until we have a good
> reason to move to overlays and a recommended way to execute that.*
Ok, the old method is straight forward and I keep that in mind. I'll
send a v2 of this using the approach we just talked about to eliminate
any misinterpretations. Just have a look and feel free to request an
"old-method" v3 immediately :P
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 36+ messages in thread* [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 22:24 ` Heiko Stübner
0 siblings, 0 replies; 36+ messages in thread
From: Heiko Stübner @ 2014-05-27 22:24 UTC (permalink / raw)
To: linux-arm-kernel
Am Dienstag, 27. Mai 2014, 23:50:29 schrieb Sebastian Hesselbarth:
> On 05/27/2014 11:35 PM, Jason Cooper wrote:
> > On Tue, May 27, 2014 at 07:28:09PM +0200, Sebastian Hesselbarth wrote:
> >> On 05/27/2014 06:11 PM, Jason Cooper wrote:
> >>> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
> > info. It may be useful here, but I'd like to hear from the DT
> > maintainers how they want it used. eg: most popular first, like you
> > have it, or oldest first
> >
> > dove-cubox-es.dts
> > +--> dove-cubox.dts
>
> In the cubox case, this is not possible. ES has a misrouted
> card-detection for sdhci, this requires an additional property.
> There is no way to remove a property once it is written down in
> any of the files included. But you know about that already.
dtc knows "/delete-property/" [0], but I may be missing something here.
[0] https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-August/018169.html
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 22:24 ` Heiko Stübner
0 siblings, 0 replies; 36+ messages in thread
From: Heiko Stübner @ 2014-05-27 22:24 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sebastian Hesselbarth, Jason Cooper, Mark Rutland, Andrew Lunn,
Russell King, Pawel Moll, Ian Campbell, linux-kernel, devicetree,
Rob Herring, Kumar Gala, Gregory Clement
Am Dienstag, 27. Mai 2014, 23:50:29 schrieb Sebastian Hesselbarth:
> On 05/27/2014 11:35 PM, Jason Cooper wrote:
> > On Tue, May 27, 2014 at 07:28:09PM +0200, Sebastian Hesselbarth wrote:
> >> On 05/27/2014 06:11 PM, Jason Cooper wrote:
> >>> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
> > info. It may be useful here, but I'd like to hear from the DT
> > maintainers how they want it used. eg: most popular first, like you
> > have it, or oldest first
> >
> > dove-cubox-es.dts
> > +--> dove-cubox.dts
>
> In the cubox case, this is not possible. ES has a misrouted
> card-detection for sdhci, this requires an additional property.
> There is no way to remove a property once it is written down in
> any of the files included. But you know about that already.
dtc knows "/delete-property/" [0], but I may be missing something here.
[0] https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-August/018169.html
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 22:24 ` Heiko Stübner
0 siblings, 0 replies; 36+ messages in thread
From: Heiko Stübner @ 2014-05-27 22:24 UTC (permalink / raw)
To: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sebastian Hesselbarth, Jason Cooper, Mark Rutland, Andrew Lunn,
Russell King, Pawel Moll, Ian Campbell,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Kumar Gala,
Gregory Clement
Am Dienstag, 27. Mai 2014, 23:50:29 schrieb Sebastian Hesselbarth:
> On 05/27/2014 11:35 PM, Jason Cooper wrote:
> > On Tue, May 27, 2014 at 07:28:09PM +0200, Sebastian Hesselbarth wrote:
> >> On 05/27/2014 06:11 PM, Jason Cooper wrote:
> >>> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
> > info. It may be useful here, but I'd like to hear from the DT
> > maintainers how they want it used. eg: most popular first, like you
> > have it, or oldest first
> >
> > dove-cubox-es.dts
> > +--> dove-cubox.dts
>
> In the cubox case, this is not possible. ES has a misrouted
> card-detection for sdhci, this requires an additional property.
> There is no way to remove a property once it is written down in
> any of the files included. But you know about that already.
dtc knows "/delete-property/" [0], but I may be missing something here.
[0] https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-August/018169.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
2014-05-27 22:24 ` Heiko Stübner
(?)
@ 2014-05-27 22:37 ` Sebastian Hesselbarth
-1 siblings, 0 replies; 36+ messages in thread
From: Sebastian Hesselbarth @ 2014-05-27 22:37 UTC (permalink / raw)
To: linux-arm-kernel
On 05/28/2014 12:24 AM, Heiko St?bner wrote:
> Am Dienstag, 27. Mai 2014, 23:50:29 schrieb Sebastian Hesselbarth:
>> On 05/27/2014 11:35 PM, Jason Cooper wrote:
>>> On Tue, May 27, 2014 at 07:28:09PM +0200, Sebastian Hesselbarth wrote:
>>>> On 05/27/2014 06:11 PM, Jason Cooper wrote:
>>>>> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
>>> info. It may be useful here, but I'd like to hear from the DT
>>> maintainers how they want it used. eg: most popular first, like you
>>> have it, or oldest first
>>>
>>> dove-cubox-es.dts
>>> +--> dove-cubox.dts
>>
>> In the cubox case, this is not possible. ES has a misrouted
>> card-detection for sdhci, this requires an additional property.
>> There is no way to remove a property once it is written down in
>> any of the files included. But you know about that already.
>
> dtc knows "/delete-property/" [0], but I may be missing something here.
>
> [0] https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-August/018169.html
Heiko,
thanks for the link, I must have completely ignored it! Now that I
think about it, it may be very useful for kirkwood-98xsomething.dtsi
that is a special Kirkwood with a bunch of IP removed (but only some
boards). That way we could consolidate the common SoCs and use
/delete-node/ for the special case SoC.
Anyway, for CuBox ES, I either prefer the v2 approach just send - or
have a cubox-common.dtsi with two board dts for 1G and ES each. We use
this structure a lot and Andrew showed it even works for up to 5 or 10
different variants.
Sebastian
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 22:37 ` Sebastian Hesselbarth
0 siblings, 0 replies; 36+ messages in thread
From: Sebastian Hesselbarth @ 2014-05-27 22:37 UTC (permalink / raw)
To: Heiko Stübner, linux-arm-kernel
Cc: Jason Cooper, Mark Rutland, Andrew Lunn, Russell King, Pawel Moll,
Ian Campbell, linux-kernel, devicetree, Rob Herring, Kumar Gala,
Gregory Clement
On 05/28/2014 12:24 AM, Heiko Stübner wrote:
> Am Dienstag, 27. Mai 2014, 23:50:29 schrieb Sebastian Hesselbarth:
>> On 05/27/2014 11:35 PM, Jason Cooper wrote:
>>> On Tue, May 27, 2014 at 07:28:09PM +0200, Sebastian Hesselbarth wrote:
>>>> On 05/27/2014 06:11 PM, Jason Cooper wrote:
>>>>> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
>>> info. It may be useful here, but I'd like to hear from the DT
>>> maintainers how they want it used. eg: most popular first, like you
>>> have it, or oldest first
>>>
>>> dove-cubox-es.dts
>>> +--> dove-cubox.dts
>>
>> In the cubox case, this is not possible. ES has a misrouted
>> card-detection for sdhci, this requires an additional property.
>> There is no way to remove a property once it is written down in
>> any of the files included. But you know about that already.
>
> dtc knows "/delete-property/" [0], but I may be missing something here.
>
> [0] https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-August/018169.html
Heiko,
thanks for the link, I must have completely ignored it! Now that I
think about it, it may be very useful for kirkwood-98xsomething.dtsi
that is a special Kirkwood with a bunch of IP removed (but only some
boards). That way we could consolidate the common SoCs and use
/delete-node/ for the special case SoC.
Anyway, for CuBox ES, I either prefer the v2 approach just send - or
have a cubox-common.dtsi with two board dts for 1G and ES each. We use
this structure a lot and Andrew showed it even works for up to 5 or 10
different variants.
Sebastian
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH 2/2] ARM: dts: mvebu: split SolidRun CuBox into variants
@ 2014-05-27 22:37 ` Sebastian Hesselbarth
0 siblings, 0 replies; 36+ messages in thread
From: Sebastian Hesselbarth @ 2014-05-27 22:37 UTC (permalink / raw)
To: Heiko Stübner,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Jason Cooper, Mark Rutland, Andrew Lunn, Russell King, Pawel Moll,
Ian Campbell, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Kumar Gala,
Gregory Clement
On 05/28/2014 12:24 AM, Heiko Stübner wrote:
> Am Dienstag, 27. Mai 2014, 23:50:29 schrieb Sebastian Hesselbarth:
>> On 05/27/2014 11:35 PM, Jason Cooper wrote:
>>> On Tue, May 27, 2014 at 07:28:09PM +0200, Sebastian Hesselbarth wrote:
>>>> On 05/27/2014 06:11 PM, Jason Cooper wrote:
>>>>> On Mon, May 26, 2014 at 11:33:29PM +0200, Sebastian Hesselbarth wrote:
>>> info. It may be useful here, but I'd like to hear from the DT
>>> maintainers how they want it used. eg: most popular first, like you
>>> have it, or oldest first
>>>
>>> dove-cubox-es.dts
>>> +--> dove-cubox.dts
>>
>> In the cubox case, this is not possible. ES has a misrouted
>> card-detection for sdhci, this requires an additional property.
>> There is no way to remove a property once it is written down in
>> any of the files included. But you know about that already.
>
> dtc knows "/delete-property/" [0], but I may be missing something here.
>
> [0] https://lists.ozlabs.org/pipermail/devicetree-discuss/2012-August/018169.html
Heiko,
thanks for the link, I must have completely ignored it! Now that I
think about it, it may be very useful for kirkwood-98xsomething.dtsi
that is a special Kirkwood with a bunch of IP removed (but only some
boards). That way we could consolidate the common SoCs and use
/delete-node/ for the special case SoC.
Anyway, for CuBox ES, I either prefer the v2 approach just send - or
have a cubox-common.dtsi with two board dts for 1G and ES each. We use
this structure a lot and Andrew showed it even works for up to 5 or 10
different variants.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 36+ messages in thread