On Thu, Sep 25, 2014 at 12:04 AM, Arnd Bergmann [off-list ref] wrote:

On Wednesday 24 September 2014 23:34:04 Sunil Kovvuri wrote:

quoted

On Wed, Sep 24, 2014 at 9:36 PM, Arnd Bergmann [off-list ref] wrote:

quoted

On Wednesday 24 September 2014 17:37:45 Robert Richter wrote:

quoted

+               compatible = "cavium,thunder-pcie";
+               device_type = "pci";
+               msi-parent = <&its>;
+               bus-range = <0 255>;
+               #size-cells = <2>;
+               #address-cells = <3>;
+               reg = <0x8480 0x00000000 0 0x10000000>;  /* Configuration space */
+               ranges = <0x03000000 0x8010 0x00000000 0x8010 0x00000000 0x70 0x00000000>, /* mem ranges */
+                       <0x03000000 0x8300 0x00000000 0x8300 0x00000000 0x80 0x00000000>,
+                       <0x03000000 0x87e0 0x00000000 0x87e0 0x00000000 0x01 0x00000000>;
+        };

If you claim the entire 0-255 bus range, I think you should also
specify a domain, otherwise it's not predictable which domain you
get.

The interrupt-map and interrupt-map-mask properties are required for PCI,
otherwise you can't do LSI interrupts.

This PCI controller supports only MSIx interrupts which are edge triggered.

Interesting, so it's not PCI compliant then? I assume this will be fixed
in the production version of the silicon, right?

Having no support for interrupts mean that the majority of PCI device drivers
will fail.

This controller is for on-board PCI devices and all of them do support
MSIx interrupts.

quoted

quoted

If your hardware can support it, you should also list I/O space and prefetchable
memory spaces. Can you explain why you have multiple non-prefetchable ranges?

Our hardware is an ECAM based host controller and doesn't support I/O
and prefetchable memory spaces.
All on-board PCI devices connected to this PCI controller have fixed resources
and doesn't have to be allocated/reassigned. Some of these devices are
SRIOV based.

I think you need to mark the ones that are nonrelocatable with flag
0x80000000, otherwise the PCI core might decide to reassign them.

Is this flag part of DT pci node properties ?
I am using IORESOURCE_PCI_FIXED flag. Its there in other patches of
the same series.

quoted

Kernel's SRIOV (pci/iov.c) is expecting 'resource->parent' hierarchy
to be set, otherwise doesn't
enable SRIOV device. So, here multiple non-prefetchable ranges of root bus
aid in resource claiming and setting res->parent hierarchy.

I don't understand. Isn't that just a bug in the code that you are working
around with the DT. Have you tried fixing the code instead?

I tried but wasn't sure if its going to impact existing SRIOV devices.
Will have a deeper look again .

quoted

We do call "pci_claim_resource" in controller driver code.
"[PATCH 1/6] pci, thunder: Add support for Thunder PCIe host controller."

My guess is that you are using the wrong interface here. Isn't the normal
request_resource() in the host driver enough?

Isn't that host driver calls "request_resource" only for resources of root port.
i.e requesting from iomem_resource/ioport_resource. Here i am referring
to SRIOV devices enumerated upon scan of root port.

        Arnd