| Message ID | 1401140009-31505-2-git-send-email-sebastian.hesselbarth@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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
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.
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
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
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...
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
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
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
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>; + }; + + 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)"; + compatible = "solidrun,cubox-es", "solidrun,cubox", "marvell,dove"; + + memory { + device_type = "memory"; + reg = <0x00000000 0x40000000>; + }; + + chosen { + bootargs = "console=ttyS0,115200n8 earlyprintk"; + }; +}; + +&sdio0 { + /* sdio0 card detect is connected to wrong pin on CuBox */ + cd-gpios = <&gpio0 12 1>; + pinctrl-0 = <&pmx_sdio0 &pmx_gpio_12>; +}; diff --git a/arch/arm/boot/dts/dove-cubox.dts b/arch/arm/boot/dts/dove-cubox.dtsi similarity index 86% rename from arch/arm/boot/dts/dove-cubox.dts rename to arch/arm/boot/dts/dove-cubox.dtsi index 7a70f4ca502a..5752d729cc71 100644 --- a/arch/arm/boot/dts/dove-cubox.dts +++ b/arch/arm/boot/dts/dove-cubox.dtsi @@ -1,20 +1,6 @@ -/dts-v1/; - #include "dove.dtsi" / { - model = "SolidRun CuBox"; - compatible = "solidrun,cubox", "marvell,dove"; - - memory { - device_type = "memory"; - reg = <0x00000000 0x40000000>; - }; - - chosen { - bootargs = "console=ttyS0,115200n8 earlyprintk"; - }; - leds { compatible = "gpio-leds"; pinctrl-0 = <&pmx_gpio_18>; @@ -111,9 +97,6 @@ &sdio0 { status = "okay"; - /* sdio0 card detect is connected to wrong pin on CuBox */ - cd-gpios = <&gpio0 12 1>; - pinctrl-0 = <&pmx_sdio0 &pmx_gpio_12>; }; &spi0 {
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%)