Skip to contentSkip to conversation

R-Car Gen2 PCIe host driver

PATCH Superseded Phil Edworthy 7 participants 38 messages Mar 21, 2014 – Mar 24, 2014 2 messages not in the archive

Subsystems (8)

v4 of 8 Superseded Latest is v8 →

lore
Share & tools
lore
#0 lore raw

v4 cover R-Car Gen2 PCIe host driver

This is version 4 of a PCIe Host driver for the R-Car Gen2 devices, i.e. R-Car H2 (r8a7790) and R-Car M2 (r8a7791). This version includes DT support, and includes a patch to add MSI.

v4:
- Patch 0001 changed to correct use of runtime PM

Thanks
Phil

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 |  40 +
 arch/arm/boot/dts/r8a7790.dtsi                     |  26 +-
 arch/arm/boot/dts/r8a7791-koelsch.dts              |   4 +
 arch/arm/boot/dts/r8a7791.dtsi                     |  26 +-
 arch/arm/configs/koelsch_defconfig                 |   4 +
 drivers/pci/host/Kconfig                           |   6 +
 drivers/pci/host/Makefile                          |   1 +
 drivers/pci/host/pcie-rcar.c                       | 831 +++++++++++++++++++++
 drivers/pci/host/pcie-rcar.h                       |  87 +++
 include/dt-bindings/clock/r8a7790-clock.h          |   1 +
 include/dt-bindings/clock/r8a7791-clock.h          |   1 +
 11 files changed, 1022 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 v4 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.

---
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 | 601 +++++++++++++++++++++++++++++++++++++++++++
 drivers/pci/host/pcie-rcar.h |  82 ++++++
 4 files changed, 690 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 +601 -0

601 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 v4 1/9 PCI: host: rcar: Add Renesas R-Car PCIe driver

drivers/pci/host/pcie-rcar.c line 53

Quoted 7 lines · On Friday 21 March 2014 10:32:40 Phil Edworthy wrote:
drivers/pci/host/pcie-rcar.c new file +7 -0
+static const struct of_device_id rcar_pcie_of_match[] = {
+	{ .compatible = "renesas,r8a7779-pcie", .data = (void *)RCAR_H1 },
+	{ .compatible = "renesas,r8a7790-pcie", .data = (void *)RCAR_GENERIC },
+	{ .compatible = "renesas,r8a7791-pcie", .data = (void *)RCAR_GENERIC },
+	{},
+};
+MODULE_DEVICE_TABLE(of, rcar_pcie_of_match);

The only difference between RCAR_H1 and RCAR_GENERIC seems to be the use of the rcar_pcie_phy_init_rcar_h1 vs rcar_pcie_hw_init functions. I think this would be expressed in a nicer way doing

static const struct of_device_id rcar_pcie_of_match[] = {
	{ .compatible = "renesas,r8a7779-pcie", .data =  rcar_pcie_phy_init_rcar_h1},
	{ .compatible = "renesas,r8a7790-pcie", .data =  rcar_pcie_hw_init},
	{ .compatible = "renesas,r8a7791-pcie", .data =  rcar_pcie_hw_init},
	{},
};

If you need other differences in the future, you can extend this to use a pointer to a struct containing the init function pointer.

Quoted 19 lines
drivers/pci/host/pcie-rcar.c new file +19 -0
+static int rcar_pcie_setup_window(int win, struct resource *res,
+					struct rcar_pcie *pcie)
+{
+	/* Setup PCIe address space mappings for each resource */
+	resource_size_t size;
+	u32 mask;
+
+	pci_write_reg(pcie, 0x00000000, PCIEPTCTLR(win));
+
+	/*
+	 * The PAMR mask is calculated in units of 128Bytes, which
+	 * keeps things pretty simple.
+	 */
+	size = resource_size(res);
+	mask = (roundup_pow_of_two(size) / SZ_128) - 1;
+	pci_write_reg(pcie, mask << 7, PCIEPAMR(win));
+
+	pci_write_reg(pcie, upper_32_bits(res->start), PCIEPARH(win));
+	pci_write_reg(pcie, lower_32_bits(res->start), PCIEPARL(win));

drivers/pci/host/pcie-rcar.c line 280

Quoted 10 lines
drivers/pci/host/pcie-rcar.c new file +10 -0
+
+	/* First resource is for IO */
+	mask = PAR_ENABLE;
+	if (res->flags & IORESOURCE_IO)
+		mask |= IO_SPACE;
+
+	pci_write_reg(pcie, mask, PCIEPTCTLR(win));
+
+	return 0;
+}

Would it be possible to have this done in the boot loader so the kernel doesn't need to be bothered with it?

