lkml.org 
[lkml]   [2016]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 3/3] pci, pci-thunder-ecam: Add driver for ThunderX-pass1 on-chip devices
On 02/08/2016 02:12 PM, Bjorn Helgaas wrote:
> 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.
>

The topology we have is currently working with the kernel's core PCI
code. I don't really want to get into discussing what the definition of
PCIe is. We have multiple devices (more than 32) on a single bus, and
they have PCI Express and ARI Capabilities. Is that PCIe? I don't know.

For the purpose of naming the device tree node, I would like to stick
with the name "pci@..." as it is somewhat accurate, a value contemplated
by the device tree specifications, ignored by the kernel code, and
already implemented.

David Daney


> Bjorn
>

\
 
 \ /
  Last update: 2016-02-09 00:21    [W:2.203 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site