From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>, Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> Cc: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Jon Loeliger <jdl-CYoMK+44s/E@public.gmane.org>, Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>, Jan Luebbe <jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>, Matt Porter <mporter-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>, devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [PATCH v7 3/5] dtc: Document the dynamic plugin internals Date: Wed, 29 Jun 2016 19:59:13 -0700 [thread overview] Message-ID: <57748B01.4050601@gmail.com> (raw) In-Reply-To: <20160530042210.GD17226-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org> Hi Pantelis, On 05/29/16 21:22, David Gibson wrote: < massive snip > >>> What other properties are you envisioning? (Looking for the architectural >>> vision that you have.) >>> >> >> Oh, there are a lot of properties that can be provided. >> >> For instance you can declare manufacturing info (like part numbers, version numbers, >> serial numbers that can be used for quirking). You can declare things like load order >> when you need precedence of overlays (i.e. on the bone the soldered on hdmi output >> should be disabled when an add on cape with display capability is attached). >> You can declare resources (i.e. pins or power draw figures) to make a decision >> whether enabling an expansion board is safe. >> >> I’m sure more ideas will come when we put it into wide-spread use. > > Yeah. I'm not entirely sure I'm convinced by the specific examples > given so far. However, in general I can see the value in providing a > way we can extend to add more metadata. The two level structure with > __overlay__ gives us that, whereas the one level approach doesn't. I'm not convinced about putting additional properties (beyond "target") in the fragment nodes. And I still find the two extra levels of "fragment" nodes and "__overlay__" nodes extra complexity, and that the complexity is especially unwelcome if the overlay dts is hand written (as the beagle cape overlays that I have seen appear to be). HOWEVER, I learned something new today that makes me more comfortable with the two extra node levels. Here is an example: $ cat ex_1_overlay.dts /dts-v1/; /plugin/; &tree_1 { remote_prop = <0xfeedfeed &foo>; }; $ dtc -@ -O dts ex_1_overlay.dts Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property /dts-v1/; / { fragment@0 { target = <0xffffffff>; __overlay__ { remote_prop = <0xfeedfeed 0xffffffff>; }; }; __symbols__ { }; __fixups__ { tree_1 = "/fragment@0:target:0"; foo = "/fragment@0/__overlay__:remote_prop:4"; }; __local_fixups__ { }; }; That example is using dtc from: url = https://github.com/pantoniou/dtc branch: dt-overlays8 as of commit: 6f4db2fc2354 I do not know if that is current or not. So the nice thing about that is that the overlay source file does not have to provide the fragment and __overlay__ nodes. They just magically appear in the compiled blob. Is that behavior that I can count on continuing to exist in dtc? Note the warning about no reg property in /fragment@0. The other issue with the device tree source in my example is that I don't think there is a way to add extra properties to node "fragment@0" in the general case where there are multiple fragments. It _is_ possible to add a property as I show in the next example, but it seems fragile to be able to count on the order and names of fragments auto generated by dtc. (And again, I don't really want those extra properties anyway.) Example of adding a property to fragment@0: $ cat ex_1b_overlay.dts /dts-v1/; /plugin/; &tree_1 { remote_prop = <0xfeedfeed &foo>; }; / { fragment@0 { another_fragment_prop = "frag property"; }; }; $ dtc -@ -O dts ex_1b_overlay.dts Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property /dts-v1/; / { fragment@0 { target = <0xffffffff>; another_fragment_prop = "frag property"; __overlay__ { remote_prop = <0xfeedfeed 0xffffffff>; }; }; __symbols__ { }; __fixups__ { tree_1 = "/fragment@0:target:0"; foo = "/fragment@0/__overlay__:remote_prop:4"; }; __local_fixups__ { }; }; >>> If load manager specific details are appropriate in the devicetree (a whole >>> different discussion) then maybe a /chosen/load-manager node could exist to >>> hold them instead of putting them in /, where the patch currently locates >>> "/* various properties for loader use; i.e. part id etc. */". -Frank
WARNING: multiple messages have this Message-ID (diff)
From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> To: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>, Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> Cc: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Jon Loeliger <jdl-CYoMK+44s/E@public.gmane.org>, Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>, Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>, Jan Luebbe <jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>, Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>, Matt Porter <mporter-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>, devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> Subject: Re: [PATCH v7 3/5] dtc: Document the dynamic plugin internals Date: Wed, 29 Jun 2016 19:59:13 -0700 [thread overview] Message-ID: <57748B01.4050601@gmail.com> (raw) In-Reply-To: <20160530042210.GD17226-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org> Hi Pantelis, On 05/29/16 21:22, David Gibson wrote: < massive snip > >>> What other properties are you envisioning? (Looking for the architectural >>> vision that you have.) >>> >> >> Oh, there are a lot of properties that can be provided. >> >> For instance you can declare manufacturing info (like part numbers, version numbers, >> serial numbers that can be used for quirking). You can declare things like load order >> when you need precedence of overlays (i.e. on the bone the soldered on hdmi output >> should be disabled when an add on cape with display capability is attached). >> You can declare resources (i.e. pins or power draw figures) to make a decision >> whether enabling an expansion board is safe. >> >> I’m sure more ideas will come when we put it into wide-spread use. > > Yeah. I'm not entirely sure I'm convinced by the specific examples > given so far. However, in general I can see the value in providing a > way we can extend to add more metadata. The two level structure with > __overlay__ gives us that, whereas the one level approach doesn't. I'm not convinced about putting additional properties (beyond "target") in the fragment nodes. And I still find the two extra levels of "fragment" nodes and "__overlay__" nodes extra complexity, and that the complexity is especially unwelcome if the overlay dts is hand written (as the beagle cape overlays that I have seen appear to be). HOWEVER, I learned something new today that makes me more comfortable with the two extra node levels. Here is an example: $ cat ex_1_overlay.dts /dts-v1/; /plugin/; &tree_1 { remote_prop = <0xfeedfeed &foo>; }; $ dtc -@ -O dts ex_1_overlay.dts Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property /dts-v1/; / { fragment@0 { target = <0xffffffff>; __overlay__ { remote_prop = <0xfeedfeed 0xffffffff>; }; }; __symbols__ { }; __fixups__ { tree_1 = "/fragment@0:target:0"; foo = "/fragment@0/__overlay__:remote_prop:4"; }; __local_fixups__ { }; }; That example is using dtc from: url = https://github.com/pantoniou/dtc branch: dt-overlays8 as of commit: 6f4db2fc2354 I do not know if that is current or not. So the nice thing about that is that the overlay source file does not have to provide the fragment and __overlay__ nodes. They just magically appear in the compiled blob. Is that behavior that I can count on continuing to exist in dtc? Note the warning about no reg property in /fragment@0. The other issue with the device tree source in my example is that I don't think there is a way to add extra properties to node "fragment@0" in the general case where there are multiple fragments. It _is_ possible to add a property as I show in the next example, but it seems fragile to be able to count on the order and names of fragments auto generated by dtc. (And again, I don't really want those extra properties anyway.) Example of adding a property to fragment@0: $ cat ex_1b_overlay.dts /dts-v1/; /plugin/; &tree_1 { remote_prop = <0xfeedfeed &foo>; }; / { fragment@0 { another_fragment_prop = "frag property"; }; }; $ dtc -@ -O dts ex_1b_overlay.dts Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property /dts-v1/; / { fragment@0 { target = <0xffffffff>; another_fragment_prop = "frag property"; __overlay__ { remote_prop = <0xfeedfeed 0xffffffff>; }; }; __symbols__ { }; __fixups__ { tree_1 = "/fragment@0:target:0"; foo = "/fragment@0/__overlay__:remote_prop:4"; }; __local_fixups__ { }; }; >>> If load manager specific details are appropriate in the devicetree (a whole >>> different discussion) then maybe a /chosen/load-manager node could exist to >>> hold them instead of putting them in /, where the patch currently locates >>> "/* various properties for loader use; i.e. part id etc. */". -Frank
next prev parent reply other threads:[~2016-06-30 2:59 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-05-24 17:50 [PATCH v7 0/5] dtc: Dynamic DT support Pantelis Antoniou [not found] ` <1464112239-29856-1-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 2016-05-24 17:50 ` [PATCH v7 1/5] util: Add xasprintf portable asprintf variant Pantelis Antoniou [not found] ` <1464112239-29856-2-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 2016-05-25 5:16 ` David Gibson 2016-05-24 17:50 ` [PATCH v7 2/5] DTBO magic and dtbo format options Pantelis Antoniou [not found] ` <1464112239-29856-3-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 2016-05-25 18:51 ` Frank Rowand [not found] ` <5745F42E.9080100-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-05-26 0:10 ` David Gibson 2016-05-26 0:11 ` David Gibson 2016-05-24 17:50 ` [PATCH v7 3/5] dtc: Document the dynamic plugin internals Pantelis Antoniou [not found] ` <1464112239-29856-4-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 2016-05-25 19:13 ` Frank Rowand [not found] ` <5745F95F.6000600-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-05-26 4:58 ` David Gibson [not found] ` <20160526045801.GD17226-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org> 2016-05-26 6:16 ` Pantelis Antoniou 2016-05-26 6:16 ` Pantelis Antoniou 2016-05-26 6:14 ` Pantelis Antoniou 2016-05-26 6:14 ` Pantelis Antoniou [not found] ` <1151E0EF-B811-4C0B-858A-00810BE9BA42-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 2016-05-26 6:28 ` David Gibson [not found] ` <20160526062848.GG17226-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org> 2016-05-26 6:31 ` Pantelis Antoniou [not found] ` <8CAE1792-841B-4048-B6B1-1F0F973E2E34-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 2016-05-26 6:33 ` David Gibson [not found] ` <20160526063334.GH17226-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org> 2016-05-26 6:36 ` Pantelis Antoniou [not found] ` <BE239F34-7B36-4A78-BE21-AA48CB8349E4-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 2016-05-26 7:12 ` David Gibson [not found] ` <20160526071243.GI17226-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org> 2016-05-26 7:16 ` Pantelis Antoniou [not found] ` <C43C3B01-5DF5-49DF-848D-0BEA48E3DB6E-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 2016-05-26 13:49 ` Rob Herring [not found] ` <CAL_JsqLTrSP577ViKRjoqyagWw4+dZuQQsTMMXdoU3n9HZSYZA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-05-26 16:55 ` Frank Rowand [not found] ` <57472A9A.1060903-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-05-26 17:09 ` Pantelis Antoniou [not found] ` <EAD64177-3519-4CD2-AFB6-5EB765CC7459-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 2016-05-26 21:31 ` Frank Rowand [not found] ` <57476B27.9070008-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-05-27 14:52 ` Pantelis Antoniou [not found] ` <26CE3FC4-2B09-45E9-94E2-9EA7836A684F-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 2016-05-30 4:22 ` David Gibson [not found] ` <20160530042210.GD17226-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org> 2016-06-30 2:59 ` Frank Rowand [this message] 2016-06-30 2:59 ` Frank Rowand [not found] ` <57748B01.4050601-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 2016-06-30 5:17 ` David Gibson 2016-05-24 17:50 ` [PATCH v7 4/5] dtc: Plugin and fixup support Pantelis Antoniou [not found] ` <1464112239-29856-5-git-send-email-pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 2016-05-27 7:33 ` David Gibson [not found] ` <20160527073306.GA17226-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org> 2016-05-31 5:06 ` David Gibson [not found] ` <20160531050634.GJ17226-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org> 2016-06-02 17:13 ` Pantelis Antoniou [not found] ` <60DA9B11-16A5-49C6-AB27-888D4FCBE3A3-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> 2016-06-03 1:11 ` David Gibson 2016-05-24 17:50 ` [PATCH v7 5/5] plugin: Transparently support old style syntax Pantelis Antoniou
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=57748B01.4050601@gmail.com \ --to=frowand.list-re5jqeeqqe8avxtiumwx3w@public.gmane.org \ --cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \ --cc=devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \ --cc=jdl-CYoMK+44s/E@public.gmane.org \ --cc=jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \ --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \ --cc=mporter-OWPKS81ov/FWk0Htik3J/w@public.gmane.org \ --cc=pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org \ --cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \ --cc=s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.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.