Hi Franck, ++ Carlos On 24-06-2016 09:15, Franck Jullien wrote: > Le 23/06/2016 à 20:27, Frank Rowand a écrit : >> On 06/22/16 08:05, Franck Jullien wrote: >>> Even if a platform doesn't use a device tree during its >>> boot process it can be useful to enable CONFIG_OF and get >>> an empty device tree. >>> >>> Then, devices can use device tree overlays to populate this >>> default tree. >> >> Hi Franck, >> >> Can you elaborate on the problem that you are trying to >> solve and the use cases that you are envisioning? >> >> Thanks, >> >> Frank >> > Hi, > > The idea behind this patch is to describe devices that are in a FPGA > which is itself connected to the platform through PCIe. The platform > might not use a devicetree for its own configuration. That's why we need > this patch. This sure looks interesting to us because we are using the exactly same setup (x86_64 + FPGA through PCIe). As I said before in the DMA mailing list our approach was different: we use platform data in each driver and we register them using a PCI driver which passes all the required parameters. Still, we were wondering if your approach can save us development time in the future. So, I have a few questions that I was hoping you could answer. > > There is an ongoing discussion about this subject [1]. > > I have a working setup (on a x86_64) using this principle. I have > created a pci resources proxy module which is parent of all devices on > the FPGA. This is an example of binding: > > proxy: pci1337_0001 { > #address-cells = <1>; > #size-cells = <1>; > #interrupt-cells = <1>; > vendor-id = <0x00001337>; > device-id = <0x00000001>; > compatible = "pci1337,0001", > "generic,pci-proxy"; > interrupt-controller; > /* Ranges will be overwritten during probe */ > ranges = <0 0 0xA0000000 0x100000 /* BAR 0 */ > 1 0 0xB0000000 0x100000 /* BAR 1 */ > 2 0 0xC0000000 0x100000>; /* BAR 2 */ > }; > > Ranges are dynamically updated on probe with regards to FPGA bars. > This node is attached to the tree (an empty tree in my case) from the > client module. I am not fully understanding where does this binding is added. You use your patches to create an empty device tree or a device tree where the FPGA is declared? > > Then FPGA devices nodes are added using overlay. This is an example: > > /dts-v1/; > / { > #address-cells = <1>; > #size-cells = <1>; > > fragment@0 { > target-path = "/pci1337_0001"; > __overlay__ { > > #address-cells = <2>; > #size-cells = <1>; > interrupt-parent = <&proxy>; > > osc: oscillator { > compatible = "fixed-clock"; > #clock-cells = <1>; > clock-frequency = <148500000>; > clock-output-names = "osc"; > }; > enet0: ethoc { > compatible = "opencores,ethoc"; > reg = <1 0x50000 0x100>; > interrupts = <0>; > }; > gpio0: gpio { > #gpio-cells = <2>; > compatible = "xlnx,xps-gpio-1.00.a"; > reg = <0 0x30000 0x10000>; > gpio-controller; > }; > }; > }; > > > }; > > Interrupts property are dynamically modified before the overlay is > applied. By the way, I had to do a little hack here in the pci-proxy. > I did not declare a new interrupt domain. What I did is to get the PCI > interrupt domain (IO-APIC on my platform): > > irq_data = irq_get_irq_data(priv->pci_dev->irq); > domain_parent = irq_data->domain; > > and then set fwnode of IO-APIC to pci-proxy fwnode so > irq_create_of_mapping get IO-APIC's domain: > > domain_parent->fwnode = &np->fwnode; In my case we have an interrupt controller driver which is embedded into the PCI driver so I also can't use the generic PCI proxy without modifying it. Can this controller be declared in the overlay device tree and then make the remaining drivers use the domain created? > > There might be a better way to make things work. > > Beside this patch I needed to export of_attach_node and of_detach_node. > This will be another patch. There is still one more thing: By default CONFIG_OF is not enabled in x86_64 so you need to enable this, right? Shouldn't a "select OF" be added to your kconfig entry? > > Thank you for your interest. > > Franck. > > [1] http://www.spinics.net/lists/dmaengine/msg09869.html > Best regards, Jose Miguel Abreu -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html