Skip to contentSkip to conversation

R-Car Gen2 PCIe host driver

PATCH Superseded Phil Edworthy 6 participants 29 messages Mar 25, 2014 – Mar 26, 2014

Subsystems (8)

v5 of 8 Superseded Latest is v8 →

lore
Share & tools
lore
#0 lore raw

v5 cover R-Car Gen2 PCIe host driver

This is version 5 of a PCIe Host driver for the R-Car Gen2 devices, i.e. R-Car H2 (r8a7790) and R-Car M2 (r8a7791).

v5:
- Use module_platform_driver instead of subsys_initcall
- Use the of_device_id data field for HW init function
- Init hw_pci struct in declaration
- Renesas SoC compatible string has peripheral before device name
- Add PCIe bus clock reference
- Use dma-ranges property to specify inbound memory regions
- Support multiple IO windows and correct resources
- Return IRQ_NONE from MSI isr when there is no pending MSI
- Add additional interrupt bindings

v4:
- Use runtime PM properly

Phil Edworthy (9):
PCI: host: rcar: Add Renesas R-Car PCIe driver
PCI: host: rcar: Add MSI support
ARM: shmobile: r8a7790: Add PCIe clock device tree nodes
ARM: shmobile: r8a7791: Add PCIe clock device tree nodes
dt-bindings: pci: rcar pcie device tree bindings
ARM: shmobile: Add PCIe device tree nodes for R8A7790
ARM: shmobile: Add PCIe device tree nodes for R8A7791 Koelsch board
ARM: koelsch: Add PCIe to defconfig
ARM: koelsch: Add HAVE_ARM_ARCH_TIMER to defconfig

 Documentation/devicetree/bindings/pci/rcar-pci.txt |  44 +
 arch/arm/boot/dts/r8a7790-lager.dts                |  10 +
 arch/arm/boot/dts/r8a7790.dtsi                     |  31 +-
 arch/arm/boot/dts/r8a7791-koelsch.dts              |  14 +
 arch/arm/boot/dts/r8a7791.dtsi                     |  31 +-
 arch/arm/configs/koelsch_defconfig                 |   4 +
 drivers/pci/host/Kconfig                           |   6 +
 drivers/pci/host/Makefile                          |   1 +
 drivers/pci/host/pcie-rcar.c                       | 937 +++++++++++++++++++++
 drivers/pci/host/pcie-rcar.h                       |  87 ++
 include/dt-bindings/clock/r8a7790-clock.h          |   1 +
 include/dt-bindings/clock/r8a7791-clock.h          |   1 +
 12 files changed, 1162 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/rcar-pci.txt
 create mode 100644 drivers/pci/host/pcie-rcar.c
 create mode 100644 drivers/pci/host/pcie-rcar.h
Signature · 1 line
1.9.0
#1 lore raw

PATCH v5 1/9 PCI: host: rcar: Add Renesas R-Car PCIe driver

This PCIe Host driver currently does not support MSI, so cards fall back to INTx interrupts.

---
v5:
- Use module_platform_driver instead of subsys_initcall
- Use the of_device_id data field for HW init function
- Init hw_pci struct in declaration
- Renesas SoC compatible string has peripheral before device name
- Add PCIe bus clock reference
- Use dma-ranges property to specify inbound memory regions
- Support multiple IO windows and correct resources

v4:
- Use runtime PM properly

v3:
- Add DT support
- Use 'of_irq_parse_and_map_pci' for '.map_irq'
- Use pm ops to enable clocks
- Fix checkpatch errors
- Use subsys_initcall to overcome issues with port bus driver
- Adjust Kconfig to match other R-Car drivers

v2:
- Use msleep instead of udelay when waiting for the link
- Use pm_runtime
- Removed unused definition
- Also replaced call to devm_request_and_ioremap with devm_ioremap_resource and fixed a bug with this when reporting errors.

---
 drivers/pci/host/Kconfig     |   6 +
 drivers/pci/host/Makefile    |   1 +
 drivers/pci/host/pcie-rcar.c | 693 +++++++++++++++++++++++++++++++++++++++++++
 drivers/pci/host/pcie-rcar.h |  82 +++++
 4 files changed, 782 insertions(+)
 create mode 100644 drivers/pci/host/pcie-rcar.c
 create mode 100644 drivers/pci/host/pcie-rcar.h
drivers/pci/host/Kconfig +6 -0
index 47d46c6..dc627e5 100644
@@ -33,4 +33,10 @@ config PCI_RCAR_GEN2
 	  There are 3 internal PCI controllers available with a single
 	  built-in EHCI/OHCI host controller present on each one.
 
+config PCI_RCAR_GEN2_PCIE
+	bool "Renesas R-Car PCIe controller"
+	depends on ARCH_SHMOBILE || (ARM && COMPILE_TEST)
+	help
+	  Say Y here if you want PCIe controller support on R-Car Gen2 SoCs.
+
 endmenu
drivers/pci/host/Makefile +1 -0
index 13fb333..19946f9 100644
@@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_IMX6) += pci-imx6.o
 obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
 obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o
 obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o
+obj-$(CONFIG_PCI_RCAR_GEN2_PCIE) += pcie-rcar.o
drivers/pci/host/pcie-rcar.c new file +693 -0

693 lines not on this page · raw message

drivers/pci/host/pcie-rcar.h new file +82 -0

82 lines not on this page · raw message

Signature · 1 line
1.9.0
#2 lore raw

PATCH v5 2/9 PCI: host: rcar: Add MSI support

In reply to Phil Edworthy

---
v5:
- Return IRQ_NONE from MSI isr when there is no pending MSI
- Add additional interrupt bindings

---
 drivers/pci/host/pcie-rcar.c | 246 ++++++++++++++++++++++++++++++++++++++++++-
 drivers/pci/host/pcie-rcar.h |   5 +
 2 files changed, 250 insertions(+), 1 deletion(-)
drivers/pci/host/pcie-rcar.c +245 -1
index c22c896..280f370 100644
@@ -15,8 +15,11 @@
 #include <linux/clk.h>
 #include <linux/delay.h>
 #include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
+#include <linux/msi.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
 #include <linux/of_pci.h>
@@ -28,6 +31,8 @@
 
 #define DRV_NAME "rcar-pcie"
 
+#define INT_PCI_MSI_NR	32
+
 #define RCONF(x)	(PCICONF(0)+(x))
 #define RPMCAP(x)	(PMCAP(0)+(x))
 #define REXPCAP(x)	(EXPCAP(0)+(x))
@@ -40,6 +45,21 @@
 #define PCI_MAX_RESOURCES 4
 #define MAX_NR_INBOUND_MAPS 6
 
+struct rcar_msi {
+	DECLARE_BITMAP(used, INT_PCI_MSI_NR);
+	struct irq_domain *domain;
+	struct msi_chip chip;
+	unsigned long pages;
+	struct mutex lock;
+	int irq1;
+	int irq2;
+};
+
+static inline struct rcar_msi *to_rcar_msi(struct msi_chip *chip)
+{
+	return container_of(chip, struct rcar_msi, chip);
+}
+
 /* Structure representing the PCIe interface */
 struct rcar_pcie {
 	struct device		*dev;
@@ -48,6 +68,7 @@ struct rcar_pcie {
 	u8			root_bus_nr;
 	struct clk		*clk;
 	struct clk		*bus_clk;
+	struct			rcar_msi msi;
 };
 
 static inline struct rcar_pcie *sys_to_pcie(struct pci_sys_data *sys)
@@ -292,6 +313,15 @@ static int rcar_pcie_setup(int nr, struct pci_sys_data *sys)
 	return 1;
 }
 
+static void rcar_pcie_add_bus(struct pci_bus *bus)
+{
+	if (IS_ENABLED(CONFIG_PCI_MSI)) {
+		struct rcar_pcie *pcie = sys_to_pcie(bus->sysdata);
+
+		bus->msi = &pcie->msi.chip;
+	}
+}
+
 static void __init rcar_pcie_enable(struct rcar_pcie *pcie)
 {
 	struct platform_device *pdev = to_platform_device(pcie->dev);
@@ -301,6 +331,7 @@ static void __init rcar_pcie_enable(struct rcar_pcie *pcie)
 		.setup          = rcar_pcie_setup,
 		.map_irq        = of_irq_parse_and_map_pci,
 		.ops            = &rcar_pcie_ops,
+		.add_bus        = rcar_pcie_add_bus,
 	};
 
 	pci_common_init_dev(&pdev->dev, &hw);
@@ -408,6 +439,10 @@ static int __init rcar_pcie_hw_init(struct rcar_pcie *pcie)
 	/* Enable MAC data scrambling. */
 	rcar_rmw32(pcie, MACCTLR, SCRAMBLE_DISABLE, 0);
 
+	/* Enable MSI */
+	if (IS_ENABLED(CONFIG_PCI_MSI))
+		pci_write_reg(pcie, 0x101f0000, PCIEMSITXR);
+
 	/* Finish initialization - establish a PCI Express link */
 	pci_write_reg(pcie, CFINIT, PCIETCTLR);
 
@@ -461,11 +496,194 @@ static int __init rcar_pcie_hw_init_h1(struct rcar_pcie *pcie)
 	return -ETIMEDOUT;
 }
 
