[PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Lorenzo Pieralisi
lorenzo.pieralisi at arm.com
Mon Jan 11 08:09:46 PST 2016
Hi Arnd,
On Mon, Dec 21, 2015 at 03:15:54PM +0100, Arnd Bergmann wrote:
> On Monday 21 December 2015, Tomasz Nowicki wrote:
> > On 21.12.2015 13:10, Lorenzo Pieralisi wrote:
> > > On Fri, Dec 18, 2015 at 06:56:39PM +0000, okaya at codeaurora.org wrote:
>
> > >> 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
> > > 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
> > > 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.
Can I ask you to elaborate on the above please ? Do you mean a single
CPU physical address range mapping the whole PCI IO address space ?
I did not quite get what you mean by "you can have legacy port numbers
on any bus", I think it would be good to clarify so that we are all
on the same page.
Thanks a lot !
Lorenzo
More information about the linux-arm-kernel
mailing list