Quoted 20 lines
drivers/pci/host/pcie-rcar.c new file +20 -0
+
+static int rcar_pcie_setup(int nr, struct pci_sys_data *sys)
+{
+	struct rcar_pcie *pcie = sys_to_pcie(sys);
+	struct resource *res;
+	int i, ret;
+
+	pcie->root_bus_nr = sys->busnr;
+
+	/* Setup PCI resources */
+	for (i = 0; i < PCI_MAX_RESOURCES; i++) {
+
+		res = &pcie->res[i];
+		if (!res->flags)
+			continue;
+
+		if (res->flags & IORESOURCE_IO) {
+			/* Setup IO mapped memory accesses */
+			ret = pci_ioremap_io(0, res->start);
+			if (ret)

drivers/pci/host/pcie-rcar.c line 310

Quoted 10 lines
drivers/pci/host/pcie-rcar.c new file +10 -0
+				return 1;
+
+			/* Correct addresses for remapped IO */
+			res->end = res->end - res->start;
+			res->start = 0;
+		}
+
+		rcar_pcie_setup_window(i, res, pcie);
+		pci_add_resource(&sys->resources, res);
+	}

This assumes that the start of the I/O window is always at bus address 0, and that you have only one PCI host in the system. Are both guaranteed through the hardware design?

drivers/pci/host/pcie-rcar.c line 326

Quoted 12 lines
drivers/pci/host/pcie-rcar.c new file +12 -0
+static void __init rcar_pcie_enable(struct rcar_pcie *pcie)
+{
+	struct platform_device *pdev = to_platform_device(pcie->dev);
+	struct hw_pci hw;
+
+	memset(&hw, 0, sizeof(hw));
+
+	hw.nr_controllers = 1;
+	hw.private_data   = (void **)&pcie;
+	hw.setup          = rcar_pcie_setup,
+	hw.map_irq        = of_irq_parse_and_map_pci,
+	hw.ops		  = &rcar_pcie_ops,

You can write this slightly nicer doing

	struct hw_pci hw = {
		.nr_controllers = 1,
		.private_data = (void **)&pcie,
		...
	};

drivers/pci/host/pcie-rcar.c line 384

Quoted 12 lines
drivers/pci/host/pcie-rcar.c new file +12 -0
+static int __init rcar_pcie_phy_init_rcar_h1(struct rcar_pcie *pcie)
+{
+	unsigned int timeout = 10;
+
+	/* Initialize the phy */
+	phy_write_reg(pcie, 0, 0x42, 0x1, 0x0EC34191);
+	phy_write_reg(pcie, 1, 0x42, 0x1, 0x0EC34180);
+	phy_write_reg(pcie, 0, 0x43, 0x1, 0x00210188);
+	phy_write_reg(pcie, 1, 0x43, 0x1, 0x00210188);
+	phy_write_reg(pcie, 0, 0x44, 0x1, 0x015C0014);
+	phy_write_reg(pcie, 1, 0x44, 0x1, 0x015C0014);
+	phy_write_reg(pcie, 1, 0x4C, 0x1, 0x786174A0);

Have you considered moving this into a separate PHY driver? There are probably good reasons either way, so I'm not asking you to do it, just to think about what would be best for this driver.

It seems that you already have two different implementations that only vary in how they access the PHY, so moving that into a separate driver would keep the knowledge out of the host driver. OTOH, the PHY registers look like they are part of the pci host itself.

drivers/pci/host/pcie-rcar.c line 443

Quoted 12 lines
drivers/pci/host/pcie-rcar.c new file +12 -0
+	/*
+	 * For target transfers, setup a single 64-bit 4GB mapping at address
+	 * 0. The hardware can only map memory that starts on a power of two
+	 * boundary, and size is power of 2, so best to ignore it.
+	 */
+	pci_write_reg(pcie, 0, PCIEPRAR(0));
+	pci_write_reg(pcie, 0, PCIELAR(0));
+	pci_write_reg(pcie, 0xfffffff0UL | LAM_PREFETCH |
+		LAM_64BIT | LAR_ENABLE, PCIELAMR(0));
+	pci_write_reg(pcie, 0, PCIELAR(1));
+	pci_write_reg(pcie, 0, PCIEPRAR(1));
+	pci_write_reg(pcie, 0, PCIELAMR(1));

Is this the only reasonable configuration? If not, you might want to do the same thing as the x-gene PCI driver that is not yet merged, and parse the 'dma-ranges' property to determine what the mapping on a particular machine should be.

Most importantly, why don't you use a mapping that includes RAM beyond the first 4GB?

drivers/pci/host/pcie-rcar.c line 597

Quoted 5 lines
drivers/pci/host/pcie-rcar.c new file +5 -0
+static int __init pcie_init(void)
+{
+	return platform_driver_probe(&rcar_pcie_driver, rcar_pcie_probe);
+}
+subsys_initcall(pcie_init);

Why so early?

Overall, this driver looks pretty good.

Arnd

#3 lore raw

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

Hi Arnd,

Thanks for the review.

Quoted 3 lines

From: Arnd Bergmann <[email protected]>
To: linux-arm-kernel at lists.infradead.org,
Cc: Phil Edworthy <[email protected]>,

linux-pci at vger.kernel.org,

Quoted 7 lines

linux-sh at vger.kernel.org, Magnus Damm <[email protected]>, Valentine

Barshak <[email protected]>, Simon Horman <[email protected]>, Bjorn Helgaas <[email protected]>, Ben Dooks <[email protected]>
Date: 21/03/2014 11:04
Subject: Re: [PATCH v4 1/9] PCI: host: rcar: Add Renesas R-Car PCIe

driver

Quoted 5 lines · On Friday 21 March 2014 10:32:40 Phil Edworthy wrote:

drivers/pci/host/pcie-rcar.c

Quoted 3 lines
drivers/pci/host/pcie-rcar.c new file +3 -0
+static const struct of_device_id rcar_pcie_of_match[] = {
+   { .compatible = "renesas,r8a7779-pcie", .data = (void *)RCAR_H1 },
+   { .compatible = "renesas,r8a7790-pcie", .data = (void 

*)RCAR_GENERIC },

Quoted 1 line
Quoted 1 line

+ { .compatible = "renesas,r8a7791-pcie", .data = (void

*)RCAR_GENERIC },

Quoted 10 lines

drivers/pci/host/pcie-rcar.c line 53

Quoted 3 lines
drivers/pci/host/pcie-rcar.c new file +3 -0
+   {},
+};
+MODULE_DEVICE_TABLE(of, rcar_pcie_of_match);

The only difference between RCAR_H1 and RCAR_GENERIC seems to be the use of the rcar_pcie_phy_init_rcar_h1 vs rcar_pcie_hw_init functions. I think this would be expressed in a nicer way doing

static const struct of_device_id rcar_pcie_of_match[] = {
   { .compatible = "renesas,r8a7779-pcie", .data = 

rcar_pcie_phy_init_rcar_h1},

Quoted 7 lines
   { .compatible = "renesas,r8a7790-pcie", .data =  rcar_pcie_hw_init},
   { .compatible = "renesas,r8a7791-pcie", .data =  rcar_pcie_hw_init},
   {},
};

If you need other differences in the future, you can extend this to use a pointer to a struct containing the init function pointer.

Ok, I understand what you mean, though the rcar_pcie_phy_init_rcar_h1 function is an extra call for r8a7779 devices to setup the PHY, not an alternative to rcar_pcie_hw_init.

Quoted 24 lines
Quoted 24 lines
drivers/pci/host/pcie-rcar.c new file +24 -0
+static int rcar_pcie_setup_window(int win, struct resource *res,
+               struct rcar_pcie *pcie)
+{
+   /* Setup PCIe address space mappings for each resource */
+   resource_size_t size;
+   u32 mask;
+
+   pci_write_reg(pcie, 0x00000000, PCIEPTCTLR(win));
+
+   /*
+    * The PAMR mask is calculated in units of 128Bytes, which
+    * keeps things pretty simple.
+    */
+   size = resource_size(res);
+   mask = (roundup_pow_of_two(size) / SZ_128) - 1;
+   pci_write_reg(pcie, mask << 7, PCIEPAMR(win));
+
+   pci_write_reg(pcie, upper_32_bits(res->start), PCIEPARH(win));
+   pci_write_reg(pcie, lower_32_bits(res->start), PCIEPARL(win));
+
+   /* First resource is for IO */
+   mask = PAR_ENABLE;
+   if (res->flags & IORESOURCE_IO)
+      mask |= IO_SPACE;
Quoted 8 lines

drivers/pci/host/pcie-rcar.c line 280

Quoted 5 lines
drivers/pci/host/pcie-rcar.c new file +5 -0
+
+   pci_write_reg(pcie, mask, PCIEPTCTLR(win));
+
+   return 0;
+}

Would it be possible to have this done in the boot loader so the kernel doesn't need to be bothered with it?

Hmm, I don't like the idea of depending on settings made by a bootloader, when it may be that a different bootloader could be used, or no bootloader at all.

Quoted 26 lines
Quoted 26 lines
drivers/pci/host/pcie-rcar.c new file +26 -0
+
+static int rcar_pcie_setup(int nr, struct pci_sys_data *sys)
+{
+   struct rcar_pcie *pcie = sys_to_pcie(sys);
+   struct resource *res;
+   int i, ret;
+
+   pcie->root_bus_nr = sys->busnr;
+
+   /* Setup PCI resources */
+   for (i = 0; i < PCI_MAX_RESOURCES; i++) {
+
+      res = &pcie->res[i];
+      if (!res->flags)
+         continue;
+
+      if (res->flags & IORESOURCE_IO) {
+         /* Setup IO mapped memory accesses */
+         ret = pci_ioremap_io(0, res->start);
+         if (ret)
+            return 1;
+
+         /* Correct addresses for remapped IO */
+         res->end = res->end - res->start;
+         res->start = 0;
+      }
Quoted 8 lines

drivers/pci/host/pcie-rcar.c line 310

Quoted 4 lines
drivers/pci/host/pcie-rcar.c new file +4 -0
+
+      rcar_pcie_setup_window(i, res, pcie);
+      pci_add_resource(&sys->resources, res);
+   }

This assumes that the start of the I/O window is always at bus address 0, and that you have only one PCI host in the system. Are both guaranteed through the hardware design?

The I/O window can be anywhere I believe, so I guess I should pull the actual bus address from the DT.
All existing devices I have seen, have a single PCIe host.

Quoted 15 lines

drivers/pci/host/pcie-rcar.c line 326

Quoted 12 lines
drivers/pci/host/pcie-rcar.c new file +12 -0
+static void __init rcar_pcie_enable(struct rcar_pcie *pcie)
+{
+   struct platform_device *pdev = to_platform_device(pcie->dev);
+   struct hw_pci hw;
+
+   memset(&hw, 0, sizeof(hw));
+
+   hw.nr_controllers = 1;
+   hw.private_data   = (void **)&pcie;
+   hw.setup          = rcar_pcie_setup,
+   hw.map_irq        = of_irq_parse_and_map_pci,
+   hw.ops        = &rcar_pcie_ops,

You can write this slightly nicer doing

Quoted 5 lines
   struct hw_pci hw = {
      .nr_controllers = 1,
      .private_data = (void **)&pcie,
      ...
   };

Ok, will do.

Quoted 17 lines

drivers/pci/host/pcie-rcar.c line 384

Quoted 12 lines
drivers/pci/host/pcie-rcar.c new file +12 -0
+static int __init rcar_pcie_phy_init_rcar_h1(struct rcar_pcie *pcie)
+{
+   unsigned int timeout = 10;
+
+   /* Initialize the phy */
+   phy_write_reg(pcie, 0, 0x42, 0x1, 0x0EC34191);
+   phy_write_reg(pcie, 1, 0x42, 0x1, 0x0EC34180);
+   phy_write_reg(pcie, 0, 0x43, 0x1, 0x00210188);
+   phy_write_reg(pcie, 1, 0x43, 0x1, 0x00210188);
+   phy_write_reg(pcie, 0, 0x44, 0x1, 0x015C0014);
+   phy_write_reg(pcie, 1, 0x44, 0x1, 0x015C0014);
+   phy_write_reg(pcie, 1, 0x4C, 0x1, 0x786174A0);

Have you considered moving this into a separate PHY driver? There are probably good reasons either way, so I'm not asking you to do it, just to think about what would be best for this driver.

Quoted 5 lines

It seems that you already have two different implementations that only vary in how they access the PHY, so moving that into a separate driver would keep the knowledge out of the host driver. OTOH, the PHY registers look like they are part of the pci host itself.

The PHYs are separate entities, but access to them is via the PCIe controller's registers. In the general case, there shouldn't be any PHY setup to do, it's just the R-Car H1 devices that needs a little tweaking.

Quoted 2 lines

Review

Quoted 2 lines
(quoted diff) +2 -0
+   /*
+    * For target transfers, setup a single 64-bit 4GB mapping at 

address

Quoted 1 line
Quoted 1 line

+ * 0. The hardware can only map memory that starts on a power of

two

Quoted 10 lines

drivers/pci/host/pcie-rcar.c line 443

Quoted 9 lines
drivers/pci/host/pcie-rcar.c new file +9 -0
+    * boundary, and size is power of 2, so best to ignore it.
+    */
+   pci_write_reg(pcie, 0, PCIEPRAR(0));
+   pci_write_reg(pcie, 0, PCIELAR(0));
+   pci_write_reg(pcie, 0xfffffff0UL | LAM_PREFETCH |
+      LAM_64BIT | LAR_ENABLE, PCIELAMR(0));
+   pci_write_reg(pcie, 0, PCIELAR(1));
+   pci_write_reg(pcie, 0, PCIEPRAR(1));
+   pci_write_reg(pcie, 0, PCIELAMR(1));
Quoted 4 lines

Is this the only reasonable configuration? If not, you might want to do the same thing as the x-gene PCI driver that is not yet merged, and parse the 'dma-ranges' property to determine what the mapping on a particular machine should be.

Based on the restrictions of these registers, it seemed like a sensible approach to open up the whole 32-bit address space. I'll have a look at the x-gene patches to see if that would be better.

Quoted 2 lines

Most importantly, why don't you use a mapping that includes RAM beyond the first 4GB?

I had intended to send a patch later on to open this up to the first 12GB. Limitations of this block of hardware mean that we can do at most three 4GB regions. The first 12GB would be ok for LPAE on existing devices as all DDR is mapped within that range, but obviously not ideal.

Quoted 7 lines

drivers/pci/host/pcie-rcar.c line 597

Quoted 5 lines
drivers/pci/host/pcie-rcar.c new file +5 -0
+static int __init pcie_init(void)
+{
+   return platform_driver_probe(&rcar_pcie_driver, rcar_pcie_probe);
+}
+subsys_initcall(pcie_init);

Why so early?

Good catch, copied from another PCIe driver!

Quoted 3 lines

Overall, this driver looks pretty good.

Arnd

Thanks
Phil

#4 lore raw

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

Quoted 5 lines · Phil.Edworthy at renesas.com

Hi Arnd,

Thanks for the review.

Quoted 8 lines
Quoted 7 lines

drivers/pci/host/pcie-rcar.c line 597

Quoted 5 lines
drivers/pci/host/pcie-rcar.c new file +5 -0
+static int __init pcie_init(void)
+{
+   return platform_driver_probe(&rcar_pcie_driver, rcar_pcie_probe);
+}
+subsys_initcall(pcie_init);

Why so early?

Good catch, copied from another PCIe driver!

I think you can change it to use module_driver() instead of the init_call.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#5 lore raw

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

In reply to Phil.Edworthy at renesas.com
Quoted 9 lines · On Friday 21 March 2014 13:59:35 Phil.Edworthy at renesas.com wrote:
Quoted 3 lines

From: Arnd Bergmann <[email protected]>

static const struct of_device_id rcar_pcie_of_match[] = {
   { .compatible = "renesas,r8a7779-pcie", .data = 

rcar_pcie_phy_init_rcar_h1},

Quoted 5 lines
   { .compatible = "renesas,r8a7790-pcie", .data =  rcar_pcie_hw_init},
   { .compatible = "renesas,r8a7791-pcie", .data =  rcar_pcie_hw_init},
   {},
};
Quoted 6 lines
Quoted 2 lines

If you need other differences in the future, you can extend this to use a pointer to a struct containing the init function pointer.

Ok, I understand what you mean, though the rcar_pcie_phy_init_rcar_h1 function is an extra call for r8a7779 devices to setup the PHY, not an alternative to rcar_pcie_hw_init.

I assumed that would be trivial to change, by calling rcar_pcie_hw_init at the end of rcar_pcie_phy_init_rcar_h1 rather than the other way round.

Quoted 33 lines
Quoted 24 lines
Quoted 24 lines
drivers/pci/host/pcie-rcar.c new file +24 -0
+static int rcar_pcie_setup_window(int win, struct resource *res,
+               struct rcar_pcie *pcie)
+{
+   /* Setup PCIe address space mappings for each resource */
+   resource_size_t size;
+   u32 mask;
+
+   pci_write_reg(pcie, 0x00000000, PCIEPTCTLR(win));
+
+   /*
+    * The PAMR mask is calculated in units of 128Bytes, which
+    * keeps things pretty simple.
+    */
+   size = resource_size(res);
+   mask = (roundup_pow_of_two(size) / SZ_128) - 1;
+   pci_write_reg(pcie, mask << 7, PCIEPAMR(win));
+
+   pci_write_reg(pcie, upper_32_bits(res->start), PCIEPARH(win));
+   pci_write_reg(pcie, lower_32_bits(res->start), PCIEPARL(win));
+
+   /* First resource is for IO */
+   mask = PAR_ENABLE;
+   if (res->flags & IORESOURCE_IO)
+      mask |= IO_SPACE;
Quoted 8 lines

drivers/pci/host/pcie-rcar.c line 280

Quoted 5 lines
drivers/pci/host/pcie-rcar.c new file +5 -0
+
+   pci_write_reg(pcie, mask, PCIEPTCTLR(win));
+
+   return 0;
+}

Would it be possible to have this done in the boot loader so the kernel doesn't need to be bothered with it?

Quoted 3 lines

Hmm, I don't like the idea of depending on settings made by a bootloader, when it may be that a different bootloader could be used, or no bootloader at all.

If you need to support the case without a boot loader, that would be a good reason to leave the code in.

Otherwise, I think it's better to mandate early that the boot loader sets up a lot of the basic stuff. As long as nobody has a kernel that does the same setup, you also won't see any boot loaders that get it wrong, because they never work. It's also easy enough to add back if you later have to support a broken boot loader.

Quoted 34 lines
Quoted 25 lines
Quoted 25 lines
drivers/pci/host/pcie-rcar.c new file +25 -0
+static int rcar_pcie_setup(int nr, struct pci_sys_data *sys)
+{
+   struct rcar_pcie *pcie = sys_to_pcie(sys);
+   struct resource *res;
+   int i, ret;
+
+   pcie->root_bus_nr = sys->busnr;
+
+   /* Setup PCI resources */
+   for (i = 0; i < PCI_MAX_RESOURCES; i++) {
+
+      res = &pcie->res[i];
+      if (!res->flags)
+         continue;
+
+      if (res->flags & IORESOURCE_IO) {
+         /* Setup IO mapped memory accesses */
+         ret = pci_ioremap_io(0, res->start);
+         if (ret)
+            return 1;
+
+         /* Correct addresses for remapped IO */
+         res->end = res->end - res->start;
+         res->start = 0;
+      }
Quoted 8 lines

drivers/pci/host/pcie-rcar.c line 310

Quoted 4 lines
drivers/pci/host/pcie-rcar.c new file +4 -0
+
+      rcar_pcie_setup_window(i, res, pcie);
+      pci_add_resource(&sys->resources, res);
+   }

This assumes that the start of the I/O window is always at bus address 0, and that you have only one PCI host in the system. Are both guaranteed through the hardware design?

Quoted 2 lines

The I/O window can be anywhere I believe, so I guess I should pull the actual bus address from the DT.

Ok. There is actually work on the way to simplify this a lot so you don't have to do it in the driver, but it will probably take a little more time, especially since Will Deacon is on an extended vacation at the moment and he was driving things.

Quoted 1 line

All existing devices I have seen, have a single PCIe host.

The seems less obvious to rely on though, it's quite common for newer hardware to have multiple blocks of whatever the first generation has only one of ;-)

Quoted 23 lines
Quoted 17 lines

drivers/pci/host/pcie-rcar.c line 384

Quoted 12 lines
drivers/pci/host/pcie-rcar.c new file +12 -0
+static int __init rcar_pcie_phy_init_rcar_h1(struct rcar_pcie *pcie)
+{
+   unsigned int timeout = 10;
+
+   /* Initialize the phy */
+   phy_write_reg(pcie, 0, 0x42, 0x1, 0x0EC34191);
+   phy_write_reg(pcie, 1, 0x42, 0x1, 0x0EC34180);
+   phy_write_reg(pcie, 0, 0x43, 0x1, 0x00210188);
+   phy_write_reg(pcie, 1, 0x43, 0x1, 0x00210188);
+   phy_write_reg(pcie, 0, 0x44, 0x1, 0x015C0014);
+   phy_write_reg(pcie, 1, 0x44, 0x1, 0x015C0014);
+   phy_write_reg(pcie, 1, 0x4C, 0x1, 0x786174A0);

Have you considered moving this into a separate PHY driver? There are probably good reasons either way, so I'm not asking you to do it, just to think about what would be best for this driver.

Quoted 5 lines

It seems that you already have two different implementations that only vary in how they access the PHY, so moving that into a separate driver would keep the knowledge out of the host driver. OTOH, the PHY registers look like they are part of the pci host itself.

Quoted 3 lines

The PHYs are separate entities, but access to them is via the PCIe controller's registers. In the general case, there shouldn't be any PHY setup to do, it's just the R-Car H1 devices that needs a little tweaking.

Ok.

Quoted 6 lines
Quoted 2 lines

Most importantly, why don't you use a mapping that includes RAM beyond the first 4GB?

I had intended to send a patch later on to open this up to the first 12GB. Limitations of this block of hardware mean that we can do at most three 4GB regions. The first 12GB would be ok for LPAE on existing devices as all DDR is mapped within that range, but obviously not ideal.

Ok, in this case it sounds like you should definitely use the dma-ranges property, since it's possibly that board designers put their ram in funny places. You probably want to have a dma-ranges property with three 4GB entries then and document the size limitation in the pci host binding, rather than a single entry spanning all of RAM.

Arnd

#6 lore raw

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

Quoted 13 lines · Arnd Bergmann
Quoted 12 lines · On Friday 21 March 2014 13:59:35 Phil.Edworthy at renesas.com wrote:
Quoted 3 lines

From: Arnd Bergmann <[email protected]>

static const struct of_device_id rcar_pcie_of_match[] = {
   { .compatible = "renesas,r8a7779-pcie", .data =

rcar_pcie_phy_init_rcar_h1},

Quoted 7 lines
   { .compatible = "renesas,r8a7790-pcie", .data =  rcar_pcie_hw_init},
   { .compatible = "renesas,r8a7791-pcie", .data =  rcar_pcie_hw_init},
   {},
};

If you need other differences in the future, you can extend this to use a pointer to a struct containing the init function pointer.

Quoted 6 lines
Quoted 3 lines

Ok, I understand what you mean, though the rcar_pcie_phy_init_rcar_h1 function is an extra call for r8a7779 devices to setup the PHY, not an alternative to rcar_pcie_hw_init.

I assumed that would be trivial to change, by calling rcar_pcie_hw_init at the end of rcar_pcie_phy_init_rcar_h1 rather than the other way round.

And this would allow to propagate the error code from rcar_pcie_phy_init_rcar_h1(), as currently rcar_pcie_hw_init() ignores it, and returns void.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

#7 lore raw

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

In reply to Phil Edworthy
---
 drivers/pci/host/pcie-rcar.c | 232 ++++++++++++++++++++++++++++++++++++++++++-
 drivers/pci/host/pcie-rcar.h |   5 +
 2 files changed, 236 insertions(+), 1 deletion(-)
drivers/pci/host/pcie-rcar.c +231 -1
index 16670e5..cbbcd77 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>
@@ -33,6 +36,8 @@ enum chip_id {
 	RCAR_H1,
 };
 
+#define INT_PCI_MSI_NR	32
+
 #define RCONF(x)	(PCICONF(0)+(x))
 #define RPMCAP(x)	(PMCAP(0)+(x))
 #define REXPCAP(x)	(EXPCAP(0)+(x))
@@ -52,6 +57,20 @@ static const struct of_device_id rcar_pcie_of_match[] = {
 };
 MODULE_DEVICE_TABLE(of, rcar_pcie_of_match);
 
+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 irq;
+};
+
+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;
@@ -61,6 +80,7 @@ struct rcar_pcie {
 	enum chip_id		chip;
 	u8			root_bus_nr;
 	struct clk		*clk;
+	struct			rcar_msi msi;
 };
 
 static inline struct rcar_pcie *sys_to_pcie(struct pci_sys_data *sys)
@@ -312,6 +332,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);
@@ -324,6 +353,7 @@ static void __init rcar_pcie_enable(struct rcar_pcie *pcie)
 	hw.setup          = rcar_pcie_setup,
 	hw.map_irq        = of_irq_parse_and_map_pci,
 	hw.ops		  = &rcar_pcie_ops,
+	hw.add_bus	  = rcar_pcie_add_bus;
 
 	pci_common_init_dev(&pdev->dev, &hw);
 }
@@ -478,6 +508,10 @@ static void __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);
 
@@ -495,11 +529,190 @@ static void __init rcar_pcie_hw_init(struct rcar_pcie *pcie)
 	wmb();
 }
 
+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);
+
+	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->irq, 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->irq+1, 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)
@@ -511,6 +724,13 @@ static int __init rcar_pcie_get_resources(struct platform_device *pdev,
 		return PTR_ERR(pcie->clk);
 	}
 
+	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");
+		return -ENOENT;
+	}
+	pcie->msi.irq = i;
+
 	clk_prepare_enable(pcie->clk);
 
 	pcie->base = devm_ioremap_resource(&pdev->dev, &res);
