[PATCH 0/2] PCI: mvebu: add support for orion soc

[PATCH 0/2] PCI: mvebu: add support for orion soc

[Mauri Sandberg]

Hello all!

Working in close co-operation with Pali we made an initial attempt at bringing
support for orion PCIe into mvebu PCIe driver. Currently the address of
workaround memory range is hard coded and based on compatible string only. As
Pali describes in another thread, we were not able to figure out what's the
correct way to configure a configuration space. That discussion is here:
https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/T/#u

I tested this with D-Link DNS-323 rev A1 and it's working. As usual, all
comments and feedback is welcome.

Thanks,
Mauri

Mauri Sandberg (2):
  dt-bindings: PCI: mvebu: Add orion5x compatible
  PCI: mvebu: add support for orion5x

 .../devicetree/bindings/pci/mvebu-pci.txt     |  1 +
 arch/arm/mach-orion5x/common.c                | 13 ----
 drivers/pci/controller/Kconfig                |  2 +-
 drivers/pci/controller/pci-mvebu.c            | 59 +++++++++++++++++++
 4 files changed, 61 insertions(+), 14 deletions(-)


base-commit: ff6992735ade75aae3e35d16b17da1008d753d28
--
2.25.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 0/2] PCI: mvebu: add support for orion soc

[Mauri Sandberg]

Hello all!

Working in close co-operation with Pali we made an initial attempt at bringing
support for orion PCIe into mvebu PCIe driver. Currently the address of
workaround memory range is hard coded and based on compatible string only. As
Pali describes in another thread, we were not able to figure out what's the
correct way to configure a configuration space. That discussion is here:
https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/T/#u

I tested this with D-Link DNS-323 rev A1 and it's working. As usual, all
comments and feedback is welcome.

Thanks,
Mauri

Mauri Sandberg (2):
  dt-bindings: PCI: mvebu: Add orion5x compatible
  PCI: mvebu: add support for orion5x

 .../devicetree/bindings/pci/mvebu-pci.txt     |  1 +
 arch/arm/mach-orion5x/common.c                | 13 ----
 drivers/pci/controller/Kconfig                |  2 +-
 drivers/pci/controller/pci-mvebu.c            | 59 +++++++++++++++++++
 4 files changed, 61 insertions(+), 14 deletions(-)


base-commit: ff6992735ade75aae3e35d16b17da1008d753d28
--
2.25.1

[PATCH 1/2] dt-bindings: PCI: mvebu: Add orion5x compatible

[Mauri Sandberg]

Add a compatible string to bindings to indicate that orion5x PCIe is
supported too.

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
---
 Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 6d022a9d36ee..ced5d030fe55 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -7,6 +7,7 @@ Mandatory properties:
     marvell,armada-xp-pcie
     marvell,dove-pcie
     marvell,kirkwood-pcie
+    marvell,orion5x-pcie
 - #address-cells, set to <3>
 - #size-cells, set to <2>
 - #interrupt-cells, set to <1>
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/2] dt-bindings: PCI: mvebu: Add orion5x compatible

[Mauri Sandberg]

Add a compatible string to bindings to indicate that orion5x PCIe is
supported too.

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
---
 Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 6d022a9d36ee..ced5d030fe55 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -7,6 +7,7 @@ Mandatory properties:
     marvell,armada-xp-pcie
     marvell,dove-pcie
     marvell,kirkwood-pcie
+    marvell,orion5x-pcie
 - #address-cells, set to <3>
 - #size-cells, set to <2>
 - #interrupt-cells, set to <1>
-- 
2.25.1

[PATCH 1/6] dt-bindings: PCI: mvebu: Add orion compatible

[Mauri Sandberg]

Add a compatible string to bindings to indicate that orion5x PCIe is
supported too.

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
---
 Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 6d022a9d36ee..ced5d030fe55 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -7,6 +7,7 @@ Mandatory properties:
     marvell,armada-xp-pcie
     marvell,dove-pcie
     marvell,kirkwood-pcie
+    marvell,orion5x-pcie
 - #address-cells, set to <3>
 - #size-cells, set to <2>
 - #interrupt-cells, set to <1>
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/6] dt-bindings: PCI: mvebu: Add orion compatible

[Mauri Sandberg]

Add a compatible string to bindings to indicate that orion5x PCIe is
supported too.

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
---
 Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 6d022a9d36ee..ced5d030fe55 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -7,6 +7,7 @@ Mandatory properties:
     marvell,armada-xp-pcie
     marvell,dove-pcie
     marvell,kirkwood-pcie
+    marvell,orion5x-pcie
 - #address-cells, set to <3>
 - #size-cells, set to <2>
 - #interrupt-cells, set to <1>
-- 
2.25.1

[PATCH 2/2] PCI: mvebu: add support for orion5x

[Mauri Sandberg]

Add support for orion5x PCIe controller.

There is Orion-specific errata that config space via CF8/CFC registers
is broken. Workaround documented in errata documented (linked from above
documentation) does not work when DMA is used and instead other
undocumented workaround is needed which maps config space to memory
(and therefore avoids usage of broken CF8/CFC memory mapped registers).

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
Cc: Pali Rohár <pali@kernel.org>
---
 arch/arm/mach-orion5x/common.c     | 13 -------
 drivers/pci/controller/Kconfig     |  2 +-
 drivers/pci/controller/pci-mvebu.c | 59 ++++++++++++++++++++++++++++++
 3 files changed, 60 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index 7bcb41137bbf..9d8be5ce1266 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -231,19 +231,6 @@ void __init orion5x_init_early(void)
 
 void orion5x_setup_wins(void)
 {
-	/*
-	 * The PCIe windows will no longer be statically allocated
-	 * here once Orion5x is migrated to the pci-mvebu driver.
-	 */
-	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
-					  ORION_MBUS_PCIE_IO_ATTR,
-					  ORION5X_PCIE_IO_PHYS_BASE,
-					  ORION5X_PCIE_IO_SIZE,
-					  ORION5X_PCIE_IO_BUS_BASE);
-	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
-				    ORION_MBUS_PCIE_MEM_ATTR,
-				    ORION5X_PCIE_MEM_PHYS_BASE,
-				    ORION5X_PCIE_MEM_SIZE);
 	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
 					  ORION_MBUS_PCI_IO_ATTR,
 					  ORION5X_PCI_IO_PHYS_BASE,
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index b8d96d38064d..a249375837f0 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -5,7 +5,7 @@ menu "PCI controller drivers"
 
 config PCI_MVEBU
 	tristate "Marvell EBU PCIe controller"
-	depends on ARCH_MVEBU || ARCH_DOVE || COMPILE_TEST
+	depends on ARCH_MVEBU || ARCH_DOVE || ARCH_ORION5X || COMPILE_TEST
 	depends on MVEBU_MBUS
 	depends on ARM
 	depends on OF
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index c1ffdb06c971..1d3052aa7e49 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -1487,6 +1487,54 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie)
 	return 0;
 }
 
+static int orion_pcie_rd_conf_wa(void __iomem *wa_base, struct pci_bus *bus,
+			  u32 devfn, int where, int size, u32 *val)
+{
+	*val = readl(wa_base + (PCIE_CONF_BUS(bus->number) |
+				PCIE_CONF_DEV(PCI_SLOT(devfn)) |
+				PCIE_CONF_FUNC(PCI_FUNC(devfn)) |
+				PCIE_CONF_REG(where)));
+
+	if (size == 1)
+		*val = (*val >> (8 * (where & 3))) & 0xff;
+	else if (size == 2)
+		*val = (*val >> (8 * (where & 3))) & 0xffff;
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+/* Relevant only for Orion-1/Orion-NAS */
+#define ORION5X_PCIE_WA_PHYS_BASE	0xf0000000
+#define ORION5X_PCIE_WA_VIRT_BASE	IOMEM(0xfd000000)
+#define ORION5X_PCIE_WA_SIZE		SZ_16M
+#define ORION_MBUS_PCIE_WA_TARGET	0x04
+#define ORION_MBUS_PCIE_WA_ATTR		0x79
+
+static int mvebu_pcie_child_rd_conf_wa(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val)
+{
+	struct mvebu_pcie *pcie = bus->sysdata;
+	struct mvebu_pcie_port *port;
+
+	port = mvebu_pcie_find_port(pcie, bus, devfn);
+	if (!port)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	if (!mvebu_pcie_link_up(port))
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	/*
+	 * We only support access to the non-extended configuration
+	 * space when using the WA access method (or we would have to
+	 * sacrifice 256M of CPU virtual address space.)
+	 */
+	if (where >= 0x100) {
+		*val = 0xffffffff;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	return orion_pcie_rd_conf_wa(ORION5X_PCIE_WA_VIRT_BASE, bus, devfn, where, size, val);
+}
+
 static int mvebu_pcie_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1663,6 +1711,16 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 	bridge->align_resource = mvebu_pcie_align_resource;
 	bridge->map_irq = mvebu_pcie_map_irq;
 
+	if (of_machine_is_compatible("marvell,orion5x-88f5181")) {
+		dev_info(dev, "Applying Orion-1/Orion-NAS PCIe config read transaction workaround\n");
+
+		mvebu_pcie_child_ops.read = mvebu_pcie_child_rd_conf_wa;
+		mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_WA_TARGET,
+					    ORION_MBUS_PCIE_WA_ATTR,
+					    ORION5X_PCIE_WA_PHYS_BASE,
+					    ORION5X_PCIE_WA_SIZE);
+	}
+
 	return pci_host_probe(bridge);
 }
 
@@ -1733,6 +1791,7 @@ static const struct of_device_id mvebu_pcie_of_match_table[] = {
 	{ .compatible = "marvell,armada-370-pcie", },
 	{ .compatible = "marvell,dove-pcie", },
 	{ .compatible = "marvell,kirkwood-pcie", },
+	{ .compatible = "marvell,orion5x-pcie", },
 	{},
 };
 
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/2] PCI: mvebu: add support for orion5x

[Mauri Sandberg]

Add support for orion5x PCIe controller.

There is Orion-specific errata that config space via CF8/CFC registers
is broken. Workaround documented in errata documented (linked from above
documentation) does not work when DMA is used and instead other
undocumented workaround is needed which maps config space to memory
(and therefore avoids usage of broken CF8/CFC memory mapped registers).

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
Cc: Pali Rohár <pali@kernel.org>
---
 arch/arm/mach-orion5x/common.c     | 13 -------
 drivers/pci/controller/Kconfig     |  2 +-
 drivers/pci/controller/pci-mvebu.c | 59 ++++++++++++++++++++++++++++++
 3 files changed, 60 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index 7bcb41137bbf..9d8be5ce1266 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -231,19 +231,6 @@ void __init orion5x_init_early(void)
 
 void orion5x_setup_wins(void)
 {
-	/*
-	 * The PCIe windows will no longer be statically allocated
-	 * here once Orion5x is migrated to the pci-mvebu driver.
-	 */
-	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
-					  ORION_MBUS_PCIE_IO_ATTR,
-					  ORION5X_PCIE_IO_PHYS_BASE,
-					  ORION5X_PCIE_IO_SIZE,
-					  ORION5X_PCIE_IO_BUS_BASE);
-	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
-				    ORION_MBUS_PCIE_MEM_ATTR,
-				    ORION5X_PCIE_MEM_PHYS_BASE,
-				    ORION5X_PCIE_MEM_SIZE);
 	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
 					  ORION_MBUS_PCI_IO_ATTR,
 					  ORION5X_PCI_IO_PHYS_BASE,
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index b8d96d38064d..a249375837f0 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -5,7 +5,7 @@ menu "PCI controller drivers"
 
 config PCI_MVEBU
 	tristate "Marvell EBU PCIe controller"
-	depends on ARCH_MVEBU || ARCH_DOVE || COMPILE_TEST
+	depends on ARCH_MVEBU || ARCH_DOVE || ARCH_ORION5X || COMPILE_TEST
 	depends on MVEBU_MBUS
 	depends on ARM
 	depends on OF
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index c1ffdb06c971..1d3052aa7e49 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -1487,6 +1487,54 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie)
 	return 0;
 }
 
+static int orion_pcie_rd_conf_wa(void __iomem *wa_base, struct pci_bus *bus,
+			  u32 devfn, int where, int size, u32 *val)
+{
+	*val = readl(wa_base + (PCIE_CONF_BUS(bus->number) |
+				PCIE_CONF_DEV(PCI_SLOT(devfn)) |
+				PCIE_CONF_FUNC(PCI_FUNC(devfn)) |
+				PCIE_CONF_REG(where)));
+
+	if (size == 1)
+		*val = (*val >> (8 * (where & 3))) & 0xff;
+	else if (size == 2)
+		*val = (*val >> (8 * (where & 3))) & 0xffff;
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+/* Relevant only for Orion-1/Orion-NAS */
+#define ORION5X_PCIE_WA_PHYS_BASE	0xf0000000
+#define ORION5X_PCIE_WA_VIRT_BASE	IOMEM(0xfd000000)
+#define ORION5X_PCIE_WA_SIZE		SZ_16M
+#define ORION_MBUS_PCIE_WA_TARGET	0x04
+#define ORION_MBUS_PCIE_WA_ATTR		0x79
+
+static int mvebu_pcie_child_rd_conf_wa(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val)
+{
+	struct mvebu_pcie *pcie = bus->sysdata;
+	struct mvebu_pcie_port *port;
+
+	port = mvebu_pcie_find_port(pcie, bus, devfn);
+	if (!port)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	if (!mvebu_pcie_link_up(port))
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	/*
+	 * We only support access to the non-extended configuration
+	 * space when using the WA access method (or we would have to
+	 * sacrifice 256M of CPU virtual address space.)
+	 */
+	if (where >= 0x100) {
+		*val = 0xffffffff;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	return orion_pcie_rd_conf_wa(ORION5X_PCIE_WA_VIRT_BASE, bus, devfn, where, size, val);
+}
+
 static int mvebu_pcie_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1663,6 +1711,16 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 	bridge->align_resource = mvebu_pcie_align_resource;
 	bridge->map_irq = mvebu_pcie_map_irq;
 
+	if (of_machine_is_compatible("marvell,orion5x-88f5181")) {
+		dev_info(dev, "Applying Orion-1/Orion-NAS PCIe config read transaction workaround\n");
+
+		mvebu_pcie_child_ops.read = mvebu_pcie_child_rd_conf_wa;
+		mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_WA_TARGET,
+					    ORION_MBUS_PCIE_WA_ATTR,
+					    ORION5X_PCIE_WA_PHYS_BASE,
+					    ORION5X_PCIE_WA_SIZE);
+	}
+
 	return pci_host_probe(bridge);
 }
 
@@ -1733,6 +1791,7 @@ static const struct of_device_id mvebu_pcie_of_match_table[] = {
 	{ .compatible = "marvell,armada-370-pcie", },
 	{ .compatible = "marvell,dove-pcie", },
 	{ .compatible = "marvell,kirkwood-pcie", },
+	{ .compatible = "marvell,orion5x-pcie", },
 	{},
 };
 
-- 
2.25.1

Re: [PATCH 1/6] dt-bindings: PCI: mvebu: Add orion compatible

[Mauri Sandberg]

This one is include in the set by a mistake, please ignore it.
Apologies.

On 18.07.22 23:28, Mauri Sandberg wrote:
> Add a compatible string to bindings to indicate that orion5x PCIe is
> supported too.
> 
> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> ---
>   Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> index 6d022a9d36ee..ced5d030fe55 100644
> --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> @@ -7,6 +7,7 @@ Mandatory properties:
>       marvell,armada-xp-pcie
>       marvell,dove-pcie
>       marvell,kirkwood-pcie
> +    marvell,orion5x-pcie
>   - #address-cells, set to <3>
>   - #size-cells, set to <2>
>   - #interrupt-cells, set to <1>

Re: [PATCH 1/6] dt-bindings: PCI: mvebu: Add orion compatible

[Mauri Sandberg]

This one is include in the set by a mistake, please ignore it.
Apologies.

On 18.07.22 23:28, Mauri Sandberg wrote:
> Add a compatible string to bindings to indicate that orion5x PCIe is
> supported too.
> 
> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> ---
>   Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> index 6d022a9d36ee..ced5d030fe55 100644
> --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
> @@ -7,6 +7,7 @@ Mandatory properties:
>       marvell,armada-xp-pcie
>       marvell,dove-pcie
>       marvell,kirkwood-pcie
> +    marvell,orion5x-pcie
>   - #address-cells, set to <3>
>   - #size-cells, set to <2>
>   - #interrupt-cells, set to <1>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Arnd Bergmann]

On Mon, Jul 18, 2022 at 10:28 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>
> Add support for orion5x PCIe controller.
>
> There is Orion-specific errata that config space via CF8/CFC registers
> is broken. Workaround documented in errata documented (linked from above
> documentation) does not work when DMA is used and instead other
> undocumented workaround is needed which maps config space to memory
> (and therefore avoids usage of broken CF8/CFC memory mapped registers).
>
> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> Cc: Pali Rohár <pali@kernel.org>

Nice job, glad you managed to figure this out!

> diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
> index 7bcb41137bbf..9d8be5ce1266 100644
> --- a/arch/arm/mach-orion5x/common.c
> +++ b/arch/arm/mach-orion5x/common.c
> @@ -231,19 +231,6 @@ void __init orion5x_init_early(void)
>
>  void orion5x_setup_wins(void)
>  {
> -       /*
> -        * The PCIe windows will no longer be statically allocated
> -        * here once Orion5x is migrated to the pci-mvebu driver.
> -        */
> -       mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
> -                                         ORION_MBUS_PCIE_IO_ATTR,
> -                                         ORION5X_PCIE_IO_PHYS_BASE,
> -                                         ORION5X_PCIE_IO_SIZE,
> -                                         ORION5X_PCIE_IO_BUS_BASE);
> -       mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
> -                                   ORION_MBUS_PCIE_MEM_ATTR,
> -                                   ORION5X_PCIE_MEM_PHYS_BASE,
> -                                   ORION5X_PCIE_MEM_SIZE);
>         mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
>                                           ORION_MBUS_PCI_IO_ATTR,
>                                           ORION5X_PCI_IO_PHYS_BASE,

If the idea is to have the PCI_MVEBU driver only used for the DT based orion5x
machines, but not the legacy board files, I suspect this breaks the legacy
pci driver, unless you move the mbus configuration into the pcie_setup()
function.

> +/* Relevant only for Orion-1/Orion-NAS */
> +#define ORION5X_PCIE_WA_PHYS_BASE      0xf0000000
> +#define ORION5X_PCIE_WA_VIRT_BASE      IOMEM(0xfd000000)

You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE
should already be part of the DT binding. There is little practical difference
here, but I see no value in taking the shortcut here either.

For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the
definition in arch/arm/mach-orion5x/common.c, and this is rather fragile.

Instead, please use ioremap() to create a mapping at runtime. The ioremap()
implementation on ARM is smart enough to reuse the address from the static
mapping in common.c, but will also keep working if that should go away.

> +#define ORION5X_PCIE_WA_SIZE           SZ_16M
> +#define ORION_MBUS_PCIE_WA_TARGET      0x04
> +#define ORION_MBUS_PCIE_WA_ATTR                0x79
> +
> +static int mvebu_pcie_child_rd_conf_wa(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val)
> +{
> +       struct mvebu_pcie *pcie = bus->sysdata;
> +       struct mvebu_pcie_port *port;
> +
> +       port = mvebu_pcie_find_port(pcie, bus, devfn);
> +       if (!port)
> +               return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +       if (!mvebu_pcie_link_up(port))
> +               return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +       /*
> +        * We only support access to the non-extended configuration
> +        * space when using the WA access method (or we would have to
> +        * sacrifice 256M of CPU virtual address space.)
> +        */
> +       if (where >= 0x100) {
> +               *val = 0xffffffff;
> +               return PCIBIOS_DEVICE_NOT_FOUND;
> +       }
> +
> +       return orion_pcie_rd_conf_wa(ORION5X_PCIE_WA_VIRT_BASE, bus, devfn, where, size, val);
> +}
> +

This is probably good enough here, though I think you could also use
the trick from drivers/pci/ecam.c and map each bus at a time.

      Arnd

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Arnd Bergmann]

On Mon, Jul 18, 2022 at 10:28 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>
> Add support for orion5x PCIe controller.
>
> There is Orion-specific errata that config space via CF8/CFC registers
> is broken. Workaround documented in errata documented (linked from above
> documentation) does not work when DMA is used and instead other
> undocumented workaround is needed which maps config space to memory
> (and therefore avoids usage of broken CF8/CFC memory mapped registers).
>
> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> Cc: Pali Rohár <pali@kernel.org>

Nice job, glad you managed to figure this out!

> diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
> index 7bcb41137bbf..9d8be5ce1266 100644
> --- a/arch/arm/mach-orion5x/common.c
> +++ b/arch/arm/mach-orion5x/common.c
> @@ -231,19 +231,6 @@ void __init orion5x_init_early(void)
>
>  void orion5x_setup_wins(void)
>  {
> -       /*
> -        * The PCIe windows will no longer be statically allocated
> -        * here once Orion5x is migrated to the pci-mvebu driver.
> -        */
> -       mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
> -                                         ORION_MBUS_PCIE_IO_ATTR,
> -                                         ORION5X_PCIE_IO_PHYS_BASE,
> -                                         ORION5X_PCIE_IO_SIZE,
> -                                         ORION5X_PCIE_IO_BUS_BASE);
> -       mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
> -                                   ORION_MBUS_PCIE_MEM_ATTR,
> -                                   ORION5X_PCIE_MEM_PHYS_BASE,
> -                                   ORION5X_PCIE_MEM_SIZE);
>         mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
>                                           ORION_MBUS_PCI_IO_ATTR,
>                                           ORION5X_PCI_IO_PHYS_BASE,

If the idea is to have the PCI_MVEBU driver only used for the DT based orion5x
machines, but not the legacy board files, I suspect this breaks the legacy
pci driver, unless you move the mbus configuration into the pcie_setup()
function.

> +/* Relevant only for Orion-1/Orion-NAS */
> +#define ORION5X_PCIE_WA_PHYS_BASE      0xf0000000
> +#define ORION5X_PCIE_WA_VIRT_BASE      IOMEM(0xfd000000)

You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE
should already be part of the DT binding. There is little practical difference
here, but I see no value in taking the shortcut here either.

For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the
definition in arch/arm/mach-orion5x/common.c, and this is rather fragile.

Instead, please use ioremap() to create a mapping at runtime. The ioremap()
implementation on ARM is smart enough to reuse the address from the static
mapping in common.c, but will also keep working if that should go away.

> +#define ORION5X_PCIE_WA_SIZE           SZ_16M
> +#define ORION_MBUS_PCIE_WA_TARGET      0x04
> +#define ORION_MBUS_PCIE_WA_ATTR                0x79
> +
> +static int mvebu_pcie_child_rd_conf_wa(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val)
> +{
> +       struct mvebu_pcie *pcie = bus->sysdata;
> +       struct mvebu_pcie_port *port;
> +
> +       port = mvebu_pcie_find_port(pcie, bus, devfn);
> +       if (!port)
> +               return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +       if (!mvebu_pcie_link_up(port))
> +               return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +       /*
> +        * We only support access to the non-extended configuration
> +        * space when using the WA access method (or we would have to
> +        * sacrifice 256M of CPU virtual address space.)
> +        */
> +       if (where >= 0x100) {
> +               *val = 0xffffffff;
> +               return PCIBIOS_DEVICE_NOT_FOUND;
> +       }
> +
> +       return orion_pcie_rd_conf_wa(ORION5X_PCIE_WA_VIRT_BASE, bus, devfn, where, size, val);
> +}
> +

This is probably good enough here, though I think you could also use
the trick from drivers/pci/ecam.c and map each bus at a time.

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Pali Rohár]

Hello!

On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote:
> On Mon, Jul 18, 2022 at 10:28 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> >
> > Add support for orion5x PCIe controller.
> >
> > There is Orion-specific errata that config space via CF8/CFC registers
> > is broken. Workaround documented in errata documented (linked from above
> > documentation) does not work when DMA is used and instead other
> > undocumented workaround is needed which maps config space to memory
> > (and therefore avoids usage of broken CF8/CFC memory mapped registers).
> >
> > Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> > Cc: Pali Rohár <pali@kernel.org>
> 
> Nice job, glad you managed to figure this out!
> 
> > diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
> > index 7bcb41137bbf..9d8be5ce1266 100644
> > --- a/arch/arm/mach-orion5x/common.c
> > +++ b/arch/arm/mach-orion5x/common.c
> > @@ -231,19 +231,6 @@ void __init orion5x_init_early(void)
> >
> >  void orion5x_setup_wins(void)
> >  {
> > -       /*
> > -        * The PCIe windows will no longer be statically allocated
> > -        * here once Orion5x is migrated to the pci-mvebu driver.
> > -        */
> > -       mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
> > -                                         ORION_MBUS_PCIE_IO_ATTR,
> > -                                         ORION5X_PCIE_IO_PHYS_BASE,
> > -                                         ORION5X_PCIE_IO_SIZE,
> > -                                         ORION5X_PCIE_IO_BUS_BASE);
> > -       mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
> > -                                   ORION_MBUS_PCIE_MEM_ATTR,
> > -                                   ORION5X_PCIE_MEM_PHYS_BASE,
> > -                                   ORION5X_PCIE_MEM_SIZE);
> >         mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
> >                                           ORION_MBUS_PCI_IO_ATTR,
> >                                           ORION5X_PCI_IO_PHYS_BASE,
> 
> If the idea is to have the PCI_MVEBU driver only used for the DT based orion5x
> machines, but not the legacy board files, I suspect this breaks the legacy
> pci driver, unless you move the mbus configuration into the pcie_setup()
> function.
> 
> > +/* Relevant only for Orion-1/Orion-NAS */
> > +#define ORION5X_PCIE_WA_PHYS_BASE      0xf0000000
> > +#define ORION5X_PCIE_WA_VIRT_BASE      IOMEM(0xfd000000)
> 
> You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE
> should already be part of the DT binding.

Of course! But the issue is that we do not know how to do this DT
binding. I have already wrote email with asking for help in which
property and which format should be this config range defined, but no
answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/

> There is little practical difference
> here, but I see no value in taking the shortcut here either.
> 
> For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the
> definition in arch/arm/mach-orion5x/common.c, and this is rather fragile.
> 
> Instead, please use ioremap() to create a mapping at runtime. The ioremap()
> implementation on ARM is smart enough to reuse the address from the static
> mapping in common.c, but will also keep working if that should go away.

I'm planning to work with Mauri on this, but current blocker is DT.

