From: Pantelis Antoniou <panto@antoniou-consulting.com> To: David Gibson <david@gibson.dropbear.id.au> Cc: Stephen Warren <swarren@wwwdotorg.org>, Kevin Hilman <khilman@ti.com>, Matt Porter <mporter@ti.com>, Koen Kooi <koen@dominion.thruhere.net>, linux-kernel <linux-kernel@vger.kernel.org>, Felipe Balbi <balbi@ti.com>, Deepak Saxena <dsaxena@linaro.org>, Scott Wood <scottwood@freescale.com>, Russ Dill <Russ.Dill@ti.com>, linux-omap@vger.kernel.org, devicetree-discuss@lists.ozlabs.org Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Date: Tue, 13 Nov 2012 10:09:28 +0200 [thread overview] Message-ID: <BD20AE03-C138-4BC6-AE02-F162AF6840B2@antoniou-consulting.com> (raw) In-Reply-To: <20121113072517.GE25915@truffula.fritz.box> Hi David, On Nov 13, 2012, at 9:25 AM, David Gibson wrote: > On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote: >> On 11/12/2012 05:10 AM, Pantelis Antoniou wrote: > [snip] >>> Oh yes. In fact if one was to use a single kernel image for beagleboard >>> and beaglebone, for the cape to work for both, it is required for it's >>> dtb to be compatible. >> >> Well, as Grant pointed out, it's not actually strictly necessary for the >> .dtb to be compatible; only the .dts /need/ be compatible, and the .dtb >> can be generated at run-time using dtc for example. > > So, actually, I think a whole bunch of problems with phandle > resolution disappear if we don't try to define an overlay .dtb format, > or at least treat it only as a very shortlived object. A more precise > proposal below. Note that this works more or less equally well with > either the original overlay approach or the graft/graft-bundle > proposal I made elsewhere. > > 1) We annotate the base tree with some extra label information for > nodes which overlays are likely to want to reference by phandle. e.g. > > beaglebone_pic: interrupt-controller@XXXXX { > ... > phandle,symbolic-name = "beaglebone_pic"; > }; > > We could extend dtc to (optionally?) auto-generate those properties > from its existing label syntax. Not sure if that's a good idea or > not yet. In any case, we compile this augmented base tree to .dtb as > normal and boot our kernel with it. > I'm fine with that. You can auto-generate when there's a label to a node. The cape dt fragment will use the label name to reference a node. More details below... > 2) The information for the capes/modules/whatever is > distributed/packaged as .dts, never .dtb. When userspace detects the > new module (or the user explicitly tells it, if it's not probeable) it > picks up the correct dts and runs it through dtc in a special mode. > In this mode dtc takes the existing base tree (from /proc/device-tree, > say) as well as the new dts. In this mode, dtc allocates phandles for > the new tree fragment so as not to collide with anything from the > supplied base tree (as well as avoiding internal conflicts, > obviously). It also allows node references to the base tree by using > those label annotations from (1) to match symbolic names to the > phandle values in the base tree. > Not good to rely on userspace kicking off dtc and compiling from source. Some capes/expansion boards might have your root fs device, for example there is an eMMC cape coming up, while networking capes are common too. However I have a compromise. I agree that compiling from source can be an option for a runtime definable cape, but for built-in capes we could do a bit better. In particular, I don't see any particular need to have a DT fragment reference anything that dependent of the runtime device tree. It should be possible to compile the DT fragment in kernel, against the generated flattened device tree, producing a flattened DT fragment with the phandles already resolved. So the sequence could be something like this: $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts -@ ${LAST_PHANDLE_FILE} $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts -@ ${LAST_PHANDLE_FILE} $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts -@ ${LAST_PHANDLE_FILE} The ${LAST_PHANDLE_FILE} can be updated with the last phandle value generated. Alternatively we could have a way to statically assign a phandle range for well known capes. All the others will have to use the runtime compile mechanism. $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts With the cape dtses having a /phandle-range/ statement at the top. This can work because the cape dts do not cross-reference each other, and neither the boot dts references the capes. That way we can use request_firmware() pretty early in the boot sequence and get the DT fragment we need even before user-space starts and root fs has mounted. request_firmware() can locate the fragments in the kernel image before rootfs. I don't know if this will cover all the cases Grant has in mind though. So just to make sure I got it right, this could work for our case. i2c2: i2c@4819c000 { compatible = "ti,omap4-i2c"; #address-cells = <1>; #size-cells = <0>; ti,hwmods = "i2c3"; reg = <0x4819c000 0x1000>; interrupt-parent = <&intc>; interrupts = <30>; status = "disabled"; }; And in the cape definition (when compiled with the special mode I describe below) / { plugin-bundle; compatible = "cco,weather-cape"; version = <00A0>; i2c2-graft = { compatible = <dt,graft>; graft-point = <&i2c2>; #address-cells = <1>; #size-cells = <0>; /* Ambient light sensor */ tsl2550@39 { compatible = "tsl,tsl2550"; reg = <0x39>; }; }; }; DTC when compiling in the special fragment mode will pick up that &i2c2 can not be resolved and lookup the phandle on the main dtb. That way, even 'phandle,symbolic-name = "i2c2";' is redundant. > 3) The resulting partial .dtb for the module is highly specific to the > base tree (which if the base tree was generated at runtime by firmware > could even be specific to a particular boot). But that's ok, because > we just spit it into the kernel, absolute phandle values and all, then > throw it away. Next time we need the module info, we recompile it > again. > >> Of course, relying on .dts compatibility rather than .dtb compatibility >> might negatively impact the complexity of an initrd environment if we >> end up loading overlays from there... > > Well, it does mean we'd need dtc in the initrd. But dtc has no > library dependencies except libc, so that really shouldn't be too > bad. In return we entirely avoid inventing a new phandle resolution > protocol. > Not every board boots with initrd; most embedded boards don't use it at all. This way we make initrd a hard requirement. It's best if we avoid it. > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson Regards -- Pantelis
WARNING: multiple messages have this Message-ID (diff)
From: Pantelis Antoniou <panto-wVdstyuyKrO8r51toPun2/C9HSW9iNxf@public.gmane.org> To: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@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>, Russ Dill <Russ.Dill-l0cyMroinI0@public.gmane.org>, Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@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: Tue, 13 Nov 2012 10:09:28 +0200 [thread overview] Message-ID: <BD20AE03-C138-4BC6-AE02-F162AF6840B2@antoniou-consulting.com> (raw) In-Reply-To: <20121113072517.GE25915-W9XWwYn+TF0XU02nzanrWNbf9cGiqdzd@public.gmane.org> Hi David, On Nov 13, 2012, at 9:25 AM, David Gibson wrote: > On Mon, Nov 12, 2012 at 09:52:32AM -0700, Stephen Warren wrote: >> On 11/12/2012 05:10 AM, Pantelis Antoniou wrote: > [snip] >>> Oh yes. In fact if one was to use a single kernel image for beagleboard >>> and beaglebone, for the cape to work for both, it is required for it's >>> dtb to be compatible. >> >> Well, as Grant pointed out, it's not actually strictly necessary for the >> .dtb to be compatible; only the .dts /need/ be compatible, and the .dtb >> can be generated at run-time using dtc for example. > > So, actually, I think a whole bunch of problems with phandle > resolution disappear if we don't try to define an overlay .dtb format, > or at least treat it only as a very shortlived object. A more precise > proposal below. Note that this works more or less equally well with > either the original overlay approach or the graft/graft-bundle > proposal I made elsewhere. > > 1) We annotate the base tree with some extra label information for > nodes which overlays are likely to want to reference by phandle. e.g. > > beaglebone_pic: interrupt-controller@XXXXX { > ... > phandle,symbolic-name = "beaglebone_pic"; > }; > > We could extend dtc to (optionally?) auto-generate those properties > from its existing label syntax. Not sure if that's a good idea or > not yet. In any case, we compile this augmented base tree to .dtb as > normal and boot our kernel with it. > I'm fine with that. You can auto-generate when there's a label to a node. The cape dt fragment will use the label name to reference a node. More details below... > 2) The information for the capes/modules/whatever is > distributed/packaged as .dts, never .dtb. When userspace detects the > new module (or the user explicitly tells it, if it's not probeable) it > picks up the correct dts and runs it through dtc in a special mode. > In this mode dtc takes the existing base tree (from /proc/device-tree, > say) as well as the new dts. In this mode, dtc allocates phandles for > the new tree fragment so as not to collide with anything from the > supplied base tree (as well as avoiding internal conflicts, > obviously). It also allows node references to the base tree by using > those label annotations from (1) to match symbolic names to the > phandle values in the base tree. > Not good to rely on userspace kicking off dtc and compiling from source. Some capes/expansion boards might have your root fs device, for example there is an eMMC cape coming up, while networking capes are common too. However I have a compromise. I agree that compiling from source can be an option for a runtime definable cape, but for built-in capes we could do a bit better. In particular, I don't see any particular need to have a DT fragment reference anything that dependent of the runtime device tree. It should be possible to compile the DT fragment in kernel, against the generated flattened device tree, producing a flattened DT fragment with the phandles already resolved. So the sequence could be something like this: $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts -@ ${LAST_PHANDLE_FILE} $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts -@ ${LAST_PHANDLE_FILE} $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts -@ ${LAST_PHANDLE_FILE} The ${LAST_PHANDLE_FILE} can be updated with the last phandle value generated. Alternatively we could have a way to statically assign a phandle range for well known capes. All the others will have to use the runtime compile mechanism. $ dtc -O dtb -o am335x-bone.dtb -b 0 am335x-bone.dts $ dtc -O dtbf -R am335x-bone.dtb -o weather-cape.dtb -b 0 weather-cape.dts $ dtc -O dtbf -R am335x-bone.dtb -o geiger-cape.dtb -b 0 geiger-cape.dts With the cape dtses having a /phandle-range/ statement at the top. This can work because the cape dts do not cross-reference each other, and neither the boot dts references the capes. That way we can use request_firmware() pretty early in the boot sequence and get the DT fragment we need even before user-space starts and root fs has mounted. request_firmware() can locate the fragments in the kernel image before rootfs. I don't know if this will cover all the cases Grant has in mind though. So just to make sure I got it right, this could work for our case. i2c2: i2c@4819c000 { compatible = "ti,omap4-i2c"; #address-cells = <1>; #size-cells = <0>; ti,hwmods = "i2c3"; reg = <0x4819c000 0x1000>; interrupt-parent = <&intc>; interrupts = <30>; status = "disabled"; }; And in the cape definition (when compiled with the special mode I describe below) / { plugin-bundle; compatible = "cco,weather-cape"; version = <00A0>; i2c2-graft = { compatible = <dt,graft>; graft-point = <&i2c2>; #address-cells = <1>; #size-cells = <0>; /* Ambient light sensor */ tsl2550@39 { compatible = "tsl,tsl2550"; reg = <0x39>; }; }; }; DTC when compiling in the special fragment mode will pick up that &i2c2 can not be resolved and lookup the phandle on the main dtb. That way, even 'phandle,symbolic-name = "i2c2";' is redundant. > 3) The resulting partial .dtb for the module is highly specific to the > base tree (which if the base tree was generated at runtime by firmware > could even be specific to a particular boot). But that's ok, because > we just spit it into the kernel, absolute phandle values and all, then > throw it away. Next time we need the module info, we recompile it > again. > >> Of course, relying on .dts compatibility rather than .dtb compatibility >> might negatively impact the complexity of an initrd environment if we >> end up loading overlays from there... > > Well, it does mean we'd need dtc in the initrd. But dtc has no > library dependencies except libc, so that really shouldn't be too > bad. In return we entirely avoid inventing a new phandle resolution > protocol. > Not every board boots with initrd; most embedded boards don't use it at all. This way we make initrd a hard requirement. It's best if we avoid it. > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson Regards -- Pantelis
next prev parent reply other threads:[~2012-11-13 8:09 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 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 [this message] 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=BD20AE03-C138-4BC6-AE02-F162AF6840B2@antoniou-consulting.com \ --to=panto@antoniou-consulting.com \ --cc=Russ.Dill@ti.com \ --cc=balbi@ti.com \ --cc=david@gibson.dropbear.id.au \ --cc=devicetree-discuss@lists.ozlabs.org \ --cc=dsaxena@linaro.org \ --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=scottwood@freescale.com \ --cc=swarren@wwwdotorg.org \ /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.