[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5677F3C8.8040200@semihalf.com>
Date: Mon, 21 Dec 2015 13:42:48 +0100
From: Tomasz Nowicki <tn@...ihalf.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@....com>, okaya@...eaurora.org
Cc: 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 21.12.2015 13:10, Lorenzo Pieralisi wrote:
> 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).
>
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.
Tomasz
--
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