@@ -566,6 +786,16 @@ static int __init rcar_pcie_probe(struct platform_device *pdev)
 			break;
 	}
 
+	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;
+		}
+	}
+
 	rcar_pcie_hw_init(pcie);
 
 	if (!pcie->haslink) {
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
#8 lore raw

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

Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:

Quoted 10 lines
---
 drivers/pci/host/pcie-rcar.c | 232 ++++++++++++++++++++++++++++++++++++++++++-
 drivers/pci/host/pcie-rcar.h |   5 +
 2 files changed, 236 insertions(+), 1 deletion(-)
drivers/pci/host/pcie-rcar.c +0 -0
index 16670e5..cbbcd77 100644

[...]

Quoted 37 lines
drivers/pci/host/pcie-rcar.c +37 -0
+
+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);
+
+	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;
+}
+
Quoted 1 line

From your DT binding it seems you have only one interrupt from the PCIe

core, shared between the MSI irqs and the PCI legacy interrupts. This means this handler may get called without an MSI irq pending, so this function really should have a path where it's returning IRQ_NONE.

Regards,
Lucas

Signature · 4 lines
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
#9 lore raw

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

Hi Lucas,

Thanks for the review.

Quoted 6 lines · Lucas

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

Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:

Quoted 3 lines
---
 drivers/pci/host/pcie-rcar.c | 232 

++++++++++++++++++++++++++++++++++++++++++-

Quoted 4 lines

Review

Quoted 4 lines
 drivers/pci/host/pcie-rcar.h |   5 +
 2 files changed, 236 insertions(+), 1 deletion(-)
(quoted diff) +0 -0

b/drivers/pci/host/pcie-rcar.c

Quoted 37 lines
Quoted 3 lines

index 16670e5..cbbcd77 100644

drivers/pci/host/pcie-rcar.c +0 -0

[...]

Quoted 33 lines
drivers/pci/host/pcie-rcar.c +33 -0
+
+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);
+
+   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);
+   }
Quoted 8 lines

drivers/pci/host/pcie-rcar.c static void __init rcar_pcie_hw_init(struct rcar_pcie *pcie) · line 598

Quoted 4 lines
drivers/pci/host/pcie-rcar.c +4 -0
+
+   return IRQ_HANDLED;
+}
+

From your DT binding it seems you have only one interrupt from the PCIe core, shared between the MSI irqs and the PCI legacy interrupts. This means this handler may get called without an MSI irq pending, so this function really should have a path where it's returning IRQ_NONE.

Ah, yes you are right... though actually there are two interrupts, one has some MSI and INTx, the other has the rest of the MSIs.

Quoted 6 lines

Regards,
Lucas

Signature · 2 lines
Pengutronix e.K.                           | Lucas Stach |
Industrial Linux Solutions                 | http://www.pengutronix.de/ 

|

Quoted 1 line

Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076

|

Quoted 1 line

Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555

|

Quoted 1 line

Thanks
Phil

#10 lore raw

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

Am Freitag, den 21.03.2014, 14:15 +0000 schrieb
Phil.Edworthy at renesas.com:

Quoted 62 lines

Hi Lucas,

Thanks for the review.

Quoted 6 lines · Lucas

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

Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:

Quoted 3 lines
---
 drivers/pci/host/pcie-rcar.c | 232 

++++++++++++++++++++++++++++++++++++++++++-

Quoted 4 lines

Review

Quoted 4 lines
 drivers/pci/host/pcie-rcar.h |   5 +
 2 files changed, 236 insertions(+), 1 deletion(-)
(quoted diff) +0 -0

b/drivers/pci/host/pcie-rcar.c

Quoted 37 lines
Quoted 3 lines

index 16670e5..cbbcd77 100644

drivers/pci/host/pcie-rcar.c +0 -0

[...]

Quoted 33 lines
drivers/pci/host/pcie-rcar.c +33 -0
+
+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);
+
+   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);
+   }
Quoted 8 lines

drivers/pci/host/pcie-rcar.c static void __init rcar_pcie_hw_init(struct rcar_pcie *pcie) · line 598

Quoted 4 lines
drivers/pci/host/pcie-rcar.c +4 -0
+
+   return IRQ_HANDLED;
+}
+

From your DT binding it seems you have only one interrupt from the PCIe core, shared between the MSI irqs and the PCI legacy interrupts. This means this handler may get called without an MSI irq pending, so this function really should have a path where it's returning IRQ_NONE.

Quoted 3 lines

Ah, yes you are right... though actually there are two interrupts, one has some MSI and INTx, the other has the rest of the MSIs.

This isn't reflected in the DT binding. If you already know that there may be more than a single interrupt for MSI, please push this into the binding by using named interrupts. Even if your driver doesn't support it yet, additional functionality can always be added later, but the DT should be a stable ABI describing your hardware.

So if you already know your hardware has more than one interrupt, please put it in the binding, to avoid churn later on.

Regards,
Lucas

Signature · 4 lines
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
#11 lore raw

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

Hi Lucas,

Quoted 63 lines · Lucas

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

Am Freitag, den 21.03.2014, 14:15 +0000 schrieb
Phil.Edworthy at renesas.com:

Quoted 59 lines

Hi Lucas,

Thanks for the review.

Quoted 6 lines · Lucas

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

Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:

Quoted 3 lines
---
 drivers/pci/host/pcie-rcar.c | 232 

++++++++++++++++++++++++++++++++++++++++++-

Quoted 4 lines

Review

Quoted 4 lines
 drivers/pci/host/pcie-rcar.h |   5 +
 2 files changed, 236 insertions(+), 1 deletion(-)
(quoted diff) +0 -0

b/drivers/pci/host/pcie-rcar.c

Quoted 42 lines
Quoted 3 lines

index 16670e5..cbbcd77 100644

drivers/pci/host/pcie-rcar.c +0 -0

[...]

Quoted 27 lines
drivers/pci/host/pcie-rcar.c +27 -0
+
+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);
+
+   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
+          */

drivers/pci/host/pcie-rcar.c static void __init rcar_pcie_hw_init(struct rcar_pcie *pcie) · line 598

Quoted 10 lines
drivers/pci/host/pcie-rcar.c +10 -0
+         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;
+}
+

From your DT binding it seems you have only one interrupt from the

PCIe

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

core, shared between the MSI irqs and the PCI legacy interrupts. This means this handler may get called without an MSI irq pending,

so

Quoted 1 line
Quoted 1 line
Quoted 1 line

this function really should have a path where it's returning

IRQ_NONE.

Quoted 1 line
Quoted 1 line

Ah, yes you are right... though actually there are two interrupts, one

has

Quoted 10 lines
Quoted 2 lines

some MSI and INTx, the other has the rest of the MSIs.

This isn't reflected in the DT binding. If you already know that there may be more than a single interrupt for MSI, please push this into the binding by using named interrupts. Even if your driver doesn't support it yet, additional functionality can always be added later, but the DT should be a stable ABI describing your hardware.

So if you already know your hardware has more than one interrupt, please put it in the binding, to avoid churn later on.

At the moment we support both interrupts but the code implicitly gets the 'next' interrupt for MSI. I'll change that so that all the interrupts are specified in the binding.

Quoted 5 lines

Regards,
Lucas

Signature · 2 lines
Pengutronix e.K.                           | Lucas Stach |
Industrial Linux Solutions                 | http://www.pengutronix.de/ 

|

Quoted 1 line

Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076

|

Quoted 1 line

Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555

|

Quoted 1 line

Thanks
Phil

#12 lore raw

PATCH v4 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
#13 lore raw

PATCH v4 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
#14 lore raw

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

In reply to Phil Edworthy

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

---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 40 ++++++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/rcar-pci.txt
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +40 -0
new file mode 100644
index 0000000..0e219b0
@@ -0,0 +1,40 @@
+* Renesas RCar PCIe interface
+
+Required properties:
+- compatible: should contain one of the following
+	"renesas,r8a7779-pcie", "renesas,r8a7790-pcie", "renesas,r8a7791-pcie"
+- 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
+- interrupts: interrupt values for MSI interrupt
+- #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"
+
+Example:
+
+SoC specific DT Entry:
+
+	pcie: pcie at 0x01000000 {
+		compatible = "renesas,r8a7790-pcie";
+		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>;
+		interrupts = <0 116 4>;
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &gic 0 116 4>;
+		clocks = <&mstp3_clks R8A7790_CLK_PCIE>;
+		clock-names = "pcie";
+		status = "disabled";
+	};
Signature · 1 line
1.9.0
#15 lore raw

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

Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:

Quoted 4 lines

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

I have one question below. If you can answer this with yes after thinking again about it, this is:

Quoted 18 lines
---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 40 ++++++++++++++++++++++
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/rcar-pci.txt
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +7 -0
new file mode 100644
index 0000000..0e219b0
@@ -0,0 +1,40 @@
+* Renesas RCar PCIe interface
+
+Required properties:
+- compatible: should contain one of the following
+	"renesas,r8a7779-pcie", "renesas,r8a7790-pcie", "renesas,r8a7791-pcie"
+- reg: base addresses and lengths of the pcie controller.
+- #address-cells: set to <3>

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

Quoted 10 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +10 -0
+- #size-cells: set to <2>
+- device_type: set to "pci"
+- ranges: ranges for the PCI memory and I/O regions
+- interrupts: interrupt values for MSI interrupt
+- #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"

You really only have one PCIe clock? So the controller is generating the PCIe bus clock from it's register clock? No need to enable any other clock for PCIe to work?

Quoted 23 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +23 -0
+
+Example:
+
+SoC specific DT Entry:
+
+	pcie: pcie at 0x01000000 {
+		compatible = "renesas,r8a7790-pcie";
+		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>;
+		interrupts = <0 116 4>;
+		#interrupt-cells = <1>;
+		interrupt-map-mask = <0 0 0 0>;
+		interrupt-map = <0 0 0 0 &gic 0 116 4>;
+		clocks = <&mstp3_clks R8A7790_CLK_PCIE>;
+		clock-names = "pcie";
+		status = "disabled";
+	};
Signature · 4 lines
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
#16 lore raw

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

Hi Lucas,

Quoted 1 line · Lucas

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

bindings

Quoted 5 lines

Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:

Quoted 3 lines

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

Quoted 8 lines
Quoted 1 line

I have one question below. If you can answer this with yes after thinking again about it, this is:

Quoted 2 lines
---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 40 

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

Quoted 5 lines

Review

Quoted 4 lines
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/rcar-pci.txt
(quoted diff) renamed from Documentation/devicetree/bindings/pci/rcar-pci.txt +0 -0

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

Quoted 10 lines

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

Quoted 10 lines

new file mode 100644
index 0000000..0e219b0

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

"renesas,r8a7791-pcie"

Quoted 13 lines

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

Quoted 12 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +12 -0
+- 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
+- interrupts: interrupt values for MSI interrupt
+- #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"
Quoted 3 lines

You really only have one PCIe clock? So the controller is generating the PCIe bus clock from it's register clock? No need to enable any other clock for PCIe to work?

Yes, just the one clock. The PCIe bus clock is an external clock dedicated to PCIe and SATA, and we have no control over it.

Quoted 15 lines
Quoted 15 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +15 -0
+
+Example:
+
+SoC specific DT Entry:
+
+   pcie: pcie at 0x01000000 {
+      compatible = "renesas,r8a7790-pcie";
+      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>;
Quoted 12 lines
Quoted 8 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +8 -0
+      interrupts = <0 116 4>;
+      #interrupt-cells = <1>;
+      interrupt-map-mask = <0 0 0 0>;
+      interrupt-map = <0 0 0 0 &gic 0 116 4>;
+      clocks = <&mstp3_clks R8A7790_CLK_PCIE>;
+      clock-names = "pcie";
+      status = "disabled";
+   };
Signature · 2 lines
Pengutronix e.K.                           | Lucas Stach |
Industrial Linux Solutions                 | http://www.pengutronix.de/ 

|

Quoted 1 line

Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076

|

Quoted 1 line

Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555

|

Quoted 1 line

Thanks
Phil

#17 lore raw

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

Am Freitag, den 21.03.2014, 14:18 +0000 schrieb
Phil.Edworthy at renesas.com:

Quoted 48 lines

Hi Lucas,

Quoted 1 line · Lucas

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

bindings

Quoted 5 lines

Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:

Quoted 3 lines

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

Quoted 8 lines
Quoted 1 line

I have one question below. If you can answer this with yes after thinking again about it, this is:

Quoted 2 lines
---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 40 

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

Quoted 5 lines

Review

Quoted 4 lines
 1 file changed, 40 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/rcar-pci.txt
(quoted diff) renamed from Documentation/devicetree/bindings/pci/rcar-pci.txt +0 -0

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

Quoted 10 lines

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

Quoted 10 lines

new file mode 100644
index 0000000..0e219b0

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

"renesas,r8a7791-pcie"

Quoted 13 lines
Quoted 12 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +12 -0
+- 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
+- interrupts: interrupt values for MSI interrupt
+- #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"
Quoted 6 lines
Quoted 3 lines

You really only have one PCIe clock? So the controller is generating the PCIe bus clock from it's register clock? No need to enable any other clock for PCIe to work?

Yes, just the one clock. The PCIe bus clock is an external clock dedicated to PCIe and SATA, and we have no control over it.

Is this some kind of always-on clock? If not you probably want a reference to it from the PCIe driver even if it's shared between SATA and PCIe. After all you don't want to end up unconditionally enabling this clock from the board or SoC level just to have PCIe working, right?

Regards,
Lucas

Signature · 4 lines
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
#18 lore raw

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

Hi Lucas,

Quoted 1 line · Lucas

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

bindings

Quoted 24 lines

Am Freitag, den 21.03.2014, 14:18 +0000 schrieb
Phil.Edworthy at renesas.com:

Quoted 21 lines

Hi Lucas,

Quoted 1 line · Lucas

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

bindings

Quoted 5 lines

Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:

Quoted 3 lines

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

Quoted 8 lines
Quoted 1 line

I have one question below. If you can answer this with yes after thinking again about it, this is:

Quoted 2 lines
---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 40 

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

Quoted 2 lines
Quoted 2 lines
 1 file changed, 40 insertions(+)
 create mode 100644 

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

Quoted 27 lines
Quoted 27 lines
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..0e219b0

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

"renesas,r8a7791-pcie"

Quoted 13 lines
Quoted 12 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +12 -0
+- 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
+- interrupts: interrupt values for MSI interrupt
+- #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"
Quoted 1 line
Quoted 1 line
Quoted 1 line

You really only have one PCIe clock? So the controller is generating

the

Quoted 3 lines
Quoted 3 lines
Quoted 2 lines

PCIe bus clock from it's register clock? No need to enable any other clock for PCIe to work?

Yes, just the one clock. The PCIe bus clock is an external clock

dedicated

Quoted 6 lines
Quoted 2 lines

to PCIe and SATA, and we have no control over it.

Is this some kind of always-on clock? If not you probably want a reference to it from the PCIe driver even if it's shared between SATA and PCIe. After all you don't want to end up unconditionally enabling this clock from the board or SoC level just to have PCIe working, right?

Ok, I see, I'll need a reference to a board clock, even if it's always on for these boards.

Quoted 5 lines

Regards,
Lucas

Signature · 2 lines
Pengutronix e.K.                           | Lucas Stach |
Industrial Linux Solutions                 | http://www.pengutronix.de/ 

|

Quoted 1 line

Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076

|

Quoted 1 line

Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555

|

Quoted 1 line

Thanks
Phil

A message that is not in the archive (sent off-list or not yet received): OFC7DD5DAC.D378B300-ON80257CA2.0051ECEE-80257CA2.00529F98@LocalDomain

#20 lore raw

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

Hi Lucas,

Quoted 1 line · Phil

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

bindings

Quoted 5 lines

Hi Lucas,

Quoted 1 line · Lucas

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

bindings

Quoted 7 lines
Quoted 7 lines

Am Freitag, den 21.03.2014, 14:18 +0000 schrieb
Phil.Edworthy at renesas.com:

Quoted 4 lines

Hi Lucas,

Quoted 1 line · Lucas

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

tree

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

bindings

Quoted 3 lines

Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:

Quoted 1 line

This patch adds the bindings for the rcar PCIE driver. The

driver

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines

resides under drivers/pci/host/pcie-rcar.c

I have one question below. If you can answer this with yes after thinking again about it, this is:

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines
---
 Documentation/devicetree/bindings/pci/rcar-pci.txt | 40 

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

Quoted 2 lines
Quoted 2 lines
 1 file changed, 40 insertions(+)
 create mode 100644 

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

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Review

Quoted 2 lines
(quoted diff) +0 -0

b/

Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
Quoted 11 lines

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..0e219b0

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

"renesas,r8a7791-pcie"

Quoted 13 lines
Quoted 12 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +12 -0
+- 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
+- interrupts: interrupt values for MSI interrupt
+- #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"
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

You really only have one PCIe clock? So the controller is

generating the

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

PCIe bus clock from it's register clock? No need to enable any

other

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line

clock for PCIe to work?

Yes, just the one clock. The PCIe bus clock is an external clock

dedicated

Quoted 6 lines
Quoted 6 lines
Quoted 2 lines

to PCIe and SATA, and we have no control over it.

Is this some kind of always-on clock? If not you probably want a reference to it from the PCIe driver even if it's shared between SATA and PCIe. After all you don't want to end up unconditionally enabling this clock from the board or SoC level just to have PCIe working,

right?

Quoted 1 line

Ok, I see, I'll need a reference to a board clock, even if it's always

on for

Quoted 1 line

these boards.

One small question...

The patches added the PCIe host controller to two devices, r8a7790 and r8a7791. The r8a7790-based Lager board doesn't have the necessary hardware to use PCIe, so should I add a dummy pcie_bus clock to the Lager board dts, even though PCIe is not used?

I'm just wondering what the dts file looks like for a board that doesn't support many interfaces. Does it become littered with dummy clocks and regulators?

Thanks
Phil

#21 lore raw

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

Quoted 85 lines · Phil.Edworthy at renesas.com

Hi Lucas,

Quoted 1 line · Phil

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

bindings

Quoted 5 lines

Hi Lucas,

Quoted 1 line · Lucas

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

bindings

Quoted 7 lines
Quoted 7 lines

Am Freitag, den 21.03.2014, 14:18 +0000 schrieb
Phil.Edworthy at renesas.com:

Quoted 4 lines

Hi Lucas,

Quoted 1 line · Lucas

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

tree

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

bindings

Quoted 3 lines

Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:

Quoted 1 line

This patch adds the bindings for the rcar PCIE driver. The

driver

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines

resides under drivers/pci/host/pcie-rcar.c

I have one question below. If you can answer this with yes after thinking again about it, this is:

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines
---
  Documentation/devicetree/bindings/pci/rcar-pci.txt | 40

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

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

create mode 100644

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

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Review

Quoted 2 lines
(quoted diff) +0 -0

b/

Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
Quoted 11 lines

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..0e219b0

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

"renesas,r8a7791-pcie"

Quoted 13 lines
Quoted 12 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +12 -0
+- 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
+- interrupts: interrupt values for MSI interrupt
+- #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"
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

You really only have one PCIe clock? So the controller is

generating the

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

PCIe bus clock from it's register clock? No need to enable any

other

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line

clock for PCIe to work?

Yes, just the one clock. The PCIe bus clock is an external clock

dedicated

Quoted 6 lines
Quoted 6 lines
Quoted 2 lines

to PCIe and SATA, and we have no control over it.

Is this some kind of always-on clock? If not you probably want a reference to it from the PCIe driver even if it's shared between SATA and PCIe. After all you don't want to end up unconditionally enabling this clock from the board or SoC level just to have PCIe working,

right?

Quoted 1 line

Ok, I see, I'll need a reference to a board clock, even if it's always

on for

Quoted 1 line

these boards.

One small question...

Quoted 8 lines

The patches added the PCIe host controller to two devices, r8a7790 and r8a7791. The r8a7790-based Lager board doesn't have the necessary hardware to use PCIe, so should I add a dummy pcie_bus clock to the Lager board dts, even though PCIe is not used?

I'm just wondering what the dts file looks like for a board that doesn't support many interfaces. Does it become littered with dummy clocks and regulators?

The bridge node should be set to disabled by default so it never gets probed. Any boards that want to use it can over-ride the status to be enabled.

Signature · 2 lines
Ben Dooks				http://www.codethink.co.uk/
Senior Engineer				Codethink - Providing Genius
#22 lore raw

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

Hi Ben,

Quoted 1 line · Ben

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

bindings

Quoted 71 lines · Phil.Edworthy at renesas.com
Quoted 69 lines

Hi Lucas,

Quoted 1 line · Phil

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

bindings

Quoted 5 lines

Hi Lucas,

Quoted 1 line · Lucas

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

bindings

Quoted 7 lines
Quoted 7 lines

Am Freitag, den 21.03.2014, 14:18 +0000 schrieb
Phil.Edworthy at renesas.com:

Quoted 4 lines

Hi Lucas,

Quoted 1 line · Lucas

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

tree

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

bindings

Quoted 3 lines

Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:

Quoted 1 line

This patch adds the bindings for the rcar PCIE driver. The

driver

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines

resides under drivers/pci/host/pcie-rcar.c

I have one question below. If you can answer this with yes after thinking again about it, this is:

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines
---
  Documentation/devicetree/bindings/pci/rcar-pci.txt | 40

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

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

create mode 100644

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

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Review

Quoted 2 lines
(quoted diff) +0 -0

b/

Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
Quoted 11 lines

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..0e219b0

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

"renesas,r8a7791-pcie"

Quoted 13 lines
Quoted 12 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +12 -0
+- 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
+- interrupts: interrupt values for MSI interrupt
+- #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"
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

You really only have one PCIe clock? So the controller is

generating the

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

PCIe bus clock from it's register clock? No need to enable any

Quoted 8 lines
Quoted 8 lines

other

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line

clock for PCIe to work?

Yes, just the one clock. The PCIe bus clock is an external clock

dedicated

Quoted 4 lines
Quoted 4 lines
Quoted 2 lines

to PCIe and SATA, and we have no control over it.

Is this some kind of always-on clock? If not you probably want a reference to it from the PCIe driver even if it's shared between

SATA

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

and PCIe. After all you don't want to end up unconditionally

enabling

Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line

this clock from the board or SoC level just to have PCIe working,

right?

Quoted 1 line

Ok, I see, I'll need a reference to a board clock, even if it's

always

Quoted 6 lines
Quoted 6 lines

on for

Quoted 1 line

these boards.

One small question...

The patches added the PCIe host controller to two devices, r8a7790 and r8a7791. The r8a7790-based Lager board doesn't have the necessary

hardware

Quoted 4 lines
Quoted 4 lines

to use PCIe, so should I add a dummy pcie_bus clock to the Lager board dts, even though PCIe is not used?

I'm just wondering what the dts file looks like for a board that

doesn't

Quoted 6 lines
Quoted 2 lines

support many interfaces. Does it become littered with dummy clocks and regulators?

The bridge node should be set to disabled by default so it never gets probed. Any boards that want to use it can over-ride the status to be enabled.

Ok, thanks.

Phil

A message that is not in the archive (sent off-list or not yet received): OF85DD7B1D.716DE42D-ON80257CA5.00443087-80257CA5.004447DB@LocalDomain

#24 lore raw

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

Hi Ben,

Quoted 1 line · Phil

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

bindings

Quoted 5 lines

Hi Ben,

Quoted 1 line · Ben

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

bindings

Quoted 4 lines
Quoted 4 lines · Phil.Edworthy at renesas.com
Quoted 2 lines

Hi Lucas,

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 1 line · Phil

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

bindings

Quoted 5 lines

Hi Lucas,

Quoted 1 line · Lucas

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

tree

Quoted 43 lines
Quoted 43 lines
Quoted 43 lines

bindings

Quoted 7 lines
Quoted 7 lines

Am Freitag, den 21.03.2014, 14:18 +0000 schrieb
Phil.Edworthy at renesas.com:

Quoted 4 lines

Hi Lucas,

Quoted 1 line · Lucas

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

tree

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

bindings

Quoted 3 lines

Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:

Quoted 1 line

This patch adds the bindings for the rcar PCIE driver. The

driver

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines

resides under drivers/pci/host/pcie-rcar.c

I have one question below. If you can answer this with yes after thinking again about it, this is:

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines
---
  Documentation/devicetree/bindings/pci/rcar-pci.txt | 40

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

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

create mode 100644

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

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Review

Quoted 2 lines
(quoted diff) +0 -0

b/

Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines

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..0e219b0

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

"renesas,r8a7791-pcie"

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines

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

Quoted 8 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +8 -0
+- 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
+- interrupts: interrupt values for MSI interrupt
+- #interrupt-cells: set to <1>
+- interrupt-map-mask and interrupt-map: standard PCI 

properties

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines

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

Quoted 4 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +4 -0
+   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"

You really only have one PCIe clock? So the controller is

generating the

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

PCIe bus clock from it's register clock? No need to enable any

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines

other

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line

clock for PCIe to work?

Yes, just the one clock. The PCIe bus clock is an external clock

dedicated

Quoted 4 lines
Quoted 4 lines
Quoted 2 lines

to PCIe and SATA, and we have no control over it.

Is this some kind of always-on clock? If not you probably want a reference to it from the PCIe driver even if it's shared between

SATA

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

and PCIe. After all you don't want to end up unconditionally

enabling

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line

this clock from the board or SoC level just to have PCIe working,

right?

Quoted 1 line

Ok, I see, I'll need a reference to a board clock, even if it's

always

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines

on for

Quoted 1 line

these boards.

One small question...

The patches added the PCIe host controller to two devices, r8a7790

and

Quoted 1 line
Quoted 1 line
Quoted 1 line

r8a7791. The r8a7790-based Lager board doesn't have the necessary

hardware

Quoted 1 line
Quoted 1 line
Quoted 1 line

to use PCIe, so should I add a dummy pcie_bus clock to the Lager

board

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

dts, even though PCIe is not used?

I'm just wondering what the dts file looks like for a board that

doesn't

Quoted 1 line
Quoted 1 line
Quoted 1 line

support many interfaces. Does it become littered with dummy clocks

and

Quoted 6 lines
Quoted 5 lines
Quoted 1 line

regulators?

The bridge node should be set to disabled by default so it never gets probed. Any boards that want to use it can over-ride the status to be enabled.

Ok, thanks.

Hmm, yes it doesn't get probed, but you still get a build problem as the DT entry references an clock that doesn't exist. Maybe I'm missing something...

Phil

#25 lore raw

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

Am Montag, den 24.03.2014, 12:46 +0000 schrieb
Phil.Edworthy at renesas.com:

Quoted 117 lines

Hi Ben,

Quoted 1 line · Phil

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

bindings

Quoted 5 lines

Hi Ben,

Quoted 1 line · Ben

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

bindings

Quoted 4 lines
Quoted 4 lines · Phil.Edworthy at renesas.com
Quoted 2 lines

Hi Lucas,

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 1 line · Phil

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

bindings

Quoted 5 lines

Hi Lucas,

Quoted 1 line · Lucas

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

tree

Quoted 43 lines
Quoted 43 lines
Quoted 43 lines

bindings

Quoted 7 lines
Quoted 7 lines

Am Freitag, den 21.03.2014, 14:18 +0000 schrieb
Phil.Edworthy at renesas.com:

Quoted 4 lines

Hi Lucas,

Quoted 1 line · Lucas

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

tree

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

bindings

Quoted 3 lines

Am Freitag, den 21.03.2014, 10:32 +0000 schrieb Phil Edworthy:

Quoted 1 line

This patch adds the bindings for the rcar PCIE driver. The

driver

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines

resides under drivers/pci/host/pcie-rcar.c

I have one question below. If you can answer this with yes after thinking again about it, this is:

Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 3 lines
Quoted 2 lines
---
  Documentation/devicetree/bindings/pci/rcar-pci.txt | 40

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

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

create mode 100644

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

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Review

Quoted 2 lines
(quoted diff) +0 -0

b/

Quoted 12 lines
Quoted 12 lines
Quoted 12 lines
Quoted 11 lines

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..0e219b0

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

"renesas,r8a7791-pcie"

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines

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

Quoted 8 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +8 -0
+- 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
+- interrupts: interrupt values for MSI interrupt
+- #interrupt-cells: set to <1>
+- interrupt-map-mask and interrupt-map: standard PCI 

properties

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines
Quoted 6 lines

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

Quoted 4 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +4 -0
+   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"

You really only have one PCIe clock? So the controller is

generating the

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

PCIe bus clock from it's register clock? No need to enable any

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines

other

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line

clock for PCIe to work?

Yes, just the one clock. The PCIe bus clock is an external clock

dedicated

Quoted 4 lines
Quoted 4 lines
Quoted 2 lines

to PCIe and SATA, and we have no control over it.

Is this some kind of always-on clock? If not you probably want a reference to it from the PCIe driver even if it's shared between

SATA

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

and PCIe. After all you don't want to end up unconditionally

enabling

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Quoted 1 line

this clock from the board or SoC level just to have PCIe working,

right?

Quoted 1 line

Ok, I see, I'll need a reference to a board clock, even if it's

always

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines

on for

Quoted 1 line

these boards.

One small question...

The patches added the PCIe host controller to two devices, r8a7790

and

Quoted 1 line
Quoted 1 line
Quoted 1 line

r8a7791. The r8a7790-based Lager board doesn't have the necessary

hardware

Quoted 1 line
Quoted 1 line
Quoted 1 line

to use PCIe, so should I add a dummy pcie_bus clock to the Lager

board

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

dts, even though PCIe is not used?

I'm just wondering what the dts file looks like for a board that

doesn't

Quoted 1 line
Quoted 1 line
Quoted 1 line

support many interfaces. Does it become littered with dummy clocks

and

Quoted 2 lines
Quoted 2 lines
Quoted 1 line

regulators?

Quoted 8 lines
Quoted 4 lines
Quoted 3 lines

The bridge node should be set to disabled by default so it never gets probed. Any boards that want to use it can over-ride the status to be enabled.

Ok, thanks.

Hmm, yes it doesn't get probed, but you still get a build problem as the DT entry references an clock that doesn't exist. Maybe I'm missing something...

If the clock is a board supplied one then you have to supply to clocks property from the board dts, to get rid of the compile failure. You can not have phandles in the PCIe node referencing a non-existing clock.

Regards,
Lucas

Signature · 4 lines
Pengutronix e.K.                           | Lucas Stach                 |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
#26 lore raw

PATCH v4 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

---
 arch/arm/boot/dts/r8a7790.dtsi | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
arch/arm/boot/dts/r8a7790.dtsi +19 -0
index df9ec61..e7d498a 100644
@@ -821,4 +821,23 @@
 		#size-cells = <0>;
 		status = "disabled";
 	};
+
+	pcie: pcie at fe000000 {
+		compatible = "renesas,r8a7790-pcie";
+		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>;
+		interrupts = <0 116 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>;
+		clock-names = "pcie";
+		status = "disabled";
+	};
 };
Signature · 1 line
1.9.0
#27 lore raw

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

Hello.

Quoted 12 lines · Phil Edworthy

This patch adds the device tree nodes for R8A7790

---
  arch/arm/boot/dts/r8a7790.dtsi | 19 +++++++++++++++++++
  1 file changed, 19 insertions(+)
arch/arm/boot/dts/r8a7790.dtsi +0 -0
index df9ec61..e7d498a 100644

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

