mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-12-13 22:14:20 +08:00
52ded9e4f0
The Raspberry Pi (RPI) is currently the only chip using this driver
(pcie-brcmstb.c). There, only one memory controller is used, without an
extension region, and the SCB0 viewport size is set to the size of the
first and only dma-range region. Other BrcmSTB SOCs have more complicated
memory configurations that require setting additional viewport sizes.
BrcmSTB PCIe controllers are intimately connected to the memory
controller(s) on the SOC. The SOC may have one to three memory
controllers; they are indicated by the term SCBi. Each controller has a
base region and an optional extension region. In physical memory, the base
and extension regions of a controller are not adjacent, but in PCIe-space
they are.
There is a "viewport" for each memory controller that allows DMA from
endpoint devices. Each viewport's size must be set to a power of two, and
that size must be equal to or larger than the amount of memory each
controller supports which is the sum of base region and its optional
extension. Further, the 1-3 viewports are also adjacent in PCIe-space.
Unfortunately the viewport sizes cannot be ascertained from the
"dma-ranges" property so they have their own property, "brcm,scb-sizes".
This is because dma-range information does not indicate what memory
controller it is associated. For example, consider the following case
where the size of one dma-range is 2GB and the second dma-range is 1GB:
/* Case 1: SCB0 size set to 4GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
/* Case 2: SCB0 size set to 2GB, SCB1 size set to 1GB */
dma-range0: 2GB (from memc0-base)
dma-range1: 1GB (from memc0-extension)
By just looking at the dma-ranges information, one cannot tell which
situation applies. That is why an additional property is needed. Its
length indicates the number of memory controllers being used and each value
indicates the viewport size.
Note that the RPI DT does not have a "brcm,scb-sizes" property value,
as it is assumed that it only requires one memory controller and no
extension. So the optional use of "brcm,scb-sizes" will be backwards
compatible.
One last layer of complexity exists: all of the viewports sizes must be
added and rounded up to a power of two to determine what the "BAR" size is.
Further, an offset must be given that indicates the base PCIe address of
this "BAR". The use of the term BAR is typically associated with endpoint
devices, and the term is used here because the PCIe HW may be used as an RC
or an EP. In the former case, all of the system memory appears in a single
"BAR" region in PCIe memory. As it turns out, BrcmSTB PCIe HW is rarely
used in the EP role and its system of mapping memory is an artifact that
requires multiple dma-ranges regions.
Link: https://lore.kernel.org/r/20200911175232.19016-8-james.quinlan@broadcom.com
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
|
||
|---|---|---|
| .. | ||
| cadence | ||
| dwc | ||
| mobiveil | ||
| Kconfig | ||
| Makefile | ||
| pci-aardvark.c | ||
| pci-ftpci100.c | ||
| pci-host-common.c | ||
| pci-host-generic.c | ||
| pci-hyperv-intf.c | ||
| pci-hyperv.c | ||
| pci-loongson.c | ||
| pci-mvebu.c | ||
| pci-rcar-gen2.c | ||
| pci-tegra.c | ||
| pci-thunder-ecam.c | ||
| pci-thunder-pem.c | ||
| pci-v3-semi.c | ||
| pci-versatile.c | ||
| pci-xgene-msi.c | ||
| pci-xgene.c | ||
| pcie-altera-msi.c | ||
| pcie-altera.c | ||
| pcie-brcmstb.c | ||
| pcie-iproc-bcma.c | ||
| pcie-iproc-msi.c | ||
| pcie-iproc-platform.c | ||
| pcie-iproc.c | ||
| pcie-iproc.h | ||
| pcie-mediatek.c | ||
| pcie-rcar-ep.c | ||
| pcie-rcar-host.c | ||
| pcie-rcar.c | ||
| pcie-rcar.h | ||
| pcie-rockchip-ep.c | ||
| pcie-rockchip-host.c | ||
| pcie-rockchip.c | ||
| pcie-rockchip.h | ||
| pcie-tango.c | ||
| pcie-xilinx-cpm.c | ||
| pcie-xilinx-nwl.c | ||
| pcie-xilinx.c | ||
| vmd.c | ||