> > +#define ORION5X_PCIE_WA_SIZE           SZ_16M
> > +#define ORION_MBUS_PCIE_WA_TARGET      0x04
> > +#define ORION_MBUS_PCIE_WA_ATTR                0x79
> > +
> > +static int mvebu_pcie_child_rd_conf_wa(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val)
> > +{
> > +       struct mvebu_pcie *pcie = bus->sysdata;
> > +       struct mvebu_pcie_port *port;
> > +
> > +       port = mvebu_pcie_find_port(pcie, bus, devfn);
> > +       if (!port)
> > +               return PCIBIOS_DEVICE_NOT_FOUND;
> > +
> > +       if (!mvebu_pcie_link_up(port))
> > +               return PCIBIOS_DEVICE_NOT_FOUND;
> > +
> > +       /*
> > +        * We only support access to the non-extended configuration
> > +        * space when using the WA access method (or we would have to
> > +        * sacrifice 256M of CPU virtual address space.)
> > +        */
> > +       if (where >= 0x100) {
> > +               *val = 0xffffffff;
> > +               return PCIBIOS_DEVICE_NOT_FOUND;
> > +       }
> > +
> > +       return orion_pcie_rd_conf_wa(ORION5X_PCIE_WA_VIRT_BASE, bus, devfn, where, size, val);
> > +}
> > +
> 
> This is probably good enough here, though I think you could also use
> the trick from drivers/pci/ecam.c and map each bus at a time.
> 
>       Arnd

Yes, there are also helper functions like map bus and etc. which could
simplify this code. I'm planning to do cleanups once we have fully
working driver for Orion.

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Pali Rohár]

Hello!

On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote:
> On Mon, Jul 18, 2022 at 10:28 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
> >
> > Add support for orion5x PCIe controller.
> >
> > There is Orion-specific errata that config space via CF8/CFC registers
> > is broken. Workaround documented in errata documented (linked from above
> > documentation) does not work when DMA is used and instead other
> > undocumented workaround is needed which maps config space to memory
> > (and therefore avoids usage of broken CF8/CFC memory mapped registers).
> >
> > Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> > Cc: Pali Rohár <pali@kernel.org>
> 
> Nice job, glad you managed to figure this out!
> 
> > diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
> > index 7bcb41137bbf..9d8be5ce1266 100644
> > --- a/arch/arm/mach-orion5x/common.c
> > +++ b/arch/arm/mach-orion5x/common.c
> > @@ -231,19 +231,6 @@ void __init orion5x_init_early(void)
> >
> >  void orion5x_setup_wins(void)
> >  {
> > -       /*
> > -        * The PCIe windows will no longer be statically allocated
> > -        * here once Orion5x is migrated to the pci-mvebu driver.
> > -        */
> > -       mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
> > -                                         ORION_MBUS_PCIE_IO_ATTR,
> > -                                         ORION5X_PCIE_IO_PHYS_BASE,
> > -                                         ORION5X_PCIE_IO_SIZE,
> > -                                         ORION5X_PCIE_IO_BUS_BASE);
> > -       mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
> > -                                   ORION_MBUS_PCIE_MEM_ATTR,
> > -                                   ORION5X_PCIE_MEM_PHYS_BASE,
> > -                                   ORION5X_PCIE_MEM_SIZE);
> >         mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
> >                                           ORION_MBUS_PCI_IO_ATTR,
> >                                           ORION5X_PCI_IO_PHYS_BASE,
> 
> If the idea is to have the PCI_MVEBU driver only used for the DT based orion5x
> machines, but not the legacy board files, I suspect this breaks the legacy
> pci driver, unless you move the mbus configuration into the pcie_setup()
> function.
> 
> > +/* Relevant only for Orion-1/Orion-NAS */
> > +#define ORION5X_PCIE_WA_PHYS_BASE      0xf0000000
> > +#define ORION5X_PCIE_WA_VIRT_BASE      IOMEM(0xfd000000)
> 
> You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE
> should already be part of the DT binding.

Of course! But the issue is that we do not know how to do this DT
binding. I have already wrote email with asking for help in which
property and which format should be this config range defined, but no
answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/

> There is little practical difference
> here, but I see no value in taking the shortcut here either.
> 
> For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the
> definition in arch/arm/mach-orion5x/common.c, and this is rather fragile.
> 
> Instead, please use ioremap() to create a mapping at runtime. The ioremap()
> implementation on ARM is smart enough to reuse the address from the static
> mapping in common.c, but will also keep working if that should go away.

I'm planning to work with Mauri on this, but current blocker is DT.

> > +#define ORION5X_PCIE_WA_SIZE           SZ_16M
> > +#define ORION_MBUS_PCIE_WA_TARGET      0x04
> > +#define ORION_MBUS_PCIE_WA_ATTR                0x79
> > +
> > +static int mvebu_pcie_child_rd_conf_wa(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val)
> > +{
> > +       struct mvebu_pcie *pcie = bus->sysdata;
> > +       struct mvebu_pcie_port *port;
> > +
> > +       port = mvebu_pcie_find_port(pcie, bus, devfn);
> > +       if (!port)
> > +               return PCIBIOS_DEVICE_NOT_FOUND;
> > +
> > +       if (!mvebu_pcie_link_up(port))
> > +               return PCIBIOS_DEVICE_NOT_FOUND;
> > +
> > +       /*
> > +        * We only support access to the non-extended configuration
> > +        * space when using the WA access method (or we would have to
> > +        * sacrifice 256M of CPU virtual address space.)
> > +        */
> > +       if (where >= 0x100) {
> > +               *val = 0xffffffff;
> > +               return PCIBIOS_DEVICE_NOT_FOUND;
> > +       }
> > +
> > +       return orion_pcie_rd_conf_wa(ORION5X_PCIE_WA_VIRT_BASE, bus, devfn, where, size, val);
> > +}
> > +
> 
> This is probably good enough here, though I think you could also use
> the trick from drivers/pci/ecam.c and map each bus at a time.
> 
>       Arnd

Yes, there are also helper functions like map bus and etc. which could
simplify this code. I'm planning to do cleanups once we have fully
working driver for Orion.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Arnd Bergmann]

On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote:
> On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote:
> > > +/* Relevant only for Orion-1/Orion-NAS */
> > > +#define ORION5X_PCIE_WA_PHYS_BASE      0xf0000000
> > > +#define ORION5X_PCIE_WA_VIRT_BASE      IOMEM(0xfd000000)
> >
> > You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE
> > should already be part of the DT binding.
>
> Of course! But the issue is that we do not know how to do this DT
> binding. I have already wrote email with asking for help in which
> property and which format should be this config range defined, but no
> answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/

Ah, I had not seen that email. Quoting from there:

> So my question is: How to properly define config space range in device
> tree file? In which device tree property and in which format? Please
> note that this memory range of config space is PCIe root port specific
> and it requires its own MBUS_ID() like memory range of PCIe MEM and PCIe
> IO mapping. Please look e.g. at armada-385.dtsi how are MBUS_ID() used:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-385.dtsi

This is probably a question for Rob as the mvebu driver is a rather special
case. Normally this would just be a 'reg' property of the host bridge,
but I think
in your case the root device is imaginary, and the ports under it are the
actual hardware devices, so you'll probably have to do the same thing as
the armada-385, translating the mbus ranges for the config space in the
"ranges" property of the parent, and then referring to them by PCI
MMIO addresses using the assigned-addresses property to pass the
config-space registers as a second set of registers in addition to the
first set.

> > There is little practical difference
> > here, but I see no value in taking the shortcut here either.
> >
> > For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the
> > definition in arch/arm/mach-orion5x/common.c, and this is rather fragile.
> >
> > Instead, please use ioremap() to create a mapping at runtime. The ioremap()
> > implementation on ARM is smart enough to reuse the address from the static
> > mapping in common.c, but will also keep working if that should go away.
>
> I'm planning to work with Mauri on this, but current blocker is DT.

Ok. It should not be hard to do this first, as you just need to pass the
same physical address that you pass in the mbus setup, but I agree
it's easier to do this afterwards to avoid having to rewrite it again.

> > This is probably good enough here, though I think you could also use
> > the trick from drivers/pci/ecam.c and map each bus at a time.
> >
> Yes, there are also helper functions like map bus and etc. which could
> simplify this code. I'm planning to do cleanups once we have fully
> working driver for Orion.

Ok. This is probably not worth the effort if the old driver doesn't already
do provide access to the high registers.

      Arnd

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Arnd Bergmann]

On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote:
> On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote:
> > > +/* Relevant only for Orion-1/Orion-NAS */
> > > +#define ORION5X_PCIE_WA_PHYS_BASE      0xf0000000
> > > +#define ORION5X_PCIE_WA_VIRT_BASE      IOMEM(0xfd000000)
> >
> > You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE
> > should already be part of the DT binding.
>
> Of course! But the issue is that we do not know how to do this DT
> binding. I have already wrote email with asking for help in which
> property and which format should be this config range defined, but no
> answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/

Ah, I had not seen that email. Quoting from there:

> So my question is: How to properly define config space range in device
> tree file? In which device tree property and in which format? Please
> note that this memory range of config space is PCIe root port specific
> and it requires its own MBUS_ID() like memory range of PCIe MEM and PCIe
> IO mapping. Please look e.g. at armada-385.dtsi how are MBUS_ID() used:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-385.dtsi

This is probably a question for Rob as the mvebu driver is a rather special
case. Normally this would just be a 'reg' property of the host bridge,
but I think
in your case the root device is imaginary, and the ports under it are the
actual hardware devices, so you'll probably have to do the same thing as
the armada-385, translating the mbus ranges for the config space in the
"ranges" property of the parent, and then referring to them by PCI
MMIO addresses using the assigned-addresses property to pass the
config-space registers as a second set of registers in addition to the
first set.

> > There is little practical difference
> > here, but I see no value in taking the shortcut here either.
> >
> > For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the
> > definition in arch/arm/mach-orion5x/common.c, and this is rather fragile.
> >
> > Instead, please use ioremap() to create a mapping at runtime. The ioremap()
> > implementation on ARM is smart enough to reuse the address from the static
> > mapping in common.c, but will also keep working if that should go away.
>
> I'm planning to work with Mauri on this, but current blocker is DT.

Ok. It should not be hard to do this first, as you just need to pass the
same physical address that you pass in the mbus setup, but I agree
it's easier to do this afterwards to avoid having to rewrite it again.

> > This is probably good enough here, though I think you could also use
> > the trick from drivers/pci/ecam.c and map each bus at a time.
> >
> Yes, there are also helper functions like map bus and etc. which could
> simplify this code. I'm planning to do cleanups once we have fully
> working driver for Orion.

Ok. This is probably not worth the effort if the old driver doesn't already
do provide access to the high registers.

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] PCI: mvebu: add support for orion soc

[Arnd Bergmann]

On Mon, Jul 18, 2022 at 10:28 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>
> Hello all!
>
> Working in close co-operation with Pali we made an initial attempt at bringing
> support for orion PCIe into mvebu PCIe driver. Currently the address of
> workaround memory range is hard coded and based on compatible string only. As
> Pali describes in another thread, we were not able to figure out what's the
> correct way to configure a configuration space. That discussion is here:
> https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/T/#u
>
> I tested this with D-Link DNS-323 rev A1 and it's working. As usual, all
> comments and feedback is welcome.

Hi Mauri,

I've managed to dig out my old series for reworking the orion5x PCI/PCIe
support, to the point where the two drivers are completely independent.

Please have a look at
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=orion-pci-cleanup

to see if this helps you at all. I see now that your DNS-323 only supports
PCIe but not PCI, so maybe it's not all that helpful for your machine,
but it should help for converting the other ones that do use legacy
PCI and want to base DT support on top of this work.

      Arnd

Re: [PATCH 0/2] PCI: mvebu: add support for orion soc

[Arnd Bergmann]

On Mon, Jul 18, 2022 at 10:28 PM Mauri Sandberg <maukka@ext.kapsi.fi> wrote:
>
> Hello all!
>
> Working in close co-operation with Pali we made an initial attempt at bringing
> support for orion PCIe into mvebu PCIe driver. Currently the address of
> workaround memory range is hard coded and based on compatible string only. As
> Pali describes in another thread, we were not able to figure out what's the
> correct way to configure a configuration space. That discussion is here:
> https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/T/#u
>
> I tested this with D-Link DNS-323 rev A1 and it's working. As usual, all
> comments and feedback is welcome.

Hi Mauri,

I've managed to dig out my old series for reworking the orion5x PCI/PCIe
support, to the point where the two drivers are completely independent.

Please have a look at
https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=orion-pci-cleanup

to see if this helps you at all. I see now that your DNS-323 only supports
PCIe but not PCI, so maybe it's not all that helpful for your machine,
but it should help for converting the other ones that do use legacy
PCI and want to base DT support on top of this work.

      Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Pali Rohár]

On Tuesday 19 July 2022 12:16:34 Arnd Bergmann wrote:
> On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote:
> > On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote:
> > > > +/* Relevant only for Orion-1/Orion-NAS */
> > > > +#define ORION5X_PCIE_WA_PHYS_BASE      0xf0000000
> > > > +#define ORION5X_PCIE_WA_VIRT_BASE      IOMEM(0xfd000000)
> > >
> > > You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE
> > > should already be part of the DT binding.
> >
> > Of course! But the issue is that we do not know how to do this DT
> > binding. I have already wrote email with asking for help in which
> > property and which format should be this config range defined, but no
> > answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/
> 
> Ah, I had not seen that email. Quoting from there:
> 
> > So my question is: How to properly define config space range in device
> > tree file? In which device tree property and in which format? Please
> > note that this memory range of config space is PCIe root port specific
> > and it requires its own MBUS_ID() like memory range of PCIe MEM and PCIe
> > IO mapping. Please look e.g. at armada-385.dtsi how are MBUS_ID() used:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-385.dtsi
> 
> This is probably a question for Rob as the mvebu driver is a rather special
> case. Normally this would just be a 'reg' property of the host bridge,
> but I think
> in your case the root device is imaginary, and the ports under it are the
> actual hardware devices

yes

> so you'll probably have to do the same thing as
> the armada-385, translating the mbus ranges for the config space in the
> "ranges" property of the parent

Problem is that "ranges" in PCIe are used for specifying MEM and IO
mappings and kernel PCI code does not allow any other type.

> and then referring to them by PCI
> MMIO addresses using the assigned-addresses property to pass the
> config-space registers as a second set of registers in addition to the
> first set.

It is more complicated. PCIe MEM and IO memory ranges are defined in
"soc" node in "pcie-mem-aperture" and "pcie-io-aperture" properties.
These ranges are shared across all PCIe controllers and assigning slices
of these ranges to specific devices is done later by dynamic allocation.
"soc" node is bind to mbus driver (which parse these properties) and
provides API for other kernel drivers for dynamic allocation of memory
from pcie aperture. In pcie node is just indirect reference to PCIe MEM
and IO via MBUS_ID() macro and it is pci-mvebu.c driver who ask mbus
driver for PCIe MEM and IO dynamic allocation.

So because PCIe config space is not of type PCIe MEM nor PCIe IO
(obviously) it cannot use "ranges" property. Because DT pcie nodes use
"reg" property for specifying BDF address, we cannot use neither "reg"
property for specifying memory range of PCIe config space.

And here I'm lost.

My guess is that proper way is to define "pcie-cfg-aperture" in "soc"
node where would be defined physical address range without any binding
to controller, then extend mbus driver to export API also for PCIe CFG
and add code which dynamically assign slice of this range to some
controller. And then use this new API by pci-mvebu.c to access config
space. But pci-mvebu.c needs to know MBUS_ID() attributes which needs to
be defined somewhere in pcie DT node...

> > > There is little practical difference
> > > here, but I see no value in taking the shortcut here either.
> > >
> > > For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the
> > > definition in arch/arm/mach-orion5x/common.c, and this is rather fragile.
> > >
> > > Instead, please use ioremap() to create a mapping at runtime. The ioremap()
> > > implementation on ARM is smart enough to reuse the address from the static
> > > mapping in common.c, but will also keep working if that should go away.
> >
> > I'm planning to work with Mauri on this, but current blocker is DT.
> 
> Ok. It should not be hard to do this first, as you just need to pass the
> same physical address that you pass in the mbus setup, but I agree
> it's easier to do this afterwards to avoid having to rewrite it again.
> 
> > > This is probably good enough here, though I think you could also use
> > > the trick from drivers/pci/ecam.c and map each bus at a time.
> > >
> > Yes, there are also helper functions like map bus and etc. which could
> > simplify this code. I'm planning to do cleanups once we have fully
> > working driver for Orion.
> 
> Ok. This is probably not worth the effort if the old driver doesn't already
> do provide access to the high registers.
> 
>       Arnd

If we have free 256MB in physical address space, then we can implement
it easily. It is just changing _size_ argument. I'm not sure how much
DDR RAM has Orion, but if only 2GB then we should be fine (remaining 2GB
should be enough for all peripherals + 256MB for PCIe config space).

Main issue is that there is no Orion documentation which would describe
how direct mapping of PCIe config space is working.
(see also https://lore.kernel.org/linux-doc/20220719080807.16729-1-pali@kernel.org/)

So we can only set "size" of the physical config space mapping and if we
choose smaller size then we cannot access upper registers. I do not see
any option how to specify "offset" for physical config space to allow
mapping just one PCI bus.

What we have under full control is virtual address space mapping, so we
can just map only one PCI bus to virtual address space from large 256MB
physical config address space.

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Pali Rohár]

On Tuesday 19 July 2022 12:16:34 Arnd Bergmann wrote:
> On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote:
> > On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote:
> > > > +/* Relevant only for Orion-1/Orion-NAS */
> > > > +#define ORION5X_PCIE_WA_PHYS_BASE      0xf0000000
> > > > +#define ORION5X_PCIE_WA_VIRT_BASE      IOMEM(0xfd000000)
> > >
> > > You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE
> > > should already be part of the DT binding.
> >
> > Of course! But the issue is that we do not know how to do this DT
> > binding. I have already wrote email with asking for help in which
> > property and which format should be this config range defined, but no
> > answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/
> 
> Ah, I had not seen that email. Quoting from there:
> 
> > So my question is: How to properly define config space range in device
> > tree file? In which device tree property and in which format? Please
> > note that this memory range of config space is PCIe root port specific
> > and it requires its own MBUS_ID() like memory range of PCIe MEM and PCIe
> > IO mapping. Please look e.g. at armada-385.dtsi how are MBUS_ID() used:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-385.dtsi
> 
> This is probably a question for Rob as the mvebu driver is a rather special
> case. Normally this would just be a 'reg' property of the host bridge,
> but I think
> in your case the root device is imaginary, and the ports under it are the
> actual hardware devices

yes

> so you'll probably have to do the same thing as
> the armada-385, translating the mbus ranges for the config space in the
> "ranges" property of the parent

Problem is that "ranges" in PCIe are used for specifying MEM and IO
mappings and kernel PCI code does not allow any other type.

> and then referring to them by PCI
> MMIO addresses using the assigned-addresses property to pass the
> config-space registers as a second set of registers in addition to the
> first set.

It is more complicated. PCIe MEM and IO memory ranges are defined in
"soc" node in "pcie-mem-aperture" and "pcie-io-aperture" properties.
These ranges are shared across all PCIe controllers and assigning slices
of these ranges to specific devices is done later by dynamic allocation.
"soc" node is bind to mbus driver (which parse these properties) and
provides API for other kernel drivers for dynamic allocation of memory
from pcie aperture. In pcie node is just indirect reference to PCIe MEM
and IO via MBUS_ID() macro and it is pci-mvebu.c driver who ask mbus
driver for PCIe MEM and IO dynamic allocation.

So because PCIe config space is not of type PCIe MEM nor PCIe IO
(obviously) it cannot use "ranges" property. Because DT pcie nodes use
"reg" property for specifying BDF address, we cannot use neither "reg"
property for specifying memory range of PCIe config space.

And here I'm lost.

My guess is that proper way is to define "pcie-cfg-aperture" in "soc"
node where would be defined physical address range without any binding
to controller, then extend mbus driver to export API also for PCIe CFG
and add code which dynamically assign slice of this range to some
controller. And then use this new API by pci-mvebu.c to access config
space. But pci-mvebu.c needs to know MBUS_ID() attributes which needs to
be defined somewhere in pcie DT node...

> > > There is little practical difference
> > > here, but I see no value in taking the shortcut here either.
> > >
> > > For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the
> > > definition in arch/arm/mach-orion5x/common.c, and this is rather fragile.
> > >
> > > Instead, please use ioremap() to create a mapping at runtime. The ioremap()
> > > implementation on ARM is smart enough to reuse the address from the static
> > > mapping in common.c, but will also keep working if that should go away.
> >
> > I'm planning to work with Mauri on this, but current blocker is DT.
> 
> Ok. It should not be hard to do this first, as you just need to pass the
> same physical address that you pass in the mbus setup, but I agree
> it's easier to do this afterwards to avoid having to rewrite it again.
> 
> > > This is probably good enough here, though I think you could also use
> > > the trick from drivers/pci/ecam.c and map each bus at a time.
> > >
> > Yes, there are also helper functions like map bus and etc. which could
> > simplify this code. I'm planning to do cleanups once we have fully
> > working driver for Orion.
> 
> Ok. This is probably not worth the effort if the old driver doesn't already
> do provide access to the high registers.
> 
>       Arnd

If we have free 256MB in physical address space, then we can implement
it easily. It is just changing _size_ argument. I'm not sure how much
DDR RAM has Orion, but if only 2GB then we should be fine (remaining 2GB
should be enough for all peripherals + 256MB for PCIe config space).

Main issue is that there is no Orion documentation which would describe
how direct mapping of PCIe config space is working.
(see also https://lore.kernel.org/linux-doc/20220719080807.16729-1-pali@kernel.org/)

So we can only set "size" of the physical config space mapping and if we
choose smaller size then we cannot access upper registers. I do not see
any option how to specify "offset" for physical config space to allow
mapping just one PCI bus.

What we have under full control is virtual address space mapping, so we
can just map only one PCI bus to virtual address space from large 256MB
physical config address space.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Andrew Lunn]

> If we have free 256MB in physical address space, then we can implement
> it easily. It is just changing _size_ argument. I'm not sure how much
> DDR RAM has Orion, but if only 2GB then we should be fine (remaining 2GB
> should be enough for all peripherals + 256MB for PCIe config space).

All the Orion5x devices i've seen have had small amounts of RAM, 64MB,
maybe 128M. It seems very unlikely there are any with 2GB for RAM. So
i don't see a problem with taking 256MB of physical addresses for PCI.

  Andrew

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Andrew Lunn]

> If we have free 256MB in physical address space, then we can implement
> it easily. It is just changing _size_ argument. I'm not sure how much
> DDR RAM has Orion, but if only 2GB then we should be fine (remaining 2GB
> should be enough for all peripherals + 256MB for PCIe config space).

All the Orion5x devices i've seen have had small amounts of RAM, 64MB,
maybe 128M. It seems very unlikely there are any with 2GB for RAM. So
i don't see a problem with taking 256MB of physical addresses for PCI.

  Andrew

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Arnd Bergmann]

On Wed, Jul 20, 2022 at 6:13 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Tuesday 19 July 2022 12:16:34 Arnd Bergmann wrote:
> > On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote:
> > so you'll probably have to do the same thing as
> > the armada-385, translating the mbus ranges for the config space in the
> > "ranges" property of the parent
>
> Problem is that "ranges" in PCIe are used for specifying MEM and IO
> mappings and kernel PCI code does not allow any other type.
>
> > and then referring to them by PCI
> > MMIO addresses using the assigned-addresses property to pass the
> > config-space registers as a second set of registers in addition to the
> > first set.
>
> It is more complicated. PCIe MEM and IO memory ranges are defined in
> "soc" node in "pcie-mem-aperture" and "pcie-io-aperture" properties.
> These ranges are shared across all PCIe controllers and assigning slices
> of these ranges to specific devices is done later by dynamic allocation.
> "soc" node is bind to mbus driver (which parse these properties) and
> provides API for other kernel drivers for dynamic allocation of memory
> from pcie aperture. In pcie node is just indirect reference to PCIe MEM
> and IO via MBUS_ID() macro and it is pci-mvebu.c driver who ask mbus
> driver for PCIe MEM and IO dynamic allocation.
>
> So because PCIe config space is not of type PCIe MEM nor PCIe IO
> (obviously) it cannot use "ranges" property. Because DT pcie nodes use
> "reg" property for specifying BDF address, we cannot use neither "reg"
> property for specifying memory range of PCIe config space.
>
> And here I'm lost.
>
> My guess is that proper way is to define "pcie-cfg-aperture" in "soc"
> node where would be defined physical address range without any binding
> to controller, then extend mbus driver to export API also for PCIe CFG
> and add code which dynamically assign slice of this range to some
> controller. And then use this new API by pci-mvebu.c to access config
> space. But pci-mvebu.c needs to know MBUS_ID() attributes which needs to
> be defined somewhere in pcie DT node...

I think you can define a "ranges" property in the parent node that
converts the MBUS address into a fake PCI MEM space address,
and this is what the Armada 385 example does with
<0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000>
In the child you can refer to this using the "assigned-addresses"
property and then use the "ranges" to ensure that only the actual
IO and MEM space addresses are translated.

The alternative would be to do away with the indirection and make
the orion5x variant be more like a single hostbridge, and getting
rid of the fake parent. This is closer to what orion5x does at the
moment with the old driver, but might be harder to integrate into
the new one.

> > > > There is little practical difference
> > > > here, but I see no value in taking the shortcut here either.
> > > >
> > > > For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the
> > > > definition in arch/arm/mach-orion5x/common.c, and this is rather fragile.
> > > >
> > > > Instead, please use ioremap() to create a mapping at runtime. The ioremap()
> > > > implementation on ARM is smart enough to reuse the address from the static
> > > > mapping in common.c, but will also keep working if that should go away.
> > >
> > > I'm planning to work with Mauri on this, but current blocker is DT.
> >
> > Ok. It should not be hard to do this first, as you just need to pass the
> > same physical address that you pass in the mbus setup, but I agree
> > it's easier to do this afterwards to avoid having to rewrite it again.
> >
> > > > This is probably good enough here, though I think you could also use
> > > > the trick from drivers/pci/ecam.c and map each bus at a time.
> > > >
> > > Yes, there are also helper functions like map bus and etc. which could
> > > simplify this code. I'm planning to do cleanups once we have fully
> > > working driver for Orion.
> >
> > Ok. This is probably not worth the effort if the old driver doesn't already
> > do provide access to the high registers.
> >
> >       Arnd
>
> If we have free 256MB in physical address space, then we can implement
> it easily. It is just changing _size_ argument. I'm not sure how much
> DDR RAM has Orion, but if only 2GB then we should be fine (remaining 2GB
> should be enough for all peripherals + 256MB for PCIe config space).

I recently checked the sizes as I was researching which boards are actually
still usable, and I can confirm what Andrew also said. The only one with
256MB is TS409, everything else has 32MB to 128MB.

