On 1/11/2016 10:39 AM, Lorenzo Pieralisi wrote:
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.
And that's what you should not do. ACPI tables have to have a 1:1 correspondence with HW resources and you must not change them to make the kernel (which version by the way, given that ARM64 ACPI PCI support is not in the mainline) work. I already said that: we must not interpret ACPI tables, we must define them according to specifications, and that's what everyone should follow to write FW.
What confused me was the kernel view of IO addresses vs. PCI IO addresses. I looked at Mark Salter's patch and I realized that the kernel is maintaining global IO addresses with offsets to real PCI IO addresses.
I was expecting to see the PCI addresses to match kernel IO addresses. I wondered if somebody put some restriction into Linux or not which happened to me below.
_#_cat_/proc/ioports 00000000-0000efff : PCI Bus 0000:00 00001000-00001fff : PCI Bus 0000:01 0000f000-0001dfff : PCI Bus 0002:00 0000f000-0000ffff : PCI Bus 0002:01 0001e000-0002cfff : PCI Bus 0006:00 0001e000-0001efff : PCI Bus 0006:01 0001e000-0001e01f : 0006:01:00.0 0001e020-0001e03f : 0006:01:00.1 / #
#_dmesg_|_grep_resource [ 2.945762] pci_bus 0000:00: root bus resource [io 0x0000-0xefff window] (bus address [0x1000-0xffff]) [ 3.652201] pci_bus 0002:00: root bus resource [io 0xf000-0x1dfff window] (bus address [0x1000-0xffff]) [ 6.546716] pci_bus 0006:00: root bus resource [io 0x1e000-0x2cfff window] (bus address [0x1000-0xffff]) / #
Since we are talking about what ACPI dictates vs. what kernel does. Here is something that got me while testing.
Somebody sneaked in a 0x10003 upper limit on PCI addresses for some reason below. There is nothing magic about 0x10003 and I'm wonding why we have this limit.
static void acpi_dev_ioresource_flags(struct resource *res, u64 len, u8 io_decode, u8 translation_type) { res->flags = IORESOURCE_IO;
if (!acpi_dev_resource_len_valid(res->start, res->end, len, true)) res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;
if (res->end >= 0x10003) res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;
I did a debug session with Tomasz last week. He fixed the issue. The range for IO resources were not being registered properly. The second root port was causing a bug check in the kernel because the IO range was overlapping with the first root port. The issue is fixed now.
So, why does your PCI IO range starts at 1k ? Please define what you mean by "kernel didn't accept anything below 1k", I want to understand what you are referring to.
I created my own version of ACPI PCI root port patch by porting ia64 to ARMv7 two years ago and wrote the ACPI table on an ARMv7 platform. I have been reusing the same tables since then.
The issue was what Arnd described in his email to this thread. (PCIBIOS_MIN_IO) macro. I have tested the IO range starting from 0 on Tomasz's patches. I'm not seeing any problems.