From: swarren@wwwdotorg•org (Stephen Warren)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v3 00/10] ARM: tegra: Add PCIe device tree support
Date: Tue, 14 Aug 2012 16:58:55 -0600 [thread overview]
Message-ID: <502AD82F.3080702@wwwdotorg.org> (raw)
In-Reply-To: <CAErSpo4Bm_Ryx=OK+svjqAwD4N8v0vrheLVdc-N1ijx8i_-N3w@mail.gmail.com>
On 08/14/2012 03:55 PM, Bjorn Helgaas wrote:
> On Tue, Aug 14, 2012 at 12:58 PM, Thierry Reding
> <thierry.reding@avionic-design•de> wrote:
>> On Tue, Aug 14, 2012 at 01:39:23PM -0600, Stephen Warren wrote:
>>> On 08/13/2012 05:18 PM, Bjorn Helgaas wrote:
>>>> On Mon, Aug 13, 2012 at 11:47 AM, Stephen Warren <swarren@wwwdotorg•org> wrote:
>>> ...
>>>>> whereas for a device tree boot:
>>>>>
>>>>> (same):
>>>>>> [ 2.112217] pci 0000:01:00.0: reg 10: [io 0x0000-0x00ff]
>>>>>> [ 2.117635] pci 0000:01:00.0: reg 18: [mem 0x00000000-0x00000fff 64bit pref]
>>>>>> [ 2.124690] pci 0000:01:00.0: reg 20: [mem 0x00000000-0x00003fff 64bit pref]
>>>>>> [ 2.131731] pci 0000:01:00.0: reg 30: [mem 0x00000000-0x0001ffff pref]
>>>>> ... (request region happens early)
>>>>>> [ 2.179838] r8169 0000:01:00.0: BAR 0: requesting [io 0x0000-0x00ff]
>>>>>> [ 2.193312] r8169 0000:01:00.0: BAR 2: requesting [mem 0x00000000-0x00000fff 64bit pref]
>>>>>> [ 2.201397] r8169 0000:01:00.0: BAR 2: can't reserve [mem 0x00000000-0x00000fff 64bit pref]
>>>>>> [ 2.209742] r8169 0000:01:00.0: (unregistered net_device): could not request regions
>>>>> ... (same, just happens too late)
>>>>>> [ 2.236818] pci 0000:01:00.0: BAR 6: assigned [mem 0xa0000000-0xa001ffff pref]
>>>>>> [ 2.244027] pci 0000:01:00.0: BAR 4: assigned [mem 0xa0020000-0xa0023fff 64bit pref]
>>>>>> [ 2.251794] pci 0000:01:00.0: BAR 2: assigned [mem 0xa0024000-0xa0024fff 64bit pref]
>>>>>> [ 2.259542] pci 0000:01:00.0: BAR 0: assigned [io 0x1000-0x10ff]
>>>>>
>>>>> I suspect this is all still related to the PCI devices themselves being
>>>>> probed much earlier in the overall PCI initialization sequence when the
>>>>> PCI controller is probed later in the boot sequence, whereas PCI device
>>>>> probe is deferred until the overall PCI initialization sequence is
>>>>> complete if the PCI controller is probed very early in the boot sequence.
>>>>
>>>> I don't know what to apply your patches to (they don't apply cleanly
>>>> to v3.6-rc2), so I can't see exactly what you're doing. But it looks
>>>> like you might be calling pci_bus_add_devices() before
>>>> pci_bus_assign_resource(), which isn't going to work.
>>>
>>> Yes, that's exactly what is happening.
>>>
>>> PCIe initialization starts in arch/arm/mach-tegra/pci.e
>>> tegra_pcie_init() which calls arch/arm/kernel/bios32.c
>>> pci_common_init(). That function first calls pcibios_init_hw() (in the
>>> same file, more about this later) and then loops over PCI buses, calling
>>> amongst other things pci_bus_assign_resources() then pci_bus_add_devices().
>>>
>>> The problem is that ARM's pcibios_init_hw() calls pci_scan_root_bus()
>>> (or a host-driver-specific function which that also calls
>>> pci_scan_root_bus() in Tegra's case) which in turn calls
>>> pci_bus_add_devices() right at the end, before control has returned to
>>> pci_common_init() and hence before pci_bus_assign_resources() has been
>>> called.
>>>
>>> If I modify pci_scan_root_bus() and remove the call to
>>> pci_bus_add_devices(), everything works as expected.
>>>
>>> So, I guess the question is: Should ARM's pcibios_init_hw() not be
>>> calling pci_scan_root_bus(), or at least presumably the ARM PCI code
>>> needs to do things in a slightly different order?
>
> I think you need to do something like this instead of using pci_scan_root_bus():
>
> pci_create_root_bus()
> pci_scan_child_bus()
> pci_bus_assign_resources()
> pci_bus_add_devices()
>
> This is the effective order used by most of the pci_create_root_bus() callers.
That would pretty much duplicate everything in pci_scan_root_bus(). That
might cause divergence down the road.
Can't we make the call to pci_bus_add_devices() optional in
pci_scan_root_bus() somehow; one of:
* Add a parameter to pci_scan_root_bus() controlling this.
(rather a large patch)
* Split pci_scan_root_bus() into pci_scan_root_bus() and
pci_scan_root_bus_no_add(), such that pci_scan_root_bus() is just a
wrapper that calls pci_scan_root_bus_no_add() then pci_bus_add_devices().
(very simple patch, and the new function can easily be used as/when it's
needed, e.g. enabled just for Tegra in 3.6 to reduce risk of regressions)
* Add a flag to struct pci_bus that requests pci_scan_root_bus() skip
the call to pci_bus_add_devices().
(a flag in the bus struct just for one function seems a little
circuitous, but perhaps OK)
* ifdef out the call to pci_bus_add_devices(), if building for ARM.
(very simple, and probably correct)
Actually, I'm not totally convinced some other archs shouldn't skip this
too; while I couldn't find any other arch that explicitly calls
pci_bus_assign_resources() and pci_bus_add_devices() after
pci_scan_root_bus(), I did see some that call
pci_assign_unassigned_resources() which seems like it might be due to a
similar situation?
* Add another pcibios_*() callback that pci_scan_root_bus() calls to
determine whether to call pci_bus_add_devices(), with default
implementation.
next prev parent reply other threads:[~2012-08-14 22:58 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-26 19:55 [PATCH v3 00/10] ARM: tegra: Add PCIe device tree support Thierry Reding
2012-07-26 19:55 ` [PATCH v3 01/10] PCI: Keep pci_fixup_irqs() around after init Thierry Reding
2012-08-14 5:06 ` Bjorn Helgaas
2012-08-14 5:37 ` Thierry Reding
2012-08-15 17:06 ` Bjorn Helgaas
2012-08-15 19:28 ` Thierry Reding
2012-08-15 19:42 ` Bjorn Helgaas
2012-08-15 20:01 ` Thierry Reding
2012-09-07 16:19 ` Stephen Warren
2012-09-07 17:00 ` Thierry Reding
2012-09-07 17:22 ` Bjorn Helgaas
2012-09-14 18:55 ` Thierry Reding
2012-09-14 19:45 ` Bjorn Helgaas
2012-07-26 19:55 ` [PATCH v3 02/10] ARM: pci: Keep pci_common_init() " Thierry Reding
2012-07-26 19:55 ` [PATCH v3 03/10] ARM: pci: Allow passing per-controller private data Thierry Reding
2012-07-26 19:55 ` [PATCH v3 04/10] ARM: tegra: Move tegra_pcie_xclk_clamp() to PMC Thierry Reding
2012-07-26 19:55 ` [PATCH v3 05/10] resource: add PCI configuration space support Thierry Reding
2012-08-14 5:00 ` Bjorn Helgaas
2012-08-14 5:55 ` Thierry Reding
2012-08-14 17:38 ` Bjorn Helgaas
2012-08-14 18:01 ` Thierry Reding
2012-08-14 21:44 ` Bjorn Helgaas
2012-08-15 6:49 ` Thierry Reding
2012-08-16 15:18 ` Stephen Warren
2012-08-16 18:27 ` Thierry Reding
2012-07-26 19:55 ` [PATCH v3 06/10] ARM: tegra: Rewrite PCIe support as a driver Thierry Reding
2012-07-26 19:55 ` [PATCH v3 07/10] ARM: tegra: pcie: Add MSI support Thierry Reding
2012-07-26 19:55 ` [PATCH v3 08/10] of/address: Handle #address-cells > 2 specially Thierry Reding
2012-07-31 20:18 ` Rob Herring
2012-08-15 20:06 ` Thierry Reding
2012-09-07 16:24 ` Stephen Warren
2012-09-07 16:32 ` Rob Herring
2012-07-26 19:55 ` [PATCH v3 09/10] of: Add of_pci_parse_ranges() Thierry Reding
2012-07-31 20:07 ` Rob Herring
2012-08-01 6:54 ` Thierry Reding
2012-08-01 16:07 ` Stephen Warren
2012-07-26 19:55 ` [PATCH v3 10/10] ARM: tegra: pcie: Add device tree support Thierry Reding
2012-08-14 20:12 ` Thierry Reding
2012-08-14 23:50 ` Bjorn Helgaas
2012-08-15 6:37 ` Thierry Reding
2012-08-15 12:18 ` Bjorn Helgaas
2012-08-15 12:30 ` Thierry Reding
2012-08-15 14:36 ` Bjorn Helgaas
2012-08-15 14:57 ` Thierry Reding
2012-08-15 20:25 ` Arnd Bergmann
2012-08-15 20:48 ` Bjorn Helgaas
2012-08-16 4:55 ` Thierry Reding
2012-08-16 7:03 ` Arnd Bergmann
2012-08-16 7:47 ` Thierry Reding
2012-08-16 12:15 ` Thierry Reding
2012-07-31 16:18 ` [PATCH v3 00/10] ARM: tegra: Add PCIe " Stephen Warren
2012-08-01 6:35 ` Thierry Reding
2012-08-01 17:02 ` Stephen Warren
2012-08-02 6:15 ` Thierry Reding
2012-08-06 19:42 ` Stephen Warren
2012-08-07 18:20 ` Thierry Reding
2012-08-13 17:40 ` Thierry Reding
2012-08-13 18:47 ` Stephen Warren
2012-08-13 20:33 ` Thierry Reding
2012-08-13 21:38 ` Rob Herring
2012-08-14 6:14 ` Thierry Reding
2012-08-13 23:18 ` Bjorn Helgaas
2012-08-14 6:29 ` Thierry Reding
2012-08-14 19:39 ` Stephen Warren
2012-08-14 19:58 ` Thierry Reding
2012-08-14 21:55 ` Bjorn Helgaas
2012-08-14 22:58 ` Stephen Warren [this message]
2012-08-14 23:51 ` Stephen Warren
2012-08-15 19:04 ` Stephen Warren
2012-08-15 20:09 ` Thierry Reding
2012-08-15 20:11 ` Stephen Warren
2012-08-15 20:19 ` Thierry Reding
2012-09-07 23:34 ` Stephen Warren
2012-09-08 0:04 ` Russell King - ARM Linux
2012-09-08 5:53 ` Stephen Warren
2012-09-08 17:51 ` Bjorn Helgaas
2012-09-18 6:33 ` Thierry Reding
2012-09-18 15:56 ` Bjorn Helgaas
2012-08-15 0:08 ` Bjorn Helgaas
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=502AD82F.3080702@wwwdotorg.org \
--to=swarren@wwwdotorg$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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