As I said before, I also see no problem with leaving the smaller mapping,
as we know that nobody has ever used the extended config space on
orion5x with mainline kernels, and we are not trying to support new
hardware.

> So we can only set "size" of the physical config space mapping and if we
> choose smaller size then we cannot access upper registers. I do not see
> any option how to specify "offset" for physical config space to allow
> mapping just one PCI bus.
>
> What we have under full control is virtual address space mapping, so we
> can just map only one PCI bus to virtual address space from large 256MB
> physical config address space.

Right.

       Arnd

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Arnd Bergmann]

On Wed, Jul 20, 2022 at 6:13 PM Pali Rohár <pali@kernel.org> wrote:
>
> On Tuesday 19 July 2022 12:16:34 Arnd Bergmann wrote:
> > On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote:
> > so you'll probably have to do the same thing as
> > the armada-385, translating the mbus ranges for the config space in the
> > "ranges" property of the parent
>
> Problem is that "ranges" in PCIe are used for specifying MEM and IO
> mappings and kernel PCI code does not allow any other type.
>
> > and then referring to them by PCI
> > MMIO addresses using the assigned-addresses property to pass the
> > config-space registers as a second set of registers in addition to the
> > first set.
>
> It is more complicated. PCIe MEM and IO memory ranges are defined in
> "soc" node in "pcie-mem-aperture" and "pcie-io-aperture" properties.
> These ranges are shared across all PCIe controllers and assigning slices
> of these ranges to specific devices is done later by dynamic allocation.
> "soc" node is bind to mbus driver (which parse these properties) and
> provides API for other kernel drivers for dynamic allocation of memory
> from pcie aperture. In pcie node is just indirect reference to PCIe MEM
> and IO via MBUS_ID() macro and it is pci-mvebu.c driver who ask mbus
> driver for PCIe MEM and IO dynamic allocation.
>
> So because PCIe config space is not of type PCIe MEM nor PCIe IO
> (obviously) it cannot use "ranges" property. Because DT pcie nodes use
> "reg" property for specifying BDF address, we cannot use neither "reg"
> property for specifying memory range of PCIe config space.
>
> And here I'm lost.
>
> My guess is that proper way is to define "pcie-cfg-aperture" in "soc"
> node where would be defined physical address range without any binding
> to controller, then extend mbus driver to export API also for PCIe CFG
> and add code which dynamically assign slice of this range to some
> controller. And then use this new API by pci-mvebu.c to access config
> space. But pci-mvebu.c needs to know MBUS_ID() attributes which needs to
> be defined somewhere in pcie DT node...

I think you can define a "ranges" property in the parent node that
converts the MBUS address into a fake PCI MEM space address,
and this is what the Armada 385 example does with
<0x82000000 0 0x80000 MBUS_ID(0xf0, 0x01) 0x80000 0 0x00002000>
In the child you can refer to this using the "assigned-addresses"
property and then use the "ranges" to ensure that only the actual
IO and MEM space addresses are translated.

The alternative would be to do away with the indirection and make
the orion5x variant be more like a single hostbridge, and getting
rid of the fake parent. This is closer to what orion5x does at the
moment with the old driver, but might be harder to integrate into
the new one.

> > > > There is little practical difference
> > > > here, but I see no value in taking the shortcut here either.
> > > >
> > > > For the ORION5X_PCIE_WA_VIRT_BASE, you rely on this to match the
> > > > definition in arch/arm/mach-orion5x/common.c, and this is rather fragile.
> > > >
> > > > Instead, please use ioremap() to create a mapping at runtime. The ioremap()
> > > > implementation on ARM is smart enough to reuse the address from the static
> > > > mapping in common.c, but will also keep working if that should go away.
> > >
> > > I'm planning to work with Mauri on this, but current blocker is DT.
> >
> > Ok. It should not be hard to do this first, as you just need to pass the
> > same physical address that you pass in the mbus setup, but I agree
> > it's easier to do this afterwards to avoid having to rewrite it again.
> >
> > > > This is probably good enough here, though I think you could also use
> > > > the trick from drivers/pci/ecam.c and map each bus at a time.
> > > >
> > > Yes, there are also helper functions like map bus and etc. which could
> > > simplify this code. I'm planning to do cleanups once we have fully
> > > working driver for Orion.
> >
> > Ok. This is probably not worth the effort if the old driver doesn't already
> > do provide access to the high registers.
> >
> >       Arnd
>
> If we have free 256MB in physical address space, then we can implement
> it easily. It is just changing _size_ argument. I'm not sure how much
> DDR RAM has Orion, but if only 2GB then we should be fine (remaining 2GB
> should be enough for all peripherals + 256MB for PCIe config space).

I recently checked the sizes as I was researching which boards are actually
still usable, and I can confirm what Andrew also said. The only one with
256MB is TS409, everything else has 32MB to 128MB.

As I said before, I also see no problem with leaving the smaller mapping,
as we know that nobody has ever used the extended config space on
orion5x with mainline kernels, and we are not trying to support new
hardware.

> So we can only set "size" of the physical config space mapping and if we
> choose smaller size then we cannot access upper registers. I do not see
> any option how to specify "offset" for physical config space to allow
> mapping just one PCI bus.
>
> What we have under full control is virtual address space mapping, so we
> can just map only one PCI bus to virtual address space from large 256MB
> physical config address space.

Right.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Rob Herring]

On Wed, Jul 20, 2022 at 10:13 AM Pali Rohár <pali@kernel.org> wrote:
>
> On Tuesday 19 July 2022 12:16:34 Arnd Bergmann wrote:
> > On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote:
> > > On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote:
> > > > > +/* Relevant only for Orion-1/Orion-NAS */
> > > > > +#define ORION5X_PCIE_WA_PHYS_BASE      0xf0000000
> > > > > +#define ORION5X_PCIE_WA_VIRT_BASE      IOMEM(0xfd000000)
> > > >
> > > > You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE
> > > > should already be part of the DT binding.
> > >
> > > Of course! But the issue is that we do not know how to do this DT
> > > binding. I have already wrote email with asking for help in which
> > > property and which format should be this config range defined, but no
> > > answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/
> >
> > Ah, I had not seen that email. Quoting from there:
> >
> > > So my question is: How to properly define config space range in device
> > > tree file? In which device tree property and in which format? Please
> > > note that this memory range of config space is PCIe root port specific
> > > and it requires its own MBUS_ID() like memory range of PCIe MEM and PCIe
> > > IO mapping. Please look e.g. at armada-385.dtsi how are MBUS_ID() used:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-385.dtsi
> >
> > This is probably a question for Rob as the mvebu driver is a rather special
> > case. Normally this would just be a 'reg' property of the host bridge,
> > but I think
> > in your case the root device is imaginary, and the ports under it are the
> > actual hardware devices
>
> yes
>
> > so you'll probably have to do the same thing as
> > the armada-385, translating the mbus ranges for the config space in the
> > "ranges" property of the parent
>
> Problem is that "ranges" in PCIe are used for specifying MEM and IO
> mappings and kernel PCI code does not allow any other type.

The kernel does not, but the binding does (well, the original OF PCI
bus supplement does, but the schema currently does not). If there's a
real need to support config space in ranges, then we can relax the
constraints.

Rob

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Rob Herring]

On Wed, Jul 20, 2022 at 10:13 AM Pali Rohár <pali@kernel.org> wrote:
>
> On Tuesday 19 July 2022 12:16:34 Arnd Bergmann wrote:
> > On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote:
> > > On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote:
> > > > > +/* Relevant only for Orion-1/Orion-NAS */
> > > > > +#define ORION5X_PCIE_WA_PHYS_BASE      0xf0000000
> > > > > +#define ORION5X_PCIE_WA_VIRT_BASE      IOMEM(0xfd000000)
> > > >
> > > > You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE
> > > > should already be part of the DT binding.
> > >
> > > Of course! But the issue is that we do not know how to do this DT
> > > binding. I have already wrote email with asking for help in which
> > > property and which format should be this config range defined, but no
> > > answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/
> >
> > Ah, I had not seen that email. Quoting from there:
> >
> > > So my question is: How to properly define config space range in device
> > > tree file? In which device tree property and in which format? Please
> > > note that this memory range of config space is PCIe root port specific
> > > and it requires its own MBUS_ID() like memory range of PCIe MEM and PCIe
> > > IO mapping. Please look e.g. at armada-385.dtsi how are MBUS_ID() used:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-385.dtsi
> >
> > This is probably a question for Rob as the mvebu driver is a rather special
> > case. Normally this would just be a 'reg' property of the host bridge,
> > but I think
> > in your case the root device is imaginary, and the ports under it are the
> > actual hardware devices
>
> yes
>
> > so you'll probably have to do the same thing as
> > the armada-385, translating the mbus ranges for the config space in the
> > "ranges" property of the parent
>
> Problem is that "ranges" in PCIe are used for specifying MEM and IO
> mappings and kernel PCI code does not allow any other type.

The kernel does not, but the binding does (well, the original OF PCI
bus supplement does, but the schema currently does not). If there's a
real need to support config space in ranges, then we can relax the
constraints.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Pali Rohár]

On Wednesday 20 July 2022 11:40:40 Rob Herring wrote:
> On Wed, Jul 20, 2022 at 10:13 AM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Tuesday 19 July 2022 12:16:34 Arnd Bergmann wrote:
> > > On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote:
> > > > On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote:
> > > > > > +/* Relevant only for Orion-1/Orion-NAS */
> > > > > > +#define ORION5X_PCIE_WA_PHYS_BASE      0xf0000000
> > > > > > +#define ORION5X_PCIE_WA_VIRT_BASE      IOMEM(0xfd000000)
> > > > >
> > > > > You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE
> > > > > should already be part of the DT binding.
> > > >
> > > > Of course! But the issue is that we do not know how to do this DT
> > > > binding. I have already wrote email with asking for help in which
> > > > property and which format should be this config range defined, but no
> > > > answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/
> > >
> > > Ah, I had not seen that email. Quoting from there:
> > >
> > > > So my question is: How to properly define config space range in device
> > > > tree file? In which device tree property and in which format? Please
> > > > note that this memory range of config space is PCIe root port specific
> > > > and it requires its own MBUS_ID() like memory range of PCIe MEM and PCIe
> > > > IO mapping. Please look e.g. at armada-385.dtsi how are MBUS_ID() used:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-385.dtsi
> > >
> > > This is probably a question for Rob as the mvebu driver is a rather special
> > > case. Normally this would just be a 'reg' property of the host bridge,
> > > but I think
> > > in your case the root device is imaginary, and the ports under it are the
> > > actual hardware devices
> >
> > yes
> >
> > > so you'll probably have to do the same thing as
> > > the armada-385, translating the mbus ranges for the config space in the
> > > "ranges" property of the parent
> >
> > Problem is that "ranges" in PCIe are used for specifying MEM and IO
> > mappings and kernel PCI code does not allow any other type.
> 
> The kernel does not, but the binding does (well, the original OF PCI
> bus supplement does, but the schema currently does not). If there's a
> real need to support config space in ranges, then we can relax the
> constraints.
> 
> Rob

Personally, I do not care where definition of address range for config
space would be defined. Just I need to know where to put it and in which
format, so it would be fine for schema checkers, kernel pci core, etc...
https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/

Re: [PATCH 2/2] PCI: mvebu: add support for orion5x

[Pali Rohár]

On Wednesday 20 July 2022 11:40:40 Rob Herring wrote:
> On Wed, Jul 20, 2022 at 10:13 AM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Tuesday 19 July 2022 12:16:34 Arnd Bergmann wrote:
> > > On Tue, Jul 19, 2022 at 11:46 AM Pali Rohár <pali@kernel.org> wrote:
> > > > On Tuesday 19 July 2022 10:05:28 Arnd Bergmann wrote:
> > > > > > +/* Relevant only for Orion-1/Orion-NAS */
> > > > > > +#define ORION5X_PCIE_WA_PHYS_BASE      0xf0000000
> > > > > > +#define ORION5X_PCIE_WA_VIRT_BASE      IOMEM(0xfd000000)
> > > > >
> > > > > You should not need to hardcode these here. The ORION5X_PCIE_WA_PHYS_BASE
> > > > > should already be part of the DT binding.
> > > >
> > > > Of course! But the issue is that we do not know how to do this DT
> > > > binding. I have already wrote email with asking for help in which
> > > > property and which format should be this config range defined, but no
> > > > answer yet: https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/
> > >
> > > Ah, I had not seen that email. Quoting from there:
> > >
> > > > So my question is: How to properly define config space range in device
> > > > tree file? In which device tree property and in which format? Please
> > > > note that this memory range of config space is PCIe root port specific
> > > > and it requires its own MBUS_ID() like memory range of PCIe MEM and PCIe
> > > > IO mapping. Please look e.g. at armada-385.dtsi how are MBUS_ID() used:
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/armada-385.dtsi
> > >
> > > This is probably a question for Rob as the mvebu driver is a rather special
> > > case. Normally this would just be a 'reg' property of the host bridge,
> > > but I think
> > > in your case the root device is imaginary, and the ports under it are the
> > > actual hardware devices
> >
> > yes
> >
> > > so you'll probably have to do the same thing as
> > > the armada-385, translating the mbus ranges for the config space in the
> > > "ranges" property of the parent
> >
> > Problem is that "ranges" in PCIe are used for specifying MEM and IO
> > mappings and kernel PCI code does not allow any other type.
> 
> The kernel does not, but the binding does (well, the original OF PCI
> bus supplement does, but the schema currently does not). If there's a
> real need to support config space in ranges, then we can relax the
> constraints.
> 
> Rob

Personally, I do not care where definition of address range for config
space would be defined. Just I need to know where to put it and in which
format, so it would be fine for schema checkers, kernel pci core, etc...
https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] dt-bindings: PCI: mvebu: Add orion5x compatible

[Rob Herring]

On Mon, 18 Jul 2022 23:28:41 +0300, Mauri Sandberg wrote:
> Add a compatible string to bindings to indicate that orion5x PCIe is
> supported too.
> 
> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> ---
>  Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH 1/2] dt-bindings: PCI: mvebu: Add orion5x compatible

[Rob Herring]

On Mon, 18 Jul 2022 23:28:41 +0300, Mauri Sandberg wrote:
> Add a compatible string to bindings to indicate that orion5x PCIe is
> supported too.
> 
> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> ---
>  Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring <robh@kernel.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] PCI: mvebu: add support for orion soc

[Bjorn Helgaas]

On Mon, Jul 18, 2022 at 11:28:40PM +0300, Mauri Sandberg wrote:
> Hello all!
> 
> Working in close co-operation with Pali we made an initial attempt at bringing
> support for orion PCIe into mvebu PCIe driver. Currently the address of
> workaround memory range is hard coded and based on compatible string only. As
> Pali describes in another thread, we were not able to figure out what's the
> correct way to configure a configuration space. That discussion is here:
> https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/T/#u
> 
> I tested this with D-Link DNS-323 rev A1 and it's working. As usual, all
> comments and feedback is welcome.
> 
> Thanks,
> Mauri
> 
> Mauri Sandberg (2):
>   dt-bindings: PCI: mvebu: Add orion5x compatible
>   PCI: mvebu: add support for orion5x
> 
>  .../devicetree/bindings/pci/mvebu-pci.txt     |  1 +
>  arch/arm/mach-orion5x/common.c                | 13 ----
>  drivers/pci/controller/Kconfig                |  2 +-
>  drivers/pci/controller/pci-mvebu.c            | 59 +++++++++++++++++++
>  4 files changed, 61 insertions(+), 14 deletions(-)

Hi Mauri,

Can you address anything in 2/2 (if necessary), incorporate any acks,
and post a v2?  There was some confusion around the first patch (there
are two in the thread, likely the same?), and I didn't read the 2/2
feedback in detail to see if any changes were needed.

Bjorn

Re: [PATCH 0/2] PCI: mvebu: add support for orion soc

[Bjorn Helgaas]

On Mon, Jul 18, 2022 at 11:28:40PM +0300, Mauri Sandberg wrote:
> Hello all!
> 
> Working in close co-operation with Pali we made an initial attempt at bringing
> support for orion PCIe into mvebu PCIe driver. Currently the address of
> workaround memory range is hard coded and based on compatible string only. As
> Pali describes in another thread, we were not able to figure out what's the
> correct way to configure a configuration space. That discussion is here:
> https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/T/#u
> 
> I tested this with D-Link DNS-323 rev A1 and it's working. As usual, all
> comments and feedback is welcome.
> 
> Thanks,
> Mauri
> 
> Mauri Sandberg (2):
>   dt-bindings: PCI: mvebu: Add orion5x compatible
>   PCI: mvebu: add support for orion5x
> 
>  .../devicetree/bindings/pci/mvebu-pci.txt     |  1 +
>  arch/arm/mach-orion5x/common.c                | 13 ----
>  drivers/pci/controller/Kconfig                |  2 +-
>  drivers/pci/controller/pci-mvebu.c            | 59 +++++++++++++++++++
>  4 files changed, 61 insertions(+), 14 deletions(-)

Hi Mauri,

Can you address anything in 2/2 (if necessary), incorporate any acks,
and post a v2?  There was some confusion around the first patch (there
are two in the thread, likely the same?), and I didn't read the 2/2
feedback in detail to see if any changes were needed.

Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] PCI: mvebu: add support for orion soc

[Mauri Sandberg]

Hi Bjorn!

On 29.07.22 20:22, Bjorn Helgaas wrote:
> On Mon, Jul 18, 2022 at 11:28:40PM +0300, Mauri Sandberg wrote:
>> Hello all!
>>
>> Working in close co-operation with Pali we made an initial attempt at bringing
>> support for orion PCIe into mvebu PCIe driver. Currently the address of
>> workaround memory range is hard coded and based on compatible string only. As
>> Pali describes in another thread, we were not able to figure out what's the
>> correct way to configure a configuration space. That discussion is here:
>> https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/T/#u
>>
>> I tested this with D-Link DNS-323 rev A1 and it's working. As usual, all
>> comments and feedback is welcome.
>>
>> Thanks,
>> Mauri
>>
>> Mauri Sandberg (2):
>>    dt-bindings: PCI: mvebu: Add orion5x compatible
>>    PCI: mvebu: add support for orion5x
>>
>>   .../devicetree/bindings/pci/mvebu-pci.txt     |  1 +
>>   arch/arm/mach-orion5x/common.c                | 13 ----
>>   drivers/pci/controller/Kconfig                |  2 +-
>>   drivers/pci/controller/pci-mvebu.c            | 59 +++++++++++++++++++
>>   4 files changed, 61 insertions(+), 14 deletions(-)
> 
> Hi Mauri,
> 
> Can you address anything in 2/2 (if necessary), incorporate any acks,
> and post a v2?  There was some confusion around the first patch (there
> are two in the thread, likely the same?), and I didn't read the 2/2
> feedback in detail to see if any changes were needed.
> 

I give it a little bit time to see if the discussion on how to configure
the configuration space would pick up, but I'll attend to the comments
and post a clean v2 soonish.

Re: [PATCH 0/2] PCI: mvebu: add support for orion soc

[Mauri Sandberg]

Hi Bjorn!

On 29.07.22 20:22, Bjorn Helgaas wrote:
> On Mon, Jul 18, 2022 at 11:28:40PM +0300, Mauri Sandberg wrote:
>> Hello all!
>>
>> Working in close co-operation with Pali we made an initial attempt at bringing
>> support for orion PCIe into mvebu PCIe driver. Currently the address of
>> workaround memory range is hard coded and based on compatible string only. As
>> Pali describes in another thread, we were not able to figure out what's the
>> correct way to configure a configuration space. That discussion is here:
>> https://lore.kernel.org/linux-pci/20220710225108.bgedria6igtqpz5l@pali/T/#u
>>
>> I tested this with D-Link DNS-323 rev A1 and it's working. As usual, all
>> comments and feedback is welcome.
>>
>> Thanks,
>> Mauri
>>
>> Mauri Sandberg (2):
>>    dt-bindings: PCI: mvebu: Add orion5x compatible
>>    PCI: mvebu: add support for orion5x
>>
>>   .../devicetree/bindings/pci/mvebu-pci.txt     |  1 +
>>   arch/arm/mach-orion5x/common.c                | 13 ----
>>   drivers/pci/controller/Kconfig                |  2 +-
>>   drivers/pci/controller/pci-mvebu.c            | 59 +++++++++++++++++++
>>   4 files changed, 61 insertions(+), 14 deletions(-)
> 
> Hi Mauri,
> 
> Can you address anything in 2/2 (if necessary), incorporate any acks,
> and post a v2?  There was some confusion around the first patch (there
> are two in the thread, likely the same?), and I didn't read the 2/2
> feedback in detail to see if any changes were needed.
> 

I give it a little bit time to see if the discussion on how to configure
the configuration space would pick up, but I'll attend to the comments
and post a clean v2 soonish.


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 0/2] PCI: mvebu: add support for orion soc

[Mauri Sandberg]

Hello all,

Here a cleaned up version of the previous series.

Changes
 - instead of removing PCIe related mvebu windows add them in pcie_setup()

I intentionally left the ORION5X_PCIE_WA_VIRT_BASE in place as all pieces
in the puzzle have not found their place yet. It will be replaced with
ioremap() or similar when the problem of passing the address to
configuration space from a device tree is solved.

Tested with DNS323 both DT and non-DT builds.

Thanks,
Mauri

Mauri Sandberg (2):
  dt-bindings: PCI: mvebu: Add orion5x compatible
  PCI: mvebu: add support for orion5x

 .../devicetree/bindings/pci/mvebu-pci.txt     |  1 +
 arch/arm/mach-orion5x/common.c                | 13 ----
 arch/arm/mach-orion5x/pci.c                   | 14 +++++
 drivers/pci/controller/Kconfig                |  2 +-
 drivers/pci/controller/pci-mvebu.c            | 59 +++++++++++++++++++
 5 files changed, 75 insertions(+), 14 deletions(-)


base-commit: 7d0d3fa7339ed5a06d6608b7cde9f079eba62bb1
--
2.25.1

[PATCH v2 0/2] PCI: mvebu: add support for orion soc

[Mauri Sandberg]

Hello all,

Here a cleaned up version of the previous series.

Changes
 - instead of removing PCIe related mvebu windows add them in pcie_setup()

I intentionally left the ORION5X_PCIE_WA_VIRT_BASE in place as all pieces
in the puzzle have not found their place yet. It will be replaced with
ioremap() or similar when the problem of passing the address to
configuration space from a device tree is solved.

Tested with DNS323 both DT and non-DT builds.

Thanks,
Mauri

Mauri Sandberg (2):
  dt-bindings: PCI: mvebu: Add orion5x compatible
  PCI: mvebu: add support for orion5x

 .../devicetree/bindings/pci/mvebu-pci.txt     |  1 +
 arch/arm/mach-orion5x/common.c                | 13 ----
 arch/arm/mach-orion5x/pci.c                   | 14 +++++
 drivers/pci/controller/Kconfig                |  2 +-
 drivers/pci/controller/pci-mvebu.c            | 59 +++++++++++++++++++
 5 files changed, 75 insertions(+), 14 deletions(-)


base-commit: 7d0d3fa7339ed5a06d6608b7cde9f079eba62bb1
--
2.25.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 1/2] dt-bindings: PCI: mvebu: Add orion5x compatible

[Mauri Sandberg]

Add a compatible string to bindings to indicate that orion5x PCIe is
supported too.

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
Acked-by: Rob Herring <robh@kernel.org>
---
v1->v2:
 - added ack by Rob
---
 Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 6d022a9d36ee..ced5d030fe55 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -7,6 +7,7 @@ Mandatory properties:
     marvell,armada-xp-pcie
     marvell,dove-pcie
     marvell,kirkwood-pcie
+    marvell,orion5x-pcie
 - #address-cells, set to <3>
 - #size-cells, set to <2>
 - #interrupt-cells, set to <1>
-- 
2.25.1

[PATCH v2 1/2] dt-bindings: PCI: mvebu: Add orion5x compatible

[Mauri Sandberg]

Add a compatible string to bindings to indicate that orion5x PCIe is
supported too.

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
Acked-by: Rob Herring <robh@kernel.org>
---
v1->v2:
 - added ack by Rob
---
 Documentation/devicetree/bindings/pci/mvebu-pci.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 6d022a9d36ee..ced5d030fe55 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -7,6 +7,7 @@ Mandatory properties:
     marvell,armada-xp-pcie
     marvell,dove-pcie
     marvell,kirkwood-pcie
+    marvell,orion5x-pcie
 - #address-cells, set to <3>
 - #size-cells, set to <2>
 - #interrupt-cells, set to <1>
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v2 2/2] PCI: mvebu: add support for orion5x

[Mauri Sandberg]

Add support for orion5x PCIe controller.

There is Orion-specific errata that config space via CF8/CFC registers
is broken. Workaround documented in errata documented (linked from above
documentation) does not work when DMA is used and instead other
undocumented workaround is needed which maps config space to memory
(and therefore avoids usage of broken CF8/CFC memory mapped registers).

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
Cc: Pali Rohár <pali@kernel.org>
---
v1 -> v2:
 - do pcie related mvebu windows and remaps in pcie_setup()
---
 arch/arm/mach-orion5x/common.c     | 13 -------
 arch/arm/mach-orion5x/pci.c        | 14 +++++++
 drivers/pci/controller/Kconfig     |  2 +-
 drivers/pci/controller/pci-mvebu.c | 59 ++++++++++++++++++++++++++++++
 4 files changed, 74 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index 7bcb41137bbf..9d8be5ce1266 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -231,19 +231,6 @@ void __init orion5x_init_early(void)
 
 void orion5x_setup_wins(void)
 {
-	/*
-	 * The PCIe windows will no longer be statically allocated
-	 * here once Orion5x is migrated to the pci-mvebu driver.
-	 */
-	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
-					  ORION_MBUS_PCIE_IO_ATTR,
-					  ORION5X_PCIE_IO_PHYS_BASE,
-					  ORION5X_PCIE_IO_SIZE,
-					  ORION5X_PCIE_IO_BUS_BASE);
-	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
-				    ORION_MBUS_PCIE_MEM_ATTR,
-				    ORION5X_PCIE_MEM_PHYS_BASE,
-				    ORION5X_PCIE_MEM_SIZE);
 	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
 					  ORION_MBUS_PCI_IO_ATTR,
 					  ORION5X_PCI_IO_PHYS_BASE,
diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion5x/pci.c
index 9574c73f3c03..7c4e2f355cc7 100644
--- a/arch/arm/mach-orion5x/pci.c
+++ b/arch/arm/mach-orion5x/pci.c
@@ -150,6 +150,20 @@ static int __init pcie_setup(struct pci_sys_data *sys)
 	 */
 	orion_pcie_setup(PCIE_BASE);
 
