> -----Original Message----- > From: devicetree-discuss-bounces+stephen.neuendorffer=xilinx....@lists.ozlabs. org [mailto:devicetree- > [email protected]] On Behalf Of Stephen Neuendorffer > Sent: Monday, June 28, 2010 9:51 PM > To: David Gibson; [email protected] > Cc: [email protected] > Subject: RE: [PATCH] of/fdt: Add unflatten_partial_device_tree > > > >> Another question is what to do with the unflattened tree once it is > >> unflattened. Some of the existing code expects the node to be part of > >> the global tree. Those could either be refactored, or the new partial > >> tree could be grafted into the global tree. Grafting will have the > >> least impact, but it probably isn't a good idea in the long term. > >> Grafting together unrelated trees seems messy to me. > > > >I think I must have missed an earlier discussion. What's the use case > >for multiple fdt blobs? > > Basically, we are building systems which have an FPGA sitting on a PCIe. The > FPGA contains an internal bus with lots of devices. From the structural point > of view, it seems to make sense to describe the connectivity of this subsystem > with a device tree: albeit a slightly strange one with no processor: just a pcie<->plb > bridge and a number of devices. Since this subsystem is, in fact, architecture independent > (you could physically plug it into a PCIe slot on a system with any processor architecture) > it is a bit of a poster case for generalizing more of the device tree infrastructure. > In particular, we are most interested in doing this in X86 systems. > > Which leads me back to the first question: My approach so far is that the device > tree fragment is completely independent of any toplevel device tree, for the simple > reason that on X86, there *isn't* a toplevel device tree... The devices that get generated > are in the regular device structure, which is similar to the way pci bridges and pcimcia > drivers work.
Going down this path, I've taken an approach where the PCI driver reads the PCI BARs which are set earlier and stuffs the correct ranges=<> property into the device tree. I think this is necessary because (I believe) powerpc programs the BARs based on the flat device tree, whereas on X86, the BIOS enumerates the BARs and everyone else just deals with it. This should enable the device driver to use the existing address translation code in driver/of/address.c:of_address_to_resource(). The current status is that I get something like: OF: ** translation for device /p...@0/xps-hwi...@80030000 ** OF: bus is default (na=1, ns=1) on /p...@0 OF: translating address: 80030000 OF: parent bus is default (na=1, ns=1) on / OF: walking ranges... OF: default map, cp=80000000, s=10000000, da=80030000 OF: parent translation for: d0000000 OF: with offset: 30000 OF: one level translation: d0030000 OF: reached root node of_icap d0030000.xps-hwicap: Xilinx icap port driver of_icap d0030000.xps-hwicap: Couldn't lock memory region at d0030000 of_icap: probe of d0030000.xps-hwicap failed with error -16 Apparently because the address region is already assigned to the PCI device. I think I need to figure out how PCI bridges declare their address range but don't lock it, so that the device in the FPGA (in this case the ICAP) can claim it later. Steve 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. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
