[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151221121050.GB11145@red-moon>
Date: Mon, 21 Dec 2015 12:10:50 +0000
From: Lorenzo Pieralisi <lorenzo.pieralisi@....com>
To: okaya@...eaurora.org
Cc: Tomasz Nowicki <tn@...ihalf.com>, bhelgaas@...gle.com,
arnd@...db.de, will.deacon@....com, catalin.marinas@....com,
rjw@...ysocki.net, hanjun.guo@...aro.org,
jiang.liu@...ux.intel.com, stefano.stabellini@...citrix.com,
robert.richter@...iumnetworks.com, mw@...ihalf.com,
liviu.dudau@....com, ddaney@...iumnetworks.com, tglx@...utronix.de,
wangyijing@...wei.com, suravee.suthikulpanit@....com,
msalter@...hat.com, linux-pci@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org, linaro-acpi@...ts.linaro.org,
jchandra@...adcom.com, jcm@...hat.com
Subject: Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI
hostbridge init based on ACPI
On Fri, Dec 18, 2015 at 06:56:39PM +0000, okaya@...eaurora.org wrote:
[...]
> Here is what I have as an IO resource.
>
> QWORDIO( //Consumed-And-produced resource
> ResourceProducer, // bit 0 of general flags is 0
> MinFixed, // Range is fixed
> MaxFixed, // Range is fixed
> PosDecode,
> EntireRange,
> 0x0000, // Granularity
> 0x1000, // Min, 0 is not accepted
> 0x10FFF, // Max
> 0x8FFFFFEF000, // Translation
> 0x10000, // Range Length
> ,, PI00
> )
>
> I don't have any type specified.
>
> I agree with Lorenzo's assessment. The min and max values represent the
> PCI IO bus addresses. The translation offset is added to these values to
> figure out the CPU view of the PCI IO range.
>
> The endpoints BAR addresses are programmed with IO addresses ranging
> between 0x1000 and 0x10FFF for this example above.
>
> Here is another question. Chris Covington and I asked this question on a
> private email to you but we didn't hear back.
>
> We were referring to a Linaro IO hack patch as we were not sure whether
> this was a limitation of the hack or a general expectation for ARM64 PCI
> in general.
>
> I'll repeat it here.
>
> 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).
Lorenzo
>
> Each root port can have the same IO address range configuration, are we
> expecting IO port numbers to be unique across the whole system for ARM64?
>
> Something like
>
> Root port 0 = IO range 0x1000-0x10FFF
> Root port 1 = IO range 0x11000-0x20FFF
> Root port 2 = IO range 0x21000-0x30FFF
>
> since the IO addresses are being remapped into PCI IO range printed during
> boot.
>
> PCI I/O : 0xffff7ffffae00000 - 0xffff7ffffbe00000 ( 16 MB)
>
> and each root port would remap to 64k of the 16MB range.
>
> >
> > Any comments are very appreciated!
> >
> > Tomasz
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > the body of a message to majordomo@...r.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists