On 1/11/2016 10:39 AM, Lorenzo Pieralisi wrote:

quoted

Thanks, I won't be touching the acpi tables then and I will assume the

quoted

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