+	/*
+	 * The PCIe windows will no longer be statically allocated
+	 * here once Orion5x is migrated to the pci-mvebu driver.
+	 */
+	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
+					  ORION_MBUS_PCIE_IO_ATTR,
+					  ORION5X_PCIE_IO_PHYS_BASE,
+					  ORION5X_PCIE_IO_SIZE,
+					  ORION5X_PCIE_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
+				    ORION_MBUS_PCIE_MEM_ATTR,
+				    ORION5X_PCIE_MEM_PHYS_BASE,
+				    ORION5X_PCIE_MEM_SIZE);
+
 	/*
 	 * Check whether to apply Orion-1/Orion-NAS PCIe config
 	 * read transaction workaround.
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index b8d96d38064d..a249375837f0 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -5,7 +5,7 @@ menu "PCI controller drivers"
 
 config PCI_MVEBU
 	tristate "Marvell EBU PCIe controller"
-	depends on ARCH_MVEBU || ARCH_DOVE || COMPILE_TEST
+	depends on ARCH_MVEBU || ARCH_DOVE || ARCH_ORION5X || COMPILE_TEST
 	depends on MVEBU_MBUS
 	depends on ARM
 	depends on OF
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index c1ffdb06c971..1d3052aa7e49 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -1487,6 +1487,54 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie)
 	return 0;
 }
 
+static int orion_pcie_rd_conf_wa(void __iomem *wa_base, struct pci_bus *bus,
+			  u32 devfn, int where, int size, u32 *val)
+{
+	*val = readl(wa_base + (PCIE_CONF_BUS(bus->number) |
+				PCIE_CONF_DEV(PCI_SLOT(devfn)) |
+				PCIE_CONF_FUNC(PCI_FUNC(devfn)) |
+				PCIE_CONF_REG(where)));
+
+	if (size == 1)
+		*val = (*val >> (8 * (where & 3))) & 0xff;
+	else if (size == 2)
+		*val = (*val >> (8 * (where & 3))) & 0xffff;
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+/* Relevant only for Orion-1/Orion-NAS */
+#define ORION5X_PCIE_WA_PHYS_BASE	0xf0000000
+#define ORION5X_PCIE_WA_VIRT_BASE	IOMEM(0xfd000000)
+#define ORION5X_PCIE_WA_SIZE		SZ_16M
+#define ORION_MBUS_PCIE_WA_TARGET	0x04
+#define ORION_MBUS_PCIE_WA_ATTR		0x79
+
+static int mvebu_pcie_child_rd_conf_wa(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val)
+{
+	struct mvebu_pcie *pcie = bus->sysdata;
+	struct mvebu_pcie_port *port;
+
+	port = mvebu_pcie_find_port(pcie, bus, devfn);
+	if (!port)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	if (!mvebu_pcie_link_up(port))
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	/*
+	 * We only support access to the non-extended configuration
+	 * space when using the WA access method (or we would have to
+	 * sacrifice 256M of CPU virtual address space.)
+	 */
+	if (where >= 0x100) {
+		*val = 0xffffffff;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	return orion_pcie_rd_conf_wa(ORION5X_PCIE_WA_VIRT_BASE, bus, devfn, where, size, val);
+}
+
 static int mvebu_pcie_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1663,6 +1711,16 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 	bridge->align_resource = mvebu_pcie_align_resource;
 	bridge->map_irq = mvebu_pcie_map_irq;
 
+	if (of_machine_is_compatible("marvell,orion5x-88f5181")) {
+		dev_info(dev, "Applying Orion-1/Orion-NAS PCIe config read transaction workaround\n");
+
+		mvebu_pcie_child_ops.read = mvebu_pcie_child_rd_conf_wa;
+		mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_WA_TARGET,
+					    ORION_MBUS_PCIE_WA_ATTR,
+					    ORION5X_PCIE_WA_PHYS_BASE,
+					    ORION5X_PCIE_WA_SIZE);
+	}
+
 	return pci_host_probe(bridge);
 }
 
@@ -1733,6 +1791,7 @@ static const struct of_device_id mvebu_pcie_of_match_table[] = {
 	{ .compatible = "marvell,armada-370-pcie", },
 	{ .compatible = "marvell,dove-pcie", },
 	{ .compatible = "marvell,kirkwood-pcie", },
+	{ .compatible = "marvell,orion5x-pcie", },
 	{},
 };
 
-- 
2.25.1

[PATCH v2 2/2] PCI: mvebu: add support for orion5x

[Mauri Sandberg]

Add support for orion5x PCIe controller.

There is Orion-specific errata that config space via CF8/CFC registers
is broken. Workaround documented in errata documented (linked from above
documentation) does not work when DMA is used and instead other
undocumented workaround is needed which maps config space to memory
(and therefore avoids usage of broken CF8/CFC memory mapped registers).

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
Cc: Pali Rohár <pali@kernel.org>
---
v1 -> v2:
 - do pcie related mvebu windows and remaps in pcie_setup()
---
 arch/arm/mach-orion5x/common.c     | 13 -------
 arch/arm/mach-orion5x/pci.c        | 14 +++++++
 drivers/pci/controller/Kconfig     |  2 +-
 drivers/pci/controller/pci-mvebu.c | 59 ++++++++++++++++++++++++++++++
 4 files changed, 74 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index 7bcb41137bbf..9d8be5ce1266 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -231,19 +231,6 @@ void __init orion5x_init_early(void)
 
 void orion5x_setup_wins(void)
 {
-	/*
-	 * The PCIe windows will no longer be statically allocated
-	 * here once Orion5x is migrated to the pci-mvebu driver.
-	 */
-	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
-					  ORION_MBUS_PCIE_IO_ATTR,
-					  ORION5X_PCIE_IO_PHYS_BASE,
-					  ORION5X_PCIE_IO_SIZE,
-					  ORION5X_PCIE_IO_BUS_BASE);
-	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
-				    ORION_MBUS_PCIE_MEM_ATTR,
-				    ORION5X_PCIE_MEM_PHYS_BASE,
-				    ORION5X_PCIE_MEM_SIZE);
 	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
 					  ORION_MBUS_PCI_IO_ATTR,
 					  ORION5X_PCI_IO_PHYS_BASE,
diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion5x/pci.c
index 9574c73f3c03..7c4e2f355cc7 100644
--- a/arch/arm/mach-orion5x/pci.c
+++ b/arch/arm/mach-orion5x/pci.c
@@ -150,6 +150,20 @@ static int __init pcie_setup(struct pci_sys_data *sys)
 	 */
 	orion_pcie_setup(PCIE_BASE);
 
+	/*
+	 * The PCIe windows will no longer be statically allocated
+	 * here once Orion5x is migrated to the pci-mvebu driver.
+	 */
+	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
+					  ORION_MBUS_PCIE_IO_ATTR,
+					  ORION5X_PCIE_IO_PHYS_BASE,
+					  ORION5X_PCIE_IO_SIZE,
+					  ORION5X_PCIE_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
+				    ORION_MBUS_PCIE_MEM_ATTR,
+				    ORION5X_PCIE_MEM_PHYS_BASE,
+				    ORION5X_PCIE_MEM_SIZE);
+
 	/*
 	 * Check whether to apply Orion-1/Orion-NAS PCIe config
 	 * read transaction workaround.
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index b8d96d38064d..a249375837f0 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -5,7 +5,7 @@ menu "PCI controller drivers"
 
 config PCI_MVEBU
 	tristate "Marvell EBU PCIe controller"
-	depends on ARCH_MVEBU || ARCH_DOVE || COMPILE_TEST
+	depends on ARCH_MVEBU || ARCH_DOVE || ARCH_ORION5X || COMPILE_TEST
 	depends on MVEBU_MBUS
 	depends on ARM
 	depends on OF
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index c1ffdb06c971..1d3052aa7e49 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -1487,6 +1487,54 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie)
 	return 0;
 }
 
+static int orion_pcie_rd_conf_wa(void __iomem *wa_base, struct pci_bus *bus,
+			  u32 devfn, int where, int size, u32 *val)
+{
+	*val = readl(wa_base + (PCIE_CONF_BUS(bus->number) |
+				PCIE_CONF_DEV(PCI_SLOT(devfn)) |
+				PCIE_CONF_FUNC(PCI_FUNC(devfn)) |
+				PCIE_CONF_REG(where)));
+
+	if (size == 1)
+		*val = (*val >> (8 * (where & 3))) & 0xff;
+	else if (size == 2)
+		*val = (*val >> (8 * (where & 3))) & 0xffff;
+
+	return PCIBIOS_SUCCESSFUL;
+}
+
+/* Relevant only for Orion-1/Orion-NAS */
+#define ORION5X_PCIE_WA_PHYS_BASE	0xf0000000
+#define ORION5X_PCIE_WA_VIRT_BASE	IOMEM(0xfd000000)
+#define ORION5X_PCIE_WA_SIZE		SZ_16M
+#define ORION_MBUS_PCIE_WA_TARGET	0x04
+#define ORION_MBUS_PCIE_WA_ATTR		0x79
+
+static int mvebu_pcie_child_rd_conf_wa(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val)
+{
+	struct mvebu_pcie *pcie = bus->sysdata;
+	struct mvebu_pcie_port *port;
+
+	port = mvebu_pcie_find_port(pcie, bus, devfn);
+	if (!port)
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	if (!mvebu_pcie_link_up(port))
+		return PCIBIOS_DEVICE_NOT_FOUND;
+
+	/*
+	 * We only support access to the non-extended configuration
+	 * space when using the WA access method (or we would have to
+	 * sacrifice 256M of CPU virtual address space.)
+	 */
+	if (where >= 0x100) {
+		*val = 0xffffffff;
+		return PCIBIOS_DEVICE_NOT_FOUND;
+	}
+
+	return orion_pcie_rd_conf_wa(ORION5X_PCIE_WA_VIRT_BASE, bus, devfn, where, size, val);
+}
+
 static int mvebu_pcie_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
@@ -1663,6 +1711,16 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 	bridge->align_resource = mvebu_pcie_align_resource;
 	bridge->map_irq = mvebu_pcie_map_irq;
 
+	if (of_machine_is_compatible("marvell,orion5x-88f5181")) {
+		dev_info(dev, "Applying Orion-1/Orion-NAS PCIe config read transaction workaround\n");
+
+		mvebu_pcie_child_ops.read = mvebu_pcie_child_rd_conf_wa;
+		mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_WA_TARGET,
+					    ORION_MBUS_PCIE_WA_ATTR,
+					    ORION5X_PCIE_WA_PHYS_BASE,
+					    ORION5X_PCIE_WA_SIZE);
+	}
+
 	return pci_host_probe(bridge);
 }
 
@@ -1733,6 +1791,7 @@ static const struct of_device_id mvebu_pcie_of_match_table[] = {
 	{ .compatible = "marvell,armada-370-pcie", },
 	{ .compatible = "marvell,dove-pcie", },
 	{ .compatible = "marvell,kirkwood-pcie", },
+	{ .compatible = "marvell,orion5x-pcie", },
 	{},
 };
 
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 0/2] PCI: mvebu: add support for orion soc

[Pali Rohár]

On Tuesday 02 August 2022 20:34:21 Mauri Sandberg wrote:
> Hello all,
> 
> Here a cleaned up version of the previous series.
> 
> Changes
>  - instead of removing PCIe related mvebu windows add them in pcie_setup()
> 
> I intentionally left the ORION5X_PCIE_WA_VIRT_BASE in place as all pieces
> in the puzzle have not found their place yet. It will be replaced with
> ioremap() or similar when the problem of passing the address to
> configuration space from a device tree is solved.

Hello all, could you please look at the issue how to write
representation of PCIe config space in device tree?
https://lore.kernel.org/linux-devicetree/20220710225108.bgedria6igtqpz5l@pali/

Without it we cannot finish this conversion of orion5x pcie code from
arch/arm to pci-mvebu.c

> Tested with DNS323 both DT and non-DT builds.
> 
> Thanks,
> Mauri
> 
> Mauri Sandberg (2):
>   dt-bindings: PCI: mvebu: Add orion5x compatible
>   PCI: mvebu: add support for orion5x
> 
>  .../devicetree/bindings/pci/mvebu-pci.txt     |  1 +
>  arch/arm/mach-orion5x/common.c                | 13 ----
>  arch/arm/mach-orion5x/pci.c                   | 14 +++++
>  drivers/pci/controller/Kconfig                |  2 +-
>  drivers/pci/controller/pci-mvebu.c            | 59 +++++++++++++++++++
>  5 files changed, 75 insertions(+), 14 deletions(-)
> 
> 
> base-commit: 7d0d3fa7339ed5a06d6608b7cde9f079eba62bb1
> --
> 2.25.1

Re: [PATCH v2 0/2] PCI: mvebu: add support for orion soc

[Pali Rohár]

On Tuesday 02 August 2022 20:34:21 Mauri Sandberg wrote:
> Hello all,
> 
> Here a cleaned up version of the previous series.
> 
> Changes
>  - instead of removing PCIe related mvebu windows add them in pcie_setup()
> 
> I intentionally left the ORION5X_PCIE_WA_VIRT_BASE in place as all pieces
> in the puzzle have not found their place yet. It will be replaced with
> ioremap() or similar when the problem of passing the address to
> configuration space from a device tree is solved.

Hello all, could you please look at the issue how to write
representation of PCIe config space in device tree?
https://lore.kernel.org/linux-devicetree/20220710225108.bgedria6igtqpz5l@pali/

Without it we cannot finish this conversion of orion5x pcie code from
arch/arm to pci-mvebu.c

> Tested with DNS323 both DT and non-DT builds.
> 
> Thanks,
> Mauri
> 
> Mauri Sandberg (2):
>   dt-bindings: PCI: mvebu: Add orion5x compatible
>   PCI: mvebu: add support for orion5x
> 
>  .../devicetree/bindings/pci/mvebu-pci.txt     |  1 +
>  arch/arm/mach-orion5x/common.c                | 13 ----
>  arch/arm/mach-orion5x/pci.c                   | 14 +++++
>  drivers/pci/controller/Kconfig                |  2 +-
>  drivers/pci/controller/pci-mvebu.c            | 59 +++++++++++++++++++
>  5 files changed, 75 insertions(+), 14 deletions(-)
> 
> 
> base-commit: 7d0d3fa7339ed5a06d6608b7cde9f079eba62bb1
> --
> 2.25.1

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/2] PCI: mvebu: add support for orion5x

[Lorenzo Pieralisi]

On Tue, Aug 02, 2022 at 08:34:23PM +0300, Mauri Sandberg wrote:
> Add support for orion5x PCIe controller.
> 
> There is Orion-specific errata that config space via CF8/CFC registers
> is broken. Workaround documented in errata documented (linked from above
> documentation) does not work when DMA is used and instead other

Linked to which documentation ?

> undocumented workaround is needed which maps config space to memory
> (and therefore avoids usage of broken CF8/CFC memory mapped registers).
> 
> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> Cc: Pali Rohár <pali@kernel.org>
> ---
> v1 -> v2:
>  - do pcie related mvebu windows and remaps in pcie_setup()
> ---
>  arch/arm/mach-orion5x/common.c     | 13 -------
>  arch/arm/mach-orion5x/pci.c        | 14 +++++++
>  drivers/pci/controller/Kconfig     |  2 +-
>  drivers/pci/controller/pci-mvebu.c | 59 ++++++++++++++++++++++++++++++
>  4 files changed, 74 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
> index 7bcb41137bbf..9d8be5ce1266 100644
> --- a/arch/arm/mach-orion5x/common.c
> +++ b/arch/arm/mach-orion5x/common.c
> @@ -231,19 +231,6 @@ void __init orion5x_init_early(void)
>  
>  void orion5x_setup_wins(void)
>  {
> -	/*
> -	 * The PCIe windows will no longer be statically allocated
> -	 * here once Orion5x is migrated to the pci-mvebu driver.
> -	 */
> -	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
> -					  ORION_MBUS_PCIE_IO_ATTR,
> -					  ORION5X_PCIE_IO_PHYS_BASE,
> -					  ORION5X_PCIE_IO_SIZE,
> -					  ORION5X_PCIE_IO_BUS_BASE);
> -	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
> -				    ORION_MBUS_PCIE_MEM_ATTR,
> -				    ORION5X_PCIE_MEM_PHYS_BASE,
> -				    ORION5X_PCIE_MEM_SIZE);
>  	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
>  					  ORION_MBUS_PCI_IO_ATTR,
>  					  ORION5X_PCI_IO_PHYS_BASE,
> diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion5x/pci.c
> index 9574c73f3c03..7c4e2f355cc7 100644
> --- a/arch/arm/mach-orion5x/pci.c
> +++ b/arch/arm/mach-orion5x/pci.c
> @@ -150,6 +150,20 @@ static int __init pcie_setup(struct pci_sys_data *sys)
>  	 */
>  	orion_pcie_setup(PCIE_BASE);
>  
> +	/*
> +	 * The PCIe windows will no longer be statically allocated
> +	 * here once Orion5x is migrated to the pci-mvebu driver.
> +	 */

Is this comment still relevant ? And more importantly, may I ask
you why this code move in this hunk ? I think, whatever the reason
is, that deserves a comment.

> +	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
> +					  ORION_MBUS_PCIE_IO_ATTR,
> +					  ORION5X_PCIE_IO_PHYS_BASE,
> +					  ORION5X_PCIE_IO_SIZE,
> +					  ORION5X_PCIE_IO_BUS_BASE);
> +	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
> +				    ORION_MBUS_PCIE_MEM_ATTR,
> +				    ORION5X_PCIE_MEM_PHYS_BASE,
> +				    ORION5X_PCIE_MEM_SIZE);
> +
>  	/*
>  	 * Check whether to apply Orion-1/Orion-NAS PCIe config
>  	 * read transaction workaround.
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index b8d96d38064d..a249375837f0 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -5,7 +5,7 @@ menu "PCI controller drivers"
>  
>  config PCI_MVEBU
>  	tristate "Marvell EBU PCIe controller"
> -	depends on ARCH_MVEBU || ARCH_DOVE || COMPILE_TEST
> +	depends on ARCH_MVEBU || ARCH_DOVE || ARCH_ORION5X || COMPILE_TEST
>  	depends on MVEBU_MBUS
>  	depends on ARM
>  	depends on OF
> diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
> index c1ffdb06c971..1d3052aa7e49 100644
> --- a/drivers/pci/controller/pci-mvebu.c
> +++ b/drivers/pci/controller/pci-mvebu.c
> @@ -1487,6 +1487,54 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie)
>  	return 0;
>  }
>  
> +static int orion_pcie_rd_conf_wa(void __iomem *wa_base, struct pci_bus *bus,
> +			  u32 devfn, int where, int size, u32 *val)
> +{
> +	*val = readl(wa_base + (PCIE_CONF_BUS(bus->number) |
> +				PCIE_CONF_DEV(PCI_SLOT(devfn)) |
> +				PCIE_CONF_FUNC(PCI_FUNC(devfn)) |
> +				PCIE_CONF_REG(where)));
> +
> +	if (size == 1)
> +		*val = (*val >> (8 * (where & 3))) & 0xff;
> +	else if (size == 2)
> +		*val = (*val >> (8 * (where & 3))) & 0xffff;
> +
> +	return PCIBIOS_SUCCESSFUL;
> +}
> +
> +/* Relevant only for Orion-1/Orion-NAS */
> +#define ORION5X_PCIE_WA_PHYS_BASE	0xf0000000
> +#define ORION5X_PCIE_WA_VIRT_BASE	IOMEM(0xfd000000)
> +#define ORION5X_PCIE_WA_SIZE		SZ_16M
> +#define ORION_MBUS_PCIE_WA_TARGET	0x04
> +#define ORION_MBUS_PCIE_WA_ATTR		0x79
> +
> +static int mvebu_pcie_child_rd_conf_wa(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val)
> +{
> +	struct mvebu_pcie *pcie = bus->sysdata;
> +	struct mvebu_pcie_port *port;
> +
> +	port = mvebu_pcie_find_port(pcie, bus, devfn);
> +	if (!port)
> +		return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +	if (!mvebu_pcie_link_up(port))
> +		return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +	/*
> +	 * We only support access to the non-extended configuration
> +	 * space when using the WA access method (or we would have to
> +	 * sacrifice 256M of CPU virtual address space.)

Please expand the comment - future reviewers and developers may need
this information to understand this choice, me included.

Lorenzo

> +	 */
> +	if (where >= 0x100) {
> +		*val = 0xffffffff;
> +		return PCIBIOS_DEVICE_NOT_FOUND;
> +	}
> +
> +	return orion_pcie_rd_conf_wa(ORION5X_PCIE_WA_VIRT_BASE, bus, devfn, where, size, val);
> +}
> +
>  static int mvebu_pcie_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> @@ -1663,6 +1711,16 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
>  	bridge->align_resource = mvebu_pcie_align_resource;
>  	bridge->map_irq = mvebu_pcie_map_irq;
>  
> +	if (of_machine_is_compatible("marvell,orion5x-88f5181")) {
> +		dev_info(dev, "Applying Orion-1/Orion-NAS PCIe config read transaction workaround\n");
> +
> +		mvebu_pcie_child_ops.read = mvebu_pcie_child_rd_conf_wa;
> +		mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_WA_TARGET,
> +					    ORION_MBUS_PCIE_WA_ATTR,
> +					    ORION5X_PCIE_WA_PHYS_BASE,
> +					    ORION5X_PCIE_WA_SIZE);
> +	}
> +
>  	return pci_host_probe(bridge);
>  }
>  
> @@ -1733,6 +1791,7 @@ static const struct of_device_id mvebu_pcie_of_match_table[] = {
>  	{ .compatible = "marvell,armada-370-pcie", },
>  	{ .compatible = "marvell,dove-pcie", },
>  	{ .compatible = "marvell,kirkwood-pcie", },
> +	{ .compatible = "marvell,orion5x-pcie", },
>  	{},
>  };
>  
> -- 
> 2.25.1
> 

Re: [PATCH v2 2/2] PCI: mvebu: add support for orion5x

[Lorenzo Pieralisi]

On Tue, Aug 02, 2022 at 08:34:23PM +0300, Mauri Sandberg wrote:
> Add support for orion5x PCIe controller.
> 
> There is Orion-specific errata that config space via CF8/CFC registers
> is broken. Workaround documented in errata documented (linked from above
> documentation) does not work when DMA is used and instead other

Linked to which documentation ?

> undocumented workaround is needed which maps config space to memory
> (and therefore avoids usage of broken CF8/CFC memory mapped registers).
> 
> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> Cc: Pali Rohár <pali@kernel.org>
> ---
> v1 -> v2:
>  - do pcie related mvebu windows and remaps in pcie_setup()
> ---
>  arch/arm/mach-orion5x/common.c     | 13 -------
>  arch/arm/mach-orion5x/pci.c        | 14 +++++++
>  drivers/pci/controller/Kconfig     |  2 +-
>  drivers/pci/controller/pci-mvebu.c | 59 ++++++++++++++++++++++++++++++
>  4 files changed, 74 insertions(+), 14 deletions(-)
> 
> diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
> index 7bcb41137bbf..9d8be5ce1266 100644
> --- a/arch/arm/mach-orion5x/common.c
> +++ b/arch/arm/mach-orion5x/common.c
> @@ -231,19 +231,6 @@ void __init orion5x_init_early(void)
>  
>  void orion5x_setup_wins(void)
>  {
> -	/*
> -	 * The PCIe windows will no longer be statically allocated
> -	 * here once Orion5x is migrated to the pci-mvebu driver.
> -	 */
> -	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
> -					  ORION_MBUS_PCIE_IO_ATTR,
> -					  ORION5X_PCIE_IO_PHYS_BASE,
> -					  ORION5X_PCIE_IO_SIZE,
> -					  ORION5X_PCIE_IO_BUS_BASE);
> -	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
> -				    ORION_MBUS_PCIE_MEM_ATTR,
> -				    ORION5X_PCIE_MEM_PHYS_BASE,
> -				    ORION5X_PCIE_MEM_SIZE);
>  	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
>  					  ORION_MBUS_PCI_IO_ATTR,
>  					  ORION5X_PCI_IO_PHYS_BASE,
> diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion5x/pci.c
> index 9574c73f3c03..7c4e2f355cc7 100644
> --- a/arch/arm/mach-orion5x/pci.c
> +++ b/arch/arm/mach-orion5x/pci.c
> @@ -150,6 +150,20 @@ static int __init pcie_setup(struct pci_sys_data *sys)
>  	 */
>  	orion_pcie_setup(PCIE_BASE);
>  
> +	/*
> +	 * The PCIe windows will no longer be statically allocated
> +	 * here once Orion5x is migrated to the pci-mvebu driver.
> +	 */

Is this comment still relevant ? And more importantly, may I ask
you why this code move in this hunk ? I think, whatever the reason
is, that deserves a comment.

