From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frank Rowand Subject: Re: [PATCH v7 3/5] dtc: Document the dynamic plugin internals Date: Wed, 29 Jun 2016 19:59:13 -0700 Message-ID: <57748B01.4050601@gmail.com> References: <8CAE1792-841B-4048-B6B1-1F0F973E2E34@konsulko.com> <20160526063334.GH17226@voom.fritz.box> <20160526071243.GI17226@voom.fritz.box> <57472A9A.1060903@gmail.com> <57476B27.9070008@gmail.com> <26CE3FC4-2B09-45E9-94E2-9EA7836A684F@konsulko.com> <20160530042210.GD17226@voom.fritz.box> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20160530042210.GD17226-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org> Sender: devicetree-compiler-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: David Gibson , Pantelis Antoniou Cc: Rob Herring , Jon Loeliger , Grant Likely , Mark Rutland , Jan Luebbe , Sascha Hauer , Matt Porter , devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" List-Id: devicetree@vger.kernel.org Hi Pantelis, On 05/29/16 21:22, David Gibson wrote: < massive snip > >>> What other properties are you envisioning? (Looking for the archit= ectural >>> 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 thing= s 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 at= tached). >> You can declare resources (i.e. pins or power draw figures) to make = a decision >> whether enabling an expansion board is safe. >> >> I=E2=80=99m sure more ideas will come when we put it into wide-sprea= d use. =20 >=20 > 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" no= des and "__overlay__" nodes extra complexity, and that the complexity is especi= ally unwelcome if the overlay dts is hand written (as the beagle cape overla= ys 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 e= xample: $ cat ex_1_overlay.dts=20 /dts-v1/; /plugin/; &tree_1 { remote_prop =3D <0xfeedfeed &foo>; }; $ dtc -@ -O dts ex_1_overlay.dts=20 Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no= reg property /dts-v1/; / { fragment@0 { target =3D <0xffffffff>; __overlay__ { remote_prop =3D <0xfeedfeed 0xffffffff>; }; }; __symbols__ { }; __fixups__ { tree_1 =3D "/fragment@0:target:0"; foo =3D "/fragment@0/__overlay__:remote_prop:4"; }; __local_fixups__ { }; }; That example is using dtc from: url =3D 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 h= ave 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 exis= t 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 gene= ral 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 t= he order and names of fragments auto generated by dtc. (And again, I don't real= ly 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 =3D <0xfeedfeed &foo>; }; / { fragment@0 { another_fragment_prop =3D "frag property"; }; }; $ dtc -@ -O dts ex_1b_overlay.dts=20 Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no= reg property /dts-v1/; / { fragment@0 { target =3D <0xffffffff>; another_fragment_prop =3D "frag property"; __overlay__ { remote_prop =3D <0xfeedfeed 0xffffffff>; }; }; __symbols__ { }; __fixups__ { tree_1 =3D "/fragment@0:target:0"; foo =3D "/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 l= ocates >>> "/* various properties for loader use; i.e. part id etc. */". -Frank From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frank Rowand Subject: Re: [PATCH v7 3/5] dtc: Document the dynamic plugin internals Date: Wed, 29 Jun 2016 19:59:13 -0700 Message-ID: <57748B01.4050601@gmail.com> References: <8CAE1792-841B-4048-B6B1-1F0F973E2E34@konsulko.com> <20160526063334.GH17226@voom.fritz.box> <20160526071243.GI17226@voom.fritz.box> <57472A9A.1060903@gmail.com> <57476B27.9070008@gmail.com> <26CE3FC4-2B09-45E9-94E2-9EA7836A684F@konsulko.com> <20160530042210.GD17226@voom.fritz.box> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=SJgnlfmKFMqJqAvBrSCnv7WKOzWHRDAGqeBGuiU8A5A=; b=CkSg41iH1CrngWLd0s5zP2eyU9SIJbVAGsEO3uRRMoac9IMjrd4o2srJsUa3mtt3bL 5ppRbYnaSMMEraK4cAlWomNdIQLn+wQtK3Nmi9ZMXdugyvzQTqU8QCTMFb6JAfw16dkW +XJqmT5XrXfN5yasp4fG6YUBADeNTnxheaWDLQM6Vu1BEgmGFgqoPADCVUGQF9vpqbKe CT9ezPHatbkVOZbiMuUWjeCZc2dUFiwT4CfcQOl/GwMLwIjD+fLmdft/h5oD25qV5j4j BTJezmrATC+4lCD1V/7c6ZqEdFYj8Sgekh7pmoLDZsORdW/z3nGrFGihahheuEhr6zwB 0ukw== In-Reply-To: <20160530042210.GD17226-RXTfZT5YzpxwFLYp8hBm2A@public.gmane.org> Sender: devicetree-compiler-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="windows-1252" To: David Gibson , Pantelis Antoniou Cc: Rob Herring , Jon Loeliger , Grant Likely , Mark Rutland , Jan Luebbe , Sascha Hauer , Matt Porter , devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, "devicetree-u79uwXL29TY76Z2rM5mHXA@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 archit= ectural >>> 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 thing= s 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 at= tached). >> You can declare resources (i.e. pins or power draw figures) to make = a decision >> whether enabling an expansion board is safe. >> >> I=E2=80=99m sure more ideas will come when we put it into wide-sprea= d use. =20 >=20 > 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" no= des and "__overlay__" nodes extra complexity, and that the complexity is especi= ally unwelcome if the overlay dts is hand written (as the beagle cape overla= ys 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 e= xample: $ cat ex_1_overlay.dts=20 /dts-v1/; /plugin/; &tree_1 { remote_prop =3D <0xfeedfeed &foo>; }; $ dtc -@ -O dts ex_1_overlay.dts=20 Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no= reg property /dts-v1/; / { fragment@0 { target =3D <0xffffffff>; __overlay__ { remote_prop =3D <0xfeedfeed 0xffffffff>; }; }; __symbols__ { }; __fixups__ { tree_1 =3D "/fragment@0:target:0"; foo =3D "/fragment@0/__overlay__:remote_prop:4"; }; __local_fixups__ { }; }; That example is using dtc from: url =3D 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 h= ave 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 exis= t 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 gene= ral 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 t= he order and names of fragments auto generated by dtc. (And again, I don't real= ly 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 =3D <0xfeedfeed &foo>; }; / { fragment@0 { another_fragment_prop =3D "frag property"; }; }; $ dtc -@ -O dts ex_1b_overlay.dts=20 Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no= reg property /dts-v1/; / { fragment@0 { target =3D <0xffffffff>; another_fragment_prop =3D "frag property"; __overlay__ { remote_prop =3D <0xfeedfeed 0xffffffff>; }; }; __symbols__ { }; __fixups__ { tree_1 =3D "/fragment@0:target:0"; foo =3D "/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 l= ocates >>> "/* various properties for loader use; i.e. part id etc. */". -Frank