[PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

[Sinan Kaya]

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.


-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project