[PATCH V1 11/11] arm64, pci, acpi: Support for ACPI based PCI hostbridge init

[okaya@codeaurora.org (Sinan Kaya)]

On 10/29/2015 11:53 AM, Tomasz Nowicki wrote:
> On 29.10.2015 16:01, Sinan Kaya wrote:
>>
>>
>> On 10/29/2015 7:38 AM, Tomasz Nowicki wrote:
>>> On 28.10.2015 21:36, Sinan Kaya wrote:
>>>> 1. ACPI code is unable to discover the interrupt numbers when objects
>>>> are ordered as follows in the ACPI file
>>>>
>>>> PNP0A08 object
>>>> PNP0C0F INTA object
>>>> PNP0C0F INTB object
>>>> PNP0C0F INTC object
>>>> PNP0C0F INTD object
>>>>
>>>> This gives me invalid link context error.
>>>>
>>>> pci 0000:00:00.0: PCI INT A: no GSI
>>>> pci 0000:01:00.0: Derived GSI for 0000:01:00.0 INT A from 0000:00:00.0
>>>> acpi PNP0C0F:00: Invalid link context
>>>>
>>>> If I order it like this in the ACPI file,
>>>>
>>>> PNP0C0F INTA object
>>>> PNP0C0F INTB object
>>>> PNP0C0F INTC object
>>>> PNP0C0F INTD object
>>>> PNP0A08 object
>>>>
>>>> then, the legacy interrupt numbers can be discovered properly.
>>>
>>> Can you show full content of your PNP0C0F and PNP0A08 objects?
>>>
>>
>> ACPI table is considered proprietary. I don't think I can get the legal
>> approval in time. I can give you pieces though.
>>
>> Here is the _PRT
>> Device (PCI0) { // PCIe port 0
>>      Name(_HID, EISAID("PNP0A08"))    // PCI express
>>      Name(_CID, EISAID("PNP0A03"))    // Compatible PCI Root Bridge
>> {
>>      ....
>>      Name(_PRT, Package(){
>>          Package(){0x0FFFF, 0, \_SB.LN0A, 0},  // Slot 0, INTA
>>          Package(){0x0FFFF, 1, \_SB.LN0B, 0},  // Slot 0, INTB
>>          Package(){0x0FFFF, 2, \_SB.LN0C, 0},  // Slot 0, INTC
>>          Package(){0x0FFFF, 3, \_SB.LN0D, 0}   // Slot 0, INTD
>>      })
>> }
>>
>> Here is the PNP0C0F
>>
>> Device(LN0A){
>>      Name(_HID, EISAID("PNP0C0F")) // PCI interrupt link
>>      Name(_UID, 1)
>>      Name(_PRS, ResourceTemplate(){
>>      Interrupt(ResourceProducer, Level, ActiveHigh, Exclusive, , ,)
>> {0xE8}
>>      })
>>      Method(_DIS) {}
>>      Method(_CRS) { Return (_PRS) }
>>      Method(_SRS, 1) {}
>> }
>>
>
> Can you please apply patch below:
>
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> index fec1c91..fe34415 100644
> --- a/arch/arm64/kernel/pci.c
> +++ b/arch/arm64/kernel/pci.c
> @@ -48,10 +48,19 @@ resource_size_t pcibios_align_resource(void *data,
> const struct resource *res,
>    */
>   int pcibios_enable_device(struct pci_dev *dev, int mask)
>   {
> +       int ret;
> +
>          if (pci_has_flag(PCI_PROBE_ONLY))
>                  return 0;
>
> -       return pci_enable_resources(dev, mask);
> +       ret = pci_enable_resources(dev, mask);
> +       if (ret < 0)
> +               return ret;
> +#ifdef CONFIG_ACPI
> +       if (!dev->msi_enabled)
> +               return acpi_pci_irq_enable(dev);
> +#endif
> +       return 0;
>   }
>
>   /*
> @@ -61,10 +70,6 @@ int pcibios_add_device(struct pci_dev *dev)
>   {
>          if (acpi_disabled)
>                  dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
> -#ifdef CONFIG_ACPI
> -       else
> -               acpi_pci_irq_enable(dev);
> -#endif
>
>          return 0;
>   }
>
> and let me know if the order still matter?
>
> Regards,
> Tomasz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks,
This seems to have fixed the ACPI table order problem.

-- 
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