+static int rcar_msi_alloc(struct rcar_msi *chip)
+{
+	int msi;
+
+	mutex_lock(&chip->lock);
+
+	msi = find_first_zero_bit(chip->used, INT_PCI_MSI_NR);
+	if (msi < INT_PCI_MSI_NR)
+		set_bit(msi, chip->used);
+	else
+		msi = -ENOSPC;
+
+	mutex_unlock(&chip->lock);
+
+	return msi;
+}
+
+static void rcar_msi_free(struct rcar_msi *chip, unsigned long irq)
+{
+	struct device *dev = chip->chip.dev;
+
+	mutex_lock(&chip->lock);
+
+	if (!test_bit(irq, chip->used))
+		dev_err(dev, "trying to free unused MSI#%lu\n", irq);
+	else
+		clear_bit(irq, chip->used);
+
+	mutex_unlock(&chip->lock);
+}
+
+static irqreturn_t rcar_pcie_msi_irq(int irq, void *data)
+{
+	struct rcar_pcie *pcie = data;
+	struct rcar_msi *msi = &pcie->msi;
+	unsigned long reg;
+
+	reg = pci_read_reg(pcie, PCIEMSIFR);
+
+	/* MSI & INTx share an interrupt - we only handle MSI here */
+	if (!reg)
+		return IRQ_NONE;
+
+	while (reg) {
+		unsigned int index = find_first_bit(&reg, 32);
+		unsigned int irq;
+
+		/* clear the interrupt */
+		pci_write_reg(pcie, 1 << index, PCIEMSIFR);
+
+		irq = irq_find_mapping(msi->domain, index);
+		if (irq) {
+			if (test_bit(index, msi->used))
+				generic_handle_irq(irq);
+			else
+				dev_info(pcie->dev, "unhandled MSI\n");
+		} else {
+			/*
+			 * that's weird who triggered this?
+			 * just clear it
+			 */
+			dev_info(pcie->dev, "unexpected MSI\n");
+		}
+
+		/* see if there's any more pending in this vector */
+		reg = pci_read_reg(pcie, PCIEMSIFR);
+	}
+
+	return IRQ_HANDLED;
+}
+
+static int rcar_msi_setup_irq(struct msi_chip *chip, struct pci_dev *pdev,
+			       struct msi_desc *desc)
+{
+	struct rcar_msi *msi = to_rcar_msi(chip);
+	struct rcar_pcie *pcie = container_of(chip, struct rcar_pcie, msi.chip);
+	struct msi_msg msg;
+	unsigned int irq;
+	int hwirq;
+
+	hwirq = rcar_msi_alloc(msi);
+	if (hwirq < 0)
+		return hwirq;
+
+	irq = irq_create_mapping(msi->domain, hwirq);
+	if (!irq) {
+		rcar_msi_free(msi, hwirq);
+		return -EINVAL;
+	}
+
+	irq_set_msi_desc(irq, desc);
+
+	msg.address_lo = pci_read_reg(pcie, PCIEMSIALR) & ~MSIFE;
+	msg.address_hi = pci_read_reg(pcie, PCIEMSIAUR);
+	msg.data = hwirq;
+
+	write_msi_msg(irq, &msg);
+
+	return 0;
+}
+
+static void rcar_msi_teardown_irq(struct msi_chip *chip, unsigned int irq)
+{
+	struct rcar_msi *msi = to_rcar_msi(chip);
+	struct irq_data *d = irq_get_irq_data(irq);
+
+	rcar_msi_free(msi, d->hwirq);
+}
+
+static struct irq_chip rcar_msi_irq_chip = {
+	.name = "R-Car PCIe MSI",
+	.irq_enable = unmask_msi_irq,
+	.irq_disable = mask_msi_irq,
+	.irq_mask = mask_msi_irq,
+	.irq_unmask = unmask_msi_irq,
+};
+
+static int rcar_msi_map(struct irq_domain *domain, unsigned int irq,
+			 irq_hw_number_t hwirq)
+{
+	irq_set_chip_and_handler(irq, &rcar_msi_irq_chip, handle_simple_irq);
+	irq_set_chip_data(irq, domain->host_data);
+	set_irq_flags(irq, IRQF_VALID);
+
+	return 0;
+}
+
+static const struct irq_domain_ops msi_domain_ops = {
+	.map = rcar_msi_map,
+};
+
+static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
+{
+	struct platform_device *pdev = to_platform_device(pcie->dev);
+	struct rcar_msi *msi = &pcie->msi;
+	unsigned long base;
+	int err;
+
+	mutex_init(&msi->lock);
+
+	msi->chip.dev = pcie->dev;
+	msi->chip.setup_irq = rcar_msi_setup_irq;
+	msi->chip.teardown_irq = rcar_msi_teardown_irq;
+
+	msi->domain = irq_domain_add_linear(pcie->dev->of_node, INT_PCI_MSI_NR,
+					    &msi_domain_ops, &msi->chip);
+	if (!msi->domain) {
+		dev_err(&pdev->dev, "failed to create IRQ domain\n");
+		return -ENOMEM;
+	}
+
+	/* Two irqs are for MSI, but they are also used for non-MSI irqs */
+	err = devm_request_irq(&pdev->dev, msi->irq1, rcar_pcie_msi_irq,
+			       IRQF_SHARED, rcar_msi_irq_chip.name, pcie);
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to request IRQ: %d\n", err);
+		goto err;
+	}
+
+	err = devm_request_irq(&pdev->dev, msi->irq2, rcar_pcie_msi_irq,
+			       IRQF_SHARED, rcar_msi_irq_chip.name, pcie);
+	if (err < 0) {
+		dev_err(&pdev->dev, "failed to request IRQ: %d\n", err);
+		goto err;
+	}
+
+	/* setup MSI data target */
+	msi->pages = __get_free_pages(GFP_KERNEL, 0);
+	base = virt_to_phys((void *)msi->pages);
+
+	pci_write_reg(pcie, base | MSIFE, PCIEMSIALR);
+	pci_write_reg(pcie, 0, PCIEMSIAUR);
+
+	/* enable all MSI interrupts */
+	pci_write_reg(pcie, 0xffffffff, PCIEMSIIER);
+
+	return 0;
+
+err:
+	irq_domain_remove(msi->domain);
+	return err;
+}
+
 static int __init rcar_pcie_get_resources(struct platform_device *pdev,
 	struct rcar_pcie *pcie)
 {
 	struct resource res;
-	int err;
+	int err, i;
 
 	err = of_address_to_resource(pdev->dev.of_node, 0, &res);
 	if (err)
@@ -490,6 +708,22 @@ static int __init rcar_pcie_get_resources(struct platform_device *pdev,
 	if (err)
 		goto err_map_reg;
 
+	i = irq_of_parse_and_map(pdev->dev.of_node, 0);
+	if (i < 0) {
+		dev_err(pcie->dev, "cannot get platform resources for msi interrupt\n");
+		err = -ENOENT;
+		goto err_map_reg;
+	}
+	pcie->msi.irq1 = i;
+
+	i = irq_of_parse_and_map(pdev->dev.of_node, 1);
+	if (i < 0) {
+		dev_err(pcie->dev, "cannot get platform resources for msi interrupt\n");
+		err = -ENOENT;
+		goto err_map_reg;
+	}
+	pcie->msi.irq2 = i;
+
 	pcie->base = devm_ioremap_resource(&pdev->dev, &res);
 	if (IS_ERR(pcie->base)) {
 		err = PTR_ERR(pcie->base);
@@ -657,6 +891,16 @@ static int __init rcar_pcie_probe(struct platform_device *pdev)
 	 if (err)
 		return err;
 
+	if (IS_ENABLED(CONFIG_PCI_MSI)) {
+		err = rcar_pcie_enable_msi(pcie);
+		if (err < 0) {
+			dev_err(&pdev->dev,
+				"failed to enable MSI support: %d\n",
+				err);
+			return err;
+		}
+	}
+
 	of_id = of_match_device(rcar_pcie_of_match, pcie->dev);
 	if (!of_id || !of_id->data)
 		return -EINVAL;
drivers/pci/host/pcie-rcar.h +5 -0
index 3dc026b..4f0c678 100644
@@ -13,6 +13,7 @@
 #define PCIEMSR			0x000028
 #define PCIEINTXR		0x000400
 #define PCIEPHYSR		0x0007f0
+#define PCIEMSITXR		0x000840
 
 /* Transfer control */
 #define PCIETCTLR		0x02000
@@ -28,6 +29,10 @@
 #define PCIEPMSR		0x02034
 #define PCIEPMSCIER		0x02038
 #define PCIEMSIFR		0x02044
+#define PCIEMSIALR		0x02048
+#define  MSIFE			1
+#define PCIEMSIAUR		0x0204c
+#define PCIEMSIIER		0x02050
 
 /* root port address */
 #define PCIEPRAR(x)		(0x02080 + ((x) * 0x4))
Signature · 1 line
1.9.0
#3 lore raw

PATCH v5 2/9 PCI: host: rcar: Add MSI support

Quoted 5 lines · Phil Edworthy

---
v5:
- Return IRQ_NONE from MSI isr when there is no pending MSI
- Add additional interrupt bindings

drivers/pci/host/pcie-rcar.c static int __init rcar_pcie_hw_init_h1(struct rcar_pcie *pcie) · line 523

Quoted 9 lines
drivers/pci/host/pcie-rcar.c +9 -0
+
+static void rcar_msi_free(struct rcar_msi *chip, unsigned long irq)
+{
+	struct device *dev = chip->chip.dev;
+
+	mutex_lock(&chip->lock);
+
+	if (!test_bit(irq, chip->used))
+		dev_err(dev, "trying to free unused MSI#%lu\n", irq);

Does the upper level not check for this?

Quoted 30 lines
drivers/pci/host/pcie-rcar.c +28 -0
+	else
+		clear_bit(irq, chip->used);
+
+	mutex_unlock(&chip->lock);
 
 
+}
+
+static irqreturn_t rcar_pcie_msi_irq(int irq, void *data)
+{
+	struct rcar_pcie *pcie = data;
+	struct rcar_msi *msi = &pcie->msi;
+	unsigned long reg;
+
+	reg = pci_read_reg(pcie, PCIEMSIFR);
+
+	/* MSI & INTx share an interrupt - we only handle MSI here */
+	if (!reg)
+		return IRQ_NONE;
+
+	while (reg) {
+		unsigned int index = find_first_bit(&reg, 32);
+		unsigned int irq;
+
+		/* clear the interrupt */
+		pci_write_reg(pcie, 1 << index, PCIEMSIFR);
+
+		irq = irq_find_mapping(msi->domain, index);
+		if (irq) {
+			if (test_bit(index, msi->used))

drivers/pci/host/pcie-rcar.c static int __init rcar_pcie_hw_init_h1(struct rcar_pcie *pcie) · line 561

Quoted 10 lines
drivers/pci/host/pcie-rcar.c +10 -0
+				generic_handle_irq(irq);
+			else
+				dev_info(pcie->dev, "unhandled MSI\n");
+		} else {
+			/*
+			 * that's weird who triggered this?
+			 * just clear it
+			 */
+			dev_info(pcie->dev, "unexpected MSI\n");
+		}

You may want to change this to something that is either rate-limited or is say debug level so it does not spam the console if something does go wrong.

Also the comment could easily be made one line

	/* Weird, unknown MSI IRQ, just clear it */
Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#4 lore raw

PATCH v5 2/9 PCI: host: rcar: Add MSI support

Hi Ben,

Quoted 19 lines · Ben

Subject: Re: [PATCH v5 2/9] PCI: host: rcar: Add MSI support

Quoted 5 lines · Phil Edworthy

---
v5:
- Return IRQ_NONE from MSI isr when there is no pending MSI
- Add additional interrupt bindings

drivers/pci/host/pcie-rcar.c static int __init rcar_pcie_hw_init_h1(struct rcar_pcie *pcie) · line 523

Quoted 9 lines
drivers/pci/host/pcie-rcar.c +9 -0
+
+static void rcar_msi_free(struct rcar_msi *chip, unsigned long irq)
+{
+   struct device *dev = chip->chip.dev;
+
+   mutex_lock(&chip->lock);
+
+   if (!test_bit(irq, chip->used))
+      dev_err(dev, "trying to free unused MSI#%lu\n", irq);

Does the upper level not check for this?

Yes, the default_teardown_msi_irqs function checks for unused MSIs, so we don't really need to check here.

Quoted 36 lines
Quoted 36 lines
drivers/pci/host/pcie-rcar.c +34 -0
+   else
+      clear_bit(irq, chip->used);
+
+   mutex_unlock(&chip->lock);
 
 
+}
+
+static irqreturn_t rcar_pcie_msi_irq(int irq, void *data)
+{
+   struct rcar_pcie *pcie = data;
+   struct rcar_msi *msi = &pcie->msi;
+   unsigned long reg;
+
+   reg = pci_read_reg(pcie, PCIEMSIFR);
+
+   /* MSI & INTx share an interrupt - we only handle MSI here */
+   if (!reg)
+      return IRQ_NONE;
+
+   while (reg) {
+      unsigned int index = find_first_bit(&reg, 32);
+      unsigned int irq;
+
+      /* clear the interrupt */
+      pci_write_reg(pcie, 1 << index, PCIEMSIFR);
+
+      irq = irq_find_mapping(msi->domain, index);
+      if (irq) {
+         if (test_bit(index, msi->used))
+            generic_handle_irq(irq);
+         else
+            dev_info(pcie->dev, "unhandled MSI\n");
+      } else {
+         /*
+          * that's weird who triggered this?
Quoted 8 lines

drivers/pci/host/pcie-rcar.c static int __init rcar_pcie_hw_init_h1(struct rcar_pcie *pcie) · line 561

Quoted 4 lines
drivers/pci/host/pcie-rcar.c +4 -0
+          * just clear it
+          */
+         dev_info(pcie->dev, "unexpected MSI\n");
+      }

You may want to change this to something that is either rate-limited or is say debug level so it does not spam the console if something does go wrong.

I'll change that to debug level.

Quoted 2 lines

Also the comment could easily be made one line
/* Weird, unknown MSI IRQ, just clear it */

Sure!

Thanks
Phil

#5 lore raw

PATCH v5 3/9 ARM: shmobile: r8a7790: Add PCIe clock device tree nodes

In reply to Phil Edworthy

This patch adds the device tree clock nodes for PCIe

---
 arch/arm/boot/dts/r8a7790.dtsi            | 7 ++++---
 include/dt-bindings/clock/r8a7790-clock.h | 1 +
 2 files changed, 5 insertions(+), 3 deletions(-)
arch/arm/boot/dts/r8a7790.dtsi +4 -3
index da69afc..df9ec61 100644
@@ -704,16 +704,17 @@
 			reg = <0 0xe615013c 0 4>, <0 0xe6150048 0 4>;
 			clocks = <&cp_clk>, <&mmc1_clk>, <&sd3_clk>, <&sd2_clk>,
 				 <&cpg_clocks R8A7790_CLK_SD1>, <&cpg_clocks R8A7790_CLK_SD0>,
-				 <&mmc0_clk>, <&rclk_clk>;
+				 <&mmc0_clk>, <&rclk_clk>, <&mp_clk>;
 			#clock-cells = <1>;
 			renesas,clock-indices = <
 				R8A7790_CLK_TPU0 R8A7790_CLK_MMCIF1 R8A7790_CLK_SDHI3
 				R8A7790_CLK_SDHI2 R8A7790_CLK_SDHI1 R8A7790_CLK_SDHI0
-				R8A7790_CLK_MMCIF0 R8A7790_CLK_CMT1
+				R8A7790_CLK_MMCIF0 R8A7790_CLK_CMT1 R8A7790_CLK_PCIE
 			>;
 			clock-output-names =
 				"tpu0", "mmcif1", "sdhi3", "sdhi2",
-				"sdhi1", "sdhi0", "mmcif0", "cmt1";
+				"sdhi1", "sdhi0", "mmcif0", "cmt1",
+				"pcie";
 		};
 		mstp5_clks: mstp5_clks at e6150144 {
 			compatible = "renesas,r8a7790-mstp-clocks", "renesas,cpg-mstp-clocks";
include/dt-bindings/clock/r8a7790-clock.h +1 -0
index 6548a5f..840dbc8 100644
@@ -57,6 +57,7 @@
 #define R8A7790_CLK_SDHI1		13
 #define R8A7790_CLK_SDHI0		14
 #define R8A7790_CLK_MMCIF0		15
+#define R8A7790_CLK_PCIE		19
 #define R8A7790_CLK_SSUSB		28
 #define R8A7790_CLK_CMT1		29
 #define R8A7790_CLK_USBDMAC0		30
Signature · 1 line
1.9.0
#6 lore raw

PATCH v5 4/9 ARM: shmobile: r8a7791: Add PCIe clock device tree nodes

In reply to Phil Edworthy

This patch adds the device tree clock nodes for PCIe

---
 arch/arm/boot/dts/r8a7791.dtsi            | 7 +++++--
 include/dt-bindings/clock/r8a7791-clock.h | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)
arch/arm/boot/dts/r8a7791.dtsi +5 -2
index 71bac2c..ccfba57 100644
@@ -717,14 +717,17 @@
 			compatible = "renesas,r8a7791-mstp-clocks", "renesas,cpg-mstp-clocks";
 			reg = <0 0xe615013c 0 4>, <0 0xe6150048 0 4>;
 			clocks = <&cp_clk>, <&sd2_clk>, <&sd1_clk>,
-				<&cpg_clocks R8A7791_CLK_SD0>, <&mmc0_clk>, <&rclk_clk>;
+				<&cpg_clocks R8A7791_CLK_SD0>, <&mmc0_clk>, <&rclk_clk>,
+				<&mp_clk>;
 			#clock-cells = <1>;
 			renesas,clock-indices = <
 				R8A7791_CLK_TPU0 R8A7791_CLK_SDHI2 R8A7791_CLK_SDHI1
 				R8A7791_CLK_SDHI0 R8A7791_CLK_MMCIF0 R8A7791_CLK_CMT1
+				R8A7791_CLK_PCIE
 			>;
 			clock-output-names =
-				"tpu0", "sdhi2", "sdhi1", "sdhi0", "mmcif0", "cmt1";
+				"tpu0", "sdhi2", "sdhi1", "sdhi0", "mmcif0", "cmt1",
+				"pcie";
 		};
 		mstp5_clks: mstp5_clks at e6150144 {
 			compatible = "renesas,r8a7791-mstp-clocks", "renesas,cpg-mstp-clocks";
include/dt-bindings/clock/r8a7791-clock.h +1 -0
index 30f82f2..d3e2cf5 100644
@@ -51,6 +51,7 @@
 #define R8A7791_CLK_SDHI1		12
 #define R8A7791_CLK_SDHI0		14
 #define R8A7791_CLK_MMCIF0		15
+#define R8A7791_CLK_PCIE		19
 #define R8A7791_CLK_SSUSB		28
 #define R8A7791_CLK_CMT1		29
 #define R8A7791_CLK_USBDMAC0		30
Signature · 1 line
1.9.0
#7 lore raw

PATCH v5 5/9 dt-bindings: pci: rcar pcie device tree bindings

In reply to Phil Edworthy

This patch adds the bindings for the R-Car PCIe driver. The driver resides under drivers/pci/host/pcie-rcar.c

---
v5:
- Add PCIe bus clock reference
- Add additional interrupt bindings
- Use dma-ranges property to specify inbound memory regions

---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 44 ++++++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/rcar-pci.txt
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +44 -0
new file mode 100644
index 0000000..61bf5ef
@@ -0,0 +1,44 @@
+* Renesas RCar PCIe interface
+
+Required properties:
+- compatible: should contain one of the following
+	"renesas,pcie-r8a7779", "renesas,pcie-r8a7790", "renesas,pcie-r8a7791"
+- reg: base addresses and lengths of the pcie controller.
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- device_type: set to "pci"
+- ranges: ranges for the PCI memory and I/O regions.
+- dma-ranges: ranges for the inbound memory regions.
+- interrupts: two interrupt sources for MSI interrupts, followed by interrupt
+	source for hardware related interrupts (e.g. link speed change).
+- #interrupt-cells: set to <1>
+- interrupt-map-mask and interrupt-map: standard PCI properties
+	to define the mapping of the PCIe interface to interrupt
+	numbers.
+- clocks: from common clock binding: handle to pci clock.
+- clock-names: from common clock binding: should be "pcie" and "pcie_bus".
+
+Example:
+
+SoC specific DT Entry:
+
+	pcie: pcie at fe000000 {
+		compatible = "renesas,pcie-r8a7791";
+		reg = <0 0xfe000000 0 0x80000>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000
+			  0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000
+			  0x02000000 0 0x30000000 0 0x30000000 0 0x08000000
+			  0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>;
+		dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000
+			      0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>;
+		interrupts = <0 116 4 0 117 4 0 118 4>;
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &gic 0 116 4>;
+		clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>;
+		clock-names = "pcie", "pcie_bus";
+		status = "disabled";
+	};
Signature · 1 line
1.9.0
#8 lore raw

PATCH v5 5/9 dt-bindings: pci: rcar pcie device tree bindings

Hello.

Quoted 20 lines · Phil Edworthy

This patch adds the bindings for the R-Car PCIe driver. The driver resides under drivers/pci/host/pcie-rcar.c

---
v5:
- Add PCIe bus clock reference
- Add additional interrupt bindings
- Use dma-ranges property to specify inbound memory regions

---
  Documentation/devicetree/bindings/pci/rcar-pci.txt | 44 ++++++++++++++++++++++
  1 file changed, 44 insertions(+)

create mode 100644 Documentation/devicetree/bindings/pci/rcar-pci.txt

Documentation/devicetree/bindings/pci/rcar-pci.txt new file +0 -0
new file mode 100644
index 0000000..61bf5ef

Documentation/devicetree/bindings/pci/rcar-pci.txt line 6

Quoted 6 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +6 -0
@@ -0,0 +1,44 @@
+* Renesas RCar PCIe interface
+
+Required properties:
+- compatible: should contain one of the following
+	"renesas,pcie-r8a7779", "renesas,pcie-r8a7790", "renesas,pcie-r8a7791"
+- reg: base addresses and lengths of the pcie controller.

Hmm, need "registers" at end. And why plural?

Documentation/devicetree/bindings/pci/rcar-pci.txt line 18

Quoted 12 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +12 -0
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- device_type: set to "pci"
+- ranges: ranges for the PCI memory and I/O regions.
+- dma-ranges: ranges for the inbound memory regions.
+- interrupts: two interrupt sources for MSI interrupts, followed by interrupt
+	source for hardware related interrupts (e.g. link speed change).
+- #interrupt-cells: set to <1>
+- interrupt-map-mask and interrupt-map: standard PCI properties
+	to define the mapping of the PCIe interface to interrupt
+	numbers.
+- clocks: from common clock binding: handle to pci clock.

s/handle/phandle/, s/pci/PCI/.
Actually, it's a clock specifier consisting not only of phandle but also
of clock #. Looking at your example, it's even a pair of clock specifiers.

Quoted 8 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +8 -0
+- clock-names: from common clock binding: should be "pcie" and "pcie_bus".
+
+Example:
+
+SoC specific DT Entry:
+
+	pcie: pcie@fe000000 {
+		compatible = "renesas,pcie-r8a7791";

Documentation/devicetree/bindings/pci/rcar-pci.txt line 36

Quoted 10 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +10 -0
+		reg = <0 0xfe000000 0 0x80000>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000
+			  0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000
+			  0x02000000 0 0x30000000 0 0x30000000 0 0x08000000
+			  0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>;
+		dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000
+			      0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>;

Hmm, this prop looks board-dependent...

Documentation/devicetree/bindings/pci/rcar-pci.txt line 44

Quoted 8 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +8 -0
+		interrupts = <0 116 4 0 117 4 0 118 4>;
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &gic 0 116 4>;
+		clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>;
+		clock-names = "pcie", "pcie_bus";
+		status = "disabled";
+	};

WBR, Sergei

#9 lore raw

PATCH v5 5/9 dt-bindings: pci: rcar pcie device tree bindings

Hi Sergei,

Quoted 1 line · Sergei

Subject: Re: [PATCH v5 5/9] dt-bindings: pci: rcar pcie device tree

bindings

Quoted 16 lines

Hello.

Quoted 11 lines · Phil Edworthy

This patch adds the bindings for the R-Car PCIe driver. The driver resides under drivers/pci/host/pcie-rcar.c

---
v5:
- Add PCIe bus clock reference
- Add additional interrupt bindings
- Use dma-ranges property to specify inbound memory regions

---
  Documentation/devicetree/bindings/pci/rcar-pci.txt | 44 

++++++++++++++++++++++

Quoted 2 lines
Quoted 2 lines
  1 file changed, 44 insertions(+)

create mode 100644

Documentation/devicetree/bindings/pci/rcar-pci.txt

Quoted 13 lines

Review

Quoted 2 lines
(quoted diff) renamed from Documentation/devicetree/bindings/pci/rcar-pci.txt +0 -0

Documentation/devicetree/bindings/pci/rcar-pci.txt

Documentation/devicetree/bindings/pci/rcar-pci.txt line 5

Quoted 10 lines

new file mode 100644
index 0000000..61bf5ef

Documentation/devicetree/bindings/pci/rcar-pci.txt new file +5 -0
@@ -0,0 +1,44 @@
+* Renesas RCar PCIe interface
+
+Required properties:
+- compatible: should contain one of the following
+   "renesas,pcie-r8a7779", "renesas,pcie-r8a7790", 

"renesas,pcie-r8a7791"

Quoted 3 lines

Documentation/devicetree/bindings/pci/rcar-pci.txt line 6

Quoted 1 line
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +1 -0
+- reg: base addresses and lengths of the pcie controller.

Hmm, need "registers" at end. And why plural?

Ok, & yes it should be singular.

Quoted 6 lines

Documentation/devicetree/bindings/pci/rcar-pci.txt

Quoted 6 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +6 -0
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- device_type: set to "pci"
+- ranges: ranges for the PCI memory and I/O regions.
+- dma-ranges: ranges for the inbound memory regions.
+- interrupts: two interrupt sources for MSI interrupts, followed by 

interrupt

Quoted 9 lines

Documentation/devicetree/bindings/pci/rcar-pci.txt line 18

Quoted 6 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +6 -0
+   source for hardware related interrupts (e.g. link speed change).
+- #interrupt-cells: set to <1>
+- interrupt-map-mask and interrupt-map: standard PCI properties
+   to define the mapping of the PCIe interface to interrupt
+   numbers.
+- clocks: from common clock binding: handle to pci clock.

s/handle/phandle/, s/pci/PCI/.
Actually, it's a clock specifier consisting not only of phandle but

also

Quoted 1 line

of clock #. Looking at your example, it's even a pair of clock

specifiers.
Right, and yes it's two clocks - I missed that when adding the PCI bus clock.

Quoted 1 line

Documentation/devicetree/bindings/pci/rcar-pci.txt line 19

Quoted 1 line
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +1 -0
+- clock-names: from common clock binding: should be "pcie" and 

"pcie_bus".

Quoted 11 lines
Quoted 11 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +11 -0
+
+Example:
+
+SoC specific DT Entry:
+
+   pcie: pcie at fe000000 {
+      compatible = "renesas,pcie-r8a7791";
+      reg = <0 0xfe000000 0 0x80000>;
+      #address-cells = <3>;
+      #size-cells = <2>;
+      device_type = "pci";
Quoted 8 lines

Documentation/devicetree/bindings/pci/rcar-pci.txt line 36

Quoted 6 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +6 -0
+      ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000
+           0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000
+           0x02000000 0 0x30000000 0 0x30000000 0 0x08000000
+           0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>;
+      dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000
+               0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>;

Hmm, this prop looks board-dependent...

Initially I thought that it would be board dependent and map the actual DDR available. However, I then considered that it is probably ok to map all possible DDR ranges that the device is capable of using. I'm ok with either approach though...

Quoted 11 lines

Documentation/devicetree/bindings/pci/rcar-pci.txt line 44

Quoted 8 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +8 -0
+      interrupts = <0 116 4 0 117 4 0 118 4>;
+      #interrupt-cells = <1>;
+      interrupt-map-mask = <0 0 0 0>;
+      interrupt-map = <0 0 0 0 &gic 0 116 4>;
+      clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>;
+      clock-names = "pcie", "pcie_bus";
+      status = "disabled";
+   };

WBR, Sergei

Thanks
Phil

#10 lore raw

PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790

In reply to Phil Edworthy

This patch adds the device tree nodes for R8A7790

---
v5:
- Renesas SoCs compatible string has peripheral before device name
- Add PCIe bus clock reference
- Add additional interrupt bindings
- Use dma-ranges property to specify inbound memory regions

---
 arch/arm/boot/dts/r8a7790-lager.dts | 10 ++++++++++
 arch/arm/boot/dts/r8a7790.dtsi      | 24 ++++++++++++++++++++++++
 2 files changed, 34 insertions(+)
arch/arm/boot/dts/r8a7790-lager.dts +10 -0
index a55c5f8..bbbcb63 100644
@@ -139,6 +139,16 @@
 		states = <3300000 1
 			  1800000 0>;
 	};
+
+	clocks {
+		/* External PCIe bus clock - not used */
+		pcie_bus_clk: pcie_bus_clk {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+			clock-output-names = "pcie_bus";
+		};
+	};
 };
 
 &extal_clk {
arch/arm/boot/dts/r8a7790.dtsi +24 -0
index df9ec61..dbcea57 100644
@@ -821,4 +821,28 @@
 		#size-cells = <0>;
 		status = "disabled";
 	};
+
+	pcie: pcie at fe000000 {
+		compatible = "renesas,pcie-r8a7790";
+		reg = <0 0xfe000000 0 0x80000>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000
+			  0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000
+			  0x02000000 0 0x30000000 0 0x30000000 0 0x08000000
+			  0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>;
+		/* Map all possible DDR as inbound ranges */
+		dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000
+			      0x43000000 1 0x80000000 1 0x80000000 0 0x80000000>;
+		interrupts = <0 116 IRQ_TYPE_LEVEL_HIGH
+			      0 117 IRQ_TYPE_LEVEL_HIGH
+			      0 118 IRQ_TYPE_LEVEL_HIGH>;
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &gic 0 116 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp3_clks R8A7790_CLK_PCIE>, <&pcie_bus_clk>;
+		clock-names = "pcie", "pcie_bus";
+		status = "disabled";
+	};
 };
Signature · 1 line
1.9.0
#11 lore raw

PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790

arch/arm/boot/dts/r8a7790.dtsi line 837

Quoted 3 lines · On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:
arch/arm/boot/dts/r8a7790.dtsi +3 -0
+               /* Map all possible DDR as inbound ranges */
+               dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000
+                             0x43000000 1 0x80000000 1 0x80000000 0 0x80000000>;

Typo: 0x43000000 should be 0x42000000 I guess.

Since you control the mapping, I wonder if you could also do this as

               dma-ranges = <0x42000000 0 0x00000000 0 0x40000000 0 0x80000000
                             0x43000000 0 0x80000000 1 0x80000000 0 0x80000000>;

i.e. map all the RAM into PCI bus addresses below the 32-bit boundary. This would be really nice from the perspective that now all PCI devices could access all of RAM without using an IOMMU or the relying on 64-bit master capability.

The downside of this is that you'd probably need a custom dma_map_ops wrapper.

Arnd

#12 lore raw

PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790

Hi Arnd,

Quoted 1 line · Arnd

Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes

for R8A7790

Quoted 4 lines · On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:

Review

Quoted 2 lines
(quoted diff) +2 -0
+               /* Map all possible DDR as inbound ranges */
+               dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 

0x80000000

Quoted 1 line
Quoted 1 line

+ 0x43000000 1 0x80000000 1 0x80000000 0

0x80000000>;

Quoted 2 lines

Typo: 0x43000000 should be 0x42000000 I guess.

I used 0x43000000 as this is a 64-bit type. The OF PCI range code currently treats both 32 and 64-bit types the same way, but I thought it would be good to set this in case we ever need to use it.

Quoted 3 lines

Since you control the mapping, I wonder if you could also do this as

               dma-ranges = <0x42000000 0 0x00000000 0 0x40000000 0 

0x80000000

Quoted 1 line
                             0x43000000 0 0x80000000 1 0x80000000 0 

0x80000000>;

Quoted 8 lines

i.e. map all the RAM into PCI bus addresses below the 32-bit boundary. This would be really nice from the perspective that now all PCI devices could access all of RAM without using an IOMMU or the relying on 64-bit master capability.

The downside of this is that you'd probably need a custom dma_map_ops wrapper.

Since the OF PCi range code treats both 32 and 64-bit types the same way, my PCIe driver only creates 64-bit mappings. In addition, the PCIe controller has to use a 64-bit mapping for anything over 2GiB. Based on this, I think it's sensible to leave the mappings as 1-to-1.

Thanks
Phil

#13 lore raw

PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790

Quoted 9 lines · On Wednesday 26 March 2014 09:55:04 Phil.Edworthy at renesas.com wrote:

Hi Arnd,

Quoted 1 line · Arnd

Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes

for R8A7790

Quoted 4 lines · On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:

Review

Quoted 2 lines
(quoted diff) +2 -0
+               /* Map all possible DDR as inbound ranges */
+               dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 
Quoted 8 lines

0x80000000

Quoted 1 line
Quoted 1 line

+ 0x43000000 1 0x80000000 1 0x80000000 0

0x80000000>;

Quoted 2 lines

Typo: 0x43000000 should be 0x42000000 I guess.

I used 0x43000000 as this is a 64-bit type. The OF PCI range code currently treats both 32 and 64-bit types the same way, but I thought it would be good to set this in case we ever need to use it.

Ah, I forgot about the space identifier. It looks correct then, but it seems a little strange to use a 32-bit identifier in one case and a 64-bit one in the other.

Quoted 12 lines
Quoted 3 lines

Since you control the mapping, I wonder if you could also do this as

               dma-ranges = <0x42000000 0 0x00000000 0 0x40000000 0 

0x80000000

Quoted 1 line
                             0x43000000 0 0x80000000 1 0x80000000 0 

0x80000000>;

Quoted 6 lines

i.e. map all the RAM into PCI bus addresses below the 32-bit boundary. This would be really nice from the perspective that now all PCI devices could access all of RAM without using an IOMMU or the relying on 64-bit master capability.

Quoted 6 lines
Quoted 2 lines

The downside of this is that you'd probably need a custom dma_map_ops wrapper.

Since the OF PCi range code treats both 32 and 64-bit types the same way, my PCIe driver only creates 64-bit mappings. In addition, the PCIe controller has to use a 64-bit mapping for anything over 2GiB. Based on this, I think it's sensible to leave the mappings as 1-to-1.

I'm not following, sorry. What is the hardware requirement in the controller?

Arnd

#14 lore raw

PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790

Hi Arnd,

Quoted 1 line · Arnd

Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes

for R8A7790

Quoted 6 lines · On Wednesday 26 March 2014 09:55:04 Phil.Edworthy at renesas.com wrote:
Quoted 4 lines

Hi Arnd,

Quoted 1 line · Arnd

Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree

nodes

Quoted 5 lines
Quoted 5 lines

for R8A7790

Quoted 4 lines · On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:
Quoted 2 lines
(quoted diff) +2 -0
+               /* Map all possible DDR as inbound ranges */
+               dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 

0

Quoted 2 lines
Quoted 2 lines

0x80000000

Quoted 1 line
Quoted 1 line

+ 0x43000000 1 0x80000000 1 0x80000000

0

Quoted 5 lines
Quoted 5 lines

0x80000000>;

Quoted 2 lines

Typo: 0x43000000 should be 0x42000000 I guess.

I used 0x43000000 as this is a 64-bit type. The OF PCI range code currently treats both 32 and 64-bit types the same way, but I thought

it

Quoted 5 lines
Quoted 1 line

would be good to set this in case we ever need to use it.

Ah, I forgot about the space identifier. It looks correct then, but it seems a little strange to use a 32-bit identifier in one case and a 64-bit one in the other.

If the OF PCI range code allowed the PCIe host driver to determine if it's a 32-bit mapping, we could use that and get a small performance improvement with PCIe throughput.

Quoted 8 lines
Quoted 8 lines
Quoted 3 lines

Since you control the mapping, I wonder if you could also do this as

               dma-ranges = <0x42000000 0 0x00000000 0 0x40000000 0 

0x80000000

Quoted 1 line
                             0x43000000 0 0x80000000 1 0x80000000 0 

0x80000000>;

Quoted 2 lines

i.e. map all the RAM into PCI bus addresses below the 32-bit

boundary.

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines

This would be really nice from the perspective that now all PCI devices could access all of RAM without using an IOMMU or the relying on 64-bit master capability.

The downside of this is that you'd probably need a custom

dma_map_ops

Quoted 2 lines
Quoted 2 lines
Quoted 1 line

wrapper.

Since the OF PCi range code treats both 32 and 64-bit types the same

way,

Quoted 2 lines
Quoted 2 lines

my PCIe driver only creates 64-bit mappings. In addition, the PCIe controller has to use a 64-bit mapping for anything over 2GiB. Based

on

Quoted 4 lines
Quoted 1 line

this, I think it's sensible to leave the mappings as 1-to-1.

I'm not following, sorry. What is the hardware requirement in the controller?

With this controller, you can only specify maps whose size are a power of two, and the size must be less than or equal to the cpu address alignment. Further, when the size is 4GiB, you have to use a 64-bit mapping. Thinking about it, the 4GiB case is not relevant to our discussion about 32-bit vs 64-bit mappings.

Still, my comment about the OF PCI range code treating both 32 and 64-bit types the same way means that PCIe host driver has to assume it's a 64-bit mapping.

Thanks
Phil

#15 lore raw

PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790

Quoted 27 lines · On Wednesday 26 March 2014 11:01:46 Phil.Edworthy at renesas.com wrote:
Quoted 1 line · Arnd

Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes

for R8A7790

Quoted 6 lines · On Wednesday 26 March 2014 09:55:04 Phil.Edworthy at renesas.com wrote:
Quoted 4 lines

Hi Arnd,

Quoted 1 line · Arnd

Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree

nodes

Quoted 5 lines
Quoted 5 lines

for R8A7790

Quoted 4 lines · On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:
Quoted 2 lines
(quoted diff) +2 -0
+               /* Map all possible DDR as inbound ranges */
+               dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 

0

Quoted 2 lines
Quoted 2 lines

0x80000000

Quoted 1 line
Quoted 1 line

+ 0x43000000 1 0x80000000 1 0x80000000

0

Quoted 5 lines
Quoted 5 lines

0x80000000>;

Quoted 2 lines

Typo: 0x43000000 should be 0x42000000 I guess.

I used 0x43000000 as this is a 64-bit type. The OF PCI range code currently treats both 32 and 64-bit types the same way, but I thought

it

Quoted 2 lines
Quoted 1 line

would be good to set this in case we ever need to use it.

Quoted 7 lines
Quoted 3 lines

Ah, I forgot about the space identifier. It looks correct then, but it seems a little strange to use a 32-bit identifier in one case and a 64-bit one in the other.

If the OF PCI range code allowed the PCIe host driver to determine if it's a 32-bit mapping, we could use that and get a small performance improvement with PCIe throughput.

I don't think it's supposed to care. Soem of the upper bits of the ranges only really make sense of PCI device registers, not for the top-level ranges property. The driver can however still look at the address itself to get that information.

Quoted 7 lines
Quoted 1 line
Quoted 1 line

Since the OF PCi range code treats both 32 and 64-bit types the same

way,

Quoted 2 lines
Quoted 2 lines

my PCIe driver only creates 64-bit mappings. In addition, the PCIe controller has to use a 64-bit mapping for anything over 2GiB. Based

on

Quoted 2 lines
Quoted 1 line

this, I think it's sensible to leave the mappings as 1-to-1.

Quoted 7 lines
Quoted 2 lines

I'm not following, sorry. What is the hardware requirement in the controller?

With this controller, you can only specify maps whose size are a power of two, and the size must be less than or equal to the cpu address alignment. Further, when the size is 4GiB, you have to use a 64-bit mapping. Thinking about it, the 4GiB case is not relevant to our discussion about 32-bit vs 64-bit mappings.

But the ranges you specified in the property don't actually fit in those
constraints: you have a range with size 0x8000000 and start 0x40000000, which you say can't be programmed into the hardware.

Quoted 3 lines

Still, my comment about the OF PCI range code treating both 32 and 64-bit types the same way means that PCIe host driver has to assume it's a 64-bit mapping.

I was thinking more of PCI devices than the host itself. If the host driver can verify that all mappings are in the first 4GB and cover all of RAM, we won't have to use an swiotlb for devices that don't support 64-bit DMA, which is a very significant performance difference.

Arnd

#16 lore raw

PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790

Hi Arnd,

Quoted 1 line · Arnd

Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes

for R8A7790

Quoted 4 lines · On Wednesday 26 March 2014 11:01:46 Phil.Edworthy at renesas.com wrote:
Quoted 2 lines
Quoted 1 line · Arnd

Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree

nodes

Quoted 5 lines
Quoted 5 lines

for R8A7790

Quoted 4 lines · On Wednesday 26 March 2014 09:55:04 Phil.Edworthy at renesas.com wrote:
Quoted 2 lines

Hi Arnd,

Quoted 8 lines
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line · Arnd

Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree

nodes

Quoted 5 lines
Quoted 5 lines

for R8A7790

Quoted 4 lines · On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:
Quoted 2 lines
(quoted diff) +2 -0
+               /* Map all possible DDR as inbound ranges */
+               dma-ranges = <0x42000000 0 0x40000000 0 

0x40000000

Quoted 3 lines
Quoted 3 lines

0

Quoted 2 lines
Quoted 2 lines

0x80000000

Quoted 1 line
Quoted 1 line

+ 0x43000000 1 0x80000000 1

0x80000000

Quoted 6 lines
Quoted 6 lines

0

Quoted 5 lines
Quoted 5 lines

0x80000000>;

Quoted 2 lines

Typo: 0x43000000 should be 0x42000000 I guess.

I used 0x43000000 as this is a 64-bit type. The OF PCI range code currently treats both 32 and 64-bit types the same way, but I

thought

Quoted 8 lines
Quoted 8 lines

it

Quoted 5 lines
Quoted 1 line

would be good to set this in case we ever need to use it.

Ah, I forgot about the space identifier. It looks correct then, but it seems a little strange to use a 32-bit identifier in one case and a 64-bit one in the other.

If the OF PCI range code allowed the PCIe host driver to determine if

it's

Quoted 4 lines
Quoted 2 lines

a 32-bit mapping, we could use that and get a small performance improvement with PCIe throughput.

I don't think it's supposed to care. Soem of the upper bits of the

ranges

Quoted 3 lines

only really make sense of PCI device registers, not for the top-level ranges property. The driver can however still look at the address itself to get that information.

Ah, yes that is a possibility.

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

Since the OF PCi range code treats both 32 and 64-bit types the

same

Quoted 4 lines
Quoted 4 lines

way,

Quoted 3 lines
Quoted 3 lines

my PCIe driver only creates 64-bit mappings. In addition, the PCIe

controller has to use a 64-bit mapping for anything over 2GiB.

Based

Quoted 6 lines
Quoted 6 lines

on

Quoted 4 lines
Quoted 1 line

this, I think it's sensible to leave the mappings as 1-to-1.

I'm not following, sorry. What is the hardware requirement in the controller?

With this controller, you can only specify maps whose size are a power

of

Quoted 1 line
Quoted 1 line

two, and the size must be less than or equal to the cpu address

alignment.

Quoted 1 line
Quoted 1 line

Further, when the size is 4GiB, you have to use a 64-bit mapping.

Thinking

Quoted 1 line
Quoted 1 line

about it, the 4GiB case is not relevant to our discussion about 32-bit

vs

Quoted 5 lines
Quoted 1 line

64-bit mappings.

But the ranges you specified in the property don't actually fit in those
constraints: you have a range with size 0x8000000 and start 0x40000000, which you say can't be programmed into the hardware.

Actually, the driver checks the dma-ranges against these constraints, and if necessary will create multiple mappings to fulfil the requested dma-ranges.

Quoted 1 line
Quoted 1 line

Still, my comment about the OF PCI range code treating both 32 and

64-bit

Quoted 1 line
Quoted 1 line

types the same way means that PCIe host driver has to assume it's a

64-bit

Quoted 4 lines
Quoted 1 line

mapping.

I was thinking more of PCI devices than the host itself. If the host driver can verify that all mappings are in the first 4GB and cover all

of

Quoted 1 line

RAM, we won't have to use an swiotlb for devices that don't support

64-bit

Quoted 1 line

DMA, which is a very significant performance difference.

Ok, I think I understand. However, all the other PCI host drivers just do 1-to-1 mapping between PCI and CPU addresses, right? Whilst it might be nice be able to support mapping CPU addresses > 4GiB to PCI addresses under 4GiB, can that be something to consider later on?

Thanks
Phil

#17 lore raw

PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790

Quoted 7 lines · On Wednesday 26 March 2014 11:34:41 Phil.Edworthy at renesas.com wrote:
Quoted 3 lines

But the ranges you specified in the property don't actually fit in those
constraints: you have a range with size 0x8000000 and start 0x40000000, which you say can't be programmed into the hardware.

Actually, the driver checks the dma-ranges against these constraints, and if necessary will create multiple mappings to fulfil the requested dma-ranges.

Ok, I didn't notice. My initial suggestion was to not put that logic into the driver but instead specify in the host bridge binding that each entry in the dma-ranges property has to meet the hardware constraints.

As long as you don't have too much complexity to detect this case, I'm fine with it either way.

Quoted 8 lines
Quoted 1 line
Quoted 1 line

Still, my comment about the OF PCI range code treating both 32 and

64-bit

Quoted 1 line
Quoted 1 line

types the same way means that PCIe host driver has to assume it's a

64-bit

Quoted 4 lines
Quoted 1 line

mapping.

I was thinking more of PCI devices than the host itself. If the host driver can verify that all mappings are in the first 4GB and cover all

Quoted 8 lines

of

Quoted 1 line

RAM, we won't have to use an swiotlb for devices that don't support

64-bit

Quoted 1 line

DMA, which is a very significant performance difference.

Ok, I think I understand. However, all the other PCI host drivers just do 1-to-1 mapping between PCI and CPU addresses, right? Whilst it might be nice be able to support mapping CPU addresses > 4GiB to PCI addresses under 4GiB, can that be something to consider later on?

Yes, fair enough. The current version is much simpler, so that's ok. Just keep it in mind if you run into performance problems. Also, note that we don't actually support swiotlb on arm32 yet, so your current code is broken for an PCI DMA master that is not 64-bit capable. We need swiotlb on arm32 anyway, and that will fix this problem, but adding the hack I described would also fix it.

Arnd

#18 lore raw

PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790

Hi Arnd,

Quoted 1 line · Arnd

Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes

for R8A7790

Quoted 3 lines · On Wednesday 26 March 2014 11:34:41 Phil.Edworthy at renesas.com wrote:
Quoted 1 line
Quoted 1 line

But the ranges you specified in the property don't actually fit in

those

Quoted 1 line
Quoted 1 line
Quoted 1 line

constraints: you have a range with size 0x8000000 and start

0x40000000,

Quoted 3 lines
Quoted 3 lines
Quoted 1 line

which you say can't be programmed into the hardware.

Actually, the driver checks the dma-ranges against these constraints,

and

Quoted 9 lines
Quoted 2 lines

if necessary will create multiple mappings to fulfil the requested dma-ranges.

Ok, I didn't notice. My initial suggestion was to not put that logic into the driver but instead specify in the host bridge binding that each entry in the dma-ranges property has to meet the hardware constraints.

As long as you don't have too much complexity to detect this case, I'm fine with it either way.

Ok, good!

Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line

Still, my comment about the OF PCI range code treating both 32 and

64-bit

Quoted 1 line
Quoted 1 line

types the same way means that PCIe host driver has to assume it's

a

Quoted 5 lines
Quoted 5 lines

64-bit

Quoted 4 lines
Quoted 1 line

mapping.

I was thinking more of PCI devices than the host itself. If the host driver can verify that all mappings are in the first 4GB and cover

all

Quoted 5 lines
Quoted 5 lines

of

Quoted 1 line

RAM, we won't have to use an swiotlb for devices that don't support

64-bit

Quoted 1 line

DMA, which is a very significant performance difference.

Ok, I think I understand. However, all the other PCI host drivers just

do

Quoted 1 line
Quoted 1 line

1-to-1 mapping between PCI and CPU addresses, right? Whilst it might

be

Quoted 9 lines
Quoted 2 lines

nice be able to support mapping CPU addresses > 4GiB to PCI addresses under 4GiB, can that be something to consider later on?

Yes, fair enough. The current version is much simpler, so that's ok. Just keep it in mind if you run into performance problems. Also, note that we don't actually support swiotlb on arm32 yet, so your current code is broken for an PCI DMA master that is not 64-bit capable. We need swiotlb on arm32 anyway, and that will fix this problem, but adding the hack I described would also fix it.

Ok, thanks for all your comments!

Phil

#19 lore raw

PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790

In reply to Phil Edworthy
Quoted 3 lines · Phil Edworthy

This patch adds the device tree nodes for R8A7790

Please split this patch into two patches.

1. A patch that updates arch/arm/boot/dts/r8a7790.dtsi

I suggest calling that patch
"ARM: shmobile: r8a7791: Add PCI device nodes"

2. A patch that updates arch/arm/boot/dts/r8a7790-lager.dts

I suggest calling that patch
"ARM: shmobile: lager: Add PCI device nodes"

Quoted 73 lines

---
v5:
- Renesas SoCs compatible string has peripheral before device name
- Add PCIe bus clock reference
- Add additional interrupt bindings
- Use dma-ranges property to specify inbound memory regions

---
 arch/arm/boot/dts/r8a7790-lager.dts | 10 ++++++++++
 arch/arm/boot/dts/r8a7790.dtsi      | 24 ++++++++++++++++++++++++
 2 files changed, 34 insertions(+)
arch/arm/boot/dts/r8a7790-lager.dts +10 -0
index a55c5f8..bbbcb63 100644
@@ -139,6 +139,16 @@
 		states = <3300000 1
 			  1800000 0>;
 	};
+
+	clocks {
+		/* External PCIe bus clock - not used */
+		pcie_bus_clk: pcie_bus_clk {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <0>;
+			clock-output-names = "pcie_bus";
+		};
+	};
 };
 
 &extal_clk {
arch/arm/boot/dts/r8a7790.dtsi +24 -0
index df9ec61..dbcea57 100644
@@ -821,4 +821,28 @@
 		#size-cells = <0>;
 		status = "disabled";
 	};
+
+	pcie: pcie at fe000000 {
+		compatible = "renesas,pcie-r8a7790";
+		reg = <0 0xfe000000 0 0x80000>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000
+			  0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000
+			  0x02000000 0 0x30000000 0 0x30000000 0 0x08000000
+			  0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>;
+		/* Map all possible DDR as inbound ranges */
+		dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000
+			      0x43000000 1 0x80000000 1 0x80000000 0 0x80000000>;
+		interrupts = <0 116 IRQ_TYPE_LEVEL_HIGH
+			      0 117 IRQ_TYPE_LEVEL_HIGH
+			      0 118 IRQ_TYPE_LEVEL_HIGH>;
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &gic 0 116 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp3_clks R8A7790_CLK_PCIE>, <&pcie_bus_clk>;
+		clock-names = "pcie", "pcie_bus";
+		status = "disabled";
+	};
 };
