* [PATCH v2 0/6] Raspberry Pi 4 PCIe support
@ 2019-11-12 15:59 Nicolas Saenz Julienne
2019-11-12 15:59 ` [PATCH v2 1/6] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions Nicolas Saenz Julienne
` (6 more replies)
0 siblings, 7 replies; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-12 15:59 UTC (permalink / raw)
To: andrew.murray, maz, linux-kernel
Cc: james.quinlan, mbrugger, f.fainelli, phil, wahrenst,
jeremy.linton, Nicolas Saenz Julienne, Robin Murphy,
bcm-kernel-feedback-list, linux-rpi-kernel, linux-arm-kernel,
linux-pci, devicetree, netdev, linux-rdma, linux-rockchip, iommu
This series aims at providing support for Raspberry Pi 4's PCIe
controller, which is also shared with the Broadcom STB family of
devices.
There was a previous attempt to upstream this some years ago[1] but was
blocked as most STB PCIe integrations have a sparse DMA mapping[2] which
is something currently not supported by the kernel. Luckily this is not
the case for the Raspberry Pi 4.
Note that the driver code is to be based on top of Rob Herring's series
simplifying inbound and outbound range parsing.
[1] https://patchwork.kernel.org/cover/10605933/
[2] https://patchwork.kernel.org/patch/10605957/
---
Changes since v1:
- add generic rounddown/roundup_pow_two64() patch
- Add MAINTAINERS patch
- Fix Kconfig
- Cleanup probe, use up to date APIs, exit on MSI failure
- Get rid of linux,pci-domain and other unused constructs
- Use edge triggered setup for MSI
- Cleanup MSI implementation
- Fix multiple cosmetic issues
- Remove supend/resume code
Jim Quinlan (3):
dt-bindings: PCI: Add bindings for brcmstb's PCIe device
PCI: brcmstb: add Broadcom STB PCIe host controller driver
PCI: brcmstb: add MSI capability
Nicolas Saenz Julienne (3):
linux/log2.h: Add roundup/rounddown_pow_two64() family of functions
ARM: dts: bcm2711: Enable PCIe controller
MAINTAINERS: Add brcmstb PCIe controller
.../bindings/pci/brcm,stb-pcie.yaml | 110 ++
MAINTAINERS | 4 +
arch/arm/boot/dts/bcm2711.dtsi | 46 +
drivers/net/ethernet/mellanox/mlx4/en_clock.c | 3 +-
drivers/pci/controller/Kconfig | 9 +
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-brcmstb.c | 1179 +++++++++++++++++
drivers/pci/controller/pcie-cadence-ep.c | 7 +-
drivers/pci/controller/pcie-cadence.c | 7 +-
drivers/pci/controller/pcie-rockchip-ep.c | 9 +-
include/linux/log2.h | 52 +
kernel/dma/direct.c | 3 +-
12 files changed, 1412 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
create mode 100644 drivers/pci/controller/pcie-brcmstb.c
--
2.24.0
^ permalink raw reply [flat|nested] 36+ messages in thread
* [PATCH v2 1/6] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions
2019-11-12 15:59 [PATCH v2 0/6] Raspberry Pi 4 PCIe support Nicolas Saenz Julienne
@ 2019-11-12 15:59 ` Nicolas Saenz Julienne
2019-11-19 11:13 ` Andrew Murray
2019-11-12 15:59 ` [PATCH v2 2/6] dt-bindings: PCI: Add bindings for brcmstb's PCIe device Nicolas Saenz Julienne
` (5 subsequent siblings)
6 siblings, 1 reply; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-12 15:59 UTC (permalink / raw)
To: andrew.murray, maz, linux-kernel, Tariq Toukan, Tom Joseph,
Lorenzo Pieralisi, Shawn Lin, Heiko Stuebner, Christoph Hellwig,
Marek Szyprowski, Robin Murphy
Cc: james.quinlan, mbrugger, f.fainelli, phil, wahrenst,
jeremy.linton, Nicolas Saenz Julienne, David S. Miller,
Bjorn Helgaas, netdev, linux-rdma, linux-pci, linux-rockchip,
linux-arm-kernel, iommu
Some users need to make sure their rounding function accepts and returns
64bit long variables regardless of the architecture. Sadly
roundup/rounddown_pow_two() takes and returns unsigned longs. Create a
new generic 64bit variant of the function and cleanup rougue custom
implementations.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/net/ethernet/mellanox/mlx4/en_clock.c | 3 +-
drivers/pci/controller/pcie-cadence-ep.c | 7 +--
drivers/pci/controller/pcie-cadence.c | 7 +--
drivers/pci/controller/pcie-rockchip-ep.c | 9 ++--
include/linux/log2.h | 52 +++++++++++++++++++
kernel/dma/direct.c | 3 +-
6 files changed, 63 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_clock.c b/drivers/net/ethernet/mellanox/mlx4/en_clock.c
index 024788549c25..027bd72505e2 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_clock.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_clock.c
@@ -33,6 +33,7 @@
#include <linux/mlx4/device.h>
#include <linux/clocksource.h>
+#include <linux/log2.h>
#include "mlx4_en.h"
@@ -252,7 +253,7 @@ static u32 freq_to_shift(u16 freq)
{
u32 freq_khz = freq * 1000;
u64 max_val_cycles = freq_khz * 1000 * MLX4_EN_WRAP_AROUND_SEC;
- u64 max_val_cycles_rounded = 1ULL << fls64(max_val_cycles - 1);
+ u64 max_val_cycles_rounded = roundup_pow_of_two64(max_val_cycles);
/* calculate max possible multiplier in order to fit in 64bit */
u64 max_mul = div64_u64(ULLONG_MAX, max_val_cycles_rounded);
diff --git a/drivers/pci/controller/pcie-cadence-ep.c b/drivers/pci/controller/pcie-cadence-ep.c
index def7820cb824..26ff424b16f5 100644
--- a/drivers/pci/controller/pcie-cadence-ep.c
+++ b/drivers/pci/controller/pcie-cadence-ep.c
@@ -10,6 +10,7 @@
#include <linux/platform_device.h>
#include <linux/pm_runtime.h>
#include <linux/sizes.h>
+#include <linux/log2.h>
#include "pcie-cadence.h"
@@ -90,11 +91,7 @@ static int cdns_pcie_ep_set_bar(struct pci_epc *epc, u8 fn,
/* BAR size is 2^(aperture + 7) */
sz = max_t(size_t, epf_bar->size, CDNS_PCIE_EP_MIN_APERTURE);
- /*
- * roundup_pow_of_two() returns an unsigned long, which is not suited
- * for 64bit values.
- */
- sz = 1ULL << fls64(sz - 1);
+ sz = roundup_pow_of_two64(sz);
aperture = ilog2(sz) - 7; /* 128B -> 0, 256B -> 1, 512B -> 2, ... */
if ((flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
diff --git a/drivers/pci/controller/pcie-cadence.c b/drivers/pci/controller/pcie-cadence.c
index cd795f6fc1e2..b2278e6b955c 100644
--- a/drivers/pci/controller/pcie-cadence.c
+++ b/drivers/pci/controller/pcie-cadence.c
@@ -4,6 +4,7 @@
// Author: Cyrille Pitchen <cyrille.pitchen@free-electrons.com>
#include <linux/kernel.h>
+#include <linux/log2.h>
#include "pcie-cadence.h"
@@ -11,11 +12,7 @@ void cdns_pcie_set_outbound_region(struct cdns_pcie *pcie, u8 fn,
u32 r, bool is_io,
u64 cpu_addr, u64 pci_addr, size_t size)
{
- /*
- * roundup_pow_of_two() returns an unsigned long, which is not suited
- * for 64bit values.
- */
- u64 sz = 1ULL << fls64(size - 1);
+ u64 sz = roundup_pow_of_two64(size);
int nbits = ilog2(sz);
u32 addr0, addr1, desc0, desc1;
diff --git a/drivers/pci/controller/pcie-rockchip-ep.c b/drivers/pci/controller/pcie-rockchip-ep.c
index d743b0a48988..ed50aaf27784 100644
--- a/drivers/pci/controller/pcie-rockchip-ep.c
+++ b/drivers/pci/controller/pcie-rockchip-ep.c
@@ -16,6 +16,7 @@
#include <linux/platform_device.h>
#include <linux/pci-epf.h>
#include <linux/sizes.h>
+#include <linux/log2.h>
#include "pcie-rockchip.h"
@@ -70,7 +71,7 @@ static void rockchip_pcie_prog_ep_ob_atu(struct rockchip_pcie *rockchip, u8 fn,
u32 r, u32 type, u64 cpu_addr,
u64 pci_addr, size_t size)
{
- u64 sz = 1ULL << fls64(size - 1);
+ u64 sz = roundup_pow_of_two64(size);
int num_pass_bits = ilog2(sz);
u32 addr0, addr1, desc0, desc1;
bool is_nor_msg = (type == AXI_WRAPPER_NOR_MSG);
@@ -172,11 +173,7 @@ static int rockchip_pcie_ep_set_bar(struct pci_epc *epc, u8 fn,
/* BAR size is 2^(aperture + 7) */
sz = max_t(size_t, epf_bar->size, MIN_EP_APERTURE);
- /*
- * roundup_pow_of_two() returns an unsigned long, which is not suited
- * for 64bit values.
- */
- sz = 1ULL << fls64(sz - 1);
+ sz = roundup_pow_of_two64(sz);
aperture = ilog2(sz) - 7; /* 128B -> 0, 256B -> 1, 512B -> 2, ... */
if ((flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
diff --git a/include/linux/log2.h b/include/linux/log2.h
index 83a4a3ca3e8a..db12d92ab6eb 100644
--- a/include/linux/log2.h
+++ b/include/linux/log2.h
@@ -67,6 +67,24 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
return 1UL << (fls_long(n) - 1);
}
+/**
+ * __roundup_pow_of_two64() - round 64bit value up to nearest power of two
+ * @n: value to round up
+ */
+static inline __attribute__((const)) __u64 __roundup_pow_of_two64(__u64 n)
+{
+ return 1UL << fls64(n - 1);
+}
+
+/**
+ * __rounddown_pow_of_two64() - round 64bit value down to nearest power of two
+ * @n: value to round down
+ */
+static inline __attribute__((const)) __u64 __rounddown_pow_of_two64(__u64 n)
+{
+ return 1UL << (fls64(n) - 1);
+}
+
/**
* const_ilog2 - log base 2 of 32-bit or a 64-bit constant unsigned value
* @n: parameter
@@ -194,6 +212,40 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
__rounddown_pow_of_two(n) \
)
+/**
+ * roundup_pow_of_two64 - round the given 64bit value up to nearest power of
+ * two
+ * @n: parameter
+ *
+ * round the given value up to the nearest power of two
+ * - the result is undefined when n == 0
+ * - this can be used to initialise global variables from constant data
+ */
+#define roundup_pow_of_two64(n) \
+( \
+ __builtin_constant_p(n) ? ( \
+ (n == 1) ? 1 : \
+ (1UL << (ilog2((n) - 1) + 1)) \
+ ) : \
+ __roundup_pow_of_two64(n) \
+)
+
+/**
+ * rounddown_pow_of_two64 - round the given 64bit value down to nearest power
+ * of two
+ * @n: parameter
+ *
+ * round the given value down to the nearest power of two
+ * - the result is undefined when n == 0
+ * - this can be used to initialise global variables from constant data
+ */
+#define rounddown_pow_of_two64(n) \
+( \
+ __builtin_constant_p(n) ? ( \
+ (1UL << ilog2(n))) : \
+ __rounddown_pow_of_two64(n) \
+)
+
static inline __attribute_const__
int __order_base_2(unsigned long n)
{
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index b9e1744999d9..a419530abd3e 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -15,6 +15,7 @@
#include <linux/vmalloc.h>
#include <linux/set_memory.h>
#include <linux/swiotlb.h>
+#include <linux/log2.h>
/*
* Most architectures use ZONE_DMA for the first 16 Megabytes, but some use it
@@ -53,7 +54,7 @@ u64 dma_direct_get_required_mask(struct device *dev)
{
u64 max_dma = phys_to_dma_direct(dev, (max_pfn - 1) << PAGE_SHIFT);
- return (1ULL << (fls64(max_dma) - 1)) * 2 - 1;
+ return rounddown_pow_of_two64(max_dma) * 2 - 1;
}
static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
--
2.24.0
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v2 2/6] dt-bindings: PCI: Add bindings for brcmstb's PCIe device
2019-11-12 15:59 [PATCH v2 0/6] Raspberry Pi 4 PCIe support Nicolas Saenz Julienne
2019-11-12 15:59 ` [PATCH v2 1/6] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions Nicolas Saenz Julienne
@ 2019-11-12 15:59 ` Nicolas Saenz Julienne
2019-11-18 21:23 ` Rob Herring
2019-11-19 11:17 ` Andrew Murray
2019-11-12 15:59 ` [PATCH v2 3/6] ARM: dts: bcm2711: Enable PCIe controller Nicolas Saenz Julienne
` (4 subsequent siblings)
6 siblings, 2 replies; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-12 15:59 UTC (permalink / raw)
To: andrew.murray, maz, linux-kernel, Eric Anholt, Stefan Wahren,
Florian Fainelli, bcm-kernel-feedback-list, Bjorn Helgaas
Cc: james.quinlan, mbrugger, phil, jeremy.linton,
Nicolas Saenz Julienne, Rob Herring, Mark Rutland,
linux-arm-kernel, linux-rpi-kernel, linux-pci, devicetree
From: Jim Quinlan <james.quinlan@broadcom.com>
The DT bindings description of the brcmstb PCIe device is described.
This node can only be used for now on the Raspberry Pi 4.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Co-developed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes since v1:
- Fix commit Subject
- Remove linux,pci-domain
This was based on Jim's original submission[1], converted to yaml and
adapted to the RPi4 case.
[1] https://patchwork.kernel.org/patch/10605937/
.../bindings/pci/brcm,stb-pcie.yaml | 110 ++++++++++++++++++
1 file changed, 110 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
new file mode 100644
index 000000000000..4cbb18821300
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/brcm,stb-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Brcmstb PCIe Host Controller Device Tree Bindings
+
+maintainers:
+ - Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+
+properties:
+ compatible:
+ const: brcm,bcm2711-pcie # The Raspberry Pi 4
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+ items:
+ - description: PCIe host controller
+ - description: builtin MSI controller
+
+ interrupt-names:
+ minItems: 1
+ maxItems: 2
+ items:
+ - const: pcie
+ - const: msi
+
+ "#address-cells":
+ const: 3
+
+ "#size-cells":
+ const: 2
+
+ "#interrupt-cells":
+ const: 1
+
+ interrupt-map-mask: true
+
+ interrupt-map: true
+
+ ranges: true
+
+ dma-ranges: true
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: sw_pcie
+
+ msi-controller:
+ description: Identifies the node as an MSI controller.
+ type: boolean
+
+ msi-parent:
+ description: MSI controller the device is capable of using.
+ $ref: /schemas/types.yaml#/definitions/phandle
+
+ brcm,enable-ssc:
+ description: Indicates usage of spread-spectrum clocking.
+ type: boolean
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - "#interrupt-cells"
+ - interrupt-map-mask
+ - interrupt-map
+ - ranges
+ - dma-ranges
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ scb {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ pcie0: pcie@7d500000 {
+ compatible = "brcm,bcm2711-pcie";
+ reg = <0x0 0x7d500000 0x9310>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ #interrupt-cells = <1>;
+ interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "pcie", "msi";
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0 0 0 1 &gicv2 GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH
+ 0 0 0 2 &gicv2 GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH
+ 0 0 0 3 &gicv2 GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH
+ 0 0 0 4 &gicv2 GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
+ msi-parent = <&pcie0>;
+ msi-controller;
+ ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>;
+ dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>;
+ brcm,enable-ssc;
+ };
+ };
--
2.24.0
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v2 3/6] ARM: dts: bcm2711: Enable PCIe controller
2019-11-12 15:59 [PATCH v2 0/6] Raspberry Pi 4 PCIe support Nicolas Saenz Julienne
2019-11-12 15:59 ` [PATCH v2 1/6] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions Nicolas Saenz Julienne
2019-11-12 15:59 ` [PATCH v2 2/6] dt-bindings: PCI: Add bindings for brcmstb's PCIe device Nicolas Saenz Julienne
@ 2019-11-12 15:59 ` Nicolas Saenz Julienne
2019-11-12 15:59 ` [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver Nicolas Saenz Julienne
` (3 subsequent siblings)
6 siblings, 0 replies; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-12 15:59 UTC (permalink / raw)
To: andrew.murray, maz, linux-kernel, Rob Herring, Mark Rutland,
Eric Anholt, Stefan Wahren
Cc: james.quinlan, mbrugger, f.fainelli, phil, jeremy.linton,
Nicolas Saenz Julienne, devicetree, bcm-kernel-feedback-list,
linux-rpi-kernel, linux-arm-kernel
This enables bcm2711's PCIe bus, which is hardwired to a VIA
Technologies XHCI USB 3.0 controller.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes since v1:
- remove linux,pci-domain
---
arch/arm/boot/dts/bcm2711.dtsi | 46 ++++++++++++++++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi
index 667658497898..664fefb2011e 100644
--- a/arch/arm/boot/dts/bcm2711.dtsi
+++ b/arch/arm/boot/dts/bcm2711.dtsi
@@ -288,6 +288,52 @@ IRQ_TYPE_LEVEL_LOW)>,
arm,cpu-registers-not-fw-configured;
};
+ scb {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ ranges = <0x0 0x7c000000 0x0 0xfc000000 0x03800000>,
+ <0x6 0x00000000 0x6 0x00000000 0x40000000>;
+
+ pcie_0: pcie@7d500000 {
+ compatible = "brcm,bcm2711-pcie";
+ reg = <0x0 0x7d500000 0x9310>;
+ msi-controller;
+ msi-parent = <&pcie_0>;
+ #address-cells = <3>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ brcm,enable-ssc;
+ interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "pcie", "msi";
+ interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+ interrupt-map = <0 0 0 1 &gicv2 GIC_SPI 143
+ IRQ_TYPE_LEVEL_HIGH
+ 0 0 0 2 &gicv2 GIC_SPI 144
+ IRQ_TYPE_LEVEL_HIGH
+ 0 0 0 3 &gicv2 GIC_SPI 145
+ IRQ_TYPE_LEVEL_HIGH
+ 0 0 0 4 &gicv2 GIC_SPI 146
+ IRQ_TYPE_LEVEL_HIGH>;
+
+ ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000
+ 0x0 0x04000000>;
+ /*
+ * The wrapper around the PCIe block has a bug
+ * preventing it from accessing beyond the first 3GB of
+ * memory. As the bus DMA mask is rounded up to the
+ * closest power of two of the dma-range size, we're
+ * forced to set the limit at 2GB. This can be
+ * harmlessly changed in the future once the DMA code
+ * handles non power of two DMA limits.
+ */
+ dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000
+ 0x0 0x80000000>;
+ };
+ };
+
cpus: cpus {
#address-cells = <1>;
#size-cells = <0>;
--
2.24.0
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver
2019-11-12 15:59 [PATCH v2 0/6] Raspberry Pi 4 PCIe support Nicolas Saenz Julienne
` (2 preceding siblings ...)
2019-11-12 15:59 ` [PATCH v2 3/6] ARM: dts: bcm2711: Enable PCIe controller Nicolas Saenz Julienne
@ 2019-11-12 15:59 ` Nicolas Saenz Julienne
2019-11-19 16:25 ` Andrew Murray
2019-11-12 15:59 ` [PATCH v2 5/6] PCI: brcmstb: add MSI capability Nicolas Saenz Julienne
` (2 subsequent siblings)
6 siblings, 1 reply; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-12 15:59 UTC (permalink / raw)
To: andrew.murray, maz, linux-kernel, Lorenzo Pieralisi, Eric Anholt,
Stefan Wahren, Florian Fainelli, bcm-kernel-feedback-list
Cc: james.quinlan, mbrugger, phil, jeremy.linton,
Nicolas Saenz Julienne, Bjorn Helgaas, linux-pci,
linux-rpi-kernel, linux-arm-kernel
From: Jim Quinlan <james.quinlan@broadcom.com>
This commit adds the basic Broadcom STB PCIe controller. Missing is the
ability to process MSI. This functionality is added in a subsequent
commit.
The PCIe block contains an MDIO interface. This is a local interface
only accessible by the PCIe controller. It cannot be used or shared
by any other HW. As such, the small amount of code for this
controller is included in this driver as there is little upside to put
it elsewhere.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Co-developed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes since v1:
- Fix Kconfig
- Remove pci domain check
- Remove all MSI related code
- Remove supend/resume code
- Simplify link state wait routine
- Prefix all functions
- Use of_device_get_match_data()
- Use devm_clk_get_optional()
- Get rid of irq variable
- Use STB all over the driver
- Fix license mismatch
- Remove unused register definitions
- Small cleanups, spell errors
NOTE: I decided to remove the suspend/resume routines for now. The
RPi4 doesn't need it, and we where having issues with the
specifics of the resume function on devices we yet don't support.
We'll deal with this in the future.
This is based on Jim's original submission[1] but adapted and tailored
specifically to bcm2711's needs (that's the Raspberry Pi 4). Support for
the rest of the brcmstb family will soon follow once we get support for
multiple dma-ranges in dma/direct.
[1] https://patchwork.kernel.org/patch/10605959/
drivers/pci/controller/Kconfig | 8 +
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-brcmstb.c | 855 ++++++++++++++++++++++++++
3 files changed, 864 insertions(+)
create mode 100644 drivers/pci/controller/pcie-brcmstb.c
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index f5de9119e8d3..486d4d570233 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -281,6 +281,14 @@ config VMD
To compile this driver as a module, choose M here: the
module will be called vmd.
+config PCIE_BRCMSTB
+ bool "Broadcom Brcmstb PCIe host controller"
+ depends on ARCH_BCM2835 || COMPILE_TEST
+ depends on OF
+ help
+ Say Y here to enable PCIe host controller support for
+ Broadcom STB based SoCs, like the Raspberry Pi 4.
+
config PCI_HYPERV_INTERFACE
tristate "Hyper-V PCI Interface"
depends on X86 && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN && X86_64
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index a2a22c9d91af..3fc0b0cf5b5b 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
obj-$(CONFIG_VMD) += vmd.o
+obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o
# pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
obj-y += dwc/
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
new file mode 100644
index 000000000000..8d81c5ab5979
--- /dev/null
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -0,0 +1,855 @@
+// SPDX-License-Identifier: GPL-2.0+
+/* Copyright (C) 2009 - 2019 Broadcom */
+
+#include <linux/clk.h>
+#include <linux/compiler.h>
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/ioport.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/log2.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/pci.h>
+#include <linux/printk.h>
+#include <linux/sizes.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/types.h>
+
+#include "../pci.h"
+
+/* BRCM_PCIE_CAP_REGS - Offset for the mandatory capability config regs */
+#define BRCM_PCIE_CAP_REGS 0x00ac
+
+/*
+ * Broadcom STB PCIe Register Offsets. The names are from the chip's RDB and we
+ * use them here so that a script can correlate this code and the RDB to
+ * prevent discrepancies.
+ */
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1 0x0188
+#define PCIE_RC_CFG_PRIV1_ID_VAL3 0x043c
+#define PCIE_RC_DL_MDIO_ADDR 0x1100
+#define PCIE_RC_DL_MDIO_WR_DATA 0x1104
+#define PCIE_RC_DL_MDIO_RD_DATA 0x1108
+#define PCIE_MISC_MISC_CTRL 0x4008
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO 0x400c
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI 0x4010
+#define PCIE_MISC_RC_BAR1_CONFIG_LO 0x402c
+#define PCIE_MISC_RC_BAR2_CONFIG_LO 0x4034
+#define PCIE_MISC_RC_BAR2_CONFIG_HI 0x4038
+#define PCIE_MISC_RC_BAR3_CONFIG_LO 0x403c
+#define PCIE_MISC_PCIE_CTRL 0x4064
+#define PCIE_MISC_PCIE_STATUS 0x4068
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT 0x4070
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI 0x4080
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI 0x4084
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
+#define PCIE_INTR2_CPU_BASE 0x4300
+
+/*
+ * Broadcom STB PCIe Register Field shift and mask info. The names are from the
+ * chip's RDB and we use them here so that a script can correlate this code and
+ * the RDB to prevent discrepancies.
+ */
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_MASK 0xc
+#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_SHIFT 0x2
+#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_MASK 0xffffff
+#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_SHIFT 0x0
+#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK 0x1000
+#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_SHIFT 0xc
+#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK 0x2000
+#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_SHIFT 0xd
+#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
+#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_SHIFT 0x14
+#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
+#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_SHIFT 0x1b
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_MASK 0x1f
+#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_SHIFT 0x0
+#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK 0x1
+#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_SHIFT 0x0
+#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_MASK 0x80
+#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_SHIFT 0x7
+#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_MASK 0x20
+#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_SHIFT 0x5
+#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_MASK 0x10
+#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_SHIFT 0x4
+#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK 0x40
+#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_SHIFT 0x6
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_MASK 0xfff00000
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_SHIFT 0x14
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK 0xfff0
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_SHIFT 0x4
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS 0xc
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_MASK 0xff
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_SHIFT 0x0
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_MASK 0xff
+#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_SHIFT 0x0
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK 0x2
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_SHIFT 0x1
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
+#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_SHIFT 0x1b
+#define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1
+#define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0
+
+#define BRCM_NUM_PCIE_OUT_WINS 0x4
+
+#define BURST_SIZE_128 0
+
+/* Offsets from PCIE_INTR2_CPU_BASE */
+#define STATUS 0x0
+#define CLR 0x8
+#define MASK_SET 0x10
+#define MASK_CLR 0x14
+
+#define PCIE_BUSNUM_SHIFT 20
+#define PCIE_SLOT_SHIFT 15
+#define PCIE_FUNC_SHIFT 12
+
+#if defined(__BIG_ENDIAN)
+#define DATA_ENDIAN 2 /* PCIe->DDR inbound traffic */
+#define MMIO_ENDIAN 2 /* CPU->PCIe outbound traffic */
+#else
+#define DATA_ENDIAN 0
+#define MMIO_ENDIAN 0
+#endif
+
+#define MDIO_PORT0 0x0
+#define MDIO_DATA_MASK 0x7fffffff
+#define MDIO_DATA_SHIFT 0x0
+#define MDIO_PORT_MASK 0xf0000
+#define MDIO_PORT_SHIFT 0x16
+#define MDIO_REGAD_MASK 0xffff
+#define MDIO_REGAD_SHIFT 0x0
+#define MDIO_CMD_MASK 0xfff00000
+#define MDIO_CMD_SHIFT 0x14
+#define MDIO_CMD_READ 0x1
+#define MDIO_CMD_WRITE 0x0
+#define MDIO_DATA_DONE_MASK 0x80000000
+#define MDIO_RD_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 1 : 0)
+#define MDIO_WT_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 0 : 1)
+#define SSC_REGS_ADDR 0x1100
+#define SET_ADDR_OFFSET 0x1f
+#define SSC_CNTL_OFFSET 0x2
+#define SSC_CNTL_OVRD_EN_MASK 0x8000
+#define SSC_CNTL_OVRD_EN_SHIFT 0xf
+#define SSC_CNTL_OVRD_VAL_MASK 0x4000
+#define SSC_CNTL_OVRD_VAL_SHIFT 0xe
+#define SSC_STATUS_OFFSET 0x1
+#define SSC_STATUS_SSC_MASK 0x400
+#define SSC_STATUS_SSC_SHIFT 0xa
+#define SSC_STATUS_PLL_LOCK_MASK 0x800
+#define SSC_STATUS_PLL_LOCK_SHIFT 0xb
+
+#define BRCM_PCIE_IDX_ADDR(pcie) \
+ ((pcie)->reg_offsets[EXT_CFG_INDEX])
+#define BRCM_PCIE_DATA_ADDR(pcie) \
+ ((pcie)->reg_offsets[EXT_CFG_DATA])
+#define BRCM_PCIE_RGR1_SW_INIT_1(pcie) \
+ ((pcie)->reg_offsets[RGR1_SW_INIT_1])
+
+enum {
+ RGR1_SW_INIT_1,
+ EXT_CFG_INDEX,
+ EXT_CFG_DATA,
+};
+
+enum {
+ RGR1_SW_INIT_1_INIT_MASK,
+ RGR1_SW_INIT_1_INIT_SHIFT,
+ RGR1_SW_INIT_1_PERST_MASK,
+ RGR1_SW_INIT_1_PERST_SHIFT,
+};
+
+enum pcie_type {
+ BCM2711,
+};
+
+struct brcm_window {
+ dma_addr_t pcie_addr;
+ phys_addr_t cpu_addr;
+ dma_addr_t size;
+};
+
+/* Internal PCIe Host Controller Information.*/
+struct brcm_pcie {
+ struct device *dev;
+ void __iomem *base;
+ struct clk *clk;
+ struct pci_bus *root_bus;
+ struct device_node *np;
+ bool ssc;
+ int gen;
+ struct brcm_window out_wins[BRCM_NUM_PCIE_OUT_WINS];
+ const int *reg_offsets;
+ const int *reg_field_info;
+ enum pcie_type type;
+};
+
+struct pcie_cfg_data {
+ const int *reg_field_info;
+ const int *offsets;
+ const enum pcie_type type;
+};
+
+static const int pcie_reg_field_info[] = {
+ [RGR1_SW_INIT_1_INIT_MASK] = 0x2,
+ [RGR1_SW_INIT_1_INIT_SHIFT] = 0x1,
+};
+
+static const int pcie_offset_bcm2711[] = {
+ [RGR1_SW_INIT_1] = 0x9210,
+ [EXT_CFG_INDEX] = 0x9000,
+ [EXT_CFG_DATA] = 0x8000,
+};
+
+static const struct pcie_cfg_data bcm2711_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offset_bcm2711,
+ .type = BCM2711,
+};
+
+static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
+ int where);
+
+static struct pci_ops brcm_pcie_ops = {
+ .map_bus = brcm_pcie_map_conf,
+ .read = pci_generic_config_read,
+ .write = pci_generic_config_write,
+};
+
+#define bcm_readl(a) readl(a)
+#define bcm_writel(d, a) writel(d, a)
+#define bcm_readw(a) readw(a)
+#define bcm_writew(d, a) writew(d, a)
+
+/* These macros extract/insert fields to host controller's register set. */
+#define RD_FLD(base, reg, field) \
+ brcm_pcie_rd_fld((base) + reg, reg##_##field##_MASK, \
+ reg##_##field##_SHIFT)
+#define WR_FLD(base, reg, field, val) \
+ brcm_pcie_wr_fld((base) + reg, reg##_##field##_MASK, \
+ reg##_##field##_SHIFT, val)
+#define WR_FLD_RB(base, reg, field, val) \
+ brcm_pcie_wr_fld_rb((base) + reg, reg##_##field##_MASK, \
+ reg##_##field##_SHIFT, val)
+#define WR_FLD_WITH_OFFSET(base, off, reg, field, val) \
+ brcm_pcie_wr_fld((base) + reg + (off), reg##_##field##_MASK, \
+ reg##_##field##_SHIFT, val)
+#define EXTRACT_FIELD(val, reg, field) \
+ (((val) & reg##_##field##_MASK) >> reg##_##field##_SHIFT)
+#define INSERT_FIELD(val, reg, field, field_val) \
+ (((val) & ~reg##_##field##_MASK) | \
+ (reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
+
+static u32 brcm_pcie_rd_fld(void __iomem *p, u32 mask, int shift)
+{
+ return (bcm_readl(p) & mask) >> shift;
+}
+
+static void brcm_pcie_wr_fld(void __iomem *p, u32 mask, int shift, u32 val)
+{
+ u32 reg = bcm_readl(p);
+
+ reg = (reg & ~mask) | ((val << shift) & mask);
+ bcm_writel(reg, p);
+}
+
+static void brcm_pcie_wr_fld_rb(void __iomem *p, u32 mask, int shift, u32 val)
+{
+ brcm_pcie_wr_fld(p, mask, shift, val);
+ (void)bcm_readl(p);
+}
+
+/*
+ * This is to convert the size of the inbound "BAR" region to the
+ * non-linear values of PCIE_X_MISC_RC_BAR[123]_CONFIG_LO.SIZE
+ */
+int brcm_pcie_encode_ibar_size(u64 size)
+{
+ int log2_in = ilog2(size);
+
+ if (log2_in >= 12 && log2_in <= 15)
+ /* Covers 4KB to 32KB (inclusive) */
+ return (log2_in - 12) + 0x1c;
+ else if (log2_in >= 16 && log2_in <= 35)
+ /* Covers 64KB to 32GB, (inclusive) */
+ return log2_in - 15;
+ /* Something is awry so disable */
+ return 0;
+}
+
+static u32 brcm_pcie_mdio_form_pkt(int port, int regad, int cmd)
+{
+ u32 pkt = 0;
+
+ pkt |= (port << MDIO_PORT_SHIFT) & MDIO_PORT_MASK;
+ pkt |= (regad << MDIO_REGAD_SHIFT) & MDIO_REGAD_MASK;
+ pkt |= (cmd << MDIO_CMD_SHIFT) & MDIO_CMD_MASK;
+
+ return pkt;
+}
+
+/* negative return value indicates error */
+static int brcm_pcie_mdio_read(void __iomem *base, u8 port, u8 regad)
+{
+ int tries;
+ u32 data;
+
+ bcm_writel(brcm_pcie_mdio_form_pkt(port, regad, MDIO_CMD_READ),
+ base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
+
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
+ for (tries = 0; !MDIO_RD_DONE(data) && tries < 10; tries++) {
+ udelay(10);
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
+ }
+
+ return MDIO_RD_DONE(data)
+ ? (data & MDIO_DATA_MASK) >> MDIO_DATA_SHIFT
+ : -EIO;
+}
+
+/* negative return value indicates error */
+static int brcm_pcie_mdio_write(void __iomem *base, u8 port,
+ u8 regad, u16 wrdata)
+{
+ int tries;
+ u32 data;
+
+ bcm_writel(brcm_pcie_mdio_form_pkt(port, regad, MDIO_CMD_WRITE),
+ base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
+ bcm_writel(MDIO_DATA_DONE_MASK | wrdata,
+ base + PCIE_RC_DL_MDIO_WR_DATA);
+
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
+ for (tries = 0; !MDIO_WT_DONE(data) && tries < 10; tries++) {
+ udelay(10);
+ data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
+ }
+
+ return MDIO_WT_DONE(data) ? 0 : -EIO;
+}
+
+/*
+ * Configures device for Spread Spectrum Clocking (SSC) mode; a negative
+ * return value indicates error.
+ */
+static int brcm_pcie_set_ssc(void __iomem *base)
+{
+ int pll, ssc;
+ u16 wrdata;
+ int tmp;
+
+ tmp = brcm_pcie_mdio_write(base, MDIO_PORT0, SET_ADDR_OFFSET,
+ SSC_REGS_ADDR);
+ if (tmp < 0)
+ return tmp;
+
+ tmp = brcm_pcie_mdio_read(base, MDIO_PORT0, SSC_CNTL_OFFSET);
+ if (tmp < 0)
+ return tmp;
+
+ wrdata = INSERT_FIELD(tmp, SSC_CNTL_OVRD, EN, 1);
+ wrdata = INSERT_FIELD(wrdata, SSC_CNTL_OVRD, VAL, 1);
+ tmp = brcm_pcie_mdio_write(base, MDIO_PORT0, SSC_CNTL_OFFSET, wrdata);
+ if (tmp < 0)
+ return tmp;
+
+ usleep_range(1000, 2000);
+ tmp = brcm_pcie_mdio_read(base, MDIO_PORT0, SSC_STATUS_OFFSET);
+ if (tmp < 0)
+ return tmp;
+
+ ssc = EXTRACT_FIELD(tmp, SSC_STATUS, SSC);
+ pll = EXTRACT_FIELD(tmp, SSC_STATUS, PLL_LOCK);
+
+ return (ssc && pll) ? 0 : -EIO;
+}
+
+/* Limits operation to a specific generation (1, 2, or 3) */
+static void brcm_pcie_set_gen(void __iomem *base, int gen)
+{
+ u32 lnkcap = bcm_readl(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCAP);
+ u16 lnkctl2 = bcm_readw(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCTL2);
+
+ lnkcap = (lnkcap & ~PCI_EXP_LNKCAP_SLS) | gen;
+ bcm_writel(lnkcap, base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCAP);
+
+ lnkctl2 = (lnkctl2 & ~0xf) | gen;
+ bcm_writew(lnkctl2, base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCTL2);
+}
+
+static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
+ unsigned int win, phys_addr_t cpu_addr,
+ dma_addr_t pcie_addr, dma_addr_t size)
+{
+ phys_addr_t cpu_addr_mb, limit_addr_mb;
+ void __iomem *base = pcie->base;
+ u32 tmp;
+
+ /* Set the base of the pcie_addr window */
+ bcm_writel(lower_32_bits(pcie_addr) + MMIO_ENDIAN,
+ base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + (win * 8));
+ bcm_writel(upper_32_bits(pcie_addr),
+ base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + (win * 8));
+
+ cpu_addr_mb = cpu_addr >> 20;
+ limit_addr_mb = (cpu_addr + size - 1) >> 20;
+
+ /* Write the addr base low register */
+ WR_FLD_WITH_OFFSET(base, (win * 4),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
+ BASE, cpu_addr_mb);
+ /* Write the addr limit low register */
+ WR_FLD_WITH_OFFSET(base, (win * 4),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
+ LIMIT, limit_addr_mb);
+
+ /* Write the cpu addr high register */
+ tmp = (u32)(cpu_addr_mb >>
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
+ WR_FLD_WITH_OFFSET(base, (win * 8),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI,
+ BASE, tmp);
+ /* Write the cpu limit high register */
+ tmp = (u32)(limit_addr_mb >>
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
+ WR_FLD_WITH_OFFSET(base, (win * 8),
+ PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI,
+ LIMIT, tmp);
+}
+
+/* Configuration space read/write support */
+static int brcm_pcie_cfg_index(int busnr, int devfn, int reg)
+{
+ return ((PCI_SLOT(devfn) & 0x1f) << PCIE_SLOT_SHIFT)
+ | ((PCI_FUNC(devfn) & 0x07) << PCIE_FUNC_SHIFT)
+ | (busnr << PCIE_BUSNUM_SHIFT)
+ | (reg & ~3);
+}
+
+/* The controller is capable of serving in both RC and EP roles */
+static bool brcm_pcie_rc_mode(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ u32 val = bcm_readl(base + PCIE_MISC_PCIE_STATUS);
+
+ return !!EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PORT);
+}
+
+static bool brcm_pcie_link_up(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ u32 val = bcm_readl(base + PCIE_MISC_PCIE_STATUS);
+ u32 dla = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_DL_ACTIVE);
+ u32 plu = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PHYLINKUP);
+
+ return (dla && plu) ? true : false;
+}
+
+static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
+ int where)
+{
+ struct brcm_pcie *pcie = bus->sysdata;
+ void __iomem *base = pcie->base;
+ int idx;
+
+ /* Accesses to the RC go right to the RC registers if slot==0 */
+ if (pci_is_root_bus(bus))
+ return PCI_SLOT(devfn) ? NULL : base + where;
+
+ /* For devices, write to the config space index register */
+ idx = brcm_pcie_cfg_index(bus->number, devfn, 0);
+ bcm_writel(idx, pcie->base + BRCM_PCIE_IDX_ADDR(pcie));
+ return base + BRCM_PCIE_DATA_ADDR(pcie) + where;
+}
+
+static inline void brcm_pcie_bridge_sw_init_set(struct brcm_pcie *pcie,
+ unsigned int val)
+{
+ unsigned int shift = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_SHIFT];
+ u32 mask = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_MASK];
+
+ brcm_pcie_wr_fld_rb(pcie->base + BRCM_PCIE_RGR1_SW_INIT_1(pcie),
+ mask, shift, val);
+}
+
+static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie,
+ unsigned int val)
+{
+ brcm_pcie_wr_fld_rb(pcie->base + BRCM_PCIE_RGR1_SW_INIT_1(pcie),
+ PCIE_RGR1_SW_INIT_1_PERST_MASK,
+ PCIE_RGR1_SW_INIT_1_PERST_SHIFT, val);
+}
+
+static inline int brcm_pcie_get_rc_bar2_size_and_offset(struct brcm_pcie *pcie,
+ u64 *rc_bar2_size,
+ u64 *rc_bar2_offset)
+{
+ struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
+ struct device *dev = pcie->dev;
+ struct resource_entry *entry;
+ u64 total_mem_size = 0;
+
+ *rc_bar2_offset = -1;
+
+ resource_list_for_each_entry(entry, &bridge->dma_ranges) {
+ /*
+ * We're promised the RC will provide a contiguous view of
+ * memory to downstream devices. We can then infer the
+ * rc_bar2_offset from the lower available dma-range offset.
+ */
+ if (entry->offset < *rc_bar2_offset)
+ *rc_bar2_offset = entry->offset;
+
+ total_mem_size += entry->res->end - entry->res->start + 1;
+ }
+
+ *rc_bar2_size = roundup_pow_of_two64(total_mem_size);
+
+ /*
+ * Validate the results:
+ *
+ * The PCIe host controller by design must set the inbound viewport to
+ * be a contiguous arrangement of all of the system's memory. In
+ * addition, its size mut be a power of two. To further complicate
+ * matters, the viewport must start on a pcie-address that is aligned
+ * on a multiple of its size. If a portion of the viewport does not
+ * represent system memory -- e.g. 3GB of memory requires a 4GB
+ * viewport -- we can map the outbound memory in or after 3GB and even
+ * though the viewport will overlap the outbound memory the controller
+ * will know to send outbound memory downstream and everything else
+ * upstream.
+ *
+ * For example:
+ *
+ * - The best-case scenario, memory up to 3GB, is to place the inbound
+ * region in the first 4GB of pcie-space, as some legacy devices can
+ * only address 32bits. We would also like to put the MSI under 4GB
+ * as well, since some devices require a 32bit MSI target address.
+ *
+ * - If the system memory is 4GB or larger we cannot start the inbound
+ * region at location 0 (since we have to allow some space for
+ * outbound memory @ 3GB). So instead it will start at the 1x
+ * multiple of its size
+ */
+ if (!*rc_bar2_size || *rc_bar2_offset % *rc_bar2_size ||
+ (*rc_bar2_offset < SZ_4G && *rc_bar2_offset > SZ_2G)) {
+ dev_err(dev, "Invalid rc_bar2_offset/size: size 0x%llx, off 0x%llx\n",
+ *rc_bar2_size, *rc_bar2_offset);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int brcm_pcie_setup(struct brcm_pcie *pcie)
+{
+ struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
+ u64 rc_bar2_offset, rc_bar2_size;
+ void __iomem *base = pcie->base;
+ struct device *dev = pcie->dev;
+ struct resource_entry *entry;
+ unsigned int scb_size_val;
+ bool ssc_good = false;
+ struct resource *res;
+ int num_out_wins = 0;
+ u16 nlw, cls, lnksta;
+ int i, ret;
+ u32 tmp;
+
+ /* Reset the bridge */
+ brcm_pcie_bridge_sw_init_set(pcie, 1);
+
+ usleep_range(100, 200);
+
+ /* Take the bridge out of reset */
+ brcm_pcie_bridge_sw_init_set(pcie, 0);
+
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
+ /* Wait for SerDes to be stable */
+ usleep_range(100, 200);
+
+ /* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
+ tmp = INSERT_FIELD(0, PCIE_MISC_MISC_CTRL, SCB_ACCESS_EN, 1);
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, CFG_READ_UR_MODE, 1);
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, MAX_BURST_SIZE,
+ BURST_SIZE_128);
+ bcm_writel(tmp, base + PCIE_MISC_MISC_CTRL);
+
+ ret = brcm_pcie_get_rc_bar2_size_and_offset(pcie, &rc_bar2_size,
+ &rc_bar2_offset);
+ if (ret)
+ return ret;
+
+ tmp = lower_32_bits(rc_bar2_offset);
+ tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
+ brcm_pcie_encode_ibar_size(rc_bar2_size));
+ bcm_writel(tmp, base + PCIE_MISC_RC_BAR2_CONFIG_LO);
+ bcm_writel(upper_32_bits(rc_bar2_offset),
+ base + PCIE_MISC_RC_BAR2_CONFIG_HI);
+
+ scb_size_val = rc_bar2_size ?
+ ilog2(rc_bar2_size) - 15 : 0xf; /* 0xf is 1GB */
+ WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB0_SIZE, scb_size_val);
+
+ /* disable the PCIe->GISB memory window (RC_BAR1) */
+ WR_FLD(base, PCIE_MISC_RC_BAR1_CONFIG_LO, SIZE, 0);
+
+ /* disable the PCIe->SCB memory window (RC_BAR3) */
+ WR_FLD(base, PCIE_MISC_RC_BAR3_CONFIG_LO, SIZE, 0);
+
+ /* clear any interrupts we find on boot */
+ bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + CLR);
+ (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + CLR);
+
+ /* Mask all interrupts since we are not handling any yet */
+ bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + MASK_SET);
+ (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + MASK_SET);
+
+ if (pcie->gen)
+ brcm_pcie_set_gen(base, pcie->gen);
+
+ /* Unassert the fundamental reset */
+ brcm_pcie_perst_set(pcie, 0);
+
+ /*
+ * Give the RC/EP time to wake up, before trying to configure RC.
+ * Intermittently check status for link-up, up to a total of 100ms.
+ */
+ for (i = 0; i < 100 && !brcm_pcie_link_up(pcie); i += 5)
+ msleep(5);
+
+ if (!brcm_pcie_link_up(pcie)) {
+ dev_info(dev, "link down\n");
+ return -ENODEV;
+ }
+
+ if (!brcm_pcie_rc_mode(pcie)) {
+ dev_err(dev, "PCIe misconfigured; is in EP mode\n");
+ return -EINVAL;
+ }
+
+ resource_list_for_each_entry(entry, &bridge->windows) {
+ res = entry->res;
+
+ if (resource_type(res) != IORESOURCE_MEM)
+ continue;
+
+ if (num_out_wins >= BRCM_NUM_PCIE_OUT_WINS) {
+ dev_err(pcie->dev, "too many outbound wins\n");
+ return -EINVAL;
+ }
+
+ brcm_pcie_set_outbound_win(pcie, num_out_wins, res->start,
+ res->start - entry->offset,
+ res->end - res->start + 1);
+ num_out_wins++;
+ }
+
+ /*
+ * For config space accesses on the RC, show the right class for
+ * a PCIe-PCIe bridge (the default setting is to be EP mode).
+ */
+ WR_FLD_RB(base, PCIE_RC_CFG_PRIV1_ID_VAL3, CLASS_CODE, 0x060400);
+
+ if (pcie->ssc) {
+ ret = brcm_pcie_set_ssc(base);
+ if (ret == 0)
+ ssc_good = true;
+ else
+ dev_err(dev, "failed attempt to enter ssc mode\n");
+ }
+
+ lnksta = bcm_readw(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKSTA);
+ cls = lnksta & PCI_EXP_LNKSTA_CLS;
+ nlw = (lnksta & PCI_EXP_LNKSTA_NLW) >> PCI_EXP_LNKSTA_NLW_SHIFT;
+ dev_info(dev, "link up, %s x%u %s\n",
+ PCIE_SPEED2STR(cls + PCI_SPEED_133MHz_PCIX_533),
+ nlw, ssc_good ? "(SSC)" : "(!SSC)");
+
+ /* PCIe->SCB endian mode for BAR */
+ /* field ENDIAN_MODE_BAR2 = DATA_ENDIAN */
+ WR_FLD_RB(base, PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1,
+ ENDIAN_MODE_BAR2, DATA_ENDIAN);
+
+ /*
+ * Refclk from RC should be gated with CLKREQ# input when ASPM L0s,L1
+ * is enabled => setting the CLKREQ_DEBUG_ENABLE field to 1.
+ */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, CLKREQ_DEBUG_ENABLE, 1);
+
+ return 0;
+}
+
+/* L23 is a low-power PCIe link state */
+static void brcm_pcie_enter_l23(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+ int l23, i;
+
+ /* assert request for L23 */
+ WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 1);
+
+ /* Wait up to 36 msec for L23 */
+ l23 = RD_FLD(base, PCIE_MISC_PCIE_STATUS, PCIE_LINK_IN_L23);
+ for (i = 0; i < 15 && !l23; i++) {
+ usleep_range(2000, 2400);
+ l23 = RD_FLD(base, PCIE_MISC_PCIE_STATUS, PCIE_LINK_IN_L23);
+ }
+
+ if (!l23)
+ dev_err(pcie->dev, "failed to enter low-power link state\n");
+}
+
+static void brcm_pcie_turn_off(struct brcm_pcie *pcie)
+{
+ void __iomem *base = pcie->base;
+
+ if (brcm_pcie_link_up(pcie))
+ brcm_pcie_enter_l23(pcie);
+ /* Assert fundamental reset */
+ brcm_pcie_perst_set(pcie, 1);
+ /* Deassert request for L23 in case it was asserted */
+ WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 0);
+ /* Turn off SerDes */
+ WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 1);
+ /* Shutdown PCIe bridge */
+ brcm_pcie_bridge_sw_init_set(pcie, 1);
+}
+
+static void __brcm_pcie_remove(struct brcm_pcie *pcie)
+{
+ brcm_pcie_turn_off(pcie);
+ clk_disable_unprepare(pcie->clk);
+ clk_put(pcie->clk);
+}
+
+static int brcm_pcie_remove(struct platform_device *pdev)
+{
+ struct brcm_pcie *pcie = platform_get_drvdata(pdev);
+
+ pci_stop_root_bus(pcie->root_bus);
+ pci_remove_root_bus(pcie->root_bus);
+ __brcm_pcie_remove(pcie);
+
+ return 0;
+}
+
+static const struct of_device_id brcm_pcie_match[] = {
+ { .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
+ {},
+};
+MODULE_DEVICE_TABLE(of, brcm_pcie_match);
+
+static int brcm_pcie_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ const struct pcie_cfg_data *data;
+ struct pci_host_bridge *bridge;
+ struct brcm_pcie *pcie;
+ struct pci_bus *child;
+ struct resource *res;
+ int ret;
+
+ bridge = devm_pci_alloc_host_bridge(&pdev->dev, sizeof(*pcie));
+ if (!bridge)
+ return -ENOMEM;
+
+ pcie = pci_host_bridge_priv(bridge);
+
+ data = of_device_get_match_data(&pdev->dev);
+ if (!data) {
+ dev_err(&pdev->dev, "failed to look up compatible string\n");
+ return -EINVAL;
+ }
+
+ pcie->reg_offsets = data->offsets;
+ pcie->reg_field_info = data->reg_field_info;
+ pcie->type = data->type;
+ pcie->np = np;
+ pcie->dev = &pdev->dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ pcie->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(pcie->base))
+ return PTR_ERR(pcie->base);
+
+ pcie->clk = devm_clk_get_optional(&pdev->dev, "sw_pcie");
+ if (IS_ERR(pcie->clk))
+ return PTR_ERR(pcie->clk);
+
+ ret = of_pci_get_max_link_speed(np);
+ pcie->gen = (ret < 0) ? 0 : ret;
+
+ pcie->ssc = of_property_read_bool(np, "brcm,enable-ssc");
+
+ ret = pci_parse_request_of_pci_ranges(pcie->dev, &bridge->windows,
+ &bridge->dma_ranges, NULL);
+ if (ret)
+ return ret;
+
+ ret = clk_prepare_enable(pcie->clk);
+ if (ret) {
+ dev_err(&pdev->dev, "could not enable clock\n");
+ return ret;
+ }
+
+ ret = brcm_pcie_setup(pcie);
+ if (ret)
+ goto fail;
+
+ bridge->dev.parent = &pdev->dev;
+ bridge->busnr = 0;
+ bridge->ops = &brcm_pcie_ops;
+ bridge->sysdata = pcie;
+ bridge->map_irq = of_irq_parse_and_map_pci;
+ bridge->swizzle_irq = pci_common_swizzle;
+
+ ret = pci_scan_root_bus_bridge(bridge);
+ if (ret < 0) {
+ dev_err(pcie->dev, "Scanning root bridge failed\n");
+ goto fail;
+ }
+
+ pci_assign_unassigned_bus_resources(bridge->bus);
+ list_for_each_entry(child, &bridge->bus->children, node)
+ pcie_bus_configure_settings(child);
+ pci_bus_add_devices(bridge->bus);
+ platform_set_drvdata(pdev, pcie);
+ pcie->root_bus = bridge->bus;
+
+ return 0;
+fail:
+ __brcm_pcie_remove(pcie);
+ return ret;
+}
+
+static struct platform_driver brcm_pcie_driver = {
+ .probe = brcm_pcie_probe,
+ .remove = brcm_pcie_remove,
+ .driver = {
+ .name = "brcm-pcie",
+ .of_match_table = brcm_pcie_match,
+ },
+};
+
+module_platform_driver(brcm_pcie_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("Broadcom STB PCIe RC driver");
+MODULE_AUTHOR("Broadcom");
--
2.24.0
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v2 5/6] PCI: brcmstb: add MSI capability
2019-11-12 15:59 [PATCH v2 0/6] Raspberry Pi 4 PCIe support Nicolas Saenz Julienne
` (3 preceding siblings ...)
2019-11-12 15:59 ` [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver Nicolas Saenz Julienne
@ 2019-11-12 15:59 ` Nicolas Saenz Julienne
2019-11-13 13:49 ` Marc Zyngier
2019-11-21 15:38 ` Andrew Murray
2019-11-12 15:59 ` [PATCH v2 6/6] MAINTAINERS: Add brcmstb PCIe controller Nicolas Saenz Julienne
2019-11-19 11:18 ` [PATCH v2 0/6] Raspberry Pi 4 PCIe support Andrew Murray
6 siblings, 2 replies; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-12 15:59 UTC (permalink / raw)
To: andrew.murray, maz, linux-kernel, Lorenzo Pieralisi,
Florian Fainelli, bcm-kernel-feedback-list, Eric Anholt,
Stefan Wahren
Cc: james.quinlan, mbrugger, phil, jeremy.linton,
Nicolas Saenz Julienne, Bjorn Helgaas, linux-pci,
linux-rpi-kernel, linux-arm-kernel
From: Jim Quinlan <james.quinlan@broadcom.com>
This commit adds MSI to the Broadcom STB PCIe host controller. It does
not add MSIX since that functionality is not in the HW. The MSI
controller is physically located within the PCIe block, however, there
is no reason why the MSI controller could not be moved elsewhere in
the future.
Since the internal Brcmstb MSI controller is intertwined with the PCIe
controller, it is not its own platform device but rather part of the
PCIe platform device.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
Co-developed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
Changes since v1:
- Move revision code and some registers to this patch
- Use PCIE_MSI_IRQ_DOMAIN in Kconfig
- Remove redundant register read from ISR
- Fail probe on MSI init error
- Get rid of msi_internal
- Use bitmap family of functions
- Use edge triggered setup
- Add comment regarding MultiMSI
- Simplify compose_msi_msg to avoid reg read
This is based on Jim's original submission[1] with some slight changes
regarding how pcie->msi_target_addr is decided.
[1] https://patchwork.kernel.org/patch/10605955/
drivers/pci/controller/Kconfig | 1 +
drivers/pci/controller/pcie-brcmstb.c | 326 +++++++++++++++++++++++++-
2 files changed, 326 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 486d4d570233..eb9d973ad8e5 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -285,6 +285,7 @@ config PCIE_BRCMSTB
bool "Broadcom Brcmstb PCIe host controller"
depends on ARCH_BCM2835 || COMPILE_TEST
depends on OF
+ depends on PCI_MSI_IRQ_DOMAIN
help
Say Y here to enable PCIe host controller support for
Broadcom STB based SoCs, like the Raspberry Pi 4.
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 8d81c5ab5979..35afd82107a7 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/* Copyright (C) 2009 - 2019 Broadcom */
+#include <linux/bitops.h>
#include <linux/clk.h>
#include <linux/compiler.h>
#include <linux/delay.h>
@@ -8,11 +9,13 @@
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/ioport.h>
+#include <linux/irqchip/chained_irq.h>
#include <linux/irqdomain.h>
#include <linux/kernel.h>
#include <linux/list.h>
#include <linux/log2.h>
#include <linux/module.h>
+#include <linux/msi.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/of_pci.h>
@@ -46,13 +49,18 @@
#define PCIE_MISC_RC_BAR2_CONFIG_LO 0x4034
#define PCIE_MISC_RC_BAR2_CONFIG_HI 0x4038
#define PCIE_MISC_RC_BAR3_CONFIG_LO 0x403c
+#define PCIE_MISC_MSI_BAR_CONFIG_LO 0x4044
+#define PCIE_MISC_MSI_BAR_CONFIG_HI 0x4048
+#define PCIE_MISC_MSI_DATA_CONFIG 0x404c
#define PCIE_MISC_PCIE_CTRL 0x4064
#define PCIE_MISC_PCIE_STATUS 0x4068
+#define PCIE_MISC_REVISION 0x406c
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT 0x4070
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI 0x4080
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI 0x4084
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
#define PCIE_INTR2_CPU_BASE 0x4300
+#define PCIE_MSI_INTR2_BASE 0x4500
/*
* Broadcom STB PCIe Register Field shift and mask info. The names are from the
@@ -87,6 +95,8 @@
#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_SHIFT 0x4
#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK 0x40
#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_SHIFT 0x6
+#define PCIE_MISC_REVISION_MAJMIN_MASK 0xffff
+#define PCIE_MISC_REVISION_MAJMIN_SHIFT 0
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_MASK 0xfff00000
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_SHIFT 0x14
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK 0xfff0
@@ -104,6 +114,11 @@
#define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0
#define BRCM_NUM_PCIE_OUT_WINS 0x4
+#define BRCM_INT_PCI_MSI_NR 32
+#define BRCM_PCIE_HW_REV_33 0x0303
+
+#define BRCM_MSI_TARGET_ADDR_LT_4GB 0x0fffffffcULL
+#define BRCM_MSI_TARGET_ADDR_GT_4GB 0xffffffffcULL
#define BURST_SIZE_128 0
@@ -182,6 +197,33 @@ struct brcm_window {
dma_addr_t size;
};
+struct brcm_msi {
+ struct device *dev;
+ void __iomem *base;
+ struct device_node *np;
+ struct irq_domain *msi_domain;
+ struct irq_domain *inner_domain;
+ struct mutex lock; /* guards the alloc/free operations */
+ u64 target_addr;
+ int irq;
+
+ /* intr_base is the base pointer for interrupt status/set/clr regs */
+ void __iomem *intr_base;
+
+ /* intr_legacy_mask indicates how many bits are MSI interrupts */
+ u32 intr_legacy_mask;
+
+ /*
+ * intr_legacy_offset indicates bit position of MSI_01. It is
+ * to map the register bit position to a hwirq that starts at 0.
+ */
+ u32 intr_legacy_offset;
+
+ /* used indicates which MSI interrupts have been alloc'd */
+ unsigned long used;
+ unsigned int rev;
+};
+
/* Internal PCIe Host Controller Information.*/
struct brcm_pcie {
struct device *dev;
@@ -191,7 +233,10 @@ struct brcm_pcie {
struct device_node *np;
bool ssc;
int gen;
+ u64 msi_target_addr;
struct brcm_window out_wins[BRCM_NUM_PCIE_OUT_WINS];
+ struct brcm_msi *msi;
+ unsigned int rev;
const int *reg_offsets;
const int *reg_field_info;
enum pcie_type type;
@@ -433,6 +478,259 @@ static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
LIMIT, tmp);
}
+static struct irq_chip brcm_msi_irq_chip = {
+ .name = "BRCM STB PCIe MSI",
+ .irq_ack = irq_chip_ack_parent,
+ .irq_mask = pci_msi_mask_irq,
+ .irq_unmask = pci_msi_unmask_irq,
+};
+
+static struct msi_domain_info brcm_msi_domain_info = {
+ /* TODO: Multi MSI is technically supported by the controller */
+ .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+ MSI_FLAG_PCI_MSIX),
+ .chip = &brcm_msi_irq_chip,
+};
+
+static void brcm_pcie_msi_isr(struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ unsigned long status, virq;
+ struct brcm_msi *msi;
+ u32 mask, bit, hwirq;
+ struct device *dev;
+
+ chained_irq_enter(chip, desc);
+ msi = irq_desc_get_handler_data(desc);
+ mask = msi->intr_legacy_mask;
+ dev = msi->dev;
+
+ status = bcm_readl(msi->intr_base + STATUS) & mask;
+ for_each_set_bit(bit, &status, BRCM_INT_PCI_MSI_NR) {
+
+ /* Account for legacy interrupt offset */
+ hwirq = bit - msi->intr_legacy_offset;
+ virq = irq_find_mapping(msi->inner_domain, hwirq);
+ if (virq)
+ generic_handle_irq(virq);
+ else
+ dev_dbg(dev, "unexpected MSI\n");
+ }
+ chained_irq_exit(chip, desc);
+}
+
+static void brcm_msi_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+ struct brcm_msi *msi = irq_data_get_irq_chip_data(data);
+
+ msg->address_lo = lower_32_bits(msi->target_addr);
+ msg->address_hi = upper_32_bits(msi->target_addr);
+ msg->data = 0x6540 | data->hwirq;
+}
+
+static int brcm_msi_set_affinity(struct irq_data *irq_data,
+ const struct cpumask *mask, bool force)
+{
+ return -EINVAL;
+}
+
+static void brcm_msi_ack_irq(struct irq_data *data)
+{
+ struct brcm_msi *msi = irq_data_get_irq_chip_data(data);
+ u32 bit = data->hwirq + msi->intr_legacy_offset;
+
+ bcm_writel(1 << bit, msi->intr_base + CLR);
+}
+
+
+static struct irq_chip brcm_msi_bottom_irq_chip = {
+ .name = "BRCM STB MSI",
+ .irq_compose_msi_msg = brcm_msi_compose_msi_msg,
+ .irq_set_affinity = brcm_msi_set_affinity,
+ .irq_ack = brcm_msi_ack_irq,
+};
+
+static int brcm_msi_alloc(struct brcm_msi *msi)
+{
+ int hwirq;
+
+ mutex_lock(&msi->lock);
+ hwirq = bitmap_find_free_region(&msi->used, BRCM_INT_PCI_MSI_NR, 0);
+ if (hwirq >= 0)
+ hwirq = hwirq - msi->intr_legacy_offset;
+ mutex_unlock(&msi->lock);
+
+ return hwirq;
+}
+
+static void brcm_msi_free(struct brcm_msi *msi, unsigned long hwirq)
+{
+ mutex_lock(&msi->lock);
+ bitmap_release_region(&msi->used, hwirq + msi->intr_legacy_offset, 0);
+ mutex_unlock(&msi->lock);
+}
+
+static int brcm_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs, void *args)
+{
+ struct brcm_msi *msi = domain->host_data;
+ int hwirq;
+
+ hwirq = brcm_msi_alloc(msi);
+
+ if (hwirq < 0)
+ return hwirq;
+
+ irq_domain_set_info(domain, virq, (irq_hw_number_t)hwirq,
+ &brcm_msi_bottom_irq_chip, domain->host_data,
+ handle_edge_irq, NULL, NULL);
+ return 0;
+}
+
+static void brcm_irq_domain_free(struct irq_domain *domain,
+ unsigned int virq, unsigned int nr_irqs)
+{
+ struct irq_data *d = irq_domain_get_irq_data(domain, virq);
+ struct brcm_msi *msi = irq_data_get_irq_chip_data(d);
+
+ brcm_msi_free(msi, d->hwirq);
+}
+
+static const struct irq_domain_ops msi_domain_ops = {
+ .alloc = brcm_irq_domain_alloc,
+ .free = brcm_irq_domain_free,
+};
+
+static int brcm_allocate_domains(struct brcm_msi *msi)
+{
+ struct fwnode_handle *fwnode = of_node_to_fwnode(msi->np);
+ struct device *dev = msi->dev;
+
+ msi->inner_domain = irq_domain_add_linear(NULL, BRCM_INT_PCI_MSI_NR,
+ &msi_domain_ops, msi);
+ if (!msi->inner_domain) {
+ dev_err(dev, "failed to create IRQ domain\n");
+ return -ENOMEM;
+ }
+
+ msi->msi_domain = pci_msi_create_irq_domain(fwnode,
+ &brcm_msi_domain_info,
+ msi->inner_domain);
+ if (!msi->msi_domain) {
+ dev_err(dev, "failed to create MSI domain\n");
+ irq_domain_remove(msi->inner_domain);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static void brcm_free_domains(struct brcm_msi *msi)
+{
+ irq_domain_remove(msi->msi_domain);
+ irq_domain_remove(msi->inner_domain);
+}
+
+static void brcm_msi_remove(struct brcm_pcie *pcie)
+{
+ struct brcm_msi *msi = pcie->msi;
+
+ if (!msi)
+ return;
+ irq_set_chained_handler(msi->irq, NULL);
+ irq_set_handler_data(msi->irq, NULL);
+ brcm_free_domains(msi);
+}
+
+static void brcm_msi_set_regs(struct brcm_msi *msi)
+{
+ u32 data_val, msi_lo, msi_hi;
+
+ if (msi->rev >= BRCM_PCIE_HW_REV_33) {
+ /*
+ * ffe0 -- least sig 5 bits are 0 indicating 32 msgs
+ * 6540 -- this is our arbitrary unique data value
+ */
+ data_val = 0xffe06540;
+ } else {
+ /*
+ * fff8 -- least sig 3 bits are 0 indicating 8 msgs
+ * 6540 -- this is our arbitrary unique data value
+ */
+ data_val = 0xfff86540;
+ }
+
+ /* Unmaks MSIs */
+ bcm_writel(0xffffffff & msi->intr_legacy_mask,
+ msi->intr_base + MASK_CLR);
+
+ msi_lo = lower_32_bits(msi->target_addr);
+ msi_hi = upper_32_bits(msi->target_addr);
+ /*
+ * The 0 bit of PCIE_MISC_MSI_BAR_CONFIG_LO is repurposed to MSI
+ * enable, which we set to 1.
+ */
+ bcm_writel(msi_lo | 1, msi->base + PCIE_MISC_MSI_BAR_CONFIG_LO);
+ bcm_writel(msi_hi, msi->base + PCIE_MISC_MSI_BAR_CONFIG_HI);
+ bcm_writel(data_val, msi->base + PCIE_MISC_MSI_DATA_CONFIG);
+}
+
+static int brcm_pcie_enable_msi(struct brcm_pcie *pcie)
+{
+ struct brcm_msi *msi;
+ int irq, ret;
+ struct device *dev = pcie->dev;
+
+ irq = irq_of_parse_and_map(dev->of_node, 1);
+ if (irq <= 0) {
+ dev_err(dev, "cannot map msi intr\n");
+ return -ENODEV;
+ }
+
+ msi = devm_kzalloc(dev, sizeof(struct brcm_msi), GFP_KERNEL);
+ if (!msi)
+ return -ENOMEM;
+
+ msi->dev = dev;
+ msi->base = pcie->base;
+ msi->rev = pcie->rev;
+ msi->np = pcie->np;
+ msi->target_addr = pcie->msi_target_addr;
+ msi->irq = irq;
+
+ ret = brcm_allocate_domains(msi);
+ if (ret)
+ return ret;
+
+ irq_set_chained_handler_and_data(msi->irq, brcm_pcie_msi_isr, msi);
+
+ if (msi->rev >= BRCM_PCIE_HW_REV_33) {
+ msi->intr_base = msi->base + PCIE_MSI_INTR2_BASE;
+ /*
+ * This version of PCIe hw has only 32 intr bits
+ * starting at bit position 0.
+ */
+ msi->intr_legacy_mask = 0xffffffff;
+ msi->intr_legacy_offset = 0x0;
+ msi->used = 0x0;
+
+ } else {
+ msi->intr_base = msi->base + PCIE_INTR2_CPU_BASE;
+ /*
+ * This version of PCIe hw has only 8 intr bits starting
+ * at bit position 24.
+ */
+ msi->intr_legacy_mask = 0xff000000;
+ msi->intr_legacy_offset = 24;
+ msi->used = 0x00ffffff;
+ }
+
+ brcm_msi_set_regs(msi);
+ pcie->msi = msi;
+
+ return 0;
+}
+
/* Configuration space read/write support */
static int brcm_pcie_cfg_index(int busnr, int devfn, int reg)
{
@@ -584,6 +882,10 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
/* Wait for SerDes to be stable */
usleep_range(100, 200);
+ /* Grab the PCIe hw revision number */
+ tmp = bcm_readl(base + PCIE_MISC_REVISION);
+ pcie->rev = EXTRACT_FIELD(tmp, PCIE_MISC_REVISION, MAJMIN);
+
/* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
tmp = INSERT_FIELD(0, PCIE_MISC_MISC_CTRL, SCB_ACCESS_EN, 1);
tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, CFG_READ_UR_MODE, 1);
@@ -596,6 +898,18 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
if (ret)
return ret;
+ /*
+ * We ideally want the MSI target address to be located in the 32bit
+ * addressable memory area. Some devices might depend on it. This is
+ * possible either when the inbound window is located above the lower
+ * 4GB or when the inbound and outbound areas fit in the lower 4GB of
+ * memory.
+ */
+ if (rc_bar2_offset >= SZ_4G || (rc_bar2_size + rc_bar2_offset) <= SZ_4G)
+ pcie->msi_target_addr = BRCM_MSI_TARGET_ADDR_LT_4GB;
+ else
+ pcie->msi_target_addr = BRCM_MSI_TARGET_ADDR_GT_4GB;
+
tmp = lower_32_bits(rc_bar2_offset);
tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
brcm_pcie_encode_ibar_size(rc_bar2_size));
@@ -734,6 +1048,7 @@ static void brcm_pcie_turn_off(struct brcm_pcie *pcie)
static void __brcm_pcie_remove(struct brcm_pcie *pcie)
{
+ brcm_msi_remove(pcie);
brcm_pcie_turn_off(pcie);
clk_disable_unprepare(pcie->clk);
clk_put(pcie->clk);
@@ -758,7 +1073,7 @@ MODULE_DEVICE_TABLE(of, brcm_pcie_match);
static int brcm_pcie_probe(struct platform_device *pdev)
{
- struct device_node *np = pdev->dev.of_node;
+ struct device_node *np = pdev->dev.of_node, *msi_np;
const struct pcie_cfg_data *data;
struct pci_host_bridge *bridge;
struct brcm_pcie *pcie;
@@ -813,6 +1128,15 @@ static int brcm_pcie_probe(struct platform_device *pdev)
if (ret)
goto fail;
+ msi_np = of_parse_phandle(pcie->np, "msi-parent", 0);
+ if (pci_msi_enabled() && msi_np == pcie->np) {
+ ret = brcm_pcie_enable_msi(pcie);
+ if (ret) {
+ dev_err(pcie->dev, "probe of internal MSI failed");
+ goto fail;
+ }
+ }
+
bridge->dev.parent = &pdev->dev;
bridge->busnr = 0;
bridge->ops = &brcm_pcie_ops;
--
2.24.0
^ permalink raw reply related [flat|nested] 36+ messages in thread
* [PATCH v2 6/6] MAINTAINERS: Add brcmstb PCIe controller
2019-11-12 15:59 [PATCH v2 0/6] Raspberry Pi 4 PCIe support Nicolas Saenz Julienne
` (4 preceding siblings ...)
2019-11-12 15:59 ` [PATCH v2 5/6] PCI: brcmstb: add MSI capability Nicolas Saenz Julienne
@ 2019-11-12 15:59 ` Nicolas Saenz Julienne
2019-11-19 11:18 ` [PATCH v2 0/6] Raspberry Pi 4 PCIe support Andrew Murray
6 siblings, 0 replies; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-12 15:59 UTC (permalink / raw)
To: andrew.murray, maz, linux-kernel
Cc: james.quinlan, mbrugger, f.fainelli, phil, wahrenst,
jeremy.linton, Nicolas Saenz Julienne
The controller serves both the Raspberry Pi 4 (bcm2711) and brcmstb
platforms.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
MAINTAINERS | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3f7f8cdbc471..96d0feed45e2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3223,6 +3223,8 @@ S: Maintained
N: bcm2711
N: bcm2835
F: drivers/staging/vc04_services
+F: Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
+F: drivers/pci/controller/pcie-brcmstb.c
BROADCOM BCM47XX MIPS ARCHITECTURE
M: Hauke Mehrtens <hauke@hauke-m.de>
@@ -3278,6 +3280,8 @@ F: drivers/bus/brcmstb_gisb.c
F: arch/arm/mm/cache-b15-rac.c
F: arch/arm/include/asm/hardware/cache-b15-rac.h
N: brcmstb
+F: Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
+F: drivers/pci/controller/pcie-brcmstb.c
BROADCOM BMIPS CPUFREQ DRIVER
M: Markus Mayer <mmayer@broadcom.com>
--
2.24.0
^ permalink raw reply related [flat|nested] 36+ messages in thread
* Re: [PATCH v2 5/6] PCI: brcmstb: add MSI capability
2019-11-12 15:59 ` [PATCH v2 5/6] PCI: brcmstb: add MSI capability Nicolas Saenz Julienne
@ 2019-11-13 13:49 ` Marc Zyngier
2019-11-21 15:38 ` Andrew Murray
1 sibling, 0 replies; 36+ messages in thread
From: Marc Zyngier @ 2019-11-13 13:49 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: andrew.murray, linux-kernel, Lorenzo Pieralisi, Florian Fainelli,
bcm-kernel-feedback-list, Eric Anholt, Stefan Wahren,
james.quinlan, mbrugger, phil, jeremy.linton, Bjorn Helgaas,
linux-pci, linux-rpi-kernel, linux-arm-kernel
On 2019-11-12 17:08, Nicolas Saenz Julienne wrote:
> From: Jim Quinlan <james.quinlan@broadcom.com>
>
> This commit adds MSI to the Broadcom STB PCIe host controller. It
> does
> not add MSIX since that functionality is not in the HW. The MSI
> controller is physically located within the PCIe block, however,
> there
> is no reason why the MSI controller could not be moved elsewhere in
> the future.
>
> Since the internal Brcmstb MSI controller is intertwined with the
> PCIe
> controller, it is not its own platform device but rather part of the
> PCIe platform device.
>
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> Co-developed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Marc Zyngier <maz@kernel.org>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: PCI: Add bindings for brcmstb's PCIe device
2019-11-12 15:59 ` [PATCH v2 2/6] dt-bindings: PCI: Add bindings for brcmstb's PCIe device Nicolas Saenz Julienne
@ 2019-11-18 21:23 ` Rob Herring
2019-11-19 9:35 ` Nicolas Saenz Julienne
2019-11-19 11:17 ` Andrew Murray
1 sibling, 1 reply; 36+ messages in thread
From: Rob Herring @ 2019-11-18 21:23 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: andrew.murray, maz, linux-kernel, Eric Anholt, Stefan Wahren,
Florian Fainelli, bcm-kernel-feedback-list, Bjorn Helgaas,
james.quinlan, mbrugger, phil, jeremy.linton, Mark Rutland,
linux-arm-kernel, linux-rpi-kernel, linux-pci, devicetree
On Tue, Nov 12, 2019 at 04:59:21PM +0100, Nicolas Saenz Julienne wrote:
> From: Jim Quinlan <james.quinlan@broadcom.com>
>
> The DT bindings description of the brcmstb PCIe device is described.
> This node can only be used for now on the Raspberry Pi 4.
>
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> Co-developed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
>
> ---
>
> Changes since v1:
> - Fix commit Subject
> - Remove linux,pci-domain
>
> This was based on Jim's original submission[1], converted to yaml and
> adapted to the RPi4 case.
>
> [1] https://patchwork.kernel.org/patch/10605937/
>
> .../bindings/pci/brcm,stb-pcie.yaml | 110 ++++++++++++++++++
> 1 file changed, 110 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
>
> diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> new file mode 100644
> index 000000000000..4cbb18821300
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> @@ -0,0 +1,110 @@
> +# SPDX-License-Identifier: GPL-2.0
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/brcm,stb-pcie.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Brcmstb PCIe Host Controller Device Tree Bindings
> +
> +maintainers:
> + - Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> +
I added a common PCI schema to dt-schema. You can reference it here:
allOf:
- $ref: /schemas/pci/pci-bus.yaml#
> +properties:
> + compatible:
> + const: brcm,bcm2711-pcie # The Raspberry Pi 4
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + minItems: 1
> + maxItems: 2
> + items:
> + - description: PCIe host controller
> + - description: builtin MSI controller
> +
> + interrupt-names:
> + minItems: 1
> + maxItems: 2
> + items:
> + - const: pcie
> + - const: msi
> +
> + "#address-cells":
> + const: 3
> +
> + "#size-cells":
> + const: 2
> +
> + "#interrupt-cells":
> + const: 1
> +
> + interrupt-map-mask: true
> +
> + interrupt-map: true
Drop all these as the pci-bus.yaml will cover them.
> +
> + ranges: true
Do you know many entries, if not, you can drop it too?
> +
> + dma-ranges: true
Do you know many entries, if not, you can drop it too?
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + items:
> + - const: sw_pcie
> +
> + msi-controller:
> + description: Identifies the node as an MSI controller.
> + type: boolean
> +
> + msi-parent:
> + description: MSI controller the device is capable of using.
> + $ref: /schemas/types.yaml#/definitions/phandle
Assume these 2 have a type defined.
> +
> + brcm,enable-ssc:
> + description: Indicates usage of spread-spectrum clocking.
> + type: boolean
> +
> +required:
> + - compatible
> + - reg
> + - "#address-cells"
> + - "#size-cells"
> + - "#interrupt-cells"
> + - interrupt-map-mask
> + - interrupt-map
> + - ranges
> + - dma-ranges
You can drop ranges, #address-cells and #size-cells as they are required
in pci-bus.yaml.
Shouldn't interrupts, interrupt-names, and msi-controller all be
required?
> +
> +additionalProperties: false
This won't work having the commmon binding, but
'unevaluatedProperties: false' will (eventually when json-schema draft8
is supported).
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + scb {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + pcie0: pcie@7d500000 {
> + compatible = "brcm,bcm2711-pcie";
> + reg = <0x0 0x7d500000 0x9310>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "pcie", "msi";
> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> + interrupt-map = <0 0 0 1 &gicv2 GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH
> + 0 0 0 2 &gicv2 GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH
> + 0 0 0 3 &gicv2 GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH
> + 0 0 0 4 &gicv2 GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
Bracket each entry. The schema is making this stricter.
Rob
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: PCI: Add bindings for brcmstb's PCIe device
2019-11-18 21:23 ` Rob Herring
@ 2019-11-19 9:35 ` Nicolas Saenz Julienne
0 siblings, 0 replies; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-19 9:35 UTC (permalink / raw)
To: Rob Herring
Cc: andrew.murray, maz, linux-kernel, Eric Anholt, Stefan Wahren,
Florian Fainelli, bcm-kernel-feedback-list, Bjorn Helgaas,
james.quinlan, mbrugger, phil, jeremy.linton, Mark Rutland,
linux-arm-kernel, linux-rpi-kernel, linux-pci, devicetree
[-- Attachment #1: Type: text/plain, Size: 5583 bytes --]
Hi Rob, thanks for the review.
On Mon, 2019-11-18 at 15:23 -0600, Rob Herring wrote:
> On Tue, Nov 12, 2019 at 04:59:21PM +0100, Nicolas Saenz Julienne wrote:
> > From: Jim Quinlan <james.quinlan@broadcom.com>
> >
> > The DT bindings description of the brcmstb PCIe device is described.
> > This node can only be used for now on the Raspberry Pi 4.
> >
> > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > Co-developed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> >
> > ---
> >
> > Changes since v1:
> > - Fix commit Subject
> > - Remove linux,pci-domain
> >
> > This was based on Jim's original submission[1], converted to yaml and
> > adapted to the RPi4 case.
> >
> > [1] https://patchwork.kernel.org/patch/10605937/
> >
> > .../bindings/pci/brcm,stb-pcie.yaml | 110 ++++++++++++++++++
> > 1 file changed, 110 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > new file mode 100644
> > index 000000000000..4cbb18821300
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > @@ -0,0 +1,110 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pci/brcm,stb-pcie.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Brcmstb PCIe Host Controller Device Tree Bindings
> > +
> > +maintainers:
> > + - Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > +
>
> I added a common PCI schema to dt-schema. You can reference it here:
>
> allOf:
> - $ref: /schemas/pci/pci-bus.yaml#
Thanks!
> > +properties:
> > + compatible:
> > + const: brcm,bcm2711-pcie # The Raspberry Pi 4
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + interrupts:
> > + minItems: 1
> > + maxItems: 2
> > + items:
> > + - description: PCIe host controller
> > + - description: builtin MSI controller
> > +
> > + interrupt-names:
> > + minItems: 1
> > + maxItems: 2
> > + items:
> > + - const: pcie
> > + - const: msi
> > +
> > + "#address-cells":
> > + const: 3
> > +
> > + "#size-cells":
> > + const: 2
> > +
> > + "#interrupt-cells":
> > + const: 1
> > +
> > + interrupt-map-mask: true
> > +
> > + interrupt-map: true
>
> Drop all these as the pci-bus.yaml will cover them.
OK
> > +
> > + ranges: true
>
> Do you know many entries, if not, you can drop it too?
As this is only aimed at the RPi4's controller we know. Only one for now, same
for dma-ranges.
> > +
> > + dma-ranges: true
>
> Do you know many entries, if not, you can drop it too?
>
> > +
> > + clocks:
> > + maxItems: 1
> > +
> > + clock-names:
> > + items:
> > + - const: sw_pcie
> > +
> > + msi-controller:
> > + description: Identifies the node as an MSI controller.
> > + type: boolean
> > +
> > + msi-parent:
> > + description: MSI controller the device is capable of using.
> > + $ref: /schemas/types.yaml#/definitions/phandle
>
> Assume these 2 have a type defined.
Ok
> > +
> > + brcm,enable-ssc:
> > + description: Indicates usage of spread-spectrum clocking.
> > + type: boolean
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - "#address-cells"
> > + - "#size-cells"
> > + - "#interrupt-cells"
> > + - interrupt-map-mask
> > + - interrupt-map
> > + - ranges
> > + - dma-ranges
>
> You can drop ranges, #address-cells and #size-cells as they are required
> in pci-bus.yaml.
>
> Shouldn't interrupts, interrupt-names, and msi-controller all be
> required?
Agree, I've have doubts with msi-controller, but I guess the HW is still a
msi-controller regardless of whether you use it so it reasonable to require it.
> > +
> > +additionalProperties: false
>
> This won't work having the commmon binding, but
> 'unevaluatedProperties: false' will (eventually when json-schema draft8
> is supported).
I'll change it.
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > + scb {
> > + #address-cells = <2>;
> > + #size-cells = <1>;
> > + pcie0: pcie@7d500000 {
> > + compatible = "brcm,bcm2711-pcie";
> > + reg = <0x0 0x7d500000 0x9310>;
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > + #interrupt-cells = <1>;
> > + interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
> > + interrupt-names = "pcie", "msi";
> > + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> > + interrupt-map = <0 0 0 1 &gicv2 GIC_SPI 143
> > IRQ_TYPE_LEVEL_HIGH
> > + 0 0 0 2 &gicv2 GIC_SPI 144
> > IRQ_TYPE_LEVEL_HIGH
> > + 0 0 0 3 &gicv2 GIC_SPI 145
> > IRQ_TYPE_LEVEL_HIGH
> > + 0 0 0 4 &gicv2 GIC_SPI 146
> > IRQ_TYPE_LEVEL_HIGH>;
>
> Bracket each entry. The schema is making this stricter.
Noted.
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 1/6] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions
2019-11-12 15:59 ` [PATCH v2 1/6] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions Nicolas Saenz Julienne
@ 2019-11-19 11:13 ` Andrew Murray
2019-11-19 11:30 ` Nicolas Saenz Julienne
0 siblings, 1 reply; 36+ messages in thread
From: Andrew Murray @ 2019-11-19 11:13 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: maz, linux-kernel, Tariq Toukan, Tom Joseph, Lorenzo Pieralisi,
Shawn Lin, Heiko Stuebner, Christoph Hellwig, Marek Szyprowski,
Robin Murphy, james.quinlan, mbrugger, f.fainelli, phil,
wahrenst, jeremy.linton, David S. Miller, Bjorn Helgaas, netdev,
linux-rdma, linux-pci, linux-rockchip, linux-arm-kernel, iommu
On Tue, Nov 12, 2019 at 04:59:20PM +0100, Nicolas Saenz Julienne wrote:
> Some users need to make sure their rounding function accepts and returns
> 64bit long variables regardless of the architecture. Sadly
> roundup/rounddown_pow_two() takes and returns unsigned longs. Create a
> new generic 64bit variant of the function and cleanup rougue custom
> implementations.
>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_clock.c | 3 +-
> drivers/pci/controller/pcie-cadence-ep.c | 7 +--
> drivers/pci/controller/pcie-cadence.c | 7 +--
> drivers/pci/controller/pcie-rockchip-ep.c | 9 ++--
Thanks for making this change. See comments inline...
> include/linux/log2.h | 52 +++++++++++++++++++
> kernel/dma/direct.c | 3 +-
> 6 files changed, 63 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_clock.c b/drivers/net/ethernet/mellanox/mlx4/en_clock.c
> index 024788549c25..027bd72505e2 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_clock.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_clock.c
> @@ -33,6 +33,7 @@
>
> #include <linux/mlx4/device.h>
> #include <linux/clocksource.h>
> +#include <linux/log2.h>
>
> #include "mlx4_en.h"
>
> @@ -252,7 +253,7 @@ static u32 freq_to_shift(u16 freq)
> {
> u32 freq_khz = freq * 1000;
> u64 max_val_cycles = freq_khz * 1000 * MLX4_EN_WRAP_AROUND_SEC;
> - u64 max_val_cycles_rounded = 1ULL << fls64(max_val_cycles - 1);
> + u64 max_val_cycles_rounded = roundup_pow_of_two64(max_val_cycles);
> /* calculate max possible multiplier in order to fit in 64bit */
> u64 max_mul = div64_u64(ULLONG_MAX, max_val_cycles_rounded);
>
> diff --git a/drivers/pci/controller/pcie-cadence-ep.c b/drivers/pci/controller/pcie-cadence-ep.c
> index def7820cb824..26ff424b16f5 100644
> --- a/drivers/pci/controller/pcie-cadence-ep.c
> +++ b/drivers/pci/controller/pcie-cadence-ep.c
> @@ -10,6 +10,7 @@
> #include <linux/platform_device.h>
> #include <linux/pm_runtime.h>
> #include <linux/sizes.h>
> +#include <linux/log2.h>
>
> #include "pcie-cadence.h"
>
> @@ -90,11 +91,7 @@ static int cdns_pcie_ep_set_bar(struct pci_epc *epc, u8 fn,
>
> /* BAR size is 2^(aperture + 7) */
> sz = max_t(size_t, epf_bar->size, CDNS_PCIE_EP_MIN_APERTURE);
> - /*
> - * roundup_pow_of_two() returns an unsigned long, which is not suited
> - * for 64bit values.
> - */
> - sz = 1ULL << fls64(sz - 1);
> + sz = roundup_pow_of_two64(sz);
> aperture = ilog2(sz) - 7; /* 128B -> 0, 256B -> 1, 512B -> 2, ... */
>
> if ((flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
> diff --git a/drivers/pci/controller/pcie-cadence.c b/drivers/pci/controller/pcie-cadence.c
> index cd795f6fc1e2..b2278e6b955c 100644
> --- a/drivers/pci/controller/pcie-cadence.c
> +++ b/drivers/pci/controller/pcie-cadence.c
> @@ -4,6 +4,7 @@
> // Author: Cyrille Pitchen <cyrille.pitchen@free-electrons.com>
>
> #include <linux/kernel.h>
> +#include <linux/log2.h>
>
> #include "pcie-cadence.h"
>
> @@ -11,11 +12,7 @@ void cdns_pcie_set_outbound_region(struct cdns_pcie *pcie, u8 fn,
> u32 r, bool is_io,
> u64 cpu_addr, u64 pci_addr, size_t size)
> {
> - /*
> - * roundup_pow_of_two() returns an unsigned long, which is not suited
> - * for 64bit values.
> - */
> - u64 sz = 1ULL << fls64(size - 1);
> + u64 sz = roundup_pow_of_two64(size);
> int nbits = ilog2(sz);
> u32 addr0, addr1, desc0, desc1;
>
> diff --git a/drivers/pci/controller/pcie-rockchip-ep.c b/drivers/pci/controller/pcie-rockchip-ep.c
> index d743b0a48988..ed50aaf27784 100644
> --- a/drivers/pci/controller/pcie-rockchip-ep.c
> +++ b/drivers/pci/controller/pcie-rockchip-ep.c
> @@ -16,6 +16,7 @@
> #include <linux/platform_device.h>
> #include <linux/pci-epf.h>
> #include <linux/sizes.h>
> +#include <linux/log2.h>
>
> #include "pcie-rockchip.h"
>
> @@ -70,7 +71,7 @@ static void rockchip_pcie_prog_ep_ob_atu(struct rockchip_pcie *rockchip, u8 fn,
> u32 r, u32 type, u64 cpu_addr,
> u64 pci_addr, size_t size)
> {
> - u64 sz = 1ULL << fls64(size - 1);
> + u64 sz = roundup_pow_of_two64(size);
> int num_pass_bits = ilog2(sz);
> u32 addr0, addr1, desc0, desc1;
> bool is_nor_msg = (type == AXI_WRAPPER_NOR_MSG);
> @@ -172,11 +173,7 @@ static int rockchip_pcie_ep_set_bar(struct pci_epc *epc, u8 fn,
> /* BAR size is 2^(aperture + 7) */
> sz = max_t(size_t, epf_bar->size, MIN_EP_APERTURE);
>
> - /*
> - * roundup_pow_of_two() returns an unsigned long, which is not suited
> - * for 64bit values.
> - */
> - sz = 1ULL << fls64(sz - 1);
> + sz = roundup_pow_of_two64(sz);
> aperture = ilog2(sz) - 7; /* 128B -> 0, 256B -> 1, 512B -> 2, ... */
>
> if ((flags & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_IO) {
> diff --git a/include/linux/log2.h b/include/linux/log2.h
> index 83a4a3ca3e8a..db12d92ab6eb 100644
> --- a/include/linux/log2.h
> +++ b/include/linux/log2.h
> @@ -67,6 +67,24 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
> return 1UL << (fls_long(n) - 1);
> }
>
> +/**
> + * __roundup_pow_of_two64() - round 64bit value up to nearest power of two
> + * @n: value to round up
> + */
> +static inline __attribute__((const)) __u64 __roundup_pow_of_two64(__u64 n)
To be consistent with other functions in the same file (__ilog_u64) you may
want to rename this to __roundup_pow_of_two_u64.
Also do you know why u64 is used in some places and __u64 in others?
> +{
> + return 1UL << fls64(n - 1);
Does this need to be (and for the others):
return 1ULL << fls64(n - 1);
Notice that the PCI drivers you convert, all use 1ULL.
Thanks,
Andrew Murray
> +}
> +
> +/**
> + * __rounddown_pow_of_two64() - round 64bit value down to nearest power of two
> + * @n: value to round down
> + */
> +static inline __attribute__((const)) __u64 __rounddown_pow_of_two64(__u64 n)
> +{
> + return 1UL << (fls64(n) - 1);
> +}
> +
> /**
> * const_ilog2 - log base 2 of 32-bit or a 64-bit constant unsigned value
> * @n: parameter
> @@ -194,6 +212,40 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
> __rounddown_pow_of_two(n) \
> )
>
> +/**
> + * roundup_pow_of_two64 - round the given 64bit value up to nearest power of
> + * two
> + * @n: parameter
> + *
> + * round the given value up to the nearest power of two
> + * - the result is undefined when n == 0
> + * - this can be used to initialise global variables from constant data
> + */
> +#define roundup_pow_of_two64(n) \
> +( \
> + __builtin_constant_p(n) ? ( \
> + (n == 1) ? 1 : \
> + (1UL << (ilog2((n) - 1) + 1)) \
> + ) : \
> + __roundup_pow_of_two64(n) \
> +)
> +
> +/**
> + * rounddown_pow_of_two64 - round the given 64bit value down to nearest power
> + * of two
> + * @n: parameter
> + *
> + * round the given value down to the nearest power of two
> + * - the result is undefined when n == 0
> + * - this can be used to initialise global variables from constant data
> + */
> +#define rounddown_pow_of_two64(n) \
> +( \
> + __builtin_constant_p(n) ? ( \
> + (1UL << ilog2(n))) : \
> + __rounddown_pow_of_two64(n) \
> +)
> +
> static inline __attribute_const__
> int __order_base_2(unsigned long n)
> {
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index b9e1744999d9..a419530abd3e 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -15,6 +15,7 @@
> #include <linux/vmalloc.h>
> #include <linux/set_memory.h>
> #include <linux/swiotlb.h>
> +#include <linux/log2.h>
>
> /*
> * Most architectures use ZONE_DMA for the first 16 Megabytes, but some use it
> @@ -53,7 +54,7 @@ u64 dma_direct_get_required_mask(struct device *dev)
> {
> u64 max_dma = phys_to_dma_direct(dev, (max_pfn - 1) << PAGE_SHIFT);
>
> - return (1ULL << (fls64(max_dma) - 1)) * 2 - 1;
> + return rounddown_pow_of_two64(max_dma) * 2 - 1;
> }
>
> static gfp_t __dma_direct_optimal_gfp_mask(struct device *dev, u64 dma_mask,
> --
> 2.24.0
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: PCI: Add bindings for brcmstb's PCIe device
2019-11-12 15:59 ` [PATCH v2 2/6] dt-bindings: PCI: Add bindings for brcmstb's PCIe device Nicolas Saenz Julienne
2019-11-18 21:23 ` Rob Herring
@ 2019-11-19 11:17 ` Andrew Murray
2019-11-19 11:28 ` Nicolas Saenz Julienne
1 sibling, 1 reply; 36+ messages in thread
From: Andrew Murray @ 2019-11-19 11:17 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: maz, linux-kernel, Eric Anholt, Stefan Wahren, Florian Fainelli,
bcm-kernel-feedback-list, Bjorn Helgaas, james.quinlan, mbrugger,
phil, jeremy.linton, Rob Herring, Mark Rutland, linux-arm-kernel,
linux-rpi-kernel, linux-pci, devicetree
On Tue, Nov 12, 2019 at 04:59:21PM +0100, Nicolas Saenz Julienne wrote:
> From: Jim Quinlan <james.quinlan@broadcom.com>
>
> The DT bindings description of the brcmstb PCIe device is described.
> This node can only be used for now on the Raspberry Pi 4.
>
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> Co-developed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
>
> ---
>
> Changes since v1:
> - Fix commit Subject
> - Remove linux,pci-domain
>
> This was based on Jim's original submission[1], converted to yaml and
> adapted to the RPi4 case.
>
> [1] https://patchwork.kernel.org/patch/10605937/
>
> .../bindings/pci/brcm,stb-pcie.yaml | 110 ++++++++++++++++++
> 1 file changed, 110 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
>
> diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> new file mode 100644
> index 000000000000..4cbb18821300
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> @@ -0,0 +1,110 @@
> +# SPDX-License-Identifier: GPL-2.0
I think in the last revision Rob asked you to change the license to
the following:
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Thanks,
Andrew Murray
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/brcm,stb-pcie.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Brcmstb PCIe Host Controller Device Tree Bindings
> +
> +maintainers:
> + - Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> +
> +properties:
> + compatible:
> + const: brcm,bcm2711-pcie # The Raspberry Pi 4
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + minItems: 1
> + maxItems: 2
> + items:
> + - description: PCIe host controller
> + - description: builtin MSI controller
> +
> + interrupt-names:
> + minItems: 1
> + maxItems: 2
> + items:
> + - const: pcie
> + - const: msi
> +
> + "#address-cells":
> + const: 3
> +
> + "#size-cells":
> + const: 2
> +
> + "#interrupt-cells":
> + const: 1
> +
> + interrupt-map-mask: true
> +
> + interrupt-map: true
> +
> + ranges: true
> +
> + dma-ranges: true
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + items:
> + - const: sw_pcie
> +
> + msi-controller:
> + description: Identifies the node as an MSI controller.
> + type: boolean
> +
> + msi-parent:
> + description: MSI controller the device is capable of using.
> + $ref: /schemas/types.yaml#/definitions/phandle
> +
> + brcm,enable-ssc:
> + description: Indicates usage of spread-spectrum clocking.
> + type: boolean
> +
> +required:
> + - compatible
> + - reg
> + - "#address-cells"
> + - "#size-cells"
> + - "#interrupt-cells"
> + - interrupt-map-mask
> + - interrupt-map
> + - ranges
> + - dma-ranges
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + scb {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + pcie0: pcie@7d500000 {
> + compatible = "brcm,bcm2711-pcie";
> + reg = <0x0 0x7d500000 0x9310>;
> + #address-cells = <3>;
> + #size-cells = <2>;
> + #interrupt-cells = <1>;
> + interrupts = <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "pcie", "msi";
> + interrupt-map-mask = <0x0 0x0 0x0 0x7>;
> + interrupt-map = <0 0 0 1 &gicv2 GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH
> + 0 0 0 2 &gicv2 GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH
> + 0 0 0 3 &gicv2 GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH
> + 0 0 0 4 &gicv2 GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>;
> + msi-parent = <&pcie0>;
> + msi-controller;
> + ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>;
> + dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>;
> + brcm,enable-ssc;
> + };
> + };
> --
> 2.24.0
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 0/6] Raspberry Pi 4 PCIe support
2019-11-12 15:59 [PATCH v2 0/6] Raspberry Pi 4 PCIe support Nicolas Saenz Julienne
` (5 preceding siblings ...)
2019-11-12 15:59 ` [PATCH v2 6/6] MAINTAINERS: Add brcmstb PCIe controller Nicolas Saenz Julienne
@ 2019-11-19 11:18 ` Andrew Murray
2019-11-19 11:49 ` Nicolas Saenz Julienne
6 siblings, 1 reply; 36+ messages in thread
From: Andrew Murray @ 2019-11-19 11:18 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: maz, linux-kernel, james.quinlan, mbrugger, f.fainelli, phil,
wahrenst, jeremy.linton, Robin Murphy, bcm-kernel-feedback-list,
linux-rpi-kernel, linux-arm-kernel, linux-pci, devicetree,
netdev, linux-rdma, linux-rockchip, iommu
On Tue, Nov 12, 2019 at 04:59:19PM +0100, Nicolas Saenz Julienne wrote:
> This series aims at providing support for Raspberry Pi 4's PCIe
> controller, which is also shared with the Broadcom STB family of
> devices.
>
> There was a previous attempt to upstream this some years ago[1] but was
> blocked as most STB PCIe integrations have a sparse DMA mapping[2] which
> is something currently not supported by the kernel. Luckily this is not
> the case for the Raspberry Pi 4.
>
> Note that the driver code is to be based on top of Rob Herring's series
> simplifying inbound and outbound range parsing.
>
> [1] https://patchwork.kernel.org/cover/10605933/
> [2] https://patchwork.kernel.org/patch/10605957/
>
What happened to patch 3? I can't see it on the list or in patchwork?
Thanks,
Andrew Murray
> ---
>
> Changes since v1:
> - add generic rounddown/roundup_pow_two64() patch
> - Add MAINTAINERS patch
> - Fix Kconfig
> - Cleanup probe, use up to date APIs, exit on MSI failure
> - Get rid of linux,pci-domain and other unused constructs
> - Use edge triggered setup for MSI
> - Cleanup MSI implementation
> - Fix multiple cosmetic issues
> - Remove supend/resume code
>
> Jim Quinlan (3):
> dt-bindings: PCI: Add bindings for brcmstb's PCIe device
> PCI: brcmstb: add Broadcom STB PCIe host controller driver
> PCI: brcmstb: add MSI capability
>
> Nicolas Saenz Julienne (3):
> linux/log2.h: Add roundup/rounddown_pow_two64() family of functions
> ARM: dts: bcm2711: Enable PCIe controller
> MAINTAINERS: Add brcmstb PCIe controller
>
> .../bindings/pci/brcm,stb-pcie.yaml | 110 ++
> MAINTAINERS | 4 +
> arch/arm/boot/dts/bcm2711.dtsi | 46 +
> drivers/net/ethernet/mellanox/mlx4/en_clock.c | 3 +-
> drivers/pci/controller/Kconfig | 9 +
> drivers/pci/controller/Makefile | 1 +
> drivers/pci/controller/pcie-brcmstb.c | 1179 +++++++++++++++++
> drivers/pci/controller/pcie-cadence-ep.c | 7 +-
> drivers/pci/controller/pcie-cadence.c | 7 +-
> drivers/pci/controller/pcie-rockchip-ep.c | 9 +-
> include/linux/log2.h | 52 +
> kernel/dma/direct.c | 3 +-
> 12 files changed, 1412 insertions(+), 18 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> create mode 100644 drivers/pci/controller/pcie-brcmstb.c
>
> --
> 2.24.0
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 2/6] dt-bindings: PCI: Add bindings for brcmstb's PCIe device
2019-11-19 11:17 ` Andrew Murray
@ 2019-11-19 11:28 ` Nicolas Saenz Julienne
0 siblings, 0 replies; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-19 11:28 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, devicetree, Florian Fainelli, Rob Herring, maz,
phil, linux-kernel, jeremy.linton, Eric Anholt, mbrugger,
bcm-kernel-feedback-list, Stefan Wahren, james.quinlan,
linux-pci, Bjorn Helgaas, linux-arm-kernel, linux-rpi-kernel
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
On Tue, 2019-11-19 at 11:17 +0000, Andrew Murray wrote:
> On Tue, Nov 12, 2019 at 04:59:21PM +0100, Nicolas Saenz Julienne wrote:
> > From: Jim Quinlan <james.quinlan@broadcom.com>
> >
> > The DT bindings description of the brcmstb PCIe device is described.
> > This node can only be used for now on the Raspberry Pi 4.
> >
> > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > Co-developed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> > Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> >
> > ---
> >
> > Changes since v1:
> > - Fix commit Subject
> > - Remove linux,pci-domain
> >
> > This was based on Jim's original submission[1], converted to yaml and
> > adapted to the RPi4 case.
> >
> > [1] https://patchwork.kernel.org/patch/10605937/
> >
> > .../bindings/pci/brcm,stb-pcie.yaml | 110 ++++++++++++++++++
> > 1 file changed, 110 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > new file mode 100644
> > index 000000000000..4cbb18821300
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > @@ -0,0 +1,110 @@
> > +# SPDX-License-Identifier: GPL-2.0
>
> I think in the last revision Rob asked you to change the license to
> the following:
>
> # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
Yes, but I had already sent this series by then. v3 will have all the fixes in.
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 1/6] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions
2019-11-19 11:13 ` Andrew Murray
@ 2019-11-19 11:30 ` Nicolas Saenz Julienne
2019-11-19 12:43 ` Nicolas Saenz Julienne
0 siblings, 1 reply; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-19 11:30 UTC (permalink / raw)
To: Andrew Murray
Cc: Heiko Stuebner, linux-pci, Shawn Lin, Christoph Hellwig,
Marek Szyprowski, Lorenzo Pieralisi, linux-rdma, maz, phil,
iommu, linux-rockchip, f.fainelli, Bjorn Helgaas,
linux-arm-kernel, mbrugger, netdev, linux-kernel, jeremy.linton,
Tom Joseph, wahrenst, james.quinlan, Robin Murphy,
David S. Miller, Tariq Toukan
[-- Attachment #1: Type: text/plain, Size: 758 bytes --]
Hi Andrew, thanks for the review.
> > +/**
> > + * __roundup_pow_of_two64() - round 64bit value up to nearest power of two
> > + * @n: value to round up
> > + */
> > +static inline __attribute__((const)) __u64 __roundup_pow_of_two64(__u64 n)
>
> To be consistent with other functions in the same file (__ilog_u64) you may
> want to rename this to __roundup_pow_of_two_u64.
Sounds good to me.
> Also do you know why u64 is used in some places and __u64 in others?
That's unwarranted, it should be __u64 everywhere.
> > +{
> > + return 1UL << fls64(n - 1);
>
> Does this need to be (and for the others):
>
> return 1ULL << fls64(n - 1);
>
> Notice that the PCI drivers you convert, all use 1ULL.
Noted
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 0/6] Raspberry Pi 4 PCIe support
2019-11-19 11:18 ` [PATCH v2 0/6] Raspberry Pi 4 PCIe support Andrew Murray
@ 2019-11-19 11:49 ` Nicolas Saenz Julienne
2019-11-21 12:18 ` Andrew Murray
0 siblings, 1 reply; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-19 11:49 UTC (permalink / raw)
To: Andrew Murray
Cc: devicetree, f.fainelli, linux-rdma, maz, phil, linux-kernel,
jeremy.linton, linux-rockchip, iommu, mbrugger,
bcm-kernel-feedback-list, wahrenst, james.quinlan, linux-pci,
Robin Murphy, netdev, linux-arm-kernel, linux-rpi-kernel
[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]
On Tue, 2019-11-19 at 11:18 +0000, Andrew Murray wrote:
> On Tue, Nov 12, 2019 at 04:59:19PM +0100, Nicolas Saenz Julienne wrote:
> > This series aims at providing support for Raspberry Pi 4's PCIe
> > controller, which is also shared with the Broadcom STB family of
> > devices.
> >
> > There was a previous attempt to upstream this some years ago[1] but was
> > blocked as most STB PCIe integrations have a sparse DMA mapping[2] which
> > is something currently not supported by the kernel. Luckily this is not
> > the case for the Raspberry Pi 4.
> >
> > Note that the driver code is to be based on top of Rob Herring's series
> > simplifying inbound and outbound range parsing.
> >
> > [1] https://patchwork.kernel.org/cover/10605933/
> > [2] https://patchwork.kernel.org/patch/10605957/
> >
>
> What happened to patch 3? I can't see it on the list or in patchwork?
For some reason the script I use to call get_maintainer.sh or git send-mail
failed to add linux-pci@vger.kernel.org and linux-kernel@vger.kernel.org as
recipients. I didn't do anything different between v1 and v2 as far as mailing
is concerned.
Nevertheless it's here: https://www.spinics.net/lists/arm-kernel/msg768461.html
and should be present in the linux-arm-kernel list.
I'll look in to it and make sure this doesn't happen in v3.
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 1/6] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions
2019-11-19 11:30 ` Nicolas Saenz Julienne
@ 2019-11-19 12:43 ` Nicolas Saenz Julienne
2019-11-19 16:28 ` Andrew Murray
0 siblings, 1 reply; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-19 12:43 UTC (permalink / raw)
To: Andrew Murray
Cc: Heiko Stuebner, linux-pci, Shawn Lin, Christoph Hellwig,
Marek Szyprowski, Lorenzo Pieralisi, linux-rdma, maz, phil,
iommu, linux-rockchip, f.fainelli, Bjorn Helgaas,
linux-arm-kernel, mbrugger, netdev, linux-kernel, jeremy.linton,
Tom Joseph, wahrenst, james.quinlan, Robin Murphy,
David S. Miller, Tariq Toukan
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]
On Tue, 2019-11-19 at 12:30 +0100, Nicolas Saenz Julienne wrote:
> Hi Andrew, thanks for the review.
> > > +/**
> > > + * __roundup_pow_of_two64() - round 64bit value up to nearest power of
> > > two
> > > + * @n: value to round up
> > > + */
> > > +static inline __attribute__((const)) __u64 __roundup_pow_of_two64(__u64
> > > n)
> >
> > To be consistent with other functions in the same file (__ilog_u64) you may
> > want to rename this to __roundup_pow_of_two_u64.
>
> Sounds good to me.
>
> > Also do you know why u64 is used in some places and __u64 in others?
>
> That's unwarranted, it should be __u64 everywhere.
Sorry, now that I look deeper into it, it should be u64.
> > > +{
> > > + return 1UL << fls64(n - 1);
> >
> > Does this need to be (and for the others):
> >
> > return 1ULL << fls64(n - 1);
> >
> > Notice that the PCI drivers you convert, all use 1ULL.
>
> Noted
>
> Regards,
> Nicolas
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver
2019-11-12 15:59 ` [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver Nicolas Saenz Julienne
@ 2019-11-19 16:25 ` Andrew Murray
2019-11-19 18:20 ` Jeremy Linton
` (2 more replies)
0 siblings, 3 replies; 36+ messages in thread
From: Andrew Murray @ 2019-11-19 16:25 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: maz, linux-kernel, Lorenzo Pieralisi, Eric Anholt, Stefan Wahren,
Florian Fainelli, bcm-kernel-feedback-list, james.quinlan,
mbrugger, phil, jeremy.linton, Bjorn Helgaas, linux-pci,
linux-rpi-kernel, linux-arm-kernel
On Tue, Nov 12, 2019 at 04:59:23PM +0100, Nicolas Saenz Julienne wrote:
> From: Jim Quinlan <james.quinlan@broadcom.com>
>
> This commit adds the basic Broadcom STB PCIe controller. Missing is the
> ability to process MSI. This functionality is added in a subsequent
> commit.
>
> The PCIe block contains an MDIO interface. This is a local interface
> only accessible by the PCIe controller. It cannot be used or shared
> by any other HW. As such, the small amount of code for this
> controller is included in this driver as there is little upside to put
> it elsewhere.
This commit message hasn't changed, despite earlier feedback.
>
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> Co-developed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
>
> ---
>
> Changes since v1:
> - Fix Kconfig
> - Remove pci domain check
> - Remove all MSI related code
> - Remove supend/resume code
> - Simplify link state wait routine
> - Prefix all functions
> - Use of_device_get_match_data()
> - Use devm_clk_get_optional()
> - Get rid of irq variable
> - Use STB all over the driver
> - Fix license mismatch
> - Remove unused register definitions
> - Small cleanups, spell errors
>
> NOTE: I decided to remove the suspend/resume routines for now. The
> RPi4 doesn't need it, and we where having issues with the
> specifics of the resume function on devices we yet don't support.
> We'll deal with this in the future.
>
> This is based on Jim's original submission[1] but adapted and tailored
> specifically to bcm2711's needs (that's the Raspberry Pi 4). Support for
> the rest of the brcmstb family will soon follow once we get support for
> multiple dma-ranges in dma/direct.
>
> [1] https://patchwork.kernel.org/patch/10605959/
>
> drivers/pci/controller/Kconfig | 8 +
> drivers/pci/controller/Makefile | 1 +
> drivers/pci/controller/pcie-brcmstb.c | 855 ++++++++++++++++++++++++++
> 3 files changed, 864 insertions(+)
> create mode 100644 drivers/pci/controller/pcie-brcmstb.c
>
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index f5de9119e8d3..486d4d570233 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -281,6 +281,14 @@ config VMD
> To compile this driver as a module, choose M here: the
> module will be called vmd.
>
> +config PCIE_BRCMSTB
> + bool "Broadcom Brcmstb PCIe host controller"
> + depends on ARCH_BCM2835 || COMPILE_TEST
> + depends on OF
> + help
> + Say Y here to enable PCIe host controller support for
> + Broadcom STB based SoCs, like the Raspberry Pi 4.
> +
> config PCI_HYPERV_INTERFACE
> tristate "Hyper-V PCI Interface"
> depends on X86 && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN && X86_64
> diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
> index a2a22c9d91af..3fc0b0cf5b5b 100644
> --- a/drivers/pci/controller/Makefile
> +++ b/drivers/pci/controller/Makefile
> @@ -30,6 +30,7 @@ obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
> obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
> obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
> obj-$(CONFIG_VMD) += vmd.o
> +obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o
> # pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
> obj-y += dwc/
>
> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> new file mode 100644
> index 000000000000..8d81c5ab5979
> --- /dev/null
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -0,0 +1,855 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/* Copyright (C) 2009 - 2019 Broadcom */
> +
> +#include <linux/clk.h>
> +#include <linux/compiler.h>
> +#include <linux/delay.h>
> +#include <linux/init.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/ioport.h>
> +#include <linux/irqdomain.h>
> +#include <linux/kernel.h>
> +#include <linux/list.h>
> +#include <linux/log2.h>
> +#include <linux/module.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_pci.h>
> +#include <linux/of_platform.h>
> +#include <linux/pci.h>
> +#include <linux/printk.h>
> +#include <linux/sizes.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <linux/types.h>
> +
> +#include "../pci.h"
> +
> +/* BRCM_PCIE_CAP_REGS - Offset for the mandatory capability config regs */
> +#define BRCM_PCIE_CAP_REGS 0x00ac
> +
> +/*
> + * Broadcom STB PCIe Register Offsets. The names are from the chip's RDB and we
> + * use them here so that a script can correlate this code and the RDB to
> + * prevent discrepancies.
> + */
> +#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1 0x0188
> +#define PCIE_RC_CFG_PRIV1_ID_VAL3 0x043c
> +#define PCIE_RC_DL_MDIO_ADDR 0x1100
> +#define PCIE_RC_DL_MDIO_WR_DATA 0x1104
> +#define PCIE_RC_DL_MDIO_RD_DATA 0x1108
> +#define PCIE_MISC_MISC_CTRL 0x4008
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO 0x400c
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI 0x4010
> +#define PCIE_MISC_RC_BAR1_CONFIG_LO 0x402c
> +#define PCIE_MISC_RC_BAR2_CONFIG_LO 0x4034
> +#define PCIE_MISC_RC_BAR2_CONFIG_HI 0x4038
> +#define PCIE_MISC_RC_BAR3_CONFIG_LO 0x403c
> +#define PCIE_MISC_PCIE_CTRL 0x4064
> +#define PCIE_MISC_PCIE_STATUS 0x4068
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT 0x4070
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI 0x4080
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI 0x4084
> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
> +#define PCIE_INTR2_CPU_BASE 0x4300
> +
> +/*
> + * Broadcom STB PCIe Register Field shift and mask info. The names are from the
> + * chip's RDB and we use them here so that a script can correlate this code and
> + * the RDB to prevent discrepancies.
> + */
> +#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_MASK 0xc
> +#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_SHIFT 0x2
> +#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_MASK 0xffffff
> +#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_SHIFT 0x0
> +#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK 0x1000
> +#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_SHIFT 0xc
> +#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK 0x2000
> +#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_SHIFT 0xd
> +#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
> +#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_SHIFT 0x14
> +#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
> +#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_SHIFT 0x1b
> +#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_MASK 0x1f
> +#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_SHIFT 0x0
> +#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_MASK 0x1f
> +#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_SHIFT 0x0
> +#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_MASK 0x1f
> +#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_SHIFT 0x0
> +#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK 0x1
> +#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_SHIFT 0x0
> +#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_MASK 0x80
> +#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_SHIFT 0x7
> +#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_MASK 0x20
> +#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_SHIFT 0x5
> +#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_MASK 0x10
> +#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_SHIFT 0x4
> +#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK 0x40
> +#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_SHIFT 0x6
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_MASK 0xfff00000
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_SHIFT 0x14
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK 0xfff0
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_SHIFT 0x4
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS 0xc
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_MASK 0xff
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_SHIFT 0x0
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_MASK 0xff
> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_SHIFT 0x0
> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK 0x2
> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_SHIFT 0x1
> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_SHIFT 0x1b
> +#define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1
> +#define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0
> +
> +#define BRCM_NUM_PCIE_OUT_WINS 0x4
> +
> +#define BURST_SIZE_128 0
> +
> +/* Offsets from PCIE_INTR2_CPU_BASE */
> +#define STATUS 0x0
> +#define CLR 0x8
> +#define MASK_SET 0x10
> +#define MASK_CLR 0x14
> +
> +#define PCIE_BUSNUM_SHIFT 20
> +#define PCIE_SLOT_SHIFT 15
> +#define PCIE_FUNC_SHIFT 12
> +
> +#if defined(__BIG_ENDIAN)
> +#define DATA_ENDIAN 2 /* PCIe->DDR inbound traffic */
> +#define MMIO_ENDIAN 2 /* CPU->PCIe outbound traffic */
> +#else
> +#define DATA_ENDIAN 0
> +#define MMIO_ENDIAN 0
> +#endif
> +
> +#define MDIO_PORT0 0x0
> +#define MDIO_DATA_MASK 0x7fffffff
> +#define MDIO_DATA_SHIFT 0x0
> +#define MDIO_PORT_MASK 0xf0000
> +#define MDIO_PORT_SHIFT 0x16
> +#define MDIO_REGAD_MASK 0xffff
> +#define MDIO_REGAD_SHIFT 0x0
> +#define MDIO_CMD_MASK 0xfff00000
> +#define MDIO_CMD_SHIFT 0x14
> +#define MDIO_CMD_READ 0x1
> +#define MDIO_CMD_WRITE 0x0
> +#define MDIO_DATA_DONE_MASK 0x80000000
> +#define MDIO_RD_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 1 : 0)
> +#define MDIO_WT_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 0 : 1)
> +#define SSC_REGS_ADDR 0x1100
> +#define SET_ADDR_OFFSET 0x1f
> +#define SSC_CNTL_OFFSET 0x2
> +#define SSC_CNTL_OVRD_EN_MASK 0x8000
> +#define SSC_CNTL_OVRD_EN_SHIFT 0xf
> +#define SSC_CNTL_OVRD_VAL_MASK 0x4000
> +#define SSC_CNTL_OVRD_VAL_SHIFT 0xe
> +#define SSC_STATUS_OFFSET 0x1
> +#define SSC_STATUS_SSC_MASK 0x400
> +#define SSC_STATUS_SSC_SHIFT 0xa
> +#define SSC_STATUS_PLL_LOCK_MASK 0x800
> +#define SSC_STATUS_PLL_LOCK_SHIFT 0xb
> +
> +#define BRCM_PCIE_IDX_ADDR(pcie) \
> + ((pcie)->reg_offsets[EXT_CFG_INDEX])
> +#define BRCM_PCIE_DATA_ADDR(pcie) \
> + ((pcie)->reg_offsets[EXT_CFG_DATA])
> +#define BRCM_PCIE_RGR1_SW_INIT_1(pcie) \
> + ((pcie)->reg_offsets[RGR1_SW_INIT_1])
> +
> +enum {
> + RGR1_SW_INIT_1,
> + EXT_CFG_INDEX,
> + EXT_CFG_DATA,
> +};
> +
> +enum {
> + RGR1_SW_INIT_1_INIT_MASK,
> + RGR1_SW_INIT_1_INIT_SHIFT,
> + RGR1_SW_INIT_1_PERST_MASK,
> + RGR1_SW_INIT_1_PERST_SHIFT,
> +};
> +
> +enum pcie_type {
> + BCM2711,
> +};
> +
> +struct brcm_window {
> + dma_addr_t pcie_addr;
> + phys_addr_t cpu_addr;
> + dma_addr_t size;
> +};
> +
> +/* Internal PCIe Host Controller Information.*/
> +struct brcm_pcie {
> + struct device *dev;
> + void __iomem *base;
> + struct clk *clk;
> + struct pci_bus *root_bus;
> + struct device_node *np;
> + bool ssc;
> + int gen;
> + struct brcm_window out_wins[BRCM_NUM_PCIE_OUT_WINS];
> + const int *reg_offsets;
> + const int *reg_field_info;
> + enum pcie_type type;
> +};
> +
> +struct pcie_cfg_data {
> + const int *reg_field_info;
> + const int *offsets;
> + const enum pcie_type type;
> +};
> +
> +static const int pcie_reg_field_info[] = {
> + [RGR1_SW_INIT_1_INIT_MASK] = 0x2,
> + [RGR1_SW_INIT_1_INIT_SHIFT] = 0x1,
> +};
> +
> +static const int pcie_offset_bcm2711[] = {
> + [RGR1_SW_INIT_1] = 0x9210,
> + [EXT_CFG_INDEX] = 0x9000,
> + [EXT_CFG_DATA] = 0x8000,
> +};
> +
> +static const struct pcie_cfg_data bcm2711_cfg = {
> + .reg_field_info = pcie_reg_field_info,
> + .offsets = pcie_offset_bcm2711,
> + .type = BCM2711,
> +};
> +
> +static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
> + int where);
> +
> +static struct pci_ops brcm_pcie_ops = {
> + .map_bus = brcm_pcie_map_conf,
> + .read = pci_generic_config_read,
> + .write = pci_generic_config_write,
> +};
> +
> +#define bcm_readl(a) readl(a)
> +#define bcm_writel(d, a) writel(d, a)
> +#define bcm_readw(a) readw(a)
> +#define bcm_writew(d, a) writew(d, a)
> +
> +/* These macros extract/insert fields to host controller's register set. */
> +#define RD_FLD(base, reg, field) \
> + brcm_pcie_rd_fld((base) + reg, reg##_##field##_MASK, \
> + reg##_##field##_SHIFT)
> +#define WR_FLD(base, reg, field, val) \
> + brcm_pcie_wr_fld((base) + reg, reg##_##field##_MASK, \
> + reg##_##field##_SHIFT, val)
> +#define WR_FLD_RB(base, reg, field, val) \
> + brcm_pcie_wr_fld_rb((base) + reg, reg##_##field##_MASK, \
> + reg##_##field##_SHIFT, val)
> +#define WR_FLD_WITH_OFFSET(base, off, reg, field, val) \
> + brcm_pcie_wr_fld((base) + reg + (off), reg##_##field##_MASK, \
> + reg##_##field##_SHIFT, val)
> +#define EXTRACT_FIELD(val, reg, field) \
> + (((val) & reg##_##field##_MASK) >> reg##_##field##_SHIFT)
> +#define INSERT_FIELD(val, reg, field, field_val) \
> + (((val) & ~reg##_##field##_MASK) | \
> + (reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
Can you use any of the existing macros in linux/bitfield.h
(e.g. ...replace_bits...) ?
> +
> +static u32 brcm_pcie_rd_fld(void __iomem *p, u32 mask, int shift)
> +{
> + return (bcm_readl(p) & mask) >> shift;
> +}
> +
> +static void brcm_pcie_wr_fld(void __iomem *p, u32 mask, int shift, u32 val)
> +{
> + u32 reg = bcm_readl(p);
> +
> + reg = (reg & ~mask) | ((val << shift) & mask);
> + bcm_writel(reg, p);
> +}
> +
> +static void brcm_pcie_wr_fld_rb(void __iomem *p, u32 mask, int shift, u32 val)
> +{
> + brcm_pcie_wr_fld(p, mask, shift, val);
> + (void)bcm_readl(p);
> +}
> +
> +/*
> + * This is to convert the size of the inbound "BAR" region to the
> + * non-linear values of PCIE_X_MISC_RC_BAR[123]_CONFIG_LO.SIZE
> + */
> +int brcm_pcie_encode_ibar_size(u64 size)
> +{
> + int log2_in = ilog2(size);
> +
> + if (log2_in >= 12 && log2_in <= 15)
> + /* Covers 4KB to 32KB (inclusive) */
> + return (log2_in - 12) + 0x1c;
> + else if (log2_in >= 16 && log2_in <= 35)
> + /* Covers 64KB to 32GB, (inclusive) */
> + return log2_in - 15;
> + /* Something is awry so disable */
> + return 0;
> +}
> +
> +static u32 brcm_pcie_mdio_form_pkt(int port, int regad, int cmd)
> +{
> + u32 pkt = 0;
> +
> + pkt |= (port << MDIO_PORT_SHIFT) & MDIO_PORT_MASK;
> + pkt |= (regad << MDIO_REGAD_SHIFT) & MDIO_REGAD_MASK;
> + pkt |= (cmd << MDIO_CMD_SHIFT) & MDIO_CMD_MASK;
> +
> + return pkt;
> +}
> +
> +/* negative return value indicates error */
> +static int brcm_pcie_mdio_read(void __iomem *base, u8 port, u8 regad)
> +{
> + int tries;
> + u32 data;
> +
> + bcm_writel(brcm_pcie_mdio_form_pkt(port, regad, MDIO_CMD_READ),
> + base + PCIE_RC_DL_MDIO_ADDR);
> + bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
> +
> + data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
> + for (tries = 0; !MDIO_RD_DONE(data) && tries < 10; tries++) {
> + udelay(10);
> + data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
> + }
> +
> + return MDIO_RD_DONE(data)
> + ? (data & MDIO_DATA_MASK) >> MDIO_DATA_SHIFT
> + : -EIO;
> +}
> +
> +/* negative return value indicates error */
> +static int brcm_pcie_mdio_write(void __iomem *base, u8 port,
> + u8 regad, u16 wrdata)
> +{
> + int tries;
> + u32 data;
> +
> + bcm_writel(brcm_pcie_mdio_form_pkt(port, regad, MDIO_CMD_WRITE),
> + base + PCIE_RC_DL_MDIO_ADDR);
> + bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
> + bcm_writel(MDIO_DATA_DONE_MASK | wrdata,
> + base + PCIE_RC_DL_MDIO_WR_DATA);
> +
> + data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
> + for (tries = 0; !MDIO_WT_DONE(data) && tries < 10; tries++) {
> + udelay(10);
> + data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
> + }
> +
> + return MDIO_WT_DONE(data) ? 0 : -EIO;
> +}
> +
> +/*
> + * Configures device for Spread Spectrum Clocking (SSC) mode; a negative
> + * return value indicates error.
> + */
> +static int brcm_pcie_set_ssc(void __iomem *base)
> +{
> + int pll, ssc;
> + u16 wrdata;
> + int tmp;
> +
> + tmp = brcm_pcie_mdio_write(base, MDIO_PORT0, SET_ADDR_OFFSET,
> + SSC_REGS_ADDR);
> + if (tmp < 0)
> + return tmp;
> +
> + tmp = brcm_pcie_mdio_read(base, MDIO_PORT0, SSC_CNTL_OFFSET);
> + if (tmp < 0)
> + return tmp;
> +
> + wrdata = INSERT_FIELD(tmp, SSC_CNTL_OVRD, EN, 1);
> + wrdata = INSERT_FIELD(wrdata, SSC_CNTL_OVRD, VAL, 1);
> + tmp = brcm_pcie_mdio_write(base, MDIO_PORT0, SSC_CNTL_OFFSET, wrdata);
> + if (tmp < 0)
> + return tmp;
> +
> + usleep_range(1000, 2000);
> + tmp = brcm_pcie_mdio_read(base, MDIO_PORT0, SSC_STATUS_OFFSET);
> + if (tmp < 0)
> + return tmp;
> +
> + ssc = EXTRACT_FIELD(tmp, SSC_STATUS, SSC);
> + pll = EXTRACT_FIELD(tmp, SSC_STATUS, PLL_LOCK);
> +
> + return (ssc && pll) ? 0 : -EIO;
> +}
> +
> +/* Limits operation to a specific generation (1, 2, or 3) */
> +static void brcm_pcie_set_gen(void __iomem *base, int gen)
> +{
> + u32 lnkcap = bcm_readl(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCAP);
> + u16 lnkctl2 = bcm_readw(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCTL2);
> +
> + lnkcap = (lnkcap & ~PCI_EXP_LNKCAP_SLS) | gen;
> + bcm_writel(lnkcap, base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCAP);
> +
> + lnkctl2 = (lnkctl2 & ~0xf) | gen;
> + bcm_writew(lnkctl2, base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCTL2);
> +}
> +
> +static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
> + unsigned int win, phys_addr_t cpu_addr,
> + dma_addr_t pcie_addr, dma_addr_t size)
> +{
> + phys_addr_t cpu_addr_mb, limit_addr_mb;
> + void __iomem *base = pcie->base;
> + u32 tmp;
> +
> + /* Set the base of the pcie_addr window */
> + bcm_writel(lower_32_bits(pcie_addr) + MMIO_ENDIAN,
> + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + (win * 8));
> + bcm_writel(upper_32_bits(pcie_addr),
> + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + (win * 8));
> +
> + cpu_addr_mb = cpu_addr >> 20;
> + limit_addr_mb = (cpu_addr + size - 1) >> 20;
> +
> + /* Write the addr base low register */
> + WR_FLD_WITH_OFFSET(base, (win * 4),
> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
> + BASE, cpu_addr_mb);
> + /* Write the addr limit low register */
> + WR_FLD_WITH_OFFSET(base, (win * 4),
> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
> + LIMIT, limit_addr_mb);
> +
> + /* Write the cpu addr high register */
> + tmp = (u32)(cpu_addr_mb >>
> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
Despite the name _MASK_BITS, this isn't being used as a mask. Is this making
some assumption about the value of cpu_addr from the DT?
Ideally we'd just use the value from the DT as we do for the low register.
> + WR_FLD_WITH_OFFSET(base, (win * 8),
> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI,
> + BASE, tmp);
> + /* Write the cpu limit high register */
> + tmp = (u32)(limit_addr_mb >>
> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
> + WR_FLD_WITH_OFFSET(base, (win * 8),
> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI,
> + LIMIT, tmp);
> +}
> +
> +/* Configuration space read/write support */
> +static int brcm_pcie_cfg_index(int busnr, int devfn, int reg)
> +{
> + return ((PCI_SLOT(devfn) & 0x1f) << PCIE_SLOT_SHIFT)
> + | ((PCI_FUNC(devfn) & 0x07) << PCIE_FUNC_SHIFT)
> + | (busnr << PCIE_BUSNUM_SHIFT)
> + | (reg & ~3);
> +}
> +
> +/* The controller is capable of serving in both RC and EP roles */
> +static bool brcm_pcie_rc_mode(struct brcm_pcie *pcie)
> +{
> + void __iomem *base = pcie->base;
> + u32 val = bcm_readl(base + PCIE_MISC_PCIE_STATUS);
> +
> + return !!EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PORT);
> +}
> +
> +static bool brcm_pcie_link_up(struct brcm_pcie *pcie)
> +{
> + void __iomem *base = pcie->base;
> + u32 val = bcm_readl(base + PCIE_MISC_PCIE_STATUS);
> + u32 dla = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_DL_ACTIVE);
> + u32 plu = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PHYLINKUP);
> +
> + return (dla && plu) ? true : false;
> +}
> +
> +static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
> + int where)
> +{
> + struct brcm_pcie *pcie = bus->sysdata;
> + void __iomem *base = pcie->base;
> + int idx;
> +
> + /* Accesses to the RC go right to the RC registers if slot==0 */
> + if (pci_is_root_bus(bus))
> + return PCI_SLOT(devfn) ? NULL : base + where;
> +
> + /* For devices, write to the config space index register */
> + idx = brcm_pcie_cfg_index(bus->number, devfn, 0);
> + bcm_writel(idx, pcie->base + BRCM_PCIE_IDX_ADDR(pcie));
> + return base + BRCM_PCIE_DATA_ADDR(pcie) + where;
> +}
> +
> +static inline void brcm_pcie_bridge_sw_init_set(struct brcm_pcie *pcie,
> + unsigned int val)
> +{
> + unsigned int shift = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_SHIFT];
> + u32 mask = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_MASK];
> +
> + brcm_pcie_wr_fld_rb(pcie->base + BRCM_PCIE_RGR1_SW_INIT_1(pcie),
> + mask, shift, val);
> +}
> +
> +static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie,
> + unsigned int val)
> +{
> + brcm_pcie_wr_fld_rb(pcie->base + BRCM_PCIE_RGR1_SW_INIT_1(pcie),
> + PCIE_RGR1_SW_INIT_1_PERST_MASK,
> + PCIE_RGR1_SW_INIT_1_PERST_SHIFT, val);
> +}
> +
> +static inline int brcm_pcie_get_rc_bar2_size_and_offset(struct brcm_pcie *pcie,
> + u64 *rc_bar2_size,
> + u64 *rc_bar2_offset)
> +{
> + struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
> + struct device *dev = pcie->dev;
> + struct resource_entry *entry;
> + u64 total_mem_size = 0;
> +
> + *rc_bar2_offset = -1;
> +
> + resource_list_for_each_entry(entry, &bridge->dma_ranges) {
> + /*
> + * We're promised the RC will provide a contiguous view of
> + * memory to downstream devices. We can then infer the
> + * rc_bar2_offset from the lower available dma-range offset.
> + */
> + if (entry->offset < *rc_bar2_offset)
> + *rc_bar2_offset = entry->offset;
> +
> + total_mem_size += entry->res->end - entry->res->start + 1;
This requires that if there are multiple dma-ranges, then there are no gaps
between them right?
> + }
> +
> + *rc_bar2_size = roundup_pow_of_two64(total_mem_size);
> +
> + /*
> + * Validate the results:
> + *
> + * The PCIe host controller by design must set the inbound viewport to
> + * be a contiguous arrangement of all of the system's memory. In
> + * addition, its size mut be a power of two. To further complicate
> + * matters, the viewport must start on a pcie-address that is aligned
> + * on a multiple of its size. If a portion of the viewport does not
> + * represent system memory -- e.g. 3GB of memory requires a 4GB
> + * viewport -- we can map the outbound memory in or after 3GB and even
> + * though the viewport will overlap the outbound memory the controller
> + * will know to send outbound memory downstream and everything else
> + * upstream.
> + *
> + * For example:
> + *
> + * - The best-case scenario, memory up to 3GB, is to place the inbound
> + * region in the first 4GB of pcie-space, as some legacy devices can
> + * only address 32bits. We would also like to put the MSI under 4GB
> + * as well, since some devices require a 32bit MSI target address.
> + *
> + * - If the system memory is 4GB or larger we cannot start the inbound
> + * region at location 0 (since we have to allow some space for
> + * outbound memory @ 3GB). So instead it will start at the 1x
> + * multiple of its size
> + */
> + if (!*rc_bar2_size || *rc_bar2_offset % *rc_bar2_size ||
> + (*rc_bar2_offset < SZ_4G && *rc_bar2_offset > SZ_2G)) {
> + dev_err(dev, "Invalid rc_bar2_offset/size: size 0x%llx, off 0x%llx\n",
> + *rc_bar2_size, *rc_bar2_offset);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int brcm_pcie_setup(struct brcm_pcie *pcie)
> +{
> + struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
> + u64 rc_bar2_offset, rc_bar2_size;
> + void __iomem *base = pcie->base;
> + struct device *dev = pcie->dev;
> + struct resource_entry *entry;
> + unsigned int scb_size_val;
> + bool ssc_good = false;
> + struct resource *res;
> + int num_out_wins = 0;
> + u16 nlw, cls, lnksta;
> + int i, ret;
> + u32 tmp;
> +
> + /* Reset the bridge */
> + brcm_pcie_bridge_sw_init_set(pcie, 1);
> +
> + usleep_range(100, 200);
> +
> + /* Take the bridge out of reset */
> + brcm_pcie_bridge_sw_init_set(pcie, 0);
> +
> + WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
> + /* Wait for SerDes to be stable */
> + usleep_range(100, 200);
> +
> + /* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
> + tmp = INSERT_FIELD(0, PCIE_MISC_MISC_CTRL, SCB_ACCESS_EN, 1);
> + tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, CFG_READ_UR_MODE, 1);
> + tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, MAX_BURST_SIZE,
> + BURST_SIZE_128);
> + bcm_writel(tmp, base + PCIE_MISC_MISC_CTRL);
> +
> + ret = brcm_pcie_get_rc_bar2_size_and_offset(pcie, &rc_bar2_size,
> + &rc_bar2_offset);
> + if (ret)
> + return ret;
> +
> + tmp = lower_32_bits(rc_bar2_offset);
> + tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
> + brcm_pcie_encode_ibar_size(rc_bar2_size));
> + bcm_writel(tmp, base + PCIE_MISC_RC_BAR2_CONFIG_LO);
> + bcm_writel(upper_32_bits(rc_bar2_offset),
> + base + PCIE_MISC_RC_BAR2_CONFIG_HI);
> +
> + scb_size_val = rc_bar2_size ?
> + ilog2(rc_bar2_size) - 15 : 0xf; /* 0xf is 1GB */
> + WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB0_SIZE, scb_size_val);
> +
> + /* disable the PCIe->GISB memory window (RC_BAR1) */
> + WR_FLD(base, PCIE_MISC_RC_BAR1_CONFIG_LO, SIZE, 0);
> +
> + /* disable the PCIe->SCB memory window (RC_BAR3) */
> + WR_FLD(base, PCIE_MISC_RC_BAR3_CONFIG_LO, SIZE, 0);
> +
> + /* clear any interrupts we find on boot */
> + bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + CLR);
> + (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + CLR);
> +
> + /* Mask all interrupts since we are not handling any yet */
> + bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + MASK_SET);
> + (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + MASK_SET);
Should you change the order and mask before clearing the interrupts?
> +
> + if (pcie->gen)
> + brcm_pcie_set_gen(base, pcie->gen);
> +
> + /* Unassert the fundamental reset */
> + brcm_pcie_perst_set(pcie, 0);
> +
> + /*
> + * Give the RC/EP time to wake up, before trying to configure RC.
> + * Intermittently check status for link-up, up to a total of 100ms.
> + */
> + for (i = 0; i < 100 && !brcm_pcie_link_up(pcie); i += 5)
> + msleep(5);
> +
> + if (!brcm_pcie_link_up(pcie)) {
> + dev_info(dev, "link down\n");
> + return -ENODEV;
> + }
> +
> + if (!brcm_pcie_rc_mode(pcie)) {
> + dev_err(dev, "PCIe misconfigured; is in EP mode\n");
> + return -EINVAL;
> + }
> +
> + resource_list_for_each_entry(entry, &bridge->windows) {
> + res = entry->res;
> +
> + if (resource_type(res) != IORESOURCE_MEM)
> + continue;
> +
> + if (num_out_wins >= BRCM_NUM_PCIE_OUT_WINS) {
> + dev_err(pcie->dev, "too many outbound wins\n");
> + return -EINVAL;
> + }
> +
> + brcm_pcie_set_outbound_win(pcie, num_out_wins, res->start,
> + res->start - entry->offset,
> + res->end - res->start + 1);
> + num_out_wins++;
> + }
> +
> + /*
> + * For config space accesses on the RC, show the right class for
> + * a PCIe-PCIe bridge (the default setting is to be EP mode).
> + */
> + WR_FLD_RB(base, PCIE_RC_CFG_PRIV1_ID_VAL3, CLASS_CODE, 0x060400);
Why does this need to be _RB ? I haven't looked at all of the uses of _RB
though I think there are others that may not be necessary.
> +
> + if (pcie->ssc) {
> + ret = brcm_pcie_set_ssc(base);
> + if (ret == 0)
> + ssc_good = true;
> + else
> + dev_err(dev, "failed attempt to enter ssc mode\n");
> + }
> +
> + lnksta = bcm_readw(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKSTA);
> + cls = lnksta & PCI_EXP_LNKSTA_CLS;
> + nlw = (lnksta & PCI_EXP_LNKSTA_NLW) >> PCI_EXP_LNKSTA_NLW_SHIFT;
> + dev_info(dev, "link up, %s x%u %s\n",
> + PCIE_SPEED2STR(cls + PCI_SPEED_133MHz_PCIX_533),
> + nlw, ssc_good ? "(SSC)" : "(!SSC)");
> +
> + /* PCIe->SCB endian mode for BAR */
> + /* field ENDIAN_MODE_BAR2 = DATA_ENDIAN */
> + WR_FLD_RB(base, PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1,
> + ENDIAN_MODE_BAR2, DATA_ENDIAN);
> +
> + /*
> + * Refclk from RC should be gated with CLKREQ# input when ASPM L0s,L1
> + * is enabled => setting the CLKREQ_DEBUG_ENABLE field to 1.
> + */
> + WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, CLKREQ_DEBUG_ENABLE, 1);
> +
> + return 0;
> +}
> +
> +/* L23 is a low-power PCIe link state */
> +static void brcm_pcie_enter_l23(struct brcm_pcie *pcie)
> +{
> + void __iomem *base = pcie->base;
> + int l23, i;
> +
> + /* assert request for L23 */
> + WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 1);
Also not sure about the _RB here, given you have a read straight after.
> +
> + /* Wait up to 36 msec for L23 */
> + l23 = RD_FLD(base, PCIE_MISC_PCIE_STATUS, PCIE_LINK_IN_L23);
> + for (i = 0; i < 15 && !l23; i++) {
> + usleep_range(2000, 2400);
> + l23 = RD_FLD(base, PCIE_MISC_PCIE_STATUS, PCIE_LINK_IN_L23);
> + }
> +
> + if (!l23)
> + dev_err(pcie->dev, "failed to enter low-power link state\n");
> +}
> +
> +static void brcm_pcie_turn_off(struct brcm_pcie *pcie)
> +{
> + void __iomem *base = pcie->base;
> +
> + if (brcm_pcie_link_up(pcie))
> + brcm_pcie_enter_l23(pcie);
> + /* Assert fundamental reset */
> + brcm_pcie_perst_set(pcie, 1);
> + /* Deassert request for L23 in case it was asserted */
> + WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 0);
> + /* Turn off SerDes */
> + WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 1);
> + /* Shutdown PCIe bridge */
What is the purpose of the _RB's here?
> + brcm_pcie_bridge_sw_init_set(pcie, 1);
> +}
> +
> +static void __brcm_pcie_remove(struct brcm_pcie *pcie)
> +{
> + brcm_pcie_turn_off(pcie);
> + clk_disable_unprepare(pcie->clk);
> + clk_put(pcie->clk);
> +}
> +
> +static int brcm_pcie_remove(struct platform_device *pdev)
> +{
> + struct brcm_pcie *pcie = platform_get_drvdata(pdev);
> +
> + pci_stop_root_bus(pcie->root_bus);
> + pci_remove_root_bus(pcie->root_bus);
> + __brcm_pcie_remove(pcie);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id brcm_pcie_match[] = {
> + { .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
I'd rather see use of the pcie_cfg_data structure removed from this series.
I've seen the comments in the previous thread [1], and I understand that
the intention is that this driver will eventually be used for other SOCs.
However this indirection isn't needed *now* and it makes reviewing this
patch more difficult. If and when a later series is made to cover other
SOCs - then I'd expect that series to find a way to apply this indirection.
And if that later series is more difficult to review because of the newly
added indirection, then I'd expect an early patch of that series to apply
the indirection in a single patch - which would be easy to review.
The other risk of such premature changes like this is that when you come
to adding other SOCs, you may then discover that there were shortcomings
in the way you've approached it here.
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, brcm_pcie_match);
> +
> +static int brcm_pcie_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + const struct pcie_cfg_data *data;
> + struct pci_host_bridge *bridge;
> + struct brcm_pcie *pcie;
> + struct pci_bus *child;
> + struct resource *res;
> + int ret;
> +
> + bridge = devm_pci_alloc_host_bridge(&pdev->dev, sizeof(*pcie));
> + if (!bridge)
> + return -ENOMEM;
> +
> + pcie = pci_host_bridge_priv(bridge);
Nit: I'd suggest moving the above line so it sits just above the
"pcie->reg_offsets = data->offsets;" line. It looks nicer.
> +
> + data = of_device_get_match_data(&pdev->dev);
> + if (!data) {
> + dev_err(&pdev->dev, "failed to look up compatible string\n");
Nit: If there is a failure here, it's probably because there is no data
defined in the brcm_pcie_match structure - seeing as we wouldn't get here
if we didn't have a compatible string. I'd suggest rewording the err slightly
or even removing it.
> + return -EINVAL;
> + }
> +
> + pcie->reg_offsets = data->offsets;
> + pcie->reg_field_info = data->reg_field_info;
> + pcie->type = data->type;
> + pcie->np = np;
> + pcie->dev = &pdev->dev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + pcie->base = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(pcie->base))
> + return PTR_ERR(pcie->base);
> +
> + pcie->clk = devm_clk_get_optional(&pdev->dev, "sw_pcie");
> + if (IS_ERR(pcie->clk))
> + return PTR_ERR(pcie->clk);
> +
> + ret = of_pci_get_max_link_speed(np);
> + pcie->gen = (ret < 0) ? 0 : ret;
> +
> + pcie->ssc = of_property_read_bool(np, "brcm,enable-ssc");
> +
> + ret = pci_parse_request_of_pci_ranges(pcie->dev, &bridge->windows,
> + &bridge->dma_ranges, NULL);
> + if (ret)
> + return ret;
> +
> + ret = clk_prepare_enable(pcie->clk);
> + if (ret) {
> + dev_err(&pdev->dev, "could not enable clock\n");
> + return ret;
> + }
> +
> + ret = brcm_pcie_setup(pcie);
> + if (ret)
> + goto fail;
> +
> + bridge->dev.parent = &pdev->dev;
> + bridge->busnr = 0;
> + bridge->ops = &brcm_pcie_ops;
> + bridge->sysdata = pcie;
> + bridge->map_irq = of_irq_parse_and_map_pci;
> + bridge->swizzle_irq = pci_common_swizzle;
> +
> + ret = pci_scan_root_bus_bridge(bridge);
> + if (ret < 0) {
> + dev_err(pcie->dev, "Scanning root bridge failed\n");
> + goto fail;
> + }
> +
> + pci_assign_unassigned_bus_resources(bridge->bus);
> + list_for_each_entry(child, &bridge->bus->children, node)
> + pcie_bus_configure_settings(child);
> + pci_bus_add_devices(bridge->bus);
> + platform_set_drvdata(pdev, pcie);
> + pcie->root_bus = bridge->bus;
> +
> + return 0;
> +fail:
> + __brcm_pcie_remove(pcie);
> + return ret;
> +}
> +
> +static struct platform_driver brcm_pcie_driver = {
> + .probe = brcm_pcie_probe,
> + .remove = brcm_pcie_remove,
> + .driver = {
> + .name = "brcm-pcie",
> + .of_match_table = brcm_pcie_match,
> + },
> +};
> +
> +module_platform_driver(brcm_pcie_driver);
> +
> +MODULE_LICENSE("GPL v2");
This is different to the SPDX at the start of the file (please see
earlier review comments).
Thanks,
Andrew Murray
[1] https://patchwork.ozlabs.org/patch/1190710/#2301173
> +MODULE_DESCRIPTION("Broadcom STB PCIe RC driver");
> +MODULE_AUTHOR("Broadcom");
> --
> 2.24.0
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 1/6] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions
2019-11-19 12:43 ` Nicolas Saenz Julienne
@ 2019-11-19 16:28 ` Andrew Murray
2019-11-19 16:55 ` Jason Gunthorpe
0 siblings, 1 reply; 36+ messages in thread
From: Andrew Murray @ 2019-11-19 16:28 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Heiko Stuebner, linux-pci, Shawn Lin, Christoph Hellwig,
Marek Szyprowski, Lorenzo Pieralisi, linux-rdma, maz, phil,
iommu, linux-rockchip, f.fainelli, Bjorn Helgaas,
linux-arm-kernel, mbrugger, netdev, linux-kernel, jeremy.linton,
Tom Joseph, wahrenst, james.quinlan, Robin Murphy,
David S. Miller, Tariq Toukan
On Tue, Nov 19, 2019 at 01:43:39PM +0100, Nicolas Saenz Julienne wrote:
> On Tue, 2019-11-19 at 12:30 +0100, Nicolas Saenz Julienne wrote:
> > Hi Andrew, thanks for the review.
> > > > +/**
> > > > + * __roundup_pow_of_two64() - round 64bit value up to nearest power of
> > > > two
> > > > + * @n: value to round up
> > > > + */
> > > > +static inline __attribute__((const)) __u64 __roundup_pow_of_two64(__u64
> > > > n)
> > >
> > > To be consistent with other functions in the same file (__ilog_u64) you may
> > > want to rename this to __roundup_pow_of_two_u64.
> >
> > Sounds good to me.
> >
> > > Also do you know why u64 is used in some places and __u64 in others?
> >
> > That's unwarranted, it should be __u64 everywhere.
>
> Sorry, now that I look deeper into it, it should be u64.
Do you know the reason why? I'd be interested to know.
Thanks,
Andrew Murray
>
> > > > +{
> > > > + return 1UL << fls64(n - 1);
> > >
> > > Does this need to be (and for the others):
> > >
> > > return 1ULL << fls64(n - 1);
> > >
> > > Notice that the PCI drivers you convert, all use 1ULL.
> >
> > Noted
> >
> > Regards,
> > Nicolas
> >
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 1/6] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions
2019-11-19 16:28 ` Andrew Murray
@ 2019-11-19 16:55 ` Jason Gunthorpe
2019-11-19 17:00 ` Andrew Murray
0 siblings, 1 reply; 36+ messages in thread
From: Jason Gunthorpe @ 2019-11-19 16:55 UTC (permalink / raw)
To: Andrew Murray
Cc: Nicolas Saenz Julienne, Heiko Stuebner, linux-pci, Shawn Lin,
Christoph Hellwig, Marek Szyprowski, Lorenzo Pieralisi,
linux-rdma, maz, phil, iommu, linux-rockchip, f.fainelli,
Bjorn Helgaas, linux-arm-kernel, mbrugger, netdev, linux-kernel,
jeremy.linton, Tom Joseph, wahrenst, james.quinlan, Robin Murphy,
David S. Miller, Tariq Toukan
On Tue, Nov 19, 2019 at 04:28:50PM +0000, Andrew Murray wrote:
> On Tue, Nov 19, 2019 at 01:43:39PM +0100, Nicolas Saenz Julienne wrote:
> > On Tue, 2019-11-19 at 12:30 +0100, Nicolas Saenz Julienne wrote:
> > > Hi Andrew, thanks for the review.
> > > > > +/**
> > > > > + * __roundup_pow_of_two64() - round 64bit value up to nearest power of
> > > > > two
> > > > > + * @n: value to round up
> > > > > + */
> > > > > +static inline __attribute__((const)) __u64 __roundup_pow_of_two64(__u64
> > > > > n)
> > > >
> > > > To be consistent with other functions in the same file (__ilog_u64) you may
> > > > want to rename this to __roundup_pow_of_two_u64.
> > >
> > > Sounds good to me.
> > >
> > > > Also do you know why u64 is used in some places and __u64 in others?
> > >
> > > That's unwarranted, it should be __u64 everywhere.
> >
> > Sorry, now that I look deeper into it, it should be u64.
>
> Do you know the reason why? I'd be interested to know.
__u64 must be used in header files that are under uapi - ie it is the
name of the symbol in userspace, and u64 does not exist.
u64 should be used in all code that is only inside the kernel, ie .c
files, internal headers, etc
I routinely discourage use of __uXX in kernel native code.
Jason
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 1/6] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions
2019-11-19 16:55 ` Jason Gunthorpe
@ 2019-11-19 17:00 ` Andrew Murray
0 siblings, 0 replies; 36+ messages in thread
From: Andrew Murray @ 2019-11-19 17:00 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Nicolas Saenz Julienne, Heiko Stuebner, linux-pci, Shawn Lin,
Christoph Hellwig, Marek Szyprowski, Lorenzo Pieralisi,
linux-rdma, maz, phil, iommu, linux-rockchip, f.fainelli,
Bjorn Helgaas, linux-arm-kernel, mbrugger, netdev, linux-kernel,
jeremy.linton, Tom Joseph, wahrenst, james.quinlan, Robin Murphy,
David S. Miller, Tariq Toukan
On Tue, Nov 19, 2019 at 12:55:02PM -0400, Jason Gunthorpe wrote:
> On Tue, Nov 19, 2019 at 04:28:50PM +0000, Andrew Murray wrote:
> > On Tue, Nov 19, 2019 at 01:43:39PM +0100, Nicolas Saenz Julienne wrote:
> > > On Tue, 2019-11-19 at 12:30 +0100, Nicolas Saenz Julienne wrote:
> > > > Hi Andrew, thanks for the review.
> > > > > > +/**
> > > > > > + * __roundup_pow_of_two64() - round 64bit value up to nearest power of
> > > > > > two
> > > > > > + * @n: value to round up
> > > > > > + */
> > > > > > +static inline __attribute__((const)) __u64 __roundup_pow_of_two64(__u64
> > > > > > n)
> > > > >
> > > > > To be consistent with other functions in the same file (__ilog_u64) you may
> > > > > want to rename this to __roundup_pow_of_two_u64.
> > > >
> > > > Sounds good to me.
> > > >
> > > > > Also do you know why u64 is used in some places and __u64 in others?
> > > >
> > > > That's unwarranted, it should be __u64 everywhere.
> > >
> > > Sorry, now that I look deeper into it, it should be u64.
> >
> > Do you know the reason why? I'd be interested to know.
>
> __u64 must be used in header files that are under uapi - ie it is the
> name of the symbol in userspace, and u64 does not exist.
>
> u64 should be used in all code that is only inside the kernel, ie .c
> files, internal headers, etc
>
> I routinely discourage use of __uXX in kernel native code.
Thanks for this, much appreciated!
Andrew Murray
>
> Jason
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver
2019-11-19 16:25 ` Andrew Murray
@ 2019-11-19 18:20 ` Jeremy Linton
2019-11-20 20:24 ` Nicolas Saenz Julienne
2019-11-19 18:34 ` Florian Fainelli
2019-11-20 19:53 ` Nicolas Saenz Julienne
2 siblings, 1 reply; 36+ messages in thread
From: Jeremy Linton @ 2019-11-19 18:20 UTC (permalink / raw)
To: Andrew Murray, Nicolas Saenz Julienne
Cc: maz, linux-kernel, Lorenzo Pieralisi, Eric Anholt, Stefan Wahren,
Florian Fainelli, bcm-kernel-feedback-list, james.quinlan,
mbrugger, phil, Bjorn Helgaas, linux-pci, linux-rpi-kernel,
linux-arm-kernel
Hi,
On 11/19/19 10:25 AM, Andrew Murray wrote:
> On Tue, Nov 12, 2019 at 04:59:23PM +0100, Nicolas Saenz Julienne wrote:
>> From: Jim Quinlan <james.quinlan@broadcom.com>
>>
>> This commit adds the basic Broadcom STB PCIe controller. Missing is the
>> ability to process MSI. This functionality is added in a subsequent
>> commit.
>>
>> The PCIe block contains an MDIO interface. This is a local interface
>> only accessible by the PCIe controller. It cannot be used or shared
>> by any other HW. As such, the small amount of code for this
>> controller is included in this driver as there is little upside to put
>> it elsewhere.
>
> This commit message hasn't changed, despite earlier feedback.
>
Also, unless i'm mistaken this controller isn't I/O coherent on the rpi.
If the commit message is to be updated, it might be nice to mention that
since it is a little unusual.
>>
>> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
>> Co-developed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
>> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
>>
>> ---
>>
>> Changes since v1:
>> - Fix Kconfig
>> - Remove pci domain check
>> - Remove all MSI related code
>> - Remove supend/resume code
>> - Simplify link state wait routine
>> - Prefix all functions
>> - Use of_device_get_match_data()
>> - Use devm_clk_get_optional()
>> - Get rid of irq variable
>> - Use STB all over the driver
>> - Fix license mismatch
>> - Remove unused register definitions
>> - Small cleanups, spell errors
>>
>> NOTE: I decided to remove the suspend/resume routines for now. The
>> RPi4 doesn't need it, and we where having issues with the
>> specifics of the resume function on devices we yet don't support.
>> We'll deal with this in the future.
>>
>> This is based on Jim's original submission[1] but adapted and tailored
>> specifically to bcm2711's needs (that's the Raspberry Pi 4). Support for
>> the rest of the brcmstb family will soon follow once we get support for
>> multiple dma-ranges in dma/direct.
>>
>> [1] https://patchwork.kernel.org/patch/10605959/
>>
>> drivers/pci/controller/Kconfig | 8 +
>> drivers/pci/controller/Makefile | 1 +
>> drivers/pci/controller/pcie-brcmstb.c | 855 ++++++++++++++++++++++++++
>> 3 files changed, 864 insertions(+)
>> create mode 100644 drivers/pci/controller/pcie-brcmstb.c
>>
>> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
>> index f5de9119e8d3..486d4d570233 100644
>> --- a/drivers/pci/controller/Kconfig
>> +++ b/drivers/pci/controller/Kconfig
>> @@ -281,6 +281,14 @@ config VMD
>> To compile this driver as a module, choose M here: the
>> module will be called vmd.
>>
>> +config PCIE_BRCMSTB
>> + bool "Broadcom Brcmstb PCIe host controller"
>> + depends on ARCH_BCM2835 || COMPILE_TEST
>> + depends on OF
>> + help
>> + Say Y here to enable PCIe host controller support for
>> + Broadcom STB based SoCs, like the Raspberry Pi 4.
>> +
>> config PCI_HYPERV_INTERFACE
>> tristate "Hyper-V PCI Interface"
>> depends on X86 && HYPERV && PCI_MSI && PCI_MSI_IRQ_DOMAIN && X86_64
>> diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
>> index a2a22c9d91af..3fc0b0cf5b5b 100644
>> --- a/drivers/pci/controller/Makefile
>> +++ b/drivers/pci/controller/Makefile
>> @@ -30,6 +30,7 @@ obj-$(CONFIG_PCIE_MEDIATEK) += pcie-mediatek.o
>> obj-$(CONFIG_PCIE_MOBIVEIL) += pcie-mobiveil.o
>> obj-$(CONFIG_PCIE_TANGO_SMP8759) += pcie-tango.o
>> obj-$(CONFIG_VMD) += vmd.o
>> +obj-$(CONFIG_PCIE_BRCMSTB) += pcie-brcmstb.o
>> # pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
>> obj-y += dwc/
>>
>> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
>> new file mode 100644
>> index 000000000000..8d81c5ab5979
>> --- /dev/null
>> +++ b/drivers/pci/controller/pcie-brcmstb.c
>> @@ -0,0 +1,855 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/* Copyright (C) 2009 - 2019 Broadcom */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/compiler.h>
>> +#include <linux/delay.h>
>> +#include <linux/init.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/ioport.h>
>> +#include <linux/irqdomain.h>
>> +#include <linux/kernel.h>
>> +#include <linux/list.h>
>> +#include <linux/log2.h>
>> +#include <linux/module.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_irq.h>
>> +#include <linux/of_pci.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/pci.h>
>> +#include <linux/printk.h>
>> +#include <linux/sizes.h>
>> +#include <linux/slab.h>
>> +#include <linux/string.h>
>> +#include <linux/types.h>
>> +
>> +#include "../pci.h"
>> +
>> +/* BRCM_PCIE_CAP_REGS - Offset for the mandatory capability config regs */
>> +#define BRCM_PCIE_CAP_REGS 0x00ac
>> +
>> +/*
>> + * Broadcom STB PCIe Register Offsets. The names are from the chip's RDB and we
>> + * use them here so that a script can correlate this code and the RDB to
>> + * prevent discrepancies.
>> + */
>> +#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1 0x0188
>> +#define PCIE_RC_CFG_PRIV1_ID_VAL3 0x043c
>> +#define PCIE_RC_DL_MDIO_ADDR 0x1100
>> +#define PCIE_RC_DL_MDIO_WR_DATA 0x1104
>> +#define PCIE_RC_DL_MDIO_RD_DATA 0x1108
>> +#define PCIE_MISC_MISC_CTRL 0x4008
>> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO 0x400c
>> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI 0x4010
>> +#define PCIE_MISC_RC_BAR1_CONFIG_LO 0x402c
>> +#define PCIE_MISC_RC_BAR2_CONFIG_LO 0x4034
>> +#define PCIE_MISC_RC_BAR2_CONFIG_HI 0x4038
>> +#define PCIE_MISC_RC_BAR3_CONFIG_LO 0x403c
>> +#define PCIE_MISC_PCIE_CTRL 0x4064
>> +#define PCIE_MISC_PCIE_STATUS 0x4068
>> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT 0x4070
>> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI 0x4080
>> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI 0x4084
>> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
>> +#define PCIE_INTR2_CPU_BASE 0x4300
>> +
>> +/*
>> + * Broadcom STB PCIe Register Field shift and mask info. The names are from the
>> + * chip's RDB and we use them here so that a script can correlate this code and
>> + * the RDB to prevent discrepancies.
>> + */
>> +#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_MASK 0xc
>> +#define PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1_ENDIAN_MODE_BAR2_SHIFT 0x2
>> +#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_MASK 0xffffff
>> +#define PCIE_RC_CFG_PRIV1_ID_VAL3_CLASS_CODE_SHIFT 0x0
>> +#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK 0x1000
>> +#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_SHIFT 0xc
>> +#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK 0x2000
>> +#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_SHIFT 0xd
>> +#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
>> +#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_SHIFT 0x14
>> +#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
>> +#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_SHIFT 0x1b
>> +#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_MASK 0x1f
>> +#define PCIE_MISC_RC_BAR1_CONFIG_LO_SIZE_SHIFT 0x0
>> +#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_MASK 0x1f
>> +#define PCIE_MISC_RC_BAR2_CONFIG_LO_SIZE_SHIFT 0x0
>> +#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_MASK 0x1f
>> +#define PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_SHIFT 0x0
>> +#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK 0x1
>> +#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_SHIFT 0x0
>> +#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_MASK 0x80
>> +#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_SHIFT 0x7
>> +#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_MASK 0x20
>> +#define PCIE_MISC_PCIE_STATUS_PCIE_DL_ACTIVE_SHIFT 0x5
>> +#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_MASK 0x10
>> +#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_SHIFT 0x4
>> +#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK 0x40
>> +#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_SHIFT 0x6
>> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_MASK 0xfff00000
>> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_SHIFT 0x14
>> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK 0xfff0
>> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_SHIFT 0x4
>> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS 0xc
>> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_MASK 0xff
>> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI_BASE_SHIFT 0x0
>> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_MASK 0xff
>> +#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI_LIMIT_SHIFT 0x0
>> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK 0x2
>> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_SHIFT 0x1
>> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
>> +#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_SHIFT 0x1b
>> +#define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1
>> +#define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0
>> +
>> +#define BRCM_NUM_PCIE_OUT_WINS 0x4
>> +
>> +#define BURST_SIZE_128 0
>> +
>> +/* Offsets from PCIE_INTR2_CPU_BASE */
>> +#define STATUS 0x0
>> +#define CLR 0x8
>> +#define MASK_SET 0x10
>> +#define MASK_CLR 0x14
>> +
>> +#define PCIE_BUSNUM_SHIFT 20
>> +#define PCIE_SLOT_SHIFT 15
>> +#define PCIE_FUNC_SHIFT 12
>> +
>> +#if defined(__BIG_ENDIAN)
>> +#define DATA_ENDIAN 2 /* PCIe->DDR inbound traffic */
>> +#define MMIO_ENDIAN 2 /* CPU->PCIe outbound traffic */
>> +#else
>> +#define DATA_ENDIAN 0
>> +#define MMIO_ENDIAN 0
>> +#endif
>> +
>> +#define MDIO_PORT0 0x0
>> +#define MDIO_DATA_MASK 0x7fffffff
>> +#define MDIO_DATA_SHIFT 0x0
>> +#define MDIO_PORT_MASK 0xf0000
>> +#define MDIO_PORT_SHIFT 0x16
>> +#define MDIO_REGAD_MASK 0xffff
>> +#define MDIO_REGAD_SHIFT 0x0
>> +#define MDIO_CMD_MASK 0xfff00000
>> +#define MDIO_CMD_SHIFT 0x14
>> +#define MDIO_CMD_READ 0x1
>> +#define MDIO_CMD_WRITE 0x0
>> +#define MDIO_DATA_DONE_MASK 0x80000000
>> +#define MDIO_RD_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 1 : 0)
>> +#define MDIO_WT_DONE(x) (((x) & MDIO_DATA_DONE_MASK) ? 0 : 1)
>> +#define SSC_REGS_ADDR 0x1100
>> +#define SET_ADDR_OFFSET 0x1f
>> +#define SSC_CNTL_OFFSET 0x2
>> +#define SSC_CNTL_OVRD_EN_MASK 0x8000
>> +#define SSC_CNTL_OVRD_EN_SHIFT 0xf
>> +#define SSC_CNTL_OVRD_VAL_MASK 0x4000
>> +#define SSC_CNTL_OVRD_VAL_SHIFT 0xe
>> +#define SSC_STATUS_OFFSET 0x1
>> +#define SSC_STATUS_SSC_MASK 0x400
>> +#define SSC_STATUS_SSC_SHIFT 0xa
>> +#define SSC_STATUS_PLL_LOCK_MASK 0x800
>> +#define SSC_STATUS_PLL_LOCK_SHIFT 0xb
>> +
>> +#define BRCM_PCIE_IDX_ADDR(pcie) \
>> + ((pcie)->reg_offsets[EXT_CFG_INDEX])
>> +#define BRCM_PCIE_DATA_ADDR(pcie) \
>> + ((pcie)->reg_offsets[EXT_CFG_DATA])
>> +#define BRCM_PCIE_RGR1_SW_INIT_1(pcie) \
>> + ((pcie)->reg_offsets[RGR1_SW_INIT_1])
>> +
>> +enum {
>> + RGR1_SW_INIT_1,
>> + EXT_CFG_INDEX,
>> + EXT_CFG_DATA,
>> +};
>> +
>> +enum {
>> + RGR1_SW_INIT_1_INIT_MASK,
>> + RGR1_SW_INIT_1_INIT_SHIFT,
>> + RGR1_SW_INIT_1_PERST_MASK,
>> + RGR1_SW_INIT_1_PERST_SHIFT,
>> +};
>> +
>> +enum pcie_type {
>> + BCM2711,
>> +};
>> +
>> +struct brcm_window {
>> + dma_addr_t pcie_addr;
>> + phys_addr_t cpu_addr;
>> + dma_addr_t size;
>> +};
>> +
>> +/* Internal PCIe Host Controller Information.*/
>> +struct brcm_pcie {
>> + struct device *dev;
>> + void __iomem *base;
>> + struct clk *clk;
>> + struct pci_bus *root_bus;
>> + struct device_node *np;
>> + bool ssc;
>> + int gen;
>> + struct brcm_window out_wins[BRCM_NUM_PCIE_OUT_WINS];
>> + const int *reg_offsets;
>> + const int *reg_field_info;
>> + enum pcie_type type;
>> +};
>> +
>> +struct pcie_cfg_data {
>> + const int *reg_field_info;
>> + const int *offsets;
>> + const enum pcie_type type;
>> +};
>> +
>> +static const int pcie_reg_field_info[] = {
>> + [RGR1_SW_INIT_1_INIT_MASK] = 0x2,
>> + [RGR1_SW_INIT_1_INIT_SHIFT] = 0x1,
>> +};
>> +
>> +static const int pcie_offset_bcm2711[] = {
>> + [RGR1_SW_INIT_1] = 0x9210,
>> + [EXT_CFG_INDEX] = 0x9000,
>> + [EXT_CFG_DATA] = 0x8000,
>> +};
>> +
>> +static const struct pcie_cfg_data bcm2711_cfg = {
>> + .reg_field_info = pcie_reg_field_info,
>> + .offsets = pcie_offset_bcm2711,
>> + .type = BCM2711,
>> +};
>> +
>> +static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
>> + int where);
>> +
>> +static struct pci_ops brcm_pcie_ops = {
>> + .map_bus = brcm_pcie_map_conf,
>> + .read = pci_generic_config_read,
>> + .write = pci_generic_config_write,
>> +};
>> +
>> +#define bcm_readl(a) readl(a)
>> +#define bcm_writel(d, a) writel(d, a)
>> +#define bcm_readw(a) readw(a)
>> +#define bcm_writew(d, a) writew(d, a)
>> +
>> +/* These macros extract/insert fields to host controller's register set. */
>> +#define RD_FLD(base, reg, field) \
>> + brcm_pcie_rd_fld((base) + reg, reg##_##field##_MASK, \
>> + reg##_##field##_SHIFT)
>> +#define WR_FLD(base, reg, field, val) \
>> + brcm_pcie_wr_fld((base) + reg, reg##_##field##_MASK, \
>> + reg##_##field##_SHIFT, val)
>> +#define WR_FLD_RB(base, reg, field, val) \
>> + brcm_pcie_wr_fld_rb((base) + reg, reg##_##field##_MASK, \
>> + reg##_##field##_SHIFT, val)
>> +#define WR_FLD_WITH_OFFSET(base, off, reg, field, val) \
>> + brcm_pcie_wr_fld((base) + reg + (off), reg##_##field##_MASK, \
>> + reg##_##field##_SHIFT, val)
>> +#define EXTRACT_FIELD(val, reg, field) \
>> + (((val) & reg##_##field##_MASK) >> reg##_##field##_SHIFT)
>> +#define INSERT_FIELD(val, reg, field, field_val) \
>> + (((val) & ~reg##_##field##_MASK) | \
>> + (reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
>
> Can you use any of the existing macros in linux/bitfield.h
> (e.g. ...replace_bits...) ?
>
>> +
>> +static u32 brcm_pcie_rd_fld(void __iomem *p, u32 mask, int shift)
>> +{
>> + return (bcm_readl(p) & mask) >> shift;
>> +}
>> +
>> +static void brcm_pcie_wr_fld(void __iomem *p, u32 mask, int shift, u32 val)
>> +{
>> + u32 reg = bcm_readl(p);
>> +
>> + reg = (reg & ~mask) | ((val << shift) & mask);
>> + bcm_writel(reg, p);
>> +}
>> +
>> +static void brcm_pcie_wr_fld_rb(void __iomem *p, u32 mask, int shift, u32 val)
>> +{
>> + brcm_pcie_wr_fld(p, mask, shift, val);
>> + (void)bcm_readl(p);
>> +}
>> +
>> +/*
>> + * This is to convert the size of the inbound "BAR" region to the
>> + * non-linear values of PCIE_X_MISC_RC_BAR[123]_CONFIG_LO.SIZE
>> + */
>> +int brcm_pcie_encode_ibar_size(u64 size)
>> +{
>> + int log2_in = ilog2(size);
>> +
>> + if (log2_in >= 12 && log2_in <= 15)
>> + /* Covers 4KB to 32KB (inclusive) */
>> + return (log2_in - 12) + 0x1c;
>> + else if (log2_in >= 16 && log2_in <= 35)
>> + /* Covers 64KB to 32GB, (inclusive) */
>> + return log2_in - 15;
>> + /* Something is awry so disable */
>> + return 0;
>> +}
>> +
>> +static u32 brcm_pcie_mdio_form_pkt(int port, int regad, int cmd)
>> +{
>> + u32 pkt = 0;
>> +
>> + pkt |= (port << MDIO_PORT_SHIFT) & MDIO_PORT_MASK;
>> + pkt |= (regad << MDIO_REGAD_SHIFT) & MDIO_REGAD_MASK;
>> + pkt |= (cmd << MDIO_CMD_SHIFT) & MDIO_CMD_MASK;
>> +
>> + return pkt;
>> +}
>> +
>> +/* negative return value indicates error */
>> +static int brcm_pcie_mdio_read(void __iomem *base, u8 port, u8 regad)
>> +{
>> + int tries;
>> + u32 data;
>> +
>> + bcm_writel(brcm_pcie_mdio_form_pkt(port, regad, MDIO_CMD_READ),
>> + base + PCIE_RC_DL_MDIO_ADDR);
>> + bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
>> +
>> + data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
>> + for (tries = 0; !MDIO_RD_DONE(data) && tries < 10; tries++) {
>> + udelay(10);
>> + data = bcm_readl(base + PCIE_RC_DL_MDIO_RD_DATA);
>> + }
>> +
>> + return MDIO_RD_DONE(data)
>> + ? (data & MDIO_DATA_MASK) >> MDIO_DATA_SHIFT
>> + : -EIO;
>> +}
>> +
>> +/* negative return value indicates error */
>> +static int brcm_pcie_mdio_write(void __iomem *base, u8 port,
>> + u8 regad, u16 wrdata)
>> +{
>> + int tries;
>> + u32 data;
>> +
>> + bcm_writel(brcm_pcie_mdio_form_pkt(port, regad, MDIO_CMD_WRITE),
>> + base + PCIE_RC_DL_MDIO_ADDR);
>> + bcm_readl(base + PCIE_RC_DL_MDIO_ADDR);
>> + bcm_writel(MDIO_DATA_DONE_MASK | wrdata,
>> + base + PCIE_RC_DL_MDIO_WR_DATA);
>> +
>> + data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
>> + for (tries = 0; !MDIO_WT_DONE(data) && tries < 10; tries++) {
>> + udelay(10);
>> + data = bcm_readl(base + PCIE_RC_DL_MDIO_WR_DATA);
>> + }
>> +
>> + return MDIO_WT_DONE(data) ? 0 : -EIO;
>> +}
>> +
>> +/*
>> + * Configures device for Spread Spectrum Clocking (SSC) mode; a negative
>> + * return value indicates error.
>> + */
>> +static int brcm_pcie_set_ssc(void __iomem *base)
>> +{
>> + int pll, ssc;
>> + u16 wrdata;
>> + int tmp;
>> +
>> + tmp = brcm_pcie_mdio_write(base, MDIO_PORT0, SET_ADDR_OFFSET,
>> + SSC_REGS_ADDR);
>> + if (tmp < 0)
>> + return tmp;
>> +
>> + tmp = brcm_pcie_mdio_read(base, MDIO_PORT0, SSC_CNTL_OFFSET);
>> + if (tmp < 0)
>> + return tmp;
>> +
>> + wrdata = INSERT_FIELD(tmp, SSC_CNTL_OVRD, EN, 1);
>> + wrdata = INSERT_FIELD(wrdata, SSC_CNTL_OVRD, VAL, 1);
>> + tmp = brcm_pcie_mdio_write(base, MDIO_PORT0, SSC_CNTL_OFFSET, wrdata);
>> + if (tmp < 0)
>> + return tmp;
>> +
>> + usleep_range(1000, 2000);
>> + tmp = brcm_pcie_mdio_read(base, MDIO_PORT0, SSC_STATUS_OFFSET);
>> + if (tmp < 0)
>> + return tmp;
>> +
>> + ssc = EXTRACT_FIELD(tmp, SSC_STATUS, SSC);
>> + pll = EXTRACT_FIELD(tmp, SSC_STATUS, PLL_LOCK);
>> +
>> + return (ssc && pll) ? 0 : -EIO;
>> +}
>> +
>> +/* Limits operation to a specific generation (1, 2, or 3) */
>> +static void brcm_pcie_set_gen(void __iomem *base, int gen)
>> +{
>> + u32 lnkcap = bcm_readl(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCAP);
>> + u16 lnkctl2 = bcm_readw(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCTL2);
>> +
>> + lnkcap = (lnkcap & ~PCI_EXP_LNKCAP_SLS) | gen;
>> + bcm_writel(lnkcap, base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCAP);
>> +
>> + lnkctl2 = (lnkctl2 & ~0xf) | gen;
>> + bcm_writew(lnkctl2, base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKCTL2);
>> +}
>> +
>> +static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
>> + unsigned int win, phys_addr_t cpu_addr,
>> + dma_addr_t pcie_addr, dma_addr_t size)
>> +{
>> + phys_addr_t cpu_addr_mb, limit_addr_mb;
>> + void __iomem *base = pcie->base;
>> + u32 tmp;
>> +
>> + /* Set the base of the pcie_addr window */
>> + bcm_writel(lower_32_bits(pcie_addr) + MMIO_ENDIAN,
>> + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + (win * 8));
>> + bcm_writel(upper_32_bits(pcie_addr),
>> + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + (win * 8));
>> +
>> + cpu_addr_mb = cpu_addr >> 20;
>> + limit_addr_mb = (cpu_addr + size - 1) >> 20;
>> +
>> + /* Write the addr base low register */
>> + WR_FLD_WITH_OFFSET(base, (win * 4),
>> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
>> + BASE, cpu_addr_mb);
>> + /* Write the addr limit low register */
>> + WR_FLD_WITH_OFFSET(base, (win * 4),
>> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
>> + LIMIT, limit_addr_mb);
>> +
>> + /* Write the cpu addr high register */
>> + tmp = (u32)(cpu_addr_mb >>
>> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
>
> Despite the name _MASK_BITS, this isn't being used as a mask. Is this making
> some assumption about the value of cpu_addr from the DT?
>
> Ideally we'd just use the value from the DT as we do for the low register.
>
>> + WR_FLD_WITH_OFFSET(base, (win * 8),
>> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI,
>> + BASE, tmp);
>> + /* Write the cpu limit high register */
>> + tmp = (u32)(limit_addr_mb >>
>> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
>> + WR_FLD_WITH_OFFSET(base, (win * 8),
>> + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI,
>> + LIMIT, tmp);
>> +}
>> +
>> +/* Configuration space read/write support */
>> +static int brcm_pcie_cfg_index(int busnr, int devfn, int reg)
>> +{
>> + return ((PCI_SLOT(devfn) & 0x1f) << PCIE_SLOT_SHIFT)
>> + | ((PCI_FUNC(devfn) & 0x07) << PCIE_FUNC_SHIFT)
>> + | (busnr << PCIE_BUSNUM_SHIFT)
>> + | (reg & ~3);
>> +}
>> +
>> +/* The controller is capable of serving in both RC and EP roles */
>> +static bool brcm_pcie_rc_mode(struct brcm_pcie *pcie)
>> +{
>> + void __iomem *base = pcie->base;
>> + u32 val = bcm_readl(base + PCIE_MISC_PCIE_STATUS);
>> +
>> + return !!EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PORT);
>> +}
>> +
>> +static bool brcm_pcie_link_up(struct brcm_pcie *pcie)
>> +{
>> + void __iomem *base = pcie->base;
>> + u32 val = bcm_readl(base + PCIE_MISC_PCIE_STATUS);
>> + u32 dla = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_DL_ACTIVE);
>> + u32 plu = EXTRACT_FIELD(val, PCIE_MISC_PCIE_STATUS, PCIE_PHYLINKUP);
>> +
>> + return (dla && plu) ? true : false;
>> +}
>> +
>> +static void __iomem *brcm_pcie_map_conf(struct pci_bus *bus, unsigned int devfn,
>> + int where)
>> +{
>> + struct brcm_pcie *pcie = bus->sysdata;
>> + void __iomem *base = pcie->base;
>> + int idx;
>> +
>> + /* Accesses to the RC go right to the RC registers if slot==0 */
>> + if (pci_is_root_bus(bus))
>> + return PCI_SLOT(devfn) ? NULL : base + where;
>> +
>> + /* For devices, write to the config space index register */
>> + idx = brcm_pcie_cfg_index(bus->number, devfn, 0);
>> + bcm_writel(idx, pcie->base + BRCM_PCIE_IDX_ADDR(pcie));
>> + return base + BRCM_PCIE_DATA_ADDR(pcie) + where;
>> +}
>> +
>> +static inline void brcm_pcie_bridge_sw_init_set(struct brcm_pcie *pcie,
>> + unsigned int val)
>> +{
>> + unsigned int shift = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_SHIFT];
>> + u32 mask = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_MASK];
>> +
>> + brcm_pcie_wr_fld_rb(pcie->base + BRCM_PCIE_RGR1_SW_INIT_1(pcie),
>> + mask, shift, val);
>> +}
>> +
>> +static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie,
>> + unsigned int val)
>> +{
>> + brcm_pcie_wr_fld_rb(pcie->base + BRCM_PCIE_RGR1_SW_INIT_1(pcie),
>> + PCIE_RGR1_SW_INIT_1_PERST_MASK,
>> + PCIE_RGR1_SW_INIT_1_PERST_SHIFT, val);
>> +}
>> +
>> +static inline int brcm_pcie_get_rc_bar2_size_and_offset(struct brcm_pcie *pcie,
>> + u64 *rc_bar2_size,
>> + u64 *rc_bar2_offset)
>> +{
>> + struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
>> + struct device *dev = pcie->dev;
>> + struct resource_entry *entry;
>> + u64 total_mem_size = 0;
>> +
>> + *rc_bar2_offset = -1;
>> +
>> + resource_list_for_each_entry(entry, &bridge->dma_ranges) {
>> + /*
>> + * We're promised the RC will provide a contiguous view of
>> + * memory to downstream devices. We can then infer the
>> + * rc_bar2_offset from the lower available dma-range offset.
>> + */
>> + if (entry->offset < *rc_bar2_offset)
>> + *rc_bar2_offset = entry->offset;
>> +
>> + total_mem_size += entry->res->end - entry->res->start + 1;
>
> This requires that if there are multiple dma-ranges, then there are no gaps
> between them right?
>
>> + }
>> +
>> + *rc_bar2_size = roundup_pow_of_two64(total_mem_size);
>> +
>> + /*
>> + * Validate the results:
>> + *
>> + * The PCIe host controller by design must set the inbound viewport to
>> + * be a contiguous arrangement of all of the system's memory. In
>> + * addition, its size mut be a power of two. To further complicate
>> + * matters, the viewport must start on a pcie-address that is aligned
>> + * on a multiple of its size. If a portion of the viewport does not
>> + * represent system memory -- e.g. 3GB of memory requires a 4GB
>> + * viewport -- we can map the outbound memory in or after 3GB and even
>> + * though the viewport will overlap the outbound memory the controller
>> + * will know to send outbound memory downstream and everything else
>> + * upstream.
>> + *
>> + * For example:
>> + *
>> + * - The best-case scenario, memory up to 3GB, is to place the inbound
>> + * region in the first 4GB of pcie-space, as some legacy devices can
>> + * only address 32bits. We would also like to put the MSI under 4GB
>> + * as well, since some devices require a 32bit MSI target address.
>> + *
>> + * - If the system memory is 4GB or larger we cannot start the inbound
>> + * region at location 0 (since we have to allow some space for
>> + * outbound memory @ 3GB). So instead it will start at the 1x
>> + * multiple of its size
>> + */
>> + if (!*rc_bar2_size || *rc_bar2_offset % *rc_bar2_size ||
>> + (*rc_bar2_offset < SZ_4G && *rc_bar2_offset > SZ_2G)) {
>> + dev_err(dev, "Invalid rc_bar2_offset/size: size 0x%llx, off 0x%llx\n",
>> + *rc_bar2_size, *rc_bar2_offset);
>> + return -EINVAL;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int brcm_pcie_setup(struct brcm_pcie *pcie)
>> +{
>> + struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
>> + u64 rc_bar2_offset, rc_bar2_size;
>> + void __iomem *base = pcie->base;
>> + struct device *dev = pcie->dev;
>> + struct resource_entry *entry;
>> + unsigned int scb_size_val;
>> + bool ssc_good = false;
>> + struct resource *res;
>> + int num_out_wins = 0;
>> + u16 nlw, cls, lnksta;
>> + int i, ret;
>> + u32 tmp;
>> +
>> + /* Reset the bridge */
>> + brcm_pcie_bridge_sw_init_set(pcie, 1);
>> +
>> + usleep_range(100, 200);
>> +
>> + /* Take the bridge out of reset */
>> + brcm_pcie_bridge_sw_init_set(pcie, 0);
>> +
>> + WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
>> + /* Wait for SerDes to be stable */
>> + usleep_range(100, 200);
>> +
>> + /* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
>> + tmp = INSERT_FIELD(0, PCIE_MISC_MISC_CTRL, SCB_ACCESS_EN, 1);
>> + tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, CFG_READ_UR_MODE, 1);
>> + tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, MAX_BURST_SIZE,
>> + BURST_SIZE_128);
>> + bcm_writel(tmp, base + PCIE_MISC_MISC_CTRL);
>> +
>> + ret = brcm_pcie_get_rc_bar2_size_and_offset(pcie, &rc_bar2_size,
>> + &rc_bar2_offset);
>> + if (ret)
>> + return ret;
>> +
>> + tmp = lower_32_bits(rc_bar2_offset);
>> + tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
>> + brcm_pcie_encode_ibar_size(rc_bar2_size));
>> + bcm_writel(tmp, base + PCIE_MISC_RC_BAR2_CONFIG_LO);
>> + bcm_writel(upper_32_bits(rc_bar2_offset),
>> + base + PCIE_MISC_RC_BAR2_CONFIG_HI);
>> +
>> + scb_size_val = rc_bar2_size ?
>> + ilog2(rc_bar2_size) - 15 : 0xf; /* 0xf is 1GB */
>> + WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB0_SIZE, scb_size_val);
>> +
>> + /* disable the PCIe->GISB memory window (RC_BAR1) */
>> + WR_FLD(base, PCIE_MISC_RC_BAR1_CONFIG_LO, SIZE, 0);
>> +
>> + /* disable the PCIe->SCB memory window (RC_BAR3) */
>> + WR_FLD(base, PCIE_MISC_RC_BAR3_CONFIG_LO, SIZE, 0);
>> +
>> + /* clear any interrupts we find on boot */
>> + bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + CLR);
>> + (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + CLR);
>> +
>> + /* Mask all interrupts since we are not handling any yet */
>> + bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + MASK_SET);
>> + (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + MASK_SET);
>
> Should you change the order and mask before clearing the interrupts?
>
>> +
>> + if (pcie->gen)
>> + brcm_pcie_set_gen(base, pcie->gen);
>> +
>> + /* Unassert the fundamental reset */
>> + brcm_pcie_perst_set(pcie, 0);
>> +
>> + /*
>> + * Give the RC/EP time to wake up, before trying to configure RC.
>> + * Intermittently check status for link-up, up to a total of 100ms.
>> + */
>> + for (i = 0; i < 100 && !brcm_pcie_link_up(pcie); i += 5)
>> + msleep(5);
>> +
>> + if (!brcm_pcie_link_up(pcie)) {
>> + dev_info(dev, "link down\n");
>> + return -ENODEV;
>> + }
>> +
>> + if (!brcm_pcie_rc_mode(pcie)) {
>> + dev_err(dev, "PCIe misconfigured; is in EP mode\n");
>> + return -EINVAL;
>> + }
>> +
>> + resource_list_for_each_entry(entry, &bridge->windows) {
>> + res = entry->res;
>> +
>> + if (resource_type(res) != IORESOURCE_MEM)
>> + continue;
>> +
>> + if (num_out_wins >= BRCM_NUM_PCIE_OUT_WINS) {
>> + dev_err(pcie->dev, "too many outbound wins\n");
>> + return -EINVAL;
>> + }
>> +
>> + brcm_pcie_set_outbound_win(pcie, num_out_wins, res->start,
>> + res->start - entry->offset,
>> + res->end - res->start + 1);
>> + num_out_wins++;
>> + }
>> +
>> + /*
>> + * For config space accesses on the RC, show the right class for
>> + * a PCIe-PCIe bridge (the default setting is to be EP mode).
>> + */
>> + WR_FLD_RB(base, PCIE_RC_CFG_PRIV1_ID_VAL3, CLASS_CODE, 0x060400);
>
> Why does this need to be _RB ? I haven't looked at all of the uses of _RB
> though I think there are others that may not be necessary.
>
>> +
>> + if (pcie->ssc) {
>> + ret = brcm_pcie_set_ssc(base);
>> + if (ret == 0)
>> + ssc_good = true;
>> + else
>> + dev_err(dev, "failed attempt to enter ssc mode\n");
>> + }
>> +
>> + lnksta = bcm_readw(base + BRCM_PCIE_CAP_REGS + PCI_EXP_LNKSTA);
>> + cls = lnksta & PCI_EXP_LNKSTA_CLS;
>> + nlw = (lnksta & PCI_EXP_LNKSTA_NLW) >> PCI_EXP_LNKSTA_NLW_SHIFT;
>> + dev_info(dev, "link up, %s x%u %s\n",
>> + PCIE_SPEED2STR(cls + PCI_SPEED_133MHz_PCIX_533),
>> + nlw, ssc_good ? "(SSC)" : "(!SSC)");
>> +
>> + /* PCIe->SCB endian mode for BAR */
>> + /* field ENDIAN_MODE_BAR2 = DATA_ENDIAN */
>> + WR_FLD_RB(base, PCIE_RC_CFG_VENDOR_VENDOR_SPECIFIC_REG1,
>> + ENDIAN_MODE_BAR2, DATA_ENDIAN);
>> +
>> + /*
>> + * Refclk from RC should be gated with CLKREQ# input when ASPM L0s,L1
>> + * is enabled => setting the CLKREQ_DEBUG_ENABLE field to 1.
>> + */
>> + WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, CLKREQ_DEBUG_ENABLE, 1);
>> +
>> + return 0;
>> +}
>> +
>> +/* L23 is a low-power PCIe link state */
>> +static void brcm_pcie_enter_l23(struct brcm_pcie *pcie)
>> +{
>> + void __iomem *base = pcie->base;
>> + int l23, i;
>> +
>> + /* assert request for L23 */
>> + WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 1);
>
> Also not sure about the _RB here, given you have a read straight after.
>
>> +
>> + /* Wait up to 36 msec for L23 */
>> + l23 = RD_FLD(base, PCIE_MISC_PCIE_STATUS, PCIE_LINK_IN_L23);
>> + for (i = 0; i < 15 && !l23; i++) {
>> + usleep_range(2000, 2400);
>> + l23 = RD_FLD(base, PCIE_MISC_PCIE_STATUS, PCIE_LINK_IN_L23);
>> + }
>> +
>> + if (!l23)
>> + dev_err(pcie->dev, "failed to enter low-power link state\n");
>> +}
>> +
>> +static void brcm_pcie_turn_off(struct brcm_pcie *pcie)
>> +{
>> + void __iomem *base = pcie->base;
>> +
>> + if (brcm_pcie_link_up(pcie))
>> + brcm_pcie_enter_l23(pcie);
>> + /* Assert fundamental reset */
>> + brcm_pcie_perst_set(pcie, 1);
>> + /* Deassert request for L23 in case it was asserted */
>> + WR_FLD_RB(base, PCIE_MISC_PCIE_CTRL, PCIE_L23_REQUEST, 0);
>> + /* Turn off SerDes */
>> + WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 1);
>> + /* Shutdown PCIe bridge */
>
> What is the purpose of the _RB's here?
>
>> + brcm_pcie_bridge_sw_init_set(pcie, 1);
>> +}
>> +
>> +static void __brcm_pcie_remove(struct brcm_pcie *pcie)
>> +{
>> + brcm_pcie_turn_off(pcie);
>> + clk_disable_unprepare(pcie->clk);
>> + clk_put(pcie->clk);
>> +}
>> +
>> +static int brcm_pcie_remove(struct platform_device *pdev)
>> +{
>> + struct brcm_pcie *pcie = platform_get_drvdata(pdev);
>> +
>> + pci_stop_root_bus(pcie->root_bus);
>> + pci_remove_root_bus(pcie->root_bus);
>> + __brcm_pcie_remove(pcie);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id brcm_pcie_match[] = {
>> + { .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
>
> I'd rather see use of the pcie_cfg_data structure removed from this series.
>
> I've seen the comments in the previous thread [1], and I understand that
> the intention is that this driver will eventually be used for other SOCs.
>
> However this indirection isn't needed *now* and it makes reviewing this
> patch more difficult. If and when a later series is made to cover other
> SOCs - then I'd expect that series to find a way to apply this indirection.
>
> And if that later series is more difficult to review because of the newly
> added indirection, then I'd expect an early patch of that series to apply
> the indirection in a single patch - which would be easy to review.
>
> The other risk of such premature changes like this is that when you come
> to adding other SOCs, you may then discover that there were shortcomings
> in the way you've approached it here.
>
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, brcm_pcie_match);
>> +
>> +static int brcm_pcie_probe(struct platform_device *pdev)
>> +{
>> + struct device_node *np = pdev->dev.of_node;
>> + const struct pcie_cfg_data *data;
>> + struct pci_host_bridge *bridge;
>> + struct brcm_pcie *pcie;
>> + struct pci_bus *child;
>> + struct resource *res;
>> + int ret;
>> +
>> + bridge = devm_pci_alloc_host_bridge(&pdev->dev, sizeof(*pcie));
>> + if (!bridge)
>> + return -ENOMEM;
>> +
>> + pcie = pci_host_bridge_priv(bridge);
>
> Nit: I'd suggest moving the above line so it sits just above the
> "pcie->reg_offsets = data->offsets;" line. It looks nicer.
>
>> +
>> + data = of_device_get_match_data(&pdev->dev);
>> + if (!data) {
>> + dev_err(&pdev->dev, "failed to look up compatible string\n");
>
> Nit: If there is a failure here, it's probably because there is no data
> defined in the brcm_pcie_match structure - seeing as we wouldn't get here
> if we didn't have a compatible string. I'd suggest rewording the err slightly
> or even removing it.
>
>> + return -EINVAL;
>> + }
>> +
>> + pcie->reg_offsets = data->offsets;
>> + pcie->reg_field_info = data->reg_field_info;
>> + pcie->type = data->type;
>> + pcie->np = np;
>> + pcie->dev = &pdev->dev;
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + pcie->base = devm_ioremap_resource(&pdev->dev, res);
>> + if (IS_ERR(pcie->base))
>> + return PTR_ERR(pcie->base);
>> +
>> + pcie->clk = devm_clk_get_optional(&pdev->dev, "sw_pcie");
>> + if (IS_ERR(pcie->clk))
>> + return PTR_ERR(pcie->clk);
>> +
>> + ret = of_pci_get_max_link_speed(np);
>> + pcie->gen = (ret < 0) ? 0 : ret;
>> +
>> + pcie->ssc = of_property_read_bool(np, "brcm,enable-ssc");
>> +
>> + ret = pci_parse_request_of_pci_ranges(pcie->dev, &bridge->windows,
>> + &bridge->dma_ranges, NULL);
>> + if (ret)
>> + return ret;
>> +
>> + ret = clk_prepare_enable(pcie->clk);
>> + if (ret) {
>> + dev_err(&pdev->dev, "could not enable clock\n");
>> + return ret;
>> + }
>> +
>> + ret = brcm_pcie_setup(pcie);
>> + if (ret)
>> + goto fail;
>> +
>> + bridge->dev.parent = &pdev->dev;
>> + bridge->busnr = 0;
>> + bridge->ops = &brcm_pcie_ops;
>> + bridge->sysdata = pcie;
>> + bridge->map_irq = of_irq_parse_and_map_pci;
>> + bridge->swizzle_irq = pci_common_swizzle;
>> +
>> + ret = pci_scan_root_bus_bridge(bridge);
>> + if (ret < 0) {
>> + dev_err(pcie->dev, "Scanning root bridge failed\n");
>> + goto fail;
>> + }
>> +
>> + pci_assign_unassigned_bus_resources(bridge->bus);
>> + list_for_each_entry(child, &bridge->bus->children, node)
>> + pcie_bus_configure_settings(child);
>> + pci_bus_add_devices(bridge->bus);
>> + platform_set_drvdata(pdev, pcie);
>> + pcie->root_bus = bridge->bus;
>> +
>> + return 0;
>> +fail:
>> + __brcm_pcie_remove(pcie);
>> + return ret;
>> +}
>> +
>> +static struct platform_driver brcm_pcie_driver = {
>> + .probe = brcm_pcie_probe,
>> + .remove = brcm_pcie_remove,
>> + .driver = {
>> + .name = "brcm-pcie",
>> + .of_match_table = brcm_pcie_match,
>> + },
>> +};
>> +
>> +module_platform_driver(brcm_pcie_driver);
>> +
>> +MODULE_LICENSE("GPL v2");
>
> This is different to the SPDX at the start of the file (please see
> earlier review comments).
>
> Thanks,
>
> Andrew Murray
>
> [1] https://patchwork.ozlabs.org/patch/1190710/#2301173
>
>> +MODULE_DESCRIPTION("Broadcom STB PCIe RC driver");
>> +MODULE_AUTHOR("Broadcom");
>> --
>> 2.24.0
>>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver
2019-11-19 16:25 ` Andrew Murray
2019-11-19 18:20 ` Jeremy Linton
@ 2019-11-19 18:34 ` Florian Fainelli
2019-11-21 12:16 ` Andrew Murray
2019-11-20 19:53 ` Nicolas Saenz Julienne
2 siblings, 1 reply; 36+ messages in thread
From: Florian Fainelli @ 2019-11-19 18:34 UTC (permalink / raw)
To: Andrew Murray, Nicolas Saenz Julienne
Cc: maz, linux-kernel, Lorenzo Pieralisi, Eric Anholt, Stefan Wahren,
Florian Fainelli, bcm-kernel-feedback-list, james.quinlan,
mbrugger, phil, jeremy.linton, Bjorn Helgaas, linux-pci,
linux-rpi-kernel, linux-arm-kernel
On 11/19/19 8:25 AM, Andrew Murray wrote:
> On Tue, Nov 12, 2019 at 04:59:23PM +0100, Nicolas Saenz Julienne wrote:
>> From: Jim Quinlan <james.quinlan@broadcom.com>
>>
>> This commit adds the basic Broadcom STB PCIe controller. Missing is the
>> ability to process MSI. This functionality is added in a subsequent
>> commit.
>>
>> The PCIe block contains an MDIO interface. This is a local interface
>> only accessible by the PCIe controller. It cannot be used or shared
>> by any other HW. As such, the small amount of code for this
>> controller is included in this driver as there is little upside to put
>> it elsewhere.
>
> This commit message hasn't changed, despite earlier feedback.
Please strip out large parts of the original patch that you are not
quoting for future responses.
[snip]
>
> I'd rather see use of the pcie_cfg_data structure removed from this series.
>
> I've seen the comments in the previous thread [1], and I understand that
> the intention is that this driver will eventually be used for other SOCs.
>
> However this indirection isn't needed *now* and it makes reviewing this
> patch more difficult. If and when a later series is made to cover other
> SOCs - then I'd expect that series to find a way to apply this indirection.
I am not completely sold on the difficulty to review given that the
indirection is in place for only 3 registers which are used in only 3
functions:
brcm_pcie_bridge_sw_init_set()
brcm_pcie_perst_set()
brcm_pcie_map_conf()
but if you think that is a deal breaker, then, okay, let's get rid of it
and we will add it back for other STB SoCs in the future.
>
> And if that later series is more difficult to review because of the newly
> added indirection, then I'd expect an early patch of that series to apply
> the indirection in a single patch - which would be easy to review.
>
> The other risk of such premature changes like this is that when you come
> to adding other SOCs, you may then discover that there were shortcomings
> in the way you've approached it here.
2711 is the latest SoC that has actually been supported by this driver,
every other ones that this driver will support in the future has been in
production for years and all the quirks/subtleties are known. This means
that 2711 was added while fitting in the existing abstraction and
Nicholas took out every other chip to leave 2711 only.
--
Florian
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver
2019-11-19 16:25 ` Andrew Murray
2019-11-19 18:20 ` Jeremy Linton
2019-11-19 18:34 ` Florian Fainelli
@ 2019-11-20 19:53 ` Nicolas Saenz Julienne
2019-11-21 12:03 ` Andrew Murray
2 siblings, 1 reply; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-20 19:53 UTC (permalink / raw)
To: Andrew Murray
Cc: Florian Fainelli, mbrugger, maz, phil, linux-kernel,
jeremy.linton, Eric Anholt, Lorenzo Pieralisi,
bcm-kernel-feedback-list, Stefan Wahren, james.quinlan,
linux-pci, Bjorn Helgaas, linux-arm-kernel, linux-rpi-kernel
[-- Attachment #1: Type: text/plain, Size: 12827 bytes --]
Hi Andrew, thanks for the review.
On Tue, 2019-11-19 at 16:25 +0000, Andrew Murray wrote:
> On Tue, Nov 12, 2019 at 04:59:23PM +0100, Nicolas Saenz Julienne wrote:
> > From: Jim Quinlan <james.quinlan@broadcom.com>
> >
> > This commit adds the basic Broadcom STB PCIe controller. Missing is the
> > ability to process MSI. This functionality is added in a subsequent
> > commit.
> >
> > The PCIe block contains an MDIO interface. This is a local interface
> > only accessible by the PCIe controller. It cannot be used or shared
> > by any other HW. As such, the small amount of code for this
> > controller is included in this driver as there is little upside to put
> > it elsewhere.
>
> This commit message hasn't changed, despite earlier feedback.
Sorry, I'll review your previous comment.
[...]
> > +#define bcm_readl(a) readl(a)
> > +#define bcm_writel(d, a) writel(d, a)
> > +#define bcm_readw(a) readw(a)
> > +#define bcm_writew(d, a) writew(d, a)
> > +
> > +/* These macros extract/insert fields to host controller's register set. */
> > +#define RD_FLD(base, reg, field) \
> > + brcm_pcie_rd_fld((base) + reg, reg##_##field##_MASK, \
> > + reg##_##field##_SHIFT)
> > +#define WR_FLD(base, reg, field, val) \
> > + brcm_pcie_wr_fld((base) + reg, reg##_##field##_MASK, \
> > + reg##_##field##_SHIFT, val)
> > +#define WR_FLD_RB(base, reg, field, val) \
> > + brcm_pcie_wr_fld_rb((base) + reg, reg##_##field##_MASK, \
> > + reg##_##field##_SHIFT, val)
> > +#define WR_FLD_WITH_OFFSET(base, off, reg, field, val) \
> > + brcm_pcie_wr_fld((base) + reg + (off), reg##_##field##_MASK, \
> > + reg##_##field##_SHIFT, val)
> > +#define EXTRACT_FIELD(val, reg, field) \
> > + (((val) & reg##_##field##_MASK) >> reg##_##field##_SHIFT)
> > +#define INSERT_FIELD(val, reg, field, field_val) \
> > + (((val) & ~reg##_##field##_MASK) | \
> > + (reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
>
> Can you use any of the existing macros in linux/bitfield.h
> (e.g. ...replace_bits...) ?
Yes, It looks like it fits perfectly, I think I can get rid of all the *_SHIFT
registers and simplify some of the functions below.
> > +
> > +static u32 brcm_pcie_rd_fld(void __iomem *p, u32 mask, int shift)
> > +{
> > + return (bcm_readl(p) & mask) >> shift;
> > +}
> > +
> > +static void brcm_pcie_wr_fld(void __iomem *p, u32 mask, int shift, u32 val)
> > +{
> > + u32 reg = bcm_readl(p);
> > +
> > + reg = (reg & ~mask) | ((val << shift) & mask);
> > + bcm_writel(reg, p);
> > +}
> > +
> > +static void brcm_pcie_wr_fld_rb(void __iomem *p, u32 mask, int shift, u32
> > val)
> > +{
> > + brcm_pcie_wr_fld(p, mask, shift, val);
> > + (void)bcm_readl(p);
> > +}
> > +
[...]
> > +static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
> > + unsigned int win, phys_addr_t cpu_addr,
> > + dma_addr_t pcie_addr, dma_addr_t size)
> > +{
> > + phys_addr_t cpu_addr_mb, limit_addr_mb;
> > + void __iomem *base = pcie->base;
> > + u32 tmp;
> > +
> > + /* Set the base of the pcie_addr window */
> > + bcm_writel(lower_32_bits(pcie_addr) + MMIO_ENDIAN,
> > + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + (win * 8));
> > + bcm_writel(upper_32_bits(pcie_addr),
> > + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + (win * 8));
> > +
> > + cpu_addr_mb = cpu_addr >> 20;
> > + limit_addr_mb = (cpu_addr + size - 1) >> 20;
> > +
> > + /* Write the addr base low register */
> > + WR_FLD_WITH_OFFSET(base, (win * 4),
> > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
> > + BASE, cpu_addr_mb);
> > + /* Write the addr limit low register */
> > + WR_FLD_WITH_OFFSET(base, (win * 4),
> > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
> > + LIMIT, limit_addr_mb);
> > +
> > + /* Write the cpu addr high register */
> > + tmp = (u32)(cpu_addr_mb >>
> > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
>
> Despite the name _MASK_BITS, this isn't being used as a mask. Is this making
> some assumption about the value of cpu_addr from the DT?
It should be read _NUM_MASK_BITS. It contains the number of set bits on that
specific mask. I agree it's not ideal. I think I'll be able to do away with it
using the bitfield.h macros.
FYI, What's happening here is that we have to save the CPU address range (which
is already shifted right 20 positions) in two parts, the lower 12 bits go into
PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT while the higher 8 bits go into
PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI or
PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI.
[...]
> > +static inline int brcm_pcie_get_rc_bar2_size_and_offset(struct brcm_pcie
> > *pcie,
> > + u64 *rc_bar2_size,
> > + u64 *rc_bar2_offset)
> > +{
> > + struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
> > + struct device *dev = pcie->dev;
> > + struct resource_entry *entry;
> > + u64 total_mem_size = 0;
> > +
> > + *rc_bar2_offset = -1;
> > +
> > + resource_list_for_each_entry(entry, &bridge->dma_ranges) {
> > + /*
> > + * We're promised the RC will provide a contiguous view of
> > + * memory to downstream devices. We can then infer the
> > + * rc_bar2_offset from the lower available dma-range offset.
> > + */
> > + if (entry->offset < *rc_bar2_offset)
> > + *rc_bar2_offset = entry->offset;
> > +
> > + total_mem_size += entry->res->end - entry->res->start + 1;
>
> This requires that if there are multiple dma-ranges, then there are no gaps
> between them right?
Yes, the PCI view of inbound memory will always be gapless. See an example
here: https://patchwork.kernel.org/patch/10605957/
That said, iterating over the dma-ranges is not strictly necessary for now as
RPi4 is assured to only need one. If that's bothering you I can always remove
it for now.
[...]
> > +static int brcm_pcie_setup(struct brcm_pcie *pcie)
> > +{
> > + struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
> > + u64 rc_bar2_offset, rc_bar2_size;
> > + void __iomem *base = pcie->base;
> > + struct device *dev = pcie->dev;
> > + struct resource_entry *entry;
> > + unsigned int scb_size_val;
> > + bool ssc_good = false;
> > + struct resource *res;
> > + int num_out_wins = 0;
> > + u16 nlw, cls, lnksta;
> > + int i, ret;
> > + u32 tmp;
> > +
> > + /* Reset the bridge */
> > + brcm_pcie_bridge_sw_init_set(pcie, 1);
> > +
> > + usleep_range(100, 200);
> > +
> > + /* Take the bridge out of reset */
> > + brcm_pcie_bridge_sw_init_set(pcie, 0);
> > +
> > + WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
> > + /* Wait for SerDes to be stable */
> > + usleep_range(100, 200);
> > +
> > + /* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
> > + tmp = INSERT_FIELD(0, PCIE_MISC_MISC_CTRL, SCB_ACCESS_EN, 1);
> > + tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, CFG_READ_UR_MODE, 1);
> > + tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, MAX_BURST_SIZE,
> > + BURST_SIZE_128);
> > + bcm_writel(tmp, base + PCIE_MISC_MISC_CTRL);
> > +
> > + ret = brcm_pcie_get_rc_bar2_size_and_offset(pcie, &rc_bar2_size,
> > + &rc_bar2_offset);
> > + if (ret)
> > + return ret;
> > +
> > + tmp = lower_32_bits(rc_bar2_offset);
> > + tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
> > + brcm_pcie_encode_ibar_size(rc_bar2_size));
> > + bcm_writel(tmp, base + PCIE_MISC_RC_BAR2_CONFIG_LO);
> > + bcm_writel(upper_32_bits(rc_bar2_offset),
> > + base + PCIE_MISC_RC_BAR2_CONFIG_HI);
> > +
> > + scb_size_val = rc_bar2_size ?
> > + ilog2(rc_bar2_size) - 15 : 0xf; /* 0xf is 1GB */
> > + WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB0_SIZE, scb_size_val);
> > +
> > + /* disable the PCIe->GISB memory window (RC_BAR1) */
> > + WR_FLD(base, PCIE_MISC_RC_BAR1_CONFIG_LO, SIZE, 0);
> > +
> > + /* disable the PCIe->SCB memory window (RC_BAR3) */
> > + WR_FLD(base, PCIE_MISC_RC_BAR3_CONFIG_LO, SIZE, 0);
> > +
> > + /* clear any interrupts we find on boot */
> > + bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + CLR);
> > + (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + CLR);
> > +
> > + /* Mask all interrupts since we are not handling any yet */
> > + bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + MASK_SET);
> > + (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + MASK_SET);
>
> Should you change the order and mask before clearing the interrupts?
Yes, agree.
> > +
> > + if (pcie->gen)
> > + brcm_pcie_set_gen(base, pcie->gen);
> > +
> > + /* Unassert the fundamental reset */
> > + brcm_pcie_perst_set(pcie, 0);
> > +
> > + /*
> > + * Give the RC/EP time to wake up, before trying to configure RC.
> > + * Intermittently check status for link-up, up to a total of 100ms.
> > + */
> > + for (i = 0; i < 100 && !brcm_pcie_link_up(pcie); i += 5)
> > + msleep(5);
> > +
> > + if (!brcm_pcie_link_up(pcie)) {
> > + dev_info(dev, "link down\n");
> > + return -ENODEV;
> > + }
> > +
> > + if (!brcm_pcie_rc_mode(pcie)) {
> > + dev_err(dev, "PCIe misconfigured; is in EP mode\n");
> > + return -EINVAL;
> > + }
> > +
> > + resource_list_for_each_entry(entry, &bridge->windows) {
> > + res = entry->res;
> > +
> > + if (resource_type(res) != IORESOURCE_MEM)
> > + continue;
> > +
> > + if (num_out_wins >= BRCM_NUM_PCIE_OUT_WINS) {
> > + dev_err(pcie->dev, "too many outbound wins\n");
> > + return -EINVAL;
> > + }
> > +
> > + brcm_pcie_set_outbound_win(pcie, num_out_wins, res->start,
> > + res->start - entry->offset,
> > + res->end - res->start + 1);
> > + num_out_wins++;
> > + }
> > +
> > + /*
> > + * For config space accesses on the RC, show the right class for
> > + * a PCIe-PCIe bridge (the default setting is to be EP mode).
> > + */
> > + WR_FLD_RB(base, PCIE_RC_CFG_PRIV1_ID_VAL3, CLASS_CODE, 0x060400);
>
> Why does this need to be _RB ? I haven't looked at all of the uses of _RB
> though I think there are others that may not be necessary.
We're reviewing the _RB usage with Jim, I'll come back to you on that topic
later.
[...]
> > + __brcm_pcie_remove(pcie);
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id brcm_pcie_match[] = {
> > + { .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
>
> I'd rather see use of the pcie_cfg_data structure removed from this series.
>
> I've seen the comments in the previous thread [1], and I understand that
> the intention is that this driver will eventually be used for other SOCs.
>
> However this indirection isn't needed *now* and it makes reviewing this
> patch more difficult. If and when a later series is made to cover other
> SOCs - then I'd expect that series to find a way to apply this indirection.
>
> And if that later series is more difficult to review because of the newly
> added indirection, then I'd expect an early patch of that series to apply
> the indirection in a single patch - which would be easy to review.
>
> The other risk of such premature changes like this is that when you come
> to adding other SOCs, you may then discover that there were shortcomings
> in the way you've approached it here.
>
I was about to make a point similar to Florian's. I'll wait for your reply and
change this accordingly.
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, brcm_pcie_match);
> > +
> > +static int brcm_pcie_probe(struct platform_device *pdev)
> > +{
> > + struct device_node *np = pdev->dev.of_node;
> > + const struct pcie_cfg_data *data;
> > + struct pci_host_bridge *bridge;
> > + struct brcm_pcie *pcie;
> > + struct pci_bus *child;
> > + struct resource *res;
> > + int ret;
> > +
> > + bridge = devm_pci_alloc_host_bridge(&pdev->dev, sizeof(*pcie));
> > + if (!bridge)
> > + return -ENOMEM;
> > +
> > + pcie = pci_host_bridge_priv(bridge);
>
> Nit: I'd suggest moving the above line so it sits just above the
> "pcie->reg_offsets = data->offsets;" line. It looks nicer.
Ok
> > +
> > + data = of_device_get_match_data(&pdev->dev);
> > + if (!data) {
> > + dev_err(&pdev->dev, "failed to look up compatible string\n");
>
> Nit: If there is a failure here, it's probably because there is no data
> defined in the brcm_pcie_match structure - seeing as we wouldn't get here
> if we didn't have a compatible string. I'd suggest rewording the err slightly
> or even removing it.
Ok
[...]
> > + },
> > +};
> > +
> > +module_platform_driver(brcm_pcie_driver);
> > +
> > +MODULE_LICENSE("GPL v2");
>
> This is different to the SPDX at the start of the file (please see
> earlier review comments).
Ouch, yes, that fix got lost, It seems I even mentioned it on the changelog...
Thanks,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver
2019-11-19 18:20 ` Jeremy Linton
@ 2019-11-20 20:24 ` Nicolas Saenz Julienne
0 siblings, 0 replies; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-20 20:24 UTC (permalink / raw)
To: Jeremy Linton, Andrew Murray
Cc: maz, linux-kernel, Lorenzo Pieralisi, Eric Anholt, Stefan Wahren,
Florian Fainelli, bcm-kernel-feedback-list, james.quinlan,
mbrugger, phil, Bjorn Helgaas, linux-pci, linux-rpi-kernel,
linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]
Hi Jeremy,
On Tue, 2019-11-19 at 12:20 -0600, Jeremy Linton wrote:
> Hi,
>
> On 11/19/19 10:25 AM, Andrew Murray wrote:
> > On Tue, Nov 12, 2019 at 04:59:23PM +0100, Nicolas Saenz Julienne wrote:
> > > From: Jim Quinlan <james.quinlan@broadcom.com>
> > >
> > > This commit adds the basic Broadcom STB PCIe controller. Missing is the
> > > ability to process MSI. This functionality is added in a subsequent
> > > commit.
> > >
> > > The PCIe block contains an MDIO interface. This is a local interface
> > > only accessible by the PCIe controller. It cannot be used or shared
> > > by any other HW. As such, the small amount of code for this
> > > controller is included in this driver as there is little upside to put
> > > it elsewhere.
> >
> > This commit message hasn't changed, despite earlier feedback.
> >
>
> Also, unless i'm mistaken this controller isn't I/O coherent on the rpi.
I'm not sure I get what you mean by I/O coherent.
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver
2019-11-20 19:53 ` Nicolas Saenz Julienne
@ 2019-11-21 12:03 ` Andrew Murray
2019-11-21 12:59 ` Nicolas Saenz Julienne
2019-11-21 13:26 ` Nicolas Saenz Julienne
0 siblings, 2 replies; 36+ messages in thread
From: Andrew Murray @ 2019-11-21 12:03 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Florian Fainelli, mbrugger, maz, phil, linux-kernel,
jeremy.linton, Eric Anholt, Lorenzo Pieralisi,
bcm-kernel-feedback-list, Stefan Wahren, james.quinlan,
linux-pci, Bjorn Helgaas, linux-arm-kernel, linux-rpi-kernel
On Wed, Nov 20, 2019 at 08:53:30PM +0100, Nicolas Saenz Julienne wrote:
> Hi Andrew, thanks for the review.
>
> On Tue, 2019-11-19 at 16:25 +0000, Andrew Murray wrote:
> > On Tue, Nov 12, 2019 at 04:59:23PM +0100, Nicolas Saenz Julienne wrote:
> > > From: Jim Quinlan <james.quinlan@broadcom.com>
> > >
> > > This commit adds the basic Broadcom STB PCIe controller. Missing is the
> > > ability to process MSI. This functionality is added in a subsequent
> > > commit.
> > >
> > > The PCIe block contains an MDIO interface. This is a local interface
> > > only accessible by the PCIe controller. It cannot be used or shared
> > > by any other HW. As such, the small amount of code for this
> > > controller is included in this driver as there is little upside to put
> > > it elsewhere.
> >
> > This commit message hasn't changed, despite earlier feedback.
>
> Sorry, I'll review your previous comment.
>
> [...]
>
> > > +#define bcm_readl(a) readl(a)
> > > +#define bcm_writel(d, a) writel(d, a)
> > > +#define bcm_readw(a) readw(a)
> > > +#define bcm_writew(d, a) writew(d, a)
> > > +
> > > +/* These macros extract/insert fields to host controller's register set. */
> > > +#define RD_FLD(base, reg, field) \
> > > + brcm_pcie_rd_fld((base) + reg, reg##_##field##_MASK, \
> > > + reg##_##field##_SHIFT)
> > > +#define WR_FLD(base, reg, field, val) \
> > > + brcm_pcie_wr_fld((base) + reg, reg##_##field##_MASK, \
> > > + reg##_##field##_SHIFT, val)
> > > +#define WR_FLD_RB(base, reg, field, val) \
> > > + brcm_pcie_wr_fld_rb((base) + reg, reg##_##field##_MASK, \
> > > + reg##_##field##_SHIFT, val)
> > > +#define WR_FLD_WITH_OFFSET(base, off, reg, field, val) \
> > > + brcm_pcie_wr_fld((base) + reg + (off), reg##_##field##_MASK, \
> > > + reg##_##field##_SHIFT, val)
> > > +#define EXTRACT_FIELD(val, reg, field) \
> > > + (((val) & reg##_##field##_MASK) >> reg##_##field##_SHIFT)
> > > +#define INSERT_FIELD(val, reg, field, field_val) \
> > > + (((val) & ~reg##_##field##_MASK) | \
> > > + (reg##_##field##_MASK & (field_val << reg##_##field##_SHIFT)))
> >
> > Can you use any of the existing macros in linux/bitfield.h
> > (e.g. ...replace_bits...) ?
>
> Yes, It looks like it fits perfectly, I think I can get rid of all the *_SHIFT
> registers and simplify some of the functions below.
I do love to see code being removed :).
>
> > > +
> > > +static u32 brcm_pcie_rd_fld(void __iomem *p, u32 mask, int shift)
> > > +{
> > > + return (bcm_readl(p) & mask) >> shift;
> > > +}
> > > +
> > > +static void brcm_pcie_wr_fld(void __iomem *p, u32 mask, int shift, u32 val)
> > > +{
> > > + u32 reg = bcm_readl(p);
> > > +
> > > + reg = (reg & ~mask) | ((val << shift) & mask);
> > > + bcm_writel(reg, p);
> > > +}
> > > +
> > > +static void brcm_pcie_wr_fld_rb(void __iomem *p, u32 mask, int shift, u32
> > > val)
> > > +{
> > > + brcm_pcie_wr_fld(p, mask, shift, val);
> > > + (void)bcm_readl(p);
> > > +}
> > > +
>
> [...]
>
> > > +static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
> > > + unsigned int win, phys_addr_t cpu_addr,
> > > + dma_addr_t pcie_addr, dma_addr_t size)
> > > +{
> > > + phys_addr_t cpu_addr_mb, limit_addr_mb;
> > > + void __iomem *base = pcie->base;
> > > + u32 tmp;
> > > +
> > > + /* Set the base of the pcie_addr window */
> > > + bcm_writel(lower_32_bits(pcie_addr) + MMIO_ENDIAN,
> > > + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + (win * 8));
> > > + bcm_writel(upper_32_bits(pcie_addr),
> > > + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + (win * 8));
> > > +
> > > + cpu_addr_mb = cpu_addr >> 20;
> > > + limit_addr_mb = (cpu_addr + size - 1) >> 20;
> > > +
> > > + /* Write the addr base low register */
> > > + WR_FLD_WITH_OFFSET(base, (win * 4),
> > > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
> > > + BASE, cpu_addr_mb);
> > > + /* Write the addr limit low register */
> > > + WR_FLD_WITH_OFFSET(base, (win * 4),
> > > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
> > > + LIMIT, limit_addr_mb);
> > > +
> > > + /* Write the cpu addr high register */
> > > + tmp = (u32)(cpu_addr_mb >>
> > > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
> >
> > Despite the name _MASK_BITS, this isn't being used as a mask. Is this making
> > some assumption about the value of cpu_addr from the DT?
>
> It should be read _NUM_MASK_BITS. It contains the number of set bits on that
> specific mask. I agree it's not ideal. I think I'll be able to do away with it
> using the bitfield.h macros.
Also why do you have a define for
PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS but not the '20' shift
used for the low registers?
>
> FYI, What's happening here is that we have to save the CPU address range (which
> is already shifted right 20 positions) in two parts, the lower 12 bits go into
> PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT while the higher 8 bits go into
> PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI or
> PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI.
The hardware spec require bits 31:20 of the address, and the high registers
require 39:32 right?
(Apologies, the indirection by the WR_FLD_** macros easily confuses me. These
type of macros are helpful, or rather would be if the whole kernel used them.
I think they can add confusion when each driver has its own set of similar
macros. This is why its *really* helpful to use any existing macros in the
kernel - and only invent new ones if needed).
>
> [...]
>
> > > +static inline int brcm_pcie_get_rc_bar2_size_and_offset(struct brcm_pcie
> > > *pcie,
> > > + u64 *rc_bar2_size,
> > > + u64 *rc_bar2_offset)
> > > +{
> > > + struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
> > > + struct device *dev = pcie->dev;
> > > + struct resource_entry *entry;
> > > + u64 total_mem_size = 0;
> > > +
> > > + *rc_bar2_offset = -1;
> > > +
> > > + resource_list_for_each_entry(entry, &bridge->dma_ranges) {
> > > + /*
> > > + * We're promised the RC will provide a contiguous view of
> > > + * memory to downstream devices. We can then infer the
> > > + * rc_bar2_offset from the lower available dma-range offset.
> > > + */
> > > + if (entry->offset < *rc_bar2_offset)
> > > + *rc_bar2_offset = entry->offset;
> > > +
> > > + total_mem_size += entry->res->end - entry->res->start + 1;
> >
> > This requires that if there are multiple dma-ranges, then there are no gaps
> > between them right?
>
> Yes, the PCI view of inbound memory will always be gapless. See an example
> here: https://patchwork.kernel.org/patch/10605957/
Thanks for the reference.
>
> That said, iterating over the dma-ranges is not strictly necessary for now as
> RPi4 is assured to only need one. If that's bothering you I can always remove
> it for now.
One purpose of this function is to validate that the information given in the
device tree is valid - I've seen other feedback on these lists where the view
is taken that 'it's not the job of the kernel to validate the DT'. Subscribing
to this view would be a justification for removing this validation - especially
given that the bindings you include have only one dma-range (in any case if
there are constraints you ought to include them in the binding document).
Though the problem with this point of view is that if the DT is wrong, it may
be possible for the driver to work well enough to do some function but with
some horrible side effects that are difficult to track down to a bad DT.
If you assume the DT will only have one range (at least for the Pi) then this
code will never be used and so can probably be removed.
>
> [...]
>
> > > +static int brcm_pcie_setup(struct brcm_pcie *pcie)
> > > +{
> > > + struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
> > > + u64 rc_bar2_offset, rc_bar2_size;
> > > + void __iomem *base = pcie->base;
> > > + struct device *dev = pcie->dev;
> > > + struct resource_entry *entry;
> > > + unsigned int scb_size_val;
> > > + bool ssc_good = false;
> > > + struct resource *res;
> > > + int num_out_wins = 0;
> > > + u16 nlw, cls, lnksta;
> > > + int i, ret;
> > > + u32 tmp;
> > > +
> > > + /* Reset the bridge */
> > > + brcm_pcie_bridge_sw_init_set(pcie, 1);
> > > +
> > > + usleep_range(100, 200);
> > > +
> > > + /* Take the bridge out of reset */
> > > + brcm_pcie_bridge_sw_init_set(pcie, 0);
> > > +
> > > + WR_FLD_RB(base, PCIE_MISC_HARD_PCIE_HARD_DEBUG, SERDES_IDDQ, 0);
> > > + /* Wait for SerDes to be stable */
> > > + usleep_range(100, 200);
> > > +
> > > + /* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
> > > + tmp = INSERT_FIELD(0, PCIE_MISC_MISC_CTRL, SCB_ACCESS_EN, 1);
> > > + tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, CFG_READ_UR_MODE, 1);
> > > + tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, MAX_BURST_SIZE,
> > > + BURST_SIZE_128);
> > > + bcm_writel(tmp, base + PCIE_MISC_MISC_CTRL);
> > > +
> > > + ret = brcm_pcie_get_rc_bar2_size_and_offset(pcie, &rc_bar2_size,
> > > + &rc_bar2_offset);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + tmp = lower_32_bits(rc_bar2_offset);
> > > + tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
> > > + brcm_pcie_encode_ibar_size(rc_bar2_size));
> > > + bcm_writel(tmp, base + PCIE_MISC_RC_BAR2_CONFIG_LO);
> > > + bcm_writel(upper_32_bits(rc_bar2_offset),
> > > + base + PCIE_MISC_RC_BAR2_CONFIG_HI);
> > > +
> > > + scb_size_val = rc_bar2_size ?
> > > + ilog2(rc_bar2_size) - 15 : 0xf; /* 0xf is 1GB */
> > > + WR_FLD(base, PCIE_MISC_MISC_CTRL, SCB0_SIZE, scb_size_val);
> > > +
> > > + /* disable the PCIe->GISB memory window (RC_BAR1) */
> > > + WR_FLD(base, PCIE_MISC_RC_BAR1_CONFIG_LO, SIZE, 0);
> > > +
> > > + /* disable the PCIe->SCB memory window (RC_BAR3) */
> > > + WR_FLD(base, PCIE_MISC_RC_BAR3_CONFIG_LO, SIZE, 0);
> > > +
> > > + /* clear any interrupts we find on boot */
> > > + bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + CLR);
> > > + (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + CLR);
> > > +
> > > + /* Mask all interrupts since we are not handling any yet */
> > > + bcm_writel(0xffffffff, base + PCIE_INTR2_CPU_BASE + MASK_SET);
> > > + (void)bcm_readl(base + PCIE_INTR2_CPU_BASE + MASK_SET);
> >
> > Should you change the order and mask before clearing the interrupts?
>
> Yes, agree.
>
> > > +
> > > + if (pcie->gen)
> > > + brcm_pcie_set_gen(base, pcie->gen);
> > > +
> > > + /* Unassert the fundamental reset */
> > > + brcm_pcie_perst_set(pcie, 0);
> > > +
> > > + /*
> > > + * Give the RC/EP time to wake up, before trying to configure RC.
> > > + * Intermittently check status for link-up, up to a total of 100ms.
> > > + */
> > > + for (i = 0; i < 100 && !brcm_pcie_link_up(pcie); i += 5)
> > > + msleep(5);
> > > +
> > > + if (!brcm_pcie_link_up(pcie)) {
> > > + dev_info(dev, "link down\n");
> > > + return -ENODEV;
> > > + }
> > > +
> > > + if (!brcm_pcie_rc_mode(pcie)) {
> > > + dev_err(dev, "PCIe misconfigured; is in EP mode\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + resource_list_for_each_entry(entry, &bridge->windows) {
> > > + res = entry->res;
> > > +
> > > + if (resource_type(res) != IORESOURCE_MEM)
> > > + continue;
> > > +
> > > + if (num_out_wins >= BRCM_NUM_PCIE_OUT_WINS) {
> > > + dev_err(pcie->dev, "too many outbound wins\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + brcm_pcie_set_outbound_win(pcie, num_out_wins, res->start,
> > > + res->start - entry->offset,
> > > + res->end - res->start + 1);
> > > + num_out_wins++;
> > > + }
> > > +
> > > + /*
> > > + * For config space accesses on the RC, show the right class for
> > > + * a PCIe-PCIe bridge (the default setting is to be EP mode).
> > > + */
> > > + WR_FLD_RB(base, PCIE_RC_CFG_PRIV1_ID_VAL3, CLASS_CODE, 0x060400);
> >
> > Why does this need to be _RB ? I haven't looked at all of the uses of _RB
> > though I think there are others that may not be necessary.
>
> We're reviewing the _RB usage with Jim, I'll come back to you on that topic
> later.
Thanks.
>
> [...]
>
> > > + __brcm_pcie_remove(pcie);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static const struct of_device_id brcm_pcie_match[] = {
> > > + { .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
> >
> > I'd rather see use of the pcie_cfg_data structure removed from this series.
> >
> > I've seen the comments in the previous thread [1], and I understand that
> > the intention is that this driver will eventually be used for other SOCs.
> >
> > However this indirection isn't needed *now* and it makes reviewing this
> > patch more difficult. If and when a later series is made to cover other
> > SOCs - then I'd expect that series to find a way to apply this indirection.
> >
> > And if that later series is more difficult to review because of the newly
> > added indirection, then I'd expect an early patch of that series to apply
> > the indirection in a single patch - which would be easy to review.
> >
> > The other risk of such premature changes like this is that when you come
> > to adding other SOCs, you may then discover that there were shortcomings
> > in the way you've approached it here.
> >
>
> I was about to make a point similar to Florian's. I'll wait for your reply and
> change this accordingly.
No problem.
>
> > > + {},
> > > +};
> > > +MODULE_DEVICE_TABLE(of, brcm_pcie_match);
> > > +
> > > +static int brcm_pcie_probe(struct platform_device *pdev)
> > > +{
> > > + struct device_node *np = pdev->dev.of_node;
> > > + const struct pcie_cfg_data *data;
> > > + struct pci_host_bridge *bridge;
> > > + struct brcm_pcie *pcie;
> > > + struct pci_bus *child;
> > > + struct resource *res;
> > > + int ret;
> > > +
> > > + bridge = devm_pci_alloc_host_bridge(&pdev->dev, sizeof(*pcie));
> > > + if (!bridge)
> > > + return -ENOMEM;
> > > +
> > > + pcie = pci_host_bridge_priv(bridge);
> >
> > Nit: I'd suggest moving the above line so it sits just above the
> > "pcie->reg_offsets = data->offsets;" line. It looks nicer.
>
> Ok
>
> > > +
> > > + data = of_device_get_match_data(&pdev->dev);
> > > + if (!data) {
> > > + dev_err(&pdev->dev, "failed to look up compatible string\n");
> >
> > Nit: If there is a failure here, it's probably because there is no data
> > defined in the brcm_pcie_match structure - seeing as we wouldn't get here
> > if we didn't have a compatible string. I'd suggest rewording the err slightly
> > or even removing it.
>
> Ok
>
> [...]
>
> > > + },
> > > +};
> > > +
> > > +module_platform_driver(brcm_pcie_driver);
> > > +
> > > +MODULE_LICENSE("GPL v2");
> >
> > This is different to the SPDX at the start of the file (please see
> > earlier review comments).
>
> Ouch, yes, that fix got lost, It seems I even mentioned it on the changelog...
:)
Thanks,
Andrew Murray
>
> Thanks,
> Nicolas
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver
2019-11-19 18:34 ` Florian Fainelli
@ 2019-11-21 12:16 ` Andrew Murray
0 siblings, 0 replies; 36+ messages in thread
From: Andrew Murray @ 2019-11-21 12:16 UTC (permalink / raw)
To: Florian Fainelli
Cc: Nicolas Saenz Julienne, maz, linux-kernel, Lorenzo Pieralisi,
Eric Anholt, Stefan Wahren, bcm-kernel-feedback-list,
james.quinlan, mbrugger, phil, jeremy.linton, Bjorn Helgaas,
linux-pci, linux-rpi-kernel, linux-arm-kernel
On Tue, Nov 19, 2019 at 10:34:59AM -0800, Florian Fainelli wrote:
> On 11/19/19 8:25 AM, Andrew Murray wrote:
> > On Tue, Nov 12, 2019 at 04:59:23PM +0100, Nicolas Saenz Julienne wrote:
> >> From: Jim Quinlan <james.quinlan@broadcom.com>
> >>
> >> This commit adds the basic Broadcom STB PCIe controller. Missing is the
> >> ability to process MSI. This functionality is added in a subsequent
> >> commit.
> >>
> >> The PCIe block contains an MDIO interface. This is a local interface
> >> only accessible by the PCIe controller. It cannot be used or shared
> >> by any other HW. As such, the small amount of code for this
> >> controller is included in this driver as there is little upside to put
> >> it elsewhere.
> >
> > This commit message hasn't changed, despite earlier feedback.
>
> Please strip out large parts of the original patch that you are not
> quoting for future responses.
>
> [snip]
>
> >
> > I'd rather see use of the pcie_cfg_data structure removed from this series.
> >
> > I've seen the comments in the previous thread [1], and I understand that
> > the intention is that this driver will eventually be used for other SOCs.
> >
> > However this indirection isn't needed *now* and it makes reviewing this
> > patch more difficult. If and when a later series is made to cover other
> > SOCs - then I'd expect that series to find a way to apply this indirection.
>
> I am not completely sold on the difficulty to review given that the
> indirection is in place for only 3 registers which are used in only 3
> functions:
>
> brcm_pcie_bridge_sw_init_set()
> brcm_pcie_perst_set()
> brcm_pcie_map_conf()
>
> but if you think that is a deal breaker, then, okay, let's get rid of it
> and we will add it back for other STB SoCs in the future.
It's also about the context - This driver already has lots of indirection, lots
of macros, lots of defines, etc. And in that context this pcie_cfg_data adds
even more. It all adds to the complexity of understanding what the driver is
doing. Indirection often adds value - but I don't yet see that here.
I'd like to see it removed.
>
> >
> > And if that later series is more difficult to review because of the newly
> > added indirection, then I'd expect an early patch of that series to apply
> > the indirection in a single patch - which would be easy to review.
> >
> > The other risk of such premature changes like this is that when you come
> > to adding other SOCs, you may then discover that there were shortcomings
> > in the way you've approached it here.
>
> 2711 is the latest SoC that has actually been supported by this driver,
I appreciate that this is frustrating - taking a complete driver that supports
lots of platforms and then stripping it down for review one platform at a time.
It also means removing all the indirection and abstraction that will likely
later be required. Only to have to add it back in on the second platform.
But those subsequent patches aren't available for review, we don't know if
they will make it into the kernel or how long that will take. And we don't
want to be left with maintaining a Pi only driver that has lots of unnecessary
code that it is more difficult to understand than it needs to be.
> every other ones that this driver will support in the future has been in
> production for years and all the quirks/subtleties are known. This means
> that 2711 was added while fitting in the existing abstraction and
> Nicholas took out every other chip to leave 2711 only.
I'm not referring to the quirks in the hardware - it may be that when you
update this driver to add another SoC (on the list) - others reviewers
may not agree with the method of abstraction, or find some issue with it.
Yet until the abstraction can be reviewed in the context of support for the
next SoC it's hard to tell.
Thanks,
Andrew Murray
> --
> Florian
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 0/6] Raspberry Pi 4 PCIe support
2019-11-19 11:49 ` Nicolas Saenz Julienne
@ 2019-11-21 12:18 ` Andrew Murray
0 siblings, 0 replies; 36+ messages in thread
From: Andrew Murray @ 2019-11-21 12:18 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: devicetree, f.fainelli, linux-rdma, maz, phil, linux-kernel,
jeremy.linton, linux-rockchip, iommu, mbrugger,
bcm-kernel-feedback-list, wahrenst, james.quinlan, linux-pci,
Robin Murphy, netdev, linux-arm-kernel, linux-rpi-kernel
On Tue, Nov 19, 2019 at 12:49:24PM +0100, Nicolas Saenz Julienne wrote:
> On Tue, 2019-11-19 at 11:18 +0000, Andrew Murray wrote:
> > On Tue, Nov 12, 2019 at 04:59:19PM +0100, Nicolas Saenz Julienne wrote:
> > > This series aims at providing support for Raspberry Pi 4's PCIe
> > > controller, which is also shared with the Broadcom STB family of
> > > devices.
> > >
> > > There was a previous attempt to upstream this some years ago[1] but was
> > > blocked as most STB PCIe integrations have a sparse DMA mapping[2] which
> > > is something currently not supported by the kernel. Luckily this is not
> > > the case for the Raspberry Pi 4.
> > >
> > > Note that the driver code is to be based on top of Rob Herring's series
> > > simplifying inbound and outbound range parsing.
> > >
> > > [1] https://patchwork.kernel.org/cover/10605933/
> > > [2] https://patchwork.kernel.org/patch/10605957/
> > >
> >
> > What happened to patch 3? I can't see it on the list or in patchwork?
>
> For some reason the script I use to call get_maintainer.sh or git send-mail
> failed to add linux-pci@vger.kernel.org and linux-kernel@vger.kernel.org as
> recipients. I didn't do anything different between v1 and v2 as far as mailing
> is concerned.
>
> Nevertheless it's here: https://www.spinics.net/lists/arm-kernel/msg768461.html
> and should be present in the linux-arm-kernel list.
>
> I'll look in to it and make sure this doesn't happen in v3.
No problem.
Thanks,
Andrew Murray
>
> Regards,
> Nicolas
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver
2019-11-21 12:03 ` Andrew Murray
@ 2019-11-21 12:59 ` Nicolas Saenz Julienne
2019-11-21 15:44 ` Andrew Murray
2019-11-21 21:07 ` Jim Quinlan
2019-11-21 13:26 ` Nicolas Saenz Julienne
1 sibling, 2 replies; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-21 12:59 UTC (permalink / raw)
To: Andrew Murray
Cc: Florian Fainelli, mbrugger, maz, phil, linux-kernel,
jeremy.linton, Eric Anholt, Lorenzo Pieralisi,
bcm-kernel-feedback-list, Stefan Wahren, james.quinlan,
linux-pci, Bjorn Helgaas, linux-arm-kernel, linux-rpi-kernel
[-- Attachment #1: Type: text/plain, Size: 8211 bytes --]
Hi Andrew,
On Thu, 2019-11-21 at 12:03 +0000, Andrew Murray wrote:
> > > > +static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
> > > > + unsigned int win, phys_addr_t
> > > > cpu_addr,
> > > > + dma_addr_t pcie_addr, dma_addr_t
> > > > size)
> > > > +{
> > > > + phys_addr_t cpu_addr_mb, limit_addr_mb;
> > > > + void __iomem *base = pcie->base;
> > > > + u32 tmp;
> > > > +
> > > > + /* Set the base of the pcie_addr window */
> > > > + bcm_writel(lower_32_bits(pcie_addr) + MMIO_ENDIAN,
> > > > + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + (win * 8));
> > > > + bcm_writel(upper_32_bits(pcie_addr),
> > > > + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + (win * 8));
> > > > +
> > > > + cpu_addr_mb = cpu_addr >> 20;
> > > > + limit_addr_mb = (cpu_addr + size - 1) >> 20;
> > > > +
> > > > + /* Write the addr base low register */
> > > > + WR_FLD_WITH_OFFSET(base, (win * 4),
> > > > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
> > > > + BASE, cpu_addr_mb);
> > > > + /* Write the addr limit low register */
> > > > + WR_FLD_WITH_OFFSET(base, (win * 4),
> > > > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
> > > > + LIMIT, limit_addr_mb);
> > > > +
> > > > + /* Write the cpu addr high register */
> > > > + tmp = (u32)(cpu_addr_mb >>
> > > > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
> > >
> > > Despite the name _MASK_BITS, this isn't being used as a mask. Is this
> > > making
> > > some assumption about the value of cpu_addr from the DT?
> >
> > It should be read _NUM_MASK_BITS. It contains the number of set bits on that
> > specific mask. I agree it's not ideal. I think I'll be able to do away with
> > it
> > using the bitfield.h macros.
>
> Also why do you have a define for
> PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS but not the '20' shift
> used for the low registers?
Good point, I'm changing it to something more explicit:
cpu_addr_mb = cpu_addr / SZ_1M;
As for [...]_NUM_MASK_BITS I'm looking for a smart/generic way to calculate it
from the actual mask. No luck so far. If not, I think I'll simply leave it as
is for now.
> > FYI, What's happening here is that we have to save the CPU address range
> > (which
> > is already shifted right 20 positions) in two parts, the lower 12 bits go
> > into
> > PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT while the higher 8 bits go into
> > PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI or
> > PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI.
>
> The hardware spec require bits 31:20 of the address, and the high registers
> require 39:32 right?
Yes, that's it.
> (Apologies, the indirection by the WR_FLD_** macros easily confuses me. These
> type of macros are helpful, or rather would be if the whole kernel used them.
> I think they can add confusion when each driver has its own set of similar
> macros. This is why its *really* helpful to use any existing macros in the
> kernel - and only invent new ones if needed).
I agree it's pretty confusing, I think v3, using bitfield.h as much as
possible, looks substantially more welcoming.
> > [...]
> >
> > > > +static inline int brcm_pcie_get_rc_bar2_size_and_offset(struct
> > > > brcm_pcie
> > > > *pcie,
> > > > + u64
> > > > *rc_bar2_size,
> > > > + u64
> > > > *rc_bar2_offset)
> > > > +{
> > > > + struct pci_host_bridge *bridge =
> > > > pci_host_bridge_from_priv(pcie);
> > > > + struct device *dev = pcie->dev;
> > > > + struct resource_entry *entry;
> > > > + u64 total_mem_size = 0;
> > > > +
> > > > + *rc_bar2_offset = -1;
> > > > +
> > > > + resource_list_for_each_entry(entry, &bridge->dma_ranges) {
> > > > + /*
> > > > + * We're promised the RC will provide a contiguous view
> > > > of
> > > > + * memory to downstream devices. We can then infer the
> > > > + * rc_bar2_offset from the lower available dma-range
> > > > offset.
> > > > + */
> > > > + if (entry->offset < *rc_bar2_offset)
> > > > + *rc_bar2_offset = entry->offset;
> > > > +
> > > > + total_mem_size += entry->res->end - entry->res->start +
> > > > 1;
> > >
> > > This requires that if there are multiple dma-ranges, then there are no
> > > gaps
> > > between them right?
> >
> > Yes, the PCI view of inbound memory will always be gapless. See an example
> > here: https://patchwork.kernel.org/patch/10605957/
>
> Thanks for the reference.
>
>
> > That said, iterating over the dma-ranges is not strictly necessary for now
> > as
> > RPi4 is assured to only need one. If that's bothering you I can always
> > remove
> > it for now.
>
> One purpose of this function is to validate that the information given in the
> device tree is valid - I've seen other feedback on these lists where the view
> is taken that 'it's not the job of the kernel to validate the DT'. Subscribing
> to this view would be a justification for removing this validation -
> especially
> given that the bindings you include have only one dma-range (in any case if
> there are constraints you ought to include them in the binding document).
>
> Though the problem with this point of view is that if the DT is wrong, it may
> be possible for the driver to work well enough to do some function but with
> some horrible side effects that are difficult to track down to a bad DT.
>
> If you assume the DT will only have one range (at least for the Pi) then this
> code will never be used and so can probably be removed.
Ok, less is more, I'll simplify it.
[...]
> > > > + continue;
> > > > +
> > > > + if (num_out_wins >= BRCM_NUM_PCIE_OUT_WINS) {
> > > > + dev_err(pcie->dev, "too many outbound wins\n");
> > > > + return -EINVAL;
> > > > + }
> > > > +
> > > > + brcm_pcie_set_outbound_win(pcie, num_out_wins, res-
> > > > >start,
> > > > + res->start - entry->offset,
> > > > + res->end - res->start + 1);
> > > > + num_out_wins++;
> > > > + }
> > > > +
> > > > + /*
> > > > + * For config space accesses on the RC, show the right class for
> > > > + * a PCIe-PCIe bridge (the default setting is to be EP mode).
> > > > + */
> > > > + WR_FLD_RB(base, PCIE_RC_CFG_PRIV1_ID_VAL3, CLASS_CODE,
> > > > 0x060400);
> > >
> > > Why does this need to be _RB ? I haven't looked at all of the uses of _RB
> > > though I think there are others that may not be necessary.
> >
> > We're reviewing the _RB usage with Jim, I'll come back to you on that topic
> > later.
>
> Thanks.
Jim and Florian went over all the _RB usages and found out none of them applied
to the Pi. Apparently they where introduced as a form of barrier needed on some
MIPS SoCs. Sorry for that, I'll remove them.
> > [...]
> >
> > > > + __brcm_pcie_remove(pcie);
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static const struct of_device_id brcm_pcie_match[] = {
> > > > + { .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
> > >
> > > I'd rather see use of the pcie_cfg_data structure removed from this
> > > series.
> > >
> > > I've seen the comments in the previous thread [1], and I understand that
> > > the intention is that this driver will eventually be used for other SOCs.
> > >
> > > However this indirection isn't needed *now* and it makes reviewing this
> > > patch more difficult. If and when a later series is made to cover other
> > > SOCs - then I'd expect that series to find a way to apply this
> > > indirection.
> > >
> > > And if that later series is more difficult to review because of the newly
> > > added indirection, then I'd expect an early patch of that series to apply
> > > the indirection in a single patch - which would be easy to review.
> > >
> > > The other risk of such premature changes like this is that when you come
> > > to adding other SOCs, you may then discover that there were shortcomings
> > > in the way you've approached it here.
> > >
> >
> > I was about to make a point similar to Florian's. I'll wait for your reply
> > and
> > change this accordingly.
>
> No problem.
Following your reply, I'll remove it.
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver
2019-11-21 12:03 ` Andrew Murray
2019-11-21 12:59 ` Nicolas Saenz Julienne
@ 2019-11-21 13:26 ` Nicolas Saenz Julienne
2019-11-21 15:46 ` Andrew Murray
1 sibling, 1 reply; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-21 13:26 UTC (permalink / raw)
To: Andrew Murray
Cc: Florian Fainelli, mbrugger, maz, phil, linux-kernel,
jeremy.linton, Eric Anholt, Lorenzo Pieralisi,
bcm-kernel-feedback-list, Stefan Wahren, james.quinlan,
linux-pci, Bjorn Helgaas, linux-arm-kernel, linux-rpi-kernel
[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]
On Thu, 2019-11-21 at 12:03 +0000, Andrew Murray wrote:
> On Wed, Nov 20, 2019 at 08:53:30PM +0100, Nicolas Saenz Julienne wrote:
> One purpose of this function is to validate that the information given in the
> device tree is valid - I've seen other feedback on these lists where the view
> is taken that 'it's not the job of the kernel to validate the DT'. Subscribing
> to this view would be a justification for removing this validation -
> especially
> given that the bindings you include have only one dma-range (in any case if
> there are constraints you ought to include them in the binding document).
>
> Though the problem with this point of view is that if the DT is wrong, it may
> be possible for the driver to work well enough to do some function but with
> some horrible side effects that are difficult to track down to a bad DT.
As for the validation, I think in this specific case it's still worthwhile. As
you might know, there is a bug on the first revision of RPI4's PCIe integration
which blocks any access higher than 3GB. Further revisions fix this and allow
full memory addressing.
I've been working with Phil Elwell (from the RPi foundation) to solve this in a
way that plays well with upstream and this driver (I'll be able to test the new
revision before this gets in). The solution is, unsurprisingly, for the
firmware to edit the DTB passed to the kernel based on the board revision.
Given that there is some live manipulation of the dma-ranges I'd rather leave
the validation check.
If you don't disagree with the above I'll add an extra code comment explaining
why we feel the need to verify the device-tree contents.
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 5/6] PCI: brcmstb: add MSI capability
2019-11-12 15:59 ` [PATCH v2 5/6] PCI: brcmstb: add MSI capability Nicolas Saenz Julienne
2019-11-13 13:49 ` Marc Zyngier
@ 2019-11-21 15:38 ` Andrew Murray
2019-11-21 17:19 ` Nicolas Saenz Julienne
1 sibling, 1 reply; 36+ messages in thread
From: Andrew Murray @ 2019-11-21 15:38 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: maz, linux-kernel, Lorenzo Pieralisi, Florian Fainelli,
bcm-kernel-feedback-list, Eric Anholt, Stefan Wahren,
james.quinlan, mbrugger, phil, jeremy.linton, Bjorn Helgaas,
linux-pci, linux-rpi-kernel, linux-arm-kernel
On Tue, Nov 12, 2019 at 04:59:24PM +0100, Nicolas Saenz Julienne wrote:
> From: Jim Quinlan <james.quinlan@broadcom.com>
>
> This commit adds MSI to the Broadcom STB PCIe host controller. It does
> not add MSIX since that functionality is not in the HW. The MSI
> controller is physically located within the PCIe block, however, there
> is no reason why the MSI controller could not be moved elsewhere in
> the future.
>
> Since the internal Brcmstb MSI controller is intertwined with the PCIe
> controller, it is not its own platform device but rather part of the
> PCIe platform device.
>
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> Co-developed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
>
> ---
>
> Changes since v1:
> - Move revision code and some registers to this patch
> - Use PCIE_MSI_IRQ_DOMAIN in Kconfig
> - Remove redundant register read from ISR
> - Fail probe on MSI init error
> - Get rid of msi_internal
> - Use bitmap family of functions
> - Use edge triggered setup
> - Add comment regarding MultiMSI
> - Simplify compose_msi_msg to avoid reg read
>
> This is based on Jim's original submission[1] with some slight changes
> regarding how pcie->msi_target_addr is decided.
>
> [1] https://patchwork.kernel.org/patch/10605955/
>
> drivers/pci/controller/Kconfig | 1 +
> drivers/pci/controller/pcie-brcmstb.c | 326 +++++++++++++++++++++++++-
> 2 files changed, 326 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index 486d4d570233..eb9d973ad8e5 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -285,6 +285,7 @@ config PCIE_BRCMSTB
> bool "Broadcom Brcmstb PCIe host controller"
> depends on ARCH_BCM2835 || COMPILE_TEST
> depends on OF
> + depends on PCI_MSI_IRQ_DOMAIN
> help
> Say Y here to enable PCIe host controller support for
> Broadcom STB based SoCs, like the Raspberry Pi 4.
> diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
> index 8d81c5ab5979..35afd82107a7 100644
> --- a/drivers/pci/controller/pcie-brcmstb.c
> +++ b/drivers/pci/controller/pcie-brcmstb.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
> /* Copyright (C) 2009 - 2019 Broadcom */
>
> +#include <linux/bitops.h>
> #include <linux/clk.h>
> #include <linux/compiler.h>
> #include <linux/delay.h>
> @@ -8,11 +9,13 @@
> #include <linux/interrupt.h>
> #include <linux/io.h>
> #include <linux/ioport.h>
> +#include <linux/irqchip/chained_irq.h>
> #include <linux/irqdomain.h>
> #include <linux/kernel.h>
> #include <linux/list.h>
> #include <linux/log2.h>
> #include <linux/module.h>
> +#include <linux/msi.h>
> #include <linux/of_address.h>
> #include <linux/of_irq.h>
> #include <linux/of_pci.h>
> @@ -46,13 +49,18 @@
> #define PCIE_MISC_RC_BAR2_CONFIG_LO 0x4034
> #define PCIE_MISC_RC_BAR2_CONFIG_HI 0x4038
> #define PCIE_MISC_RC_BAR3_CONFIG_LO 0x403c
> +#define PCIE_MISC_MSI_BAR_CONFIG_LO 0x4044
> +#define PCIE_MISC_MSI_BAR_CONFIG_HI 0x4048
> +#define PCIE_MISC_MSI_DATA_CONFIG 0x404c
> #define PCIE_MISC_PCIE_CTRL 0x4064
> #define PCIE_MISC_PCIE_STATUS 0x4068
> +#define PCIE_MISC_REVISION 0x406c
> #define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT 0x4070
> #define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI 0x4080
> #define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI 0x4084
> #define PCIE_MISC_HARD_PCIE_HARD_DEBUG 0x4204
> #define PCIE_INTR2_CPU_BASE 0x4300
> +#define PCIE_MSI_INTR2_BASE 0x4500
>
> /*
> * Broadcom STB PCIe Register Field shift and mask info. The names are from the
> @@ -87,6 +95,8 @@
> #define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_SHIFT 0x4
> #define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK 0x40
> #define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_SHIFT 0x6
> +#define PCIE_MISC_REVISION_MAJMIN_MASK 0xffff
> +#define PCIE_MISC_REVISION_MAJMIN_SHIFT 0
I don't think these two are used.
> #define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_MASK 0xfff00000
> #define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_SHIFT 0x14
> #define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK 0xfff0
> @@ -104,6 +114,11 @@
> #define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0
>
> #define BRCM_NUM_PCIE_OUT_WINS 0x4
> +#define BRCM_INT_PCI_MSI_NR 32
> +#define BRCM_PCIE_HW_REV_33 0x0303
> +
> +#define BRCM_MSI_TARGET_ADDR_LT_4GB 0x0fffffffcULL
> +#define BRCM_MSI_TARGET_ADDR_GT_4GB 0xffffffffcULL
>
> #define BURST_SIZE_128 0
>
> @@ -182,6 +197,33 @@ struct brcm_window {
> dma_addr_t size;
> };
>
> +struct brcm_msi {
> + struct device *dev;
> + void __iomem *base;
> + struct device_node *np;
> + struct irq_domain *msi_domain;
> + struct irq_domain *inner_domain;
> + struct mutex lock; /* guards the alloc/free operations */
> + u64 target_addr;
> + int irq;
> +
> + /* intr_base is the base pointer for interrupt status/set/clr regs */
> + void __iomem *intr_base;
> +
> + /* intr_legacy_mask indicates how many bits are MSI interrupts */
> + u32 intr_legacy_mask;
> +
> + /*
> + * intr_legacy_offset indicates bit position of MSI_01. It is
> + * to map the register bit position to a hwirq that starts at 0.
> + */
> + u32 intr_legacy_offset;
> +
> + /* used indicates which MSI interrupts have been alloc'd */
> + unsigned long used;
> + unsigned int rev;
> +};
> +
> /* Internal PCIe Host Controller Information.*/
> struct brcm_pcie {
> struct device *dev;
> @@ -191,7 +233,10 @@ struct brcm_pcie {
> struct device_node *np;
> bool ssc;
> int gen;
> + u64 msi_target_addr;
> struct brcm_window out_wins[BRCM_NUM_PCIE_OUT_WINS];
> + struct brcm_msi *msi;
> + unsigned int rev;
> const int *reg_offsets;
> const int *reg_field_info;
> enum pcie_type type;
> @@ -433,6 +478,259 @@ static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
> LIMIT, tmp);
> }
>
> +static struct irq_chip brcm_msi_irq_chip = {
> + .name = "BRCM STB PCIe MSI",
> + .irq_ack = irq_chip_ack_parent,
> + .irq_mask = pci_msi_mask_irq,
> + .irq_unmask = pci_msi_unmask_irq,
> +};
> +
> +static struct msi_domain_info brcm_msi_domain_info = {
> + /* TODO: Multi MSI is technically supported by the controller */
As I understand we're not supporting MSI_FLAG_MULTI_PCI_MSI, not because there
is no hardware capability, but because the current use-case (RPi EPs) have no
need for it. It wouldn't be a stretch to add this support (compare your alloc
implementation with nwl_irq_domain_alloc from pcie-xilinx-nwl.c) - though I
appreciate the difficulity you may have with testing.
I'd probably replace the TODO line with:
/* Multi MSI is supported by the controller, but not by this driver */
> + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> + MSI_FLAG_PCI_MSIX),
Why the MSIX flag if the commit message says "It does not add MSIX since that
functionality is not in the HW." in the commit message?
> + .chip = &brcm_msi_irq_chip,
> +};
> +
> +static void brcm_pcie_msi_isr(struct irq_desc *desc)
> +{
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + unsigned long status, virq;
> + struct brcm_msi *msi;
> + u32 mask, bit, hwirq;
> + struct device *dev;
> +
> + chained_irq_enter(chip, desc);
> + msi = irq_desc_get_handler_data(desc);
> + mask = msi->intr_legacy_mask;
NIT: As you only use this variable once, you could get rid of it.
> + dev = msi->dev;
> +
> + status = bcm_readl(msi->intr_base + STATUS) & mask;
> + for_each_set_bit(bit, &status, BRCM_INT_PCI_MSI_NR) {
> +
> + /* Account for legacy interrupt offset */
> + hwirq = bit - msi->intr_legacy_offset;
> + virq = irq_find_mapping(msi->inner_domain, hwirq);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + dev_dbg(dev, "unexpected MSI\n");
> + }
> + chained_irq_exit(chip, desc);
> +}
> +
> +static void brcm_msi_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> + struct brcm_msi *msi = irq_data_get_irq_chip_data(data);
> +
> + msg->address_lo = lower_32_bits(msi->target_addr);
> + msg->address_hi = upper_32_bits(msi->target_addr);
> + msg->data = 0x6540 | data->hwirq;
> +}
> +
> +static int brcm_msi_set_affinity(struct irq_data *irq_data,
> + const struct cpumask *mask, bool force)
> +{
> + return -EINVAL;
> +}
> +
> +static void brcm_msi_ack_irq(struct irq_data *data)
> +{
> + struct brcm_msi *msi = irq_data_get_irq_chip_data(data);
> + u32 bit = data->hwirq + msi->intr_legacy_offset;
> +
> + bcm_writel(1 << bit, msi->intr_base + CLR);
> +}
> +
> +
> +static struct irq_chip brcm_msi_bottom_irq_chip = {
> + .name = "BRCM STB MSI",
> + .irq_compose_msi_msg = brcm_msi_compose_msi_msg,
> + .irq_set_affinity = brcm_msi_set_affinity,
> + .irq_ack = brcm_msi_ack_irq,
> +};
> +
> +static int brcm_msi_alloc(struct brcm_msi *msi)
> +{
> + int hwirq;
> +
> + mutex_lock(&msi->lock);
> + hwirq = bitmap_find_free_region(&msi->used, BRCM_INT_PCI_MSI_NR, 0);
> + if (hwirq >= 0)
> + hwirq = hwirq - msi->intr_legacy_offset;
> + mutex_unlock(&msi->lock);
> +
> + return hwirq;
> +}
> +
> +static void brcm_msi_free(struct brcm_msi *msi, unsigned long hwirq)
> +{
> + mutex_lock(&msi->lock);
> + bitmap_release_region(&msi->used, hwirq + msi->intr_legacy_offset, 0);
> + mutex_unlock(&msi->lock);
> +}
> +
> +static int brcm_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
> + unsigned int nr_irqs, void *args)
> +{
> + struct brcm_msi *msi = domain->host_data;
> + int hwirq;
> +
> + hwirq = brcm_msi_alloc(msi);
> +
> + if (hwirq < 0)
> + return hwirq;
> +
> + irq_domain_set_info(domain, virq, (irq_hw_number_t)hwirq,
> + &brcm_msi_bottom_irq_chip, domain->host_data,
> + handle_edge_irq, NULL, NULL);
> + return 0;
> +}
> +
> +static void brcm_irq_domain_free(struct irq_domain *domain,
> + unsigned int virq, unsigned int nr_irqs)
> +{
> + struct irq_data *d = irq_domain_get_irq_data(domain, virq);
> + struct brcm_msi *msi = irq_data_get_irq_chip_data(d);
> +
> + brcm_msi_free(msi, d->hwirq);
> +}
> +
> +static const struct irq_domain_ops msi_domain_ops = {
> + .alloc = brcm_irq_domain_alloc,
> + .free = brcm_irq_domain_free,
> +};
> +
> +static int brcm_allocate_domains(struct brcm_msi *msi)
> +{
> + struct fwnode_handle *fwnode = of_node_to_fwnode(msi->np);
> + struct device *dev = msi->dev;
> +
> + msi->inner_domain = irq_domain_add_linear(NULL, BRCM_INT_PCI_MSI_NR,
> + &msi_domain_ops, msi);
> + if (!msi->inner_domain) {
> + dev_err(dev, "failed to create IRQ domain\n");
> + return -ENOMEM;
> + }
> +
> + msi->msi_domain = pci_msi_create_irq_domain(fwnode,
> + &brcm_msi_domain_info,
> + msi->inner_domain);
> + if (!msi->msi_domain) {
> + dev_err(dev, "failed to create MSI domain\n");
> + irq_domain_remove(msi->inner_domain);
> + return -ENOMEM;
> + }
> +
> + return 0;
> +}
> +
> +static void brcm_free_domains(struct brcm_msi *msi)
> +{
> + irq_domain_remove(msi->msi_domain);
> + irq_domain_remove(msi->inner_domain);
> +}
> +
> +static void brcm_msi_remove(struct brcm_pcie *pcie)
> +{
> + struct brcm_msi *msi = pcie->msi;
> +
> + if (!msi)
> + return;
> + irq_set_chained_handler(msi->irq, NULL);
> + irq_set_handler_data(msi->irq, NULL);
> + brcm_free_domains(msi);
> +}
> +
> +static void brcm_msi_set_regs(struct brcm_msi *msi)
> +{
> + u32 data_val, msi_lo, msi_hi;
> +
> + if (msi->rev >= BRCM_PCIE_HW_REV_33) {
> + /*
> + * ffe0 -- least sig 5 bits are 0 indicating 32 msgs
> + * 6540 -- this is our arbitrary unique data value
> + */
> + data_val = 0xffe06540;
> + } else {
> + /*
> + * fff8 -- least sig 3 bits are 0 indicating 8 msgs
> + * 6540 -- this is our arbitrary unique data value
> + */
> + data_val = 0xfff86540;
> + }
> +
> + /* Unmaks MSIs */
> + bcm_writel(0xffffffff & msi->intr_legacy_mask,
> + msi->intr_base + MASK_CLR);
> +
> + msi_lo = lower_32_bits(msi->target_addr);
> + msi_hi = upper_32_bits(msi->target_addr);
> + /*
> + * The 0 bit of PCIE_MISC_MSI_BAR_CONFIG_LO is repurposed to MSI
> + * enable, which we set to 1.
> + */
> + bcm_writel(msi_lo | 1, msi->base + PCIE_MISC_MSI_BAR_CONFIG_LO);
> + bcm_writel(msi_hi, msi->base + PCIE_MISC_MSI_BAR_CONFIG_HI);
> + bcm_writel(data_val, msi->base + PCIE_MISC_MSI_DATA_CONFIG);
> +}
> +
> +static int brcm_pcie_enable_msi(struct brcm_pcie *pcie)
> +{
> + struct brcm_msi *msi;
> + int irq, ret;
> + struct device *dev = pcie->dev;
> +
> + irq = irq_of_parse_and_map(dev->of_node, 1);
> + if (irq <= 0) {
> + dev_err(dev, "cannot map msi intr\n");
NIT: I think we can spare a few more characters and replace intr with interrupt.
> + return -ENODEV;
> + }
> +
> + msi = devm_kzalloc(dev, sizeof(struct brcm_msi), GFP_KERNEL);
> + if (!msi)
> + return -ENOMEM;
> +
> + msi->dev = dev;
> + msi->base = pcie->base;
> + msi->rev = pcie->rev;
> + msi->np = pcie->np;
> + msi->target_addr = pcie->msi_target_addr;
> + msi->irq = irq;
> +
> + ret = brcm_allocate_domains(msi);
> + if (ret)
> + return ret;
> +
> + irq_set_chained_handler_and_data(msi->irq, brcm_pcie_msi_isr, msi);
> +
> + if (msi->rev >= BRCM_PCIE_HW_REV_33) {
> + msi->intr_base = msi->base + PCIE_MSI_INTR2_BASE;
> + /*
> + * This version of PCIe hw has only 32 intr bits
> + * starting at bit position 0.
> + */
> + msi->intr_legacy_mask = 0xffffffff;
> + msi->intr_legacy_offset = 0x0;
> + msi->used = 0x0;
> +
> + } else {
> + msi->intr_base = msi->base + PCIE_INTR2_CPU_BASE;
> + /*
> + * This version of PCIe hw has only 8 intr bits starting
> + * at bit position 24.
> + */
> + msi->intr_legacy_mask = 0xff000000;
> + msi->intr_legacy_offset = 24;
> + msi->used = 0x00ffffff;
> + }
> +
> + brcm_msi_set_regs(msi);
> + pcie->msi = msi;
> +
> + return 0;
> +}
> +
> /* Configuration space read/write support */
> static int brcm_pcie_cfg_index(int busnr, int devfn, int reg)
> {
> @@ -584,6 +882,10 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> /* Wait for SerDes to be stable */
> usleep_range(100, 200);
>
> + /* Grab the PCIe hw revision number */
> + tmp = bcm_readl(base + PCIE_MISC_REVISION);
> + pcie->rev = EXTRACT_FIELD(tmp, PCIE_MISC_REVISION, MAJMIN);
> +
> /* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
> tmp = INSERT_FIELD(0, PCIE_MISC_MISC_CTRL, SCB_ACCESS_EN, 1);
> tmp = INSERT_FIELD(tmp, PCIE_MISC_MISC_CTRL, CFG_READ_UR_MODE, 1);
> @@ -596,6 +898,18 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
> if (ret)
> return ret;
>
> + /*
> + * We ideally want the MSI target address to be located in the 32bit
> + * addressable memory area. Some devices might depend on it. This is
> + * possible either when the inbound window is located above the lower
> + * 4GB or when the inbound and outbound areas fit in the lower 4GB of
> + * memory.
> + */
> + if (rc_bar2_offset >= SZ_4G || (rc_bar2_size + rc_bar2_offset) <= SZ_4G)
> + pcie->msi_target_addr = BRCM_MSI_TARGET_ADDR_LT_4GB;
> + else
> + pcie->msi_target_addr = BRCM_MSI_TARGET_ADDR_GT_4GB;
> +
Can this above hunk me moved into brcm_pcie_enable_msi? You could then avoid
having the pcie->msi_target_addr and just have a single msi->target_addr
variable?
Thanks,
Andrew Murray
> tmp = lower_32_bits(rc_bar2_offset);
> tmp = INSERT_FIELD(tmp, PCIE_MISC_RC_BAR2_CONFIG_LO, SIZE,
> brcm_pcie_encode_ibar_size(rc_bar2_size));
> @@ -734,6 +1048,7 @@ static void brcm_pcie_turn_off(struct brcm_pcie *pcie)
>
> static void __brcm_pcie_remove(struct brcm_pcie *pcie)
> {
> + brcm_msi_remove(pcie);
> brcm_pcie_turn_off(pcie);
> clk_disable_unprepare(pcie->clk);
> clk_put(pcie->clk);
> @@ -758,7 +1073,7 @@ MODULE_DEVICE_TABLE(of, brcm_pcie_match);
>
> static int brcm_pcie_probe(struct platform_device *pdev)
> {
> - struct device_node *np = pdev->dev.of_node;
> + struct device_node *np = pdev->dev.of_node, *msi_np;
> const struct pcie_cfg_data *data;
> struct pci_host_bridge *bridge;
> struct brcm_pcie *pcie;
> @@ -813,6 +1128,15 @@ static int brcm_pcie_probe(struct platform_device *pdev)
> if (ret)
> goto fail;
>
> + msi_np = of_parse_phandle(pcie->np, "msi-parent", 0);
> + if (pci_msi_enabled() && msi_np == pcie->np) {
> + ret = brcm_pcie_enable_msi(pcie);
> + if (ret) {
> + dev_err(pcie->dev, "probe of internal MSI failed");
> + goto fail;
> + }
> + }
> +
> bridge->dev.parent = &pdev->dev;
> bridge->busnr = 0;
> bridge->ops = &brcm_pcie_ops;
> --
> 2.24.0
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver
2019-11-21 12:59 ` Nicolas Saenz Julienne
@ 2019-11-21 15:44 ` Andrew Murray
2019-11-21 21:07 ` Jim Quinlan
1 sibling, 0 replies; 36+ messages in thread
From: Andrew Murray @ 2019-11-21 15:44 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Florian Fainelli, mbrugger, maz, phil, linux-kernel,
jeremy.linton, Eric Anholt, Lorenzo Pieralisi,
bcm-kernel-feedback-list, Stefan Wahren, james.quinlan,
linux-pci, Bjorn Helgaas, linux-arm-kernel, linux-rpi-kernel
On Thu, Nov 21, 2019 at 01:59:40PM +0100, Nicolas Saenz Julienne wrote:
> Hi Andrew,
>
> On Thu, 2019-11-21 at 12:03 +0000, Andrew Murray wrote:
> > > > > +static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
> > > > > + unsigned int win, phys_addr_t
> > > > > cpu_addr,
> > > > > + dma_addr_t pcie_addr, dma_addr_t
> > > > > size)
> > > > > +{
> > > > > + phys_addr_t cpu_addr_mb, limit_addr_mb;
> > > > > + void __iomem *base = pcie->base;
> > > > > + u32 tmp;
> > > > > +
> > > > > + /* Set the base of the pcie_addr window */
> > > > > + bcm_writel(lower_32_bits(pcie_addr) + MMIO_ENDIAN,
> > > > > + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + (win * 8));
> > > > > + bcm_writel(upper_32_bits(pcie_addr),
> > > > > + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + (win * 8));
> > > > > +
> > > > > + cpu_addr_mb = cpu_addr >> 20;
> > > > > + limit_addr_mb = (cpu_addr + size - 1) >> 20;
> > > > > +
> > > > > + /* Write the addr base low register */
> > > > > + WR_FLD_WITH_OFFSET(base, (win * 4),
> > > > > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
> > > > > + BASE, cpu_addr_mb);
> > > > > + /* Write the addr limit low register */
> > > > > + WR_FLD_WITH_OFFSET(base, (win * 4),
> > > > > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
> > > > > + LIMIT, limit_addr_mb);
> > > > > +
> > > > > + /* Write the cpu addr high register */
> > > > > + tmp = (u32)(cpu_addr_mb >>
> > > > > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
> > > >
> > > > Despite the name _MASK_BITS, this isn't being used as a mask. Is this
> > > > making
> > > > some assumption about the value of cpu_addr from the DT?
> > >
> > > It should be read _NUM_MASK_BITS. It contains the number of set bits on that
> > > specific mask. I agree it's not ideal. I think I'll be able to do away with
> > > it
> > > using the bitfield.h macros.
> >
> > Also why do you have a define for
> > PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS but not the '20' shift
> > used for the low registers?
>
> Good point, I'm changing it to something more explicit:
>
> cpu_addr_mb = cpu_addr / SZ_1M;
>
> As for [...]_NUM_MASK_BITS I'm looking for a smart/generic way to calculate it
> from the actual mask. No luck so far. If not, I think I'll simply leave it as
> is for now.
OK.
>
> > > FYI, What's happening here is that we have to save the CPU address range
> > > (which
> > > is already shifted right 20 positions) in two parts, the lower 12 bits go
> > > into
> > > PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT while the higher 8 bits go into
> > > PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI or
> > > PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI.
> >
> > The hardware spec require bits 31:20 of the address, and the high registers
> > require 39:32 right?
>
> Yes, that's it.
>
> > (Apologies, the indirection by the WR_FLD_** macros easily confuses me. These
> > type of macros are helpful, or rather would be if the whole kernel used them.
> > I think they can add confusion when each driver has its own set of similar
> > macros. This is why its *really* helpful to use any existing macros in the
> > kernel - and only invent new ones if needed).
>
> I agree it's pretty confusing, I think v3, using bitfield.h as much as
> possible, looks substantially more welcoming.
Looking forward to seeing it.
>
> > > [...]
> > >
> > > > > +static inline int brcm_pcie_get_rc_bar2_size_and_offset(struct
> > > > > brcm_pcie
> > > > > *pcie,
> > > > > + u64
> > > > > *rc_bar2_size,
> > > > > + u64
> > > > > *rc_bar2_offset)
> > > > > +{
> > > > > + struct pci_host_bridge *bridge =
> > > > > pci_host_bridge_from_priv(pcie);
> > > > > + struct device *dev = pcie->dev;
> > > > > + struct resource_entry *entry;
> > > > > + u64 total_mem_size = 0;
> > > > > +
> > > > > + *rc_bar2_offset = -1;
> > > > > +
> > > > > + resource_list_for_each_entry(entry, &bridge->dma_ranges) {
> > > > > + /*
> > > > > + * We're promised the RC will provide a contiguous view
> > > > > of
> > > > > + * memory to downstream devices. We can then infer the
> > > > > + * rc_bar2_offset from the lower available dma-range
> > > > > offset.
> > > > > + */
> > > > > + if (entry->offset < *rc_bar2_offset)
> > > > > + *rc_bar2_offset = entry->offset;
> > > > > +
> > > > > + total_mem_size += entry->res->end - entry->res->start +
> > > > > 1;
> > > >
> > > > This requires that if there are multiple dma-ranges, then there are no
> > > > gaps
> > > > between them right?
> > >
> > > Yes, the PCI view of inbound memory will always be gapless. See an example
> > > here: https://patchwork.kernel.org/patch/10605957/
> >
> > Thanks for the reference.
> >
> >
> > > That said, iterating over the dma-ranges is not strictly necessary for now
> > > as
> > > RPi4 is assured to only need one. If that's bothering you I can always
> > > remove
> > > it for now.
> >
> > One purpose of this function is to validate that the information given in the
> > device tree is valid - I've seen other feedback on these lists where the view
> > is taken that 'it's not the job of the kernel to validate the DT'. Subscribing
> > to this view would be a justification for removing this validation -
> > especially
> > given that the bindings you include have only one dma-range (in any case if
> > there are constraints you ought to include them in the binding document).
> >
> > Though the problem with this point of view is that if the DT is wrong, it may
> > be possible for the driver to work well enough to do some function but with
> > some horrible side effects that are difficult to track down to a bad DT.
> >
> > If you assume the DT will only have one range (at least for the Pi) then this
> > code will never be used and so can probably be removed.
>
> Ok, less is more, I'll simplify it.
>
> [...]
>
> > > > > + continue;
> > > > > +
> > > > > + if (num_out_wins >= BRCM_NUM_PCIE_OUT_WINS) {
> > > > > + dev_err(pcie->dev, "too many outbound wins\n");
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + brcm_pcie_set_outbound_win(pcie, num_out_wins, res-
> > > > > >start,
> > > > > + res->start - entry->offset,
> > > > > + res->end - res->start + 1);
> > > > > + num_out_wins++;
> > > > > + }
> > > > > +
> > > > > + /*
> > > > > + * For config space accesses on the RC, show the right class for
> > > > > + * a PCIe-PCIe bridge (the default setting is to be EP mode).
> > > > > + */
> > > > > + WR_FLD_RB(base, PCIE_RC_CFG_PRIV1_ID_VAL3, CLASS_CODE,
> > > > > 0x060400);
> > > >
> > > > Why does this need to be _RB ? I haven't looked at all of the uses of _RB
> > > > though I think there are others that may not be necessary.
> > >
> > > We're reviewing the _RB usage with Jim, I'll come back to you on that topic
> > > later.
> >
> > Thanks.
>
> Jim and Florian went over all the _RB usages and found out none of them applied
> to the Pi. Apparently they where introduced as a form of barrier needed on some
> MIPS SoCs. Sorry for that, I'll remove them.
If I recall correctly, a read cannot overtake a write. Therefore adding a read
after a write ensures that the write has 'happened' to some degree...
>
> > > [...]
> > >
> > > > > + __brcm_pcie_remove(pcie);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +static const struct of_device_id brcm_pcie_match[] = {
> > > > > + { .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
> > > >
> > > > I'd rather see use of the pcie_cfg_data structure removed from this
> > > > series.
> > > >
> > > > I've seen the comments in the previous thread [1], and I understand that
> > > > the intention is that this driver will eventually be used for other SOCs.
> > > >
> > > > However this indirection isn't needed *now* and it makes reviewing this
> > > > patch more difficult. If and when a later series is made to cover other
> > > > SOCs - then I'd expect that series to find a way to apply this
> > > > indirection.
> > > >
> > > > And if that later series is more difficult to review because of the newly
> > > > added indirection, then I'd expect an early patch of that series to apply
> > > > the indirection in a single patch - which would be easy to review.
> > > >
> > > > The other risk of such premature changes like this is that when you come
> > > > to adding other SOCs, you may then discover that there were shortcomings
> > > > in the way you've approached it here.
> > > >
> > >
> > > I was about to make a point similar to Florian's. I'll wait for your reply
> > > and
> > > change this accordingly.
> >
> > No problem.
>
> Following your reply, I'll remove it.
Thanks,
Andrew Murray
>
> Regards,
> Nicolas
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver
2019-11-21 13:26 ` Nicolas Saenz Julienne
@ 2019-11-21 15:46 ` Andrew Murray
0 siblings, 0 replies; 36+ messages in thread
From: Andrew Murray @ 2019-11-21 15:46 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Florian Fainelli, mbrugger, maz, phil, linux-kernel,
jeremy.linton, Eric Anholt, Lorenzo Pieralisi,
bcm-kernel-feedback-list, Stefan Wahren, james.quinlan,
linux-pci, Bjorn Helgaas, linux-arm-kernel, linux-rpi-kernel
On Thu, Nov 21, 2019 at 02:26:15PM +0100, Nicolas Saenz Julienne wrote:
> On Thu, 2019-11-21 at 12:03 +0000, Andrew Murray wrote:
> > On Wed, Nov 20, 2019 at 08:53:30PM +0100, Nicolas Saenz Julienne wrote:
> > One purpose of this function is to validate that the information given in the
> > device tree is valid - I've seen other feedback on these lists where the view
> > is taken that 'it's not the job of the kernel to validate the DT'. Subscribing
> > to this view would be a justification for removing this validation -
> > especially
> > given that the bindings you include have only one dma-range (in any case if
> > there are constraints you ought to include them in the binding document).
> >
> > Though the problem with this point of view is that if the DT is wrong, it may
> > be possible for the driver to work well enough to do some function but with
> > some horrible side effects that are difficult to track down to a bad DT.
>
> As for the validation, I think in this specific case it's still worthwhile. As
> you might know, there is a bug on the first revision of RPI4's PCIe integration
> which blocks any access higher than 3GB. Further revisions fix this and allow
> full memory addressing.
>
> I've been working with Phil Elwell (from the RPi foundation) to solve this in a
> way that plays well with upstream and this driver (I'll be able to test the new
> revision before this gets in). The solution is, unsurprisingly, for the
> firmware to edit the DTB passed to the kernel based on the board revision.
> Given that there is some live manipulation of the dma-ranges I'd rather leave
> the validation check.
>
> If you don't disagree with the above I'll add an extra code comment explaining
> why we feel the need to verify the device-tree contents.
I'll be interested in seeing it.
Thanks,
Andrew Murray
>
> Regards,
> Nicolas
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 5/6] PCI: brcmstb: add MSI capability
2019-11-21 15:38 ` Andrew Murray
@ 2019-11-21 17:19 ` Nicolas Saenz Julienne
0 siblings, 0 replies; 36+ messages in thread
From: Nicolas Saenz Julienne @ 2019-11-21 17:19 UTC (permalink / raw)
To: Andrew Murray
Cc: maz, linux-kernel, Lorenzo Pieralisi, Florian Fainelli,
bcm-kernel-feedback-list, Eric Anholt, Stefan Wahren,
james.quinlan, mbrugger, phil, jeremy.linton, Bjorn Helgaas,
linux-pci, linux-rpi-kernel, linux-arm-kernel
[-- Attachment #1: Type: text/plain, Size: 3491 bytes --]
On Thu, 2019-11-21 at 15:38 +0000, Andrew Murray wrote:
> > #define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_SHIFT 0x4
> > #define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK 0x40
> > #define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_SHIFT 0x6
> > +#define PCIE_MISC_REVISION_MAJMIN_MASK 0xffff
> > +#define PCIE_MISC_REVISION_MAJMIN_SHIFT 0
>
> I don't think these two are used.
Yes, in brcm_pcie_setup(), when we grab the PCIe hw revision number.
[...]
> > +static struct msi_domain_info brcm_msi_domain_info = {
> > + /* TODO: Multi MSI is technically supported by the controller */
>
> As I understand we're not supporting MSI_FLAG_MULTI_PCI_MSI, not because there
> is no hardware capability, but because the current use-case (RPi EPs) have no
> need for it. It wouldn't be a stretch to add this support (compare your alloc
> implementation with nwl_irq_domain_alloc from pcie-xilinx-nwl.c) - though I
> appreciate the difficulity you may have with testing.
>
> I'd probably replace the TODO line with:
>
> /* Multi MSI is supported by the controller, but not by this driver */
I'll replace the comment for now.
I've already seen people who unsoldered the XHCI chip on the RPi4 to then add a
proper PCI connector. If someone shows up with such setup, I'll be happy to
work out the MultiMSI support.
[...]
> > + .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
> > + MSI_FLAG_PCI_MSIX),
>
> Why the MSIX flag if the commit message says "It does not add MSIX since that
> functionality is not in the HW." in the commit message?
That's plain wrong, sorry.
[...]
> > + .chip = &brcm_msi_irq_chip,
> > +};
> > +
> > +static void brcm_pcie_msi_isr(struct irq_desc *desc)
> > +{
> > + struct irq_chip *chip = irq_desc_get_chip(desc);
> > + unsigned long status, virq;
> > + struct brcm_msi *msi;
> > + u32 mask, bit, hwirq;
> > + struct device *dev;
> > +
> > + chained_irq_enter(chip, desc);
> > + msi = irq_desc_get_handler_data(desc);
> > + mask = msi->intr_legacy_mask;
>
> NIT: As you only use this variable once, you could get rid of it.
OK
[...]
> > +
> > +static int brcm_pcie_enable_msi(struct brcm_pcie *pcie)
> > +{
> > + struct brcm_msi *msi;
> > + int irq, ret;
> > + struct device *dev = pcie->dev;
> > +
> > + irq = irq_of_parse_and_map(dev->of_node, 1);
> > + if (irq <= 0) {
> > + dev_err(dev, "cannot map msi intr\n");
>
> NIT: I think we can spare a few more characters and replace intr with
> interrupt.
Of course.
[...]
> > + /*
> > + * We ideally want the MSI target address to be located in the 32bit
> > + * addressable memory area. Some devices might depend on it. This is
> > + * possible either when the inbound window is located above the lower
> > + * 4GB or when the inbound and outbound areas fit in the lower 4GB of
> > + * memory.
> > + */
> > + if (rc_bar2_offset >= SZ_4G || (rc_bar2_size + rc_bar2_offset) <= SZ_4G)
> > + pcie->msi_target_addr = BRCM_MSI_TARGET_ADDR_LT_4GB;
> > + else
> > + pcie->msi_target_addr = BRCM_MSI_TARGET_ADDR_GT_4GB;
> > +
>
> Can this above hunk me moved into brcm_pcie_enable_msi? You could then avoid
> having the pcie->msi_target_addr and just have a single msi->target_addr
> variable?
As it depends on rc_bar2_offset and rc_bar2_size it's not really possible
without having to store those values in exchange, which IMO amounts to
negative benefit.
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver
2019-11-21 12:59 ` Nicolas Saenz Julienne
2019-11-21 15:44 ` Andrew Murray
@ 2019-11-21 21:07 ` Jim Quinlan
2019-11-22 14:59 ` Robin Murphy
1 sibling, 1 reply; 36+ messages in thread
From: Jim Quinlan @ 2019-11-21 21:07 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: Andrew Murray, Florian Fainelli, mbrugger, maz, Phil Elwell,
linux-kernel, Jeremy Linton, Eric Anholt, Lorenzo Pieralisi,
bcm-kernel-feedback-list, Stefan Wahren, Jim Quinlan, linux-pci,
Bjorn Helgaas,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-rpi-kernel
On Thu, Nov 21, 2019 at 8:02 AM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> wrote:
>
> Hi Andrew,
>
> On Thu, 2019-11-21 at 12:03 +0000, Andrew Murray wrote:
> > > > > +static void brcm_pcie_set_outbound_win(struct brcm_pcie *pcie,
> > > > > + unsigned int win, phys_addr_t
> > > > > cpu_addr,
> > > > > + dma_addr_t pcie_addr, dma_addr_t
> > > > > size)
> > > > > +{
> > > > > + phys_addr_t cpu_addr_mb, limit_addr_mb;
> > > > > + void __iomem *base = pcie->base;
> > > > > + u32 tmp;
> > > > > +
> > > > > + /* Set the base of the pcie_addr window */
> > > > > + bcm_writel(lower_32_bits(pcie_addr) + MMIO_ENDIAN,
> > > > > + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO + (win * 8));
> > > > > + bcm_writel(upper_32_bits(pcie_addr),
> > > > > + base + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_HI + (win * 8));
> > > > > +
> > > > > + cpu_addr_mb = cpu_addr >> 20;
> > > > > + limit_addr_mb = (cpu_addr + size - 1) >> 20;
> > > > > +
> > > > > + /* Write the addr base low register */
> > > > > + WR_FLD_WITH_OFFSET(base, (win * 4),
> > > > > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
> > > > > + BASE, cpu_addr_mb);
> > > > > + /* Write the addr limit low register */
> > > > > + WR_FLD_WITH_OFFSET(base, (win * 4),
> > > > > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT,
> > > > > + LIMIT, limit_addr_mb);
> > > > > +
> > > > > + /* Write the cpu addr high register */
> > > > > + tmp = (u32)(cpu_addr_mb >>
> > > > > + PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS);
> > > >
> > > > Despite the name _MASK_BITS, this isn't being used as a mask. Is this
> > > > making
> > > > some assumption about the value of cpu_addr from the DT?
> > >
> > > It should be read _NUM_MASK_BITS. It contains the number of set bits on that
> > > specific mask. I agree it's not ideal. I think I'll be able to do away with
> > > it
> > > using the bitfield.h macros.
> >
> > Also why do you have a define for
> > PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_NUM_MASK_BITS but not the '20' shift
> > used for the low registers?
>
> Good point, I'm changing it to something more explicit:
>
> cpu_addr_mb = cpu_addr / SZ_1M;
>
> As for [...]_NUM_MASK_BITS I'm looking for a smart/generic way to calculate it
> from the actual mask. No luck so far. If not, I think I'll simply leave it as
> is for now.
>
> > > FYI, What's happening here is that we have to save the CPU address range
> > > (which
> > > is already shifted right 20 positions) in two parts, the lower 12 bits go
> > > into
> > > PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT while the higher 8 bits go into
> > > PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI or
> > > PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI.
> >
> > The hardware spec require bits 31:20 of the address, and the high registers
> > require 39:32 right?
>
> Yes, that's it.
>
> > (Apologies, the indirection by the WR_FLD_** macros easily confuses me. These
> > type of macros are helpful, or rather would be if the whole kernel used them.
> > I think they can add confusion when each driver has its own set of similar
> > macros. This is why its *really* helpful to use any existing macros in the
> > kernel - and only invent new ones if needed).
>
> I agree it's pretty confusing, I think v3, using bitfield.h as much as
> possible, looks substantially more welcoming.
The reason we use custom macros is because we'd like to keep the
register names the same as the HW declares and our internal tools
support. As you may have noticed, our register names are unusually
long and it is hard to fit a simple read or write field assignment
within 80 columns w/o using custom macros tailored to our register
names' format.
Perhaps Nicolas can pull a rabbit out of a hat and use Linux macros
while keeping our long register names, but if he has to use his own
shorter register names it will become harder for Broadcom developers
to debug this driver.
Thanks,
Jim
>
> > > [...]
> > >
> > > > > +static inline int brcm_pcie_get_rc_bar2_size_and_offset(struct
> > > > > brcm_pcie
> > > > > *pcie,
> > > > > + u64
> > > > > *rc_bar2_size,
> > > > > + u64
> > > > > *rc_bar2_offset)
> > > > > +{
> > > > > + struct pci_host_bridge *bridge =
> > > > > pci_host_bridge_from_priv(pcie);
> > > > > + struct device *dev = pcie->dev;
> > > > > + struct resource_entry *entry;
> > > > > + u64 total_mem_size = 0;
> > > > > +
> > > > > + *rc_bar2_offset = -1;
> > > > > +
> > > > > + resource_list_for_each_entry(entry, &bridge->dma_ranges) {
> > > > > + /*
> > > > > + * We're promised the RC will provide a contiguous view
> > > > > of
> > > > > + * memory to downstream devices. We can then infer the
> > > > > + * rc_bar2_offset from the lower available dma-range
> > > > > offset.
> > > > > + */
> > > > > + if (entry->offset < *rc_bar2_offset)
> > > > > + *rc_bar2_offset = entry->offset;
> > > > > +
> > > > > + total_mem_size += entry->res->end - entry->res->start +
> > > > > 1;
> > > >
> > > > This requires that if there are multiple dma-ranges, then there are no
> > > > gaps
> > > > between them right?
> > >
> > > Yes, the PCI view of inbound memory will always be gapless. See an example
> > > here: https://patchwork.kernel.org/patch/10605957/
> >
> > Thanks for the reference.
> >
> >
> > > That said, iterating over the dma-ranges is not strictly necessary for now
> > > as
> > > RPi4 is assured to only need one. If that's bothering you I can always
> > > remove
> > > it for now.
> >
> > One purpose of this function is to validate that the information given in the
> > device tree is valid - I've seen other feedback on these lists where the view
> > is taken that 'it's not the job of the kernel to validate the DT'. Subscribing
> > to this view would be a justification for removing this validation -
> > especially
> > given that the bindings you include have only one dma-range (in any case if
> > there are constraints you ought to include them in the binding document).
> >
> > Though the problem with this point of view is that if the DT is wrong, it may
> > be possible for the driver to work well enough to do some function but with
> > some horrible side effects that are difficult to track down to a bad DT.
> >
> > If you assume the DT will only have one range (at least for the Pi) then this
> > code will never be used and so can probably be removed.
>
> Ok, less is more, I'll simplify it.
>
> [...]
>
> > > > > + continue;
> > > > > +
> > > > > + if (num_out_wins >= BRCM_NUM_PCIE_OUT_WINS) {
> > > > > + dev_err(pcie->dev, "too many outbound wins\n");
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > + brcm_pcie_set_outbound_win(pcie, num_out_wins, res-
> > > > > >start,
> > > > > + res->start - entry->offset,
> > > > > + res->end - res->start + 1);
> > > > > + num_out_wins++;
> > > > > + }
> > > > > +
> > > > > + /*
> > > > > + * For config space accesses on the RC, show the right class for
> > > > > + * a PCIe-PCIe bridge (the default setting is to be EP mode).
> > > > > + */
> > > > > + WR_FLD_RB(base, PCIE_RC_CFG_PRIV1_ID_VAL3, CLASS_CODE,
> > > > > 0x060400);
> > > >
> > > > Why does this need to be _RB ? I haven't looked at all of the uses of _RB
> > > > though I think there are others that may not be necessary.
> > >
> > > We're reviewing the _RB usage with Jim, I'll come back to you on that topic
> > > later.
> >
> > Thanks.
>
> Jim and Florian went over all the _RB usages and found out none of them applied
> to the Pi. Apparently they where introduced as a form of barrier needed on some
> MIPS SoCs. Sorry for that, I'll remove them.
>
> > > [...]
> > >
> > > > > + __brcm_pcie_remove(pcie);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +static const struct of_device_id brcm_pcie_match[] = {
> > > > > + { .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
> > > >
> > > > I'd rather see use of the pcie_cfg_data structure removed from this
> > > > series.
> > > >
> > > > I've seen the comments in the previous thread [1], and I understand that
> > > > the intention is that this driver will eventually be used for other SOCs.
> > > >
> > > > However this indirection isn't needed *now* and it makes reviewing this
> > > > patch more difficult. If and when a later series is made to cover other
> > > > SOCs - then I'd expect that series to find a way to apply this
> > > > indirection.
> > > >
> > > > And if that later series is more difficult to review because of the newly
> > > > added indirection, then I'd expect an early patch of that series to apply
> > > > the indirection in a single patch - which would be easy to review.
> > > >
> > > > The other risk of such premature changes like this is that when you come
> > > > to adding other SOCs, you may then discover that there were shortcomings
> > > > in the way you've approached it here.
> > > >
> > >
> > > I was about to make a point similar to Florian's. I'll wait for your reply
> > > and
> > > change this accordingly.
> >
> > No problem.
>
> Following your reply, I'll remove it.
>
> Regards,
> Nicolas
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver
2019-11-21 21:07 ` Jim Quinlan
@ 2019-11-22 14:59 ` Robin Murphy
0 siblings, 0 replies; 36+ messages in thread
From: Robin Murphy @ 2019-11-22 14:59 UTC (permalink / raw)
To: Jim Quinlan, Nicolas Saenz Julienne
Cc: Florian Fainelli, maz, Phil Elwell, linux-kernel, Jeremy Linton,
Eric Anholt, mbrugger, bcm-kernel-feedback-list, Stefan Wahren,
Jim Quinlan, linux-pci, Bjorn Helgaas, Andrew Murray,
Lorenzo Pieralisi,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-rpi-kernel
On 21/11/2019 9:07 pm, Jim Quinlan wrote:
[...]
>> As for [...]_NUM_MASK_BITS I'm looking for a smart/generic way to calculate it
>> from the actual mask. No luck so far. If not, I think I'll simply leave it as
>> is for now.
HWEIGHT()?
>>>> FYI, What's happening here is that we have to save the CPU address range
>>>> (which
>>>> is already shifted right 20 positions) in two parts, the lower 12 bits go
>>>> into
>>>> PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT while the higher 8 bits go into
>>>> PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_HI or
>>>> PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LIMIT_HI.
>>>
>>> The hardware spec require bits 31:20 of the address, and the high registers
>>> require 39:32 right?
>>
>> Yes, that's it.
>>
>>> (Apologies, the indirection by the WR_FLD_** macros easily confuses me. These
>>> type of macros are helpful, or rather would be if the whole kernel used them.
>>> I think they can add confusion when each driver has its own set of similar
>>> macros. This is why its *really* helpful to use any existing macros in the
>>> kernel - and only invent new ones if needed).
>>
>> I agree it's pretty confusing, I think v3, using bitfield.h as much as
>> possible, looks substantially more welcoming.
>
> The reason we use custom macros is because we'd like to keep the
> register names the same as the HW declares and our internal tools
> support. As you may have noticed, our register names are unusually
> long and it is hard to fit a simple read or write field assignment
> within 80 columns w/o using custom macros tailored to our register
> names' format.
>
> Perhaps Nicolas can pull a rabbit out of a hat and use Linux macros
> while keeping our long register names, but if he has to use his own
> shorter register names it will become harder for Broadcom developers
> to debug this driver.
Regardless of the length of the names, the standard bitfield helpers can
still make things easier to reason about - in this particular case I
think you could lose some boilerplate and indirection with essentially
no change to the readability you're concerned for - compare:
#define REG_NAME ...
#define REG_NAME_FIELD_NAME_MASK ...
#define REG_NAME_FIELD_NAME_SHIFT ...
val = RD_FIELD(base, REG_NAME,
FIELD_NAME);
vs.
#define REG_NAME ...
#define FIELD_NAME ...
reg = bcm_readl(base + REG_NAME);
val = FIELD_GET(FIELD_NAME, reg);
Robin.
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2019-11-22 14:59 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-12 15:59 [PATCH v2 0/6] Raspberry Pi 4 PCIe support Nicolas Saenz Julienne
2019-11-12 15:59 ` [PATCH v2 1/6] linux/log2.h: Add roundup/rounddown_pow_two64() family of functions Nicolas Saenz Julienne
2019-11-19 11:13 ` Andrew Murray
2019-11-19 11:30 ` Nicolas Saenz Julienne
2019-11-19 12:43 ` Nicolas Saenz Julienne
2019-11-19 16:28 ` Andrew Murray
2019-11-19 16:55 ` Jason Gunthorpe
2019-11-19 17:00 ` Andrew Murray
2019-11-12 15:59 ` [PATCH v2 2/6] dt-bindings: PCI: Add bindings for brcmstb's PCIe device Nicolas Saenz Julienne
2019-11-18 21:23 ` Rob Herring
2019-11-19 9:35 ` Nicolas Saenz Julienne
2019-11-19 11:17 ` Andrew Murray
2019-11-19 11:28 ` Nicolas Saenz Julienne
2019-11-12 15:59 ` [PATCH v2 3/6] ARM: dts: bcm2711: Enable PCIe controller Nicolas Saenz Julienne
2019-11-12 15:59 ` [PATCH v2 4/6] PCI: brcmstb: add Broadcom STB PCIe host controller driver Nicolas Saenz Julienne
2019-11-19 16:25 ` Andrew Murray
2019-11-19 18:20 ` Jeremy Linton
2019-11-20 20:24 ` Nicolas Saenz Julienne
2019-11-19 18:34 ` Florian Fainelli
2019-11-21 12:16 ` Andrew Murray
2019-11-20 19:53 ` Nicolas Saenz Julienne
2019-11-21 12:03 ` Andrew Murray
2019-11-21 12:59 ` Nicolas Saenz Julienne
2019-11-21 15:44 ` Andrew Murray
2019-11-21 21:07 ` Jim Quinlan
2019-11-22 14:59 ` Robin Murphy
2019-11-21 13:26 ` Nicolas Saenz Julienne
2019-11-21 15:46 ` Andrew Murray
2019-11-12 15:59 ` [PATCH v2 5/6] PCI: brcmstb: add MSI capability Nicolas Saenz Julienne
2019-11-13 13:49 ` Marc Zyngier
2019-11-21 15:38 ` Andrew Murray
2019-11-21 17:19 ` Nicolas Saenz Julienne
2019-11-12 15:59 ` [PATCH v2 6/6] MAINTAINERS: Add brcmstb PCIe controller Nicolas Saenz Julienne
2019-11-19 11:18 ` [PATCH v2 0/6] Raspberry Pi 4 PCIe support Andrew Murray
2019-11-19 11:49 ` Nicolas Saenz Julienne
2019-11-21 12:18 ` Andrew Murray
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).