On Monday 21 December 2015, Tomasz Nowicki wrote:

quoted

On 21.12.2015 13:10, Lorenzo Pieralisi wrote:

quoted

On Fri, Dec 18, 2015 at 06:56:39PM +0000, okaya at codeaurora.org wrote:

quoted

quoted

quoted

I have multiple root ports with the same IO port configuration in the
current ACPI table.

Root port 0 = IO range 0x1000-0x10FFF
Root port 1 = IO range 0x1000-0x10FFF
Root port 2 = IO range 0x1000-0x10FFF

It is fine. You end up mapping for each of those a 4k window of the
virtual address space allocated to IO and that's what you will have in
the kernel PCI resources (not in the HW BARs though). If that was a

problem

quoted

it would be even for the current DT host controllers eg:

arch/arm64/boot/dts/apm/apm-storm.dtsi

it should not be (again I will let Arnd comment on this since he may

be

quoted

aware of issues encountered on other arches/platforms).

Root port 0 = IO range 0x1000-0x10FFF
Root port 1 = IO range 0x1000-0x10FFF
Root port 2 = IO range 0x1000-0x10FFF

If above ranges are mapped into different CPU windows, then yes, it is
fine.

Ideally, they should all be the same CPU address so we only have to map
the window
once, each device gets an address below 64K, and you can have legacy port
numbers
(below 4K) on any bus, which is required to make certain GPUs work.

I haven't actually seen anyone do that on ARM though, every implementation
so
far has a separate mapping per host bridge, and we can cope with that too,
and we can live with either overlapping bus addresses or unique bus
addresses,
any of them can be expressed by the PCI core in Linux, we just have to
make sure
that we correctly translate the firmware tables into our internal
structures.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks, I won't be touching the acpi tables then and I will assume the
hack had a problem. It was trying to remap the io range of the second root
port  to the first port io address map.

I was getting a warning from resource.c

Btw, when I tested the io ranges before, kernel didn't accept anything
below 1k like 0. That is why my range starts at 1k.