* [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips
@ 2020-05-26 19:12 Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 01/14] PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB Jim Quinlan
` (14 more replies)
0 siblings, 15 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Alan Stern, Andy Shevchenko, Corey Minyard, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE,
Greg Kroah-Hartman, Heikki Krogerus,
open list:DMA MAPPING HELPERS, Julien Grall,
moderated list:ARM PORT,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
open list,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:USB SUBSYSTEM, Mark Brown, Oliver Neukum,
Rafael J. Wysocki, Rob Herring, Robin Murphy, Saravana Kannan,
Stefano Stabellini, Suzuki K Poulose, Ulf Hansson, Wolfram Sang
v2:
Commit: "device core: Add ability to handle multiple dma offsets"
o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
o dev->dma_pfn_map => dev->dma_pfn_offset_map
o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
o In device.h: s/const void */const struct dma_pfn_offset_region */
o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since
guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph)
o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now
dev->dma_pfn_offset_map is copied as well.
o Merged two of the DMA commits into one (Christoph).
Commit "arm: dma-mapping: Invoke dma offset func if needed":
o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET
Other commits' changes:
o Removed need for carrying of_id var in priv (Nicolas)
o Commit message rewordings (Bjorn)
o Commit log messages filled to 75 chars (Bjorn)
o devm_reset_control_get_shared())
=> devm_reset_control_get_optional_shared (Philipp)
o Add call to reset_control_assert() in PCIe remove routines (Philipp)
v1:
This patchset expands the usefulness of the Broadcom Settop Box PCIe
controller by building upon the PCIe driver used currently by the
Raspbery Pi. Other forms of this patchset were submitted by me years
ago and not accepted; the major sticking point was the code required
for the DMA remapping needed for the PCIe driver to work [1].
There have been many changes to the DMA and OF subsystems since that
time, making a cleaner and less intrusive patchset possible. This
patchset implements a generalization of "dev->dma_pfn_offset", except
that instead of a single scalar offset it provides for multiple
offsets via a function which depends upon the "dma-ranges" property of
the PCIe host controller. This is required for proper functionality
of the BrcmSTB PCIe controller and possibly some other devices.
[1] https://lore.kernel.org/linux-arm-kernel/1516058925-46522-5-git-send-email-jim2101024@gmail.com/
Jim Quinlan (14):
PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB
ata: ahci_brcm: Fix use of BCM7216 reset controller
dt-bindings: PCI: Add bindings for more Brcmstb chips
PCI: brcmstb: Add bcm7278 reigister info
PCI: brcmstb: Add suspend and resume pm_ops
PCI: brcmstb: Add bcm7278 PERST support
PCI: brcmstb: Add control of rescal reset
of: Include a dev param in of_dma_get_range()
device core: Add ability to handle multiple dma offsets
arm: dma-mapping: Invoke dma offset func if needed
PCI: brcmstb: Set internal memory viewport sizes
PCI: brcmstb: Accommodate MSI for older chips
PCI: brcmstb: Set bus max burst size by chip type
PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list
.../bindings/pci/brcm,stb-pcie.yaml | 40 +-
arch/arm/include/asm/dma-mapping.h | 13 +-
drivers/ata/ahci_brcm.c | 14 +-
drivers/of/address.c | 69 ++-
drivers/of/device.c | 2 +-
drivers/of/of_private.h | 8 +-
drivers/pci/controller/Kconfig | 3 +-
drivers/pci/controller/pcie-brcmstb.c | 408 +++++++++++++++---
drivers/usb/core/message.c | 3 +
drivers/usb/core/usb.c | 3 +
include/linux/device.h | 10 +-
include/linux/dma-direct.h | 10 +-
include/linux/dma-mapping.h | 46 ++
kernel/dma/Kconfig | 13 +
14 files changed, 559 insertions(+), 83 deletions(-)
--
2.17.1
^ permalink raw reply [flat|nested] 30+ messages in thread
* [PATCH v2 01/14] PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
@ 2020-05-26 19:12 ` Jim Quinlan
2020-06-01 21:44 ` Rob Herring
2020-05-26 19:12 ` [PATCH v2 02/14] ata: ahci_brcm: Fix use of BCM7216 reset controller Jim Quinlan
` (13 subsequent siblings)
14 siblings, 1 reply; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Jim Quinlan, Lorenzo Pieralisi, Rob Herring, Bjorn Helgaas, open list
From: Jim Quinlan <jquinlan@broadcom.com>
Have PCIE_BRCMSTB depend on ARCH_BRCMSTB. Also set the default value to
ARCH_BRCMSTB.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/pci/controller/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 91bfdb784829..c0f3d4d10047 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -244,9 +244,10 @@ config VMD
config PCIE_BRCMSTB
tristate "Broadcom Brcmstb PCIe host controller"
- depends on ARCH_BCM2835 || COMPILE_TEST
+ depends on ARCH_BRCMSTB || ARCH_BCM2835 || COMPILE_TEST
depends on OF
depends on PCI_MSI_IRQ_DOMAIN
+ default ARCH_BRCMSTB
help
Say Y here to enable PCIe host controller support for
Broadcom STB based SoCs, like the Raspberry Pi 4.
--
2.17.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 02/14] ata: ahci_brcm: Fix use of BCM7216 reset controller
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 01/14] PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB Jim Quinlan
@ 2020-05-26 19:12 ` Jim Quinlan
2020-05-27 23:57 ` Florian Fainelli
2020-05-26 19:12 ` [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips Jim Quinlan
` (12 subsequent siblings)
14 siblings, 1 reply; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Jim Quinlan, Jens Axboe, Philipp Zabel,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
open list
From: Jim Quinlan <jquinlan@broadcom.com>
A reset controller "rescal" is shared between the AHCI driver and the PCIe
driver for the BrcmSTB 7216 chip. The code is modified to allow this
sharing and to deassert() properly.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
drivers/ata/ahci_brcm.c | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/ata/ahci_brcm.c b/drivers/ata/ahci_brcm.c
index 6853dbb4131d..c4ea555573dd 100644
--- a/drivers/ata/ahci_brcm.c
+++ b/drivers/ata/ahci_brcm.c
@@ -428,7 +428,6 @@ static int brcm_ahci_probe(struct platform_device *pdev)
{
const struct of_device_id *of_id;
struct device *dev = &pdev->dev;
- const char *reset_name = NULL;
struct brcm_ahci_priv *priv;
struct ahci_host_priv *hpriv;
struct resource *res;
@@ -452,11 +451,11 @@ static int brcm_ahci_probe(struct platform_device *pdev)
/* Reset is optional depending on platform and named differently */
if (priv->version == BRCM_SATA_BCM7216)
- reset_name = "rescal";
+ priv->rcdev = devm_reset_control_get_optional_shared(&pdev->dev,
+ "rescal");
else
- reset_name = "ahci";
-
- priv->rcdev = devm_reset_control_get_optional(&pdev->dev, reset_name);
+ priv->rcdev = devm_reset_control_get_optional(&pdev->dev,
+ "ahci");
if (IS_ERR(priv->rcdev))
return PTR_ERR(priv->rcdev);
@@ -479,10 +478,7 @@ static int brcm_ahci_probe(struct platform_device *pdev)
break;
}
- if (priv->version == BRCM_SATA_BCM7216)
- ret = reset_control_reset(priv->rcdev);
- else
- ret = reset_control_deassert(priv->rcdev);
+ ret = reset_control_deassert(priv->rcdev);
if (ret)
return ret;
--
2.17.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 01/14] PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 02/14] ata: ahci_brcm: Fix use of BCM7216 reset controller Jim Quinlan
@ 2020-05-26 19:12 ` Jim Quinlan
2020-05-29 17:46 ` Rob Herring
2020-05-26 19:12 ` [PATCH v2 04/14] PCI: brcmstb: Add bcm7278 reigister info Jim Quinlan
` (11 subsequent siblings)
14 siblings, 1 reply; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Jim Quinlan, Florian Fainelli, Bjorn Helgaas, Rob Herring,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
From: Jim Quinlan <jquinlan@broadcom.com>
- Add compatible strings for three more Broadcom STB chips: 7278, 7216,
7211 (STB version of RPi4).
- add new property 'brcm,scb-sizes'
- add new property 'resets'
- add new property 'reset-names'
- allow 'ranges' and 'dma-ranges' to have more than one item and update
the example to show this.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
.../bindings/pci/brcm,stb-pcie.yaml | 40 +++++++++++++++++--
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
index 8680a0f86c5a..66a7df45983d 100644
--- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
+++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
@@ -14,7 +14,13 @@ allOf:
properties:
compatible:
- const: brcm,bcm2711-pcie # The Raspberry Pi 4
+ items:
+ - enum:
+ - brcm,bcm2711-pcie # The Raspberry Pi 4
+ - brcm,bcm7211-pcie # Broadcom STB version of RPi4
+ - brcm,bcm7278-pcie # Broadcom 7278 Arm
+ - brcm,bcm7216-pcie # Broadcom 7216 Arm
+ - brcm,bcm7445-pcie # Broadcom 7445 Arm
reg:
maxItems: 1
@@ -34,10 +40,12 @@ properties:
- const: msi
ranges:
- maxItems: 1
+ minItems: 1
+ maxItems: 4
dma-ranges:
- maxItems: 1
+ minItems: 1
+ maxItems: 6
clocks:
maxItems: 1
@@ -58,8 +66,30 @@ properties:
aspm-no-l0s: true
+ resets:
+ description: for "brcm,bcm7216-pcie", must be a valid reset
+ phandle pointing to the RESCAL reset controller provider node.
+ $ref: "/schemas/types.yaml#/definitions/phandle"
+
+ reset-names:
+ items:
+ - const: rescal
+
+ brcm,scb-sizes:
+ description: (u32, u32) tuple giving the 64bit PCIe memory
+ viewport size of a memory controller. There may be up to
+ three controllers, and each size must be a power of two
+ with a size greater or equal to the amount of memory the
+ controller supports.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+ - items:
+ minItems: 2
+ maxItems: 6
+
required:
- reg
+ - ranges
- dma-ranges
- "#interrupt-cells"
- interrupts
@@ -93,7 +123,9 @@ examples:
msi-parent = <&pcie0>;
msi-controller;
ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>;
- dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>;
+ dma-ranges = <0x42000000 0x1 0x00000000 0x0 0x40000000 0x0 0x80000000>,
+ <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>;
brcm,enable-ssc;
+ brcm,scb-sizes = <0x0 0x80000000 0x0 0x80000000>;
};
};
--
2.17.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 04/14] PCI: brcmstb: Add bcm7278 reigister info
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
` (2 preceding siblings ...)
2020-05-26 19:12 ` [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips Jim Quinlan
@ 2020-05-26 19:12 ` Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 05/14] PCI: brcmstb: Add suspend and resume pm_ops Jim Quinlan
` (10 subsequent siblings)
14 siblings, 0 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Jim Quinlan, Lorenzo Pieralisi, Rob Herring, Bjorn Helgaas,
Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list
From: Jim Quinlan <jquinlan@broadcom.com>
Add in compatibility strings and code for three Broadcom STB chips. Some
of the register locations, shifts, and masks are different for certain
chips, requiring the use of different constants based on of_id.
We would like to add the following at this time to the match list but we
need to wait until the end of this patchset so that everything works.
{ .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
{ .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
{ .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 108 +++++++++++++++++++++++---
1 file changed, 96 insertions(+), 12 deletions(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 73020b4ff090..7c707e483181 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -120,9 +120,8 @@
#define PCIE_EXT_SLOT_SHIFT 15
#define PCIE_EXT_FUNC_SHIFT 12
-#define PCIE_RGR1_SW_INIT_1 0x9210
#define PCIE_RGR1_SW_INIT_1_PERST_MASK 0x1
-#define PCIE_RGR1_SW_INIT_1_INIT_MASK 0x2
+#define PCIE_RGR1_SW_INIT_1_PERST_SHIFT 0x0
/* PCIe parameters */
#define BRCM_NUM_PCIE_OUT_WINS 0x4
@@ -152,6 +151,76 @@
#define SSC_STATUS_SSC_MASK 0x400
#define SSC_STATUS_PLL_LOCK_MASK 0x800
+#define IDX_ADDR(pcie) \
+ (pcie->reg_offsets[EXT_CFG_INDEX])
+#define DATA_ADDR(pcie) \
+ (pcie->reg_offsets[EXT_CFG_DATA])
+#define 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,
+};
+
+enum pcie_type {
+ GENERIC,
+ BCM7278,
+ BCM2711,
+};
+
+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_reg_field_info_bcm7278[] = {
+ [RGR1_SW_INIT_1_INIT_MASK] = 0x1,
+ [RGR1_SW_INIT_1_INIT_SHIFT] = 0x0,
+};
+
+static const int pcie_offsets[] = {
+ [RGR1_SW_INIT_1] = 0x9210,
+ [EXT_CFG_INDEX] = 0x9000,
+ [EXT_CFG_DATA] = 0x9004,
+};
+
+static const struct pcie_cfg_data generic_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offsets,
+ .type = GENERIC,
+};
+
+static const int pcie_offset_bcm7278[] = {
+ [RGR1_SW_INIT_1] = 0xc010,
+ [EXT_CFG_INDEX] = 0x9000,
+ [EXT_CFG_DATA] = 0x9004,
+};
+
+static const struct pcie_cfg_data bcm7278_cfg = {
+ .reg_field_info = pcie_reg_field_info_bcm7278,
+ .offsets = pcie_offset_bcm7278,
+ .type = BCM7278,
+};
+
+static const struct pcie_cfg_data bcm2711_cfg = {
+ .reg_field_info = pcie_reg_field_info,
+ .offsets = pcie_offsets,
+ .type = BCM2711,
+};
+
struct brcm_msi {
struct device *dev;
void __iomem *base;
@@ -176,6 +245,9 @@ struct brcm_pcie {
int gen;
u64 msi_target_addr;
struct brcm_msi *msi;
+ const int *reg_offsets;
+ const int *reg_field_info;
+ enum pcie_type type;
};
/*
@@ -602,20 +674,21 @@ static struct pci_ops brcm_pcie_ops = {
static inline void brcm_pcie_bridge_sw_init_set(struct brcm_pcie *pcie, u32 val)
{
- u32 tmp;
+ u32 tmp, mask = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_MASK];
+ u32 shift = pcie->reg_field_info[RGR1_SW_INIT_1_INIT_SHIFT];
- tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1);
- u32p_replace_bits(&tmp, val, PCIE_RGR1_SW_INIT_1_INIT_MASK);
- writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1);
+ tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
+ tmp = (tmp & ~mask) | ((val << shift) & mask);
+ writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
}
static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie, u32 val)
{
u32 tmp;
- tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1);
+ tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
u32p_replace_bits(&tmp, val, PCIE_RGR1_SW_INIT_1_PERST_MASK);
- writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1);
+ writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
}
static inline int brcm_pcie_get_rc_bar2_size_and_offset(struct brcm_pcie *pcie,
@@ -924,10 +997,16 @@ static int brcm_pcie_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id brcm_pcie_match[] = {
+ { .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
+ {},
+};
+
static int brcm_pcie_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node, *msi_np;
struct pci_host_bridge *bridge;
+ const struct pcie_cfg_data *data;
struct brcm_pcie *pcie;
struct pci_bus *child;
struct resource *res;
@@ -937,9 +1016,18 @@ static int brcm_pcie_probe(struct platform_device *pdev)
if (!bridge)
return -ENOMEM;
+ data = of_device_get_match_data(&pdev->dev);
+ if (!data) {
+ pr_err("failed to look up compatible string\n");
+ return -EINVAL;
+ }
+
pcie = pci_host_bridge_priv(bridge);
pcie->dev = &pdev->dev;
pcie->np = np;
+ pcie->reg_offsets = data->offsets;
+ pcie->reg_field_info = data->reg_field_info;
+ pcie->type = data->type;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
pcie->base = devm_ioremap_resource(&pdev->dev, res);
@@ -1005,10 +1093,6 @@ static int brcm_pcie_probe(struct platform_device *pdev)
return ret;
}
-static const struct of_device_id brcm_pcie_match[] = {
- { .compatible = "brcm,bcm2711-pcie" },
- {},
-};
MODULE_DEVICE_TABLE(of, brcm_pcie_match);
static struct platform_driver brcm_pcie_driver = {
--
2.17.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 05/14] PCI: brcmstb: Add suspend and resume pm_ops
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
` (3 preceding siblings ...)
2020-05-26 19:12 ` [PATCH v2 04/14] PCI: brcmstb: Add bcm7278 reigister info Jim Quinlan
@ 2020-05-26 19:12 ` Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 06/14] PCI: brcmstb: Add bcm7278 PERST support Jim Quinlan
` (9 subsequent siblings)
14 siblings, 0 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Jim Quinlan, Lorenzo Pieralisi, Rob Herring, Bjorn Helgaas,
Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list
From: Jim Quinlan <jquinlan@broadcom.com>
Broadcom Set-top (BrcmSTB) boards typically support S2, S3, and S5 suspend
and resume. Now the PCIe driver may do so as well.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 49 +++++++++++++++++++++++++++
1 file changed, 49 insertions(+)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 7c707e483181..f444751e247c 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -979,6 +979,49 @@ static void brcm_pcie_turn_off(struct brcm_pcie *pcie)
brcm_pcie_bridge_sw_init_set(pcie, 1);
}
+static int brcm_pcie_suspend(struct device *dev)
+{
+ struct brcm_pcie *pcie = dev_get_drvdata(dev);
+ int ret = 0;
+
+ brcm_pcie_turn_off(pcie);
+ clk_disable_unprepare(pcie->clk);
+
+ return ret;
+}
+
+static int brcm_pcie_resume(struct device *dev)
+{
+ struct brcm_pcie *pcie = dev_get_drvdata(dev);
+ void __iomem *base;
+ u32 tmp;
+ int ret;
+
+ base = pcie->base;
+ clk_prepare_enable(pcie->clk);
+
+ /* Take bridge out of reset so we can access the SERDES reg */
+ brcm_pcie_bridge_sw_init_set(pcie, 0);
+
+ /* SERDES_IDDQ = 0 */
+ tmp = readl(base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
+ u32p_replace_bits(&tmp, 0,
+ PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK);
+ writel(tmp, base + PCIE_MISC_HARD_PCIE_HARD_DEBUG);
+
+ /* wait for serdes to be stable */
+ udelay(100);
+
+ ret = brcm_pcie_setup(pcie);
+ if (ret)
+ return ret;
+
+ if (pcie->msi)
+ brcm_msi_set_regs(pcie->msi);
+
+ return 0;
+}
+
static void __brcm_pcie_remove(struct brcm_pcie *pcie)
{
brcm_msi_remove(pcie);
@@ -1095,12 +1138,18 @@ static int brcm_pcie_probe(struct platform_device *pdev)
MODULE_DEVICE_TABLE(of, brcm_pcie_match);
+static const struct dev_pm_ops brcm_pcie_pm_ops = {
+ .suspend_noirq = brcm_pcie_suspend,
+ .resume_noirq = brcm_pcie_resume,
+};
+
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,
+ .pm = &brcm_pcie_pm_ops,
},
};
module_platform_driver(brcm_pcie_driver);
--
2.17.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 06/14] PCI: brcmstb: Add bcm7278 PERST support
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
` (4 preceding siblings ...)
2020-05-26 19:12 ` [PATCH v2 05/14] PCI: brcmstb: Add suspend and resume pm_ops Jim Quinlan
@ 2020-05-26 19:12 ` Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 07/14] PCI: brcmstb: Add control of rescal reset Jim Quinlan
` (8 subsequent siblings)
14 siblings, 0 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Jim Quinlan, Lorenzo Pieralisi, Rob Herring, Bjorn Helgaas,
Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list
From: Jim Quinlan <jquinlan@broadcom.com>
The PERST bit was moved to a different register in 7278-type STB chips. In
addition, the polarity of the bit was also changed; for other chips writing
a 1 specified assert; for 7278-type chips, writing a 0 specifies assert.
Signal-wise, PERST is an asserted-low signal.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index f444751e247c..0bcae9eba048 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -81,6 +81,7 @@
#define PCIE_MISC_PCIE_CTRL 0x4064
#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK 0x1
+#define PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_MASK 0x4
#define PCIE_MISC_PCIE_STATUS 0x4068
#define PCIE_MISC_PCIE_STATUS_PCIE_PORT_MASK 0x80
@@ -686,9 +687,17 @@ static inline void brcm_pcie_perst_set(struct brcm_pcie *pcie, u32 val)
{
u32 tmp;
- tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
- u32p_replace_bits(&tmp, val, PCIE_RGR1_SW_INIT_1_PERST_MASK);
- writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
+ if (pcie->type == BCM7278) {
+ /* Perst bit has moved and assert value is 0 */
+ tmp = readl(pcie->base + PCIE_MISC_PCIE_CTRL);
+ u32p_replace_bits(&tmp,
+ !val, PCIE_MISC_PCIE_CTRL_PCIE_PERSTB_MASK);
+ writel(tmp, pcie->base + PCIE_MISC_PCIE_CTRL);
+ } else {
+ tmp = readl(pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
+ u32p_replace_bits(&tmp, val, PCIE_RGR1_SW_INIT_1_PERST_MASK);
+ writel(tmp, pcie->base + PCIE_RGR1_SW_INIT_1(pcie));
+ }
}
static inline int brcm_pcie_get_rc_bar2_size_and_offset(struct brcm_pcie *pcie,
--
2.17.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 07/14] PCI: brcmstb: Add control of rescal reset
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
` (5 preceding siblings ...)
2020-05-26 19:12 ` [PATCH v2 06/14] PCI: brcmstb: Add bcm7278 PERST support Jim Quinlan
@ 2020-05-26 19:12 ` Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 08/14] of: Include a dev param in of_dma_get_range() Jim Quinlan
` (7 subsequent siblings)
14 siblings, 0 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Jim Quinlan, Lorenzo Pieralisi, Rob Herring, Bjorn Helgaas,
Florian Fainelli, Philipp Zabel,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list
From: Jim Quinlan <jquinlan@broadcom.com>
Some STB chips have a special purpose reset controller named RESCAL (reset
calibration). The PCIe HW can now control RESCAL to start and stop its
operation.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 81 ++++++++++++++++++++++++++-
1 file changed, 80 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 0bcae9eba048..fa356bc149c3 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -23,6 +23,7 @@
#include <linux/of_platform.h>
#include <linux/pci.h>
#include <linux/printk.h>
+#include <linux/reset.h>
#include <linux/sizes.h>
#include <linux/slab.h>
#include <linux/string.h>
@@ -152,7 +153,17 @@
#define SSC_STATUS_SSC_MASK 0x400
#define SSC_STATUS_PLL_LOCK_MASK 0x800
-#define IDX_ADDR(pcie) \
+/* Rescal registers */
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL 0xc700
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS 0x3
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_DIG_RESET_MASK 0x4
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_DIG_RESET_SHIFT 0x2
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_RESET_MASK 0x2
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_RESET_SHIFT 0x1
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_MASK 0x1
+#define PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_SHIFT 0x0
+
+#define IDX_ADDR(pcie) \
(pcie->reg_offsets[EXT_CFG_INDEX])
#define DATA_ADDR(pcie) \
(pcie->reg_offsets[EXT_CFG_DATA])
@@ -249,6 +260,7 @@ struct brcm_pcie {
const int *reg_offsets;
const int *reg_field_info;
enum pcie_type type;
+ struct reset_control *rescal;
};
/*
@@ -964,6 +976,47 @@ static void brcm_pcie_enter_l23(struct brcm_pcie *pcie)
dev_err(pcie->dev, "failed to enter low-power link state\n");
}
+static int brcm_phy_cntl(struct brcm_pcie *pcie, const int start)
+{
+ static const u32 shifts[PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS] = {
+ PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_SHIFT,
+ PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_RESET_SHIFT,
+ PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_DIG_RESET_SHIFT,};
+ static const u32 masks[PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS] = {
+ PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_PWRDN_MASK,
+ PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_RESET_MASK,
+ PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_DIG_RESET_MASK,};
+ const int beg = start ? 0 : PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS - 1;
+ const int end = start ? PCIE_DVT_PMU_PCIE_PHY_CTRL_DAST_NFLDS : -1;
+ u32 tmp, combined_mask = 0;
+ u32 val = !!start;
+ void __iomem *base = pcie->base;
+ int i;
+
+ for (i = beg; i != end; start ? i++ : i--) {
+ tmp = readl(base + PCIE_DVT_PMU_PCIE_PHY_CTRL);
+ tmp = (tmp & ~masks[i]) | ((val << shifts[i]) & masks[i]);
+ writel(tmp, base + PCIE_DVT_PMU_PCIE_PHY_CTRL);
+ usleep_range(50, 200);
+ combined_mask |= masks[i];
+ }
+
+ tmp = readl(base + PCIE_DVT_PMU_PCIE_PHY_CTRL);
+ val = start ? combined_mask : 0;
+
+ return (tmp & combined_mask) == val ? 0 : -EIO;
+}
+
+static inline int brcm_phy_start(struct brcm_pcie *pcie)
+{
+ return pcie->rescal ? brcm_phy_cntl(pcie, 1) : 0;
+}
+
+static inline int brcm_phy_stop(struct brcm_pcie *pcie)
+{
+ return pcie->rescal ? brcm_phy_cntl(pcie, 0) : 0;
+}
+
static void brcm_pcie_turn_off(struct brcm_pcie *pcie)
{
void __iomem *base = pcie->base;
@@ -994,6 +1047,9 @@ static int brcm_pcie_suspend(struct device *dev)
int ret = 0;
brcm_pcie_turn_off(pcie);
+ ret = brcm_phy_stop(pcie);
+ if (ret)
+ dev_err(pcie->dev, "failed to stop phy\n");
clk_disable_unprepare(pcie->clk);
return ret;
@@ -1009,6 +1065,12 @@ static int brcm_pcie_resume(struct device *dev)
base = pcie->base;
clk_prepare_enable(pcie->clk);
+ ret = brcm_phy_start(pcie);
+ if (ret) {
+ dev_err(pcie->dev, "failed to start phy\n");
+ return ret;
+ }
+
/* Take bridge out of reset so we can access the SERDES reg */
brcm_pcie_bridge_sw_init_set(pcie, 0);
@@ -1035,6 +1097,9 @@ static void __brcm_pcie_remove(struct brcm_pcie *pcie)
{
brcm_msi_remove(pcie);
brcm_pcie_turn_off(pcie);
+ if (brcm_phy_stop(pcie))
+ dev_err(pcie->dev, "failed to stop phy\n");
+ reset_control_assert(pcie->rescal);
clk_disable_unprepare(pcie->clk);
}
@@ -1105,6 +1170,20 @@ static int brcm_pcie_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "could not enable clock\n");
return ret;
}
+ pcie->rescal = devm_reset_control_get_optional_shared(&pdev->dev,
+ "rescal");
+ if (IS_ERR(pcie->rescal))
+ return PTR_ERR(pcie->rescal);
+
+ ret = reset_control_deassert(pcie->rescal);
+ if (ret)
+ dev_err(&pdev->dev, "failed to deassert 'rescal'\n");
+
+ ret = brcm_phy_start(pcie);
+ if (ret) {
+ dev_err(pcie->dev, "failed to start phy\n");
+ return ret;
+ }
ret = brcm_pcie_setup(pcie);
if (ret)
--
2.17.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 08/14] of: Include a dev param in of_dma_get_range()
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
` (6 preceding siblings ...)
2020-05-26 19:12 ` [PATCH v2 07/14] PCI: brcmstb: Add control of rescal reset Jim Quinlan
@ 2020-05-26 19:12 ` Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets Jim Quinlan
` (6 subsequent siblings)
14 siblings, 0 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Rob Herring, Frank Rowand,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list
Currently there is only one caller of of_dma_get_range(). A struct device
*dev param is needed For implementing multiple dma offsets. This function
will still work if dev == NULL.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
drivers/of/address.c | 4 +++-
drivers/of/device.c | 2 +-
drivers/of/of_private.h | 8 ++++----
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 8eea3f6e29a4..96d8cfb14a60 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -920,6 +920,7 @@ EXPORT_SYMBOL(of_io_request_and_map);
/**
* of_dma_get_range - Get DMA range info
+ * @dev: device pointer; only needed for a corner case.
* @np: device node to get DMA range info
* @dma_addr: pointer to store initial DMA address of DMA range
* @paddr: pointer to store initial CPU address of DMA range
@@ -935,7 +936,8 @@ EXPORT_SYMBOL(of_io_request_and_map);
* It returns -ENODEV if "dma-ranges" property was not found
* for this device in DT.
*/
-int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
+int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
+ u64 *paddr, u64 *size)
{
struct device_node *node = of_node_get(np);
const __be32 *ranges = NULL;
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 27203bfd0b22..ef6a741f9f0b 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -95,7 +95,7 @@ int of_dma_configure(struct device *dev, struct device_node *np, bool force_dma)
const struct iommu_ops *iommu;
u64 mask, end;
- ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
+ ret = of_dma_get_range(dev, np, &dma_addr, &paddr, &size);
if (ret < 0) {
/*
* For legacy reasons, we have to assume some devices need
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index edc682249c00..7a83d3a81ab6 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -158,11 +158,11 @@ extern int of_bus_n_addr_cells(struct device_node *np);
extern int of_bus_n_size_cells(struct device_node *np);
#ifdef CONFIG_OF_ADDRESS
-extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
- u64 *paddr, u64 *size);
+extern int of_dma_get_range(struct device *dev, struct device_node *np,
+ u64 *dma_addr, u64 *paddr, u64 *size);
#else
-static inline int of_dma_get_range(struct device_node *np, u64 *dma_addr,
- u64 *paddr, u64 *size)
+static inline int of_dma_get_range(struct device *dev, struct device_node *np,
+ u64 *dma_addr, u64 *paddr, u64 *size)
{
return -ENODEV;
}
--
2.17.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
` (7 preceding siblings ...)
2020-05-26 19:12 ` [PATCH v2 08/14] of: Include a dev param in of_dma_get_range() Jim Quinlan
@ 2020-05-26 19:12 ` Jim Quinlan
2020-05-26 20:54 ` Andy Shevchenko
2020-05-27 15:00 ` Nicolas Saenz Julienne
2020-05-26 19:12 ` [PATCH v2 10/14] arm: dma-mapping: Invoke dma offset func if needed Jim Quinlan
` (5 subsequent siblings)
14 siblings, 2 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Rob Herring, Frank Rowand, Greg Kroah-Hartman, Marek Szyprowski,
Robin Murphy, Alan Stern, Oliver Neukum, Rafael J. Wysocki,
Andy Shevchenko, Wolfram Sang, Corey Minyard,
Srinivas Kandagatla, Suzuki K Poulose, Saravana Kannan,
Heikki Krogerus, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:USB SUBSYSTEM, open list:DMA MAPPING HELPERS
The new field in struct device 'dma_pfn_offset_map' is used to facilitate
the use of multiple pfn offsets between cpu addrs and dma addrs. It is
similar to 'dma_pfn_offset' except that the offset chosen depends on the
cpu or dma address involved.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
drivers/of/address.c | 65 +++++++++++++++++++++++++++++++++++--
drivers/usb/core/message.c | 3 ++
drivers/usb/core/usb.c | 3 ++
include/linux/device.h | 10 +++++-
include/linux/dma-direct.h | 10 ++++--
include/linux/dma-mapping.h | 46 ++++++++++++++++++++++++++
kernel/dma/Kconfig | 13 ++++++++
7 files changed, 144 insertions(+), 6 deletions(-)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 96d8cfb14a60..a01afffcde7d 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -918,6 +918,47 @@ void __iomem *of_io_request_and_map(struct device_node *np, int index,
}
EXPORT_SYMBOL(of_io_request_and_map);
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+static int attach_dma_pfn_offset_map(struct device *dev,
+ struct device_node *node, int num_ranges)
+{
+ struct of_range_parser parser;
+ struct of_range range;
+ size_t r_size = (num_ranges + 1)
+ * sizeof(struct dma_pfn_offset_region);
+ struct dma_pfn_offset_region *r;
+
+ r = devm_kzalloc(dev, r_size, GFP_KERNEL);
+ if (!r)
+ return -ENOMEM;
+ dev->dma_pfn_offset_map = r;
+ of_dma_range_parser_init(&parser, node);
+
+ /*
+ * Record all info for DMA ranges array. We could
+ * just use the of_range struct, but if we did that it
+ * would require more calculations for phys_to_dma and
+ * dma_to_phys conversions.
+ */
+ for_each_of_range(&parser, &range) {
+ r->cpu_beg = range.cpu_addr;
+ r->cpu_end = r->cpu_beg + range.size;
+ r->dma_beg = range.bus_addr;
+ r->dma_end = r->dma_beg + range.size;
+ r->pfn_offset = PFN_DOWN(range.cpu_addr)
+ - PFN_DOWN(range.bus_addr);
+ r++;
+ }
+ return 0;
+}
+#else
+static int attach_dma_pfn_offset_map(struct device *dev,
+ struct device_node *node, int num_ranges)
+{
+ return 0;
+}
+#endif
+
/**
* of_dma_get_range - Get DMA range info
* @dev: device pointer; only needed for a corner case.
@@ -947,6 +988,8 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
struct of_range_parser parser;
struct of_range range;
u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
+ bool dma_multi_pfn_offset = false;
+ int num_ranges = 0;
while (node) {
ranges = of_get_property(node, "dma-ranges", &len);
@@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
range.bus_addr, range.cpu_addr, range.size);
+ num_ranges++;
if (dma_offset && range.cpu_addr - range.bus_addr != dma_offset) {
- pr_warn("Can't handle multiple dma-ranges with different offsets on node(%pOF)\n", node);
- /* Don't error out as we'd break some existing DTs */
- continue;
+ if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
+ pr_warn("Can't handle multiple dma-ranges with different offsets on node(%pOF)\n", node);
+ pr_warn("Perhaps set DMA_PFN_OFFSET_MAP=y?\n");
+ /*
+ * Don't error out as we'd break some existing
+ * DTs that are using configs w/o
+ * CONFIG_DMA_PFN_OFFSET_MAP set.
+ */
+ continue;
+ }
+ dma_multi_pfn_offset = true;
}
dma_offset = range.cpu_addr - range.bus_addr;
@@ -991,6 +1043,13 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
dma_end = range.bus_addr + range.size;
}
+ if (dma_multi_pfn_offset) {
+ dma_offset = 0;
+ ret = attach_dma_pfn_offset_map(dev, node, num_ranges);
+ if (ret)
+ return ret;
+ }
+
if (dma_start >= dma_end) {
ret = -EINVAL;
pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
index 6197938dcc2d..aaa3e58f5eb4 100644
--- a/drivers/usb/core/message.c
+++ b/drivers/usb/core/message.c
@@ -1960,6 +1960,9 @@ int usb_set_configuration(struct usb_device *dev, int configuration)
*/
intf->dev.dma_mask = dev->dev.dma_mask;
intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset;
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+ intf->dev.dma_pfn_offset_map = dev->dev.dma_pfn_offset_map;
+#endif
INIT_WORK(&intf->reset_ws, __usb_queue_reset_device);
intf->minor = -1;
device_initialize(&intf->dev);
diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
index f16c26dc079d..d2ed4d90e56e 100644
--- a/drivers/usb/core/usb.c
+++ b/drivers/usb/core/usb.c
@@ -612,6 +612,9 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
*/
dev->dev.dma_mask = bus->sysdev->dma_mask;
dev->dev.dma_pfn_offset = bus->sysdev->dma_pfn_offset;
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+ dev->dev.dma_pfn_offset_map = bus->sysdev->dma_pfn_offset_map;
+#endif
set_dev_node(&dev->dev, dev_to_node(bus->sysdev));
dev->state = USB_STATE_ATTACHED;
dev->lpm_disable_count = 1;
diff --git a/include/linux/device.h b/include/linux/device.h
index ac8e37cd716a..67a240ad4fc5 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -493,6 +493,8 @@ struct dev_links_info {
* @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
* DMA limit than the device itself supports.
* @dma_pfn_offset: offset of DMA memory range relatively of RAM
+ * @dma_pfn_offset_map: Like dma_pfn_offset but used when there are multiple
+ * pfn offsets for multiple dma-ranges.
* @dma_parms: A low level driver may set these to teach IOMMU code about
* segment limitations.
* @dma_pools: Dma pools (if dma'ble device).
@@ -578,7 +580,13 @@ struct device {
allocations such descriptors. */
u64 bus_dma_limit; /* upstream dma constraint */
unsigned long dma_pfn_offset;
-
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+ const struct dma_pfn_offset_region *dma_pfn_offset_map;
+ /* Like dma_pfn_offset, but for
+ * the unlikely case of multiple
+ * offsets. If non-null, dma_pfn_offset
+ * will be set to 0. */
+#endif
struct device_dma_parameters *dma_parms;
struct list_head dma_pools; /* dma pools (if dma'ble) */
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 24b8684aa21d..03110a57eabc 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -14,15 +14,21 @@ extern unsigned int zone_dma_bits;
static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
{
dma_addr_t dev_addr = (dma_addr_t)paddr;
+ /* The compiler should remove the 2nd term if !DMA_PFN_OFFSET_MAP */
+ unsigned long dma_pfn_offset = dev->dma_pfn_offset
+ + dma_pfn_offset_from_phys_addr(dev, paddr);
- return dev_addr - ((dma_addr_t)dev->dma_pfn_offset << PAGE_SHIFT);
+ return dev_addr - ((dma_addr_t)dma_pfn_offset << PAGE_SHIFT);
}
static inline phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dev_addr)
{
phys_addr_t paddr = (phys_addr_t)dev_addr;
+ /* The compiler should remove the 2nd term if !DMA_PFN_OFFSET_MAP */
+ unsigned long dma_pfn_offset = dev->dma_pfn_offset
+ + dma_pfn_offset_from_dma_addr(dev, paddr);
- return paddr + ((phys_addr_t)dev->dma_pfn_offset << PAGE_SHIFT);
+ return paddr + ((phys_addr_t)dma_pfn_offset << PAGE_SHIFT);
}
#endif /* !CONFIG_ARCH_HAS_PHYS_TO_DMA */
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 330ad58fbf4d..91940bba2229 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -256,6 +256,52 @@ static inline void dma_direct_sync_sg_for_cpu(struct device *dev,
size_t dma_direct_max_mapping_size(struct device *dev);
#ifdef CONFIG_HAS_DMA
+#ifdef CONFIG_DMA_PFN_OFFSET_MAP
+struct dma_pfn_offset_region {
+ phys_addr_t cpu_beg;
+ phys_addr_t cpu_end;
+ dma_addr_t dma_beg;
+ dma_addr_t dma_end;
+ unsigned long pfn_offset;
+};
+
+static inline unsigned long dma_pfn_offset_from_dma_addr(struct device *dev,
+ dma_addr_t dma_addr)
+{
+ const struct dma_pfn_offset_region *m = dev->dma_pfn_offset_map;
+
+ if (m)
+ for (; m->cpu_end; m++)
+ if (dma_addr >= m->dma_beg && dma_addr < m->dma_end)
+ return m->pfn_offset;
+ return 0;
+}
+
+static inline unsigned long dma_pfn_offset_from_phys_addr(struct device *dev,
+ phys_addr_t paddr)
+{
+ const struct dma_pfn_offset_region *m = dev->dma_pfn_offset_map;
+
+ if (m)
+ for (; m->cpu_end; m++)
+ if (paddr >= m->cpu_beg && paddr < m->cpu_end)
+ return m->pfn_offset;
+ return 0;
+}
+#else /* CONFIG_DMA_PFN_OFFSET_MAP */
+static inline unsigned long dma_pfn_offset_from_dma_addr(struct device *dev,
+ dma_addr_t dma_addr)
+{
+ return 0;
+}
+
+static inline unsigned long dma_pfn_offset_from_phys_addr(struct device *dev,
+ phys_addr_t paddr)
+{
+ return 0;
+}
+#endif /* CONFIG_DMA_PFN_OFFSET_MAP */
+
#include <asm/dma-mapping.h>
static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
index 4c103a24e380..ceb7e5e8f501 100644
--- a/kernel/dma/Kconfig
+++ b/kernel/dma/Kconfig
@@ -195,3 +195,16 @@ config DMA_API_DEBUG_SG
is technically out-of-spec.
If unsure, say N.
+
+config DMA_PFN_OFFSET_MAP
+ bool "Uses a DMA range map to calculate PFN offset"
+ depends on PCIE_BRCMSTB
+ default n
+ help
+ Some devices have a dma-range that gets converted to
+ a dev->dma_pfn_offset value. This option is for the
+ atypical case of there being multiple dma-ranges requiring
+ multiple pfn offsets, which are selected from when
+ converting to phys to dma and vice versa.
+
+ If unsure, say N.
--
2.17.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 10/14] arm: dma-mapping: Invoke dma offset func if needed
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
` (8 preceding siblings ...)
2020-05-26 19:12 ` [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets Jim Quinlan
@ 2020-05-26 19:12 ` Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 11/14] PCI: brcmstb: Set internal memory viewport sizes Jim Quinlan
` (4 subsequent siblings)
14 siblings, 0 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Russell King, Julien Grall, Stefano Stabellini, Ulf Hansson,
moderated list:ARM PORT, open list
Just like dma_pfn_offset, another offset is added to the dma/phys
translation if there happen to be multiple regions that have different
mapping offsets.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
arch/arm/include/asm/dma-mapping.h | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/dma-mapping.h b/arch/arm/include/asm/dma-mapping.h
index bdd80ddbca34..811389b4fb29 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -35,8 +35,12 @@ static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
#ifndef __arch_pfn_to_dma
static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
{
- if (dev)
+ if (dev) {
+ /* This should compile out if !CONFIG_DMA_PFN_OFFSET_MAP */
+ pfn -= dma_pfn_offset_from_phys_addr(dev, PFN_PHYS(pfn));
+
pfn -= dev->dma_pfn_offset;
+ }
return (dma_addr_t)__pfn_to_bus(pfn);
}
@@ -44,9 +48,12 @@ static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
{
unsigned long pfn = __bus_to_pfn(addr);
- if (dev)
- pfn += dev->dma_pfn_offset;
+ if (dev) {
+ /* This should compile out if !CONFIG_DMA_PFN_OFFSET_MAP */
+ pfn += dma_pfn_offset_from_dma_addr(dev, addr);
+ pfn += dev->dma_pfn_offset;
+ }
return pfn;
}
--
2.17.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 11/14] PCI: brcmstb: Set internal memory viewport sizes
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
` (9 preceding siblings ...)
2020-05-26 19:12 ` [PATCH v2 10/14] arm: dma-mapping: Invoke dma offset func if needed Jim Quinlan
@ 2020-05-26 19:12 ` Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 12/14] PCI: brcmstb: Accommodate MSI for older chips Jim Quinlan
` (3 subsequent siblings)
14 siblings, 0 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Lorenzo Pieralisi, Rob Herring, Bjorn Helgaas, Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list
BrcmSTB PCIe controllers are intimately connected to the memory
controller(s) on the SOC. There is a "viewport" for each memory controller
that allows inbound accesses to CPU memory. Each viewport's size must be
set to a power of two, and that size must be equal to or larger than the
amount of memory each controller supports.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 67 ++++++++++++++++++++-------
1 file changed, 49 insertions(+), 18 deletions(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index fa356bc149c3..338e9ed44230 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -55,6 +55,8 @@
#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_128 0x0
#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
+#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK 0x07c00000
+#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK 0x0000001f
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_LO 0x400c
#define PCIE_MEM_WIN0_LO(win) \
@@ -152,6 +154,7 @@
#define SSC_STATUS_OFFSET 0x1
#define SSC_STATUS_SSC_MASK 0x400
#define SSC_STATUS_PLL_LOCK_MASK 0x800
+#define PCIE_BRCM_MAX_MEMC 3
/* Rescal registers */
#define PCIE_DVT_PMU_PCIE_PHY_CTRL 0xc700
@@ -261,6 +264,8 @@ struct brcm_pcie {
const int *reg_field_info;
enum pcie_type type;
struct reset_control *rescal;
+ int num_memc;
+ u64 memc_size[PCIE_BRCM_MAX_MEMC];
};
/*
@@ -717,22 +722,40 @@ static inline int brcm_pcie_get_rc_bar2_size_and_offset(struct brcm_pcie *pcie,
u64 *rc_bar2_offset)
{
struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
- struct device *dev = pcie->dev;
struct resource_entry *entry;
+ struct device *dev = pcie->dev;
+ u64 lowest_pcie_addr = ~(u64)0;
+ int ret, i = 0;
+ u64 size = 0;
- entry = resource_list_first_type(&bridge->dma_ranges, IORESOURCE_MEM);
- if (!entry)
- return -ENODEV;
+ resource_list_for_each_entry(entry, &bridge->dma_ranges) {
+ u64 pcie_beg = entry->res->start - entry->offset;
+ size += entry->res->end - entry->res->start + 1;
+ if (pcie_beg < lowest_pcie_addr)
+ lowest_pcie_addr = pcie_beg;
+ }
- /*
- * The controller expects the inbound window offset to be calculated as
- * the difference between PCIe's address space and CPU's. The offset
- * provided by the firmware is calculated the opposite way, so we
- * negate it.
- */
- *rc_bar2_offset = -entry->offset;
- *rc_bar2_size = 1ULL << fls64(entry->res->end - entry->res->start);
+ ret = of_property_read_variable_u64_array(
+ pcie->np, "brcm,scb-sizes", pcie->memc_size, 1,
+ PCIE_BRCM_MAX_MEMC);
+
+ if (ret <= 0) {
+ /* Make an educated guess */
+ pcie->num_memc = 1;
+ pcie->memc_size[0] = 1 << fls64(size - 1);
+ } else {
+ pcie->num_memc = ret;
+ }
+
+ /* Each memc is viewed through a "port" that is a power of 2 */
+ for (i = 0, size = 0; i < pcie->num_memc; i++)
+ size += pcie->memc_size[i];
+
+ /* System memory starts at this address in PCIe-space */
+ *rc_bar2_offset = lowest_pcie_addr;
+ /* The sum of all memc views must also be a power of 2 */
+ *rc_bar2_size = 1ULL << fls64(size - 1);
/*
* We validate the inbound memory view even though we should trust
@@ -784,12 +807,11 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
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;
+ int i, ret, memc;
u32 tmp, aspm_support;
/* Reset the bridge */
@@ -825,11 +847,20 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
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 */
tmp = readl(base + PCIE_MISC_MISC_CTRL);
- u32p_replace_bits(&tmp, scb_size_val,
- PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK);
+ for (memc = 0; memc < pcie->num_memc; memc++) {
+ u32 scb_size_val = ilog2(pcie->memc_size[memc]) - 15;
+
+ if (memc == 0)
+ u32p_replace_bits(&tmp, scb_size_val,
+ PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK);
+ else if (memc == 1)
+ u32p_replace_bits(&tmp, scb_size_val,
+ PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK);
+ else if (memc == 2)
+ u32p_replace_bits(&tmp, scb_size_val,
+ PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK);
+ }
writel(tmp, base + PCIE_MISC_MISC_CTRL);
/*
--
2.17.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 12/14] PCI: brcmstb: Accommodate MSI for older chips
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
` (10 preceding siblings ...)
2020-05-26 19:12 ` [PATCH v2 11/14] PCI: brcmstb: Set internal memory viewport sizes Jim Quinlan
@ 2020-05-26 19:12 ` Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 13/14] PCI: brcmstb: Set bus max burst size by chip type Jim Quinlan
` (2 subsequent siblings)
14 siblings, 0 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Jim Quinlan, Lorenzo Pieralisi, Rob Herring, Bjorn Helgaas,
Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list
From: Jim Quinlan <jquinlan@broadcom.com>
Older BrcmSTB chips do not have a separate register for MSI interrupts; the
MSIs are in a register that also contains unrelated interrupts. In
addition, the interrupts lie in bits [31..24] for these legacy chips. This
commit provides common code for both legacy and non-legacy MSI interrupt
registers.
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 72 +++++++++++++++++++--------
1 file changed, 52 insertions(+), 20 deletions(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 338e9ed44230..9930419e3ac2 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -80,7 +80,8 @@
#define PCIE_MISC_MSI_BAR_CONFIG_HI 0x4048
#define PCIE_MISC_MSI_DATA_CONFIG 0x404c
-#define PCIE_MISC_MSI_DATA_CONFIG_VAL 0xffe06540
+#define PCIE_MISC_MSI_DATA_CONFIG_VAL_32 0xffe06540
+#define PCIE_MISC_MSI_DATA_CONFIG_VAL_8 0xfff86540
#define PCIE_MISC_PCIE_CTRL 0x4064
#define PCIE_MISC_PCIE_CTRL_PCIE_L23_REQUEST_MASK 0x1
@@ -92,6 +93,9 @@
#define PCIE_MISC_PCIE_STATUS_PCIE_PHYLINKUP_MASK 0x10
#define PCIE_MISC_PCIE_STATUS_PCIE_LINK_IN_L23_MASK 0x40
+#define PCIE_MISC_REVISION 0x406c
+#define BRCM_PCIE_HW_REV_33 0x0303
+
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT 0x4070
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_LIMIT_MASK 0xfff00000
#define PCIE_MISC_CPU_2_PCIE_MEM_WIN0_BASE_LIMIT_BASE_MASK 0xfff0
@@ -112,10 +116,14 @@
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_CLKREQ_DEBUG_ENABLE_MASK 0x2
#define PCIE_MISC_HARD_PCIE_HARD_DEBUG_SERDES_IDDQ_MASK 0x08000000
-#define PCIE_MSI_INTR2_STATUS 0x4500
-#define PCIE_MSI_INTR2_CLR 0x4508
-#define PCIE_MSI_INTR2_MASK_SET 0x4510
-#define PCIE_MSI_INTR2_MASK_CLR 0x4514
+
+#define PCIE_INTR2_CPU_BASE 0x4300
+#define PCIE_MSI_INTR2_BASE 0x4500
+/* Offsets from PCIE_INTR2_CPU_BASE and PCIE_MSI_INTR2_BASE */
+#define MSI_INT_STATUS 0x0
+#define MSI_INT_CLR 0x8
+#define MSI_INT_MASK_SET 0x10
+#define MSI_INT_MASK_CLR 0x14
#define PCIE_EXT_CFG_DATA 0x8000
@@ -130,6 +138,8 @@
/* PCIe parameters */
#define BRCM_NUM_PCIE_OUT_WINS 0x4
#define BRCM_INT_PCI_MSI_NR 32
+#define BRCM_INT_PCI_MSI_LEGACY_NR 8
+#define BRCM_INT_PCI_MSI_SHIFT 0
/* MSI target adresses */
#define BRCM_MSI_TARGET_ADDR_LT_4GB 0x0fffffffcULL
@@ -247,6 +257,12 @@ struct brcm_msi {
int irq;
/* used indicates which MSI interrupts have been alloc'd */
unsigned long used;
+ bool legacy;
+ /* Some chips have MSIs in bits [31..24] of a shared register. */
+ int legacy_shift;
+ int nr; /* No. of MSI available, depends on chip */
+ /* This is the base pointer for interrupt status/set/clr regs */
+ void __iomem *intr_base;
};
/* Internal PCIe Host Controller Information.*/
@@ -266,6 +282,7 @@ struct brcm_pcie {
struct reset_control *rescal;
int num_memc;
u64 memc_size[PCIE_BRCM_MAX_MEMC];
+ u32 hw_rev;
};
/*
@@ -456,8 +473,10 @@ static void brcm_pcie_msi_isr(struct irq_desc *desc)
msi = irq_desc_get_handler_data(desc);
dev = msi->dev;
- status = readl(msi->base + PCIE_MSI_INTR2_STATUS);
- for_each_set_bit(bit, &status, BRCM_INT_PCI_MSI_NR) {
+ status = readl(msi->intr_base + MSI_INT_STATUS);
+ status >>= msi->legacy_shift;
+
+ for_each_set_bit(bit, &status, msi->nr) {
virq = irq_find_mapping(msi->inner_domain, bit);
if (virq)
generic_handle_irq(virq);
@@ -474,7 +493,7 @@ static void brcm_msi_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
msg->address_lo = lower_32_bits(msi->target_addr);
msg->address_hi = upper_32_bits(msi->target_addr);
- msg->data = (0xffff & PCIE_MISC_MSI_DATA_CONFIG_VAL) | data->hwirq;
+ msg->data = (0xffff & PCIE_MISC_MSI_DATA_CONFIG_VAL_32) | data->hwirq;
}
static int brcm_msi_set_affinity(struct irq_data *irq_data,
@@ -486,8 +505,9 @@ static int brcm_msi_set_affinity(struct irq_data *irq_data,
static void brcm_msi_ack_irq(struct irq_data *data)
{
struct brcm_msi *msi = irq_data_get_irq_chip_data(data);
+ const int shift_amt = data->hwirq + msi->legacy_shift;
- writel(1 << data->hwirq, msi->base + PCIE_MSI_INTR2_CLR);
+ writel(1 << shift_amt, msi->intr_base + MSI_INT_CLR);
}
@@ -503,7 +523,7 @@ 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);
+ hwirq = bitmap_find_free_region(&msi->used, msi->nr, 0);
mutex_unlock(&msi->lock);
return hwirq;
@@ -552,7 +572,7 @@ 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->inner_domain = irq_domain_add_linear(NULL, msi->nr,
&msi_domain_ops, msi);
if (!msi->inner_domain) {
dev_err(dev, "failed to create IRQ domain\n");
@@ -590,7 +610,10 @@ static void brcm_msi_remove(struct brcm_pcie *pcie)
static void brcm_msi_set_regs(struct brcm_msi *msi)
{
- writel(0xffffffff, msi->base + PCIE_MSI_INTR2_MASK_CLR);
+ u32 val = __GENMASK(31, msi->legacy_shift);
+
+ writel(val, msi->intr_base + MSI_INT_MASK_CLR);
+ writel(val, msi->intr_base + MSI_INT_CLR);
/*
* The 0 bit of PCIE_MISC_MSI_BAR_CONFIG_LO is repurposed to MSI
@@ -601,8 +624,10 @@ static void brcm_msi_set_regs(struct brcm_msi *msi)
writel(upper_32_bits(msi->target_addr),
msi->base + PCIE_MISC_MSI_BAR_CONFIG_HI);
- writel(PCIE_MISC_MSI_DATA_CONFIG_VAL,
- msi->base + PCIE_MISC_MSI_DATA_CONFIG);
+ val = msi->legacy ? PCIE_MISC_MSI_DATA_CONFIG_VAL_8 :
+ PCIE_MISC_MSI_DATA_CONFIG_VAL_32;
+
+ writel(val, msi->base + PCIE_MISC_MSI_DATA_CONFIG);
}
static int brcm_pcie_enable_msi(struct brcm_pcie *pcie)
@@ -627,6 +652,17 @@ static int brcm_pcie_enable_msi(struct brcm_pcie *pcie)
msi->np = pcie->np;
msi->target_addr = pcie->msi_target_addr;
msi->irq = irq;
+ msi->legacy = pcie->hw_rev < BRCM_PCIE_HW_REV_33;
+
+ if (msi->legacy) {
+ msi->intr_base = msi->base + PCIE_INTR2_CPU_BASE;
+ msi->nr = BRCM_INT_PCI_MSI_LEGACY_NR;
+ msi->legacy_shift = 24;
+ } else {
+ msi->intr_base = msi->base + PCIE_MSI_INTR2_BASE;
+ msi->nr = BRCM_INT_PCI_MSI_NR;
+ msi->legacy_shift = 0;
+ }
ret = brcm_allocate_domains(msi);
if (ret)
@@ -885,12 +921,6 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
tmp &= ~PCIE_MISC_RC_BAR3_CONFIG_LO_SIZE_MASK;
writel(tmp, base + PCIE_MISC_RC_BAR3_CONFIG_LO);
- /* Mask all interrupts since we are not handling any yet */
- writel(0xffffffff, pcie->base + PCIE_MSI_INTR2_MASK_SET);
-
- /* clear any interrupts we find on boot */
- writel(0xffffffff, pcie->base + PCIE_MSI_INTR2_CLR);
-
if (pcie->gen)
brcm_pcie_set_gen(pcie, pcie->gen);
@@ -1220,6 +1250,8 @@ static int brcm_pcie_probe(struct platform_device *pdev)
if (ret)
goto fail;
+ pcie->hw_rev = readl(pcie->base + PCIE_MISC_REVISION);
+
msi_np = of_parse_phandle(pcie->np, "msi-parent", 0);
if (pci_msi_enabled() && msi_np == pcie->np) {
ret = brcm_pcie_enable_msi(pcie);
--
2.17.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 13/14] PCI: brcmstb: Set bus max burst size by chip type
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
` (11 preceding siblings ...)
2020-05-26 19:12 ` [PATCH v2 12/14] PCI: brcmstb: Accommodate MSI for older chips Jim Quinlan
@ 2020-05-26 19:12 ` Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 14/14] PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list Jim Quinlan
2020-05-29 17:48 ` [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Rob Herring
14 siblings, 0 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Jim Quinlan, Lorenzo Pieralisi, Rob Herring, Bjorn Helgaas,
Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list
From: Jim Quinlan <jquinlan@broadcom.com>
The proper value of the parameter SCB_MAX_BURST_SIZE varies per chip. The
2711 family requires 128B whereas other devices can employ 512. The
assignment is complicated by the fact that the values for this two-bit
field have different meanings;
Value Type_Generic Type_7278
00 Reserved 128B
01 128B 256B
10 256B 512B
11 512B Reserved
Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 18 +++++++++++++++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 9930419e3ac2..131cf0a51398 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -53,7 +53,7 @@
#define PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK 0x1000
#define PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK 0x2000
#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK 0x300000
-#define PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_128 0x0
+
#define PCIE_MISC_MISC_CTRL_SCB0_SIZE_MASK 0xf8000000
#define PCIE_MISC_MISC_CTRL_SCB1_SIZE_MASK 0x07c00000
#define PCIE_MISC_MISC_CTRL_SCB2_SIZE_MASK 0x0000001f
@@ -848,7 +848,7 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
int num_out_wins = 0;
u16 nlw, cls, lnksta;
int i, ret, memc;
- u32 tmp, aspm_support;
+ u32 tmp, burst, aspm_support;
/* Reset the bridge */
brcm_pcie_bridge_sw_init_set(pcie, 1);
@@ -864,10 +864,22 @@ static int brcm_pcie_setup(struct brcm_pcie *pcie)
/* Wait for SerDes to be stable */
usleep_range(100, 200);
+ /*
+ * SCB_MAX_BURST_SIZE is a two bit field. For GENERIC chips it
+ * is encoded as 0=128, 1=256, 2=512, 3=Rsvd, for BCM7278 it
+ * is encoded as 0=Rsvd, 1=128, 2=256, 3=512.
+ */
+ if (pcie->type == BCM2711)
+ burst = 0x0; /* 128B */
+ else if (pcie->type == BCM7278)
+ burst = 0x3; /* 512 bytes */
+ else
+ burst = 0x2; /* 512 bytes */
+
/* Set SCB_MAX_BURST_SIZE, CFG_READ_UR_MODE, SCB_ACCESS_EN */
u32p_replace_bits(&tmp, 1, PCIE_MISC_MISC_CTRL_SCB_ACCESS_EN_MASK);
u32p_replace_bits(&tmp, 1, PCIE_MISC_MISC_CTRL_CFG_READ_UR_MODE_MASK);
- u32p_replace_bits(&tmp, PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_128,
+ u32p_replace_bits(&tmp, burst,
PCIE_MISC_MISC_CTRL_MAX_BURST_SIZE_MASK);
writel(tmp, base + PCIE_MISC_MISC_CTRL);
--
2.17.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* [PATCH v2 14/14] PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
` (12 preceding siblings ...)
2020-05-26 19:12 ` [PATCH v2 13/14] PCI: brcmstb: Set bus max burst size by chip type Jim Quinlan
@ 2020-05-26 19:12 ` Jim Quinlan
2020-05-29 17:48 ` [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Rob Herring
14 siblings, 0 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 19:12 UTC (permalink / raw)
To: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, james.quinlan
Cc: Lorenzo Pieralisi, Rob Herring, Bjorn Helgaas, Florian Fainelli,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list
Now that the support is in place with previous commits, we add several
chips that use the BrcmSTB driver.
Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
---
drivers/pci/controller/pcie-brcmstb.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/pci/controller/pcie-brcmstb.c b/drivers/pci/controller/pcie-brcmstb.c
index 131cf0a51398..22dbecb5403c 100644
--- a/drivers/pci/controller/pcie-brcmstb.c
+++ b/drivers/pci/controller/pcie-brcmstb.c
@@ -1189,6 +1189,10 @@ static int brcm_pcie_remove(struct platform_device *pdev)
static const struct of_device_id brcm_pcie_match[] = {
{ .compatible = "brcm,bcm2711-pcie", .data = &bcm2711_cfg },
+ { .compatible = "brcm,bcm7211-pcie", .data = &generic_cfg },
+ { .compatible = "brcm,bcm7278-pcie", .data = &bcm7278_cfg },
+ { .compatible = "brcm,bcm7216-pcie", .data = &bcm7278_cfg },
+ { .compatible = "brcm,bcm7445-pcie", .data = &generic_cfg },
{},
};
--
2.17.1
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
2020-05-26 19:12 ` [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets Jim Quinlan
@ 2020-05-26 20:54 ` Andy Shevchenko
2020-05-26 22:01 ` Jim Quinlan
2020-05-27 15:00 ` Nicolas Saenz Julienne
1 sibling, 1 reply; 30+ messages in thread
From: Andy Shevchenko @ 2020-05-26 20:54 UTC (permalink / raw)
To: Jim Quinlan
Cc: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, Rob Herring, Frank Rowand,
Greg Kroah-Hartman, Marek Szyprowski, Robin Murphy, Alan Stern,
Oliver Neukum, Rafael J. Wysocki, Wolfram Sang, Corey Minyard,
Srinivas Kandagatla, Suzuki K Poulose, Saravana Kannan,
Heikki Krogerus, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:USB SUBSYSTEM, open list:DMA MAPPING HELPERS
On Tue, May 26, 2020 at 03:12:48PM -0400, Jim Quinlan wrote:
> The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> similar to 'dma_pfn_offset' except that the offset chosen depends on the
> cpu or dma address involved.
>
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> ---
> drivers/of/address.c | 65 +++++++++++++++++++++++++++++++++++--
> drivers/usb/core/message.c | 3 ++
> drivers/usb/core/usb.c | 3 ++
> include/linux/device.h | 10 +++++-
> include/linux/dma-direct.h | 10 ++++--
> include/linux/dma-mapping.h | 46 ++++++++++++++++++++++++++
> kernel/dma/Kconfig | 13 ++++++++
> 7 files changed, 144 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 96d8cfb14a60..a01afffcde7d 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -918,6 +918,47 @@ void __iomem *of_io_request_and_map(struct device_node *np, int index,
> }
> EXPORT_SYMBOL(of_io_request_and_map);
>
> +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> +static int attach_dma_pfn_offset_map(struct device *dev,
> + struct device_node *node, int num_ranges)
> +{
> + struct of_range_parser parser;
> + struct of_range range;
> + size_t r_size = (num_ranges + 1)
> + * sizeof(struct dma_pfn_offset_region);
> + struct dma_pfn_offset_region *r;
> +
> + r = devm_kzalloc(dev, r_size, GFP_KERNEL);
devm_?!
Looking at r_size it should be rather kcalloc().
> + if (!r)
> + return -ENOMEM;
> + dev->dma_pfn_offset_map = r;
> + of_dma_range_parser_init(&parser, node);
> +
> + /*
> + * Record all info for DMA ranges array. We could
> + * just use the of_range struct, but if we did that it
> + * would require more calculations for phys_to_dma and
> + * dma_to_phys conversions.
> + */
> + for_each_of_range(&parser, &range) {
> + r->cpu_beg = range.cpu_addr;
> + r->cpu_end = r->cpu_beg + range.size;
> + r->dma_beg = range.bus_addr;
> + r->dma_end = r->dma_beg + range.size;
> + r->pfn_offset = PFN_DOWN(range.cpu_addr)
> + - PFN_DOWN(range.bus_addr);
> + r++;
> + }
> + return 0;
> +}
> +#else
> +static int attach_dma_pfn_offset_map(struct device *dev,
> + struct device_node *node, int num_ranges)
> +{
> + return 0;
> +}
> +#endif
> +
> /**
> * of_dma_get_range - Get DMA range info
> * @dev: device pointer; only needed for a corner case.
> @@ -947,6 +988,8 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
> struct of_range_parser parser;
> struct of_range range;
> u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
> + bool dma_multi_pfn_offset = false;
> + int num_ranges = 0;
>
> while (node) {
> ranges = of_get_property(node, "dma-ranges", &len);
> @@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
> pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> range.bus_addr, range.cpu_addr, range.size);
>
> + num_ranges++;
> if (dma_offset && range.cpu_addr - range.bus_addr != dma_offset) {
> - pr_warn("Can't handle multiple dma-ranges with different offsets on node(%pOF)\n", node);
> - /* Don't error out as we'd break some existing DTs */
> - continue;
> + if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
> + pr_warn("Can't handle multiple dma-ranges with different offsets on node(%pOF)\n", node);
> + pr_warn("Perhaps set DMA_PFN_OFFSET_MAP=y?\n");
> + /*
> + * Don't error out as we'd break some existing
> + * DTs that are using configs w/o
> + * CONFIG_DMA_PFN_OFFSET_MAP set.
> + */
> + continue;
> + }
> + dma_multi_pfn_offset = true;
> }
> dma_offset = range.cpu_addr - range.bus_addr;
>
> @@ -991,6 +1043,13 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
> dma_end = range.bus_addr + range.size;
> }
>
> + if (dma_multi_pfn_offset) {
> + dma_offset = 0;
> + ret = attach_dma_pfn_offset_map(dev, node, num_ranges);
> + if (ret)
> + return ret;
> + }
> +
> if (dma_start >= dma_end) {
> ret = -EINVAL;
> pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
> diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> index 6197938dcc2d..aaa3e58f5eb4 100644
> --- a/drivers/usb/core/message.c
> +++ b/drivers/usb/core/message.c
> @@ -1960,6 +1960,9 @@ int usb_set_configuration(struct usb_device *dev, int configuration)
> */
> intf->dev.dma_mask = dev->dev.dma_mask;
> intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset;
> +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> + intf->dev.dma_pfn_offset_map = dev->dev.dma_pfn_offset_map;
> +#endif
> INIT_WORK(&intf->reset_ws, __usb_queue_reset_device);
> intf->minor = -1;
> device_initialize(&intf->dev);
> diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> index f16c26dc079d..d2ed4d90e56e 100644
> --- a/drivers/usb/core/usb.c
> +++ b/drivers/usb/core/usb.c
> @@ -612,6 +612,9 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
> */
> dev->dev.dma_mask = bus->sysdev->dma_mask;
> dev->dev.dma_pfn_offset = bus->sysdev->dma_pfn_offset;
> +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> + dev->dev.dma_pfn_offset_map = bus->sysdev->dma_pfn_offset_map;
> +#endif
> set_dev_node(&dev->dev, dev_to_node(bus->sysdev));
> dev->state = USB_STATE_ATTACHED;
> dev->lpm_disable_count = 1;
> diff --git a/include/linux/device.h b/include/linux/device.h
> index ac8e37cd716a..67a240ad4fc5 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -493,6 +493,8 @@ struct dev_links_info {
> * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
> * DMA limit than the device itself supports.
> * @dma_pfn_offset: offset of DMA memory range relatively of RAM
> + * @dma_pfn_offset_map: Like dma_pfn_offset but used when there are multiple
> + * pfn offsets for multiple dma-ranges.
> * @dma_parms: A low level driver may set these to teach IOMMU code about
> * segment limitations.
> * @dma_pools: Dma pools (if dma'ble device).
> @@ -578,7 +580,13 @@ struct device {
> allocations such descriptors. */
> u64 bus_dma_limit; /* upstream dma constraint */
> unsigned long dma_pfn_offset;
> -
> +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> + const struct dma_pfn_offset_region *dma_pfn_offset_map;
> + /* Like dma_pfn_offset, but for
> + * the unlikely case of multiple
> + * offsets. If non-null, dma_pfn_offset
> + * will be set to 0. */
A bit harder to read comment indented too much and located after the declared variable.
> +#endif
> struct device_dma_parameters *dma_parms;
>
> struct list_head dma_pools; /* dma pools (if dma'ble) */
> diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
> index 24b8684aa21d..03110a57eabc 100644
> --- a/include/linux/dma-direct.h
> +++ b/include/linux/dma-direct.h
> @@ -14,15 +14,21 @@ extern unsigned int zone_dma_bits;
> static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
> {
> dma_addr_t dev_addr = (dma_addr_t)paddr;
> + /* The compiler should remove the 2nd term if !DMA_PFN_OFFSET_MAP */
> + unsigned long dma_pfn_offset = dev->dma_pfn_offset
> + + dma_pfn_offset_from_phys_addr(dev, paddr);
>
> - return dev_addr - ((dma_addr_t)dev->dma_pfn_offset << PAGE_SHIFT);
> + return dev_addr - ((dma_addr_t)dma_pfn_offset << PAGE_SHIFT);
> }
>
> static inline phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dev_addr)
> {
> phys_addr_t paddr = (phys_addr_t)dev_addr;
> + /* The compiler should remove the 2nd term if !DMA_PFN_OFFSET_MAP */
> + unsigned long dma_pfn_offset = dev->dma_pfn_offset
> + + dma_pfn_offset_from_dma_addr(dev, paddr);
>
> - return paddr + ((phys_addr_t)dev->dma_pfn_offset << PAGE_SHIFT);
> + return paddr + ((phys_addr_t)dma_pfn_offset << PAGE_SHIFT);
> }
> #endif /* !CONFIG_ARCH_HAS_PHYS_TO_DMA */
>
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 330ad58fbf4d..91940bba2229 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -256,6 +256,52 @@ static inline void dma_direct_sync_sg_for_cpu(struct device *dev,
> size_t dma_direct_max_mapping_size(struct device *dev);
>
> #ifdef CONFIG_HAS_DMA
> +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> +struct dma_pfn_offset_region {
> + phys_addr_t cpu_beg;
> + phys_addr_t cpu_end;
> + dma_addr_t dma_beg;
> + dma_addr_t dma_end;
Perhaps
s,beg,start,
in above names
> + unsigned long pfn_offset;
> +};
> +
> +static inline unsigned long dma_pfn_offset_from_dma_addr(struct device *dev,
> + dma_addr_t dma_addr)
> +{
> + const struct dma_pfn_offset_region *m = dev->dma_pfn_offset_map;
> + if (m)
> + for (; m->cpu_end; m++)
Why not simple
while (m) {
...
}
?
> + if (dma_addr >= m->dma_beg && dma_addr < m->dma_end)
> + return m->pfn_offset;
> + return 0;
> +}
> +
> +static inline unsigned long dma_pfn_offset_from_phys_addr(struct device *dev,
> + phys_addr_t paddr)
> +{
> + const struct dma_pfn_offset_region *m = dev->dma_pfn_offset_map;
> +
> + if (m)
> + for (; m->cpu_end; m++)
Ditto.
> + if (paddr >= m->cpu_beg && paddr < m->cpu_end)
> + return m->pfn_offset;
> + return 0;
> +}
> +#else /* CONFIG_DMA_PFN_OFFSET_MAP */
> +static inline unsigned long dma_pfn_offset_from_dma_addr(struct device *dev,
> + dma_addr_t dma_addr)
> +{
> + return 0;
> +}
> +
> +static inline unsigned long dma_pfn_offset_from_phys_addr(struct device *dev,
> + phys_addr_t paddr)
> +{
> + return 0;
> +}
> +#endif /* CONFIG_DMA_PFN_OFFSET_MAP */
> +
> #include <asm/dma-mapping.h>
>
> static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
> diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> index 4c103a24e380..ceb7e5e8f501 100644
> --- a/kernel/dma/Kconfig
> +++ b/kernel/dma/Kconfig
> @@ -195,3 +195,16 @@ config DMA_API_DEBUG_SG
> is technically out-of-spec.
>
> If unsure, say N.
> +
> +config DMA_PFN_OFFSET_MAP
> + bool "Uses a DMA range map to calculate PFN offset"
> + depends on PCIE_BRCMSTB
> + default n
Redundant.
> + help
> + Some devices have a dma-range that gets converted to
> + a dev->dma_pfn_offset value. This option is for the
> + atypical case of there being multiple dma-ranges requiring
> + multiple pfn offsets, which are selected from when
> + converting to phys to dma and vice versa.
> +
> + If unsure, say N.
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
2020-05-26 20:54 ` Andy Shevchenko
@ 2020-05-26 22:01 ` Jim Quinlan
0 siblings, 0 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-26 22:01 UTC (permalink / raw)
To: Andy Shevchenko
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, Nicolas Saenz Julienne,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Rob Herring,
Frank Rowand, Greg Kroah-Hartman, Marek Szyprowski, Robin Murphy,
Alan Stern, Oliver Neukum, Rafael J. Wysocki, Wolfram Sang,
Corey Minyard, Srinivas Kandagatla, Suzuki K Poulose,
Saravana Kannan, Heikki Krogerus, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:USB SUBSYSTEM, open list:DMA MAPPING HELPERS
Hello Andy,
On Tue, May 26, 2020 at 4:54 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
>
> On Tue, May 26, 2020 at 03:12:48PM -0400, Jim Quinlan wrote:
> > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> > similar to 'dma_pfn_offset' except that the offset chosen depends on the
> > cpu or dma address involved.
> >
> > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > ---
> > drivers/of/address.c | 65 +++++++++++++++++++++++++++++++++++--
> > drivers/usb/core/message.c | 3 ++
> > drivers/usb/core/usb.c | 3 ++
> > include/linux/device.h | 10 +++++-
> > include/linux/dma-direct.h | 10 ++++--
> > include/linux/dma-mapping.h | 46 ++++++++++++++++++++++++++
> > kernel/dma/Kconfig | 13 ++++++++
> > 7 files changed, 144 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> > index 96d8cfb14a60..a01afffcde7d 100644
> > --- a/drivers/of/address.c
> > +++ b/drivers/of/address.c
> > @@ -918,6 +918,47 @@ void __iomem *of_io_request_and_map(struct device_node *np, int index,
> > }
> > EXPORT_SYMBOL(of_io_request_and_map);
> >
> > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > +static int attach_dma_pfn_offset_map(struct device *dev,
> > + struct device_node *node, int num_ranges)
> > +{
> > + struct of_range_parser parser;
> > + struct of_range range;
> > + size_t r_size = (num_ranges + 1)
> > + * sizeof(struct dma_pfn_offset_region);
> > + struct dma_pfn_offset_region *r;
> > +
>
> > + r = devm_kzalloc(dev, r_size, GFP_KERNEL);
>
> devm_?!
Yes, otherwise if the device gets unbound/bound repeatedly then there
would be a memory leak.
>
>
> Looking at r_size it should be rather kcalloc().
Yep.
>
>
> > + if (!r)
> > + return -ENOMEM;
> > + dev->dma_pfn_offset_map = r;
> > + of_dma_range_parser_init(&parser, node);
> > +
> > + /*
> > + * Record all info for DMA ranges array. We could
> > + * just use the of_range struct, but if we did that it
> > + * would require more calculations for phys_to_dma and
> > + * dma_to_phys conversions.
> > + */
> > + for_each_of_range(&parser, &range) {
> > + r->cpu_beg = range.cpu_addr;
> > + r->cpu_end = r->cpu_beg + range.size;
> > + r->dma_beg = range.bus_addr;
> > + r->dma_end = r->dma_beg + range.size;
> > + r->pfn_offset = PFN_DOWN(range.cpu_addr)
> > + - PFN_DOWN(range.bus_addr);
> > + r++;
> > + }
> > + return 0;
> > +}
> > +#else
> > +static int attach_dma_pfn_offset_map(struct device *dev,
> > + struct device_node *node, int num_ranges)
> > +{
> > + return 0;
> > +}
> > +#endif
> > +
> > /**
> > * of_dma_get_range - Get DMA range info
> > * @dev: device pointer; only needed for a corner case.
> > @@ -947,6 +988,8 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
> > struct of_range_parser parser;
> > struct of_range range;
> > u64 dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
> > + bool dma_multi_pfn_offset = false;
> > + int num_ranges = 0;
> >
> > while (node) {
> > ranges = of_get_property(node, "dma-ranges", &len);
> > @@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
> > pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> > range.bus_addr, range.cpu_addr, range.size);
> >
> > + num_ranges++;
> > if (dma_offset && range.cpu_addr - range.bus_addr != dma_offset) {
> > - pr_warn("Can't handle multiple dma-ranges with different offsets on node(%pOF)\n", node);
> > - /* Don't error out as we'd break some existing DTs */
> > - continue;
> > + if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
> > + pr_warn("Can't handle multiple dma-ranges with different offsets on node(%pOF)\n", node);
> > + pr_warn("Perhaps set DMA_PFN_OFFSET_MAP=y?\n");
> > + /*
> > + * Don't error out as we'd break some existing
> > + * DTs that are using configs w/o
> > + * CONFIG_DMA_PFN_OFFSET_MAP set.
> > + */
> > + continue;
> > + }
> > + dma_multi_pfn_offset = true;
> > }
> > dma_offset = range.cpu_addr - range.bus_addr;
> >
> > @@ -991,6 +1043,13 @@ int of_dma_get_range(struct device *dev, struct device_node *np, u64 *dma_addr,
> > dma_end = range.bus_addr + range.size;
> > }
> >
> > + if (dma_multi_pfn_offset) {
> > + dma_offset = 0;
> > + ret = attach_dma_pfn_offset_map(dev, node, num_ranges);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > if (dma_start >= dma_end) {
> > ret = -EINVAL;
> > pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
> > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> > index 6197938dcc2d..aaa3e58f5eb4 100644
> > --- a/drivers/usb/core/message.c
> > +++ b/drivers/usb/core/message.c
> > @@ -1960,6 +1960,9 @@ int usb_set_configuration(struct usb_device *dev, int configuration)
> > */
> > intf->dev.dma_mask = dev->dev.dma_mask;
> > intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset;
> > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > + intf->dev.dma_pfn_offset_map = dev->dev.dma_pfn_offset_map;
> > +#endif
> > INIT_WORK(&intf->reset_ws, __usb_queue_reset_device);
> > intf->minor = -1;
> > device_initialize(&intf->dev);
> > diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> > index f16c26dc079d..d2ed4d90e56e 100644
> > --- a/drivers/usb/core/usb.c
> > +++ b/drivers/usb/core/usb.c
> > @@ -612,6 +612,9 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent,
> > */
> > dev->dev.dma_mask = bus->sysdev->dma_mask;
> > dev->dev.dma_pfn_offset = bus->sysdev->dma_pfn_offset;
> > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > + dev->dev.dma_pfn_offset_map = bus->sysdev->dma_pfn_offset_map;
> > +#endif
> > set_dev_node(&dev->dev, dev_to_node(bus->sysdev));
> > dev->state = USB_STATE_ATTACHED;
> > dev->lpm_disable_count = 1;
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index ac8e37cd716a..67a240ad4fc5 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -493,6 +493,8 @@ struct dev_links_info {
> > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
> > * DMA limit than the device itself supports.
> > * @dma_pfn_offset: offset of DMA memory range relatively of RAM
> > + * @dma_pfn_offset_map: Like dma_pfn_offset but used when there are multiple
> > + * pfn offsets for multiple dma-ranges.
> > * @dma_parms: A low level driver may set these to teach IOMMU code about
> > * segment limitations.
> > * @dma_pools: Dma pools (if dma'ble device).
> > @@ -578,7 +580,13 @@ struct device {
> > allocations such descriptors. */
> > u64 bus_dma_limit; /* upstream dma constraint */
> > unsigned long dma_pfn_offset;
> > -
> > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > + const struct dma_pfn_offset_region *dma_pfn_offset_map;
>
> > + /* Like dma_pfn_offset, but for
> > + * the unlikely case of multiple
> > + * offsets. If non-null, dma_pfn_offset
> > + * will be set to 0. */
>
> A bit harder to read comment indented too much and located after the declared variable.
Okay, will change. I was trying to keep the comment style of the other
variables.
> > +#endif
> > struct device_dma_parameters *dma_parms;
> >
> > struct list_head dma_pools; /* dma pools (if dma'ble) */
> > diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
> > index 24b8684aa21d..03110a57eabc 100644
> > --- a/include/linux/dma-direct.h
> > +++ b/include/linux/dma-direct.h
> > @@ -14,15 +14,21 @@ extern unsigned int zone_dma_bits;
> > static inline dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
> > {
> > dma_addr_t dev_addr = (dma_addr_t)paddr;
> > + /* The compiler should remove the 2nd term if !DMA_PFN_OFFSET_MAP */
> > + unsigned long dma_pfn_offset = dev->dma_pfn_offset
> > + + dma_pfn_offset_from_phys_addr(dev, paddr);
> >
> > - return dev_addr - ((dma_addr_t)dev->dma_pfn_offset << PAGE_SHIFT);
> > + return dev_addr - ((dma_addr_t)dma_pfn_offset << PAGE_SHIFT);
> > }
> >
> > static inline phys_addr_t __dma_to_phys(struct device *dev, dma_addr_t dev_addr)
> > {
> > phys_addr_t paddr = (phys_addr_t)dev_addr;
> > + /* The compiler should remove the 2nd term if !DMA_PFN_OFFSET_MAP */
> > + unsigned long dma_pfn_offset = dev->dma_pfn_offset
> > + + dma_pfn_offset_from_dma_addr(dev, paddr);
> >
> > - return paddr + ((phys_addr_t)dev->dma_pfn_offset << PAGE_SHIFT);
> > + return paddr + ((phys_addr_t)dma_pfn_offset << PAGE_SHIFT);
> > }
> > #endif /* !CONFIG_ARCH_HAS_PHYS_TO_DMA */
> >
> > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> > index 330ad58fbf4d..91940bba2229 100644
> > --- a/include/linux/dma-mapping.h
> > +++ b/include/linux/dma-mapping.h
> > @@ -256,6 +256,52 @@ static inline void dma_direct_sync_sg_for_cpu(struct device *dev,
> > size_t dma_direct_max_mapping_size(struct device *dev);
> >
> > #ifdef CONFIG_HAS_DMA
> > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > +struct dma_pfn_offset_region {
>
> > + phys_addr_t cpu_beg;
> > + phys_addr_t cpu_end;
> > + dma_addr_t dma_beg;
> > + dma_addr_t dma_end;
>
> Perhaps
> s,beg,start,
> in above names
>
Okay.
>
> > + unsigned long pfn_offset;
> > +};
> > +
> > +static inline unsigned long dma_pfn_offset_from_dma_addr(struct device *dev,
> > + dma_addr_t dma_addr)
> > +{
> > + const struct dma_pfn_offset_region *m = dev->dma_pfn_offset_map;
>
> > + if (m)
> > + for (; m->cpu_end; m++)
>
> Why not simple
>
> while (m) {
> ...
> }
>
> ?
>
That won't work; 'm' is either null or a valid pointer to an array
which has an additional entry that is 0-filled.. If non-null, 'm'
will never turn into NULL via 'm++' and the while loop will not
terminate.
>
>
> > + if (dma_addr >= m->dma_beg && dma_addr < m->dma_end)
> > + return m->pfn_offset;
> > + return 0;
> > +}
> > +
> > +static inline unsigned long dma_pfn_offset_from_phys_addr(struct device *dev,
> > + phys_addr_t paddr)
> > +{
> > + const struct dma_pfn_offset_region *m = dev->dma_pfn_offset_map;
> > +
>
> > + if (m)
> > + for (; m->cpu_end; m++)
>
> Ditto.
>
> > + if (paddr >= m->cpu_beg && paddr < m->cpu_end)
> > + return m->pfn_offset;
> > + return 0;
> > +}
> > +#else /* CONFIG_DMA_PFN_OFFSET_MAP */
> > +static inline unsigned long dma_pfn_offset_from_dma_addr(struct device *dev,
> > + dma_addr_t dma_addr)
> > +{
> > + return 0;
> > +}
> > +
> > +static inline unsigned long dma_pfn_offset_from_phys_addr(struct device *dev,
> > + phys_addr_t paddr)
> > +{
> > + return 0;
> > +}
> > +#endif /* CONFIG_DMA_PFN_OFFSET_MAP */
> > +
> > #include <asm/dma-mapping.h>
> >
> > static inline const struct dma_map_ops *get_dma_ops(struct device *dev)
> > diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig
> > index 4c103a24e380..ceb7e5e8f501 100644
> > --- a/kernel/dma/Kconfig
> > +++ b/kernel/dma/Kconfig
> > @@ -195,3 +195,16 @@ config DMA_API_DEBUG_SG
> > is technically out-of-spec.
> >
> > If unsure, say N.
> > +
> > +config DMA_PFN_OFFSET_MAP
> > + bool "Uses a DMA range map to calculate PFN offset"
> > + depends on PCIE_BRCMSTB
>
> > + default n
>
> Redundant.
Okay.
>
> > + help
> > + Some devices have a dma-range that gets converted to
> > + a dev->dma_pfn_offset value. This option is for the
> > + atypical case of there being multiple dma-ranges requiring
> > + multiple pfn offsets, which are selected from when
> > + converting to phys to dma and vice versa.
> > +
> > + If unsure, say N.
> > --
> > 2.17.1
> >
>
> --
> With Best Regards,
> Andy Shevchenko
Thanks!
Jim Quinlan
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
2020-05-26 19:12 ` [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets Jim Quinlan
2020-05-26 20:54 ` Andy Shevchenko
@ 2020-05-27 15:00 ` Nicolas Saenz Julienne
2020-05-27 15:43 ` Jim Quinlan
1 sibling, 1 reply; 30+ messages in thread
From: Nicolas Saenz Julienne @ 2020-05-27 15:00 UTC (permalink / raw)
To: Jim Quinlan, linux-pci, Christoph Hellwig, bcm-kernel-feedback-list
Cc: Rob Herring, Frank Rowand, Greg Kroah-Hartman, Marek Szyprowski,
Robin Murphy, Alan Stern, Oliver Neukum, Rafael J. Wysocki,
Andy Shevchenko, Wolfram Sang, Corey Minyard,
Srinivas Kandagatla, Suzuki K Poulose, Saravana Kannan,
Heikki Krogerus, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:USB SUBSYSTEM, open list:DMA MAPPING HELPERS
[-- Attachment #1: Type: text/plain, Size: 6547 bytes --]
Hi Jim,
one thing comes to mind, there is a small test suite in drivers/of/unittest.c
(specifically of_unittest_pci_dma_ranges()) you could extend it to include your
use cases.
On Tue, 2020-05-26 at 15:12 -0400, Jim Quinlan wrote:
> The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> similar to 'dma_pfn_offset' except that the offset chosen depends on the
> cpu or dma address involved.
>
> Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> ---
> drivers/of/address.c | 65 +++++++++++++++++++++++++++++++++++--
> drivers/usb/core/message.c | 3 ++
> drivers/usb/core/usb.c | 3 ++
> include/linux/device.h | 10 +++++-
> include/linux/dma-direct.h | 10 ++++--
> include/linux/dma-mapping.h | 46 ++++++++++++++++++++++++++
> kernel/dma/Kconfig | 13 ++++++++
> 7 files changed, 144 insertions(+), 6 deletions(-)
>
[...]
> @@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct
> device_node *np, u64 *dma_addr,
> pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> range.bus_addr, range.cpu_addr, range.size);
>
> + num_ranges++;
> if (dma_offset && range.cpu_addr - range.bus_addr != dma_offset)
> {
> - pr_warn("Can't handle multiple dma-ranges with different
> offsets on node(%pOF)\n", node);
> - /* Don't error out as we'd break some existing DTs */
> - continue;
> + if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
> + pr_warn("Can't handle multiple dma-ranges with
> different offsets on node(%pOF)\n", node);
> + pr_warn("Perhaps set DMA_PFN_OFFSET_MAP=y?\n");
> + /*
> + * Don't error out as we'd break some existing
> + * DTs that are using configs w/o
> + * CONFIG_DMA_PFN_OFFSET_MAP set.
> + */
> + continue;
dev->bus_dma_limit is set in of_dma_configure(), this function's caller, based
on dma_start's value (set after this continue). So you'd be effectively setting
the dev->bus_dma_limit to whatever we get from the first dma-range.
This can be troublesome depending on how the dma-ranges are setup, for example
if the first dma-range doesn't include the CMA area, in arm64 generally set as
high as possible in ZONE_DMA32, that would render it useless for
dma/{direct/swiotlb}. Again depending on the bus_dma_limit value, if smaller
than ZONE_DMA you'd be unable to allocate any DMA memory.
IMO, a solution to this calls for a revamp of dma-direct's dma_capable(): match
the target DMA memory area with each dma-range we have to see if it fits.
> + }
> + dma_multi_pfn_offset = true;
> }
> dma_offset = range.cpu_addr - range.bus_addr;
>
> @@ -991,6 +1043,13 @@ int of_dma_get_range(struct device *dev, struct
> device_node *np, u64 *dma_addr,
> dma_end = range.bus_addr + range.size;
> }
>
> + if (dma_multi_pfn_offset) {
> + dma_offset = 0;
> + ret = attach_dma_pfn_offset_map(dev, node, num_ranges);
> + if (ret)
> + return ret;
> + }
> +
> if (dma_start >= dma_end) {
> ret = -EINVAL;
> pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
> diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> index 6197938dcc2d..aaa3e58f5eb4 100644
> --- a/drivers/usb/core/message.c
> +++ b/drivers/usb/core/message.c
> @@ -1960,6 +1960,9 @@ int usb_set_configuration(struct usb_device *dev, int
> configuration)
> */
> intf->dev.dma_mask = dev->dev.dma_mask;
> intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset;
> +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> + intf->dev.dma_pfn_offset_map = dev->dev.dma_pfn_offset_map;
> +#endif
Thanks for looking at this, that said, I see more instances of drivers changing
dma_pfn_offset outside of the core code. Why not doing this there too?
Also, are we 100% sure that dev->dev.dma_pfn_offset isn't going to be freed
before we're done using intf->dev? Maybe it's safer to copy the ranges?
> INIT_WORK(&intf->reset_ws, __usb_queue_reset_device);
> intf->minor = -1;
> device_initialize(&intf->dev);
> diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> index f16c26dc079d..d2ed4d90e56e 100644
> --- a/drivers/usb/core/usb.c
> +++ b/drivers/usb/core/usb.c
> @@ -612,6 +612,9 @@ struct usb_device *usb_alloc_dev(struct usb_device
> *parent,
> */
> dev->dev.dma_mask = bus->sysdev->dma_mask;
> dev->dev.dma_pfn_offset = bus->sysdev->dma_pfn_offset;
> +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> + dev->dev.dma_pfn_offset_map = bus->sysdev->dma_pfn_offset_map;
> +#endif
> set_dev_node(&dev->dev, dev_to_node(bus->sysdev));
> dev->state = USB_STATE_ATTACHED;
> dev->lpm_disable_count = 1;
> diff --git a/include/linux/device.h b/include/linux/device.h
> index ac8e37cd716a..67a240ad4fc5 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -493,6 +493,8 @@ struct dev_links_info {
> * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
> * DMA limit than the device itself supports.
> * @dma_pfn_offset: offset of DMA memory range relatively of RAM
> + * @dma_pfn_offset_map: Like dma_pfn_offset but used when there are
> multiple
> + * pfn offsets for multiple dma-ranges.
> * @dma_parms: A low level driver may set these to teach IOMMU code
> about
> * segment limitations.
> * @dma_pools: Dma pools (if dma'ble device).
> @@ -578,7 +580,13 @@ struct device {
> allocations such descriptors. */
> u64 bus_dma_limit; /* upstream dma constraint */
> unsigned long dma_pfn_offset;
> -
> +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> + const struct dma_pfn_offset_region *dma_pfn_offset_map;
> + /* Like dma_pfn_offset, but for
> + * the unlikely case of multiple
> + * offsets. If non-null, dma_pfn_offset
> + * will be set to 0. */
> +#endif
I'm still sad this doesn't fully replace dma_pfn_offset & bus_dma_limit. I feel
the extra logic involved in incorporating this as default isn't going to be
noticeable as far as performance is concerned to single dma-range users, and
it'd make for a nicer DMA code. Also you'd force everyone to test their changes
on the multi dma-ranges code path, as opposed to having this disabled 99.9% of
the time (hence broken every so often).
Note that I sympathize with the amount of work involved on improving that, so
better wait to hear what more knowledgeable people have to say about this :)
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
2020-05-27 15:00 ` Nicolas Saenz Julienne
@ 2020-05-27 15:43 ` Jim Quinlan
2020-05-27 17:01 ` Nicolas Saenz Julienne
2020-05-29 17:34 ` Rob Herring
0 siblings, 2 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-27 15:43 UTC (permalink / raw)
To: Nicolas Saenz Julienne
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
Rob Herring, Frank Rowand, Greg Kroah-Hartman, Marek Szyprowski,
Robin Murphy, Alan Stern, Oliver Neukum, Rafael J. Wysocki,
Andy Shevchenko, Wolfram Sang, Corey Minyard,
Srinivas Kandagatla, Suzuki K Poulose, Saravana Kannan,
Heikki Krogerus, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:USB SUBSYSTEM, open list:DMA MAPPING HELPERS
Hi Nicolas,
On Wed, May 27, 2020 at 11:00 AM Nicolas Saenz Julienne
<nsaenzjulienne@suse.de> wrote:
>
> Hi Jim,
> one thing comes to mind, there is a small test suite in drivers/of/unittest.c
> (specifically of_unittest_pci_dma_ranges()) you could extend it to include your
> use cases.
Sure, will check out.
>
> On Tue, 2020-05-26 at 15:12 -0400, Jim Quinlan wrote:
> > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> > similar to 'dma_pfn_offset' except that the offset chosen depends on the
> > cpu or dma address involved.
> >
> > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > ---
> > drivers/of/address.c | 65 +++++++++++++++++++++++++++++++++++--
> > drivers/usb/core/message.c | 3 ++
> > drivers/usb/core/usb.c | 3 ++
> > include/linux/device.h | 10 +++++-
> > include/linux/dma-direct.h | 10 ++++--
> > include/linux/dma-mapping.h | 46 ++++++++++++++++++++++++++
> > kernel/dma/Kconfig | 13 ++++++++
> > 7 files changed, 144 insertions(+), 6 deletions(-)
> >
>
> [...]
>
> > @@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct
> > device_node *np, u64 *dma_addr,
> > pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> > range.bus_addr, range.cpu_addr, range.size);
> >
> > + num_ranges++;
> > if (dma_offset && range.cpu_addr - range.bus_addr != dma_offset)
> > {
> > - pr_warn("Can't handle multiple dma-ranges with different
> > offsets on node(%pOF)\n", node);
> > - /* Don't error out as we'd break some existing DTs */
> > - continue;
> > + if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
> > + pr_warn("Can't handle multiple dma-ranges with
> > different offsets on node(%pOF)\n", node);
> > + pr_warn("Perhaps set DMA_PFN_OFFSET_MAP=y?\n");
> > + /*
> > + * Don't error out as we'd break some existing
> > + * DTs that are using configs w/o
> > + * CONFIG_DMA_PFN_OFFSET_MAP set.
> > + */
> > + continue;
>
> dev->bus_dma_limit is set in of_dma_configure(), this function's caller, based
> on dma_start's value (set after this continue). So you'd be effectively setting
> the dev->bus_dma_limit to whatever we get from the first dma-range.
I'm not seeing that at all. On the evaluation of each dma-range,
dma_start and dma_end are re-evaluated to be the lowest and highest
bus values of the dma-ranges seen so far. After all dma-ranges are
examined, dev->bus_dma_limit being set to the highest. In fact, the
current code -- ie before my commits -- already does this for multiple
dma-ranges as long as the cpu-bus offset is the same in the
dma-ranges.
>
> This can be troublesome depending on how the dma-ranges are setup, for example
> if the first dma-range doesn't include the CMA area, in arm64 generally set as
> high as possible in ZONE_DMA32, that would render it useless for
> dma/{direct/swiotlb}. Again depending on the bus_dma_limit value, if smaller
> than ZONE_DMA you'd be unable to allocate any DMA memory.
>
> IMO, a solution to this calls for a revamp of dma-direct's dma_capable(): match
> the target DMA memory area with each dma-range we have to see if it fits.
>
> > + }
> > + dma_multi_pfn_offset = true;
> > }
> > dma_offset = range.cpu_addr - range.bus_addr;
> >
> > @@ -991,6 +1043,13 @@ int of_dma_get_range(struct device *dev, struct
> > device_node *np, u64 *dma_addr,
> > dma_end = range.bus_addr + range.size;
> > }
> >
> > + if (dma_multi_pfn_offset) {
> > + dma_offset = 0;
> > + ret = attach_dma_pfn_offset_map(dev, node, num_ranges);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > if (dma_start >= dma_end) {
> > ret = -EINVAL;
> > pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
> > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> > index 6197938dcc2d..aaa3e58f5eb4 100644
> > --- a/drivers/usb/core/message.c
> > +++ b/drivers/usb/core/message.c
> > @@ -1960,6 +1960,9 @@ int usb_set_configuration(struct usb_device *dev, int
> > configuration)
> > */
> > intf->dev.dma_mask = dev->dev.dma_mask;
> > intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset;
> > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > + intf->dev.dma_pfn_offset_map = dev->dev.dma_pfn_offset_map;
> > +#endif
>
> Thanks for looking at this, that said, I see more instances of drivers changing
> dma_pfn_offset outside of the core code. Why not doing this there too?
>
> Also, are we 100% sure that dev->dev.dma_pfn_offset isn't going to be freed
> before we're done using intf->dev? Maybe it's safer to copy the ranges?
>
> > INIT_WORK(&intf->reset_ws, __usb_queue_reset_device);
> > intf->minor = -1;
> > device_initialize(&intf->dev);
> > diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> > index f16c26dc079d..d2ed4d90e56e 100644
> > --- a/drivers/usb/core/usb.c
> > +++ b/drivers/usb/core/usb.c
> > @@ -612,6 +612,9 @@ struct usb_device *usb_alloc_dev(struct usb_device
> > *parent,
> > */
> > dev->dev.dma_mask = bus->sysdev->dma_mask;
> > dev->dev.dma_pfn_offset = bus->sysdev->dma_pfn_offset;
> > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > + dev->dev.dma_pfn_offset_map = bus->sysdev->dma_pfn_offset_map;
> > +#endif
> > set_dev_node(&dev->dev, dev_to_node(bus->sysdev));
> > dev->state = USB_STATE_ATTACHED;
> > dev->lpm_disable_count = 1;
> > diff --git a/include/linux/device.h b/include/linux/device.h
> > index ac8e37cd716a..67a240ad4fc5 100644
> > --- a/include/linux/device.h
> > +++ b/include/linux/device.h
> > @@ -493,6 +493,8 @@ struct dev_links_info {
> > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
> > * DMA limit than the device itself supports.
> > * @dma_pfn_offset: offset of DMA memory range relatively of RAM
> > + * @dma_pfn_offset_map: Like dma_pfn_offset but used when there are
> > multiple
> > + * pfn offsets for multiple dma-ranges.
> > * @dma_parms: A low level driver may set these to teach IOMMU code
> > about
> > * segment limitations.
> > * @dma_pools: Dma pools (if dma'ble device).
> > @@ -578,7 +580,13 @@ struct device {
> > allocations such descriptors. */
> > u64 bus_dma_limit; /* upstream dma constraint */
> > unsigned long dma_pfn_offset;
> > -
> > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > + const struct dma_pfn_offset_region *dma_pfn_offset_map;
> > + /* Like dma_pfn_offset, but for
> > + * the unlikely case of multiple
> > + * offsets. If non-null, dma_pfn_offset
> > + * will be set to 0. */
> > +#endif
>
> I'm still sad this doesn't fully replace dma_pfn_offset & bus_dma_limit. I feel
> the extra logic involved in incorporating this as default isn't going to be
> noticeable as far as performance is concerned to single dma-range users, and
> it'd make for a nicer DMA code. Also you'd force everyone to test their changes
> on the multi dma-ranges code path, as opposed to having this disabled 99.9% of
> the time (hence broken every so often).
Good point.
>
> Note that I sympathize with the amount of work involved on improving that, so
> better wait to hear what more knowledgeable people have to say about this :)
Yes, I agree. I want to avoid coding and testing one solution only to
have a different reviewer NAK it.
Many thanks,
Jim
>
> Regards,
> Nicolas
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
2020-05-27 15:43 ` Jim Quinlan
@ 2020-05-27 17:01 ` Nicolas Saenz Julienne
2020-05-29 17:34 ` Rob Herring
1 sibling, 0 replies; 30+ messages in thread
From: Nicolas Saenz Julienne @ 2020-05-27 17:01 UTC (permalink / raw)
To: Jim Quinlan
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
Rob Herring, Frank Rowand, Greg Kroah-Hartman, Marek Szyprowski,
Robin Murphy, Alan Stern, Oliver Neukum, Rafael J. Wysocki,
Andy Shevchenko, Wolfram Sang, Corey Minyard,
Srinivas Kandagatla, Suzuki K Poulose, Saravana Kannan,
Heikki Krogerus, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:USB SUBSYSTEM, open list:DMA MAPPING HELPERS
[-- Attachment #1: Type: text/plain, Size: 3658 bytes --]
Hi Jim,
On Wed, 2020-05-27 at 11:43 -0400, Jim Quinlan wrote:
> Hi Nicolas,
>
> On Wed, May 27, 2020 at 11:00 AM Nicolas Saenz Julienne
> <nsaenzjulienne@suse.de> wrote:
> > Hi Jim,
> > one thing comes to mind, there is a small test suite in
> > drivers/of/unittest.c
> > (specifically of_unittest_pci_dma_ranges()) you could extend it to include
> > your
> > use cases.
> Sure, will check out.
> > On Tue, 2020-05-26 at 15:12 -0400, Jim Quinlan wrote:
> > > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > > the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> > > similar to 'dma_pfn_offset' except that the offset chosen depends on the
> > > cpu or dma address involved.
> > >
> > > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > > ---
> > > drivers/of/address.c | 65 +++++++++++++++++++++++++++++++++++--
> > > drivers/usb/core/message.c | 3 ++
> > > drivers/usb/core/usb.c | 3 ++
> > > include/linux/device.h | 10 +++++-
> > > include/linux/dma-direct.h | 10 ++++--
> > > include/linux/dma-mapping.h | 46 ++++++++++++++++++++++++++
> > > kernel/dma/Kconfig | 13 ++++++++
> > > 7 files changed, 144 insertions(+), 6 deletions(-)
> > >
> >
> > [...]
> >
> > > @@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct
> > > device_node *np, u64 *dma_addr,
> > > pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> > > range.bus_addr, range.cpu_addr, range.size);
> > >
> > > + num_ranges++;
> > > if (dma_offset && range.cpu_addr - range.bus_addr !=
> > > dma_offset)
> > > {
> > > - pr_warn("Can't handle multiple dma-ranges with
> > > different
> > > offsets on node(%pOF)\n", node);
> > > - /* Don't error out as we'd break some existing DTs
> > > */
> > > - continue;
> > > + if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
> > > + pr_warn("Can't handle multiple dma-ranges
> > > with
> > > different offsets on node(%pOF)\n", node);
> > > + pr_warn("Perhaps set
> > > DMA_PFN_OFFSET_MAP=y?\n");
> > > + /*
> > > + * Don't error out as we'd break some
> > > existing
> > > + * DTs that are using configs w/o
> > > + * CONFIG_DMA_PFN_OFFSET_MAP set.
> > > + */
> > > + continue;
> >
> > dev->bus_dma_limit is set in of_dma_configure(), this function's caller,
> > based
> > on dma_start's value (set after this continue). So you'd be effectively
> > setting
> > the dev->bus_dma_limit to whatever we get from the first dma-range.
> I'm not seeing that at all. On the evaluation of each dma-range,
> dma_start and dma_end are re-evaluated to be the lowest and highest
> bus values of the dma-ranges seen so far. After all dma-ranges are
> examined, dev->bus_dma_limit being set to the highest. In fact, the
> current code -- ie before my commits -- already does this for multiple
> dma-ranges as long as the cpu-bus offset is the same in the
> dma-ranges.
Sorry I got carried away, you're right.
So I understand there is an underlaying assumption that the non DMAble memory
space will always sit on top of the bus memory space, as intertwined as it
might be, so as to every phys_to_dma() call on non DMAble memory to fall above
bus_dma_limit.
Regards,
Nicolas
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 02/14] ata: ahci_brcm: Fix use of BCM7216 reset controller
2020-05-26 19:12 ` [PATCH v2 02/14] ata: ahci_brcm: Fix use of BCM7216 reset controller Jim Quinlan
@ 2020-05-27 23:57 ` Florian Fainelli
0 siblings, 0 replies; 30+ messages in thread
From: Florian Fainelli @ 2020-05-27 23:57 UTC (permalink / raw)
To: Jim Quinlan, linux-pci, Christoph Hellwig,
Nicolas Saenz Julienne, bcm-kernel-feedback-list
Cc: Jens Axboe, Philipp Zabel,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
open list
On 5/26/2020 12:12 PM, Jim Quinlan wrote:
> From: Jim Quinlan <jquinlan@broadcom.com>
>
> A reset controller "rescal" is shared between the AHCI driver and the PCIe
> driver for the BrcmSTB 7216 chip. The code is modified to allow this
> sharing and to deassert() properly.
>
> Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
This patch is actually a bug fix and should have:
Fixes: 272ecd60a636 ("ata: ahci_brcm: BCM7216 reset is self de-asserting")
Fixes: c345ec6a50e9 ("ata: ahci_brcm: Support BCM7216 reset controller
name")
and it could probably be merged out of this patch series I believe.
--
Florian
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
2020-05-27 15:43 ` Jim Quinlan
2020-05-27 17:01 ` Nicolas Saenz Julienne
@ 2020-05-29 17:34 ` Rob Herring
2020-05-29 17:51 ` Jim Quinlan
1 sibling, 1 reply; 30+ messages in thread
From: Rob Herring @ 2020-05-29 17:34 UTC (permalink / raw)
To: Jim Quinlan
Cc: Nicolas Saenz Julienne,
open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
Frank Rowand, Greg Kroah-Hartman, Marek Szyprowski, Robin Murphy,
Alan Stern, Oliver Neukum, Rafael J. Wysocki, Andy Shevchenko,
Wolfram Sang, Corey Minyard, Srinivas Kandagatla,
Suzuki K Poulose, Saravana Kannan, Heikki Krogerus, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:USB SUBSYSTEM, open list:DMA MAPPING HELPERS
On Wed, May 27, 2020 at 9:43 AM Jim Quinlan <james.quinlan@broadcom.com> wrote:
>
> Hi Nicolas,
>
> On Wed, May 27, 2020 at 11:00 AM Nicolas Saenz Julienne
> <nsaenzjulienne@suse.de> wrote:
> >
> > Hi Jim,
> > one thing comes to mind, there is a small test suite in drivers/of/unittest.c
> > (specifically of_unittest_pci_dma_ranges()) you could extend it to include your
> > use cases.
> Sure, will check out.
> >
> > On Tue, 2020-05-26 at 15:12 -0400, Jim Quinlan wrote:
> > > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > > the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> > > similar to 'dma_pfn_offset' except that the offset chosen depends on the
> > > cpu or dma address involved.
> > >
> > > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > > ---
> > > drivers/of/address.c | 65 +++++++++++++++++++++++++++++++++++--
> > > drivers/usb/core/message.c | 3 ++
> > > drivers/usb/core/usb.c | 3 ++
> > > include/linux/device.h | 10 +++++-
> > > include/linux/dma-direct.h | 10 ++++--
> > > include/linux/dma-mapping.h | 46 ++++++++++++++++++++++++++
> > > kernel/dma/Kconfig | 13 ++++++++
> > > 7 files changed, 144 insertions(+), 6 deletions(-)
> > >
> >
> > [...]
> >
> > > @@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct
> > > device_node *np, u64 *dma_addr,
> > > pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> > > range.bus_addr, range.cpu_addr, range.size);
> > >
> > > + num_ranges++;
> > > if (dma_offset && range.cpu_addr - range.bus_addr != dma_offset)
> > > {
> > > - pr_warn("Can't handle multiple dma-ranges with different
> > > offsets on node(%pOF)\n", node);
> > > - /* Don't error out as we'd break some existing DTs */
> > > - continue;
> > > + if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
> > > + pr_warn("Can't handle multiple dma-ranges with
> > > different offsets on node(%pOF)\n", node);
> > > + pr_warn("Perhaps set DMA_PFN_OFFSET_MAP=y?\n");
> > > + /*
> > > + * Don't error out as we'd break some existing
> > > + * DTs that are using configs w/o
> > > + * CONFIG_DMA_PFN_OFFSET_MAP set.
> > > + */
> > > + continue;
> >
> > dev->bus_dma_limit is set in of_dma_configure(), this function's caller, based
> > on dma_start's value (set after this continue). So you'd be effectively setting
> > the dev->bus_dma_limit to whatever we get from the first dma-range.
> I'm not seeing that at all. On the evaluation of each dma-range,
> dma_start and dma_end are re-evaluated to be the lowest and highest
> bus values of the dma-ranges seen so far. After all dma-ranges are
> examined, dev->bus_dma_limit being set to the highest. In fact, the
> current code -- ie before my commits -- already does this for multiple
> dma-ranges as long as the cpu-bus offset is the same in the
> dma-ranges.
> >
> > This can be troublesome depending on how the dma-ranges are setup, for example
> > if the first dma-range doesn't include the CMA area, in arm64 generally set as
> > high as possible in ZONE_DMA32, that would render it useless for
> > dma/{direct/swiotlb}. Again depending on the bus_dma_limit value, if smaller
> > than ZONE_DMA you'd be unable to allocate any DMA memory.
> >
> > IMO, a solution to this calls for a revamp of dma-direct's dma_capable(): match
> > the target DMA memory area with each dma-range we have to see if it fits.
> >
> > > + }
> > > + dma_multi_pfn_offset = true;
> > > }
> > > dma_offset = range.cpu_addr - range.bus_addr;
> > >
> > > @@ -991,6 +1043,13 @@ int of_dma_get_range(struct device *dev, struct
> > > device_node *np, u64 *dma_addr,
> > > dma_end = range.bus_addr + range.size;
> > > }
> > >
> > > + if (dma_multi_pfn_offset) {
> > > + dma_offset = 0;
> > > + ret = attach_dma_pfn_offset_map(dev, node, num_ranges);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > +
> > > if (dma_start >= dma_end) {
> > > ret = -EINVAL;
> > > pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
> > > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> > > index 6197938dcc2d..aaa3e58f5eb4 100644
> > > --- a/drivers/usb/core/message.c
> > > +++ b/drivers/usb/core/message.c
> > > @@ -1960,6 +1960,9 @@ int usb_set_configuration(struct usb_device *dev, int
> > > configuration)
> > > */
> > > intf->dev.dma_mask = dev->dev.dma_mask;
> > > intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset;
> > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > > + intf->dev.dma_pfn_offset_map = dev->dev.dma_pfn_offset_map;
> > > +#endif
> >
> > Thanks for looking at this, that said, I see more instances of drivers changing
> > dma_pfn_offset outside of the core code. Why not doing this there too?
> >
> > Also, are we 100% sure that dev->dev.dma_pfn_offset isn't going to be freed
> > before we're done using intf->dev? Maybe it's safer to copy the ranges?
> >
> > > INIT_WORK(&intf->reset_ws, __usb_queue_reset_device);
> > > intf->minor = -1;
> > > device_initialize(&intf->dev);
> > > diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> > > index f16c26dc079d..d2ed4d90e56e 100644
> > > --- a/drivers/usb/core/usb.c
> > > +++ b/drivers/usb/core/usb.c
> > > @@ -612,6 +612,9 @@ struct usb_device *usb_alloc_dev(struct usb_device
> > > *parent,
> > > */
> > > dev->dev.dma_mask = bus->sysdev->dma_mask;
> > > dev->dev.dma_pfn_offset = bus->sysdev->dma_pfn_offset;
> > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > > + dev->dev.dma_pfn_offset_map = bus->sysdev->dma_pfn_offset_map;
> > > +#endif
> > > set_dev_node(&dev->dev, dev_to_node(bus->sysdev));
> > > dev->state = USB_STATE_ATTACHED;
> > > dev->lpm_disable_count = 1;
> > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > index ac8e37cd716a..67a240ad4fc5 100644
> > > --- a/include/linux/device.h
> > > +++ b/include/linux/device.h
> > > @@ -493,6 +493,8 @@ struct dev_links_info {
> > > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
> > > * DMA limit than the device itself supports.
> > > * @dma_pfn_offset: offset of DMA memory range relatively of RAM
> > > + * @dma_pfn_offset_map: Like dma_pfn_offset but used when there are
> > > multiple
> > > + * pfn offsets for multiple dma-ranges.
> > > * @dma_parms: A low level driver may set these to teach IOMMU code
> > > about
> > > * segment limitations.
> > > * @dma_pools: Dma pools (if dma'ble device).
> > > @@ -578,7 +580,13 @@ struct device {
> > > allocations such descriptors. */
> > > u64 bus_dma_limit; /* upstream dma constraint */
> > > unsigned long dma_pfn_offset;
> > > -
> > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > > + const struct dma_pfn_offset_region *dma_pfn_offset_map;
> > > + /* Like dma_pfn_offset, but for
> > > + * the unlikely case of multiple
> > > + * offsets. If non-null, dma_pfn_offset
> > > + * will be set to 0. */
> > > +#endif
> >
> > I'm still sad this doesn't fully replace dma_pfn_offset & bus_dma_limit. I feel
> > the extra logic involved in incorporating this as default isn't going to be
> > noticeable as far as performance is concerned to single dma-range users, and
> > it'd make for a nicer DMA code. Also you'd force everyone to test their changes
> > on the multi dma-ranges code path, as opposed to having this disabled 99.9% of
> > the time (hence broken every so often).
> Good point.
+1
> > Note that I sympathize with the amount of work involved on improving that, so
> > better wait to hear what more knowledgeable people have to say about this :)
> Yes, I agree. I want to avoid coding and testing one solution only to
> have a different reviewer NAK it.
It's a pretty safe bet that everyone will prefer one code path over 2.
Rob
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips
2020-05-26 19:12 ` [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips Jim Quinlan
@ 2020-05-29 17:46 ` Rob Herring
2020-06-02 20:53 ` Jim Quinlan
0 siblings, 1 reply; 30+ messages in thread
From: Rob Herring @ 2020-05-29 17:46 UTC (permalink / raw)
To: Jim Quinlan
Cc: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, Florian Fainelli, Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
On Tue, May 26, 2020 at 03:12:42PM -0400, Jim Quinlan wrote:
> From: Jim Quinlan <jquinlan@broadcom.com>
>
> - Add compatible strings for three more Broadcom STB chips: 7278, 7216,
> 7211 (STB version of RPi4).
> - add new property 'brcm,scb-sizes'
> - add new property 'resets'
> - add new property 'reset-names'
> - allow 'ranges' and 'dma-ranges' to have more than one item and update
> the example to show this.
>
> Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> ---
> .../bindings/pci/brcm,stb-pcie.yaml | 40 +++++++++++++++++--
> 1 file changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> index 8680a0f86c5a..66a7df45983d 100644
> --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> @@ -14,7 +14,13 @@ allOf:
>
> properties:
> compatible:
> - const: brcm,bcm2711-pcie # The Raspberry Pi 4
> + items:
> + - enum:
Don't need items here. Just change the const to enum.
> + - brcm,bcm2711-pcie # The Raspberry Pi 4
> + - brcm,bcm7211-pcie # Broadcom STB version of RPi4
> + - brcm,bcm7278-pcie # Broadcom 7278 Arm
> + - brcm,bcm7216-pcie # Broadcom 7216 Arm
> + - brcm,bcm7445-pcie # Broadcom 7445 Arm
>
> reg:
> maxItems: 1
> @@ -34,10 +40,12 @@ properties:
> - const: msi
>
> ranges:
> - maxItems: 1
> + minItems: 1
> + maxItems: 4
>
> dma-ranges:
> - maxItems: 1
> + minItems: 1
> + maxItems: 6
>
> clocks:
> maxItems: 1
> @@ -58,8 +66,30 @@ properties:
>
> aspm-no-l0s: true
>
> + resets:
> + description: for "brcm,bcm7216-pcie", must be a valid reset
> + phandle pointing to the RESCAL reset controller provider node.
> + $ref: "/schemas/types.yaml#/definitions/phandle"
> +
> + reset-names:
> + items:
> + - const: rescal
These are going to need to be an if/then schema if they only apply to
certain compatible(s).
> +
> + brcm,scb-sizes:
> + description: (u32, u32) tuple giving the 64bit PCIe memory
> + viewport size of a memory controller. There may be up to
> + three controllers, and each size must be a power of two
> + with a size greater or equal to the amount of memory the
> + controller supports.
This sounds like what dma-ranges should express?
If not, we do have 64-bit size if that what you need.
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32-array
> + - items:
> + minItems: 2
> + maxItems: 6
> +
> required:
> - reg
> + - ranges
> - dma-ranges
> - "#interrupt-cells"
> - interrupts
> @@ -93,7 +123,9 @@ examples:
> msi-parent = <&pcie0>;
> msi-controller;
> ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>;
> - dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>;
> + dma-ranges = <0x42000000 0x1 0x00000000 0x0 0x40000000 0x0 0x80000000>,
> + <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>;
> brcm,enable-ssc;
> + brcm,scb-sizes = <0x0 0x80000000 0x0 0x80000000>;
> };
> };
> --
> 2.17.1
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
` (13 preceding siblings ...)
2020-05-26 19:12 ` [PATCH v2 14/14] PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list Jim Quinlan
@ 2020-05-29 17:48 ` Rob Herring
2020-05-29 17:55 ` Jim Quinlan
14 siblings, 1 reply; 30+ messages in thread
From: Rob Herring @ 2020-05-29 17:48 UTC (permalink / raw)
To: Jim Quinlan
Cc: linux-pci, Christoph Hellwig, Nicolas Saenz Julienne,
bcm-kernel-feedback-list, Alan Stern, Andy Shevchenko,
Corey Minyard, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE,
Greg Kroah-Hartman, Heikki Krogerus,
open list:DMA MAPPING HELPERS, Julien Grall,
moderated list:ARM PORT,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
open list,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:USB SUBSYSTEM, Mark Brown, Oliver Neukum,
Rafael J. Wysocki, Robin Murphy, Saravana Kannan,
Stefano Stabellini, Suzuki K Poulose, Ulf Hansson, Wolfram Sang
On Tue, May 26, 2020 at 03:12:39PM -0400, Jim Quinlan wrote:
> v2:
> Commit: "device core: Add ability to handle multiple dma offsets"
> o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
> o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
> o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
> o dev->dma_pfn_map => dev->dma_pfn_offset_map
> o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
> o In device.h: s/const void */const struct dma_pfn_offset_region */
> o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since
> guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph)
> o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now
> dev->dma_pfn_offset_map is copied as well.
> o Merged two of the DMA commits into one (Christoph).
>
> Commit "arm: dma-mapping: Invoke dma offset func if needed":
> o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET
>
> Other commits' changes:
> o Removed need for carrying of_id var in priv (Nicolas)
> o Commit message rewordings (Bjorn)
> o Commit log messages filled to 75 chars (Bjorn)
> o devm_reset_control_get_shared())
> => devm_reset_control_get_optional_shared (Philipp)
> o Add call to reset_control_assert() in PCIe remove routines (Philipp)
>
> v1:
> This patchset expands the usefulness of the Broadcom Settop Box PCIe
> controller by building upon the PCIe driver used currently by the
> Raspbery Pi. Other forms of this patchset were submitted by me years
> ago and not accepted; the major sticking point was the code required
> for the DMA remapping needed for the PCIe driver to work [1].
>
> There have been many changes to the DMA and OF subsystems since that
> time, making a cleaner and less intrusive patchset possible. This
> patchset implements a generalization of "dev->dma_pfn_offset", except
> that instead of a single scalar offset it provides for multiple
> offsets via a function which depends upon the "dma-ranges" property of
> the PCIe host controller. This is required for proper functionality
> of the BrcmSTB PCIe controller and possibly some other devices.
If you can enable the h/w support without the multiple offset support,
then I'd split up this series. The latter part might take a bit more
time.
Rob
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets
2020-05-29 17:34 ` Rob Herring
@ 2020-05-29 17:51 ` Jim Quinlan
0 siblings, 0 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-29 17:51 UTC (permalink / raw)
To: Rob Herring
Cc: Nicolas Saenz Julienne,
open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE,
Frank Rowand, Greg Kroah-Hartman, Marek Szyprowski, Robin Murphy,
Alan Stern, Oliver Neukum, Rafael J. Wysocki, Andy Shevchenko,
Wolfram Sang, Corey Minyard, Srinivas Kandagatla,
Suzuki K Poulose, Saravana Kannan, Heikki Krogerus, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list,
open list:USB SUBSYSTEM, open list:DMA MAPPING HELPERS
On Fri, May 29, 2020 at 1:35 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Wed, May 27, 2020 at 9:43 AM Jim Quinlan <james.quinlan@broadcom.com> wrote:
> >
> > Hi Nicolas,
> >
> > On Wed, May 27, 2020 at 11:00 AM Nicolas Saenz Julienne
> > <nsaenzjulienne@suse.de> wrote:
> > >
> > > Hi Jim,
> > > one thing comes to mind, there is a small test suite in drivers/of/unittest.c
> > > (specifically of_unittest_pci_dma_ranges()) you could extend it to include your
> > > use cases.
> > Sure, will check out.
> > >
> > > On Tue, 2020-05-26 at 15:12 -0400, Jim Quinlan wrote:
> > > > The new field in struct device 'dma_pfn_offset_map' is used to facilitate
> > > > the use of multiple pfn offsets between cpu addrs and dma addrs. It is
> > > > similar to 'dma_pfn_offset' except that the offset chosen depends on the
> > > > cpu or dma address involved.
> > > >
> > > > Signed-off-by: Jim Quinlan <james.quinlan@broadcom.com>
> > > > ---
> > > > drivers/of/address.c | 65 +++++++++++++++++++++++++++++++++++--
> > > > drivers/usb/core/message.c | 3 ++
> > > > drivers/usb/core/usb.c | 3 ++
> > > > include/linux/device.h | 10 +++++-
> > > > include/linux/dma-direct.h | 10 ++++--
> > > > include/linux/dma-mapping.h | 46 ++++++++++++++++++++++++++
> > > > kernel/dma/Kconfig | 13 ++++++++
> > > > 7 files changed, 144 insertions(+), 6 deletions(-)
> > > >
> > >
> > > [...]
> > >
> > > > @@ -977,10 +1020,19 @@ int of_dma_get_range(struct device *dev, struct
> > > > device_node *np, u64 *dma_addr,
> > > > pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
> > > > range.bus_addr, range.cpu_addr, range.size);
> > > >
> > > > + num_ranges++;
> > > > if (dma_offset && range.cpu_addr - range.bus_addr != dma_offset)
> > > > {
> > > > - pr_warn("Can't handle multiple dma-ranges with different
> > > > offsets on node(%pOF)\n", node);
> > > > - /* Don't error out as we'd break some existing DTs */
> > > > - continue;
> > > > + if (!IS_ENABLED(CONFIG_DMA_PFN_OFFSET_MAP)) {
> > > > + pr_warn("Can't handle multiple dma-ranges with
> > > > different offsets on node(%pOF)\n", node);
> > > > + pr_warn("Perhaps set DMA_PFN_OFFSET_MAP=y?\n");
> > > > + /*
> > > > + * Don't error out as we'd break some existing
> > > > + * DTs that are using configs w/o
> > > > + * CONFIG_DMA_PFN_OFFSET_MAP set.
> > > > + */
> > > > + continue;
> > >
> > > dev->bus_dma_limit is set in of_dma_configure(), this function's caller, based
> > > on dma_start's value (set after this continue). So you'd be effectively setting
> > > the dev->bus_dma_limit to whatever we get from the first dma-range.
> > I'm not seeing that at all. On the evaluation of each dma-range,
> > dma_start and dma_end are re-evaluated to be the lowest and highest
> > bus values of the dma-ranges seen so far. After all dma-ranges are
> > examined, dev->bus_dma_limit being set to the highest. In fact, the
> > current code -- ie before my commits -- already does this for multiple
> > dma-ranges as long as the cpu-bus offset is the same in the
> > dma-ranges.
> > >
> > > This can be troublesome depending on how the dma-ranges are setup, for example
> > > if the first dma-range doesn't include the CMA area, in arm64 generally set as
> > > high as possible in ZONE_DMA32, that would render it useless for
> > > dma/{direct/swiotlb}. Again depending on the bus_dma_limit value, if smaller
> > > than ZONE_DMA you'd be unable to allocate any DMA memory.
> > >
> > > IMO, a solution to this calls for a revamp of dma-direct's dma_capable(): match
> > > the target DMA memory area with each dma-range we have to see if it fits.
> > >
> > > > + }
> > > > + dma_multi_pfn_offset = true;
> > > > }
> > > > dma_offset = range.cpu_addr - range.bus_addr;
> > > >
> > > > @@ -991,6 +1043,13 @@ int of_dma_get_range(struct device *dev, struct
> > > > device_node *np, u64 *dma_addr,
> > > > dma_end = range.bus_addr + range.size;
> > > > }
> > > >
> > > > + if (dma_multi_pfn_offset) {
> > > > + dma_offset = 0;
> > > > + ret = attach_dma_pfn_offset_map(dev, node, num_ranges);
> > > > + if (ret)
> > > > + return ret;
> > > > + }
> > > > +
> > > > if (dma_start >= dma_end) {
> > > > ret = -EINVAL;
> > > > pr_debug("Invalid DMA ranges configuration on node(%pOF)\n",
> > > > diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c
> > > > index 6197938dcc2d..aaa3e58f5eb4 100644
> > > > --- a/drivers/usb/core/message.c
> > > > +++ b/drivers/usb/core/message.c
> > > > @@ -1960,6 +1960,9 @@ int usb_set_configuration(struct usb_device *dev, int
> > > > configuration)
> > > > */
> > > > intf->dev.dma_mask = dev->dev.dma_mask;
> > > > intf->dev.dma_pfn_offset = dev->dev.dma_pfn_offset;
> > > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > > > + intf->dev.dma_pfn_offset_map = dev->dev.dma_pfn_offset_map;
> > > > +#endif
> > >
> > > Thanks for looking at this, that said, I see more instances of drivers changing
> > > dma_pfn_offset outside of the core code. Why not doing this there too?
> > >
> > > Also, are we 100% sure that dev->dev.dma_pfn_offset isn't going to be freed
> > > before we're done using intf->dev? Maybe it's safer to copy the ranges?
> > >
> > > > INIT_WORK(&intf->reset_ws, __usb_queue_reset_device);
> > > > intf->minor = -1;
> > > > device_initialize(&intf->dev);
> > > > diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
> > > > index f16c26dc079d..d2ed4d90e56e 100644
> > > > --- a/drivers/usb/core/usb.c
> > > > +++ b/drivers/usb/core/usb.c
> > > > @@ -612,6 +612,9 @@ struct usb_device *usb_alloc_dev(struct usb_device
> > > > *parent,
> > > > */
> > > > dev->dev.dma_mask = bus->sysdev->dma_mask;
> > > > dev->dev.dma_pfn_offset = bus->sysdev->dma_pfn_offset;
> > > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > > > + dev->dev.dma_pfn_offset_map = bus->sysdev->dma_pfn_offset_map;
> > > > +#endif
> > > > set_dev_node(&dev->dev, dev_to_node(bus->sysdev));
> > > > dev->state = USB_STATE_ATTACHED;
> > > > dev->lpm_disable_count = 1;
> > > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > > index ac8e37cd716a..67a240ad4fc5 100644
> > > > --- a/include/linux/device.h
> > > > +++ b/include/linux/device.h
> > > > @@ -493,6 +493,8 @@ struct dev_links_info {
> > > > * @bus_dma_limit: Limit of an upstream bridge or bus which imposes a smaller
> > > > * DMA limit than the device itself supports.
> > > > * @dma_pfn_offset: offset of DMA memory range relatively of RAM
> > > > + * @dma_pfn_offset_map: Like dma_pfn_offset but used when there are
> > > > multiple
> > > > + * pfn offsets for multiple dma-ranges.
> > > > * @dma_parms: A low level driver may set these to teach IOMMU code
> > > > about
> > > > * segment limitations.
> > > > * @dma_pools: Dma pools (if dma'ble device).
> > > > @@ -578,7 +580,13 @@ struct device {
> > > > allocations such descriptors. */
> > > > u64 bus_dma_limit; /* upstream dma constraint */
> > > > unsigned long dma_pfn_offset;
> > > > -
> > > > +#ifdef CONFIG_DMA_PFN_OFFSET_MAP
> > > > + const struct dma_pfn_offset_region *dma_pfn_offset_map;
> > > > + /* Like dma_pfn_offset, but for
> > > > + * the unlikely case of multiple
> > > > + * offsets. If non-null, dma_pfn_offset
> > > > + * will be set to 0. */
> > > > +#endif
> > >
> > > I'm still sad this doesn't fully replace dma_pfn_offset & bus_dma_limit. I feel
> > > the extra logic involved in incorporating this as default isn't going to be
> > > noticeable as far as performance is concerned to single dma-range users, and
> > > it'd make for a nicer DMA code. Also you'd force everyone to test their changes
> > > on the multi dma-ranges code path, as opposed to having this disabled 99.9% of
> > > the time (hence broken every so often).
> > Good point.
>
> +1
>
> > > Note that I sympathize with the amount of work involved on improving that, so
> > > better wait to hear what more knowledgeable people have to say about this :)
> > Yes, I agree. I want to avoid coding and testing one solution only to
> > have a different reviewer NAK it.
>
> It's a pretty safe bet that everyone will prefer one code path over 2.
>
> Rob
Thanks for the input. Will do, and send out v3 ASAP.
Thanks, Jim
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips
2020-05-29 17:48 ` [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Rob Herring
@ 2020-05-29 17:55 ` Jim Quinlan
0 siblings, 0 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-05-29 17:55 UTC (permalink / raw)
To: Rob Herring
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, Nicolas Saenz Julienne,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Alan Stern,
Andy Shevchenko, Corey Minyard, Dan Williams,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE,
Greg Kroah-Hartman, Heikki Krogerus,
open list:DMA MAPPING HELPERS, Julien Grall,
moderated list:ARM PORT,
open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers),
open list,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:USB SUBSYSTEM, Mark Brown, Oliver Neukum,
Rafael J. Wysocki, Robin Murphy, Saravana Kannan,
Stefano Stabellini, Suzuki K Poulose, Ulf Hansson, Wolfram Sang
On Fri, May 29, 2020 at 1:49 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, May 26, 2020 at 03:12:39PM -0400, Jim Quinlan wrote:
> > v2:
> > Commit: "device core: Add ability to handle multiple dma offsets"
> > o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph)
> > o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph)
> > o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP
> > o dev->dma_pfn_map => dev->dma_pfn_offset_map
> > o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph)
> > o In device.h: s/const void */const struct dma_pfn_offset_region */
> > o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since
> > guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph)
> > o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now
> > dev->dma_pfn_offset_map is copied as well.
> > o Merged two of the DMA commits into one (Christoph).
> >
> > Commit "arm: dma-mapping: Invoke dma offset func if needed":
> > o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET
> >
> > Other commits' changes:
> > o Removed need for carrying of_id var in priv (Nicolas)
> > o Commit message rewordings (Bjorn)
> > o Commit log messages filled to 75 chars (Bjorn)
> > o devm_reset_control_get_shared())
> > => devm_reset_control_get_optional_shared (Philipp)
> > o Add call to reset_control_assert() in PCIe remove routines (Philipp)
> >
> > v1:
> > This patchset expands the usefulness of the Broadcom Settop Box PCIe
> > controller by building upon the PCIe driver used currently by the
> > Raspbery Pi. Other forms of this patchset were submitted by me years
> > ago and not accepted; the major sticking point was the code required
> > for the DMA remapping needed for the PCIe driver to work [1].
> >
> > There have been many changes to the DMA and OF subsystems since that
> > time, making a cleaner and less intrusive patchset possible. This
> > patchset implements a generalization of "dev->dma_pfn_offset", except
> > that instead of a single scalar offset it provides for multiple
> > offsets via a function which depends upon the "dma-ranges" property of
> > the PCIe host controller. This is required for proper functionality
> > of the BrcmSTB PCIe controller and possibly some other devices.
>
> If you can enable the h/w support without the multiple offset support,
> then I'd split up this series. The latter part might take a bit more
> time.
>
> Rob
Unfortunately, the STB PCIe controller depends on the multiple PFN
offset functionality.
Thanks,
Jim
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 01/14] PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB
2020-05-26 19:12 ` [PATCH v2 01/14] PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB Jim Quinlan
@ 2020-06-01 21:44 ` Rob Herring
0 siblings, 0 replies; 30+ messages in thread
From: Rob Herring @ 2020-06-01 21:44 UTC (permalink / raw)
To: Jim Quinlan
Cc: Nicolas Saenz Julienne, Christoph Hellwig, Bjorn Helgaas,
Lorenzo Pieralisi, linux-pci, linux-kernel,
bcm-kernel-feedback-list
On Tue, 26 May 2020 15:12:40 -0400, Jim Quinlan wrote:
> From: Jim Quinlan <jquinlan@broadcom.com>
>
> Have PCIE_BRCMSTB depend on ARCH_BRCMSTB. Also set the default value to
> ARCH_BRCMSTB.
>
> Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/pci/controller/Kconfig | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips
2020-05-29 17:46 ` Rob Herring
@ 2020-06-02 20:53 ` Jim Quinlan
2020-06-02 21:41 ` Rob Herring
0 siblings, 1 reply; 30+ messages in thread
From: Jim Quinlan @ 2020-06-02 20:53 UTC (permalink / raw)
To: Rob Herring
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, Nicolas Saenz Julienne,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Florian Fainelli,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
On Fri, May 29, 2020 at 1:46 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, May 26, 2020 at 03:12:42PM -0400, Jim Quinlan wrote:
> > From: Jim Quinlan <jquinlan@broadcom.com>
> >
> > - Add compatible strings for three more Broadcom STB chips: 7278, 7216,
> > 7211 (STB version of RPi4).
> > - add new property 'brcm,scb-sizes'
> > - add new property 'resets'
> > - add new property 'reset-names'
> > - allow 'ranges' and 'dma-ranges' to have more than one item and update
> > the example to show this.
> >
> > Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> > ---
> > .../bindings/pci/brcm,stb-pcie.yaml | 40 +++++++++++++++++--
> > 1 file changed, 36 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > index 8680a0f86c5a..66a7df45983d 100644
> > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > @@ -14,7 +14,13 @@ allOf:
> >
> > properties:
> > compatible:
> > - const: brcm,bcm2711-pcie # The Raspberry Pi 4
> > + items:
> > + - enum:
>
> Don't need items here. Just change the const to enum.
>
> > + - brcm,bcm2711-pcie # The Raspberry Pi 4
> > + - brcm,bcm7211-pcie # Broadcom STB version of RPi4
> > + - brcm,bcm7278-pcie # Broadcom 7278 Arm
> > + - brcm,bcm7216-pcie # Broadcom 7216 Arm
> > + - brcm,bcm7445-pcie # Broadcom 7445 Arm
> >
> > reg:
> > maxItems: 1
> > @@ -34,10 +40,12 @@ properties:
> > - const: msi
> >
> > ranges:
> > - maxItems: 1
> > + minItems: 1
> > + maxItems: 4
> >
> > dma-ranges:
> > - maxItems: 1
> > + minItems: 1
> > + maxItems: 6
> >
> > clocks:
> > maxItems: 1
> > @@ -58,8 +66,30 @@ properties:
> >
> > aspm-no-l0s: true
> >
> > + resets:
> > + description: for "brcm,bcm7216-pcie", must be a valid reset
> > + phandle pointing to the RESCAL reset controller provider node.
> > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > +
> > + reset-names:
> > + items:
> > + - const: rescal
>
> These are going to need to be an if/then schema if they only apply to
> certain compatible(s).
Why is that -- the code is general enough to handle its presence or
not (it is an optional compatibility)>
>
>
> > +
> > + brcm,scb-sizes:
> > + description: (u32, u32) tuple giving the 64bit PCIe memory
> > + viewport size of a memory controller. There may be up to
> > + three controllers, and each size must be a power of two
> > + with a size greater or equal to the amount of memory the
> > + controller supports.
>
> This sounds like what dma-ranges should express?
There is some overlap but this contains information that is not in the
dma-ranges. Believe me I tried.
>
> If not, we do have 64-bit size if that what you need.
IIRC I tried the 64-bit size but the YAML validator did not like it;
it wanted numbers like <0x1122334455667788> while dtc wanted <
0x11223344 0x55667788>. I gave up trying and switched to u32.
Thanks,
Jim
>
>
> > + allOf:
> > + - $ref: /schemas/types.yaml#/definitions/uint32-array
> > + - items:
> > + minItems: 2
> > + maxItems: 6
> > +
> > required:
> > - reg
> > + - ranges
> > - dma-ranges
> > - "#interrupt-cells"
> > - interrupts
> > @@ -93,7 +123,9 @@ examples:
> > msi-parent = <&pcie0>;
> > msi-controller;
> > ranges = <0x02000000 0x0 0xf8000000 0x6 0x00000000 0x0 0x04000000>;
> > - dma-ranges = <0x02000000 0x0 0x00000000 0x0 0x00000000 0x0 0x80000000>;
> > + dma-ranges = <0x42000000 0x1 0x00000000 0x0 0x40000000 0x0 0x80000000>,
> > + <0x42000000 0x1 0x80000000 0x3 0x00000000 0x0 0x80000000>;
> > brcm,enable-ssc;
> > + brcm,scb-sizes = <0x0 0x80000000 0x0 0x80000000>;
> > };
> > };
> > --
> > 2.17.1
> >
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips
2020-06-02 20:53 ` Jim Quinlan
@ 2020-06-02 21:41 ` Rob Herring
2020-06-02 21:55 ` Jim Quinlan
0 siblings, 1 reply; 30+ messages in thread
From: Rob Herring @ 2020-06-02 21:41 UTC (permalink / raw)
To: Jim Quinlan
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, Nicolas Saenz Julienne,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Florian Fainelli,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
On Tue, Jun 2, 2020 at 2:53 PM Jim Quinlan <james.quinlan@broadcom.com> wrote:
>
> On Fri, May 29, 2020 at 1:46 PM Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, May 26, 2020 at 03:12:42PM -0400, Jim Quinlan wrote:
> > > From: Jim Quinlan <jquinlan@broadcom.com>
> > >
> > > - Add compatible strings for three more Broadcom STB chips: 7278, 7216,
> > > 7211 (STB version of RPi4).
> > > - add new property 'brcm,scb-sizes'
> > > - add new property 'resets'
> > > - add new property 'reset-names'
> > > - allow 'ranges' and 'dma-ranges' to have more than one item and update
> > > the example to show this.
> > >
> > > Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> > > ---
> > > .../bindings/pci/brcm,stb-pcie.yaml | 40 +++++++++++++++++--
> > > 1 file changed, 36 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > index 8680a0f86c5a..66a7df45983d 100644
> > > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > @@ -14,7 +14,13 @@ allOf:
> > >
> > > properties:
> > > compatible:
> > > - const: brcm,bcm2711-pcie # The Raspberry Pi 4
> > > + items:
> > > + - enum:
> >
> > Don't need items here. Just change the const to enum.
> >
> > > + - brcm,bcm2711-pcie # The Raspberry Pi 4
> > > + - brcm,bcm7211-pcie # Broadcom STB version of RPi4
> > > + - brcm,bcm7278-pcie # Broadcom 7278 Arm
> > > + - brcm,bcm7216-pcie # Broadcom 7216 Arm
> > > + - brcm,bcm7445-pcie # Broadcom 7445 Arm
> > >
> > > reg:
> > > maxItems: 1
> > > @@ -34,10 +40,12 @@ properties:
> > > - const: msi
> > >
> > > ranges:
> > > - maxItems: 1
> > > + minItems: 1
> > > + maxItems: 4
> > >
> > > dma-ranges:
> > > - maxItems: 1
> > > + minItems: 1
> > > + maxItems: 6
> > >
> > > clocks:
> > > maxItems: 1
> > > @@ -58,8 +66,30 @@ properties:
> > >
> > > aspm-no-l0s: true
> > >
> > > + resets:
> > > + description: for "brcm,bcm7216-pcie", must be a valid reset
> > > + phandle pointing to the RESCAL reset controller provider node.
> > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > +
> > > + reset-names:
> > > + items:
> > > + - const: rescal
> >
> > These are going to need to be an if/then schema if they only apply to
> > certain compatible(s).
>
> Why is that -- the code is general enough to handle its presence or
> not (it is an optional compatibility)>
Because an if/then schema expresses in a parse-able form what your
'description' does in free form text.
Presumably a 'resets' property for !brcm,bcm7216-pcie is invalid, so
we should check that. The schema shouldn't be just what some driver
happens to currently allow. Also, it's not a driver's job to validate
DT, so it shouldn't check any of this.
> > > + brcm,scb-sizes:
> > > + description: (u32, u32) tuple giving the 64bit PCIe memory
> > > + viewport size of a memory controller. There may be up to
> > > + three controllers, and each size must be a power of two
> > > + with a size greater or equal to the amount of memory the
> > > + controller supports.
> >
> > This sounds like what dma-ranges should express?
>
> There is some overlap but this contains information that is not in the
> dma-ranges. Believe me I tried.
I don't understand. If you had 3 dma-ranges entries, you'd have 3
sizes. Can you expand or show me what you tried?
> > If not, we do have 64-bit size if that what you need.
>
> IIRC I tried the 64-bit size but the YAML validator did not like it;
> it wanted numbers like <0x1122334455667788> while dtc wanted <
> 0x11223344 0x55667788>. I gave up trying and switched to u32.
You used the /bits/ annotation for dtc?:
/bits/ 64 <0x1122334455667788>
I also made a recent fix to dt-schema around handling of 64-bit sizes,
so update if you have problems still.
Rob
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips
2020-06-02 21:41 ` Rob Herring
@ 2020-06-02 21:55 ` Jim Quinlan
0 siblings, 0 replies; 30+ messages in thread
From: Jim Quinlan @ 2020-06-02 21:55 UTC (permalink / raw)
To: Rob Herring
Cc: open list:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS,
Christoph Hellwig, Nicolas Saenz Julienne,
maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE, Florian Fainelli,
Bjorn Helgaas,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
On Tue, Jun 2, 2020 at 5:41 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Jun 2, 2020 at 2:53 PM Jim Quinlan <james.quinlan@broadcom.com> wrote:
> >
> > On Fri, May 29, 2020 at 1:46 PM Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Tue, May 26, 2020 at 03:12:42PM -0400, Jim Quinlan wrote:
> > > > From: Jim Quinlan <jquinlan@broadcom.com>
> > > >
> > > > - Add compatible strings for three more Broadcom STB chips: 7278, 7216,
> > > > 7211 (STB version of RPi4).
> > > > - add new property 'brcm,scb-sizes'
> > > > - add new property 'resets'
> > > > - add new property 'reset-names'
> > > > - allow 'ranges' and 'dma-ranges' to have more than one item and update
> > > > the example to show this.
> > > >
> > > > Signed-off-by: Jim Quinlan <jquinlan@broadcom.com>
> > > > ---
> > > > .../bindings/pci/brcm,stb-pcie.yaml | 40 +++++++++++++++++--
> > > > 1 file changed, 36 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > > index 8680a0f86c5a..66a7df45983d 100644
> > > > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > > > @@ -14,7 +14,13 @@ allOf:
> > > >
> > > > properties:
> > > > compatible:
> > > > - const: brcm,bcm2711-pcie # The Raspberry Pi 4
> > > > + items:
> > > > + - enum:
> > >
> > > Don't need items here. Just change the const to enum.
> > >
> > > > + - brcm,bcm2711-pcie # The Raspberry Pi 4
> > > > + - brcm,bcm7211-pcie # Broadcom STB version of RPi4
> > > > + - brcm,bcm7278-pcie # Broadcom 7278 Arm
> > > > + - brcm,bcm7216-pcie # Broadcom 7216 Arm
> > > > + - brcm,bcm7445-pcie # Broadcom 7445 Arm
> > > >
> > > > reg:
> > > > maxItems: 1
> > > > @@ -34,10 +40,12 @@ properties:
> > > > - const: msi
> > > >
> > > > ranges:
> > > > - maxItems: 1
> > > > + minItems: 1
> > > > + maxItems: 4
> > > >
> > > > dma-ranges:
> > > > - maxItems: 1
> > > > + minItems: 1
> > > > + maxItems: 6
> > > >
> > > > clocks:
> > > > maxItems: 1
> > > > @@ -58,8 +66,30 @@ properties:
> > > >
> > > > aspm-no-l0s: true
> > > >
> > > > + resets:
> > > > + description: for "brcm,bcm7216-pcie", must be a valid reset
> > > > + phandle pointing to the RESCAL reset controller provider node.
> > > > + $ref: "/schemas/types.yaml#/definitions/phandle"
> > > > +
> > > > + reset-names:
> > > > + items:
> > > > + - const: rescal
> > >
> > > These are going to need to be an if/then schema if they only apply to
> > > certain compatible(s).
> >
> > Why is that -- the code is general enough to handle its presence or
> > not (it is an optional compatibility)>
>
> Because an if/then schema expresses in a parse-able form what your
> 'description' does in free form text.
>
> Presumably a 'resets' property for !brcm,bcm7216-pcie is invalid, so
> we should check that. The schema shouldn't be just what some driver
> happens to currently allow. Also, it's not a driver's job to validate
> DT, so it shouldn't check any of this.
Got it, will fix.
>
> > > > + brcm,scb-sizes:
> > > > + description: (u32, u32) tuple giving the 64bit PCIe memory
> > > > + viewport size of a memory controller. There may be up to
> > > > + three controllers, and each size must be a power of two
> > > > + with a size greater or equal to the amount of memory the
> > > > + controller supports.
> > >
> > > This sounds like what dma-ranges should express?
> >
> > There is some overlap but this contains information that is not in the
> > dma-ranges. Believe me I tried.
>
> I don't understand. If you had 3 dma-ranges entries, you'd have 3
> sizes. Can you expand or show me what you tried?
Here is a simple example: suppose you have two dma-ranges. This could
be from one of two cases:
- Both dma-ranges are from the same memory controller (the second
range is the "extended" region).
- One dma-range can be from memc0 and the other can be from memc1; the
extensions are not used.
The driver has to determine (a) how many memory controllers there are
and (b) what the size should be for each of them. It is impossible to
do this with the case above.
>
> > > If not, we do have 64-bit size if that what you need.
> >
> > IIRC I tried the 64-bit size but the YAML validator did not like it;
> > it wanted numbers like <0x1122334455667788> while dtc wanted <
> > 0x11223344 0x55667788>. I gave up trying and switched to u32.
>
> You used the /bits/ annotation for dtc?:
>
> /bits/ 64 <0x1122334455667788>
>
> I also made a recent fix to dt-schema around handling of 64-bit sizes,
> so update if you have problems still.
I didn't try the /bits/ so I'll pursue this.
Thanks,
Jim
>
> Rob
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2020-06-02 21:56 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-26 19:12 [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 01/14] PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB Jim Quinlan
2020-06-01 21:44 ` Rob Herring
2020-05-26 19:12 ` [PATCH v2 02/14] ata: ahci_brcm: Fix use of BCM7216 reset controller Jim Quinlan
2020-05-27 23:57 ` Florian Fainelli
2020-05-26 19:12 ` [PATCH v2 03/14] dt-bindings: PCI: Add bindings for more Brcmstb chips Jim Quinlan
2020-05-29 17:46 ` Rob Herring
2020-06-02 20:53 ` Jim Quinlan
2020-06-02 21:41 ` Rob Herring
2020-06-02 21:55 ` Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 04/14] PCI: brcmstb: Add bcm7278 reigister info Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 05/14] PCI: brcmstb: Add suspend and resume pm_ops Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 06/14] PCI: brcmstb: Add bcm7278 PERST support Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 07/14] PCI: brcmstb: Add control of rescal reset Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 08/14] of: Include a dev param in of_dma_get_range() Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 09/14] device core: Add ability to handle multiple dma offsets Jim Quinlan
2020-05-26 20:54 ` Andy Shevchenko
2020-05-26 22:01 ` Jim Quinlan
2020-05-27 15:00 ` Nicolas Saenz Julienne
2020-05-27 15:43 ` Jim Quinlan
2020-05-27 17:01 ` Nicolas Saenz Julienne
2020-05-29 17:34 ` Rob Herring
2020-05-29 17:51 ` Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 10/14] arm: dma-mapping: Invoke dma offset func if needed Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 11/14] PCI: brcmstb: Set internal memory viewport sizes Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 12/14] PCI: brcmstb: Accommodate MSI for older chips Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 13/14] PCI: brcmstb: Set bus max burst size by chip type Jim Quinlan
2020-05-26 19:12 ` [PATCH v2 14/14] PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list Jim Quinlan
2020-05-29 17:48 ` [PATCH v2 00/14] PCI: brcmstb: enable PCIe for STB chips Rob Herring
2020-05-29 17:55 ` Jim Quinlan
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).