Quoted 6 lines
arch/arm/boot/dts/r8a7790.dtsi +3 -0
@@ -821,4 +821,23 @@
  		#size-cells = <0>;
  		status = "disabled";
  	};
+
+	pcie: pcie@fe000000 {
+		compatible = "renesas,r8a7790-pcie";

The convention adopted on this list is to put the "pcie" first, and SoC
name the last.

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

Quoted 4 lines
arch/arm/boot/dts/r8a7790.dtsi +4 -0
+		reg = <0 0xfe000000 0 0x80000>;
+		#address-cells = <3>;
+		#size-cells = <2>;
+		device_type = "pci";

This legacy property is only meaningful for the true OF firmware and thus
have been phased out (it's only actively used for the memory nodes).

WBR, Sergei

#28 lore raw

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

Hi Sergei,

Quoted 1 line · Sergei

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

for R8A7790

Quoted 5 lines

Hello.

On 03/21/2014 01:32 PM, Phil Edworthy wrote:

Quoted 8 lines

Review

Quoted 8 lines

This patch adds the device tree nodes for R8A7790

---
  arch/arm/boot/dts/r8a7790.dtsi | 19 +++++++++++++++++++
  1 file changed, 19 insertions(+)
(quoted diff) +0 -0

b/arch/arm/boot/dts/r8a7790.dtsi

Quoted 4 lines
Quoted 4 lines

index df9ec61..e7d498a 100644

arch/arm/boot/dts/r8a7790.dtsi +0 -0
@@ -821,4 +821,23 @@
Quoted 8 lines

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

Quoted 6 lines
arch/arm/boot/dts/r8a7790.dtsi +3 -0
        #size-cells = <0>;
        status = "disabled";
     };
+
+   pcie: pcie at fe000000 {
+      compatible = "renesas,r8a7790-pcie";

The convention adopted on this list is to put the "pcie" first, and

SoC

Quoted 1 line

name the last.

Ok, shame that all the other PCI hosts use vendor,device-pcie

Quoted 6 lines

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

Quoted 4 lines
arch/arm/boot/dts/r8a7790.dtsi +4 -0
+      reg = <0 0xfe000000 0 0x80000>;
+      #address-cells = <3>;
+      #size-cells = <2>;
+      device_type = "pci";

This legacy property is only meaningful for the true OF firmware and

thus

Quoted 1 line

have been phased out (it's only actively used for the memory nodes).

Ok, thanks for pointing this out.

Quoted 2 lines

WBR, Sergei

Thanks
Phil

#29 lore raw

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

Quoted 11 lines · On Friday 21 March 2014 14:53:48 Phil.Edworthy at renesas.com wrote:
Quoted 7 lines

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

Quoted 5 lines
arch/arm/boot/dts/r8a7790.dtsi +4 -0
+      reg = <0 0xfe000000 0 0x80000>;
+      #address-cells = >;
+      #size-cells = <2>;
+      device_type = "pci";

This legacy property is only meaningful for the true OF firmware and

thus

Quoted 1 line

have been phased out (it's only actively used for the memory nodes).

Ok, thanks for pointing this out.

I think the code still relies on it for PCI though.

Arnd

#30 lore raw

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

Hello.

Quoted 11 lines · Arnd Bergmann
Quoted 9 lines
Quoted 7 lines

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

Quoted 4 lines
arch/arm/boot/dts/r8a7790.dtsi +4 -0
+      reg = <0 0xfe000000 0 0x80000>;
+      #address-cells = >;
+      #size-cells = <2>;
+      device_type = "pci";

This legacy property is only meaningful for the true OF firmware and thus
have been phased out (it's only actively used for the memory nodes).

Ok, thanks for pointing this out.

I think the code still relies on it for PCI though.

OK, I have found where it does that but the recommended value seems to be
"pciex" for PCI-Express case.

Quoted 1 line

Arnd

WBR, Sergei

#31 lore raw

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

Hi Sergei,

Quoted 1 line · Sergei

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

for R8A7790

Quoted 11 lines

Hello.

Quoted 6 lines · Arnd Bergmann
Quoted 6 lines
Quoted 6 lines

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

Quoted 4 lines
arch/arm/boot/dts/r8a7790.dtsi +4 -0
+      reg = <0 0xfe000000 0 0x80000>;
+      #address-cells = >;
+      #size-cells = <2>;
+      device_type = "pci";

This legacy property is only meaningful for the true OF

firmware and thus

Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line

have been phased out (it's only actively used for the memory nodes).

Ok, thanks for pointing this out.

I think the code still relies on it for PCI though.

OK, I have found where it does that but the recommended value seems

to be

Quoted 1 line

"pciex" for PCI-Express case.

Ok, but why then do all the other PCIe hosts use "pci"?

Thanks
Phil

#32 lore raw

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

Quoted 4 lines · Phil.Edworthy at renesas.com
Quoted 2 lines

OK, I have found where it does that but the recommended value
seems to be "pciex" for PCI-Express case.

Ok, but why then do all the other PCIe hosts use "pci"?

Because that is what the PCI bus binding standard says to do, and new drivers have been pushed toward conforming to that document.

I'm not sure if "pciex" was ever standardized, I haven't see a spec that reflects that at least.

Commit 14e2abb732e485ee57d9d5b2cb8884652238e5c1 introduced support for the "pciex" word, but it looks driven by proprietary choices by IBM..

In any event there isn't a single 'device_type = "pciex";' pre-exsting in the kernel bindings today, so please don't add one :)

Regards,
Jason

#33 lore raw

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

In reply to Arnd Bergmann
Quoted 7 lines · Arnd Bergmann
Quoted 6 lines · On Friday 21 March 2014 14:53:48 Phil.Edworthy at renesas.com wrote:
Quoted 6 lines
Quoted 5 lines
arch/arm/boot/dts/r8a7790.dtsi +4 -0
+      reg = <0 0xfe000000 0 0x80000>;
+      #address-cells = >;
+      #size-cells = <2>;
+      device_type = "pci";
Quoted 7 lines
Quoted 5 lines
Quoted 1 line

This legacy property is only meaningful for the true OF firmware and

thus

Quoted 1 line

have been phased out (it's only actively used for the memory nodes).

Ok, thanks for pointing this out.

I think the code still relies on it for PCI though.

Right, it must be present for PCI nodes, it triggers special behavior in the address parsing routines.

What Phil has looks correct to me.

Regards,
Jason

#34 lore raw

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

In reply to Sergei Shtylyov
Quoted 6 lines · Sergei Shtylyov

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

Quoted 3 lines
arch/arm/boot/dts/r8a7790.dtsi +3 -0
+
+       pcie: pcie at fe000000 {
+               compatible = "renesas,r8a7790-pcie";

The convention adopted on this list is to put the "pcie" first, and SoC
name the last.

Except for clock bindings ;-)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

#35 lore raw

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

In reply to Phil Edworthy

Hello.

Quoted 6 lines · Phil Edworthy

This patch adds the device tree nodes for R8A7790

---
  arch/arm/boot/dts/r8a7790.dtsi | 19 +++++++++++++++++++
  1 file changed, 19 insertions(+)

Why are you not enabling PCIe for Lager, only on Koelsch?

WBR, Sergei

#36 lore raw

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

Hi Sergei,

Quoted 1 line · Sergei

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

for R8A7790

Quoted 5 lines

Hello.

On 03/21/2014 01:32 PM, Phil Edworthy wrote:

Quoted 8 lines
Quoted 6 lines

This patch adds the device tree nodes for R8A7790

---
  arch/arm/boot/dts/r8a7790.dtsi | 19 +++++++++++++++++++
  1 file changed, 19 insertions(+)

Why are you not enabling PCIe for Lager, only on Koelsch?

The Lager board doesn't have PCIe hardware. Note that it's possible to modify the Lager board and convert the SATA signals to PCIe, and we've done that to check that it works on R-Car H2.

Quoted 2 lines

WBR, Sergei

Thanks
Phil

#37 lore raw

PATCH v4 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

---
 arch/arm/boot/dts/r8a7791-koelsch.dts |  4 ++++
 arch/arm/boot/dts/r8a7791.dtsi        | 19 +++++++++++++++++++
 2 files changed, 23 insertions(+)
arch/arm/boot/dts/r8a7791-koelsch.dts +4 -0
index e24fed9..17c953f 100644
@@ -352,3 +352,7 @@
 		spi-cpha;
 	};
 };
+
+&pcie {
+	status = "okay";
+};
arch/arm/boot/dts/r8a7791.dtsi +19 -0
index ccfba57..915a5a6 100644
@@ -836,4 +836,23 @@
 		#size-cells = <0>;
 		status = "disabled";
 	};
+
+	pcie: pcie at fe000000 {
+		compatible = "renesas,r8a7791-pcie";
+		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>;
+		interrupts = <0 116 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>;
+		clock-names = "pcie";
+		status = "disabled";
+	};
 };
Signature · 1 line
1.9.0
#38 lore raw

PATCH v4 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
#39 lore raw

PATCH v4 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