<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7655.4">
<TITLE>RE: [PATCH] of/fdt: Add unflatten_partial_device_tree</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>>> Another question is what to do with the unflattened tree once it is<BR>
>> unflattened. Some of the existing code expects the node to be part of<BR>
>> the global tree. Those could either be refactored, or the new partial<BR>
>> tree could be grafted into the global tree. Grafting will have the<BR>
>> least impact, but it probably isn't a good idea in the long term.<BR>
>> Grafting together unrelated trees seems messy to me.<BR>
><BR>
>I think I must have missed an earlier discussion. What's the use case<BR>
>for multiple fdt blobs?<BR>
<BR>
Basically, we are building systems which have an FPGA sitting on a PCIe. The<BR>
FPGA contains an internal bus with lots of devices. From the structural point<BR>
of view, it seems to make sense to describe the connectivity of this subsystem<BR>
with a device tree: albeit a slightly strange one with no processor: just a pcie<->plb<BR>
bridge and a number of devices. Since this subsystem is, in fact, architecture independent<BR>
(you could physically plug it into a PCIe slot on a system with any processor architecture)<BR>
it is a bit of a poster case for generalizing more of the device tree infrastructure.<BR>
In particular, we are most interested in doing this in X86 systems.<BR>
<BR>
Which leads me back to the first question: My approach so far is that the device<BR>
tree fragment is completely independent of any toplevel device tree, for the simple<BR>
reason that on X86, there *isn't* a toplevel device tree... The devices that get generated<BR>
are in the regular device structure, which is similar to the way pci bridges and pcimcia<BR>
drivers work.<BR>
<BR>
Steve<BR>
<BR>
</FONT>
</P>
<br clear=all> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
</BODY>
</HTML>