> +	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
> +					  ORION_MBUS_PCIE_IO_ATTR,
> +					  ORION5X_PCIE_IO_PHYS_BASE,
> +					  ORION5X_PCIE_IO_SIZE,
> +					  ORION5X_PCIE_IO_BUS_BASE);
> +	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
> +				    ORION_MBUS_PCIE_MEM_ATTR,
> +				    ORION5X_PCIE_MEM_PHYS_BASE,
> +				    ORION5X_PCIE_MEM_SIZE);
> +
>  	/*
>  	 * Check whether to apply Orion-1/Orion-NAS PCIe config
>  	 * read transaction workaround.
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index b8d96d38064d..a249375837f0 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -5,7 +5,7 @@ menu "PCI controller drivers"
>  
>  config PCI_MVEBU
>  	tristate "Marvell EBU PCIe controller"
> -	depends on ARCH_MVEBU || ARCH_DOVE || COMPILE_TEST
> +	depends on ARCH_MVEBU || ARCH_DOVE || ARCH_ORION5X || COMPILE_TEST
>  	depends on MVEBU_MBUS
>  	depends on ARM
>  	depends on OF
> diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
> index c1ffdb06c971..1d3052aa7e49 100644
> --- a/drivers/pci/controller/pci-mvebu.c
> +++ b/drivers/pci/controller/pci-mvebu.c
> @@ -1487,6 +1487,54 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie)
>  	return 0;
>  }
>  
> +static int orion_pcie_rd_conf_wa(void __iomem *wa_base, struct pci_bus *bus,
> +			  u32 devfn, int where, int size, u32 *val)
> +{
> +	*val = readl(wa_base + (PCIE_CONF_BUS(bus->number) |
> +				PCIE_CONF_DEV(PCI_SLOT(devfn)) |
> +				PCIE_CONF_FUNC(PCI_FUNC(devfn)) |
> +				PCIE_CONF_REG(where)));
> +
> +	if (size == 1)
> +		*val = (*val >> (8 * (where & 3))) & 0xff;
> +	else if (size == 2)
> +		*val = (*val >> (8 * (where & 3))) & 0xffff;
> +
> +	return PCIBIOS_SUCCESSFUL;
> +}
> +
> +/* Relevant only for Orion-1/Orion-NAS */
> +#define ORION5X_PCIE_WA_PHYS_BASE	0xf0000000
> +#define ORION5X_PCIE_WA_VIRT_BASE	IOMEM(0xfd000000)
> +#define ORION5X_PCIE_WA_SIZE		SZ_16M
> +#define ORION_MBUS_PCIE_WA_TARGET	0x04
> +#define ORION_MBUS_PCIE_WA_ATTR		0x79
> +
> +static int mvebu_pcie_child_rd_conf_wa(struct pci_bus *bus, u32 devfn, int where, int size, u32 *val)
> +{
> +	struct mvebu_pcie *pcie = bus->sysdata;
> +	struct mvebu_pcie_port *port;
> +
> +	port = mvebu_pcie_find_port(pcie, bus, devfn);
> +	if (!port)
> +		return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +	if (!mvebu_pcie_link_up(port))
> +		return PCIBIOS_DEVICE_NOT_FOUND;
> +
> +	/*
> +	 * We only support access to the non-extended configuration
> +	 * space when using the WA access method (or we would have to
> +	 * sacrifice 256M of CPU virtual address space.)

Please expand the comment - future reviewers and developers may need
this information to understand this choice, me included.

Lorenzo

> +	 */
> +	if (where >= 0x100) {
> +		*val = 0xffffffff;
> +		return PCIBIOS_DEVICE_NOT_FOUND;
> +	}
> +
> +	return orion_pcie_rd_conf_wa(ORION5X_PCIE_WA_VIRT_BASE, bus, devfn, where, size, val);
> +}
> +
>  static int mvebu_pcie_probe(struct platform_device *pdev)
>  {
>  	struct device *dev = &pdev->dev;
> @@ -1663,6 +1711,16 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
>  	bridge->align_resource = mvebu_pcie_align_resource;
>  	bridge->map_irq = mvebu_pcie_map_irq;
>  
> +	if (of_machine_is_compatible("marvell,orion5x-88f5181")) {
> +		dev_info(dev, "Applying Orion-1/Orion-NAS PCIe config read transaction workaround\n");
> +
> +		mvebu_pcie_child_ops.read = mvebu_pcie_child_rd_conf_wa;
> +		mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_WA_TARGET,
> +					    ORION_MBUS_PCIE_WA_ATTR,
> +					    ORION5X_PCIE_WA_PHYS_BASE,
> +					    ORION5X_PCIE_WA_SIZE);
> +	}
> +
>  	return pci_host_probe(bridge);
>  }
>  
> @@ -1733,6 +1791,7 @@ static const struct of_device_id mvebu_pcie_of_match_table[] = {
>  	{ .compatible = "marvell,armada-370-pcie", },
>  	{ .compatible = "marvell,dove-pcie", },
>  	{ .compatible = "marvell,kirkwood-pcie", },
> +	{ .compatible = "marvell,orion5x-pcie", },
>  	{},
>  };
>  
> -- 
> 2.25.1
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/2] PCI: mvebu: add support for orion5x

[Pali Rohár]

On Thursday 25 August 2022 17:15:36 Lorenzo Pieralisi wrote:
> On Tue, Aug 02, 2022 at 08:34:23PM +0300, Mauri Sandberg wrote:
> > Add support for orion5x PCIe controller.
> > 
> > There is Orion-specific errata that config space via CF8/CFC registers
> > is broken. Workaround documented in errata documented (linked from above
> > documentation) does not work when DMA is used and instead other
> 
> Linked to which documentation ?

Hello! Orion Errata document is linked from kernel doc:
https://www.kernel.org/doc/html/latest/arm/marvell.html

Re: [PATCH v2 2/2] PCI: mvebu: add support for orion5x

[Pali Rohár]

On Thursday 25 August 2022 17:15:36 Lorenzo Pieralisi wrote:
> On Tue, Aug 02, 2022 at 08:34:23PM +0300, Mauri Sandberg wrote:
> > Add support for orion5x PCIe controller.
> > 
> > There is Orion-specific errata that config space via CF8/CFC registers
> > is broken. Workaround documented in errata documented (linked from above
> > documentation) does not work when DMA is used and instead other
> 
> Linked to which documentation ?

Hello! Orion Errata document is linked from kernel doc:
https://www.kernel.org/doc/html/latest/arm/marvell.html

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v2 2/2] PCI: mvebu: add support for orion5x

[Lorenzo Pieralisi]

On Thu, Aug 25, 2022 at 06:00:51PM +0200, Pali Rohár wrote:
> On Thursday 25 August 2022 17:15:36 Lorenzo Pieralisi wrote:
> > On Tue, Aug 02, 2022 at 08:34:23PM +0300, Mauri Sandberg wrote:
> > > Add support for orion5x PCIe controller.
> > > 
> > > There is Orion-specific errata that config space via CF8/CFC registers
> > > is broken. Workaround documented in errata documented (linked from above
> > > documentation) does not work when DMA is used and instead other
> > 
> > Linked to which documentation ?
> 
> Hello! Orion Errata document is linked from kernel doc:
> https://www.kernel.org/doc/html/latest/arm/marvell.html

Add a Link: tag to the patch, thanks.

Lorenzo

Re: [PATCH v2 2/2] PCI: mvebu: add support for orion5x

[Lorenzo Pieralisi]

On Thu, Aug 25, 2022 at 06:00:51PM +0200, Pali Rohár wrote:
> On Thursday 25 August 2022 17:15:36 Lorenzo Pieralisi wrote:
> > On Tue, Aug 02, 2022 at 08:34:23PM +0300, Mauri Sandberg wrote:
> > > Add support for orion5x PCIe controller.
> > > 
> > > There is Orion-specific errata that config space via CF8/CFC registers
> > > is broken. Workaround documented in errata documented (linked from above
> > > documentation) does not work when DMA is used and instead other
> > 
> > Linked to which documentation ?
> 
> Hello! Orion Errata document is linked from kernel doc:
> https://www.kernel.org/doc/html/latest/arm/marvell.html

Add a Link: tag to the patch, thanks.

Lorenzo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 0/7] PCI: mvebu: add support for orion soc

[Pali Rohár]

Hello! This patch series add support for Orion PCIe controller into
pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
to parse all physical addresses from device tree files according to
mvebu-pci.txt documentation, allow access to all extended PCIe config
space registers and use modern kernel API pci_remap_cfgspace() and
mvebu_mbus_add_window_by_id() fir mapping PCIe config space.

Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
there because this change and it is de-facto API between dts files and
kernel used for a long time. Note that it is misused according to PCI
device tree bindings, but we have to follow this Marvell bindings to do
not introduce backward incompatibility issues for other non-Orion
platforms.

Mauri tested these changes on DNS323 board with both DT and non-DT builds.
PCIe AER is working too (one of the feature which proved that access to
extended PCIe config registers is working fine).

After this patch is accepted we are planning to look at existing Orion
arch specific code and covert it to use this new DT based pci-mvebu.c
code. Later this would allow to kill arch specific Orion PCIe code,
which is in arch/arm/plat-orion/pcie.c and parts also in file
arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).

This patch series depends on another patches:
https://lore.kernel.org/linux-pci/20220524122817.7199-1-pali@kernel.org/
https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/

Mauri Sandberg (2):
  bus: mvebu-mbus: add configuration space aperture
  dt-bindings: PCI: mvebu: Add orion5x compatible

Pali Rohár (5):
  ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
    pcie_setup()
  PCI: mvebu: Remove unused busn member
  PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
  PCI: mvebu: Add support for Orion PCIe controller
  ARM: dts: orion5x: Add PCIe node

 .../devicetree/bindings/pci/mvebu-pci.txt     |   4 +-
 arch/arm/boot/dts/orion5x.dtsi                |  51 +++++
 arch/arm/mach-orion5x/common.c                |  13 --
 arch/arm/mach-orion5x/pci.c                   |  14 ++
 drivers/bus/mvebu-mbus.c                      |  26 ++-
 drivers/pci/controller/Kconfig                |   4 +-
 drivers/pci/controller/pci-mvebu.c            | 202 ++++++++++++++----
 include/linux/mbus.h                          |   1 +
 8 files changed, 256 insertions(+), 59 deletions(-)

-- 
2.20.1

[PATCH v3 0/7] PCI: mvebu: add support for orion soc

[Pali Rohár]

Hello! This patch series add support for Orion PCIe controller into
pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
to parse all physical addresses from device tree files according to
mvebu-pci.txt documentation, allow access to all extended PCIe config
space registers and use modern kernel API pci_remap_cfgspace() and
mvebu_mbus_add_window_by_id() fir mapping PCIe config space.

Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
there because this change and it is de-facto API between dts files and
kernel used for a long time. Note that it is misused according to PCI
device tree bindings, but we have to follow this Marvell bindings to do
not introduce backward incompatibility issues for other non-Orion
platforms.

Mauri tested these changes on DNS323 board with both DT and non-DT builds.
PCIe AER is working too (one of the feature which proved that access to
extended PCIe config registers is working fine).

After this patch is accepted we are planning to look at existing Orion
arch specific code and covert it to use this new DT based pci-mvebu.c
code. Later this would allow to kill arch specific Orion PCIe code,
which is in arch/arm/plat-orion/pcie.c and parts also in file
arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).

This patch series depends on another patches:
https://lore.kernel.org/linux-pci/20220524122817.7199-1-pali@kernel.org/
https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/

Mauri Sandberg (2):
  bus: mvebu-mbus: add configuration space aperture
  dt-bindings: PCI: mvebu: Add orion5x compatible

Pali Rohár (5):
  ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
    pcie_setup()
  PCI: mvebu: Remove unused busn member
  PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
  PCI: mvebu: Add support for Orion PCIe controller
  ARM: dts: orion5x: Add PCIe node

 .../devicetree/bindings/pci/mvebu-pci.txt     |   4 +-
 arch/arm/boot/dts/orion5x.dtsi                |  51 +++++
 arch/arm/mach-orion5x/common.c                |  13 --
 arch/arm/mach-orion5x/pci.c                   |  14 ++
 drivers/bus/mvebu-mbus.c                      |  26 ++-
 drivers/pci/controller/Kconfig                |   4 +-
 drivers/pci/controller/pci-mvebu.c            | 202 ++++++++++++++----
 include/linux/mbus.h                          |   1 +
 8 files changed, 256 insertions(+), 59 deletions(-)

-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 1/7] ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to pcie_setup()

[Pali Rohár]

This would allow to migrate Orion PCIe code to pci-mvebu.c driver as this
driver reads mapping information from device tree files and does not relay
on static mappings.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
Changes in v3:
* Split it from pci-mvebu.c change to separate patch
---
 arch/arm/mach-orion5x/common.c | 13 -------------
 arch/arm/mach-orion5x/pci.c    | 14 ++++++++++++++
 2 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index 2e711b7252c6..df5e7b237946 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -228,19 +228,6 @@ void __init orion5x_init_early(void)
 
 void orion5x_setup_wins(void)
 {
-	/*
-	 * The PCIe windows will no longer be statically allocated
-	 * here once Orion5x is migrated to the pci-mvebu driver.
-	 */
-	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
-					  ORION_MBUS_PCIE_IO_ATTR,
-					  ORION5X_PCIE_IO_PHYS_BASE,
-					  ORION5X_PCIE_IO_SIZE,
-					  ORION5X_PCIE_IO_BUS_BASE);
-	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
-				    ORION_MBUS_PCIE_MEM_ATTR,
-				    ORION5X_PCIE_MEM_PHYS_BASE,
-				    ORION5X_PCIE_MEM_SIZE);
 	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
 					  ORION_MBUS_PCI_IO_ATTR,
 					  ORION5X_PCI_IO_PHYS_BASE,
diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion5x/pci.c
index 888fdc9099c5..e0836be92f3f 100644
--- a/arch/arm/mach-orion5x/pci.c
+++ b/arch/arm/mach-orion5x/pci.c
@@ -147,6 +147,20 @@ static int __init pcie_setup(struct pci_sys_data *sys)
 	 */
 	orion_pcie_setup(PCIE_BASE);
 
+	/*
+	 * The PCIe windows will no longer be statically allocated
+	 * here once Orion5x is migrated to the pci-mvebu driver.
+	 */
+	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
+					  ORION_MBUS_PCIE_IO_ATTR,
+					  ORION5X_PCIE_IO_PHYS_BASE,
+					  ORION5X_PCIE_IO_SIZE,
+					  ORION5X_PCIE_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
+				    ORION_MBUS_PCIE_MEM_ATTR,
+				    ORION5X_PCIE_MEM_PHYS_BASE,
+				    ORION5X_PCIE_MEM_SIZE);
+
 	/*
 	 * Check whether to apply Orion-1/Orion-NAS PCIe config
 	 * read transaction workaround.
-- 
2.20.1

[PATCH v3 1/7] ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to pcie_setup()

[Pali Rohár]

This would allow to migrate Orion PCIe code to pci-mvebu.c driver as this
driver reads mapping information from device tree files and does not relay
on static mappings.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
Changes in v3:
* Split it from pci-mvebu.c change to separate patch
---
 arch/arm/mach-orion5x/common.c | 13 -------------
 arch/arm/mach-orion5x/pci.c    | 14 ++++++++++++++
 2 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-orion5x/common.c b/arch/arm/mach-orion5x/common.c
index 2e711b7252c6..df5e7b237946 100644
--- a/arch/arm/mach-orion5x/common.c
+++ b/arch/arm/mach-orion5x/common.c
@@ -228,19 +228,6 @@ void __init orion5x_init_early(void)
 
 void orion5x_setup_wins(void)
 {
-	/*
-	 * The PCIe windows will no longer be statically allocated
-	 * here once Orion5x is migrated to the pci-mvebu driver.
-	 */
-	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
-					  ORION_MBUS_PCIE_IO_ATTR,
-					  ORION5X_PCIE_IO_PHYS_BASE,
-					  ORION5X_PCIE_IO_SIZE,
-					  ORION5X_PCIE_IO_BUS_BASE);
-	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
-				    ORION_MBUS_PCIE_MEM_ATTR,
-				    ORION5X_PCIE_MEM_PHYS_BASE,
-				    ORION5X_PCIE_MEM_SIZE);
 	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCI_IO_TARGET,
 					  ORION_MBUS_PCI_IO_ATTR,
 					  ORION5X_PCI_IO_PHYS_BASE,
diff --git a/arch/arm/mach-orion5x/pci.c b/arch/arm/mach-orion5x/pci.c
index 888fdc9099c5..e0836be92f3f 100644
--- a/arch/arm/mach-orion5x/pci.c
+++ b/arch/arm/mach-orion5x/pci.c
@@ -147,6 +147,20 @@ static int __init pcie_setup(struct pci_sys_data *sys)
 	 */
 	orion_pcie_setup(PCIE_BASE);
 
+	/*
+	 * The PCIe windows will no longer be statically allocated
+	 * here once Orion5x is migrated to the pci-mvebu driver.
+	 */
+	mvebu_mbus_add_window_remap_by_id(ORION_MBUS_PCIE_IO_TARGET,
+					  ORION_MBUS_PCIE_IO_ATTR,
+					  ORION5X_PCIE_IO_PHYS_BASE,
+					  ORION5X_PCIE_IO_SIZE,
+					  ORION5X_PCIE_IO_BUS_BASE);
+	mvebu_mbus_add_window_by_id(ORION_MBUS_PCIE_MEM_TARGET,
+				    ORION_MBUS_PCIE_MEM_ATTR,
+				    ORION5X_PCIE_MEM_PHYS_BASE,
+				    ORION5X_PCIE_MEM_SIZE);
+
 	/*
 	 * Check whether to apply Orion-1/Orion-NAS PCIe config
 	 * read transaction workaround.
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 2/7] bus: mvebu-mbus: add configuration space aperture

[Pali Rohár]

From: Mauri Sandberg <maukka@ext.kapsi.fi>

Adds a new resource for describing PCI configuration space and accessor for it.

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 drivers/bus/mvebu-mbus.c | 26 +++++++++++++++++++++++---
 include/linux/mbus.h     |  1 +
 2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 5dc2669432ba..9702c6ddbbe6 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -139,6 +139,7 @@ struct mvebu_mbus_state {
 	struct dentry *debugfs_devs;
 	struct resource pcie_mem_aperture;
 	struct resource pcie_io_aperture;
+	struct resource pcie_cfg_aperture;
 	const struct mvebu_mbus_soc_data *soc;
 	int hw_io_coherency;
 
@@ -950,6 +951,14 @@ void mvebu_mbus_get_pcie_io_aperture(struct resource *res)
 }
 EXPORT_SYMBOL_GPL(mvebu_mbus_get_pcie_io_aperture);
 
+void mvebu_mbus_get_pcie_cfg_aperture(struct resource *res)
+{
+	if (!res)
+		return;
+	*res = mbus_state.pcie_cfg_aperture;
+}
+EXPORT_SYMBOL_GPL(mvebu_mbus_get_pcie_cfg_aperture);
+
 int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr)
 {
 	const struct mbus_dram_target_info *dram;
@@ -1277,7 +1286,8 @@ static int __init mbus_dt_setup(struct mvebu_mbus_state *mbus,
 
 static void __init mvebu_mbus_get_pcie_resources(struct device_node *np,
 						 struct resource *mem,
-						 struct resource *io)
+						 struct resource *io,
+						 struct resource *cfg)
 {
 	u32 reg[2];
 	int ret;
@@ -1290,6 +1300,8 @@ static void __init mvebu_mbus_get_pcie_resources(struct device_node *np,
 	mem->end = -1;
 	memset(io, 0, sizeof(struct resource));
 	io->end = -1;
+	memset(cfg, 0, sizeof(struct resource));
+	cfg->end = -1;
 
 	ret = of_property_read_u32_array(np, "pcie-mem-aperture", reg, ARRAY_SIZE(reg));
 	if (!ret) {
@@ -1304,6 +1316,13 @@ static void __init mvebu_mbus_get_pcie_resources(struct device_node *np,
 		io->end = io->start + reg[1] - 1;
 		io->flags = IORESOURCE_IO;
 	}
+
+	ret = of_property_read_u32_array(np, "pcie-cfg-aperture", reg, ARRAY_SIZE(reg));
+	if (!ret) {
+		cfg->start = reg[0];
+		cfg->end = cfg->start + reg[1] - 1;
+		cfg->flags = IORESOURCE_MEM;
+	}
 }
 
 int __init mvebu_mbus_dt_init(bool is_coherent)
@@ -1359,9 +1378,10 @@ int __init mvebu_mbus_dt_init(bool is_coherent)
 
 	mbus_state.hw_io_coherency = is_coherent;
 
-	/* Get optional pcie-{mem,io}-aperture properties */
+	/* Get optional pcie-{mem,io,cfg}-aperture properties */
 	mvebu_mbus_get_pcie_resources(np, &mbus_state.pcie_mem_aperture,
-					  &mbus_state.pcie_io_aperture);
+					  &mbus_state.pcie_io_aperture,
+					  &mbus_state.pcie_cfg_aperture);
 
 	ret = mvebu_mbus_common_init(&mbus_state,
 				     mbuswins_res.start,
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 4773145246ed..525b56ddd0c2 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -86,6 +86,7 @@ static inline int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size,
 int mvebu_mbus_save_cpu_target(u32 __iomem *store_addr);
 void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
 void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
+void mvebu_mbus_get_pcie_cfg_aperture(struct resource *res);
 int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr);
 int mvebu_mbus_add_window_remap_by_id(unsigned int target,
 				      unsigned int attribute,
-- 
2.20.1

[PATCH v3 2/7] bus: mvebu-mbus: add configuration space aperture

[Pali Rohár]

From: Mauri Sandberg <maukka@ext.kapsi.fi>

Adds a new resource for describing PCI configuration space and accessor for it.

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
Signed-off-by: Pali Rohár <pali@kernel.org>
---
 drivers/bus/mvebu-mbus.c | 26 +++++++++++++++++++++++---
 include/linux/mbus.h     |  1 +
 2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index 5dc2669432ba..9702c6ddbbe6 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -139,6 +139,7 @@ struct mvebu_mbus_state {
 	struct dentry *debugfs_devs;
 	struct resource pcie_mem_aperture;
 	struct resource pcie_io_aperture;
+	struct resource pcie_cfg_aperture;
 	const struct mvebu_mbus_soc_data *soc;
 	int hw_io_coherency;
 
@@ -950,6 +951,14 @@ void mvebu_mbus_get_pcie_io_aperture(struct resource *res)
 }
 EXPORT_SYMBOL_GPL(mvebu_mbus_get_pcie_io_aperture);
 
+void mvebu_mbus_get_pcie_cfg_aperture(struct resource *res)
+{
+	if (!res)
+		return;
+	*res = mbus_state.pcie_cfg_aperture;
+}
+EXPORT_SYMBOL_GPL(mvebu_mbus_get_pcie_cfg_aperture);
+
 int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr)
 {
 	const struct mbus_dram_target_info *dram;
@@ -1277,7 +1286,8 @@ static int __init mbus_dt_setup(struct mvebu_mbus_state *mbus,
 
 static void __init mvebu_mbus_get_pcie_resources(struct device_node *np,
 						 struct resource *mem,
-						 struct resource *io)
+						 struct resource *io,
+						 struct resource *cfg)
 {
 	u32 reg[2];
 	int ret;
@@ -1290,6 +1300,8 @@ static void __init mvebu_mbus_get_pcie_resources(struct device_node *np,
 	mem->end = -1;
 	memset(io, 0, sizeof(struct resource));
 	io->end = -1;
+	memset(cfg, 0, sizeof(struct resource));
+	cfg->end = -1;
 
 	ret = of_property_read_u32_array(np, "pcie-mem-aperture", reg, ARRAY_SIZE(reg));
 	if (!ret) {
@@ -1304,6 +1316,13 @@ static void __init mvebu_mbus_get_pcie_resources(struct device_node *np,
 		io->end = io->start + reg[1] - 1;
 		io->flags = IORESOURCE_IO;
 	}
+
+	ret = of_property_read_u32_array(np, "pcie-cfg-aperture", reg, ARRAY_SIZE(reg));
+	if (!ret) {
+		cfg->start = reg[0];
+		cfg->end = cfg->start + reg[1] - 1;
+		cfg->flags = IORESOURCE_MEM;
+	}
 }
 
 int __init mvebu_mbus_dt_init(bool is_coherent)
@@ -1359,9 +1378,10 @@ int __init mvebu_mbus_dt_init(bool is_coherent)
 
 	mbus_state.hw_io_coherency = is_coherent;
 
-	/* Get optional pcie-{mem,io}-aperture properties */
+	/* Get optional pcie-{mem,io,cfg}-aperture properties */
 	mvebu_mbus_get_pcie_resources(np, &mbus_state.pcie_mem_aperture,
-					  &mbus_state.pcie_io_aperture);
+					  &mbus_state.pcie_io_aperture,
+					  &mbus_state.pcie_cfg_aperture);
 
 	ret = mvebu_mbus_common_init(&mbus_state,
 				     mbuswins_res.start,
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 4773145246ed..525b56ddd0c2 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -86,6 +86,7 @@ static inline int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size,
 int mvebu_mbus_save_cpu_target(u32 __iomem *store_addr);
 void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
 void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
+void mvebu_mbus_get_pcie_cfg_aperture(struct resource *res);
 int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr);
 int mvebu_mbus_add_window_remap_by_id(unsigned int target,
 				      unsigned int attribute,
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 3/7] dt-bindings: PCI: mvebu: Add orion5x compatible

[Pali Rohár]

From: Mauri Sandberg <maukka@ext.kapsi.fi>

Add a compatible string to bindings to indicate that orion5x PCIe is
supported too. Orion requires additional bindings for config space
registers.

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
Signed-off-by: Pali Rohár <pali@kernel.org>
---
Changes in v3:
* Add more detailed information about MMIO registers
---
 Documentation/devicetree/bindings/pci/mvebu-pci.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 8f0bca42113f..d8d6afc6376a 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -7,6 +7,7 @@ Mandatory properties:
     marvell,armada-xp-pcie
     marvell,dove-pcie
     marvell,kirkwood-pcie
+    marvell,orion5x-pcie
 - #address-cells, set to <3>
 - #size-cells, set to <2>
 - #interrupt-cells, set to <1>
@@ -60,7 +61,8 @@ PCIe interface, having the following mandatory properties:
 - reg: used only for interrupt mapping, so only the first four bytes
   are used to refer to the correct bus number and device number.
 - assigned-addresses: reference to the MMIO registers used to control
-  this PCIe interface.
+  this PCIe interface. first value controls internal registers and
+  second value (Orion-specific) controls config space registers.
 - clocks: the clock associated to this PCIe interface
 - marvell,pcie-port: the physical PCIe port number
 - status: either "disabled" or "okay"
-- 
2.20.1

[PATCH v3 3/7] dt-bindings: PCI: mvebu: Add orion5x compatible

[Pali Rohár]

From: Mauri Sandberg <maukka@ext.kapsi.fi>

Add a compatible string to bindings to indicate that orion5x PCIe is
supported too. Orion requires additional bindings for config space
registers.

Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
Signed-off-by: Pali Rohár <pali@kernel.org>
---
Changes in v3:
* Add more detailed information about MMIO registers
---
 Documentation/devicetree/bindings/pci/mvebu-pci.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 8f0bca42113f..d8d6afc6376a 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -7,6 +7,7 @@ Mandatory properties:
     marvell,armada-xp-pcie
     marvell,dove-pcie
     marvell,kirkwood-pcie
+    marvell,orion5x-pcie
 - #address-cells, set to <3>
 - #size-cells, set to <2>
 - #interrupt-cells, set to <1>
@@ -60,7 +61,8 @@ PCIe interface, having the following mandatory properties:
 - reg: used only for interrupt mapping, so only the first four bytes
   are used to refer to the correct bus number and device number.
 - assigned-addresses: reference to the MMIO registers used to control
-  this PCIe interface.
+  this PCIe interface. first value controls internal registers and
+  second value (Orion-specific) controls config space registers.
 - clocks: the clock associated to this PCIe interface
 - marvell,pcie-port: the physical PCIe port number
 - status: either "disabled" or "okay"
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 4/7] PCI: mvebu: Remove unused busn member

[Pali Rohár]

Signed-off-by: Pali Rohár <pali@kernel.org>
---
Changes in v3:
* New patch
---
 drivers/pci/controller/pci-mvebu.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 6ef8c1ee4cbb..d9e46bd7a4ec 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -96,7 +96,6 @@ struct mvebu_pcie {
 	struct resource io;
 	struct resource realio;
 	struct resource mem;
-	struct resource busn;
 	int nports;
 };
 
-- 
2.20.1

[PATCH v3 4/7] PCI: mvebu: Remove unused busn member

[Pali Rohár]

Signed-off-by: Pali Rohár <pali@kernel.org>
---
Changes in v3:
* New patch
---
 drivers/pci/controller/pci-mvebu.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 6ef8c1ee4cbb..d9e46bd7a4ec 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -96,7 +96,6 @@ struct mvebu_pcie {
 	struct resource io;
 	struct resource realio;
 	struct resource mem;
-	struct resource busn;
 	int nports;
 };
 
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 5/7] PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()

