linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Hawkins <dwh@ovro.caltech.edu>
Cc: "linuxppc-dev@ozlabs.org list" <linuxppc-dev@ozlabs.org>,
	Felix Radensky <felix@embedded-sol.com>,
	Ira Snyder <iws@ovro.caltech.edu>
Subject: Re: MPC8536 PCI rescan to discover FPGA
Date: Tue, 22 Sep 2009 17:23:03 +1000	[thread overview]
Message-ID: <1253604183.7103.213.camel@pasglop> (raw)
In-Reply-To: <4AB7A411.3030406@ovro.caltech.edu>

On Mon, 2009-09-21 at 09:04 -0700, David Hawkins wrote:
> This can be made to work using the kernel hot-swap
> interface. PCI devices have an ENUM# interrupt that
> they assert when inserted or extracted, and the host
> hot-swap driver can be hooked up to it. PCI-E may
> have a similar mechanism, if it does, then when your
> FPGA configures as a PCI-E device, it can assert that
> interrupt line (or send the appropriate PCI-E
> message to simulate that interrupt).
> 
> However, even if PCI-E does not have the concept of
> an ENUM# interrupt there is a way to generate a fake
> hot-swap event and generate a re-scan of the PCI bus.
> 
> I haven't tested the kernel hot-swap interface, but I
> know that Ira did, so I'll cc him on this mail, and he
> can let you know what he tested.

Right. However, in case it's a bit too much work to get
hotswap implemented on the machine, you may still be able
to do something simpler from your platform code, after you've
finished loading the FPGA. I assume the FPGA doesn't contain a
P2P bridge that would require probing further below the FPGA
itself.

The basic idea is to call pci_scan_slot() on the devfn where
the FPGA is supposed to respond.

Then you need to also do some fixup. First you need to call
pcibios_setup_bus_devices(). This will wire up the device
to an OF node if you have one, setup some default DMA ops,
etc...

Note that this function will walk over all devices on that bus
which is interesting since some of those may have already been
fully setup initially. Hopefully that isn't a problem. If it
was to become one, we would have to figure out a way to skip
devices that have already been "setup".

And finally you call pcibios_finish_adding_to_bus() which will
do the resource allocation pass on all new devices on the bus
and register them with the core device layer.

Cheers,
Ben.

  reply	other threads:[~2009-09-22  7:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-21 15:35 MPC8536 PCI rescan to discover FPGA Felix Radensky
2009-09-21 16:04 ` David Hawkins
2009-09-22  7:23   ` Benjamin Herrenschmidt [this message]
2009-09-30  7:06     ` Felix Radensky

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=1253604183.7103.213.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=dwh@ovro.caltech.edu \
    --cc=felix@embedded-sol.com \
    --cc=iws@ovro.caltech.edu \
    --cc=linuxppc-dev@ozlabs.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;
as well as URLs for NNTP newsgroup(s).