Signature · 6 lines
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#20 lore raw

PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790

Hi Simon,

Quoted 1 line · Simon

Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes

for R8A7790

Quoted 10 lines · Phil Edworthy
Quoted 3 lines

This patch adds the device tree nodes for R8A7790

Please split this patch into two patches.

1. A patch that updates arch/arm/boot/dts/r8a7790.dtsi

Quoted 8 lines

I suggest calling that patch
"ARM: shmobile: r8a7791: Add PCI device nodes"

2. A patch that updates arch/arm/boot/dts/r8a7790-lager.dts

I suggest calling that patch
"ARM: shmobile: lager: Add PCI device nodes"

For this, and your other comments, will do!

Thanks
Phil

#21 lore raw

PATCH v5 7/9 ARM: shmobile: Add PCIe device tree nodes for R8A7791 Koelsch board

In reply to Phil Edworthy

This patch adds the device tree nodes for the R8A7791 Koelsch board

---
v5:
- Renesas SoCs compatible string has peripheral before device name
- Add PCIe bus clock reference
- Add additional interrupt bindings
- Use dma-ranges property to specify inbound memory regions

---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 14 ++++++++++++++
 arch/arm/boot/dts/r8a7791.dtsi        | 24 ++++++++++++++++++++++++
 2 files changed, 38 insertions(+)
