On 03/03/2017 21:04, Bjorn Helgaas wrote:
> On Fri, Mar 03, 2017 at 06:18:02PM +0100, Mason wrote:
>
>> # /usr/sbin/lspci -v
>> 00:00.0 PCI bridge: Sigma Designs, Inc. Device 0024 (rev 01) (prog-if 00 [Normal decode])
>> Flags: bus master, fast devsel, latency 0
>> Memory at 90000000 (64-bit, non-prefetchable) [size=16M]
>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
>> I/O behind bridge: 00000000-00000fff
>
> Something's wrong with this. You have no I/O windows through the host
> bridge, which implies that you can't generic PCI I/O transactions, so
> this I/O window should be disabled. This might be an lspci issue;
> what does "lspci -xxx" show?
>
>> Memory behind bridge: 91000000-910fffff
>> Prefetchable memory behind bridge: 00000000-000fffff
>
> This prefetchable memory window is bogus, too. It should probably be
> disabled. If the bridge doesn't support a prefetchable window, the
> base and limit should be hardwired to zero. If it supports a window
> but it's disabled, the limit should be less than the base. For
> example, on my system I see this for a bridge with the window
> disabled:
>
> # setpci -s00:1c.0 PREF_MEMORY_BASE
> fff1
> # setpci -s00:1c.0 PREF_MEMORY_LIMIT
> 0001
MAJOR UPDATE: As pointed out by Ard, my DT was hopelessly wrong for
the non-prefetchable memory region (in the ranges prop).
In fact, my platform *multiplexes* config and MEM spaces.
In other words, there are *two* overlapping 256 MB windows at CPU
address 0x50000000. A register in MMIO space allows software to
select either config space or MEM space.
Current DT node:
pcie@50000000 {
compatible = "pci-host-ecam-generic";
reg = <0x50000000 0x10000000>;
device_type = "pci";
#size-cells = <2>;
#address-cells = <3>;
#interrupt-cells = <1>;
ranges = <0x02000000 0x0 0x0 0x50000000 0x0 0x10000000>;
};
Ard pointed out that Linux does not support such a setup.
[ 0.994011] OF: PCI: host bridge /soc/pcie@50000000 ranges:
[ 0.999721] OF: PCI: Parsing ranges property...
[ 1.004386] OF: PCI: MEM 0x50000000..0x5fffffff -> 0x00000000
[ 1.010471] pci-host-generic 50000000.pcie:
can't claim ECAM area [mem 0x50000000-0x5fffffff]:
address conflict with /soc/pcie@50000000 [mem 0x50000000-0x5fffffff]
[ 1.025265] pci-host-generic: probe of 50000000.pcie failed with error -16
IIUC, there may be concurrent accesses to config space and MEM space?
I'm wondering what my options are for this controller at this point :-(
In a separate (related) thread ("Panic in quirk_usb_early_handoff",
David Laight wrote:
> So to do a config space access you have to use a pair of IPIs
> to stop the other cpus doing any PCIe data accesses while the
> MMIO bit makes the accesses all point to config space.
> (After taking a lock to get access to the MMIO register.)
>
> Or has someone a better idea?
Regards.
