From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>,
Roderick Colenbrander <thunderbird2k@gmail.com>,
John Linn <John.Linn@xilinx.com>
Subject: Re: Musings on PCI busses
Date: Wed, 20 May 2009 13:01:30 +1000 [thread overview]
Message-ID: <1242788490.16901.133.camel@pasglop> (raw)
In-Reply-To: <fa686aa40905190828x251765dek586f5bf8e73e4cf7@mail.gmail.com>
On Tue, 2009-05-19 at 09:28 -0600, Grant Likely wrote:
> 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).
We are doing that on Cell as mentioned by Arnd. However, there are a
few issues with that approach. One is that it relies on PCI-hotplug
related bits that currently only exist in 64-bit land. Another is
that doing so tends to expose various hidden issues or subtle
dependencies to the PCI stuff being setup early and probed early.
For example, some of the OF parsing bits may fail to convert memory
addresses to IO addresses if the PCI host bridges have not been
discovered yet, potentially causing issues with matching of resources
between the early serial stuff and the generic serial driver (if you
use an IO driven UART, the PCI 8250 driver may not properly figure out
that what it's finding in its IO BARs is actually the same port as
what it gets from the platform code as the later will end up with
memory addresses rather than IO ones). That's one example.
At this stage, I much prefer if we stick to doing the PHB discovery
at setup_arch() time, especially since there's other WIP in the area
of PCI coming from Kumar and I don't want to mixup multiple source of
problems in that area at the same time.
We can revisit that later but we'll have to be very careful.
Cheers,
Ben.
next prev parent reply other threads:[~2009-05-20 3:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-19 15:28 Musings on PCI busses Grant Likely
2009-05-19 16:12 ` 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 [this message]
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=1242788490.16901.133.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=John.Linn@xilinx.com \
--cc=grant.likely@secretlab.ca \
--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).