Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752346Ab2KLMsn (ORCPT ); Mon, 12 Nov 2012 07:48:43 -0500 Received: from li42-95.members.linode.com ([209.123.162.95]:57565 "EHLO li42-95.members.linode.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751552Ab2KLMsm convert rfc822-to-8bit (ORCPT ); Mon, 12 Nov 2012 07:48:42 -0500 Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Pantelis Antoniou In-Reply-To: Date: Mon, 12 Nov 2012 14:48:33 +0200 Cc: Grant Likely , Rob Herring , Deepak Saxena , Benjamin Herrenschmidt , Scott Wood , Tony Lindgren , Russ Dill , Felipe Balbi , Benoit Cousson , linux-kernel , Koen Kooi , Matt Porter , linux-omap@vger.kernel.org, Kevin Hilman , Paul Walmsley , devicetree-discuss@lists.ozlabs.org Content-Transfer-Encoding: 8BIT Message-Id: References: <02FF5400-9F97-4B8A-AEF0-267B01C8099F@antoniou-consulting.com> <-4237940489086529028@unknownmsgid> <559B8433-67C3-4A1A-A5D6-859907655176@antoniou-consulting.com> To: Joel A Fernandes X-Mailer: Apple Mail (2.1085) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3634 Lines: 88 Hi Joel, Again, sorry for the late reply due to travel. On Nov 10, 2012, at 5:36 AM, Joel A Fernandes wrote: > Hi Pantelis, > > On Fri, Nov 9, 2012 at 2:13 AM, Pantelis Antoniou > wrote: > >>>>> Option C: U-Boot loads both the base and overlay FDT files, merges them, >>>>> and passes the resolved tree to the kernel. >>>>> >>>> >>>> Could be made to work. Only really required if Joanne wants the >>>> cape interface to work for u-boot too. For example if the cape has some >>>> kind of network interface that u-boot will use to boot from. >>>> >>> >>> I love Grant's hashing idea a lot keeping the phandle problem for >>> compile time and not requiring fixups. >>> >>> IMO it is still a cleaner approach if u-boot does the tree merging for >>> all cases, and not the kernel. >>> >>> That way from a development standpoint, very little or nothing will >>> have to be changed in kernel (except for scripts/dtc) considering we >>> are moving forward with hashing. >>> >>> Also this discussed a while back but at some point is going to brought >>> up again- loading of dt fragment directly from EEPROM and merging at >>> run time. If we were to implement this in kernel, we would have to add >>> cape specific EEPROM reading code, merge the tree before it is >>> unflattened and parse. I think doing tree merging in kernel is messy >>> and we should do it in uboot. Ideally reading the fragment from the >>> EEPROM for all capes and merging without worrying about version >>> detection, Doing the merge and passing the merged blob to the kernel >>> which (kernel) works the same way it does today. >> >> Not going to work, for a lot of cases. Doing it in the kernel seems to be >> the cleaner option. There are valid use cases for doing in u-boot too. > > True, if dynamic runtime stuff from userspace is what we're talking > about, then yeah I see the important need for kernel to do the merge. > Kernel doing the merge is our use case, and I feel it's the use case of about 90% of users. u-boot doing the merge is the rest. >>> Alternatively to hashing, reading david gibsons paper I followed, >>> phandle is supposed to 'uniquely' identity node. I wonder why the node >>> name itself is not sufficient to unquiely identify. The code that does >>> the tree walking can then just strcmp the node name while it walks the >>> tree instead of having to find a node with a phandle number. I guess >>> the reason is phandles are small to store as data values. Another >>> approach can be to arrange the string block in alphabetical order >>> (unless it already is), and store phandle as index of the node name >>> referenced relative to the starting of the strong block. This will not >>> affect nodes in dtb being moved around since they will still have the >>> same index value. the problem being adding or removing nodes Changes >>> the offsets of all other nodes in the string block as well.. Hmm. >>> >> >> This is pretty radical change to the DT format, no? > > Yes, true and the only way hypothetically to replace the phandle > tree-walking mechanism is to store node paths instead of phandle which > David pointed is too long to store, so I guess this wont work after > all. Anyway this was an interesting exercise, thanks. > It is always nice to have a fresh perspective. Thank you. > Regards, > Joel Regards -- Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/