From: Tomasz Nowicki <tn@semihalf.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: arnd@arndb.de, will.deacon@arm.com, catalin.marinas@arm.com,
rafael@kernel.org, hanjun.guo@linaro.org,
Lorenzo.Pieralisi@arm.com, okaya@codeaurora.org,
jchandra@broadcom.com, robert.richter@caviumnetworks.com,
mw@semihalf.com, Liviu.Dudau@arm.com, ddaney@caviumnetworks.com,
wangyijing@huawei.com, Suravee.Suthikulpanit@amd.com,
msalter@redhat.com, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linaro-acpi@lists.linaro.org,
jcm@redhat.com, andrea.gallo@linaro.org, dhdang@apm.com,
jeremy.linton@arm.com, liudongdong3@huawei.com,
cov@codeaurora.org
Subject: Re: [PATCH V9 09/11] ARM64/PCI: ACPI support for legacy IRQs parsing and consolidation with DT code
Date: Mon, 13 Jun 2016 12:00:17 +0200 [thread overview]
Message-ID: <575E8431.9000104@semihalf.com> (raw)
In-Reply-To: <20160610233612.GB7671@localhost>
On 11.06.2016 01:36, Bjorn Helgaas wrote:
> On Fri, Jun 10, 2016 at 09:55:17PM +0200, Tomasz Nowicki wrote:
>> To enable PCI legacy IRQs on platforms booting with ACPI, arch code
>> should include ACPI specific callbacks that parse and set-up the
>> device IRQ number, equivalent to the DT boot path. Owing to the current
>> ACPI core scan handlers implementation, ACPI PCI legacy IRQs bindings
>> cannot be parsed at device add time, since that would trigger ACPI scan
>> handlers ordering issues depending on how the ACPI tables are defined.
>
> Uh, OK :) I can't figure out exactly what the problem is here -- I
> don't know where to look if I wanted to fix the scan handler ordering
> issues, and I don't know how I could tell if it would ever be safe to
> move this from driver probe-time back to device add-time.
>
> I also notice that x86 and ia64 call acpi_pci_irq_enable() even later,
> when the driver *enables* the device. Is there a reason you didn't do
> it at the same time as x86 and ia64? This is another of those pcibios
> hooks that really don't do anything arch-specific, so I can imagine
> refactoring this somehow, someday.
>
> Did we have this conversation before? It seems vaguely familiar, so I
> apologize if you already explained this once.
It stared with a scan handler ordering issue, please see:
https://lists.linaro.org/pipermail/linaro-acpi/2015-October/005944.html
hence we decided to postpone ACPI legacy IRQs parsing. We also decided
to keep ACPI and DT legacy IRQs parsing all together as the candidate
for further PCI legacy IRQs consolidation, please see [1].
This will allow us to remove it from here (as you pointed out is is not
arch-specific at all).
I share Lorenzo's option. We could put this to pcibios_enable_device
instead of pcibios_alloc_irq but since ACPI and DT code is in one call
we wanted to avoid regressions on PCI host controllers that do not call
pci_fixup_irqs(), but rely on the legacy IRQ routing to be done in arm64
pcibios_add_device().
[1] http://www.spinics.net/lists/linux-pci/msg45950.html
Thanks,
Tomasz
>
>> To solve this problem and consolidate FW PCI legacy IRQs parsing in
>> one single pcibios callback (pending final removal), this patch moves
>> DT PCI IRQ parsing to the pcibios_alloc_irq() callback (called by
>> PCI core code at device probe time) and adds ACPI PCI legacy IRQs
>> parsing to the same callback too, so that FW PCI legacy IRQs parsing
>> is confined in one single arch callback that can be easily removed
>> when code parsing PCI legacy IRQs is consolidated and moved to core
>> PCI code.
>>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> ---
>> arch/arm64/kernel/pci.c | 11 ++++++++---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>> index d5d3d26..b3b8a2c 100644
>> --- a/arch/arm64/kernel/pci.c
>> +++ b/arch/arm64/kernel/pci.c
>> @@ -51,11 +51,16 @@ int pcibios_enable_device(struct pci_dev *dev, int mask)
>> }
>>
>> /*
>> - * Try to assign the IRQ number from DT when adding a new device
>> + * Try to assign the IRQ number when probing a new device
>> */
>> -int pcibios_add_device(struct pci_dev *dev)
>> +int pcibios_alloc_irq(struct pci_dev *dev)
>> {
>> - dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
>> + if (acpi_disabled)
>> + dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
>> +#ifdef CONFIG_ACPI
>> + else
>> + return acpi_pci_irq_enable(dev);
>> +#endif
>>
>> return 0;
>> }
>> --
>> 1.9.1
>>
next prev parent reply other threads:[~2016-06-13 10:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-10 19:55 [PATCH V9 00/11] Support for ARM64 ACPI based PCI host controller Tomasz Nowicki
2016-06-10 19:55 ` [PATCH V9 01/11] PCI/ECAM: Move ecam.h to linux/include/pci-ecam.h Tomasz Nowicki
2016-06-10 19:55 ` [PATCH V9 02/11] PCI/ECAM: Add parent device field to pci_config_window Tomasz Nowicki
2016-06-10 19:55 ` [PATCH V9 03/11] PCI: Add new function to unmap IO resources Tomasz Nowicki
2016-06-10 19:55 ` [PATCH V9 04/11] ACPI/PCI: Support IO resources when parsing PCI host bridge resources Tomasz Nowicki
2016-06-10 19:55 ` [PATCH V9 05/11] ACPI/PCI: Add generic MCFG table handling Tomasz Nowicki
2016-06-10 23:25 ` Bjorn Helgaas
2016-06-10 19:55 ` [PATCH V9 06/11] PCI: Refactor generic bus domain assignment Tomasz Nowicki
2016-06-10 20:50 ` Lorenzo Pieralisi
2016-06-10 19:55 ` [PATCH V9 07/11] PCI: Factor DT specific pci_bus_find_domain_nr() code out Tomasz Nowicki
2016-06-10 20:51 ` Lorenzo Pieralisi
2016-06-10 19:55 ` [PATCH V9 08/11] ARM64/PCI: Add ACPI hook to assign domain number Tomasz Nowicki
2016-06-10 19:55 ` [PATCH V9 09/11] ARM64/PCI: ACPI support for legacy IRQs parsing and consolidation with DT code Tomasz Nowicki
2016-06-10 23:36 ` Bjorn Helgaas
2016-06-13 10:00 ` Tomasz Nowicki [this message]
2016-06-13 10:40 ` Lorenzo Pieralisi
2016-06-13 15:56 ` Liviu.Dudau
2016-06-13 20:01 ` Duc Dang
2016-06-14 9:30 ` Lorenzo Pieralisi
2016-06-10 19:55 ` [PATCH V9 10/11] ARM64/PCI: Implement ACPI low-level calls to access PCI_Config region from AML Tomasz Nowicki
2016-06-10 20:54 ` Lorenzo Pieralisi
2016-06-10 19:55 ` [PATCH V9 11/11] ARM64/PCI: Support for ACPI based PCI host controller Tomasz Nowicki
2016-11-22 23:13 ` Bjorn Helgaas
2016-11-23 11:21 ` Tomasz Nowicki
2016-11-23 18:22 ` Bjorn Helgaas
2016-11-24 11:10 ` Tomasz Nowicki
2016-06-10 23:41 ` [PATCH V9 00/11] Support for ARM64 " Bjorn Helgaas
2016-06-10 23:50 ` Jon Masters
2016-06-10 23:58 ` [Linaro-acpi] " Jon Masters
2016-06-11 9:51 ` Tomasz Nowicki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=575E8431.9000104@semihalf.com \
--to=tn@semihalf.com \
--cc=Liviu.Dudau@arm.com \
--cc=Lorenzo.Pieralisi@arm.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=andrea.gallo@linaro.org \
--cc=arnd@arndb.de \
--cc=catalin.marinas@arm.com \
--cc=cov@codeaurora.org \
--cc=ddaney@caviumnetworks.com \
--cc=dhdang@apm.com \
--cc=hanjun.guo@linaro.org \
--cc=helgaas@kernel.org \
--cc=jchandra@broadcom.com \
--cc=jcm@redhat.com \
--cc=jeremy.linton@arm.com \
--cc=linaro-acpi@lists.linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=liudongdong3@huawei.com \
--cc=msalter@redhat.com \
--cc=mw@semihalf.com \
--cc=okaya@codeaurora.org \
--cc=rafael@kernel.org \
--cc=robert.richter@caviumnetworks.com \
--cc=wangyijing@huawei.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox