From: bhelgaas@google.com (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/6] pci, thunder: Add PCIe host controller devicetree bindings
Date: Thu, 25 Sep 2014 14:49:29 -0600 [thread overview]
Message-ID: <CAErSpo6yXoETkXkimW2Lv724D4gn8ENi0U3wM=dFhQVkZJKXKg@mail.gmail.com> (raw)
In-Reply-To: <201409252222.23825.arnd@arndb.de>
On Thu, Sep 25, 2014 at 2:22 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 25 September 2014, Bjorn Helgaas wrote:
>> OK. You said "a range that has the nonrelocatable flag set should be
>> used for IORESOURCE_PCI_FIXED mappings." I thought you meant that the
>> range was a bridge window, and somehow PCI_FIXED BARs should be put in
>> that window.
>>
>> But maybe you meant that nonrelocatable ranges should have the
>> IORESOURCE_PCI_FIXED bit set in their struct resources. That would
>> mean we couldn't move the window, but we could put relocatable BARs
>> inside the window.
>>
>> What needs to be implemented? Just the code that would set
>> IORESOURCE_PCI_FIXED for nonrelocatable ranges?
>
> It might be more complex than I thought. Let's see what the original
> hack does:
>
> +/*
> + * All PCIe devices in Thunder have fixed resources, shouldn't be reassigned.
> + * Also claim the device's valid resources to set 'res->parent' hierarchy.
> + */
> +static void pci_dev_resource_fixup(struct pci_dev *dev)
> +{
> + struct resource *res;
> + int resno;
> +
> + for (resno = 0; resno < PCI_NUM_RESOURCES; resno++)
> + dev->resource[resno].flags |= IORESOURCE_PCI_FIXED;
> +
> + for (resno = 0; resno < PCI_BRIDGE_RESOURCES; resno++) {
> + res = &dev->resource[resno];
> + if (res->parent || !(res->flags & IORESOURCE_MEM))
> + continue;
> + pci_claim_resource(dev, resno);
> + }
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID,
> + pci_dev_resource_fixup);
>
> This actually looks harmful, because it means that any kernel that contains
> the thunder host controller driver will do the above for any device made
> by Cavium, whether it's connected to this bridge or not.
I agree, that looks broken.
> What I think we want instead is to mark any resource whose parent
> resource is IORESOURCE_PCI_FIXED to have the same flag, and mark
> the PCI host controller resources IORESOURCE_PCI_FIXED when the
> nonrelocatable flag is set, and that should all be done in core
> code, not in a driver fixup.
The PCI host controller resources are host bridge windows, right? I
don't think it matters whether they have IORESOURCE_PCI_FIXED set,
because the bridge is not itself a PCI device, and PCI resource
assignment treats the host bridge windows as fixed.
That doesn't imply that the PCI device resources *inside* the windows
need to be fixed, though. Regular BARs can be moved around inside the
window.
Sunil said "All on-board PCI devices connected to this PCI controller
have fixed resources..." That sounds like these on-board PCI devices
are non-compliant because their BARs don't work per spec. But that
doesn't sound right, because we wouldn't be able to size them.
> The part that still looks weird is the pci_claim_resource() that
> Sunil mentioned. This is currently done for resources that do not
> have a parent, but AFAICT all PCI device resources should have a
> parent that connects it to the upstream bridge.
Ideally the pci_claim_resource() would be in the core, not in arch
code, but it's a bit of a hodge-podge right now.
Bjorn
next prev parent reply other threads:[~2014-09-25 20:49 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-24 15:37 [PATCH 0/6] pci, thunder: Add Cavium Thunder PCIe host controller Robert Richter
2014-09-24 15:37 ` [PATCH 1/6] pci, thunder: Add support for " Robert Richter
2014-09-24 16:12 ` Arnd Bergmann
2014-09-24 16:49 ` Will Deacon
2014-09-30 9:14 ` Sunil Kovvuri
2014-09-24 15:37 ` [PATCH 2/6] GICv3: Add ITS entry to THUNDER dts Robert Richter
2015-06-25 23:19 ` Chalamarla, Tirumalesh
2015-06-26 9:00 ` Marc Zyngier
2014-09-24 15:37 ` [PATCH 3/6] pci, thunder: Add PCIe host controller devicetree bindings Robert Richter
2014-09-24 16:06 ` Arnd Bergmann
2014-09-24 18:04 ` Sunil Kovvuri
2014-09-24 18:34 ` Arnd Bergmann
2014-09-24 19:07 ` Sunil Kovvuri
2014-09-25 7:31 ` Arnd Bergmann
2014-09-25 16:16 ` Bjorn Helgaas
2014-09-25 19:26 ` Arnd Bergmann
2014-09-25 20:10 ` Bjorn Helgaas
2014-09-25 20:22 ` Arnd Bergmann
2014-09-25 20:49 ` Bjorn Helgaas [this message]
2014-09-26 18:26 ` Rob Herring
2014-09-30 9:11 ` Sunil Kovvuri
2014-10-07 14:27 ` Robert Richter
2014-10-07 15:01 ` Liviu Dudau
2014-10-08 8:49 ` Robert Richter
2014-10-08 16:44 ` Liviu Dudau
2014-10-09 6:23 ` Robert Richter
2014-09-24 15:37 ` [PATCH 4/6] pci, thunder: Document " Robert Richter
2014-09-24 15:37 ` [PATCH 5/6] arm64, defconfig: Enable PCI Robert Richter
2014-09-24 16:14 ` Arnd Bergmann
2014-09-24 16:26 ` Robert Richter
2014-09-24 17:10 ` Catalin Marinas
2014-09-24 18:40 ` Arnd Bergmann
2014-09-25 9:35 ` Catalin Marinas
2014-09-25 10:45 ` Arnd Bergmann
2014-09-24 15:37 ` [PATCH 6/6] pci, thunder: Enable Cavium Thunder PCIe host controller Robert Richter
2014-09-24 17:12 ` Catalin Marinas
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='CAErSpo6yXoETkXkimW2Lv724D4gn8ENi0U3wM=dFhQVkZJKXKg@mail.gmail.com' \
--to=bhelgaas@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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).