arch/arm/boot/dts/r8a7791-koelsch.dts +14 -0
index ee23b7b..3130a0c 100644
@@ -204,6 +204,16 @@
 		states = <3300000 1
 			  1800000 0>;
 	};
+
+	clocks {
+		/* External PCIe bus clock */
+		pcie_bus_clk: pcie_bus_clk {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <100000000>;
+			clock-output-names = "pcie_bus";
+		};
+	};
 };
 
 &extal_clk {
@@ -382,3 +392,7 @@
 		spi-cpha;
 	};
 };
+
+&pcie {
+	status = "okay";
+};
arch/arm/boot/dts/r8a7791.dtsi +24 -0
index ccfba57..7a4be4c 100644
@@ -836,4 +836,28 @@
 		#size-cells = <0>;
 		status = "disabled";
 	};
+
+	pcie: pcie at fe000000 {
+		compatible = "renesas,pcie-r8a7791";
+		reg = <0 0xfe000000 0 0x80000>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000
+			  0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000
+			  0x02000000 0 0x30000000 0 0x30000000 0 0x08000000
+			  0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>;
+		/* Map all possible DDR as inbound ranges */
+		dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000
+			      0x43000000 2 0x00000000 2 0x00000000 1 0x00000000>;
+		interrupts = <0 116 IRQ_TYPE_LEVEL_HIGH
+			      0 117 IRQ_TYPE_LEVEL_HIGH
+			      0 118 IRQ_TYPE_LEVEL_HIGH>;
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &gic 0 116 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>;
+		clock-names = "pcie", "pcie_bus";
+		status = "disabled";
+	};
 };
