Le Wed, 6 Apr 2022 15:33:46 +0200, Alexandre Belloni <alexandre.belloni@xxxxxxxxxxx> a écrit : > On 06/04/2022 08:19:16-0500, Rob Herring wrote: > > > > > > I've told the Xilinx folks the same thing, but I would separate this > > > > > > into 2 parts. First is just h/w work in a DT based system. Second is > > > > > > creating a base tree an overlay can be applied to. The first part should > > > > > > be pretty straightforward. We already have PCI bus bindings. The only > > > > > > tricky part is getting address translation working from leaf device thru > > > > > > the PCI bus to host bus, but support for that should all be in place > > > > > > (given we support ISA buses off of PCI bus). The second part will > > > > > > require generating PCI DT nodes at runtime. That may be needed for both > > > > > > DT and ACPI systems as we don't always describe all the PCI hierarchy > > > > > > in DT. > > > > > > > > > > But then, if the driver generate the nodes, it will most probably > > > > > have to describe the nodes by hardcoding them right ? > > > > > > > > No, the kernel already maintains its own tree of devices. You just > > > > need to use that to generate the tree. That's really not much more > > > > than nodes with a 'reg' property encoding the device and function > > > > numbers. > > > > > > Just to clarified a point, my PCI device exposes multiple peripherals > > > behind one single PCI function. > > > > Right. I would expect your PCI device DT node to have a 'simple-bus' > > child node with all those peripherals. And maybe there's other nodes > > like fixed-clocks, etc. > > > > > To be sure I understood what you are suggesting, you propose to create > > > a DT node from the PCI driver that has been probed dynamically > > > matching this same PCI device with a 'reg' property. I also think > > > this would requires to generate some 'pci-ranges' to remap the > > > downstream devices that are described in the DTBO, finally, load the > > > overlay to be apply under this newly created node. Is that right ? > > > > Right. You'll need to take the BAR address(es) for the device and stick > > those into 'ranges' to translate offsets to BAR+offset. > > > > Last time I tried that, this was not working well because it means that > the ranges property of the device depends on the host machine... > Yes, but we can actually resolve that dynamically. The ranges property that is inserted is inserted in the top node (the PCI device one). Since this node will be created by "us" (the kernel/driver), we can insert whatever we want. And most probably, we'll insert a specific BAR remapping. The underlying nodes will then be loaded from the overlay and merged in the top PCI device node (At least I guess ;)). These nodes don't need any "machine dependent" addresses, only realtive addresses from the top node. -- Clément Léger, Embedded Linux and Kernel engineer at Bootlin https://bootlin.com
