From: Thierry Reding <thierry.reding@avionic-design.de>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Russell King <linux@arm.linux.org.uk>,
linux-tegra@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org,
Grant Likely <grant.likely@secretlab.ca>,
Rob Herring <rob.herring@calxeda.com>,
devicetree-discuss@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
Colin Cross <ccross@android.com>, Olof Johansson <olof@lixom.net>,
Mitch Bradley <wmb@firmworks.com>, Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v3 00/10] ARM: tegra: Add PCIe device tree support
Date: Mon, 13 Aug 2012 22:33:00 +0200 [thread overview]
Message-ID: <20120813203300.GA8891@avionic-0098.mockup.avionic-design.de> (raw)
In-Reply-To: <50294BCA.1070807@wwwdotorg.org>
[-- Attachment #1.1: Type: text/plain, Size: 5896 bytes --]
On Mon, Aug 13, 2012 at 12:47:38PM -0600, Stephen Warren wrote:
> On 08/13/2012 11:40 AM, Thierry Reding wrote:
> > On Mon, Aug 06, 2012 at 01:42:21PM -0600, Stephen Warren wrote:
> >> On 07/26/2012 01:55 PM, Thierry Reding wrote:
> >>> This patch series adds support for device tree based probing of
> >>> the PCIe controller found on Tegra SoCs.
> >>
> >> Thierry, I just tested all Tegra boards in v3.6-rc1, and noticed
> >> that PCIe doesn't work on TrimSlice when booting use device tree.
> >> I think I found the cause, and I can't see why the same problem
> >> doesn't affect this series. Perhaps you can enlighten me?
> ...
> >> PCI: Device 0000:01:00.0 not available because of resource
> >> collisions
> ...
> > I've looked into this a bit, and it seems like ARM is using an
> > open- coded version of the pci_enable_resources() function here,
> > with the only difference being the unconditional enabling of both
> > I/O and memory- mapped access for bridges. On Tegra there is
> > already a PCI fixup to do this, so pci_enable_resources() can be
> > used as-is. I came up with the attached patch but haven't been able
> > to test it yet.
>
> Thanks very much for looking into this.
>
> The patch did alter the behavior a little for TrimSlice, but didn't
> solve the problem. The old error messages:
>
> > [ 2.173971] PCI: Device 0000:01:00.0 not available because of resource collisions
> > [ 2.181453] r8169 0000:01:00.0: (unregistered net_device): enable failure
> > [ 2.188254] r8169: probe of 0000:01:00.0 failed with error -22
>
> Were replaced with the following with your patch:
>
> > [ 2.174010] r8169 0000:01:00.0: device not available (can't reserve [io 0x0000-0x00ff])
> > [ 2.182098] r8169 0000:01:00.0: (unregistered net_device): enable failure
> > [ 2.188900] r8169: probe of 0000:01:00.0 failed with error -22
>
> This message appears from drivers/pci/setup-res.c pci_enable_resources()
> due to:
>
> > if (!r->parent) {
> > dev_err(&dev->dev, "device not available "
> > "(can't reserve %pR)\n", r);
> > return -EINVAL;
> > }
Looking at the code some more, this may be caused by the pci_remap_io()
patch series, so you might want to revert that patch and see if it fixes
the I/O resources.
> That check doesn't appear in ARM's custom pcibios_enable_device().
> Disabling that check yields:
>
> > [ 2.174192] r8169 0000:01:00.0: enabling device (0140 -> 0143)
> > [ 2.180041] r8169 0000:01:00.0: BAR 2: can't reserve [mem 0x00000000-0x00000fff 64bit pref]
> > [ 2.188386] r8169 0000:01:00.0: (unregistered net_device): could not request regions
> > [ 2.196140] r8169: probe of 0000:01:00.0 failed with error -16
>
> I think that's because the pci_dev's resources are initially assigned
> PCI-aperture-relative addresses, and then these are later patched up to
> take account of where the aperture is mapped into the CPU's address space.
>
> Boot log using board files:
>
> > [ 1.146145] pci 0000:01:00.0: reg 10: [io 0x0000-0x00ff]
> > [ 1.151745] pci 0000:01:00.0: reg 18: [mem 0x00000000-0x00000fff 64bit pref]
> > [ 1.159007] pci 0000:01:00.0: reg 20: [mem 0x00000000-0x00003fff 64bit pref]
> > [ 1.166270] pci 0000:01:00.0: reg 30: [mem 0x00000000-0x0001ffff pref]
> ...
> > [ 1.217829] pci 0000:01:00.0: BAR 6: assigned [mem 0xa0000000-0xa001ffff pref]
> > [ 1.225264] pci 0000:01:00.0: BAR 4: assigned [mem 0xa0020000-0xa0023fff 64bit pref]
> > [ 1.233236] pci 0000:01:00.0: BAR 2: assigned [mem 0xa0024000-0xa0024fff 64bit pref]
> > [ 1.241206] pci 0000:01:00.0: BAR 0: assigned [io 0x1000-0x10ff]
> ... (I added some extra printks:)
> > [ 1.488007] r8169 0000:01:00.0: BAR 0: requesting [io 0x1000-0x10ff]
> > [ 1.501483] r8169 0000:01:00.0: BAR 2: requesting [mem 0xa0024000-0xa0024fff 64bit pref]
> > [ 1.516611] r8169 0000:01:00.0: BAR 4: requesting [mem 0xa0020000-0xa0023fff 64bit pref]
>
> 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.
>
> Does anyone know where/what that "probe now" vs. "probe later" decision
> point is? I'll try and track it down if nobody beats me to it.
There's the io_offset and mem_offset fields that I've completely ignored
up to now. Can you try the patch below to see if it changes anything?
I'm sorry but I can't test any of this myself right now.
Thierry
[-- Attachment #1.2: pcie.patch --]
[-- Type: text/plain, Size: 1030 bytes --]
diff --git a/arch/arm/mach-tegra/pcie.c b/arch/arm/mach-tegra/pcie.c
index 3463fb5..9b9b3e0 100644
--- a/arch/arm/mach-tegra/pcie.c
+++ b/arch/arm/mach-tegra/pcie.c
@@ -395,7 +395,7 @@ static int tegra_pcie_setup(int nr, struct pci_sys_data *sys)
pp->res[0].flags = IORESOURCE_MEM;
if (request_resource(&iomem_resource, &pp->res[0]))
panic("Request PCIe Memory resource failed\n");
- pci_add_resource_offset(&sys->resources, &pp->res[0], sys->mem_offset);
+ pci_add_resource_offset(&sys->resources, &pp->res[0], pp->res[0].start);
/*
* IORESOURCE_MEM | IORESOURCE_PREFETCH
@@ -414,7 +414,7 @@ static int tegra_pcie_setup(int nr, struct pci_sys_data *sys)
pp->res[1].flags = IORESOURCE_MEM | IORESOURCE_PREFETCH;
if (request_resource(&iomem_resource, &pp->res[1]))
panic("Request PCIe Prefetch Memory resource failed\n");
- pci_add_resource_offset(&sys->resources, &pp->res[1], sys->mem_offset);
+ pci_add_resource_offset(&sys->resources, &pp->res[1], pp->res[1].start);
return 1;
}
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-08-13 20:33 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 [this message]
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
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=20120813203300.GA8891@avionic-0098.mockup.avionic-design.de \
--to=thierry.reding@avionic-design.de \
--cc=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=ccross@android.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=olof@lixom.net \
--cc=rob.herring@calxeda.com \
--cc=swarren@wwwdotorg.org \
--cc=wmb@firmworks.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;
as well as URLs for NNTP newsgroup(s).