On 2015年06月05日 00:29, Jiang Liu wrote:
On 2015/6/4 23:51, Mark Salter wrote:
On Thu, 2015-06-04 at 14:41 +0800, Jiang Liu wrote:
On 2015/6/4 14:31, Hanjun Guo wrote:
Hi Jiang,
On 2015年06月04日 09:54, Jiang Liu wrote:
On 2015/6/4 4:27, Al Stone wrote:
On 06/02/2015 12:12 AM, Jiang Liu wrote:
This patch set consolidates common code to support ACPI PCI root on x86
and IA64 platforms into ACPI core, to reproduce duplicated code and
simplify maintenance. And a patch set based on this to support ACPI
based
PCIe host bridge on ARM64 has been posted at:
Link is missing (or it's a typo of some flavor).
HI Al,
Sorry, I missed the link. It has been posted at:
https://lkml.org/lkml/2015/5/26/207
I failed to get io resources for PCI hostbridge when I was testing PCI
on ARM64 QEMU, I debugged this for quite a while, and finally found out
that ACPI resource parsing for IO is not suitable for ARM64, because io
space for x86 is 64K, but 16M for ARM64.
This issue is only found when the firmware representing the io resource
using the type ACPI_RESOURCE_TYPE_ADDRESS32, so the io address will
greater than 64k.
In drivers/acpi/resource.c:
static void acpi_dev_ioresource_flags(struct resource *res, u64 len,
u8 io_decode, u8 translation_type)
{
res->flags = IORESOURCE_IO;
[...]
if (res->end >= 0x10003)
res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;
[...]
}
so the code will filter out res->end >= 0x10003, and in my case, it will
more than 64K, so we can't get the IO resources.
I got a question, why we use if (res->end >= 0x10003) here?
I mean 64k will be 0x10000, and in that case, we should use
if (res->end >= 0x10000) here, not 0x10003, any history behind that?
Hi Hanjun,
This is a special tricky for x86. You may read a dword(four bytes) from
IO port 0xffff, so the effective io port space is 0x10003 bytes.
Is there something in ACPI spec which would limit PCI IO space to 64K?
PCI itself allows 32-bit IO addresses and at least some arm64 platforms
use PCI bus addresses above 64K for IO transactions. From a PCI view,
the (res->end >= 0x10003) check doesn't make sense. Am I missing
something?
HI Mark,
Something interesting here. According to my understanding,
the actually limitations are
1) the maximum size for each IO port space is 64k,
2) each PCI segment may only have one IO port space assigned at most.
Other than those, it's flexible for system designer to:
1) have multiple IO port spaces, each is 64K at most.
2) CPU may use MMIO transactions to access PCI IO space, and PCI host
bridge will do the translation from CPU side MMIO address to PCI side
IO port address.
For example, we may have following configuration on IA64 platforms:
1) CPU side physical address [0x100000000-0x100010000] maps to IO space
[0x00000-0x10000] on PCI segment 0
2) CPU side physical address [0x100010000-0x100020000] maps to IO space
[0x00000-0x10000] on PCI segment 1
And ACPI resource descriptor provides 'translation_offset' to support
such an usage case. Hope this helps:)
Hi Jiang,
It seems the translation_offset for IA64 is assuming to zero in this
patch set, which have regressions if we use DworldIO() with offset
to report io port resources, am I missing something?
Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
