From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: local bus enumeration beyond a PCI device
Date: Mon, 22 Apr 2024 10:59:50 +0300 [thread overview]
Message-ID: <ZiYY9u7uL7hnetFU@surfacebook.localdomain> (raw)
In-Reply-To: <bad63409-ed2b-4cef-988b-3c143636e9fa@alliedtelesis.co.nz>
Thu, Apr 18, 2024 at 12:24:06AM +0000, Chris Packham kirjoitti:
> 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.
>
> But as things can change based on the FPGA program I'd like some
> flexibility to treat it separately from the PCI bridge.
Why? AFAIU the architecture, you have an FPGA with a real PCI bridge / switch,
no? If it's the case, the software shouldn't care if the respective IP comes
from FPGA or SoC.
> 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?
AFAIK there is an FPGA framework in the kernel and the idea is that each FPGA
configuration provides a complimentary DT to describe the hardware setup. As
Bjorn Cc'ed this to Herve you may get the answer on what's going on there much
better as I'm not involved in the development of that topic.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-04-22 7:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-18 0:24 local bus enumeration beyond a PCI device Chris Packham
2024-04-18 18:45 ` Bjorn Helgaas
2024-04-22 8:00 ` Andy Shevchenko
2024-04-23 1:05 ` Chris Packham
2024-04-23 11:33 ` Herve Codina
2024-04-22 7:59 ` Andy Shevchenko [this message]
2024-04-23 1:12 ` Chris Packham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZiYY9u7uL7hnetFU@surfacebook.localdomain \
--to=andy.shevchenko@gmail.com \
--cc=Chris.Packham@alliedtelesis.co.nz \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox