On 08/21/2012 09:38 AM, Alan Tull wrote:
> On Sat, 2012-08-18 at 10:45 -0500, Rob Herring wrote:
>> On 08/16/2012 02:43 PM, Alan Tull wrote:
>>>
>>> Hello,
>>>
>>> I'm Alan Tull, interested in dynamic features of device trees.
>>
>> Hey Alan. How are you doing?
> Doing good! Nice to hear from you.
>
>>
>>> The following patch adds a char driver to add or remove device tree
>>> nodes dynamically. Its ioctl passes a struct with:
>>> - size of the blob
>>> - pointer to the blob
>>>
>>> The path to add the nodes under is coded in the blob with dummy nodes.
>>> For example the following can be compiled into a blob and sent to this
>>> driver adding a single node under /soc/apb_periphs:
>>>
>>> /dts-v1/;
>>> / {
>>> soc {
>>> apb_periphs {
>>> i2c1: i2c@ffc05000 {
>>> compatible = "snps,designware-i2c";
>>> reg = <0xffc05000 0x1000>;
>>> interrupts = <0 159 4>;
>>> emptyfifo_hold_master = <1>;
>>> };
>>> };
>>> };
>>> };
>>>
>>> I wanted to get feeback early before I went too far down this particular
>>> path. As such, this code doesn't do any notification for drivers yet.
>>> Also it won't properly add nested nodes yet. It can add/remove a single
>>> node and see it show up properly under /proc/device-tree.
>>
>> Have you looked at arch/powerpc/platforms/pseries/reconfig.c?
> Yes. In fact I borrowed a three functions from it and gave credit in
> the patch. I'm trying to do something that is architecture independent
> and that uses the same type of device tree files (blobs) as are used
> during bootup. In my case it will run on an ARM which will have soft
> peripherals instantiated in a FPGA. So after bootup we want to be able
> to reconfigure the IP in the FPGA dynamically, then reconfigure the
> device tree and load some drivers. Pretty cool stuff.That's why I'm
> interested in doing this dynamically without a reboot.
>
>
>> There was also a recent discussion titled "OF_DYNAMIC usage" that you
>> should look at.
>>
>> I don't think a char driver and ioctls will fly...
> Doh! Yes, I know the thread. For some reason, I thought it would be
> better to post a patch as a new thread rather than posting a patch to
> the "OF_DYNAMIC usage" thread but perhaps not. Sorry for forking the
> discussion.
The fork is fine. Just making sure you were aware of it.
> That is where I got the idea of doing ioctls. I am assuming that
> there's only going to be one proper place in the tree for each blob to
> get inserted, so I leave that path information in the blob rather than
> storing it passing it as a separate parameter of the ioctl.
ioctls simply won't fly. So I would start by extending the current
interface to do blobs. From a user standpoint, something like this is
certainly easier to use than an ioctl:
echo "add blob" > /proc/devicetree/ofdt
cat blob.dtb > /proc/devicetree/ofdt
> reconfig.c's interface is pretty bad. It uses /proc as the place for
> the user to write commands. The commands are broken up such that the
> userspace has to 'add _node', then do 'add_property' a few times. Also
> it had to introduce a flag "OF_DYNAMIC" (not to be confused with
> "CONFIG_OF_DYNAMIC") to keep of_node_release from releasing the nodes
> that are allocated in reconfig.c. Seems messy.
>
> With an ioctl, the userspace can just send a single command to add a
> blob. The blob can contain one node or many nodes as long as they all
> end up under the same path. Removing nodes is just as straightforward
> and clean.
Whether paths are part of the blob are debatable. I'm sure you and your
competitors can put your heads together and come up with something. :)
Rob
>>
>> Another option could be kexecing with a new DTB if you can live with a
>> reboot.
> We are looking at reconfiguring soft peripheral in a FPGA on the fly.
> So a reboot won't work here.
>
>>
>> Rob
>>
>>>
>>> Alan Tull
>>> Altera
>>>
>>> _______________________________________________
>>> devicetree-discuss mailing list
>>> devicetree-discuss@lists.ozlabs.org
>>> https://lists.ozlabs.org/listinfo/devicetree-discuss
>>>
>>
>>
>
>
>
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
