On 12/17/2012 07:51 PM, Jason Gunthorpe wrote:

[trimmed the cc list]

On Mon, Dec 17, 2012 at 07:10:59PM -0700, Stephen Warren wrote:

quoted

quoted

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.

Some internal discussion implies this shouldn't be required; here's
what they said:

Looking at the driver, it says:

+ * 0x80000000 - 0x80003fff - PCI controller registers
+ * 0x80004000 - 0x80103fff - PCI configuration space
+ * 0x80104000 - 0x80203fff - PCI extended configuration space

And the bridge config regions are at:

+#define RP0_OFFSET     0x0000
+#define RP1_OFFSET     0x1000

And from the first checkin, config space accesses have been split into
three designations:
 bridge #0 - 0x80000000 + 0
 bridge #1 - 0x80000000 + 0x1000
 Every other bus - 0x80104000 + [equation]

And based on Thierry's results it looks like once the bridge
subordinate bus numbers are setup (via their lower mappings) then the
'every other bus' mapping starts working as expected.

So.. is there a register to be set that lets the bridge configuration
be accessed through the [0x80004000 - 0x80103fff] region as bus 0?
Presumably a non-PCI device number register?

It looks like some PCI host controller registers do need to be set up
(so far the information is related to "type 0" vs. "type 1"
configuration accesses, although I'm not familiar with what that means).

Jay will continue to drive this with our HW folks and try and get this
working.