Re: [PATCH V13 2/5] PCI: Create device tree node for bridge

[Andy Shevchenko]

On Mon, Sep 11, 2023 at 05:22:56PM +0100, Jonathan Cameron wrote:
> On Mon, 11 Sep 2023 16:47:41 +0100
> Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote:
> > On Mon, 11 Sep 2023 17:35:03 +0200
> > Herve Codina <herve.codina@xxxxxxxxxxx> wrote:
> > > On Mon, 11 Sep 2023 15:48:56 +0100
> > > Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote:
> > > > On Tue, 15 Aug 2023 10:19:57 -0700
> > > > Lizhi Hou <lizhi.hou@xxxxxxx> wrote:

> > > > > The PCI endpoint device such as Xilinx Alveo PCI card maps the register
> > > > > spaces from multiple hardware peripherals to its PCI BAR. Normally,
> > > > > the PCI core discovers devices and BARs using the PCI enumeration process.
> > > > > There is no infrastructure to discover the hardware peripherals that are
> > > > > present in a PCI device, and which can be accessed through the PCI BARs.
> > > > > 
> > > > > Apparently, the device tree framework requires a device tree node for the
> > > > > PCI device. Thus, it can generate the device tree nodes for hardware
> > > > > peripherals underneath. Because PCI is self discoverable bus, there might
> > > > > not be a device tree node created for PCI devices. Furthermore, if the PCI
> > > > > device is hot pluggable, when it is plugged in, the device tree nodes for
> > > > > its parent bridges are required. Add support to generate device tree node
> > > > > for PCI bridges.
> > > > > 
> > > > > Add an of_pci_make_dev_node() interface that can be used to create device
> > > > > tree node for PCI devices.
> > > > > 
> > > > > Add a PCI_DYNAMIC_OF_NODES config option. When the option is turned on,
> > > > > the kernel will generate device tree nodes for PCI bridges unconditionally.
> > > > > 
> > > > > Initially, add the basic properties for the dynamically generated device
> > > > > tree nodes which include #address-cells, #size-cells, device_type,
> > > > > compatible, ranges, reg.
> > > > > 
> > > > > Acked-by: Bjorn Helgaas <bhelgaas@xxxxxxxxxx>
> > > > > Signed-off-by: Lizhi Hou <lizhi.hou@xxxxxxx>      
> > > > 
> > > > I tried to bring this up for a custom PCIe card emulated in QEMU on an ARM ACPI
> > > > machine.
> > > > 
> > > > There are some missing parts that were present in Clements series, but not this
> > > > one, particularly creation of the root pci object.
> > > > 
> > > > Anyhow, hit an intermittent crash...    
> > > 
> > > I am facing the same issues.
> > > 
> > > I use a custom PCIe board too but on x86 ACPI machine.
> > > 
> > > In order to have a working system, I need also to build a DT node for the PCI
> > > Host bridge (previously done by Clement's patch) and I am a bit stuck with
> > > interrupts.
> > > 
> > > On your side (ACPI machine) how do you handle this ?  
> > 
> > That was next on my list to look at now I've gotten the device tree stuff
> > to show up.
> > 
> > > I mean is your PCI host bridge provided by ACPI ? And if so, you probably need
> > > to build a DT node for this PCI host bridge and add some interrupt-map,
> > > interrupt-map-mask properties in the DT node.  
> > 
> > Agreed. Potentially some other stuff, but interrupts are the thing that
> > showed up first as an issue.
> > 
> > Given the only reason I'm looking at this is to potentially solve
> > a long term CXL / MCTP over I2C upstreaming problem on QEMU side, I've only
> > limited time to throw at this (thought it was a short activity
> > for a Friday afternoon :)  Will see if it turns out not too be
> > too hard to build the rest.
> > 
> > I can at least boot same system with device tree and check I'm matching
> > what is being generated by QEMU.
> 
> So, I'm not really sure how to approach this.  It seems 'unwise'/'unworkable' to
> instantiate the device tree blob for the interrupt controller we already have
> ACPI for and without that I have nothing to route to.
> 
> Or can we just ignore the interrupt map stuff completely and instead
> rely on instantiating an interrupt controller on the card (that under
> the hood uses non DT paths to make interrupts actually happen?)
> 
> That path to me seems workable and keeps the boundary of ACPI vs DT
> actually getting used within the card specific driver.
> 
> Suggestions welcome!

Interestingly I haven't got your message in the thread via `b4`.
Anyways, I think that was has been discussed at some point and
DT appears just to be handy blob format to be supplied along with
the device as "description of its configuration". Whatever format
is chosen it should be available for ACPI/DT/etc platforms and
be uniform. ACPI also supports overlays (as a debug feature, though)
but would it make sense to have AML (compiled ASL) for ACPI and DTB
for DT platforms and etc for etc platforms with duplicative data
inside with all limitations of the each of those formats and their
respective parsers/interpreters?

-- 
With Best Regards,
Andy Shevchenko