Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1158151 > unrolled thread

Re: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI core

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI  core Jiang Liu <jiang.liu@linux.intel.com> - 2015-06-04 04:00 +0200
    Re: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI  core Hanjun Guo <hanjun.guo@linaro.org> - 2015-06-04 08:40 +0200
      Re: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI  core Jiang Liu <jiang.liu@linux.intel.com> - 2015-06-04 08:50 +0200
        Re: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI  core Hanjun Guo <hanjun.guo@linaro.org> - 2015-06-04 09:10 +0200

#1158151 — Re: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI core

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
Thanks!
Gerry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1158287

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?

This is not the problem of this patch set, but need updating
the core ACPI resource parsing code, I'm working on that. I'm
just wondering there is no special IO space on IA64, how this works
on IA64?

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1158288

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.

> 
> This is not the problem of this patch set, but need updating
> the core ACPI resource parsing code, I'm working on that. I'm
> just wondering there is no special IO space on IA64, how this works
> on IA64?
There is special handling for IO port on IA64. IA64 io ports are
actually memory-mapped, and there may be multiple 64K IO port spaces.
For example, each PCI domain may have its own 64k memory-mapped
IO space.
Thanks!
Gerry
> 
> Thanks
> Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1158302

On 2015年06月04日 14:41, 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.

Thanks for the explanation, how about add a patch to comment on it?
if it's ok to you and will improve the code readability, I can prepare
one.

>
>>
>> This is not the problem of this patch set, but need updating
>> the core ACPI resource parsing code, I'm working on that. I'm
>> just wondering there is no special IO space on IA64, how this works
>> on IA64?
> There is special handling for IO port on IA64. IA64 io ports are
> actually memory-mapped, and there may be multiple 64K IO port spaces.
> For example, each PCI domain may have its own 64k memory-mapped
> IO space.

That's the case for ARM64 too, I will review the IA64 code for
reference, great thanks for the help and explanation :)

Thanks
Hanjun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web