Signature · 1 line
1.9.0
#22 lore raw

PATCH v5 7/9 ARM: shmobile: Add PCIe device tree nodes for R8A7791 Koelsch board

Quoted 1 line · Phil Edworthy

This patch adds the device tree nodes for the R8A7791 Koelsch board

Please split this patch into two patches.

1. A patch that updates arch/arm/boot/dts/r8a7791.dtsi

I suggest calling that patch
"ARM: shmobile: r8a7791: Add PCI device nodes"

2. A patch that updates arch/arm/boot/dts/r8a7791-koelsch.dts

I suggest calling that patch
"ARM: shmobile: koelsch: Add PCI device nodes"

Quoted 82 lines

---
v5:
- Renesas SoCs compatible string has peripheral before device name
- Add PCIe bus clock reference
- Add additional interrupt bindings
- Use dma-ranges property to specify inbound memory regions

---
 arch/arm/boot/dts/r8a7791-koelsch.dts | 14 ++++++++++++++
 arch/arm/boot/dts/r8a7791.dtsi        | 24 ++++++++++++++++++++++++
 2 files changed, 38 insertions(+)
arch/arm/boot/dts/r8a7791-koelsch.dts +14 -0
index ee23b7b..3130a0c 100644
@@ -204,6 +204,16 @@
 		states = <3300000 1
 			  1800000 0>;
 	};
