From: Chen Yuanquan-B41889 <B41889@freescale.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Yuanquan Chen <Yuanquan.Chen@freescale.com>,
<linuxppc-dev@lists.ozlabs.org>, <linux-pci@vger.kernel.org>,
<bhelgaas@google.com>,
Hiroo Matsumoto <matsumoto.hiroo@jp.fujitsu.com>
Subject: Re: [PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform
Date: Tue, 23 Apr 2013 17:26:48 +0800 [thread overview]
Message-ID: <517653D8.8000205@freescale.com> (raw)
In-Reply-To: <51652C20.2060105@freescale.com>
On 04/10/2013 05:08 PM, Chen Yuanquan-B41889 wrote:
> On 04/03/2013 12:08 PM, Chen Yuanquan-B41889 wrote:
>> On 04/02/2013 11:10 PM, Benjamin Herrenschmidt wrote:
>>> On Tue, 2013-04-02 at 19:26 +0800, Yuanquan Chen wrote:
>>>> So we move the DMA & IRQ initialization code from
>>>> pcibios_setup_devices() and
>>>> construct a new function pcibios_enable_device. We call this
>>>> function in
>>>> pcibios_enable_device, which will be called by PCI-e rescan code.
>>>> At the
>>>> meanwhile, we avoid the the impact on cardbus. I also validate this
>>>> patch with
>>>> silicon's PCIe-sata which encounters the IRQ issue.
>>> My worry is that this delays the setup of the IRQ and DMA to very
>>> late in
>>> the process, possibly after the quirks have been run, which can be
>>> problematic. We have platform hooks that might try to "fixup" specific
>>> IRQ issues on some platforms (especially macs) which I worry might fail
>>> if delayed that way (I may be wrong, I don't have a specific case in
>>> mind,
>>> but I would feel better if we kept setting up these things earlier).
>>>
>>> Cheers,
>>> Ben.
>>>
>>
>> Hi Ben,
>>
>> I have checked all the quirk functions which are declared in kernel
>> arch/powerpc
>> with command :
>> grep DECLARE_PCI_FIXUP_ `find arch/powerpc/ *.[hc]`
>>
>> All the quirk function are defined as DECLARE_PCI_FIXUP_EARLY ,
>> DECLARE_PCI_FIXUP_HEADER
>> and DECLARE_PCI_FIXUP_FINAL, except quirk_uli5229() in
>> arch/powerpc/platforms/fsl_uli1575.c, which is
>> defined both as DECLARE_PCI_FIXUP_HEADER and
>> DECLARE_PCI_FIXUP_RESUME. So the quirk_uli5229()
>> will also be called with PCI pm module. The quirk functions defined
>> as xxx_FINAL, HEADER and EARLY,
>> will be called in the path:
>>
>> pci_scan_child_bus()->pci_scan_slot()->pci_scan_single_device()->pci_scan_device()->pci_setup_device()
>>
>> ->pci_device_add()
>>
>> the pci_scan_slot() is called earlier than pcibios_fixup_bus() even
>> for the first scan of PCI-e bus, so the quirk
>> functions on powerpc platform is called before the DMA & IRQ fixup.
>> So in reality, the delay of DMA & IRQ fixup
>> won't affect anything.
>>
>> Regards,
>> Yuanquan
>>
>
> Hi Ben,
>
> How do you think about this? Do you have any comment?
>
> Thanks,
> Yuanquan
>
Hi Bjorn,
There's no response from Ben. How do you think about this patch? What's
your advice?
Thanks,
Yuanquan
>>>
>>>
>>>
>>
>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Chen Yuanquan-B41889 <B41889@freescale.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Yuanquan Chen <Yuanquan.Chen@freescale.com>,
Hiroo Matsumoto <matsumoto.hiroo@jp.fujitsu.com>,
linux-pci@vger.kernel.org, bhelgaas@google.com,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform
Date: Tue, 23 Apr 2013 17:26:48 +0800 [thread overview]
Message-ID: <517653D8.8000205@freescale.com> (raw)
In-Reply-To: <51652C20.2060105@freescale.com>
On 04/10/2013 05:08 PM, Chen Yuanquan-B41889 wrote:
> On 04/03/2013 12:08 PM, Chen Yuanquan-B41889 wrote:
>> On 04/02/2013 11:10 PM, Benjamin Herrenschmidt wrote:
>>> On Tue, 2013-04-02 at 19:26 +0800, Yuanquan Chen wrote:
>>>> So we move the DMA & IRQ initialization code from
>>>> pcibios_setup_devices() and
>>>> construct a new function pcibios_enable_device. We call this
>>>> function in
>>>> pcibios_enable_device, which will be called by PCI-e rescan code.
>>>> At the
>>>> meanwhile, we avoid the the impact on cardbus. I also validate this
>>>> patch with
>>>> silicon's PCIe-sata which encounters the IRQ issue.
>>> My worry is that this delays the setup of the IRQ and DMA to very
>>> late in
>>> the process, possibly after the quirks have been run, which can be
>>> problematic. We have platform hooks that might try to "fixup" specific
>>> IRQ issues on some platforms (especially macs) which I worry might fail
>>> if delayed that way (I may be wrong, I don't have a specific case in
>>> mind,
>>> but I would feel better if we kept setting up these things earlier).
>>>
>>> Cheers,
>>> Ben.
>>>
>>
>> Hi Ben,
>>
>> I have checked all the quirk functions which are declared in kernel
>> arch/powerpc
>> with command :
>> grep DECLARE_PCI_FIXUP_ `find arch/powerpc/ *.[hc]`
>>
>> All the quirk function are defined as DECLARE_PCI_FIXUP_EARLY ,
>> DECLARE_PCI_FIXUP_HEADER
>> and DECLARE_PCI_FIXUP_FINAL, except quirk_uli5229() in
>> arch/powerpc/platforms/fsl_uli1575.c, which is
>> defined both as DECLARE_PCI_FIXUP_HEADER and
>> DECLARE_PCI_FIXUP_RESUME. So the quirk_uli5229()
>> will also be called with PCI pm module. The quirk functions defined
>> as xxx_FINAL, HEADER and EARLY,
>> will be called in the path:
>>
>> pci_scan_child_bus()->pci_scan_slot()->pci_scan_single_device()->pci_scan_device()->pci_setup_device()
>>
>> ->pci_device_add()
>>
>> the pci_scan_slot() is called earlier than pcibios_fixup_bus() even
>> for the first scan of PCI-e bus, so the quirk
>> functions on powerpc platform is called before the DMA & IRQ fixup.
>> So in reality, the delay of DMA & IRQ fixup
>> won't affect anything.
>>
>> Regards,
>> Yuanquan
>>
>
> Hi Ben,
>
> How do you think about this? Do you have any comment?
>
> Thanks,
> Yuanquan
>
Hi Bjorn,
There's no response from Ben. How do you think about this patch? What's
your advice?
Thanks,
Yuanquan
>>>
>>>
>>>
>>
>
>
>
next prev parent reply other threads:[~2013-04-23 9:27 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-02 11:26 [PATCH] powerpc/pci: fix PCI-e devices rescan issue on powerpc platform Yuanquan Chen
2013-04-02 11:26 ` Yuanquan Chen
2013-04-02 15:10 ` Benjamin Herrenschmidt
2013-04-02 15:10 ` Benjamin Herrenschmidt
2013-04-03 4:08 ` Chen Yuanquan-B41889
2013-04-03 4:08 ` Chen Yuanquan-B41889
2013-04-10 9:08 ` Chen Yuanquan-B41889
2013-04-10 9:08 ` Chen Yuanquan-B41889
2013-04-23 9:26 ` Chen Yuanquan-B41889 [this message]
2013-04-23 9:26 ` Chen Yuanquan-B41889
2013-04-23 10:05 ` Benjamin Herrenschmidt
2013-04-23 10:05 ` Benjamin Herrenschmidt
2013-04-23 10:51 ` Chen Yuanquan-B41889
2013-04-23 10:51 ` Chen Yuanquan-B41889
2013-04-23 11:30 ` Michael Ellerman
2013-04-23 11:30 ` Michael Ellerman
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=517653D8.8000205@freescale.com \
--to=b41889@freescale.com \
--cc=Yuanquan.Chen@freescale.com \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=matsumoto.hiroo@jp.fujitsu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.