Re: [PATCH 0/3] amd/pci: Add AMD hostbridge supports for newer AMD systems

[Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>]

On 3/5/2014 8:13 PM, Suravee Suthikulanit wrote:
> On 3/5/2014 3:24 PM, Bjorn Helgaas wrote:
>> [+cc linux-acpi]
>>
>> On Wed, Mar 5, 2014 at 2:06 PM,  <suravee.suthikulpanit@amd.com> wrote:
>>> From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
>>>
>>> The current code only supports upto AMD hostbridge for family11h.
>>> This causes PCI numa_node information to be reported incorrectly
>>> for newer family with multi sockets.
>>
>> Where is the incorrect reporting?  In ACPI tables?  Is this patch a
>> way to cover up firmware defects in the ACPI description?  Or is this
>> for machines without ACPI (it seems unlikely that machines with new
>> AMD processors would not have ACPI)?
>
> This is incorrectly reported in the sysfs for each PCI device (e.g.
> /devices/pci0000:50/0000:50:00.2/numa_node). Without the patch, they
> return -1.
>
> In file arch/x86/pci/acpi.c, in function pci_acpi_scan_root(), it is
> queries the node information as following:
>
> #ifdef CONFIG_ACPI_NUMA
>      pxm = acpi_get_pxm(device->handle);
>      if (pxm >= 0)
>          node = pxm_to_node(pxm);
>      if (node != -1)
>          set_mp_bus_to_node(busnum, node);
>      else
> #endif
>          node = get_mp_bus_to_node(busnum);
>
> In this case, I see that the acpi_get_pxm() returns -1.  Therefore, it
> falls back to using the node information in mp_bus_to_node[].  So,
> without this patch, it would also returning -1.
>
> Also, the spec mentioned that the _PXM is optional, so I am not sure if
> this is a firmware bug.
>
> Suravee

I am not quite familiar with the ACPI for this part.  However, after 
taking a look at the code (in driver/acpi/pci_root.c: 
acpi_pci_root_add()), I believe it's trying to locate _PXM method in the 
DSDT table, in which I don't see any _PXM methods.

I'm still trying to debug this issue, any suggestions would be appreciated.

Thank you,

Suravee