+
+	clocks {
+		/* External PCIe bus clock */
+		pcie_bus_clk: pcie_bus_clk {
+			compatible = "fixed-clock";
+			#clock-cells = <0>;
+			clock-frequency = <100000000>;
+			clock-output-names = "pcie_bus";
+		};
+	};
 };
 
 &extal_clk {
@@ -382,3 +392,7 @@
 		spi-cpha;
 	};
 };
+
+&pcie {
+	status = "okay";
+};
arch/arm/boot/dts/r8a7791.dtsi +24 -0
index ccfba57..7a4be4c 100644
@@ -836,4 +836,28 @@
 		#size-cells = <0>;
 		status = "disabled";
 	};
+
+	pcie: pcie at fe000000 {
+		compatible = "renesas,pcie-r8a7791";
+		reg = <0 0xfe000000 0 0x80000>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";
+		ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000
+			  0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000
+			  0x02000000 0 0x30000000 0 0x30000000 0 0x08000000
+			  0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>;
+		/* Map all possible DDR as inbound ranges */
+		dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000
+			      0x43000000 2 0x00000000 2 0x00000000 1 0x00000000>;
+		interrupts = <0 116 IRQ_TYPE_LEVEL_HIGH
+			      0 117 IRQ_TYPE_LEVEL_HIGH
+			      0 118 IRQ_TYPE_LEVEL_HIGH>;
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &gic 0 116 IRQ_TYPE_LEVEL_HIGH>;
+		clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>;
+		clock-names = "pcie", "pcie_bus";
+		status = "disabled";
+	};
 };
