On Fri, 2012-07-06 at 08:51 +0200, Michal Simek wrote: > On 07/06/2012 08:19 AM, Benjamin Herrenschmidt wrote: > > On Fri, 2012-07-06 at 08:03 +0200, Michal Simek wrote: > >>> > >>> The way it works at the moment is that when something new is plugged in, > >>> the hypervisor talks to a proprietary crap daemon in userspace which > >>> talks to a special tool (that one we have the source code) which then > >>> obtains via some FW interfaces a "blob" of bits of device-tree to add > >>> (or to remove), using a phyp specific format, and echo that stuff > >>> into /proc/ppc64/ofdt. > >> > >> Where is that source code for the special tool? > > > > I can dig that for you, however ... > > > >> Can you point me to the "phyp specific format"? > > > > Same deal, I don't think there's a public doc, however.. > > Why is it in the kernel something which does not have any public > documentation? > It seems like that it is more proprietary code.
Don't ask me, it's been there since day 1 of the ppc64 port afaik, before I was involved in it. I've been wanting to deprecate that interface for a while, but haven't got to it yet. > > > >> From reconfig.c it looks like that there are some key words like > >> add_node/remove_node/add_property... follow by space and node name + > >> options which lookes like dtb format. > > > > Right, I would just recommend you don't do that. > > > > The need to "hotplug" bits of device-tree is going to be generic enough > > that we should come up with something better and more generic than that > > pseries stuff. > > > > IE. Some way to pass bits of ftb blob rather than this specific format > > to begin with, etc... > > Can we discuss this a little bit more? Sure :-) > From my partial reconfiguration understanding is that you have partial > bitstream > which you pass through pcap(IP and driver which can do it) to specific > location > which they are known. > > It means you have to unplug device which is in the same location, > load partial bitstream via pcap > register driver and probe it. > > I expect that pcap driver could be aware which driver is at that location > and is able to plug and unplug it based on description. > > I will ask Xilinx how this is exactly done and I hope I will get any example > to be able to do some experiments. > > > > > So I'd say just ignore the pseries stuff, I can dig the tool etc... if > > you -really- need them but I'd rather you don't base your stuff on it, > > just make up something better& more generic for you. It will be useful > > to others. > > My point here is just to try to understand current working version > to get the better overview how it is done and probably working somehow. > > Of course some ideas how this can/should be done will be helpful. Well, I think the right way is to have some mechanism (TBD) to be able to inject into the kernel a bit of device-tree (or remove a bit of device-tree). Ideally by passing it an FDT blob segment which is a well known & documented format. The kernel would then expand it and call some notifiers which we can use to create platform devices if needed etc... Cheers, Ben. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
