Hi, On 19/04/24 06:45, Bjorn Helgaas wrote: > [+cc Herve] > > On Thu, Apr 18, 2024 at 12:24:06AM +0000, Chris Packham wrote: >> Hi, >> >> We've got a custom x86_64 based design that is using an ASIX9100 to >> provide a PCI to local bus bridge. Attached to that local bus is an FPGA >> which mostly provides some GPIOs accessed via registers on the local >> bus. Right now we've got a custom driver that bundles everything >> together so effectively we've got a PCI device that provides GPIOs. > What's the local bus? The ASIX9100 (for which Google doesn't find any > details) would have a PCI interface on the primary (upstream) side. > What's the local bus on the secondary (downstream) side? Below you > mention "PCI bridge", which normally means both the primary and > secondary sides are PCI buses. The ASIX9100 is a multi purpose chip with a few options for providing GPIO/I2C/SPI/etc. In our hardware configuration we're using it to provide a 16-bit parallel bus which we're using for register access to the FPGA. There's an outside chance someone might ask us to hang other parallel devices like an SRAM or some NOR Flash off it as well. These are all things we've done on other products with more traditional embedded SoCs that have a parallel bus interface. > If the local bus is not PCI, I guess the ASIX9100 would look to the OS > like an endpoint, i.e., PCI_HEADER_TYPE_NORMAL, and the ASIX9100 > driver would handle any "bridge" functionality completely internally? I might be using the terminology wrong. Essentially the ASIX9100 is a PCI-e endpoint (so a device from the PCI subsystems point of view) but that device can be a I2C, SPI or parallel bus controller onto which other devices are connected.Hence it's providing a bridge between PCI and 16-bit parallel busses. > Maybe Herve's work at > https://lore.kernel.org/r/20240325153919.199337-1-herve.codina@xxxxxxxxxxx > would be relevant? I've had a quick look at that series. I'm not 100% sure it'll help. The platform I'm dealing with is x86_64 and doesn't have device tree support (if someone can say "hey do xyz and you'll get DT on x86" that'd be great).But I'll take a closer look at it and at the original "Generate device tree node for pci devices" series. >> But as things can change based on the FPGA program I'd like some >> flexibility to treat it separately from the PCI bridge. So really I'd >> like to have a PCI device driver for the ASIX9100 that provides a local >> bus controller and a (platform?) driver for the FPGA that provides the >> GPIOs where I can have different compatibles for the different >> implementations. >> >> Then in the ACPI overlay I'd have something like >> >> Scope (\_SB.PCI0.D0B0) >> { >> Device (ASIX) >> { >> Name (_ADR, 0x0000) >> >> Device (FPGA) >> { >> Name (_HID, "PRP0001") >> Name (_DSD, Package () >> { >> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), >> Package () >> { >> Package () { >> "compatible", "my-platform-driver-for-fpga" }, >> } >> }) >> } >> } >> } >> >> Scope(\_SB) >> { >> Device(OTHR) >> { >> GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, >> "\\_SB.PCI0.D0B0.ASIX.FPGA",) { 0 } >> } >> } >> >> Is it even possible to register a host controller for another platform bus? >> >> Thanks, >> Chris