[Pali Rohár]

Move cleanup calls to error labels. This simplify error handling when
registering of some port fails.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
Changes in v3:
* New patch
---
 drivers/pci/controller/pci-mvebu.c | 59 ++++++++++++++----------------
 1 file changed, 28 insertions(+), 31 deletions(-)

diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index d9e46bd7a4ec..9986dd486680 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -1856,18 +1856,14 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 		if (IS_ERR(port->base)) {
 			dev_err(dev, "%s: cannot map registers\n", port->name);
 			port->base = NULL;
-			mvebu_pcie_powerdown(port);
-			continue;
+			goto err_port_down;
 		}
 
 		ret = mvebu_pci_bridge_emul_init(port);
 		if (ret < 0) {
 			dev_err(dev, "%s: cannot init emulated bridge\n",
 				port->name);
-			devm_iounmap(dev, port->base);
-			port->base = NULL;
-			mvebu_pcie_powerdown(port);
-			continue;
+			goto err_base_unmap;
 		}
 
 		if (port->error_irq > 0 || port->intx_irq > 0) {
@@ -1875,11 +1871,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 			if (ret) {
 				dev_err(dev, "%s: cannot init irq domain\n",
 					port->name);
-				pci_bridge_emul_cleanup(&port->bridge);
-				devm_iounmap(dev, port->base);
-				port->base = NULL;
-				mvebu_pcie_powerdown(port);
-				continue;
+				goto err_bridge_cleanup;
 			}
 		}
 
@@ -1891,15 +1883,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 			if (ret) {
 				dev_err(dev, "%s: cannot register error interrupt handler: %d\n",
 					port->name, ret);
-				if (port->intx_irq_domain)
-					irq_domain_remove(port->intx_irq_domain);
-				if (port->rp_irq_domain)
-					irq_domain_remove(port->rp_irq_domain);
-				pci_bridge_emul_cleanup(&port->bridge);
-				devm_iounmap(dev, port->base);
-				port->base = NULL;
-				mvebu_pcie_powerdown(port);
-				continue;
+				goto err_domain_remove;
 			}
 		}
 
@@ -1911,17 +1895,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 			if (ret) {
 				dev_err(dev, "%s: cannot register intx interrupt handler: %d\n",
 					port->name, ret);
-				if (port->error_irq > 0)
-					devm_free_irq(dev, port->error_irq, port);
-				if (port->intx_irq_domain)
-					irq_domain_remove(port->intx_irq_domain);
-				if (port->rp_irq_domain)
-					irq_domain_remove(port->rp_irq_domain);
-				pci_bridge_emul_cleanup(&port->bridge);
-				devm_iounmap(dev, port->base);
-				port->base = NULL;
-				mvebu_pcie_powerdown(port);
-				continue;
+				goto err_free_error_irq;
 			}
 		}
 
@@ -2015,6 +1989,29 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 		mvebu_pcie_setup_hw(port);
 		mvebu_pcie_set_local_dev_nr(port, 1);
 		mvebu_pcie_set_local_bus_nr(port, 0);
+
+		continue;
+
+err_free_error_irq:
+		if (port->error_irq > 0)
+			devm_free_irq(dev, port->error_irq, port);
+
+err_domain_remove:
+		if (port->intx_irq_domain)
+			irq_domain_remove(port->intx_irq_domain);
+
+		if (port->rp_irq_domain)
+			irq_domain_remove(port->rp_irq_domain);
+
+err_bridge_cleanup:
+		pci_bridge_emul_cleanup(&port->bridge);
+
+err_base_unmap:
+		devm_iounmap(dev, port->base);
+		port->base = NULL;
+
+err_port_down:
+		mvebu_pcie_powerdown(port);
 	}
 
 	bridge->sysdata = pcie;
-- 
2.20.1

[PATCH v3 5/7] PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()

[Pali Rohár]

Move cleanup calls to error labels. This simplify error handling when
registering of some port fails.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
Changes in v3:
* New patch
---
 drivers/pci/controller/pci-mvebu.c | 59 ++++++++++++++----------------
 1 file changed, 28 insertions(+), 31 deletions(-)

diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index d9e46bd7a4ec..9986dd486680 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -1856,18 +1856,14 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 		if (IS_ERR(port->base)) {
 			dev_err(dev, "%s: cannot map registers\n", port->name);
 			port->base = NULL;
-			mvebu_pcie_powerdown(port);
-			continue;
+			goto err_port_down;
 		}
 
 		ret = mvebu_pci_bridge_emul_init(port);
 		if (ret < 0) {
 			dev_err(dev, "%s: cannot init emulated bridge\n",
 				port->name);
-			devm_iounmap(dev, port->base);
-			port->base = NULL;
-			mvebu_pcie_powerdown(port);
-			continue;
+			goto err_base_unmap;
 		}
 
 		if (port->error_irq > 0 || port->intx_irq > 0) {
@@ -1875,11 +1871,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 			if (ret) {
 				dev_err(dev, "%s: cannot init irq domain\n",
 					port->name);
-				pci_bridge_emul_cleanup(&port->bridge);
-				devm_iounmap(dev, port->base);
-				port->base = NULL;
-				mvebu_pcie_powerdown(port);
-				continue;
+				goto err_bridge_cleanup;
 			}
 		}
 
@@ -1891,15 +1883,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 			if (ret) {
 				dev_err(dev, "%s: cannot register error interrupt handler: %d\n",
 					port->name, ret);
-				if (port->intx_irq_domain)
-					irq_domain_remove(port->intx_irq_domain);
-				if (port->rp_irq_domain)
-					irq_domain_remove(port->rp_irq_domain);
-				pci_bridge_emul_cleanup(&port->bridge);
-				devm_iounmap(dev, port->base);
-				port->base = NULL;
-				mvebu_pcie_powerdown(port);
-				continue;
+				goto err_domain_remove;
 			}
 		}
 
@@ -1911,17 +1895,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 			if (ret) {
 				dev_err(dev, "%s: cannot register intx interrupt handler: %d\n",
 					port->name, ret);
-				if (port->error_irq > 0)
-					devm_free_irq(dev, port->error_irq, port);
-				if (port->intx_irq_domain)
-					irq_domain_remove(port->intx_irq_domain);
-				if (port->rp_irq_domain)
-					irq_domain_remove(port->rp_irq_domain);
-				pci_bridge_emul_cleanup(&port->bridge);
-				devm_iounmap(dev, port->base);
-				port->base = NULL;
-				mvebu_pcie_powerdown(port);
-				continue;
+				goto err_free_error_irq;
 			}
 		}
 
@@ -2015,6 +1989,29 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 		mvebu_pcie_setup_hw(port);
 		mvebu_pcie_set_local_dev_nr(port, 1);
 		mvebu_pcie_set_local_bus_nr(port, 0);
+
+		continue;
+
+err_free_error_irq:
+		if (port->error_irq > 0)
+			devm_free_irq(dev, port->error_irq, port);
+
+err_domain_remove:
+		if (port->intx_irq_domain)
+			irq_domain_remove(port->intx_irq_domain);
+
+		if (port->rp_irq_domain)
+			irq_domain_remove(port->rp_irq_domain);
+
+err_bridge_cleanup:
+		pci_bridge_emul_cleanup(&port->bridge);
+
+err_base_unmap:
+		devm_iounmap(dev, port->base);
+		port->base = NULL;
+
+err_port_down:
+		mvebu_pcie_powerdown(port);
 	}
 
 	bridge->sysdata = pcie;
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 6/7] PCI: mvebu: Add support for Orion PCIe controller

[Pali Rohár]

Orion PCIe controller has same register sets, same APIs, same functionality
and also same bugs related to PCIe Root Ports as new PCIe controllers from
Marvell found on Kirkwood, Dove or Armada products. So pci-mvebu.c should
work fine with Orion PCIe controllers too.

But Orion PCIe controller has additional bug - broken Marvell CF8/CFC
registers which are used for config space access. This hardware bug is
documented in Marvell Orion Functional Errata, linked from kernel docs
https://www.kernel.org/doc/html/latest/arm/marvell.html. Document contains
also official workaround, but that workaround does not work when CPU or
other side of PCIe link is doing PCIe TLP operations. Because of race
conditions that official workaround is unusable for kernel, any other
multi-threaded systems and any PCIe card with bus mastering support.

Instead Linux kernel for a long time implements different undocumented
workaround (which does not have this issue) via platform code found in
arch/arm/mach-orion5x/pci.c and arch/arm/plat-orion/pcie.c files. It maps
PCIe config space directly into CPU physical address space via Marvell mbus
driver and then kernel access directly mapped physical address of config
space. The only disadvantage of this workaround is that it required
additional 16 MB of physical address space and only standard PCI config
space registers are accessible.

Testing proved that via mbus the physical size can be of this special
address range increased to 256 MB and then whole PCIe config space,
including PCIe registers, is accessible. So the only disadvantage is
requirement of free 256 MB in physical address space.

So for Orion support in pci-mvebu.c driver, this change reimplements
arch-specific mapping of config space with existing mbus driver and
kernel function pci_remap_cfgspace() which simplify physical space
mappings. Therefore pci-mvebu.c driver does not have to relay on static
virtual MMU mappings like old arch-specific code.

Like with any address ranges settings and configurations, this Orion code
reads physical config space address range from device tree files. There are
no fixed settings in the pci-mvebu.c driver as opposite of the old
arch-specific implementation. It is up to the board or platform dts file to
define how PCIe config space could be mapped into physical CPU address
space.

mbus specific target and attribute numbers, required for mbus mappings of
config space registers are also read from device tree files, in exactly
same format as are read for PCIe MEM and PCIe IO space mappings.

During probing of Orion PCIe controller, pci-mvebu.c driver ask kernel mbus
driver to map config space into CPU physical address range (based on DTS
offset and size). Config space stays mapped in physical address range while
PCIe controller is bind to driver.

Note that layout of PCIe config space is not standard PCIe ECAM. It is same
as layout accessed indirectly via CF8/CFC registers used in other Armada
PCIe controllers. Support for extended PCIe registers in this layout is
non-standard and hence it is Marvell specific layout.

The main issue with this layout is that config space of PCIe bus in not
coherent in address range. And neither address range of one PCIe device is
coherent. Therefore it is not possible to use PCI core .map_bus callback
for implementing access into config space. And because Orion is 32-bit
platform it is not a wise idea to map whole 256 MB PCIe config space into
CPU virtual address space permanently.

So because layout of config space via direct or indirect method is same,
functions mvebu_pcie_child_rd_conf() and mvebu_pcie_child_wd_conf() are
slightly modified to support also direct config space access method.
Functions calculates where in physical address range is requested config
space register and do virtual mapping at request time. After register
access it is unmapped from virtual address range.

Links: https://www.kernel.org/doc/html/latest/arm/marvell.html
Signed-off-by: Pali Rohár <pali@kernel.org>
---
Changes in v3:
* Completely rewritten
* Implement full support for accessing PCIe config space based on device
  tree details without any harcoded address in pci-mvebu.c driver
---
 drivers/pci/controller/Kconfig     |   4 +-
 drivers/pci/controller/pci-mvebu.c | 142 +++++++++++++++++++++++++++--
 2 files changed, 136 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 8da2efdc5177..ae5a430387bc 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -5,7 +5,7 @@ menu "PCI controller drivers"
 
 config PCI_MVEBU
 	tristate "Marvell EBU PCIe controller"
-	depends on ARCH_MVEBU || ARCH_DOVE || COMPILE_TEST
+	depends on ARCH_MVEBU || ARCH_DOVE || ARCH_ORION5X || COMPILE_TEST
 	depends on MVEBU_MBUS
 	depends on ARM
 	depends on OF
@@ -15,7 +15,7 @@ config PCI_MVEBU
 	select HOTPLUG_PCI_PCIE
 	help
 	 Add support for Marvell EBU PCIe controller. This PCIe controller
-	 is used on 32-bit Marvell ARM SoCs: Dove, Kirkwood, Armada 370,
+	 is used on 32-bit Marvell ARM SoCs: Orion, Kirkwood, Dove, Armada 370,
 	 Armada XP, Armada 375, Armada 38x and Armada 39x.
 
 config PCI_AARDVARK
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 9986dd486680..2ef04a8241fc 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -96,6 +96,7 @@ struct mvebu_pcie {
 	struct resource io;
 	struct resource realio;
 	struct resource mem;
+	struct resource cfg;
 	int nports;
 };
 
@@ -127,6 +128,7 @@ struct mvebu_pcie_port {
 	struct mvebu_pcie_window iowin;
 	u32 saved_pcie_stat;
 	struct resource regs;
+	struct resource cfg;
 	u8 slot_power_limit_value;
 	u8 slot_power_limit_scale;
 	struct irq_domain *rp_irq_domain;
@@ -409,6 +411,7 @@ static int mvebu_pcie_child_rd_conf(struct pci_bus *bus, u32 devfn, int where,
 	struct mvebu_pcie *pcie = bus->sysdata;
 	struct mvebu_pcie_port *port;
 	void __iomem *conf_data;
+	u32 offset;
 
 	port = mvebu_pcie_find_port(pcie, bus, devfn);
 	if (!port)
@@ -417,10 +420,20 @@ static int mvebu_pcie_child_rd_conf(struct pci_bus *bus, u32 devfn, int where,
 	if (!mvebu_pcie_link_up(port))
 		return PCIBIOS_DEVICE_NOT_FOUND;
 
-	conf_data = port->base + PCIE_CONF_DATA_OFF;
+	if (resource_size(&port->cfg)) {
+		offset = PCIE_CONF_ADDR(bus->number, devfn, where) & ~PCIE_CONF_ADDR_EN;
+		if (offset >= resource_size(&port->cfg))
+			return PCIBIOS_DEVICE_NOT_FOUND;
 
-	mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where),
-		     PCIE_CONF_ADDR_OFF);
+		conf_data = pci_remap_cfgspace(port->cfg.start + offset, size);
+		if (!conf_data)
+			return PCIBIOS_DEVICE_NOT_FOUND;
+	} else {
+		conf_data = port->base + PCIE_CONF_DATA_OFF;
+
+		mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where),
+			     PCIE_CONF_ADDR_OFF);
+	}
 
 	switch (size) {
 	case 1:
@@ -433,9 +446,14 @@ static int mvebu_pcie_child_rd_conf(struct pci_bus *bus, u32 devfn, int where,
 		*val = readl_relaxed(conf_data);
 		break;
 	default:
+		if (resource_size(&port->cfg))
+			iounmap(conf_data);
 		return PCIBIOS_BAD_REGISTER_NUMBER;
 	}
 
+	if (resource_size(&port->cfg))
+		iounmap(conf_data);
+
 	return PCIBIOS_SUCCESSFUL;
 }
 
@@ -445,6 +463,7 @@ static int mvebu_pcie_child_wr_conf(struct pci_bus *bus, u32 devfn,
 	struct mvebu_pcie *pcie = bus->sysdata;
 	struct mvebu_pcie_port *port;
 	void __iomem *conf_data;
+	u32 offset;
 
 	port = mvebu_pcie_find_port(pcie, bus, devfn);
 	if (!port)
@@ -453,10 +472,20 @@ static int mvebu_pcie_child_wr_conf(struct pci_bus *bus, u32 devfn,
 	if (!mvebu_pcie_link_up(port))
 		return PCIBIOS_DEVICE_NOT_FOUND;
 
-	conf_data = port->base + PCIE_CONF_DATA_OFF;
+	if (resource_size(&port->cfg)) {
+		offset = PCIE_CONF_ADDR(bus->number, devfn, where) & ~PCIE_CONF_ADDR_EN;
+		if (offset >= resource_size(&port->cfg))
+			return PCIBIOS_DEVICE_NOT_FOUND;
+
+		conf_data = pci_remap_cfgspace(port->cfg.start + offset, size);
+		if (!conf_data)
+			return PCIBIOS_DEVICE_NOT_FOUND;
+	} else {
+		conf_data = port->base + PCIE_CONF_DATA_OFF;
 
-	mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where),
-		     PCIE_CONF_ADDR_OFF);
+		mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where),
+			     PCIE_CONF_ADDR_OFF);
+	}
 
 	switch (size) {
 	case 1:
@@ -469,9 +498,14 @@ static int mvebu_pcie_child_wr_conf(struct pci_bus *bus, u32 devfn,
 		writel(val, conf_data);
 		break;
 	default:
+		if (resource_size(&port->cfg))
+			iounmap(conf_data);
 		return PCIBIOS_BAD_REGISTER_NUMBER;
 	}
 
+	if (resource_size(&port->cfg))
+		iounmap(conf_data);
+
 	return PCIBIOS_SUCCESSFUL;
 }
 
