From: Grant Likely <grant.likely@secretlab.ca>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Kumar Gala <galak@kernel.crashing.org>,
Josh Boyer <jwboyer@linux.vnet.ibm.com>,
Roderick Colenbrander <thunderbird2k@gmail.com>,
John Linn <John.Linn@xilinx.com>,
linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Musings on PCI busses
Date: Tue, 19 May 2009 09:28:32 -0600 [thread overview]
Message-ID: <fa686aa40905190828x251765dek586f5bf8e73e4cf7@mail.gmail.com> (raw)
Hey all,
I've been having some thoughts on PCI host controller probing and how
best to handle it. Currently AFAICT, the SoC platform code explicitly
calls the PCI setup code. In all of the existing SoCs this works fine
because there is SoC specific platform code which knows what PCI
busses to expect on the SoC.
I'm now looking at the case of Xilinx Virtex FPGA support. Because it
is an FPGA and the SW view of the design is so flexible and fluid, I'm
trying to keep platform code unified for all Virtex platforms. (ie.
two radically different board layouts can look identical from the
CPU's perspective, or the behaviour of one board can be completely
changed with a new bitstream).
Roderick has written a patch to support one of the Xilinx reference
designs that includes a PCI host controller. Right now the patch adds
a separate platform file, but I'm not comfortable with the approach
(despite suggesting it to Roderick in the first place) because it
relegates PCI support to only work with the ml510 reference design.
ie. PCI will not be automatically supported for anyone who modifies
the reference design or adds the PCI host controller to their own
design. So I've been thinking of alternatives. Here's what I've come
up with.
1) Probe the host controller in an of_platform driver. This has the
advantage of simplicity. The probe routine will get automatically
called when the PCI host controller device tree node is registered
with the of_platform bus. The bus parenthood also gets reflected in
the device model and sysfs. The disadvantage is that it defers PCI
bus probing until after the of_platform bus is probed (maybe this is
okay; maybe this already happens anyway).
2) Probe the host controller in an subsys_initcall(). Advantage is
PCI can be probed earlier in the init path. Disadvantages (minor) are
that it will always get called if the driver is enabled, and it needs
to manually search the device tree for PCI nodes.
I'm leaning towards making it an of_platform driver. Doing so also
makes it available to other powerpc processors (not just virtex) in
the case where a Xilinx FPGA is welded up to a discrete SoC and a host
controller instance is put into the FPGA. (one of those weird things
people do when they have an FPGA in their system).
Comments? Opinions?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
next reply other threads:[~2009-05-19 15:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-19 15:28 Grant Likely [this message]
2009-05-19 16:12 ` Musings on PCI busses Arnd Bergmann
2009-05-19 19:05 ` David Miller
2009-05-19 20:02 ` Grant Likely
2009-05-20 5:33 ` Benjamin Herrenschmidt
2009-05-19 16:25 ` Stephen Neuendorffer
2009-05-19 16:30 ` Grant Likely
2009-05-20 3:02 ` Benjamin Herrenschmidt
2009-05-20 3:17 ` Grant Likely
2009-05-20 5:31 ` Benjamin Herrenschmidt
2009-05-20 3:01 ` Benjamin Herrenschmidt
2009-05-20 5:51 ` David Miller
2009-05-20 6:51 ` Benjamin Herrenschmidt
2009-05-20 19:24 ` David Miller
2009-05-20 20:06 ` Grant Likely
2009-05-20 21:59 ` Benjamin Herrenschmidt
2009-05-20 22:28 ` Grant Likely
2009-05-20 22:41 ` David Miller
2009-05-20 22:49 ` Benjamin Herrenschmidt
2009-05-20 21:56 ` Benjamin Herrenschmidt
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=fa686aa40905190828x251765dek586f5bf8e73e4cf7@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=John.Linn@xilinx.com \
--cc=benh@kernel.crashing.org \
--cc=galak@kernel.crashing.org \
--cc=jwboyer@linux.vnet.ibm.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=thunderbird2k@gmail.com \
/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).