Signature · 6 lines
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#23 lore raw

PATCH v5 8/9 ARM: koelsch: Add PCIe to defconfig

In reply to Phil Edworthy
---
 arch/arm/configs/koelsch_defconfig | 3 +++
 1 file changed, 3 insertions(+)
arch/arm/configs/koelsch_defconfig +3 -0
index 86faab5..ec14547 100644
@@ -15,6 +15,9 @@ CONFIG_MACH_KOELSCH=y
 CONFIG_CPU_BPREDICT_DISABLE=y
 CONFIG_PL310_ERRATA_588369=y
 CONFIG_ARM_ERRATA_754322=y
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_PCI_RCAR_GEN2_PCIE=y
 CONFIG_SMP=y
 CONFIG_SCHED_MC=y
 CONFIG_NR_CPUS=8
Signature · 1 line
1.9.0
#24 lore raw

PATCH v5 8/9 ARM: koelsch: Add PCIe to defconfig

Please update the subject of this patch to:

ARM: shmobile: koelsch: Add PCIe to defconfig

Quoted 27 lines · Phil Edworthy
---
 arch/arm/configs/koelsch_defconfig | 3 +++
 1 file changed, 3 insertions(+)
arch/arm/configs/koelsch_defconfig +3 -0
index 86faab5..ec14547 100644
@@ -15,6 +15,9 @@ CONFIG_MACH_KOELSCH=y
 CONFIG_CPU_BPREDICT_DISABLE=y
 CONFIG_PL310_ERRATA_588369=y
 CONFIG_ARM_ERRATA_754322=y