@@ -1472,6 +1506,7 @@ static void __iomem *mvebu_pcie_map_registers(struct platform_device *pdev,
 
 static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
 			      unsigned long type,
+			      unsigned long offset,
 			      unsigned int *tgt,
 			      unsigned int *attr)
 {
@@ -1493,6 +1528,7 @@ static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
 	for (i = 0; i < nranges; i++, range += rangesz) {
 		u32 flags = of_read_number(range, 1);
 		u32 slot = of_read_number(range + 1, 1);
+		u32 dtaddr = of_read_number(range + 2, 1);
 		u64 cpuaddr = of_read_number(range + na, pna);
 		unsigned long rtype;
 
@@ -1503,6 +1539,9 @@ static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
 		else
 			continue;
 
+		if (dtaddr != offset)
+			continue;
+
 		if (slot == PCI_SLOT(devfn) && type == rtype) {
 			*tgt = DT_CPUADDR_TO_TARGET(cpuaddr);
 			*attr = DT_CPUADDR_TO_ATTR(cpuaddr);
@@ -1513,6 +1552,43 @@ static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
 	return -ENOENT;
 }
 
+static int mvebu_get_cfg_tgt_attr(struct device_node *np, phys_addr_t start,
+				  struct resource *res,
+				  unsigned int *tgt, unsigned int *attr)
+{
+	const __be32 *addrp;
+	unsigned int flags;
+	u64 offset;
+	u64 size;
+	int ret;
+
+	/* get second cell from assigned-addresses property */
+	addrp = of_get_address(np, 1, &size, &flags);
+	if (!addrp)
+		return -EINVAL;
+
+	if (!(flags & IORESOURCE_MEM))
+		return -EINVAL;
+
+	if (be32_to_cpu(addrp[1]) != 0x0)
+		return -EINVAL;
+
+	flags |= IORESOURCE_MEM_NONPOSTED;
+	offset = be32_to_cpu(addrp[2]);
+
+	ret = mvebu_get_tgt_attr(of_get_parent(np), 0, IORESOURCE_MEM, offset, tgt, attr);
+	if (ret)
+		return ret;
+
+	memset(res, 0, sizeof(*res));
+	res->start = start;
+	res->end = start + size - 1;
+	res->flags = flags;
+	res->name = "PCI CFG";
+
+	return 0;
+}
+
 static int mvebu_pcie_suspend(struct device *dev)
 {
 	struct mvebu_pcie *pcie;
@@ -1592,7 +1668,7 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
 		goto skip;
 	}
 
-	ret = mvebu_get_tgt_attr(dev->of_node, port->devfn, IORESOURCE_MEM,
+	ret = mvebu_get_tgt_attr(dev->of_node, port->devfn, IORESOURCE_MEM, 0,
 				 &port->mem_target, &port->mem_attr);
 	if (ret < 0) {
 		dev_err(dev, "%s: cannot get tgt/attr for mem window\n",
@@ -1601,7 +1677,7 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
 	}
 
 	if (resource_size(&pcie->io) != 0) {
-		mvebu_get_tgt_attr(dev->of_node, port->devfn, IORESOURCE_IO,
+		mvebu_get_tgt_attr(dev->of_node, port->devfn, IORESOURCE_IO, 0,
 				   &port->io_target, &port->io_attr);
 	} else {
 		port->io_target = -1;
@@ -1794,6 +1870,20 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie)
 			return ret;
 	}
 
+	if (of_device_is_compatible(dev->of_node, "marvell,orion5x-pcie")) {
+		/* Get the PCIe configuration space aperture */
+		mvebu_mbus_get_pcie_cfg_aperture(&pcie->cfg);
+		if (resource_size(&pcie->cfg) == 0) {
+			dev_err(dev, "invalid config space aperature size\n");
+			return -EINVAL;
+		}
+
+		pcie->cfg.name = "PCI CFG";
+		ret = devm_request_resource(dev, &iomem_resource, &pcie->cfg);
+		if (ret)
+			return ret;
+	}
+
 	return 0;
 }
 
@@ -1804,6 +1894,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 	struct pci_host_bridge *bridge;
 	struct device_node *np = dev->of_node;
 	struct device_node *child;
+	phys_addr_t pcie_cfg_offset;
 	int num, i, ret;
 
 	bridge = devm_pci_alloc_host_bridge(dev, sizeof(struct mvebu_pcie));
@@ -1818,6 +1909,8 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	pcie_cfg_offset = pcie->cfg.start;
+
 	num = of_get_available_child_count(np);
 
 	pcie->ports = devm_kcalloc(dev, num, sizeof(*pcie->ports), GFP_KERNEL);
@@ -1852,6 +1945,32 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 		if (ret < 0)
 			continue;
 
+		if (resource_size(&pcie->cfg) != 0) {
+			unsigned int cfg_target, cfg_attr;
+
+			ret = mvebu_get_cfg_tgt_attr(child, pcie_cfg_offset, &port->cfg, &cfg_target, &cfg_attr);
+			if (ret) {
+				dev_err(dev, "%s: missing address range for cfg space\n", port->name);
+				goto err_port_down;
+			}
+
+			if (port->cfg.end > pcie->cfg.end) {
+				dev_err(dev, "%s: requested cfg space of %u bytes is too large, available only %u bytes\n",
+					port->name, resource_size(&port->cfg), pcie->cfg.end - pcie_cfg_offset + 1);
+				port->cfg.start = port->cfg.end = 0;
+				goto err_port_down;
+			}
+
+			ret = mvebu_mbus_add_window_by_id(cfg_target, cfg_attr, port->cfg.start, resource_size(&port->cfg));
+			if (ret) {
+				dev_info(dev, "%s: cannot add mbus window for cfg space: %d\n", port->name, ret);
+				port->cfg.start = port->cfg.end = 0;
+				goto err_port_down;
+			}
+
+			pcie_cfg_offset += resource_size(&port->cfg);
+		}
+
 		port->base = mvebu_pcie_map_registers(pdev, child, port);
 		if (IS_ERR(port->base)) {
 			dev_err(dev, "%s: cannot map registers\n", port->name);
@@ -2011,6 +2130,9 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 		port->base = NULL;
 
 err_port_down:
+		if (port->cfg.end && resource_size(&port->cfg))
+			mvebu_mbus_del_window(port->cfg.start, resource_size(&port->cfg));
+
 		mvebu_pcie_powerdown(port);
 	}
 
@@ -2090,6 +2212,9 @@ static int mvebu_pcie_remove(struct platform_device *pdev)
 		if (port->memwin.size)
 			mvebu_pcie_del_windows(port, port->memwin.base, port->memwin.size);
 
+		if (port->cfg.end && resource_size(&port->cfg))
+			mvebu_mbus_del_window(port->cfg.start, resource_size(&port->cfg));
+
 		/* Power down card and disable clocks. Must be the last step. */
 		mvebu_pcie_powerdown(port);
 	}
@@ -2102,6 +2227,7 @@ static const struct of_device_id mvebu_pcie_of_match_table[] = {
 	{ .compatible = "marvell,armada-370-pcie", },
 	{ .compatible = "marvell,dove-pcie", },
 	{ .compatible = "marvell,kirkwood-pcie", },
+	{ .compatible = "marvell,orion5x-pcie", },
 	{},
 };
 
-- 
2.20.1

[PATCH v3 6/7] PCI: mvebu: Add support for Orion PCIe controller

[Pali Rohár]

Orion PCIe controller has same register sets, same APIs, same functionality
and also same bugs related to PCIe Root Ports as new PCIe controllers from
Marvell found on Kirkwood, Dove or Armada products. So pci-mvebu.c should
work fine with Orion PCIe controllers too.

But Orion PCIe controller has additional bug - broken Marvell CF8/CFC
registers which are used for config space access. This hardware bug is
documented in Marvell Orion Functional Errata, linked from kernel docs
https://www.kernel.org/doc/html/latest/arm/marvell.html. Document contains
also official workaround, but that workaround does not work when CPU or
other side of PCIe link is doing PCIe TLP operations. Because of race
conditions that official workaround is unusable for kernel, any other
multi-threaded systems and any PCIe card with bus mastering support.

Instead Linux kernel for a long time implements different undocumented
workaround (which does not have this issue) via platform code found in
arch/arm/mach-orion5x/pci.c and arch/arm/plat-orion/pcie.c files. It maps
PCIe config space directly into CPU physical address space via Marvell mbus
driver and then kernel access directly mapped physical address of config
space. The only disadvantage of this workaround is that it required
additional 16 MB of physical address space and only standard PCI config
space registers are accessible.

Testing proved that via mbus the physical size can be of this special
address range increased to 256 MB and then whole PCIe config space,
including PCIe registers, is accessible. So the only disadvantage is
requirement of free 256 MB in physical address space.

So for Orion support in pci-mvebu.c driver, this change reimplements
arch-specific mapping of config space with existing mbus driver and
kernel function pci_remap_cfgspace() which simplify physical space
mappings. Therefore pci-mvebu.c driver does not have to relay on static
virtual MMU mappings like old arch-specific code.

Like with any address ranges settings and configurations, this Orion code
reads physical config space address range from device tree files. There are
no fixed settings in the pci-mvebu.c driver as opposite of the old
arch-specific implementation. It is up to the board or platform dts file to
define how PCIe config space could be mapped into physical CPU address
space.

mbus specific target and attribute numbers, required for mbus mappings of
config space registers are also read from device tree files, in exactly
same format as are read for PCIe MEM and PCIe IO space mappings.

During probing of Orion PCIe controller, pci-mvebu.c driver ask kernel mbus
driver to map config space into CPU physical address range (based on DTS
offset and size). Config space stays mapped in physical address range while
PCIe controller is bind to driver.

Note that layout of PCIe config space is not standard PCIe ECAM. It is same
as layout accessed indirectly via CF8/CFC registers used in other Armada
PCIe controllers. Support for extended PCIe registers in this layout is
non-standard and hence it is Marvell specific layout.

The main issue with this layout is that config space of PCIe bus in not
coherent in address range. And neither address range of one PCIe device is
coherent. Therefore it is not possible to use PCI core .map_bus callback
for implementing access into config space. And because Orion is 32-bit
platform it is not a wise idea to map whole 256 MB PCIe config space into
CPU virtual address space permanently.

So because layout of config space via direct or indirect method is same,
functions mvebu_pcie_child_rd_conf() and mvebu_pcie_child_wd_conf() are
slightly modified to support also direct config space access method.
Functions calculates where in physical address range is requested config
space register and do virtual mapping at request time. After register
access it is unmapped from virtual address range.

Links: https://www.kernel.org/doc/html/latest/arm/marvell.html
Signed-off-by: Pali Rohár <pali@kernel.org>
---
Changes in v3:
* Completely rewritten
* Implement full support for accessing PCIe config space based on device
  tree details without any harcoded address in pci-mvebu.c driver
---
 drivers/pci/controller/Kconfig     |   4 +-
 drivers/pci/controller/pci-mvebu.c | 142 +++++++++++++++++++++++++++--
 2 files changed, 136 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index 8da2efdc5177..ae5a430387bc 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -5,7 +5,7 @@ menu "PCI controller drivers"
 
 config PCI_MVEBU
 	tristate "Marvell EBU PCIe controller"
-	depends on ARCH_MVEBU || ARCH_DOVE || COMPILE_TEST
+	depends on ARCH_MVEBU || ARCH_DOVE || ARCH_ORION5X || COMPILE_TEST
 	depends on MVEBU_MBUS
 	depends on ARM
 	depends on OF
@@ -15,7 +15,7 @@ config PCI_MVEBU
 	select HOTPLUG_PCI_PCIE
 	help
 	 Add support for Marvell EBU PCIe controller. This PCIe controller
-	 is used on 32-bit Marvell ARM SoCs: Dove, Kirkwood, Armada 370,
+	 is used on 32-bit Marvell ARM SoCs: Orion, Kirkwood, Dove, Armada 370,
 	 Armada XP, Armada 375, Armada 38x and Armada 39x.
 
 config PCI_AARDVARK
diff --git a/drivers/pci/controller/pci-mvebu.c b/drivers/pci/controller/pci-mvebu.c
index 9986dd486680..2ef04a8241fc 100644
--- a/drivers/pci/controller/pci-mvebu.c
+++ b/drivers/pci/controller/pci-mvebu.c
@@ -96,6 +96,7 @@ struct mvebu_pcie {
 	struct resource io;
 	struct resource realio;
 	struct resource mem;
+	struct resource cfg;
 	int nports;
 };
 
@@ -127,6 +128,7 @@ struct mvebu_pcie_port {
 	struct mvebu_pcie_window iowin;
 	u32 saved_pcie_stat;
 	struct resource regs;
+	struct resource cfg;
 	u8 slot_power_limit_value;
 	u8 slot_power_limit_scale;
 	struct irq_domain *rp_irq_domain;
@@ -409,6 +411,7 @@ static int mvebu_pcie_child_rd_conf(struct pci_bus *bus, u32 devfn, int where,
 	struct mvebu_pcie *pcie = bus->sysdata;
 	struct mvebu_pcie_port *port;
 	void __iomem *conf_data;
+	u32 offset;
 
 	port = mvebu_pcie_find_port(pcie, bus, devfn);
 	if (!port)
@@ -417,10 +420,20 @@ static int mvebu_pcie_child_rd_conf(struct pci_bus *bus, u32 devfn, int where,
 	if (!mvebu_pcie_link_up(port))
 		return PCIBIOS_DEVICE_NOT_FOUND;
 
-	conf_data = port->base + PCIE_CONF_DATA_OFF;
+	if (resource_size(&port->cfg)) {
+		offset = PCIE_CONF_ADDR(bus->number, devfn, where) & ~PCIE_CONF_ADDR_EN;
+		if (offset >= resource_size(&port->cfg))
+			return PCIBIOS_DEVICE_NOT_FOUND;
 
-	mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where),
-		     PCIE_CONF_ADDR_OFF);
+		conf_data = pci_remap_cfgspace(port->cfg.start + offset, size);
+		if (!conf_data)
+			return PCIBIOS_DEVICE_NOT_FOUND;
+	} else {
+		conf_data = port->base + PCIE_CONF_DATA_OFF;
+
+		mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where),
+			     PCIE_CONF_ADDR_OFF);
+	}
 
 	switch (size) {
 	case 1:
@@ -433,9 +446,14 @@ static int mvebu_pcie_child_rd_conf(struct pci_bus *bus, u32 devfn, int where,
 		*val = readl_relaxed(conf_data);
 		break;
 	default:
+		if (resource_size(&port->cfg))
+			iounmap(conf_data);
 		return PCIBIOS_BAD_REGISTER_NUMBER;
 	}
 
+	if (resource_size(&port->cfg))
+		iounmap(conf_data);
+
 	return PCIBIOS_SUCCESSFUL;
 }
 
@@ -445,6 +463,7 @@ static int mvebu_pcie_child_wr_conf(struct pci_bus *bus, u32 devfn,
 	struct mvebu_pcie *pcie = bus->sysdata;
 	struct mvebu_pcie_port *port;
 	void __iomem *conf_data;
+	u32 offset;
 
 	port = mvebu_pcie_find_port(pcie, bus, devfn);
 	if (!port)
@@ -453,10 +472,20 @@ static int mvebu_pcie_child_wr_conf(struct pci_bus *bus, u32 devfn,
 	if (!mvebu_pcie_link_up(port))
 		return PCIBIOS_DEVICE_NOT_FOUND;
 
-	conf_data = port->base + PCIE_CONF_DATA_OFF;
+	if (resource_size(&port->cfg)) {
+		offset = PCIE_CONF_ADDR(bus->number, devfn, where) & ~PCIE_CONF_ADDR_EN;
+		if (offset >= resource_size(&port->cfg))
+			return PCIBIOS_DEVICE_NOT_FOUND;
+
+		conf_data = pci_remap_cfgspace(port->cfg.start + offset, size);
+		if (!conf_data)
+			return PCIBIOS_DEVICE_NOT_FOUND;
+	} else {
+		conf_data = port->base + PCIE_CONF_DATA_OFF;
 
-	mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where),
-		     PCIE_CONF_ADDR_OFF);
+		mvebu_writel(port, PCIE_CONF_ADDR(bus->number, devfn, where),
+			     PCIE_CONF_ADDR_OFF);
+	}
 
 	switch (size) {
 	case 1:
@@ -469,9 +498,14 @@ static int mvebu_pcie_child_wr_conf(struct pci_bus *bus, u32 devfn,
 		writel(val, conf_data);
 		break;
 	default:
+		if (resource_size(&port->cfg))
+			iounmap(conf_data);
 		return PCIBIOS_BAD_REGISTER_NUMBER;
 	}
 
+	if (resource_size(&port->cfg))
+		iounmap(conf_data);
+
 	return PCIBIOS_SUCCESSFUL;
 }
 
@@ -1472,6 +1506,7 @@ static void __iomem *mvebu_pcie_map_registers(struct platform_device *pdev,
 
 static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
 			      unsigned long type,
+			      unsigned long offset,
 			      unsigned int *tgt,
 			      unsigned int *attr)
 {
@@ -1493,6 +1528,7 @@ static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
 	for (i = 0; i < nranges; i++, range += rangesz) {
 		u32 flags = of_read_number(range, 1);
 		u32 slot = of_read_number(range + 1, 1);
+		u32 dtaddr = of_read_number(range + 2, 1);
 		u64 cpuaddr = of_read_number(range + na, pna);
 		unsigned long rtype;
 
@@ -1503,6 +1539,9 @@ static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
 		else
 			continue;
 
+		if (dtaddr != offset)
+			continue;
+
 		if (slot == PCI_SLOT(devfn) && type == rtype) {
 			*tgt = DT_CPUADDR_TO_TARGET(cpuaddr);
 			*attr = DT_CPUADDR_TO_ATTR(cpuaddr);
@@ -1513,6 +1552,43 @@ static int mvebu_get_tgt_attr(struct device_node *np, int devfn,
 	return -ENOENT;
 }
 
+static int mvebu_get_cfg_tgt_attr(struct device_node *np, phys_addr_t start,
+				  struct resource *res,
+				  unsigned int *tgt, unsigned int *attr)
+{
+	const __be32 *addrp;
+	unsigned int flags;
+	u64 offset;
+	u64 size;
+	int ret;
+
+	/* get second cell from assigned-addresses property */
+	addrp = of_get_address(np, 1, &size, &flags);
+	if (!addrp)
+		return -EINVAL;
+
+	if (!(flags & IORESOURCE_MEM))
+		return -EINVAL;
+
+	if (be32_to_cpu(addrp[1]) != 0x0)
+		return -EINVAL;
+
+	flags |= IORESOURCE_MEM_NONPOSTED;
+	offset = be32_to_cpu(addrp[2]);
+
+	ret = mvebu_get_tgt_attr(of_get_parent(np), 0, IORESOURCE_MEM, offset, tgt, attr);
+	if (ret)
+		return ret;
+
+	memset(res, 0, sizeof(*res));
+	res->start = start;
+	res->end = start + size - 1;
+	res->flags = flags;
+	res->name = "PCI CFG";
+
+	return 0;
+}
+
 static int mvebu_pcie_suspend(struct device *dev)
 {
 	struct mvebu_pcie *pcie;
@@ -1592,7 +1668,7 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
 		goto skip;
 	}
 
-	ret = mvebu_get_tgt_attr(dev->of_node, port->devfn, IORESOURCE_MEM,
+	ret = mvebu_get_tgt_attr(dev->of_node, port->devfn, IORESOURCE_MEM, 0,
 				 &port->mem_target, &port->mem_attr);
 	if (ret < 0) {
 		dev_err(dev, "%s: cannot get tgt/attr for mem window\n",
@@ -1601,7 +1677,7 @@ static int mvebu_pcie_parse_port(struct mvebu_pcie *pcie,
 	}
 
 	if (resource_size(&pcie->io) != 0) {
-		mvebu_get_tgt_attr(dev->of_node, port->devfn, IORESOURCE_IO,
+		mvebu_get_tgt_attr(dev->of_node, port->devfn, IORESOURCE_IO, 0,
 				   &port->io_target, &port->io_attr);
 	} else {
 		port->io_target = -1;
@@ -1794,6 +1870,20 @@ static int mvebu_pcie_parse_request_resources(struct mvebu_pcie *pcie)
 			return ret;
 	}
 
+	if (of_device_is_compatible(dev->of_node, "marvell,orion5x-pcie")) {
+		/* Get the PCIe configuration space aperture */
+		mvebu_mbus_get_pcie_cfg_aperture(&pcie->cfg);
+		if (resource_size(&pcie->cfg) == 0) {
+			dev_err(dev, "invalid config space aperature size\n");
+			return -EINVAL;
+		}
+
+		pcie->cfg.name = "PCI CFG";
+		ret = devm_request_resource(dev, &iomem_resource, &pcie->cfg);
+		if (ret)
+			return ret;
+	}
+
 	return 0;
 }
 
@@ -1804,6 +1894,7 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 	struct pci_host_bridge *bridge;
 	struct device_node *np = dev->of_node;
 	struct device_node *child;
+	phys_addr_t pcie_cfg_offset;
 	int num, i, ret;
 
 	bridge = devm_pci_alloc_host_bridge(dev, sizeof(struct mvebu_pcie));
@@ -1818,6 +1909,8 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	pcie_cfg_offset = pcie->cfg.start;
+
 	num = of_get_available_child_count(np);
 
 	pcie->ports = devm_kcalloc(dev, num, sizeof(*pcie->ports), GFP_KERNEL);
@@ -1852,6 +1945,32 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 		if (ret < 0)
 			continue;
 
+		if (resource_size(&pcie->cfg) != 0) {
+			unsigned int cfg_target, cfg_attr;
+
+			ret = mvebu_get_cfg_tgt_attr(child, pcie_cfg_offset, &port->cfg, &cfg_target, &cfg_attr);
+			if (ret) {
+				dev_err(dev, "%s: missing address range for cfg space\n", port->name);
+				goto err_port_down;
+			}
+
+			if (port->cfg.end > pcie->cfg.end) {
+				dev_err(dev, "%s: requested cfg space of %u bytes is too large, available only %u bytes\n",
+					port->name, resource_size(&port->cfg), pcie->cfg.end - pcie_cfg_offset + 1);
+				port->cfg.start = port->cfg.end = 0;
+				goto err_port_down;
+			}
+
+			ret = mvebu_mbus_add_window_by_id(cfg_target, cfg_attr, port->cfg.start, resource_size(&port->cfg));
+			if (ret) {
+				dev_info(dev, "%s: cannot add mbus window for cfg space: %d\n", port->name, ret);
+				port->cfg.start = port->cfg.end = 0;
+				goto err_port_down;
+			}
+
+			pcie_cfg_offset += resource_size(&port->cfg);
+		}
+
 		port->base = mvebu_pcie_map_registers(pdev, child, port);
 		if (IS_ERR(port->base)) {
 			dev_err(dev, "%s: cannot map registers\n", port->name);
@@ -2011,6 +2130,9 @@ static int mvebu_pcie_probe(struct platform_device *pdev)
 		port->base = NULL;
 
 err_port_down:
+		if (port->cfg.end && resource_size(&port->cfg))
+			mvebu_mbus_del_window(port->cfg.start, resource_size(&port->cfg));
+
 		mvebu_pcie_powerdown(port);
 	}
 
@@ -2090,6 +2212,9 @@ static int mvebu_pcie_remove(struct platform_device *pdev)
 		if (port->memwin.size)
 			mvebu_pcie_del_windows(port, port->memwin.base, port->memwin.size);
 
+		if (port->cfg.end && resource_size(&port->cfg))
+			mvebu_mbus_del_window(port->cfg.start, resource_size(&port->cfg));
+
 		/* Power down card and disable clocks. Must be the last step. */
 		mvebu_pcie_powerdown(port);
 	}
@@ -2102,6 +2227,7 @@ static const struct of_device_id mvebu_pcie_of_match_table[] = {
 	{ .compatible = "marvell,armada-370-pcie", },
 	{ .compatible = "marvell,dove-pcie", },
 	{ .compatible = "marvell,kirkwood-pcie", },
+	{ .compatible = "marvell,orion5x-pcie", },
 	{},
 };
 
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v3 7/7] ARM: dts: orion5x: Add PCIe node

[Pali Rohár]

Define PCIe aperture for top level soc node handled by mbus driver and
define PCIe controller node with one PCIe Root Port.

Old Orion arch code maps first 16 MB of PCIe config space to physical
address 0xf0000000. But for full PCIe support it is needed to map whole
256 MB long PCIe config space.

There are probably no Orion boards with more than 2 GB of RAM, so 256 MB of
free physical address space must exist. Tests on Orion board proved that
there is free space in physical address range 0xd0000000-0xdfffffff.

So use this physical space for mapping whole 256 MB long PCIe config space.
In case there would be some issue with this range, particular Orion device
tree board file can change it to 16 MB size or move it to old location.

By default orion5x.dtsi include file would contains whole PCIe config space
for full PCIe support.

By default is PCIe node disabled, so this change in orion5x.dtsi has no
effect for any board until board dts file explicitly enable it. Each board
has to migrate its PCIe code from old arch specific to device tree based.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
Changes in v3:
* New patch
---
 arch/arm/boot/dts/orion5x.dtsi | 51 ++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
index 2d41f5c166ee..41954d96ebbf 100644
--- a/arch/arm/boot/dts/orion5x.dtsi
+++ b/arch/arm/boot/dts/orion5x.dtsi
@@ -18,6 +18,9 @@
 		#address-cells = <2>;
 		#size-cells = <1>;
 		controller = <&mbusc>;
+		pcie-cfg-aperture = <0xd0000000 0x10000000>; /* 256 MiB config space */
+		pcie-mem-aperture = <0xe0000000 0x08000000>; /* 128 MiB memory space */
+		pcie-io-aperture  = <0xf2000000 0x00100000>; /*   1 MiB I/O space */
 
 		devbus_bootcs: devbus-bootcs {
 			compatible = "marvell,orion-devbus";
@@ -226,6 +229,54 @@
 			};
 		};
 
+		pciec: pcie {
+			compatible = "marvell,orion5x-pcie";
+			status = "disabled";
+			device_type = "pci";
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			msi-parent = <&intc>;
+			bus-range = <0x00 0xff>;
+
+			ranges = <0x82000000 0x0    0x40000  MBUS_ID(0xf0, 0x01) 0x40000  0x0     0x2000>, /* Port 0.0 Internal registers */
+				 <0x82000000 0x0 0xf0000000  MBUS_ID(0x04, 0x79)     0x0  0x0 0x10000000>, /* Port 0.0 Config space registers */
+				 <0x82000000 0x1 0x00000000  MBUS_ID(0x04, 0x59)     0x0  0x1 0x00000000>, /* Port 0.0 Mem */
+				 <0x81000000 0x1 0x00000000  MBUS_ID(0x04, 0x51)     0x0  0x1 0x00000000>; /* Port 0.0 I/O */
+
+			pcie0: pcie@1,0 {
+				status = "disabled";
+				reg = <0x0800 0 0 0 0>;
+				device_type = "pci";
+				#address-cells = <3>;
+				#size-cells = <2>;
+
+				assigned-addresses =         <0x82000800 0x0    0x40000  0x0     0x2000>, /* Port 0.0 Internal registers */
+						             <0x82000800 0x0 0xf0000000  0x0 0x10000000>; /* Port 0.0 Config space registers */
+				ranges = <0x82000000 0x0 0x0  0x82000000 0x1 0x00000000  0x1 0x00000000>, /* Port 0.0 Mem */
+				         <0x81000000 0x0 0x0  0x81000000 0x1 0x00000000  0x1 0x00000000>; /* Port 0.0 I/O */
+				bus-range = <0x00 0xff>;
+
+				clocks = <&core_clk 0>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+
+				#interrupt-cells = <1>;
+				interrupt-names = "intx", "error";
+				interrupts = <11>, <10>;
+				interrupt-map-mask = <0 0 0 7>;
+				interrupt-map = <0 0 0 1 &pcie_intc 0>,
+						<0 0 0 2 &pcie_intc 1>,
+						<0 0 0 3 &pcie_intc 2>,
+						<0 0 0 4 &pcie_intc 3>;
+
+				pcie_intc: interrupt-controller {
+					interrupt-controller;
+					#interrupt-cells = <1>;
+				};
+			};
+		};
+
 		crypto_sram: sa-sram {
 			compatible = "mmio-sram";
 			reg = <MBUS_ID(0x09, 0x00) 0x0 0x800>;
-- 
2.20.1

[PATCH v3 7/7] ARM: dts: orion5x: Add PCIe node

[Pali Rohár]

Define PCIe aperture for top level soc node handled by mbus driver and
define PCIe controller node with one PCIe Root Port.

Old Orion arch code maps first 16 MB of PCIe config space to physical
address 0xf0000000. But for full PCIe support it is needed to map whole
256 MB long PCIe config space.

There are probably no Orion boards with more than 2 GB of RAM, so 256 MB of
free physical address space must exist. Tests on Orion board proved that
there is free space in physical address range 0xd0000000-0xdfffffff.

So use this physical space for mapping whole 256 MB long PCIe config space.
In case there would be some issue with this range, particular Orion device
tree board file can change it to 16 MB size or move it to old location.

By default orion5x.dtsi include file would contains whole PCIe config space
for full PCIe support.

By default is PCIe node disabled, so this change in orion5x.dtsi has no
effect for any board until board dts file explicitly enable it. Each board
has to migrate its PCIe code from old arch specific to device tree based.

Signed-off-by: Pali Rohár <pali@kernel.org>
---
Changes in v3:
* New patch
---
 arch/arm/boot/dts/orion5x.dtsi | 51 ++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm/boot/dts/orion5x.dtsi b/arch/arm/boot/dts/orion5x.dtsi
index 2d41f5c166ee..41954d96ebbf 100644
--- a/arch/arm/boot/dts/orion5x.dtsi
+++ b/arch/arm/boot/dts/orion5x.dtsi
@@ -18,6 +18,9 @@
 		#address-cells = <2>;
 		#size-cells = <1>;
 		controller = <&mbusc>;
+		pcie-cfg-aperture = <0xd0000000 0x10000000>; /* 256 MiB config space */
+		pcie-mem-aperture = <0xe0000000 0x08000000>; /* 128 MiB memory space */
+		pcie-io-aperture  = <0xf2000000 0x00100000>; /*   1 MiB I/O space */
 
 		devbus_bootcs: devbus-bootcs {
 			compatible = "marvell,orion-devbus";
@@ -226,6 +229,54 @@
 			};
 		};
 
+		pciec: pcie {
+			compatible = "marvell,orion5x-pcie";
+			status = "disabled";
+			device_type = "pci";
+			#address-cells = <3>;
+			#size-cells = <2>;
+
+			msi-parent = <&intc>;
+			bus-range = <0x00 0xff>;
+
+			ranges = <0x82000000 0x0    0x40000  MBUS_ID(0xf0, 0x01) 0x40000  0x0     0x2000>, /* Port 0.0 Internal registers */
+				 <0x82000000 0x0 0xf0000000  MBUS_ID(0x04, 0x79)     0x0  0x0 0x10000000>, /* Port 0.0 Config space registers */
+				 <0x82000000 0x1 0x00000000  MBUS_ID(0x04, 0x59)     0x0  0x1 0x00000000>, /* Port 0.0 Mem */
+				 <0x81000000 0x1 0x00000000  MBUS_ID(0x04, 0x51)     0x0  0x1 0x00000000>; /* Port 0.0 I/O */
+
+			pcie0: pcie@1,0 {
+				status = "disabled";
+				reg = <0x0800 0 0 0 0>;
+				device_type = "pci";
+				#address-cells = <3>;
+				#size-cells = <2>;
+
+				assigned-addresses =         <0x82000800 0x0    0x40000  0x0     0x2000>, /* Port 0.0 Internal registers */
+						             <0x82000800 0x0 0xf0000000  0x0 0x10000000>; /* Port 0.0 Config space registers */
+				ranges = <0x82000000 0x0 0x0  0x82000000 0x1 0x00000000  0x1 0x00000000>, /* Port 0.0 Mem */
+				         <0x81000000 0x0 0x0  0x81000000 0x1 0x00000000  0x1 0x00000000>; /* Port 0.0 I/O */
+				bus-range = <0x00 0xff>;
+
+				clocks = <&core_clk 0>;
+				marvell,pcie-port = <0>;
+				marvell,pcie-lane = <0>;
+
+				#interrupt-cells = <1>;
+				interrupt-names = "intx", "error";
+				interrupts = <11>, <10>;
+				interrupt-map-mask = <0 0 0 7>;
+				interrupt-map = <0 0 0 1 &pcie_intc 0>,
+						<0 0 0 2 &pcie_intc 1>,
+						<0 0 0 3 &pcie_intc 2>,
+						<0 0 0 4 &pcie_intc 3>;
+
+				pcie_intc: interrupt-controller {
+					interrupt-controller;
+					#interrupt-cells = <1>;
+				};
+			};
+		};
+
 		crypto_sram: sa-sram {
 			compatible = "mmio-sram";
 			reg = <MBUS_ID(0x09, 0x00) 0x0 0x800>;
-- 
2.20.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 3/7] dt-bindings: PCI: mvebu: Add orion5x compatible

[Rob Herring]

On Mon, 05 Sep 2022 21:23:06 +0200, Pali Rohár wrote:
> From: Mauri Sandberg <maukka@ext.kapsi.fi>
> 
> Add a compatible string to bindings to indicate that orion5x PCIe is
> supported too. Orion requires additional bindings for config space
> registers.
> 
> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> Signed-off-by: Pali Rohár <pali@kernel.org>
> ---
> Changes in v3:
> * Add more detailed information about MMIO registers
> ---
>  Documentation/devicetree/bindings/pci/mvebu-pci.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring <robh@kernel.org>

Re: [PATCH v3 3/7] dt-bindings: PCI: mvebu: Add orion5x compatible

[Rob Herring]

On Mon, 05 Sep 2022 21:23:06 +0200, Pali Rohár wrote:
> From: Mauri Sandberg <maukka@ext.kapsi.fi>
> 
> Add a compatible string to bindings to indicate that orion5x PCIe is
> supported too. Orion requires additional bindings for config space
> registers.
> 
> Signed-off-by: Mauri Sandberg <maukka@ext.kapsi.fi>
> Signed-off-by: Pali Rohár <pali@kernel.org>
> ---
> Changes in v3:
> * Add more detailed information about MMIO registers
> ---
>  Documentation/devicetree/bindings/pci/mvebu-pci.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring <robh@kernel.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/7] PCI: mvebu: add support for orion soc

[Lorenzo Pieralisi]

On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Rohár wrote:
> Hello! This patch series add support for Orion PCIe controller into
> pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> to parse all physical addresses from device tree files according to
> mvebu-pci.txt documentation, allow access to all extended PCIe config
> space registers and use modern kernel API pci_remap_cfgspace() and
> mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
> 
> Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> there because this change and it is de-facto API between dts files and
> kernel used for a long time. Note that it is misused according to PCI
> device tree bindings, but we have to follow this Marvell bindings to do
> not introduce backward incompatibility issues for other non-Orion
> platforms.
> 
> Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> PCIe AER is working too (one of the feature which proved that access to
> extended PCIe config registers is working fine).
> 
> After this patch is accepted we are planning to look at existing Orion
> arch specific code and covert it to use this new DT based pci-mvebu.c
> code. Later this would allow to kill arch specific Orion PCIe code,
> which is in arch/arm/plat-orion/pcie.c and parts also in file
> arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
> 
> This patch series depends on another patches:
> https://lore.kernel.org/linux-pci/20220524122817.7199-1-pali@kernel.org/
> https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/

Can I rebase it on top of v6.0-rc1 ? I will not be able to pull it till
-rc7 but I don't think there is a strict dependency so we should try to
upstream it this cycle.

Lorenzo

> 
> Mauri Sandberg (2):
>   bus: mvebu-mbus: add configuration space aperture
>   dt-bindings: PCI: mvebu: Add orion5x compatible
> 
> Pali Rohár (5):
>   ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
>     pcie_setup()
>   PCI: mvebu: Remove unused busn member
>   PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
>   PCI: mvebu: Add support for Orion PCIe controller
>   ARM: dts: orion5x: Add PCIe node
> 
>  .../devicetree/bindings/pci/mvebu-pci.txt     |   4 +-
>  arch/arm/boot/dts/orion5x.dtsi                |  51 +++++
>  arch/arm/mach-orion5x/common.c                |  13 --
>  arch/arm/mach-orion5x/pci.c                   |  14 ++
>  drivers/bus/mvebu-mbus.c                      |  26 ++-
>  drivers/pci/controller/Kconfig                |   4 +-
>  drivers/pci/controller/pci-mvebu.c            | 202 ++++++++++++++----
>  include/linux/mbus.h                          |   1 +
>  8 files changed, 256 insertions(+), 59 deletions(-)
> 
> -- 
> 2.20.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/7] PCI: mvebu: add support for orion soc

[Lorenzo Pieralisi]

On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Rohár wrote:
> Hello! This patch series add support for Orion PCIe controller into
> pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> to parse all physical addresses from device tree files according to
> mvebu-pci.txt documentation, allow access to all extended PCIe config
> space registers and use modern kernel API pci_remap_cfgspace() and
> mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
> 
> Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> there because this change and it is de-facto API between dts files and
> kernel used for a long time. Note that it is misused according to PCI
> device tree bindings, but we have to follow this Marvell bindings to do
> not introduce backward incompatibility issues for other non-Orion
> platforms.
> 
> Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> PCIe AER is working too (one of the feature which proved that access to
> extended PCIe config registers is working fine).
> 
> After this patch is accepted we are planning to look at existing Orion
> arch specific code and covert it to use this new DT based pci-mvebu.c
> code. Later this would allow to kill arch specific Orion PCIe code,
> which is in arch/arm/plat-orion/pcie.c and parts also in file
> arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
> 
> This patch series depends on another patches:
> https://lore.kernel.org/linux-pci/20220524122817.7199-1-pali@kernel.org/
> https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/

Can I rebase it on top of v6.0-rc1 ? I will not be able to pull it till
-rc7 but I don't think there is a strict dependency so we should try to
upstream it this cycle.

Lorenzo

> 
> Mauri Sandberg (2):
>   bus: mvebu-mbus: add configuration space aperture
>   dt-bindings: PCI: mvebu: Add orion5x compatible
> 
> Pali Rohár (5):
>   ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
>     pcie_setup()
>   PCI: mvebu: Remove unused busn member
>   PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
>   PCI: mvebu: Add support for Orion PCIe controller
>   ARM: dts: orion5x: Add PCIe node
> 
>  .../devicetree/bindings/pci/mvebu-pci.txt     |   4 +-
>  arch/arm/boot/dts/orion5x.dtsi                |  51 +++++
>  arch/arm/mach-orion5x/common.c                |  13 --
>  arch/arm/mach-orion5x/pci.c                   |  14 ++
>  drivers/bus/mvebu-mbus.c                      |  26 ++-
>  drivers/pci/controller/Kconfig                |   4 +-
>  drivers/pci/controller/pci-mvebu.c            | 202 ++++++++++++++----
>  include/linux/mbus.h                          |   1 +
>  8 files changed, 256 insertions(+), 59 deletions(-)
> 
> -- 
> 2.20.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/7] PCI: mvebu: add support for orion soc

[Lorenzo Pieralisi]

On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Rohár wrote:
> Hello! This patch series add support for Orion PCIe controller into
> pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> to parse all physical addresses from device tree files according to
> mvebu-pci.txt documentation, allow access to all extended PCIe config
> space registers and use modern kernel API pci_remap_cfgspace() and
> mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
> 
> Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> there because this change and it is de-facto API between dts files and
> kernel used for a long time. Note that it is misused according to PCI
> device tree bindings, but we have to follow this Marvell bindings to do
> not introduce backward incompatibility issues for other non-Orion
> platforms.
> 
> Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> PCIe AER is working too (one of the feature which proved that access to
> extended PCIe config registers is working fine).
> 
> After this patch is accepted we are planning to look at existing Orion
> arch specific code and covert it to use this new DT based pci-mvebu.c
> code. Later this would allow to kill arch specific Orion PCIe code,
> which is in arch/arm/plat-orion/pcie.c and parts also in file
> arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
> 
> This patch series depends on another patches:
> https://lore.kernel.org/linux-pci/20220524122817.7199-1-pali@kernel.org/
> https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/

Can this series be rebased please on top of v6.1-rc1 so that we can merge it ?

Thanks,
Lorenzo

> Mauri Sandberg (2):
>   bus: mvebu-mbus: add configuration space aperture
>   dt-bindings: PCI: mvebu: Add orion5x compatible
> 
> Pali Rohár (5):
>   ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
>     pcie_setup()
>   PCI: mvebu: Remove unused busn member
>   PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
>   PCI: mvebu: Add support for Orion PCIe controller
>   ARM: dts: orion5x: Add PCIe node
> 
>  .../devicetree/bindings/pci/mvebu-pci.txt     |   4 +-
>  arch/arm/boot/dts/orion5x.dtsi                |  51 +++++
>  arch/arm/mach-orion5x/common.c                |  13 --
>  arch/arm/mach-orion5x/pci.c                   |  14 ++
>  drivers/bus/mvebu-mbus.c                      |  26 ++-
>  drivers/pci/controller/Kconfig                |   4 +-
>  drivers/pci/controller/pci-mvebu.c            | 202 ++++++++++++++----
>  include/linux/mbus.h                          |   1 +
>  8 files changed, 256 insertions(+), 59 deletions(-)
> 
> -- 
> 2.20.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/7] PCI: mvebu: add support for orion soc

