From: Benoit Cousson <b-cousson@ti.com> To: Pantelis Antoniou <panto@antoniou-consulting.com> Cc: Grant Likely <grant.likely@secretlab.ca>, Rob Herring <robherring2@gmail.com>, Deepak Saxena <dsaxena@linaro.org>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Scott Wood <scottwood@freescale.com>, Tony Lindgren <tony@atomide.com>, Russ Dill <Russ.Dill@ti.com>, Felipe Balbi <balbi@ti.com>, linux-kernel <linux-kernel@vger.kernel.org>, Koen Kooi <koen@dominion.thruhere.net>, Matt Porter <mporter@ti.com>, <linux-omap@vger.kernel.org>, Kevin Hilman <khilman@ti.com>, Paul Walmsley <paul@pwsan.com>, <devicetree-discuss@lists.ozlabs.org> Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Date: Wed, 7 Nov 2012 12:12:50 +0100 [thread overview] Message-ID: <509A4232.9090709@ti.com> (raw) In-Reply-To: <A6697FB9-3614-4027-A71B-59C7556005BF@antoniou-consulting.com> On 11/07/2012 12:02 PM, Pantelis Antoniou wrote: > Hi Benoit, > > On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote: > >> Hi Panto, >> >> On 11/07/2012 09:13 AM, Pantelis Antoniou wrote: >>> Hi Grant >>> >>> On Nov 6, 2012, at 9:45 PM, Grant Likely wrote: >>> >>>> On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou >>>> <panto@antoniou-consulting.com> wrote: >>> >>> [ snip ] >>>> >>>> g. >>> >>> Since we've started talking about longer term goals, and the versioning >>> provision seems to stand, I hope we address how much the fragment versioning >>> thing is similar to the way board revisions progress. >>> >>> If a versioning syntax is available then one could create a single DT >>> file for a bunch of 'almost' similar board and board revisions. >> >> I even think that the version issue is probably much more important for the short term than the overlay aspect. Well at least as important. We start having as well a bunch a panda board version with different HW setup. >> >> Having a single board-XXX.dts that will support all these versions is probably the best approach to avoid choosing that from the bootloader. >> >> We need to figure out a format + mechanism compatible with the current non-versioned format to allow filtering the nodes at runtime to keep only the relevant one. >> >> Something that can find the driver that will provide the proper board version or subsystem version or whatever like that: >> >> compatible-version = "ti,panda-version", "panda"; >> >> Then at runtime we should create only the node with the correct match between the driver version and the string version. >> >> > > This is exactly what we need. FWIW the capebus syntax is a little bit different. > >> /* regular panda audio routing */ >> sound: sound { >> compatible = "ti,abe-twl6040"; >> ti,model = "PandaBoard"; >> compatible-version = "ti,panda-version", "panda"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "HSMIC", "Headset Mic", >> "Headset Mic", "Headset Mic Bias", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> >> >> /* Audio routing is different between PandaBoard4430 and PandaBoardES */ >> &sound { >> ti,model = "PandaBoardES"; >> compatible-version = "ti,panda-version", "panda-es"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> > > We use this syntax for capebus (totally non-standard of-course), > > sound: sound { > compatible = "ti,abe-twl6040"; > > > model@0 { > ti,model = "PandaBoard"; > ti,audio-routing = > "Headset Stereophone", "HSOL", > "Headset Stereophone", "HSOR", > "Ext Spk", "HFL", > "Ext Spk", "HFR", > "Line Out", "AUXL", > "Line Out", "AUXR", > "HSMIC", "Headset Mic", > "Headset Mic", "Headset Mic Bias", > "AFML", "Line In", > "AFMR", "Line In"; > }; > > model@1 { > ti,model = "PandaBoardES"; > ti,audio-routing = > "Headset Stereophone", "HSOL", > "Headset Stereophone", "HSOR", > "Ext Spk", "HFL", > "Ext Spk", "HFR", > "Line Out", "AUXL", > "Line Out", "AUXR", > "AFML", "Line In", > "AFMR", "Line In"; > }; > > /* common properties for either model */ > }; > > The difference is that you don't get to repeat the common properties. > > I don't know if this breaks any conventions but seems to work fine for our case. Yeah, my main concern with that approach is that you change the structure of the tree by adding an extra node/hierarchy that will not be there in case of non-versioned tree. That's why I think we should have something lighter that will not change the structure. Ideally we should be able to add extra versioned node to the original dts without changing it at all. >> Maybe some extra version match table can just be passed during the board machine_init >> >> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); >> > > Would we need explicit of_platform_populate calls if we have node modification notifiers? > In that case the notifier would pick it up automatically, and can do the per > version matching internally. Yes indeed, but here I was thinking about an intermediate step, i.e. now, without any dynamic node insertion mechanism. Thanks to this simple approach, when can already fix the board versionning problem. Regards, Benoit
WARNING: multiple messages have this Message-ID (diff)
From: Benoit Cousson <b-cousson-l0cyMroinI0@public.gmane.org> To: Pantelis Antoniou <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> Cc: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>, Matt Porter <mporter-l0cyMroinI0@public.gmane.org>, Koen Kooi <koen-QLwJDigV5abLmq1fohREcCpxlwaOVQ5f@public.gmane.org>, linux-kernel <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>, Deepak Saxena <dsaxena-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>, Russ Dill <Russ.Dill-l0cyMroinI0@public.gmane.org>, linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Date: Wed, 7 Nov 2012 12:12:50 +0100 [thread overview] Message-ID: <509A4232.9090709@ti.com> (raw) In-Reply-To: <A6697FB9-3614-4027-A71B-59C7556005BF-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> On 11/07/2012 12:02 PM, Pantelis Antoniou wrote: > Hi Benoit, > > On Nov 7, 2012, at 11:19 AM, Benoit Cousson wrote: > >> Hi Panto, >> >> On 11/07/2012 09:13 AM, Pantelis Antoniou wrote: >>> Hi Grant >>> >>> On Nov 6, 2012, at 9:45 PM, Grant Likely wrote: >>> >>>> On Tue, Nov 6, 2012 at 7:34 PM, Pantelis Antoniou >>>> <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> wrote: >>> >>> [ snip ] >>>> >>>> g. >>> >>> Since we've started talking about longer term goals, and the versioning >>> provision seems to stand, I hope we address how much the fragment versioning >>> thing is similar to the way board revisions progress. >>> >>> If a versioning syntax is available then one could create a single DT >>> file for a bunch of 'almost' similar board and board revisions. >> >> I even think that the version issue is probably much more important for the short term than the overlay aspect. Well at least as important. We start having as well a bunch a panda board version with different HW setup. >> >> Having a single board-XXX.dts that will support all these versions is probably the best approach to avoid choosing that from the bootloader. >> >> We need to figure out a format + mechanism compatible with the current non-versioned format to allow filtering the nodes at runtime to keep only the relevant one. >> >> Something that can find the driver that will provide the proper board version or subsystem version or whatever like that: >> >> compatible-version = "ti,panda-version", "panda"; >> >> Then at runtime we should create only the node with the correct match between the driver version and the string version. >> >> > > This is exactly what we need. FWIW the capebus syntax is a little bit different. > >> /* regular panda audio routing */ >> sound: sound { >> compatible = "ti,abe-twl6040"; >> ti,model = "PandaBoard"; >> compatible-version = "ti,panda-version", "panda"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "HSMIC", "Headset Mic", >> "Headset Mic", "Headset Mic Bias", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> >> >> /* Audio routing is different between PandaBoard4430 and PandaBoardES */ >> &sound { >> ti,model = "PandaBoardES"; >> compatible-version = "ti,panda-version", "panda-es"; >> >> /* Audio routing */ >> ti,audio-routing = >> "Headset Stereophone", "HSOL", >> "Headset Stereophone", "HSOR", >> "Ext Spk", "HFL", >> "Ext Spk", "HFR", >> "Line Out", "AUXL", >> "Line Out", "AUXR", >> "AFML", "Line In", >> "AFMR", "Line In"; >> }; >> > > We use this syntax for capebus (totally non-standard of-course), > > sound: sound { > compatible = "ti,abe-twl6040"; > > > model@0 { > ti,model = "PandaBoard"; > ti,audio-routing = > "Headset Stereophone", "HSOL", > "Headset Stereophone", "HSOR", > "Ext Spk", "HFL", > "Ext Spk", "HFR", > "Line Out", "AUXL", > "Line Out", "AUXR", > "HSMIC", "Headset Mic", > "Headset Mic", "Headset Mic Bias", > "AFML", "Line In", > "AFMR", "Line In"; > }; > > model@1 { > ti,model = "PandaBoardES"; > ti,audio-routing = > "Headset Stereophone", "HSOL", > "Headset Stereophone", "HSOR", > "Ext Spk", "HFL", > "Ext Spk", "HFR", > "Line Out", "AUXL", > "Line Out", "AUXR", > "AFML", "Line In", > "AFMR", "Line In"; > }; > > /* common properties for either model */ > }; > > The difference is that you don't get to repeat the common properties. > > I don't know if this breaks any conventions but seems to work fine for our case. Yeah, my main concern with that approach is that you change the structure of the tree by adding an extra node/hierarchy that will not be there in case of non-versioned tree. That's why I think we should have something lighter that will not change the structure. Ideally we should be able to add extra versioned node to the original dts without changing it at all. >> Maybe some extra version match table can just be passed during the board machine_init >> >> of_platform_populate(NULL, omap_dt_match_table, NULL, NULL, panda_version_match_table); >> > > Would we need explicit of_platform_populate calls if we have node modification notifiers? > In that case the notifier would pick it up automatically, and can do the per > version matching internally. Yes indeed, but here I was thinking about an intermediate step, i.e. now, without any dynamic node insertion mechanism. Thanks to this simple approach, when can already fix the board versionning problem. Regards, Benoit
next prev parent reply other threads:[~2012-11-07 11:13 UTC|newest] Thread overview: 135+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-11-05 20:40 [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Grant Likely 2012-11-05 21:40 ` Tabi Timur-B04825 2012-11-05 21:40 ` Tabi Timur-B04825 2012-11-05 23:22 ` Tony Lindgren 2012-11-05 23:22 ` Tony Lindgren 2012-11-09 12:06 ` Grant Likely 2012-11-09 12:06 ` Grant Likely 2012-11-06 0:07 ` Grant Likely 2012-11-06 0:07 ` Grant Likely 2012-11-06 10:31 ` Pantelis Antoniou 2012-11-06 10:31 ` Pantelis Antoniou 2012-11-07 22:35 ` Ryan Mallon 2012-11-07 22:35 ` Ryan Mallon 2012-11-08 13:28 ` Koen Kooi 2012-11-08 13:28 ` Koen Kooi 2012-11-08 14:09 ` Timur Tabi 2012-11-08 14:09 ` Timur Tabi 2012-11-08 17:00 ` Mitch Bradley 2012-11-08 17:00 ` Mitch Bradley 2012-11-06 10:30 ` Pantelis Antoniou 2012-11-06 11:14 ` Grant Likely 2012-11-06 18:35 ` Tony Lindgren 2012-11-06 19:29 ` Russ Dill 2012-11-06 19:41 ` Pantelis Antoniou 2012-11-06 19:41 ` Pantelis Antoniou 2012-11-06 22:17 ` Stephen Warren 2012-11-06 22:17 ` Stephen Warren 2012-11-06 19:34 ` Pantelis Antoniou 2012-11-06 20:45 ` Grant Likely 2012-11-06 20:50 ` Grant Likely 2012-11-07 8:06 ` Pantelis Antoniou 2012-11-07 15:33 ` Alan Tull 2012-11-07 15:33 ` Alan Tull 2012-11-09 17:03 ` Grant Likely 2012-11-07 8:13 ` Pantelis Antoniou 2012-11-07 10:19 ` Benoit Cousson 2012-11-07 10:19 ` Benoit Cousson 2012-11-07 11:02 ` Pantelis Antoniou 2012-11-07 11:02 ` Pantelis Antoniou 2012-11-07 11:12 ` Benoit Cousson [this message] 2012-11-07 11:12 ` Benoit Cousson 2012-11-07 11:23 ` Pantelis Antoniou 2012-11-07 11:23 ` Pantelis Antoniou 2012-11-09 20:33 ` Grant Likely 2012-11-12 11:34 ` Pantelis Antoniou 2012-11-12 13:01 ` Grant Likely 2012-11-07 17:25 ` Stephen Warren 2012-11-07 22:10 ` Pantelis Antoniou 2012-11-07 22:10 ` Pantelis Antoniou 2012-11-08 10:36 ` Cousson, Benoit 2012-11-08 10:36 ` Cousson, Benoit 2012-11-09 5:32 ` Joel A Fernandes 2012-11-09 14:29 ` David Gibson 2012-11-10 3:15 ` Joel A Fernandes 2012-11-09 21:22 ` Grant Likely 2012-11-12 11:47 ` Pantelis Antoniou 2012-11-12 11:47 ` Pantelis Antoniou 2012-11-13 3:59 ` Joel A Fernandes 2012-11-09 22:59 ` Stephen Warren [not found] ` <-4237940489086529028@unknownmsgid> [not found] ` <559B8433-67C3-4A1A-A5D6-859907655176@antoniou-consulting.com> 2012-11-10 3:36 ` Joel A Fernandes 2012-11-10 3:36 ` Joel A Fernandes 2012-11-12 12:48 ` Pantelis Antoniou 2012-11-13 2:28 ` David Gibson 2012-11-06 22:37 ` Stephen Warren 2012-11-06 22:37 ` Stephen Warren 2012-11-07 0:54 ` Mitch Bradley 2012-11-07 0:54 ` Mitch Bradley 2012-11-09 17:02 ` Grant Likely 2012-11-12 11:29 ` Pantelis Antoniou 2012-11-07 8:47 ` Pantelis Antoniou 2012-11-07 17:18 ` Stephen Warren 2012-11-07 22:08 ` Pantelis Antoniou 2012-11-07 22:08 ` Pantelis Antoniou 2012-11-09 16:28 ` Grant Likely 2012-11-09 23:23 ` Stephen Warren 2012-11-09 23:40 ` Grant Likely 2012-11-12 10:53 ` Koen Kooi 2012-11-12 12:10 ` Pantelis Antoniou 2012-11-12 12:10 ` Pantelis Antoniou 2012-11-12 16:52 ` Stephen Warren 2012-11-13 7:25 ` David Gibson 2012-11-13 8:09 ` Pantelis Antoniou 2012-11-13 8:09 ` Pantelis Antoniou 2012-11-13 12:24 ` Grant Likely 2012-11-13 13:38 ` Pantelis Antoniou 2012-11-13 13:38 ` Pantelis Antoniou 2012-11-15 4:57 ` David Gibson 2012-11-13 17:10 ` Stephen Warren 2012-11-13 23:30 ` David Gibson 2012-11-13 23:30 ` David Gibson 2012-11-14 0:00 ` Pantelis Antoniou 2012-11-13 16:57 ` Stephen Warren 2012-11-13 18:10 ` Mitch Bradley 2012-11-13 18:10 ` Mitch Bradley 2012-11-13 18:29 ` Stephen Warren 2012-11-13 18:29 ` Stephen Warren 2012-11-13 19:09 ` Mitch Bradley 2012-11-13 19:11 ` Pantelis Antoniou 2012-11-17 22:27 ` Jean-Christophe PLAGNIOL-VILLARD 2012-11-20 17:09 ` Grant Likely 2012-11-11 20:47 ` Rob Landley 2012-11-12 12:50 ` Pantelis Antoniou 2012-11-12 16:54 ` Stephen Warren 2012-11-12 16:54 ` Stephen Warren 2012-11-12 11:23 ` Pantelis Antoniou 2012-11-12 16:49 ` Stephen Warren 2012-11-12 17:00 ` Pantelis Antoniou 2012-11-12 17:10 ` Stephen Warren 2012-11-12 17:19 ` Pantelis Antoniou 2012-11-12 17:29 ` Stephen Warren 2012-11-12 17:38 ` Pantelis Antoniou 2012-11-12 20:16 ` Russ Dill 2012-11-12 16:45 ` Stephen Warren 2012-11-09 2:26 ` David Gibson 2012-11-09 15:40 ` Pantelis Antoniou 2012-11-13 0:03 ` David Gibson 2012-11-13 0:03 ` David Gibson 2012-11-09 21:08 ` Grant Likely 2012-11-13 0:05 ` David Gibson 2012-11-13 0:05 ` David Gibson 2012-11-09 21:42 ` Grant Likely 2012-11-13 1:05 ` David Gibson 2012-11-13 1:05 ` David Gibson 2012-11-13 5:22 ` Stephen Warren 2012-11-13 6:54 ` David Gibson 2012-11-13 6:54 ` David Gibson 2012-11-09 22:57 ` Stephen Warren 2012-11-09 23:27 ` Grant Likely 2012-11-12 12:05 ` Pantelis Antoniou 2012-11-09 23:14 ` Stephen Warren 2012-11-09 23:14 ` Stephen Warren 2012-11-09 23:06 ` Stephen Warren 2012-11-09 23:32 ` Grant Likely 2012-11-12 11:03 ` Koen Kooi 2012-11-12 11:03 ` Koen Kooi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=509A4232.9090709@ti.com \ --to=b-cousson@ti.com \ --cc=Russ.Dill@ti.com \ --cc=balbi@ti.com \ --cc=benh@kernel.crashing.org \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=dsaxena@linaro.org \ --cc=grant.likely@secretlab.ca \ --cc=khilman@ti.com \ --cc=koen@dominion.thruhere.net \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-omap@vger.kernel.org \ --cc=mporter@ti.com \ --cc=panto@antoniou-consulting.com \ --cc=paul@pwsan.com \ --cc=robherring2@gmail.com \ --cc=scottwood@freescale.com \ --cc=tony@atomide.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.