On Thursday 13 December 2012, Thomas Petazzoni wrote:

Dear Jason Gunthorpe,

On Thu, 13 Dec 2012 10:54:42 -0700, Jason Gunthorpe wrote:

quoted

On Thu, Dec 13, 2012 at 12:19:39PM +0000, Arnd Bergmann wrote:
 

quoted

Do those ten ports have a shared I/O space window, or does each one
have its own 64K? 

The smallest mbus routing window size is 64k, and you need to use a
mbus routing window per PEX to decode into IO.

Correct.

quoted

Thomas: Note this complicates my earlier suggestion of just using
config transactions because this is horribly non-conformant, PCIe
requires a much finer granularity for the root port bridge, it would
need some kind of specialness to make the standard Linux resource
allocator work properly.... :|

Hum, not sure to follow you here. What sort of finer granularity does
PCIe requires?

It's common for multiple buses to share a single I/O address space,
and just allocate port numbers for each BAR from a global 64KB
window, because x86 only has a single 64KB I/O space in hardware.

Maybe it works correctly if you set up all ten I/O windows to point
to the same addresses? I don't have the documentation, so it might
say that this is unsupported, but otherwise it may be worth trying.

quoted

By far the easiest thing is to keep them as separate PCI busses and
require DT to manage each one individually, address ranges and
all. :(

Does that mean that your earlier suggestion of emulating a PCI-to-PCI
bridge in software is no longer your preferred suggestion?

If the child buses of that virtual bridge can't use the same I/O
space window, that would require significant changes to the Linux
PCI implementation, which does not sound right.

One possibility would be to declare I/O space accesses invalid on this
driver, but that would break support for a number of (older) devices.

	Arnd