[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <C26F7AC2-3C0E-47BF-AC37-BB1F1E246145@antoniou-consulting.com>
Date: Mon, 12 Nov 2012 14:48:33 +0200
From: Pantelis Antoniou <panto@...oniou-consulting.com>
To: Joel A Fernandes <agnel.joel@...il.com>
Cc: Grant Likely <grant.likely@...retlab.ca>,
Rob Herring <robherring2@...il.com>,
Deepak Saxena <dsaxena@...aro.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Scott Wood <scottwood@...escale.com>,
Tony Lindgren <tony@...mide.com>, Russ Dill <Russ.Dill@...com>,
Felipe Balbi <balbi@...com>, Benoit Cousson <b-cousson@...com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Koen Kooi <koen@...inion.thruhere.net>,
Matt Porter <mporter@...com>, linux-omap@...r.kernel.org,
Kevin Hilman <khilman@...com>, Paul Walmsley <paul@...an.com>,
devicetree-discuss@...ts.ozlabs.org
Subject: Re: [RFC] Device Tree Overlays Proposal (Was Re: capebus moving omap_devices to mach-omap2)
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
> <panto@...oniou-consulting.com> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists