Hi Phil, > On Nov 24, 2016, at 15:49 , Phil Elwell <phil@xxxxxxxxxxxxxxx> wrote: > > On 24/11/2016 12:31, Pantelis Antoniou wrote: >> This patch enable the generation of symbols & local fixup information >> for trees compiled with the -@ (--symbols) option. >> >> Using this patch labels in the tree and their users emit information >> in __symbols__ and __local_fixups__ nodes. >> >> The __fixups__ node make possible the dynamic resolution of phandle >> references which are present in the plugin tree but lie in the >> tree that are applying the overlay against. >> >> While there is a new magic number for dynamic device tree/overlays blobs >> it is by default disabled. This is in order to give time for DT blob >> methods to be updated. >> >> Signed-off-by: Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx> >> Signed-off-by: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> >> Signed-off-by: Jan Luebbe <jlu@xxxxxxxxxxxxxx> > It's great to see this work about to come to fruition, but I have a > reservation about this patch. Like previous versions, this > implementation generates __fixups__, __local_fixups__ and __symbols__ > whenever the "-@" command line parameter is given; without it you get > none. In my opinion, this logic causes the DTBs to be unnecessarily > large with no obvious benefit. > > You can divide the compiled outputs from DTC into two categories - fully > resolved DTBs (what I would call base DTBs), and overlays. Base DTBs > should include __symbols__ to allow overlays to be applied, and it is > right that this should be controlled by the "-@" flag, but since base > DTBs are fully resolved I think there is no reason to include either > __fixups__ or __local_fixups__. Therefore I think both kinds of fixups > should only be omitted when the "/plugin/ " directive is used. This was > the purpose of one of the patches I provided you with. > Yes, I’m quite aware of that. There is a reason for generating every resolve node for the base tree. It contains information about the dependencies of every hardware device due to phandle references. We can utilize that to re-order the device probe order to eliminate -EPROBE_DEFER cycles upon boot. It is important we get the core support in and then you can add extra switches for every special platform case. What kind of problems do you have with larger device tree blobs? I do carry a hashed phandle patch on my mainline tracking tree which should help with larger DTBs. > Phil Elwell, Raspberry Pi Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