+CONFIG_PCI=y
+CONFIG_PCI_MSI=y
+CONFIG_PCI_RCAR_GEN2_PCIE=y
 CONFIG_SMP=y
 CONFIG_SCHED_MC=y
 CONFIG_NR_CPUS=8
Signature · 6 lines
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#25 lore raw

PATCH v5 9/9 ARM: koelsch: Add HAVE_ARM_ARCH_TIMER to defconfig

In reply to Phil Edworthy

This is fixes a boot problem when the R-Car PCIe driver is enabled.

---
 arch/arm/configs/koelsch_defconfig | 1 +
 1 file changed, 1 insertion(+)
arch/arm/configs/koelsch_defconfig +1 -0
index ec14547..67666b6 100644
@@ -15,6 +15,7 @@ CONFIG_MACH_KOELSCH=y
 CONFIG_CPU_BPREDICT_DISABLE=y
 CONFIG_PL310_ERRATA_588369=y
 CONFIG_ARM_ERRATA_754322=y
+CONFIG_HAVE_ARM_ARCH_TIMER=y
 CONFIG_PCI=y
 CONFIG_PCI_MSI=y
 CONFIG_PCI_RCAR_GEN2_PCIE=y
Signature · 1 line
1.9.0
#26 lore raw

PATCH v5 9/9 ARM: koelsch: Add HAVE_ARM_ARCH_TIMER to defconfig

Please update the subject of this patch to:

ARM: shmobile: koelsch: Add HAVE_ARM_ARCH_TIMER to defconfig

Quoted 27 lines · Phil Edworthy

This is fixes a boot problem when the R-Car PCIe driver is enabled.

---
 arch/arm/configs/koelsch_defconfig | 1 +
 1 file changed, 1 insertion(+)
arch/arm/configs/koelsch_defconfig +1 -0
index ec14547..67666b6 100644
@@ -15,6 +15,7 @@ CONFIG_MACH_KOELSCH=y
 CONFIG_CPU_BPREDICT_DISABLE=y
 CONFIG_PL310_ERRATA_588369=y
 CONFIG_ARM_ERRATA_754322=y
+CONFIG_HAVE_ARM_ARCH_TIMER=y
 CONFIG_PCI=y
 CONFIG_PCI_MSI=y
 CONFIG_PCI_RCAR_GEN2_PCIE=y
Signature · 6 lines
1.9.0

--
To unsubscribe from this list: send the line "unsubscribe linux-sh" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
maintainer
#27 lore raw

PATCH v5 9/9 ARM: koelsch: Add HAVE_ARM_ARCH_TIMER to defconfig

In reply to Phil Edworthy
Quoted 12 lines · Phil Edworthy

This is fixes a boot problem when the R-Car PCIe driver is enabled.

---
 arch/arm/configs/koelsch_defconfig | 1 +
 1 file changed, 1 insertion(+)
arch/arm/configs/koelsch_defconfig +0 -0
index ec14547..67666b6 100644

arch/arm/configs/koelsch_defconfig CONFIG_MACH_KOELSCH=y · line 18

Quoted 4 lines
arch/arm/configs/koelsch_defconfig +1 -0
@@ -15,6 +15,7 @@ CONFIG_MACH_KOELSCH=y
 CONFIG_CPU_BPREDICT_DISABLE=y
 CONFIG_PL310_ERRATA_588369=y
 CONFIG_ARM_ERRATA_754322=y
+CONFIG_HAVE_ARM_ARCH_TIMER=y

Hi Phil,

Thanks for your patches! I appreciate that you send out a whole series with broken out patches, that makes it easier to see what is going on.

However, regarding this particular patch I'm not so sure if your fix is correct. The issue is most likely there, no doubt about that, but this "select" does not match well with how we currently handle timers for the rest of the SoCs in mach-shmobile. We for instance want to be able to boot with CMT only.

So here's a gentle "NAK" on this particular patch. I think this shows that either deferred probing or a different init ordering is needed somehow.

Thanks,

/ magnus

#28 lore raw

PATCH v5 9/9 ARM: koelsch: Add HAVE_ARM_ARCH_TIMER to defconfig

Hi Magnus,

Quoted 1 line · Magnus

Subject: Re: [PATCH v5 9/9] ARM: koelsch: Add HAVE_ARM_ARCH_TIMER to

defconfig

Quoted 11 lines

Review

Quoted 8 lines · Phil Edworthy

This is fixes a boot problem when the R-Car PCIe driver is enabled.

---
 arch/arm/configs/koelsch_defconfig | 1 +
 1 file changed, 1 insertion(+)
(quoted diff) +0 -0

b/arch/arm/configs/koelsch_defconfig

Quoted 20 lines

arch/arm/configs/koelsch_defconfig CONFIG_MACH_KOELSCH=y · line 18

Quoted 8 lines

index ec14547..67666b6 100644

arch/arm/configs/koelsch_defconfig +1 -0
@@ -15,6 +15,7 @@ CONFIG_MACH_KOELSCH=y
 CONFIG_CPU_BPREDICT_DISABLE=y
 CONFIG_PL310_ERRATA_588369=y
 CONFIG_ARM_ERRATA_754322=y
+CONFIG_HAVE_ARM_ARCH_TIMER=y

Hi Phil,

Thanks for your patches! I appreciate that you send out a whole series with broken out patches, that makes it easier to see what is going on.

However, regarding this particular patch I'm not so sure if your fix is correct. The issue is most likely there, no doubt about that, but this "select" does not match well with how we currently handle timers for the rest of the SoCs in mach-shmobile. We for instance want to be able to boot with CMT only.

Quoted 3 lines

So here's a gentle "NAK" on this particular patch. I think this shows that either deferred probing or a different init ordering is needed somehow.

When reading your comments, I realised that since I changed the driver to use module_platform_driver instead of subsys_initcall, we no longer need this patch.

Thanks
Phil