OF_DYNAMIC usage

[Stephen Neuendorffer]

> -----Original Message-----
> From: devicetree-discuss [mailto:devicetree-discuss-
> bounces+stephen.neuendorffer=xilinx.com at lists.ozlabs.org] On Behalf Of
> Benjamin Herrenschmidt
> Sent: Friday, July 06, 2012 1:10 AM
> To: monstr at monstr.eu
> Cc: devicetree-discuss at lists.ozlabs.org
> Subject: Re: OF_DYNAMIC usage
> 
> On Fri, 2012-07-06 at 10:02 +0200, Michal Simek wrote:
> 
> > ok. How that FDT blob segment should look like?
> > It can't be just one node because it also requires path where it is
> connected.
> >
> > It means at least the part like below for injecting.
> 
> No, my idea was to pass 3 arguments:
> 
>  - action (enum)
>  - path (string)
>  - segment (blob)
> 
> action would be typically add/remove
> 
>  * add: add node under <path> whose content is in <segment>
> 
>  * remove: remove node <path> and all children
> 
> (or we could require children removal to be done explicitly).

I've implemented something like Michal's suggestion, although I never
worked out the details of removing.  Primarily, I was interested in the
slightly simpler case of a PCIe endpoint, whose contents are described
by a device tree.  This means that the device tree fragment has
to be able to be independent of its context.  Basically, I added a
function: 

+/**
+ * unflatten_partial_device_tree - create tree of device_nodes from
flat blob
+ *
+ * unflattens the device-tree passed by the firmware, creating the
+ * tree of struct device_node. It also fills the "name" and "type"
+ * pointers of the nodes so the normal device-tree walking functions
+ * can be used.
+ */
+void unflatten_partial_device_tree(unsigned long *blob, struct
device_node **mynodes)

That can be called by a device driver, like:

+       unflatten_partial_device_tree(drvdata->fw_entry->data,
+                                     &drvdata->child_nodes);
+
+       /* Generate child devices from the device tree */
+       of_platform_bus_probe(drvdata->child_nodes, NULL, &pdev->dev);

Part of the reason for implementing it this way is that it allows the
result to work on x86, where
there may not be a toplevel device tree, so adding and deleting device
nodes is handled at the device level, rather than having the device
trees themselves be dynamic.  The downside, of course it that it is
harder to get references from one device tree fragment into another.
However, in the case of either partial reconfiguration or PCIe, I think
this makes more sense than the OF_DYNAMIC way.

We demonstrated this working in a PCIe system and posted the patches
several years ago, but they were never mainlined, and the
architecture-independent device tree pieces have gone through a lot of
change since then.  Maybe Michal can get them to compile and post
updated versions for more comment?

Steve


> 
> Cheers,
> Ben.
> 
> > /dts-v1/;
> > / {
> > 	#address-cells = <1>;
> > 	#size-cells = <1>;
> > 	compatible = "xlnx,microblaze";
> >
> > 	mb_plb: plb at 0 {
> > 		#address-cells = <1>;
> > 		#size-cells = <1>;
> > 		compatible = "xlnx,plb-v46-1.00.a", "simple-bus";
> > 		DIP_Switches_4Bit: gpio at 81440000 {
> > 			#gpio-cells = <2>;
> > 			compatible = "xlnx,xps-gpio-1.00.a";
> > 			gpio-controller ;
> > 			reg = < 0x81440000 0x10000 >;
> > 			/* ... */
> > 		} ;
> > 	} ;
> > };
> >
> > Not sure if this can be used for removing. I mean if you want to
> remove node
> > if make sense to pass the whole node.
> >
> >
> > Thanks,
> > Michal
> >
> >
> 
> 
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss


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.