On Mon, Dec 17, 2012 at 11:29:11AM -0700, Jason Gunthorpe wrote:

quoted

quoted

Ie route access for 00:1N.0 to the configuration space on bridge port N

Is there any particular reason why you choose 0x10 as the base slot
for bridge ports? With the latest DT support patches, mapping this
should be even simpler as we associate a port index with each port
and the port array is gone.

No specific reason, it similar to what intel did and clearly shows the
port number in a octet of the device id. It just can't be 0.

So I tried and implemented something along the lines of what you
suggested, and guess what? It does work indeed. For some reason even the
"imprecise external abort" goes away. Basically what I did is fake the
configuration space accesses to 0000:0.0 so that they return semi-valid
data. Nothing special yet, just basically returning vendor and product
ID, header type, class and other static data.

Initially the implementation was read-only and that still caused the
external abort, but adding nop'ed write functions apparently solved
that.

What I'll do next is add some caching of written values, so that reading
them back actually yields something correct. After that I'll post what I
have so that others can look at it or even reuse it.

The problem of matching DT nodes to the root ports still isn't solved,
but I'll take another look at that tomorrow.

quoted

quoted

Then you are a bit closer. You should see both root port bridges
appear in your lspci.. IIRC the host bridge device is not essential to
discovery working on Linux.

The second port will probably still not appear, at least not in the
latest patches for DT support since it won't be registered unless
enabled. Even if enabled it will not be registered unless a link is
available, which it isn't in any of the setups that I currently have.
I'll need to check with our hardware engineers whether we can hook
something up to the second port.

You can probably bodge around and just register it anyhow, the
internal bridge will still show up in linux, even though there is no
device behind it.

I'm not sure if PCI-E ports should be ignored if the link is down. The
kernel has the ability to re-scan them at runtime, and if the
controller has a link up interrupt then it can happen automatically.

I sent through a patch for kirkwood that did this, we hot plug the
PCIe device because userspace intializes it.

I don't think the root ports on Tegra support this. Or at least there's
no code to support it yet. I'll see if I can at least modify the code to
still show the root port on the bus if it is enabled but the link is not
available. The DT binding allows each port to be enabled so that if a
board configuration doesn't provide a physical connection the software
doesn't have to bother initializing it.
available.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121217/207850de/attachment-0001.sig>