| Message ID | 1401140009-31505-1-git-send-email-sebastian.hesselbarth@gmail.com |
|---|---|
| State | Accepted, archived |
| Commit | 481ff165acd10fbba4d9acebacecedb0bc5066cf |
| 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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 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... -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 26, 2014 at 4:33 PM, Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> wrote: > SolidRun is a company from Israel producing small-sized home-media > computers like the Marvell Dove based CuBox and Freescale IMX based > CuBox-i. Document the missing vendor prefix. > > 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: Randy Dunlap <rdunlap@infradead.org> > Cc: devicetree@vger.kernel.org > Cc: linux-doc@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-kernel@vger.kernel.org Acked-by: Rob Herring <robh@kernel.org> > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt > index 0f01c9bf19c8..f0c046aff55b 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -102,6 +102,7 @@ sii Seiko Instruments, Inc. > sirf SiRF Technology, Inc. > smsc Standard Microsystems Corporation > snps Synopsys, Inc. > +solidrun SolidRun > spansion Spansion Inc. > st STMicroelectronics > ste ST-Ericsson > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, May 26, 2014 at 11:33:28PM +0200, Sebastian Hesselbarth wrote: > SolidRun is a company from Israel producing small-sized home-media > computers like the Marvell Dove based CuBox and Freescale IMX based > CuBox-i. Document the missing vendor prefix. > > 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: Randy Dunlap <rdunlap@infradead.org> > Cc: devicetree@vger.kernel.org > Cc: linux-doc@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) Applied to mvebu/dt with Rob's Ack. v2 of patch 2/2 also applied to mvebu/dt. thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 0f01c9bf19c8..f0c046aff55b 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -102,6 +102,7 @@ sii Seiko Instruments, Inc. sirf SiRF Technology, Inc. smsc Standard Microsystems Corporation snps Synopsys, Inc. +solidrun SolidRun spansion Spansion Inc. st STMicroelectronics ste ST-Ericsson
SolidRun is a company from Israel producing small-sized home-media computers like the Marvell Dove based CuBox and Freescale IMX based CuBox-i. Document the missing vendor prefix. 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: Randy Dunlap <rdunlap@infradead.org> Cc: devicetree@vger.kernel.org Cc: linux-doc@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+)