[Lorenzo Pieralisi]

On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Rohár wrote:
> Hello! This patch series add support for Orion PCIe controller into
> pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> to parse all physical addresses from device tree files according to
> mvebu-pci.txt documentation, allow access to all extended PCIe config
> space registers and use modern kernel API pci_remap_cfgspace() and
> mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
> 
> Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> there because this change and it is de-facto API between dts files and
> kernel used for a long time. Note that it is misused according to PCI
> device tree bindings, but we have to follow this Marvell bindings to do
> not introduce backward incompatibility issues for other non-Orion
> platforms.
> 
> Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> PCIe AER is working too (one of the feature which proved that access to
> extended PCIe config registers is working fine).
> 
> After this patch is accepted we are planning to look at existing Orion
> arch specific code and covert it to use this new DT based pci-mvebu.c
> code. Later this would allow to kill arch specific Orion PCIe code,
> which is in arch/arm/plat-orion/pcie.c and parts also in file
> arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
> 
> This patch series depends on another patches:
> https://lore.kernel.org/linux-pci/20220524122817.7199-1-pali@kernel.org/
> https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/

Can this series be rebased please on top of v6.1-rc1 so that we can merge it ?

Thanks,
Lorenzo

> Mauri Sandberg (2):
>   bus: mvebu-mbus: add configuration space aperture
>   dt-bindings: PCI: mvebu: Add orion5x compatible
> 
> Pali Rohár (5):
>   ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
>     pcie_setup()
>   PCI: mvebu: Remove unused busn member
>   PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
>   PCI: mvebu: Add support for Orion PCIe controller
>   ARM: dts: orion5x: Add PCIe node
> 
>  .../devicetree/bindings/pci/mvebu-pci.txt     |   4 +-
>  arch/arm/boot/dts/orion5x.dtsi                |  51 +++++
>  arch/arm/mach-orion5x/common.c                |  13 --
>  arch/arm/mach-orion5x/pci.c                   |  14 ++
>  drivers/bus/mvebu-mbus.c                      |  26 ++-
>  drivers/pci/controller/Kconfig                |   4 +-
>  drivers/pci/controller/pci-mvebu.c            | 202 ++++++++++++++----
>  include/linux/mbus.h                          |   1 +
>  8 files changed, 256 insertions(+), 59 deletions(-)
> 
> -- 
> 2.20.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/7] PCI: mvebu: add support for orion soc

[Pali Rohár]

On Thursday 27 October 2022 16:10:48 Lorenzo Pieralisi wrote:
> On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Rohár wrote:
> > Hello! This patch series add support for Orion PCIe controller into
> > pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> > to parse all physical addresses from device tree files according to
> > mvebu-pci.txt documentation, allow access to all extended PCIe config
> > space registers and use modern kernel API pci_remap_cfgspace() and
> > mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
> > 
> > Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> > there because this change and it is de-facto API between dts files and
> > kernel used for a long time. Note that it is misused according to PCI
> > device tree bindings, but we have to follow this Marvell bindings to do
> > not introduce backward incompatibility issues for other non-Orion
> > platforms.
> > 
> > Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> > PCIe AER is working too (one of the feature which proved that access to
> > extended PCIe config registers is working fine).
> > 
> > After this patch is accepted we are planning to look at existing Orion
> > arch specific code and covert it to use this new DT based pci-mvebu.c
> > code. Later this would allow to kill arch specific Orion PCIe code,
> > which is in arch/arm/plat-orion/pcie.c and parts also in file
> > arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
> > 
> > This patch series depends on another patches:
> > https://lore.kernel.org/linux-pci/20220524122817.7199-1-pali@kernel.org/
> > https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/
> 
> Can this series be rebased please on top of v6.1-rc1 so that we can merge it ?

IIRC above two dependent patches still applies on master branch and this
patch series applies on above two dependent patches.

> Thanks,
> Lorenzo
> 
> > Mauri Sandberg (2):
> >   bus: mvebu-mbus: add configuration space aperture
> >   dt-bindings: PCI: mvebu: Add orion5x compatible
> > 
> > Pali Rohár (5):
> >   ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
> >     pcie_setup()
> >   PCI: mvebu: Remove unused busn member
> >   PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
> >   PCI: mvebu: Add support for Orion PCIe controller
> >   ARM: dts: orion5x: Add PCIe node
> > 
> >  .../devicetree/bindings/pci/mvebu-pci.txt     |   4 +-
> >  arch/arm/boot/dts/orion5x.dtsi                |  51 +++++
> >  arch/arm/mach-orion5x/common.c                |  13 --
> >  arch/arm/mach-orion5x/pci.c                   |  14 ++
> >  drivers/bus/mvebu-mbus.c                      |  26 ++-
> >  drivers/pci/controller/Kconfig                |   4 +-
> >  drivers/pci/controller/pci-mvebu.c            | 202 ++++++++++++++----
> >  include/linux/mbus.h                          |   1 +
> >  8 files changed, 256 insertions(+), 59 deletions(-)
> > 
> > -- 
> > 2.20.1
> > 
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/7] PCI: mvebu: add support for orion soc

[Pali Rohár]

On Thursday 27 October 2022 16:10:48 Lorenzo Pieralisi wrote:
> On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Rohár wrote:
> > Hello! This patch series add support for Orion PCIe controller into
> > pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> > to parse all physical addresses from device tree files according to
> > mvebu-pci.txt documentation, allow access to all extended PCIe config
> > space registers and use modern kernel API pci_remap_cfgspace() and
> > mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
> > 
> > Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> > there because this change and it is de-facto API between dts files and
> > kernel used for a long time. Note that it is misused according to PCI
> > device tree bindings, but we have to follow this Marvell bindings to do
> > not introduce backward incompatibility issues for other non-Orion
> > platforms.
> > 
> > Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> > PCIe AER is working too (one of the feature which proved that access to
> > extended PCIe config registers is working fine).
> > 
> > After this patch is accepted we are planning to look at existing Orion
> > arch specific code and covert it to use this new DT based pci-mvebu.c
> > code. Later this would allow to kill arch specific Orion PCIe code,
> > which is in arch/arm/plat-orion/pcie.c and parts also in file
> > arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
> > 
> > This patch series depends on another patches:
> > https://lore.kernel.org/linux-pci/20220524122817.7199-1-pali@kernel.org/
> > https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/
> 
> Can this series be rebased please on top of v6.1-rc1 so that we can merge it ?

IIRC above two dependent patches still applies on master branch and this
patch series applies on above two dependent patches.

> Thanks,
> Lorenzo
> 
> > Mauri Sandberg (2):
> >   bus: mvebu-mbus: add configuration space aperture
> >   dt-bindings: PCI: mvebu: Add orion5x compatible
> > 
> > Pali Rohár (5):
> >   ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
> >     pcie_setup()
> >   PCI: mvebu: Remove unused busn member
> >   PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
> >   PCI: mvebu: Add support for Orion PCIe controller
> >   ARM: dts: orion5x: Add PCIe node
> > 
> >  .../devicetree/bindings/pci/mvebu-pci.txt     |   4 +-
> >  arch/arm/boot/dts/orion5x.dtsi                |  51 +++++
> >  arch/arm/mach-orion5x/common.c                |  13 --
> >  arch/arm/mach-orion5x/pci.c                   |  14 ++
> >  drivers/bus/mvebu-mbus.c                      |  26 ++-
> >  drivers/pci/controller/Kconfig                |   4 +-
> >  drivers/pci/controller/pci-mvebu.c            | 202 ++++++++++++++----
> >  include/linux/mbus.h                          |   1 +
> >  8 files changed, 256 insertions(+), 59 deletions(-)
> > 
> > -- 
> > 2.20.1
> > 
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/7] PCI: mvebu: add support for orion soc

[Lorenzo Pieralisi]

On Mon, Nov 07, 2022 at 12:28:24AM +0100, Pali Rohár wrote:
> On Thursday 27 October 2022 16:10:48 Lorenzo Pieralisi wrote:
> > On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Rohár wrote:
> > > Hello! This patch series add support for Orion PCIe controller into
> > > pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> > > to parse all physical addresses from device tree files according to
> > > mvebu-pci.txt documentation, allow access to all extended PCIe config
> > > space registers and use modern kernel API pci_remap_cfgspace() and
> > > mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
> > > 
> > > Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> > > there because this change and it is de-facto API between dts files and
> > > kernel used for a long time. Note that it is misused according to PCI
> > > device tree bindings, but we have to follow this Marvell bindings to do
> > > not introduce backward incompatibility issues for other non-Orion
> > > platforms.
> > > 
> > > Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> > > PCIe AER is working too (one of the feature which proved that access to
> > > extended PCIe config registers is working fine).
> > > 
> > > After this patch is accepted we are planning to look at existing Orion
> > > arch specific code and covert it to use this new DT based pci-mvebu.c
> > > code. Later this would allow to kill arch specific Orion PCIe code,
> > > which is in arch/arm/plat-orion/pcie.c and parts also in file
> > > arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
> > > 
> > > This patch series depends on another patches:
> > > https://lore.kernel.org/linux-pci/20220524122817.7199-1-pali@kernel.org/
> > > https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/
> > 
> > Can this series be rebased please on top of v6.1-rc1 so that we can merge it ?
> 
> IIRC above two dependent patches still applies on master branch and this
> patch series applies on above two dependent patches.

Which I can't merge for reasons you are aware of already.

So, does this series _really_ depend on the two patches above ?

I don't think so but let me ask again.

Lorenzo

> > Thanks,
> > Lorenzo
> > 
> > > Mauri Sandberg (2):
> > >   bus: mvebu-mbus: add configuration space aperture
> > >   dt-bindings: PCI: mvebu: Add orion5x compatible
> > > 
> > > Pali Rohár (5):
> > >   ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
> > >     pcie_setup()
> > >   PCI: mvebu: Remove unused busn member
> > >   PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
> > >   PCI: mvebu: Add support for Orion PCIe controller
> > >   ARM: dts: orion5x: Add PCIe node
> > > 
> > >  .../devicetree/bindings/pci/mvebu-pci.txt     |   4 +-
> > >  arch/arm/boot/dts/orion5x.dtsi                |  51 +++++
> > >  arch/arm/mach-orion5x/common.c                |  13 --
> > >  arch/arm/mach-orion5x/pci.c                   |  14 ++
> > >  drivers/bus/mvebu-mbus.c                      |  26 ++-
> > >  drivers/pci/controller/Kconfig                |   4 +-
> > >  drivers/pci/controller/pci-mvebu.c            | 202 ++++++++++++++----
> > >  include/linux/mbus.h                          |   1 +
> > >  8 files changed, 256 insertions(+), 59 deletions(-)
> > > 
> > > -- 
> > > 2.20.1
> > > 
> > > 
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/7] PCI: mvebu: add support for orion soc

[Lorenzo Pieralisi]

On Mon, Nov 07, 2022 at 12:28:24AM +0100, Pali Rohár wrote:
> On Thursday 27 October 2022 16:10:48 Lorenzo Pieralisi wrote:
> > On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Rohár wrote:
> > > Hello! This patch series add support for Orion PCIe controller into
> > > pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> > > to parse all physical addresses from device tree files according to
> > > mvebu-pci.txt documentation, allow access to all extended PCIe config
> > > space registers and use modern kernel API pci_remap_cfgspace() and
> > > mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
> > > 
> > > Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> > > there because this change and it is de-facto API between dts files and
> > > kernel used for a long time. Note that it is misused according to PCI
> > > device tree bindings, but we have to follow this Marvell bindings to do
> > > not introduce backward incompatibility issues for other non-Orion
> > > platforms.
> > > 
> > > Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> > > PCIe AER is working too (one of the feature which proved that access to
> > > extended PCIe config registers is working fine).
> > > 
> > > After this patch is accepted we are planning to look at existing Orion
> > > arch specific code and covert it to use this new DT based pci-mvebu.c
> > > code. Later this would allow to kill arch specific Orion PCIe code,
> > > which is in arch/arm/plat-orion/pcie.c and parts also in file
> > > arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
> > > 
> > > This patch series depends on another patches:
> > > https://lore.kernel.org/linux-pci/20220524122817.7199-1-pali@kernel.org/
> > > https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/
> > 
> > Can this series be rebased please on top of v6.1-rc1 so that we can merge it ?
> 
> IIRC above two dependent patches still applies on master branch and this
> patch series applies on above two dependent patches.

Which I can't merge for reasons you are aware of already.

So, does this series _really_ depend on the two patches above ?

I don't think so but let me ask again.

Lorenzo

> > Thanks,
> > Lorenzo
> > 
> > > Mauri Sandberg (2):
> > >   bus: mvebu-mbus: add configuration space aperture
> > >   dt-bindings: PCI: mvebu: Add orion5x compatible
> > > 
> > > Pali Rohár (5):
> > >   ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
> > >     pcie_setup()
> > >   PCI: mvebu: Remove unused busn member
> > >   PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
> > >   PCI: mvebu: Add support for Orion PCIe controller
> > >   ARM: dts: orion5x: Add PCIe node
> > > 
> > >  .../devicetree/bindings/pci/mvebu-pci.txt     |   4 +-
> > >  arch/arm/boot/dts/orion5x.dtsi                |  51 +++++
> > >  arch/arm/mach-orion5x/common.c                |  13 --
> > >  arch/arm/mach-orion5x/pci.c                   |  14 ++
> > >  drivers/bus/mvebu-mbus.c                      |  26 ++-
> > >  drivers/pci/controller/Kconfig                |   4 +-
> > >  drivers/pci/controller/pci-mvebu.c            | 202 ++++++++++++++----
> > >  include/linux/mbus.h                          |   1 +
> > >  8 files changed, 256 insertions(+), 59 deletions(-)
> > > 
> > > -- 
> > > 2.20.1
> > > 
> > > 
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/7] PCI: mvebu: add support for orion soc

[Pali Rohár]

On Friday 11 November 2022 13:49:57 Lorenzo Pieralisi wrote:
> On Mon, Nov 07, 2022 at 12:28:24AM +0100, Pali Rohár wrote:
> > On Thursday 27 October 2022 16:10:48 Lorenzo Pieralisi wrote:
> > > On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Rohár wrote:
> > > > Hello! This patch series add support for Orion PCIe controller into
> > > > pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> > > > to parse all physical addresses from device tree files according to
> > > > mvebu-pci.txt documentation, allow access to all extended PCIe config
> > > > space registers and use modern kernel API pci_remap_cfgspace() and
> > > > mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
> > > > 
> > > > Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> > > > there because this change and it is de-facto API between dts files and
> > > > kernel used for a long time. Note that it is misused according to PCI
> > > > device tree bindings, but we have to follow this Marvell bindings to do
> > > > not introduce backward incompatibility issues for other non-Orion
> > > > platforms.
> > > > 
> > > > Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> > > > PCIe AER is working too (one of the feature which proved that access to
> > > > extended PCIe config registers is working fine).
> > > > 
> > > > After this patch is accepted we are planning to look at existing Orion
> > > > arch specific code and covert it to use this new DT based pci-mvebu.c
> > > > code. Later this would allow to kill arch specific Orion PCIe code,
> > > > which is in arch/arm/plat-orion/pcie.c and parts also in file
> > > > arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
> > > > 
> > > > This patch series depends on another patches:
> > > > https://lore.kernel.org/linux-pci/20220524122817.7199-1-pali@kernel.org/
> > > > https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/
> > > 
> > > Can this series be rebased please on top of v6.1-rc1 so that we can merge it ?
> > 
> > IIRC above two dependent patches still applies on master branch and this
> > patch series applies on above two dependent patches.
> 
> Which I can't merge for reasons you are aware of already.
> 
> So, does this series _really_ depend on the two patches above ?
> 
> I don't think so but let me ask again.
> 
> Lorenzo

Yes, this patch series depends on above tow patches. Kirkwood and older
platforms (including the oldest one Orion) needs fixes for registering
and handling of shared interrupts.

> > > Thanks,
> > > Lorenzo
> > > 
> > > > Mauri Sandberg (2):
> > > >   bus: mvebu-mbus: add configuration space aperture
> > > >   dt-bindings: PCI: mvebu: Add orion5x compatible
> > > > 
> > > > Pali Rohár (5):
> > > >   ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
> > > >     pcie_setup()
> > > >   PCI: mvebu: Remove unused busn member
> > > >   PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
> > > >   PCI: mvebu: Add support for Orion PCIe controller
> > > >   ARM: dts: orion5x: Add PCIe node
> > > > 
> > > >  .../devicetree/bindings/pci/mvebu-pci.txt     |   4 +-
> > > >  arch/arm/boot/dts/orion5x.dtsi                |  51 +++++
> > > >  arch/arm/mach-orion5x/common.c                |  13 --
> > > >  arch/arm/mach-orion5x/pci.c                   |  14 ++
> > > >  drivers/bus/mvebu-mbus.c                      |  26 ++-
> > > >  drivers/pci/controller/Kconfig                |   4 +-
> > > >  drivers/pci/controller/pci-mvebu.c            | 202 ++++++++++++++----
> > > >  include/linux/mbus.h                          |   1 +
> > > >  8 files changed, 256 insertions(+), 59 deletions(-)
> > > > 
> > > > -- 
> > > > 2.20.1
> > > > 
> > > > 
> > > > _______________________________________________
> > > > linux-arm-kernel mailing list
> > > > linux-arm-kernel@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v3 0/7] PCI: mvebu: add support for orion soc

[Pali Rohár]

On Friday 11 November 2022 13:49:57 Lorenzo Pieralisi wrote:
> On Mon, Nov 07, 2022 at 12:28:24AM +0100, Pali Rohár wrote:
> > On Thursday 27 October 2022 16:10:48 Lorenzo Pieralisi wrote:
> > > On Mon, Sep 05, 2022 at 09:23:03PM +0200, Pali Rohár wrote:
> > > > Hello! This patch series add support for Orion PCIe controller into
> > > > pci-mvebu.c driver. V3 version has completely rewritten pci-mvebu.c code
> > > > to parse all physical addresses from device tree files according to
> > > > mvebu-pci.txt documentation, allow access to all extended PCIe config
> > > > space registers and use modern kernel API pci_remap_cfgspace() and
> > > > mvebu_mbus_add_window_by_id() fir mapping PCIe config space.
> > > > 
> > > > Most of Marvell device tree code in pci-mvebu.c is giant magic, but it was
> > > > there because this change and it is de-facto API between dts files and
> > > > kernel used for a long time. Note that it is misused according to PCI
> > > > device tree bindings, but we have to follow this Marvell bindings to do
> > > > not introduce backward incompatibility issues for other non-Orion
> > > > platforms.
> > > > 
> > > > Mauri tested these changes on DNS323 board with both DT and non-DT builds.
> > > > PCIe AER is working too (one of the feature which proved that access to
> > > > extended PCIe config registers is working fine).
> > > > 
> > > > After this patch is accepted we are planning to look at existing Orion
> > > > arch specific code and covert it to use this new DT based pci-mvebu.c
> > > > code. Later this would allow to kill arch specific Orion PCIe code,
> > > > which is in arch/arm/plat-orion/pcie.c and parts also in file
> > > > arch/arm/mach-orion5x/pci.c (shared with old-PCI bus code).
> > > > 
> > > > This patch series depends on another patches:
> > > > https://lore.kernel.org/linux-pci/20220524122817.7199-1-pali@kernel.org/
> > > > https://lore.kernel.org/linux-pci/20220817230036.817-3-pali@kernel.org/
> > > 
> > > Can this series be rebased please on top of v6.1-rc1 so that we can merge it ?
> > 
> > IIRC above two dependent patches still applies on master branch and this
> > patch series applies on above two dependent patches.
> 
> Which I can't merge for reasons you are aware of already.
> 
> So, does this series _really_ depend on the two patches above ?
> 
> I don't think so but let me ask again.
> 
> Lorenzo

Yes, this patch series depends on above tow patches. Kirkwood and older
platforms (including the oldest one Orion) needs fixes for registering
and handling of shared interrupts.

> > > Thanks,
> > > Lorenzo
> > > 
> > > > Mauri Sandberg (2):
> > > >   bus: mvebu-mbus: add configuration space aperture
> > > >   dt-bindings: PCI: mvebu: Add orion5x compatible
> > > > 
> > > > Pali Rohár (5):
> > > >   ARM: orion: Move PCIe mbus window mapping from orion5x_setup_wins() to
> > > >     pcie_setup()
> > > >   PCI: mvebu: Remove unused busn member
> > > >   PCI: mvebu: Cleanup error handling in mvebu_pcie_probe()
> > > >   PCI: mvebu: Add support for Orion PCIe controller
> > > >   ARM: dts: orion5x: Add PCIe node
> > > > 
> > > >  .../devicetree/bindings/pci/mvebu-pci.txt     |   4 +-
> > > >  arch/arm/boot/dts/orion5x.dtsi                |  51 +++++
> > > >  arch/arm/mach-orion5x/common.c                |  13 --
> > > >  arch/arm/mach-orion5x/pci.c                   |  14 ++
> > > >  drivers/bus/mvebu-mbus.c                      |  26 ++-
> > > >  drivers/pci/controller/Kconfig                |   4 +-
> > > >  drivers/pci/controller/pci-mvebu.c            | 202 ++++++++++++++----
> > > >  include/linux/mbus.h                          |   1 +
> > > >  8 files changed, 256 insertions(+), 59 deletions(-)
> > > > 
> > > > -- 
> > > > 2.20.1
> > > > 
> > > > 
> > > > _______________________________________________
> > > > linux-arm-kernel mailing list
> > > > linux-arm-kernel@lists.infradead.org
> > > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel