From: Bjorn Helgaas <helgaas@kernel.org>
To: David Daney <ddaney@caviumnetworks.com>
Cc: Rob Herring <robh@kernel.org>,
David Daney <ddaney.cavm@gmail.com>,
Bjorn Helgaas <bhelgaas@google.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
Will Deacon <will.deacon@arm.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
David Daney <david.daney@cavium.com>
Subject: Re: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices
Date: Mon, 8 Feb 2016 16:12:04 -0600 [thread overview]
Message-ID: <20160208221204.GA30821@localhost> (raw)
In-Reply-To: <56B90B09.7090500@caviumnetworks.com>
On Mon, Feb 08, 2016 at 01:39:21PM -0800, David Daney wrote:
> On 02/08/2016 01:12 PM, Rob Herring wrote:
> >On Mon, Feb 8, 2016 at 2:47 PM, David Daney <ddaney@caviumnetworks.com> wrote:
> >>On 02/08/2016 11:56 AM, Rob Herring wrote:
> >>>On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote:
> >>>>From: David Daney <david.daney@cavium.com>
> >
> >[...]
> >
> >>>>+Properties of the host controller node that differ from
> >>>>+host-generic-pci.txt:
> >>>>+
> >>>>+- compatible : Must be "cavium,pci-host-thunder-ecam"
> >>>>+
> >>>>+Example:
> >>>>+
> >>>>+ pci@84b0,00000000 {
> >>>
> >>>
> >>>Drop the comma,
> >>
> >>
> >>OK...
> >>
> >>>and the node name should be "pcie".
> >>>
> >>
> >>Why pcie?
> >>
> >>There are no PCIe devices or buses reachable from this type of root complex.
> >>There are however many PCI devices.
> >
> >I thought ECAM is a PCIe thing. If not, then nevermind.
The "ECAM" confusion bites again :)
> Well, Enhanced Configuration Access Mechanism (ECAM) is defined the
> the PCI Express(R) base Specification, but it just defines a
> standard layout of address bits to memory map config space
> operations. Since the PCI config space is a sub set of the PCIe
> config space, ECAM can also be used in PCI systems.
>
> Really, it is a bit of a gray area here as we don't have any bridges
> to PCIe buses and there are multiple devices residing on each bus,
> so from that point of view it cannot be PCIe. There are, however,
> devices that implement the PCI Express Capability structure, so does
> that make it PCIe? It is not clear what the specifications demand
> here.
The PCI core doesn't care about the node name in the device tree. But
it *does* care about some details of PCI/PCIe topology. We consider
anything with a PCIe capability to be PCIe. For example,
- pci_cfg_space_size() thinks PCIe devices have 4K of config space
- only_one_child() thinks a PCIe bus, i.e., a link, only has a
single device on it
- a PCIe device should have a PCIe Root Port or PCIe Downstream Port
upstream from it (we did remove some of these restrictions with
b35b1df5e6c2 ("PCI: Tolerate hierarchies with no Root Port"), but
it's possible we didn't get them all)
I assume your system conforms to expectations like these; I'm just
pointing them out because you mentioned buses with multiple devices on
them, which is definitely something one doesn't expect in PCIe.
Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: helgaas@kernel.org (Bjorn Helgaas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices
Date: Mon, 8 Feb 2016 16:12:04 -0600 [thread overview]
Message-ID: <20160208221204.GA30821@localhost> (raw)
In-Reply-To: <56B90B09.7090500@caviumnetworks.com>
On Mon, Feb 08, 2016 at 01:39:21PM -0800, David Daney wrote:
> On 02/08/2016 01:12 PM, Rob Herring wrote:
> >On Mon, Feb 8, 2016 at 2:47 PM, David Daney <ddaney@caviumnetworks.com> wrote:
> >>On 02/08/2016 11:56 AM, Rob Herring wrote:
> >>>On Fri, Feb 05, 2016 at 03:41:15PM -0800, David Daney wrote:
> >>>>From: David Daney <david.daney@cavium.com>
> >
> >[...]
> >
> >>>>+Properties of the host controller node that differ from
> >>>>+host-generic-pci.txt:
> >>>>+
> >>>>+- compatible : Must be "cavium,pci-host-thunder-ecam"
> >>>>+
> >>>>+Example:
> >>>>+
> >>>>+ pci at 84b0,00000000 {
> >>>
> >>>
> >>>Drop the comma,
> >>
> >>
> >>OK...
> >>
> >>>and the node name should be "pcie".
> >>>
> >>
> >>Why pcie?
> >>
> >>There are no PCIe devices or buses reachable from this type of root complex.
> >>There are however many PCI devices.
> >
> >I thought ECAM is a PCIe thing. If not, then nevermind.
The "ECAM" confusion bites again :)
> Well, Enhanced Configuration Access Mechanism (ECAM) is defined the
> the PCI Express(R) base Specification, but it just defines a
> standard layout of address bits to memory map config space
> operations. Since the PCI config space is a sub set of the PCIe
> config space, ECAM can also be used in PCI systems.
>
> Really, it is a bit of a gray area here as we don't have any bridges
> to PCIe buses and there are multiple devices residing on each bus,
> so from that point of view it cannot be PCIe. There are, however,
> devices that implement the PCI Express Capability structure, so does
> that make it PCIe? It is not clear what the specifications demand
> here.
The PCI core doesn't care about the node name in the device tree. But
it *does* care about some details of PCI/PCIe topology. We consider
anything with a PCIe capability to be PCIe. For example,
- pci_cfg_space_size() thinks PCIe devices have 4K of config space
- only_one_child() thinks a PCIe bus, i.e., a link, only has a
single device on it
- a PCIe device should have a PCIe Root Port or PCIe Downstream Port
upstream from it (we did remove some of these restrictions with
b35b1df5e6c2 ("PCI: Tolerate hierarchies with no Root Port"), but
it's possible we didn't get them all)
I assume your system conforms to expectations like these; I'm just
pointing them out because you mentioned buses with multiple devices on
them, which is definitely something one doesn't expect in PCIe.
Bjorn
next prev parent reply other threads:[~2016-02-08 22:12 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 23:41 [PATCH v5 0/3] Add host controller drivers for Cavium ThunderX PCI David Daney
2016-02-05 23:41 ` David Daney
2016-02-05 23:41 ` David Daney
2016-02-05 23:41 ` [PATCH v5 1/3] PCI: generic: Refactor code to enable reuse by other drivers David Daney
2016-02-05 23:41 ` David Daney
2016-02-05 23:41 ` [PATCH v5 2/3] pci, pci-thunder-pem: Add PCIe host driver for ThunderX processors David Daney
2016-02-05 23:41 ` David Daney
2016-02-06 16:01 ` Bjorn Helgaas
2016-02-06 16:01 ` Bjorn Helgaas
2016-02-06 16:01 ` Bjorn Helgaas
2016-02-05 23:41 ` [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices David Daney
2016-02-05 23:41 ` David Daney
2016-02-08 19:56 ` Rob Herring
2016-02-08 19:56 ` Rob Herring
2016-02-08 20:47 ` David Daney
2016-02-08 20:47 ` David Daney
2016-02-08 20:47 ` David Daney
2016-02-08 21:12 ` Rob Herring
2016-02-08 21:12 ` Rob Herring
2016-02-08 21:39 ` David Daney
2016-02-08 21:39 ` David Daney
2016-02-08 22:12 ` Bjorn Helgaas [this message]
2016-02-08 22:12 ` Bjorn Helgaas
2016-02-08 22:41 ` David Daney
2016-02-08 22:41 ` David Daney
2016-02-08 22:41 ` David Daney
2016-02-08 23:24 ` Bjorn Helgaas
2016-02-08 23:24 ` Bjorn Helgaas
2016-02-08 23:31 ` David Daney
2016-02-08 23:31 ` David Daney
2016-02-09 9:25 ` Arnd Bergmann
2016-02-09 9:25 ` Arnd Bergmann
2016-02-09 16:26 ` Bjorn Helgaas
2016-02-09 16:26 ` Bjorn Helgaas
2016-02-09 16:31 ` Arnd Bergmann
2016-02-09 16:31 ` Arnd Bergmann
2016-02-09 16:58 ` David Daney
2016-02-09 16:58 ` David Daney
2016-02-09 16:58 ` David Daney
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=20160208221204.GA30821@localhost \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=david.daney@cavium.com \
--cc=ddaney.cavm@gmail.com \
--cc=ddaney@caviumnetworks.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh@kernel.org \
--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 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.