R-Car Gen2 PCIe host driver
Subsystems (8)
v5 cover R-Car Gen2 PCIe host driver
This is version 5 of a PCIe Host driver for the R-Car Gen2 devices, i.e. R-Car H2 (r8a7790) and R-Car M2 (r8a7791).
v5:
- Use module_platform_driver instead of subsys_initcall
- Use the of_device_id data field for HW init function
- Init hw_pci struct in declaration
- Renesas SoC compatible string has peripheral before device name
- Add PCIe bus clock reference
- Use dma-ranges property to specify inbound memory regions
- Support multiple IO windows and correct resources
- Return IRQ_NONE from MSI isr when there is no pending MSI
- Add additional interrupt bindings
v4:
- Use runtime PM properly
Phil Edworthy (9):
PCI: host: rcar: Add Renesas R-Car PCIe driver
PCI: host: rcar: Add MSI support
ARM: shmobile: r8a7790: Add PCIe clock device tree nodes
ARM: shmobile: r8a7791: Add PCIe clock device tree nodes
dt-bindings: pci: rcar pcie device tree bindings
ARM: shmobile: Add PCIe device tree nodes for R8A7790
ARM: shmobile: Add PCIe device tree nodes for R8A7791 Koelsch board
ARM: koelsch: Add PCIe to defconfig
ARM: koelsch: Add HAVE_ARM_ARCH_TIMER to defconfig
Documentation/devicetree/bindings/pci/rcar-pci.txt | 44 + arch/arm/boot/dts/r8a7790-lager.dts | 10 + arch/arm/boot/dts/r8a7790.dtsi | 31 +- arch/arm/boot/dts/r8a7791-koelsch.dts | 14 + arch/arm/boot/dts/r8a7791.dtsi | 31 +- arch/arm/configs/koelsch_defconfig | 4 + drivers/pci/host/Kconfig | 6 + drivers/pci/host/Makefile | 1 + drivers/pci/host/pcie-rcar.c | 937 +++++++++++++++++++++ drivers/pci/host/pcie-rcar.h | 87 ++ include/dt-bindings/clock/r8a7790-clock.h | 1 + include/dt-bindings/clock/r8a7791-clock.h | 1 + 12 files changed, 1162 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/rcar-pci.txt create mode 100644 drivers/pci/host/pcie-rcar.c create mode 100644 drivers/pci/host/pcie-rcar.h
Signature · 1 line
1.9.0
PATCH v5 1/9 PCI: host: rcar: Add Renesas R-Car PCIe driver
This PCIe Host driver currently does not support MSI, so cards fall back to INTx interrupts.
---
v5:
- Use module_platform_driver instead of subsys_initcall
- Use the of_device_id data field for HW init function
- Init hw_pci struct in declaration
- Renesas SoC compatible string has peripheral before device name
- Add PCIe bus clock reference
- Use dma-ranges property to specify inbound memory regions
- Support multiple IO windows and correct resources
v4:
- Use runtime PM properly
v3:
- Add DT support
- Use 'of_irq_parse_and_map_pci' for '.map_irq'
- Use pm ops to enable clocks
- Fix checkpatch errors
- Use subsys_initcall to overcome issues with port bus driver
- Adjust Kconfig to match other R-Car drivers
v2:
- Use msleep instead of udelay when waiting for the link
- Use pm_runtime
- Removed unused definition
- Also replaced call to devm_request_and_ioremap with devm_ioremap_resource and fixed a bug with this when reporting errors.
--- drivers/pci/host/Kconfig | 6 + drivers/pci/host/Makefile | 1 + drivers/pci/host/pcie-rcar.c | 693 +++++++++++++++++++++++++++++++++++++++++++ drivers/pci/host/pcie-rcar.h | 82 +++++ 4 files changed, 782 insertions(+) create mode 100644 drivers/pci/host/pcie-rcar.c create mode 100644 drivers/pci/host/pcie-rcar.h
drivers/pci/host/Kconfig +6 -0
@@ -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
@@ -4,3 +4,4 @@ obj-$(CONFIG_PCI_IMX6) += pci-imx6.o obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o obj-$(CONFIG_PCI_TEGRA) += pci-tegra.o obj-$(CONFIG_PCI_RCAR_GEN2) += pci-rcar-gen2.o +obj-$(CONFIG_PCI_RCAR_GEN2_PCIE) += pcie-rcar.o
drivers/pci/host/pcie-rcar.c new file +693 -0
693 lines not on this page · raw message
drivers/pci/host/pcie-rcar.h new file +82 -0
82 lines not on this page · raw message
Signature · 1 line
1.9.0
PATCH v5 2/9 PCI: host: rcar: Add MSI support
In reply to Phil Edworthy---
v5:
- Return IRQ_NONE from MSI isr when there is no pending MSI
- Add additional interrupt bindings
--- drivers/pci/host/pcie-rcar.c | 246 ++++++++++++++++++++++++++++++++++++++++++- drivers/pci/host/pcie-rcar.h | 5 + 2 files changed, 250 insertions(+), 1 deletion(-)
drivers/pci/host/pcie-rcar.c +245 -1
@@ -15,8 +15,11 @@#include <linux/clk.h> #include <linux/delay.h> #include <linux/interrupt.h> +#include <linux/irq.h> +#include <linux/irqdomain.h> #include <linux/kernel.h> #include <linux/module.h> +#include <linux/msi.h> #include <linux/of_address.h> #include <linux/of_irq.h> #include <linux/of_pci.h>
@@ -28,6 +31,8 @@#define DRV_NAME "rcar-pcie" +#define INT_PCI_MSI_NR 32 +#define RCONF (x) (PCICONF(0)+(x))#define RPMCAP (x) (PMCAP(0)+(x))#define REXPCAP (x) (EXPCAP(0)+(x))
@@ -40,6 +45,21 @@#define PCI_MAX_RESOURCES 4#define MAX_NR_INBOUND_MAPS 6 +struct rcar_msi { + DECLARE_BITMAP(used, INT_PCI_MSI_NR); +struct irq_domain *domain; +struct msi_chip chip; +unsigned long pages; +struct mutex lock; +int irq1; +int irq2; +}; + +static inline struct rcar_msi *to_rcar_msi (struct msi_chip *chip) +{ + return container_of(chip, struct rcar_msi, chip); +} +/* Structure representing the PCIe interface */ struct rcar_pcie {struct device *dev;
@@ -48,6 +68,7 @@ struct rcar_pcie {u8 root_bus_nr;struct clk *clk;struct clk *bus_clk; +struct rcar_msi msi; };static inline struct rcar_pcie *sys_to_pcie (struct pci_sys_data *sys)
@@ -292,6 +313,15 @@ static int rcar_pcie_setup(int nr, struct pci_sys_data *sys)return 1 ; } +static void rcar_pcie_add_bus (struct pci_bus *bus) +{ +if (IS_ENABLED (CONFIG_PCI_MSI )) { +struct rcar_pcie *pcie =sys_to_pcie (bus->sysdata); + + bus->msi = &pcie->msi.chip; + } +} +static void __init rcar_pcie_enable (struct rcar_pcie *pcie) {struct platform_device *pdev =to_platform_device (pcie->dev);
@@ -301,6 +331,7 @@ static void __init rcar_pcie_enable(struct rcar_pcie *pcie) .setup = rcar_pcie_setup, .map_irq = of_irq_parse_and_map_pci, .ops = &rcar_pcie_ops, + .add_bus = rcar_pcie_add_bus, };pci_common_init_dev (&pdev->dev, &hw);
@@ -408,6 +439,10 @@ static int __init rcar_pcie_hw_init(struct rcar_pcie *pcie)/* Enable MAC data scrambling. */ rcar_rmw32 (pcie,MACCTLR ,SCRAMBLE_DISABLE ,0 ); +/* Enable MSI */ +if (IS_ENABLED (CONFIG_PCI_MSI )) +pci_write_reg (pcie,0x101f0000 ,PCIEMSITXR ); +/* Finish initialization - establish a PCI Express link */ pci_write_reg (pcie,CFINIT ,PCIETCTLR );
@@ -461,11 +496,194 @@ static int __init rcar_pcie_hw_init_h1(struct rcar_pcie *pcie)return -ETIMEDOUT ; } +static int rcar_msi_alloc (struct rcar_msi *chip) +{ +int msi; + +mutex_lock (&chip->lock); + + msi =find_first_zero_bit (chip->used,INT_PCI_MSI_NR ); +if (msi <INT_PCI_MSI_NR ) +set_bit (msi, chip->used); +else + msi = -ENOSPC ; + +mutex_unlock (&chip->lock); + +return msi; +} + +static void rcar_msi_free (struct rcar_msi *chip,unsigned long irq) +{ +struct device *dev = chip->chip.dev; + +mutex_lock (&chip->lock); + +if (!test_bit (irq, chip->used)) +dev_err (dev,"trying to free unused MSI#%lu\n" , irq); +else +clear_bit (irq, chip->used); + +mutex_unlock (&chip->lock); +} + +static irqreturn_t rcar_pcie_msi_irq (int irq,void *data) +{ +struct rcar_pcie *pcie = data; +struct rcar_msi *msi = &pcie->msi; +unsigned long reg; + + reg =pci_read_reg (pcie,PCIEMSIFR ); + +/* MSI & INTx share an interrupt - we only handle MSI here */ +if (!reg) +return IRQ_NONE ; + +while (reg) { +unsigned int index =find_first_bit (®,32 ); +unsigned int irq; + +/* clear the interrupt */ +pci_write_reg (pcie,1 << index,PCIEMSIFR ); + + irq =irq_find_mapping (msi->domain, index); +if (irq) { +if (test_bit (index, msi->used)) +generic_handle_irq (irq); +else +dev_info (pcie->dev,"unhandled MSI\n" ); + }else { +/* +* that's weird who triggered this? +* just clear it +*/ +dev_info (pcie->dev,"unexpected MSI\n" ); + } + +/* see if there's any more pending in this vector */ + reg =pci_read_reg (pcie,PCIEMSIFR ); + } + +return IRQ_HANDLED ; +} + +static int rcar_msi_setup_irq (struct msi_chip *chip,struct pci_dev *pdev, +struct msi_desc *desc) +{ +struct rcar_msi *msi =to_rcar_msi (chip); + struct rcar_pcie *pcie = container_of(chip, struct rcar_pcie, msi.chip); +struct msi_msg msg; +unsigned int irq; +int hwirq; + + hwirq =rcar_msi_alloc (msi); +if (hwirq <0 ) +return hwirq; + + irq =irq_create_mapping (msi->domain, hwirq); +if (!irq) { +rcar_msi_free (msi, hwirq); +return -EINVAL ; + } + +irq_set_msi_desc (irq, desc); + + msg.address_lo =pci_read_reg (pcie,PCIEMSIALR ) & ~MSIFE ; + msg.address_hi =pci_read_reg (pcie,PCIEMSIAUR ); + msg.data = hwirq; + +write_msi_msg (irq, &msg); + +return 0 ; +} + +static void rcar_msi_teardown_irq (struct msi_chip *chip,unsigned int irq) +{ +struct rcar_msi *msi =to_rcar_msi (chip); +struct irq_data *d =irq_get_irq_data (irq); + +rcar_msi_free (msi, d->hwirq); +} + +static struct irq_chip rcar_msi_irq_chip = { + .name ="R-Car PCIe MSI" , + .irq_enable = unmask_msi_irq, + .irq_disable = mask_msi_irq, + .irq_mask = mask_msi_irq, + .irq_unmask = unmask_msi_irq, +}; + +static int rcar_msi_map (struct irq_domain *domain,unsigned int irq, +irq_hw_number_t hwirq) +{ +irq_set_chip_and_handler (irq, &rcar_msi_irq_chip, handle_simple_irq); +irq_set_chip_data (irq, domain->host_data); +set_irq_flags (irq,IRQF_VALID ); + +return 0 ; +} + +static const struct irq_domain_ops msi_domain_ops = { + .map = rcar_msi_map, +}; + +static int rcar_pcie_enable_msi (struct rcar_pcie *pcie) +{ +struct platform_device *pdev =to_platform_device (pcie->dev); +struct rcar_msi *msi = &pcie->msi; +unsigned long base; +int err; + +mutex_init (&msi->lock); + + msi->chip.dev = pcie->dev; + msi->chip.setup_irq = rcar_msi_setup_irq; + msi->chip.teardown_irq = rcar_msi_teardown_irq; + + msi->domain =irq_domain_add_linear (pcie->dev->of_node,INT_PCI_MSI_NR , + &msi_domain_ops, &msi->chip); +if (!msi->domain) { +dev_err (&pdev->dev,"failed to create IRQ domain\n" ); +return -ENOMEM ; + } + +/* Two irqs are for MSI, but they are also used for non-MSI irqs */ + err =devm_request_irq (&pdev->dev, msi->irq1, rcar_pcie_msi_irq, +IRQF_SHARED , rcar_msi_irq_chip.name, pcie); +if (err <0 ) { +dev_err (&pdev->dev,"failed to request IRQ: %d\n" , err); + goto err; + } + + err =devm_request_irq (&pdev->dev, msi->irq2, rcar_pcie_msi_irq, +IRQF_SHARED , rcar_msi_irq_chip.name, pcie); +if (err <0 ) { +dev_err (&pdev->dev,"failed to request IRQ: %d\n" , err); + goto err; + } + +/* setup MSI data target */ + msi->pages =__get_free_pages (GFP_KERNEL ,0 ); + base =virt_to_phys ((void *)msi->pages); + +pci_write_reg (pcie, base |MSIFE ,PCIEMSIALR ); +pci_write_reg (pcie,0 ,PCIEMSIAUR ); + +/* enable all MSI interrupts */ +pci_write_reg (pcie,0xffffffff ,PCIEMSIIER ); + +return 0 ; + +err: +irq_domain_remove (msi->domain); +return err; +} +static int __init rcar_pcie_get_resources (struct platform_device *pdev,struct rcar_pcie *pcie) {struct resource res; -int err; +int err, i; err =of_address_to_resource (pdev->dev.of_node,0 , &res);if (err)
@@ -490,6 +708,22 @@ static int __init rcar_pcie_get_resources(struct platform_device *pdev,if (err) goto err_map_reg; + i =irq_of_parse_and_map (pdev->dev.of_node,0 ); +if (i <0 ) { +dev_err (pcie->dev,"cannot get platform resources for msi interrupt\n" ); + err = -ENOENT ; + goto err_map_reg; + } + pcie->msi.irq1 = i; + + i =irq_of_parse_and_map (pdev->dev.of_node,1 ); +if (i <0 ) { +dev_err (pcie->dev,"cannot get platform resources for msi interrupt\n" ); + err = -ENOENT ; + goto err_map_reg; + } + pcie->msi.irq2 = i; + pcie->base =devm_ioremap_resource (&pdev->dev, &res);if (IS_ERR (pcie->base)) { err =PTR_ERR (pcie->base);
@@ -657,6 +891,16 @@ static int __init rcar_pcie_probe(struct platform_device *pdev)if (err)return err; +if (IS_ENABLED (CONFIG_PCI_MSI )) { + err =rcar_pcie_enable_msi (pcie); +if (err <0 ) { +dev_err (&pdev->dev, +"failed to enable MSI support: %d\n" , + err); +return err; + } + } + of_id =of_match_device (rcar_pcie_of_match, pcie->dev);if (!of_id || !of_id->data)return -EINVAL ;
drivers/pci/host/pcie-rcar.h +5 -0
@@ -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
PATCH v5 2/9 PCI: host: rcar: Add MSI support
Quoted 5 lines · Phil Edworthy
Signed-off-by Phil Edworthy <[email protected]>---
v5:
- ReturnIRQ_NONEfrom MSI isr when there is no pending MSI
- Add additional interrupt bindings
drivers/pci/host/pcie-rcar.c static int __init rcar_pcie_hw_init_h1(struct rcar_pcie *pcie) · line 523
Quoted 9 lines
drivers/pci/host/pcie-rcar.c +9
-0+ +static void rcar_msi_free (struct rcar_msi *chip,unsigned long irq) +{ +struct device *dev = chip->chip.dev; + +mutex_lock (&chip->lock); + +if (!test_bit (irq, chip->used)) +dev_err (dev,"trying to free unused MSI#%lu\n" , irq);
Does the upper level not check for this?
Quoted 30 lines
drivers/pci/host/pcie-rcar.c +28
-0+else +clear_bit (irq, chip->used); + +mutex_unlock (&chip->lock); +} + +static irqreturn_t rcar_pcie_msi_irq (int irq,void *data) +{ +struct rcar_pcie *pcie = data; +struct rcar_msi *msi = &pcie->msi; +unsigned long reg; + + reg =pci_read_reg (pcie,PCIEMSIFR ); + +/* MSI & INTx share an interrupt - we only handle MSI here */ +if (!reg) +return IRQ_NONE ; + +while (reg) { +unsigned int index =find_first_bit (®,32 ); +unsigned int irq; + +/* clear the interrupt */ +pci_write_reg (pcie,1 << index,PCIEMSIFR ); + + irq =irq_find_mapping (msi->domain, index); +if (irq) { +if (test_bit (index, msi->used))
drivers/pci/host/pcie-rcar.c static int __init rcar_pcie_hw_init_h1(struct rcar_pcie *pcie) · line 561
Quoted 10 lines
drivers/pci/host/pcie-rcar.c +10
-0+generic_handle_irq (irq); + else + dev_info(pcie->dev, "unhandled MSI\n"); + }else { +/* +* that's weird who triggered this? +* just clear it +*/ +dev_info (pcie->dev,"unexpected MSI\n" ); + }
You may want to change this to something that is either rate-limited or is say debug level so it does not spam the console if something does go wrong.
Also the comment could easily be made one line
/* Weird, unknown MSI IRQ, just clear it */
Signature · 2 lines
Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius
PATCH v5 2/9 PCI: host: rcar: Add MSI support
Hi Ben,
Quoted 19 lines · Ben
Subject: Re: [PATCH v5 2/9] PCI: host: rcar: Add MSI support
Quoted 5 lines · Phil Edworthy
Signed-off-by Phil Edworthy <[email protected]>---
v5:
- ReturnIRQ_NONEfrom MSI isr when there is no pending MSI
- Add additional interrupt bindingsdrivers/pci/host/pcie-rcar.c static int __init rcar_pcie_hw_init_h1(struct rcar_pcie *pcie) · line 523
Quoted 9 lines
drivers/pci/host/pcie-rcar.c +9
-0+ +static void rcar_msi_free (struct rcar_msi *chip,unsigned long irq) +{ +struct device *dev = chip->chip.dev; + +mutex_lock (&chip->lock); + +if (!test_bit (irq, chip->used)) +dev_err (dev,"trying to free unused MSI#%lu\n" , irq);Does the upper level not check for this?
Yes, the default_teardown_msi_irqs function checks for unused MSIs, so we don't really need to check here.
Quoted 36 lines
Quoted 36 lines
drivers/pci/host/pcie-rcar.c +34
-0+else +clear_bit (irq, chip->used); + +mutex_unlock (&chip->lock); +} + +static irqreturn_t rcar_pcie_msi_irq (int irq,void *data) +{ +struct rcar_pcie *pcie = data; +struct rcar_msi *msi = &pcie->msi; +unsigned long reg; + + reg =pci_read_reg (pcie,PCIEMSIFR ); + +/* MSI & INTx share an interrupt - we only handle MSI here */ +if (!reg) +return IRQ_NONE ; + +while (reg) { +unsigned int index =find_first_bit (®,32 ); +unsigned int irq; + +/* clear the interrupt */ +pci_write_reg (pcie,1 << index,PCIEMSIFR ); + + irq =irq_find_mapping (msi->domain, index); +if (irq) { +if (test_bit (index, msi->used)) +generic_handle_irq (irq); +else +dev_info (pcie->dev,"unhandled MSI\n" ); + }else { +/* +* that's weird who triggered this?
Quoted 8 lines
drivers/pci/host/pcie-rcar.c static int __init rcar_pcie_hw_init_h1(struct rcar_pcie *pcie) · line 561
Quoted 4 lines
drivers/pci/host/pcie-rcar.c +4
-0+* just clear it +*/ +dev_info (pcie->dev,"unexpected MSI\n" ); + }You may want to change this to something that is either rate-limited or is say debug level so it does not spam the console if something does go wrong.
I'll change that to debug level.
Quoted 2 lines
Also the comment could easily be made one line
/* Weird, unknown MSI IRQ, just clear it */
Sure!
Thanks
Phil
PATCH v5 3/9 ARM: shmobile: r8a7790: Add PCIe clock device tree nodes
In reply to Phil EdworthyThis 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
@@ -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
@@ -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
PATCH v5 4/9 ARM: shmobile: r8a7791: Add PCIe clock device tree nodes
In reply to Phil EdworthyThis 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
@@ -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
@@ -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
PATCH v5 5/9 dt-bindings: pci: rcar pcie device tree bindings
In reply to Phil EdworthyThis patch adds the bindings for the R-Car PCIe driver. The driver resides under drivers/pci/host/pcie-rcar.c
---
v5:
- Add PCIe bus clock reference
- Add additional interrupt bindings
- Use dma-ranges property to specify inbound memory regions
--- Documentation/devicetree/bindings/pci/rcar-pci.txt | 44 ++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/rcar-pci.txt
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +44 -0
@@ -0,0 +1,44 @@ +* Renesas RCar PCIe interface + +Required properties: +- compatible: should contain one of the following + "renesas,pcie-r8a7779", "renesas,pcie-r8a7790", "renesas,pcie-r8a7791" +- reg: base addresses and lengths of the pcie controller. +- #address-cells: set to <3> +- #size-cells: set to <2> +- device_type: set to "pci" +- ranges: ranges for the PCI memory and I/O regions. +- dma-ranges: ranges for the inbound memory regions. +- interrupts: two interrupt sources for MSI interrupts, followed by interrupt + source for hardware related interrupts (e.g. link speed change). +- #interrupt-cells: set to <1> +- interrupt-map-mask and interrupt-map: standard PCI properties + to define the mapping of the PCIe interface to interrupt + numbers. +- clocks: from common clock binding: handle to pci clock. +- clock-names: from common clock binding: should be "pcie" and "pcie_bus". + +Example: + +SoC specific DT Entry: + + pcie: pcie at fe000000 { + compatible = "renesas,pcie-r8a7791"; + reg = <0 0xfe000000 0 0x80000>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000 + 0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000 + 0x02000000 0 0x30000000 0 0x30000000 0 0x08000000 + 0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>; + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000 + 0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>; + interrupts = <0 116 4 0 117 4 0 118 4>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic 0 116 4>; + clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>; + clock-names = "pcie", "pcie_bus"; + status = "disabled"; + };
Signature · 1 line
1.9.0
PATCH v5 5/9 dt-bindings: pci: rcar pcie device tree bindings
Hello.
Quoted 20 lines · Phil Edworthy
This patch adds the bindings for the R-Car PCIe driver. The driver resides under
drivers/pci/host/pcie-rcar.cSigned-off-by Phil Edworthy <[email protected]>---
v5:
- Add PCIe bus clock reference
- Add additional interrupt bindings
- Use dma-ranges property to specify inbound memory regions--- Documentation/devicetree/bindings/pci/rcar-pci.txt | 44 ++++++++++++++++++++++ 1 file changed, 44 insertions(+)create mode 100644
Documentation/devicetree/bindings/pci/rcar-pci.txtDocumentation/devicetree/bindings/pci/rcar-pci.txt new file +0
-0
Documentation/devicetree/bindings/pci/rcar-pci.txt line 6
Quoted 6 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +6
-0@@ -0,0 +1,44 @@ +* Renesas RCar PCIe interface + +Required properties: +- compatible: should contain one of the following + "renesas,pcie-r8a7779", "renesas,pcie-r8a7790", "renesas,pcie-r8a7791" +- reg: base addresses and lengths of the pcie controller.
Hmm, need "registers" at end. And why plural?
Documentation/devicetree/bindings/pci/rcar-pci.txt line 18
Quoted 12 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +12
-0+- #address-cells: set to <3> +- #size-cells: set to <2> +- device_type: set to "pci" +- ranges: ranges for the PCI memory and I/O regions. +- dma-ranges: ranges for the inbound memory regions. +- interrupts: two interrupt sources for MSI interrupts, followed by interrupt + source for hardware related interrupts (e.g. link speed change). +- #interrupt-cells: set to <1> +- interrupt-map-mask and interrupt-map: standard PCI properties + to define the mapping of the PCIe interface to interrupt + numbers. +- clocks: from common clock binding: handle to pci clock.
s/handle/phandle/, s/pci/PCI/.
Actually, it's a clock specifier consisting not only of phandle but also
of clock #. Looking at your example, it's even a pair of clock specifiers.
Quoted 8 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +8
-0+- clock-names: from common clock binding: should be "pcie" and "pcie_bus". + +Example: + +SoC specific DT Entry: + + pcie: pcie@fe000000 { + compatible = "renesas,pcie-r8a7791";
Documentation/devicetree/bindings/pci/rcar-pci.txt line 36
Quoted 10 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +10
-0+ reg = <0 0xfe000000 0 0x80000>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000 + 0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000 + 0x02000000 0 0x30000000 0 0x30000000 0 0x08000000 + 0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>; + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000 + 0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>;
Hmm, this prop looks board-dependent...
Documentation/devicetree/bindings/pci/rcar-pci.txt line 44
Quoted 8 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +8
-0+ interrupts = <0 116 4 0 117 4 0 118 4>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic 0 116 4>; + clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>; + clock-names = "pcie", "pcie_bus"; + status = "disabled"; + };
WBR, Sergei
PATCH v5 5/9 dt-bindings: pci: rcar pcie device tree bindings
Hi Sergei,
Quoted 1 line · Sergei
Subject: Re: [PATCH v5 5/9] dt-bindings: pci: rcar pcie device tree
bindings
Quoted 16 lines
Hello.
Quoted 11 lines · Phil Edworthy
This patch adds the bindings for the R-Car PCIe driver. The driver resides under
drivers/pci/host/pcie-rcar.cSigned-off-by Phil Edworthy <[email protected]>---
v5:
- Add PCIe bus clock reference
- Add additional interrupt bindings
- Use dma-ranges property to specify inbound memory regions--- Documentation/devicetree/bindings/pci/rcar-pci.txt | 44
++++++++++++++++++++++
Quoted 2 lines
Quoted 2 lines
1 file changed, 44 insertions(+)create mode 100644
Documentation/devicetree/bindings/pci/rcar-pci.txt
Quoted 13 lines
Review
Quoted 2 lines
(quoted diff) renamed from Documentation/devicetree/bindings/pci/rcar-pci.txt +0
-0
Documentation/devicetree/bindings/pci/rcar-pci.txtDocumentation/devicetree/bindings/pci/rcar-pci.txt line 5
Quoted 10 lines
new file mode 100644
index 0000000..61bf5efDocumentation/devicetree/bindings/pci/rcar-pci.txt new file +5
-0@@ -0,0 +1,44 @@ +* Renesas RCar PCIe interface + +Required properties: +- compatible: should contain one of the following + "renesas,pcie-r8a7779", "renesas,pcie-r8a7790",
"renesas,pcie-r8a7791"
Quoted 3 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt line 6
Quoted 1 line
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +1
-0+- reg: base addresses and lengths of the pcie controller.Hmm, need "registers" at end. And why plural?
Ok, & yes it should be singular.
Quoted 6 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt
Quoted 6 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +6
-0+- #address-cells: set to <3> +- #size-cells: set to <2> +- device_type: set to "pci" +- ranges: ranges for the PCI memory and I/O regions. +- dma-ranges: ranges for the inbound memory regions. +- interrupts: two interrupt sources for MSI interrupts, followed by
interrupt
Quoted 9 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt line 18
Quoted 6 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +6
-0+ source for hardware related interrupts (e.g. link speed change). +- #interrupt-cells: set to <1> +- interrupt-map-mask and interrupt-map: standard PCI properties + to define the mapping of the PCIe interface to interrupt + numbers. +- clocks: from common clock binding: handle to pci clock.s/handle/phandle/, s/pci/PCI/.
Actually, it's a clock specifier consisting not only of phandle but
also
Quoted 1 line
of clock #. Looking at your example, it's even a pair of clock
specifiers.
Right, and yes it's two clocks - I missed that when adding the PCI bus clock.
Quoted 1 line
Documentation/devicetree/bindings/pci/rcar-pci.txt line 19
Quoted 1 line
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +1
-0+- clock-names: from common clock binding: should be "pcie" and
"pcie_bus".
Quoted 11 lines
Quoted 11 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +11
-0+ +Example: + +SoC specific DT Entry: + + pcie: pcie at fe000000 { + compatible = "renesas,pcie-r8a7791"; + reg = <0 0xfe000000 0 0x80000>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci";
Quoted 8 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt line 36
Quoted 6 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +6
-0+ ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000 + 0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000 + 0x02000000 0 0x30000000 0 0x30000000 0 0x08000000 + 0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>; + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000 + 0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>;Hmm, this prop looks board-dependent...
Initially I thought that it would be board dependent and map the actual DDR available. However, I then considered that it is probably ok to map all possible DDR ranges that the device is capable of using. I'm ok with either approach though...
Quoted 11 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt line 44
Quoted 8 lines
Documentation/devicetree/bindings/pci/rcar-pci.txt new file +8
-0+ interrupts = <0 116 4 0 117 4 0 118 4>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic 0 116 4>; + clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>; + clock-names = "pcie", "pcie_bus"; + status = "disabled"; + };WBR, Sergei
Thanks
Phil
PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790
In reply to Phil EdworthyThis patch adds the device tree nodes for R8A7790
---
v5:
- Renesas SoCs compatible string has peripheral before device name
- Add PCIe bus clock reference
- Add additional interrupt bindings
- Use dma-ranges property to specify inbound memory regions
--- arch/arm/boot/dts/r8a7790-lager.dts | 10 ++++++++++ arch/arm/boot/dts/r8a7790.dtsi | 24 ++++++++++++++++++++++++ 2 files changed, 34 insertions(+)
arch/arm/boot/dts/r8a7790-lager.dts +10 -0
@@ -139,6 +139,16 @@ states = <3300000 1 1800000 0>; }; + + clocks { + /* External PCIe bus clock - not used */ + pcie_bus_clk: pcie_bus_clk { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <0>; + clock-output-names = "pcie_bus"; + }; + }; }; &extal_clk {
arch/arm/boot/dts/r8a7790.dtsi +24 -0
@@ -821,4 +821,28 @@ #size-cells = <0>; status = "disabled"; }; + + pcie: pcie at fe000000 { + compatible = "renesas,pcie-r8a7790"; + reg = <0 0xfe000000 0 0x80000>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000 + 0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000 + 0x02000000 0 0x30000000 0 0x30000000 0 0x08000000 + 0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>; + /* Map all possible DDR as inbound ranges */ + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000 + 0x43000000 1 0x80000000 1 0x80000000 0 0x80000000>; + interrupts = <0 116 IRQ_TYPE_LEVEL_HIGH + 0 117 IRQ_TYPE_LEVEL_HIGH + 0 118 IRQ_TYPE_LEVEL_HIGH>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic 0 116 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp3_clks R8A7790_CLK_PCIE>, <&pcie_bus_clk>; + clock-names = "pcie", "pcie_bus"; + status = "disabled"; + }; };
Signature · 1 line
1.9.0
PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790
arch/arm/boot/dts/r8a7790.dtsi line 837
Quoted 3 lines · On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:
arch/arm/boot/dts/r8a7790.dtsi +3
-0+ /* Map all possible DDR as inbound ranges */ + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000 + 0x43000000 1 0x80000000 1 0x80000000 0 0x80000000>;
Typo: 0x43000000 should be 0x42000000 I guess.
Since you control the mapping, I wonder if you could also do this as
dma-ranges = <0x42000000 0 0x00000000 0 0x40000000 0 0x80000000
0x43000000 0 0x80000000 1 0x80000000 0 0x80000000>;i.e. map all the RAM into PCI bus addresses below the 32-bit boundary. This would be really nice from the perspective that now all PCI devices could access all of RAM without using an IOMMU or the relying on 64-bit master capability.
The downside of this is that you'd probably need a custom dma_map_ops wrapper.
Arnd
PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790
Hi Arnd,
Quoted 1 line · Arnd
Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes
for R8A7790
Quoted 4 lines · On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:
Review
Quoted 2 lines
(quoted diff) +2
-0+ /* Map all possible DDR as inbound ranges */ + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0
0x80000000
Quoted 1 line
Quoted 1 line
+
0x4300000010x8000000010x800000000
0x80000000>;
Quoted 2 lines
Typo:
0x43000000should be0x42000000I guess.
I used 0x43000000 as this is a 64-bit type. The OF PCI range code currently treats both 32 and 64-bit types the same way, but I thought it would be good to set this in case we ever need to use it.
Quoted 3 lines
Since you control the mapping, I wonder if you could also do this as
dma-ranges = <0x42000000 0 0x00000000 0 0x40000000 0
0x80000000
Quoted 1 line
0x43000000 0 0x80000000 1 0x80000000 0
0x80000000>;
Quoted 8 lines
i.e. map all the RAM into PCI bus addresses below the 32-bit boundary. This would be really nice from the perspective that now all PCI devices could access all of RAM without using an IOMMU or the relying on 64-bit master capability.
The downside of this is that you'd probably need a custom
dma_map_opswrapper.
Since the OF PCi range code treats both 32 and 64-bit types the same way, my PCIe driver only creates 64-bit mappings. In addition, the PCIe controller has to use a 64-bit mapping for anything over 2GiB. Based on this, I think it's sensible to leave the mappings as 1-to-1.
Thanks
Phil
PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790
Quoted 9 lines · On Wednesday 26 March 2014 09:55:04 Phil.Edworthy at renesas.com wrote:
Hi Arnd,
Quoted 1 line · Arnd
Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes
for R8A7790
Quoted 4 lines · On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:
Review
Quoted 2 lines
(quoted diff) +2
-0+ /* Map all possible DDR as inbound ranges */ + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0
Quoted 8 lines
0x80000000Quoted 1 line
Quoted 1 line
+
0x4300000010x8000000010x800000000
0x80000000>;Quoted 2 lines
Typo:
0x43000000should be0x42000000I guess.I used
0x43000000as this is a 64-bit type. The OF PCI range code currently treats both 32 and 64-bit types the same way, but I thought it would be good to set this in case we ever need to use it.
Ah, I forgot about the space identifier. It looks correct then, but it seems a little strange to use a 32-bit identifier in one case and a 64-bit one in the other.
Quoted 12 lines
Quoted 3 lines
Since you control the mapping, I wonder if you could also do this as
dma-ranges = <0x42000000 0 0x00000000 0 0x40000000 0
0x80000000Quoted 1 line
0x43000000 0 0x80000000 1 0x80000000 0
0x80000000>;Quoted 6 lines
i.e. map all the RAM into PCI bus addresses below the 32-bit boundary. This would be really nice from the perspective that now all PCI devices could access all of RAM without using an IOMMU or the relying on 64-bit master capability.
Quoted 6 lines
Quoted 2 lines
The downside of this is that you'd probably need a custom
dma_map_opswrapper.Since the OF PCi range code treats both 32 and 64-bit types the same way, my PCIe driver only creates 64-bit mappings. In addition, the PCIe controller has to use a 64-bit mapping for anything over 2GiB. Based on this, I think it's sensible to leave the mappings as 1-to-1.
I'm not following, sorry. What is the hardware requirement in the controller?
Arnd
PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790
Hi Arnd,
Quoted 1 line · Arnd
Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes
for R8A7790
Quoted 6 lines · On Wednesday 26 March 2014 09:55:04 Phil.Edworthy at renesas.com wrote:
Quoted 4 lines
Hi Arnd,
Quoted 1 line · Arnd
Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree
nodes
Quoted 5 lines
Quoted 5 lines
for R8A7790
Quoted 4 lines · On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:
Quoted 2 lines
(quoted diff) +2
-0+ /* Map all possible DDR as inbound ranges */ + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000
0
Quoted 2 lines
Quoted 2 lines
0x80000000Quoted 1 line
Quoted 1 line
+
0x4300000010x8000000010x80000000
0
Quoted 5 lines
Quoted 5 lines
0x80000000>;Quoted 2 lines
Typo:
0x43000000should be0x42000000I guess.I used
0x43000000as this is a 64-bit type. The OF PCI range code currently treats both 32 and 64-bit types the same way, but I thought
it
Quoted 5 lines
Quoted 1 line
would be good to set this in case we ever need to use it.
Ah, I forgot about the space identifier. It looks correct then, but it seems a little strange to use a 32-bit identifier in one case and a 64-bit one in the other.
If the OF PCI range code allowed the PCIe host driver to determine if it's a 32-bit mapping, we could use that and get a small performance improvement with PCIe throughput.
Quoted 8 lines
Quoted 8 lines
Quoted 3 lines
Since you control the mapping, I wonder if you could also do this as
dma-ranges = <0x42000000 0 0x00000000 0 0x40000000 0
0x80000000Quoted 1 line
0x43000000 0 0x80000000 1 0x80000000 0
0x80000000>;Quoted 2 lines
i.e. map all the RAM into PCI bus addresses below the 32-bit
boundary.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
This would be really nice from the perspective that now all PCI devices could access all of RAM without using an IOMMU or the relying on 64-bit master capability.
The downside of this is that you'd probably need a custom
dma_map_ops
Quoted 2 lines
Quoted 2 lines
Quoted 1 line
wrapper.
Since the OF PCi range code treats both 32 and 64-bit types the same
way,
Quoted 2 lines
Quoted 2 lines
my PCIe driver only creates 64-bit mappings. In addition, the PCIe controller has to use a 64-bit mapping for anything over 2GiB. Based
on
Quoted 4 lines
Quoted 1 line
this, I think it's sensible to leave the mappings as 1-to-1.
I'm not following, sorry. What is the hardware requirement in the controller?
With this controller, you can only specify maps whose size are a power of two, and the size must be less than or equal to the cpu address alignment. Further, when the size is 4GiB, you have to use a 64-bit mapping. Thinking about it, the 4GiB case is not relevant to our discussion about 32-bit vs 64-bit mappings.
Still, my comment about the OF PCI range code treating both 32 and 64-bit types the same way means that PCIe host driver has to assume it's a 64-bit mapping.
Thanks
Phil
PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790
Quoted 27 lines · On Wednesday 26 March 2014 11:01:46 Phil.Edworthy at renesas.com wrote:
Quoted 1 line · Arnd
Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes
for R8A7790
Quoted 6 lines · On Wednesday 26 March 2014 09:55:04 Phil.Edworthy at renesas.com wrote:
Quoted 4 lines
Hi Arnd,
Quoted 1 line · Arnd
Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree
nodes
Quoted 5 lines
Quoted 5 lines
for R8A7790
Quoted 4 lines · On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:
Quoted 2 lines
(quoted diff) +2
-0+ /* Map all possible DDR as inbound ranges */ + dma-ranges = <0x42000000 0 0x40000000 0 0x400000000
Quoted 2 lines
Quoted 2 lines
0x80000000Quoted 1 line
Quoted 1 line
+
0x4300000010x8000000010x800000000
Quoted 5 lines
Quoted 5 lines
0x80000000>;Quoted 2 lines
Typo:
0x43000000should be0x42000000I guess.I used
0x43000000as this is a 64-bit type. The OF PCI range code currently treats both 32 and 64-bit types the same way, but I thoughtit
Quoted 2 lines
Quoted 1 line
would be good to set this in case we ever need to use it.
Quoted 7 lines
Quoted 3 lines
Ah, I forgot about the space identifier. It looks correct then, but it seems a little strange to use a 32-bit identifier in one case and a 64-bit one in the other.
If the OF PCI range code allowed the PCIe host driver to determine if it's a 32-bit mapping, we could use that and get a small performance improvement with PCIe throughput.
I don't think it's supposed to care. Soem of the upper bits of the ranges only really make sense of PCI device registers, not for the top-level ranges property. The driver can however still look at the address itself to get that information.
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Since the OF PCi range code treats both 32 and 64-bit types the same
way,
Quoted 2 lines
Quoted 2 lines
my PCIe driver only creates 64-bit mappings. In addition, the PCIe controller has to use a 64-bit mapping for anything over 2GiB. Based
on
Quoted 2 lines
Quoted 1 line
this, I think it's sensible to leave the mappings as 1-to-1.
Quoted 7 lines
Quoted 2 lines
I'm not following, sorry. What is the hardware requirement in the controller?
With this controller, you can only specify maps whose size are a power of two, and the size must be less than or equal to the cpu address alignment. Further, when the size is 4GiB, you have to use a 64-bit mapping. Thinking about it, the 4GiB case is not relevant to our discussion about 32-bit vs 64-bit mappings.
But the ranges you specified in the property don't actually fit in those
constraints: you have a range with size 0x8000000 and start 0x40000000, which you say can't be programmed into the hardware.
Quoted 3 lines
Still, my comment about the OF PCI range code treating both 32 and 64-bit types the same way means that PCIe host driver has to assume it's a 64-bit mapping.
I was thinking more of PCI devices than the host itself. If the host driver can verify that all mappings are in the first 4GB and cover all of RAM, we won't have to use an swiotlb for devices that don't support 64-bit DMA, which is a very significant performance difference.
Arnd
PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790
Hi Arnd,
Quoted 1 line · Arnd
Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes
for R8A7790
Quoted 4 lines · On Wednesday 26 March 2014 11:01:46 Phil.Edworthy at renesas.com wrote:
Quoted 2 lines
Quoted 1 line · Arnd
Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree
nodes
Quoted 5 lines
Quoted 5 lines
for R8A7790
Quoted 4 lines · On Wednesday 26 March 2014 09:55:04 Phil.Edworthy at renesas.com wrote:
Quoted 2 lines
Hi Arnd,
Quoted 8 lines
Quoted 8 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line · Arnd
Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree
nodes
Quoted 5 lines
Quoted 5 lines
for R8A7790
Quoted 4 lines · On Tuesday 25 March 2014 16:56:41 Phil Edworthy wrote:
Quoted 2 lines
(quoted diff) +2
-0+ /* Map all possible DDR as inbound ranges */ + dma-ranges = <0x42000000 0 0x40000000 0
0x40000000
Quoted 3 lines
Quoted 3 lines
0
Quoted 2 lines
Quoted 2 lines
0x80000000Quoted 1 line
Quoted 1 line
+
0x4300000010x800000001
0x80000000
Quoted 6 lines
Quoted 6 lines
0
Quoted 5 lines
Quoted 5 lines
0x80000000>;Quoted 2 lines
Typo:
0x43000000should be0x42000000I guess.I used
0x43000000as this is a 64-bit type. The OF PCI range code currently treats both 32 and 64-bit types the same way, but I
thought
Quoted 8 lines
Quoted 8 lines
it
Quoted 5 lines
Quoted 1 line
would be good to set this in case we ever need to use it.
Ah, I forgot about the space identifier. It looks correct then, but it seems a little strange to use a 32-bit identifier in one case and a 64-bit one in the other.
If the OF PCI range code allowed the PCIe host driver to determine if
it's
Quoted 4 lines
Quoted 2 lines
a 32-bit mapping, we could use that and get a small performance improvement with PCIe throughput.
I don't think it's supposed to care. Soem of the upper bits of the
ranges
Quoted 3 lines
only really make sense of PCI device registers, not for the top-level ranges property. The driver can however still look at the address itself to get that information.
Ah, yes that is a possibility.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Since the OF PCi range code treats both 32 and 64-bit types the
same
Quoted 4 lines
Quoted 4 lines
way,
Quoted 3 lines
Quoted 3 lines
my PCIe driver only creates 64-bit mappings. In addition, the PCIe
controller has to use a 64-bit mapping for anything over 2GiB.
Based
Quoted 6 lines
Quoted 6 lines
on
Quoted 4 lines
Quoted 1 line
this, I think it's sensible to leave the mappings as 1-to-1.
I'm not following, sorry. What is the hardware requirement in the controller?
With this controller, you can only specify maps whose size are a power
of
Quoted 1 line
Quoted 1 line
two, and the size must be less than or equal to the cpu address
alignment.
Quoted 1 line
Quoted 1 line
Further, when the size is 4GiB, you have to use a 64-bit mapping.
Thinking
Quoted 1 line
Quoted 1 line
about it, the 4GiB case is not relevant to our discussion about 32-bit
vs
Quoted 5 lines
Quoted 1 line
64-bit mappings.
But the ranges you specified in the property don't actually fit in those
constraints: you have a range with size0x8000000and start0x40000000, which you say can't be programmed into the hardware.
Actually, the driver checks the dma-ranges against these constraints, and if necessary will create multiple mappings to fulfil the requested dma-ranges.
Quoted 1 line
Quoted 1 line
Still, my comment about the OF PCI range code treating both 32 and
64-bit
Quoted 1 line
Quoted 1 line
types the same way means that PCIe host driver has to assume it's a
64-bit
Quoted 4 lines
Quoted 1 line
mapping.
I was thinking more of PCI devices than the host itself. If the host driver can verify that all mappings are in the first 4GB and cover all
of
Quoted 1 line
RAM, we won't have to use an swiotlb for devices that don't support
64-bit
Quoted 1 line
DMA, which is a very significant performance difference.
Ok, I think I understand. However, all the other PCI host drivers just do 1-to-1 mapping between PCI and CPU addresses, right? Whilst it might be nice be able to support mapping CPU addresses > 4GiB to PCI addresses under 4GiB, can that be something to consider later on?
Thanks
Phil
PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790
Quoted 7 lines · On Wednesday 26 March 2014 11:34:41 Phil.Edworthy at renesas.com wrote:
Quoted 3 lines
But the ranges you specified in the property don't actually fit in those
constraints: you have a range with size0x8000000and start0x40000000, which you say can't be programmed into the hardware.Actually, the driver checks the dma-ranges against these constraints, and if necessary will create multiple mappings to fulfil the requested dma-ranges.
Ok, I didn't notice. My initial suggestion was to not put that logic into the driver but instead specify in the host bridge binding that each entry in the dma-ranges property has to meet the hardware constraints.
As long as you don't have too much complexity to detect this case, I'm fine with it either way.
Quoted 8 lines
Quoted 1 line
Quoted 1 line
Still, my comment about the OF PCI range code treating both 32 and
64-bit
Quoted 1 line
Quoted 1 line
types the same way means that PCIe host driver has to assume it's a
64-bit
Quoted 4 lines
Quoted 1 line
mapping.
I was thinking more of PCI devices than the host itself. If the host driver can verify that all mappings are in the first 4GB and cover all
Quoted 8 lines
of
Quoted 1 line
RAM, we won't have to use an swiotlb for devices that don't support
64-bit
Quoted 1 line
DMA, which is a very significant performance difference.
Ok, I think I understand. However, all the other PCI host drivers just do 1-to-1 mapping between PCI and CPU addresses, right? Whilst it might be nice be able to support mapping CPU addresses > 4GiB to PCI addresses under 4GiB, can that be something to consider later on?
Yes, fair enough. The current version is much simpler, so that's ok. Just keep it in mind if you run into performance problems. Also, note that we don't actually support swiotlb on arm32 yet, so your current code is broken for an PCI DMA master that is not 64-bit capable. We need swiotlb on arm32 anyway, and that will fix this problem, but adding the hack I described would also fix it.
Arnd
PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790
Hi Arnd,
Quoted 1 line · Arnd
Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes
for R8A7790
Quoted 3 lines · On Wednesday 26 March 2014 11:34:41 Phil.Edworthy at renesas.com wrote:
Quoted 1 line
Quoted 1 line
But the ranges you specified in the property don't actually fit in
those
Quoted 1 line
Quoted 1 line
Quoted 1 line
constraints: you have a range with size
0x8000000and start
0x40000000,
Quoted 3 lines
Quoted 3 lines
Quoted 1 line
which you say can't be programmed into the hardware.
Actually, the driver checks the dma-ranges against these constraints,
and
Quoted 9 lines
Quoted 2 lines
if necessary will create multiple mappings to fulfil the requested dma-ranges.
Ok, I didn't notice. My initial suggestion was to not put that logic into the driver but instead specify in the host bridge binding that each entry in the dma-ranges property has to meet the hardware constraints.
As long as you don't have too much complexity to detect this case, I'm fine with it either way.
Ok, good!
Quoted 4 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Still, my comment about the OF PCI range code treating both 32 and
64-bit
Quoted 1 line
Quoted 1 line
types the same way means that PCIe host driver has to assume it's
a
Quoted 5 lines
Quoted 5 lines
64-bit
Quoted 4 lines
Quoted 1 line
mapping.
I was thinking more of PCI devices than the host itself. If the host driver can verify that all mappings are in the first 4GB and cover
all
Quoted 5 lines
Quoted 5 lines
of
Quoted 1 line
RAM, we won't have to use an swiotlb for devices that don't support
64-bit
Quoted 1 line
DMA, which is a very significant performance difference.
Ok, I think I understand. However, all the other PCI host drivers just
do
Quoted 1 line
Quoted 1 line
1-to-1 mapping between PCI and CPU addresses, right? Whilst it might
be
Quoted 9 lines
Quoted 2 lines
nice be able to support mapping CPU addresses > 4GiB to PCI addresses under 4GiB, can that be something to consider later on?
Yes, fair enough. The current version is much simpler, so that's ok. Just keep it in mind if you run into performance problems. Also, note that we don't actually support swiotlb on arm32 yet, so your current code is broken for an PCI DMA master that is not 64-bit capable. We need swiotlb on arm32 anyway, and that will fix this problem, but adding the hack I described would also fix it.
Ok, thanks for all your comments!
Phil
PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790
In reply to Phil EdworthyQuoted 3 lines · Phil Edworthy
This patch adds the device tree nodes for R8A7790
Signed-off-by Phil Edworthy <[email protected]>
Please split this patch into two patches.
1. A patch that updates arch/arm/boot/dts/r8a7790.dtsi
I suggest calling that patch
"ARM: shmobile: r8a7791: Add PCI device nodes"
2. A patch that updates arch/arm/boot/dts/r8a7790-lager.dts
I suggest calling that patch
"ARM: shmobile: lager: Add PCI device nodes"
Quoted 73 lines
---
v5:
- Renesas SoCs compatible string has peripheral before device name
- Add PCIe bus clock reference
- Add additional interrupt bindings
- Use dma-ranges property to specify inbound memory regions--- arch/arm/boot/dts/r8a7790-lager.dts | 10 ++++++++++ arch/arm/boot/dts/r8a7790.dtsi | 24 ++++++++++++++++++++++++ 2 files changed, 34 insertions(+)arch/arm/boot/dts/r8a7790-lager.dts +10
-0@@ -139,6 +139,16 @@ states = <3300000 1 1800000 0>; }; + + clocks { + /* External PCIe bus clock - not used */ + pcie_bus_clk: pcie_bus_clk { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <0>; + clock-output-names = "pcie_bus"; + }; + }; }; &extal_clk {arch/arm/boot/dts/r8a7790.dtsi +24
-0@@ -821,4 +821,28 @@ #size-cells = <0>; status = "disabled"; }; + + pcie: pcie at fe000000 { + compatible = "renesas,pcie-r8a7790"; + reg = <0 0xfe000000 0 0x80000>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000 + 0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000 + 0x02000000 0 0x30000000 0 0x30000000 0 0x08000000 + 0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>; + /* Map all possible DDR as inbound ranges */ + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000 + 0x43000000 1 0x80000000 1 0x80000000 0 0x80000000>; + interrupts = <0 116 IRQ_TYPE_LEVEL_HIGH + 0 117 IRQ_TYPE_LEVEL_HIGH + 0 118 IRQ_TYPE_LEVEL_HIGH>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic 0 116 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp3_clks R8A7790_CLK_PCIE>, <&pcie_bus_clk>; + clock-names = "pcie", "pcie_bus"; + status = "disabled"; + }; };Signature · 6 lines
1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v5 6/9 ARM: shmobile: Add PCIe device tree nodes for R8A7790
Hi Simon,
Quoted 1 line · Simon
Subject: Re: [PATCH v5 6/9] ARM: shmobile: Add PCIe device tree nodes
for R8A7790
Quoted 10 lines · Phil Edworthy
Quoted 3 lines
This patch adds the device tree nodes for R8A7790
Signed-off-by Phil Edworthy <[email protected]>Please split this patch into two patches.
1. A patch that updates
arch/arm/boot/dts/r8a7790.dtsi
Quoted 8 lines
I suggest calling that patch
"ARM: shmobile: r8a7791: Add PCI device nodes"2. A patch that updates
arch/arm/boot/dts/r8a7790-lager.dtsI suggest calling that patch
"ARM: shmobile: lager: Add PCI device nodes"
For this, and your other comments, will do!
Thanks
Phil
PATCH v5 7/9 ARM: shmobile: Add PCIe device tree nodes for R8A7791 Koelsch board
In reply to Phil EdworthyThis patch adds the device tree nodes for the R8A7791 Koelsch board
---
v5:
- Renesas SoCs compatible string has peripheral before device name
- Add PCIe bus clock reference
- Add additional interrupt bindings
- Use dma-ranges property to specify inbound memory regions
--- arch/arm/boot/dts/r8a7791-koelsch.dts | 14 ++++++++++++++ arch/arm/boot/dts/r8a7791.dtsi | 24 ++++++++++++++++++++++++ 2 files changed, 38 insertions(+)
arch/arm/boot/dts/r8a7791-koelsch.dts +14 -0
@@ -204,6 +204,16 @@ states = <3300000 1 1800000 0>; }; + + clocks { + /* External PCIe bus clock */ + pcie_bus_clk: pcie_bus_clk { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <100000000>; + clock-output-names = "pcie_bus"; + }; + }; }; &extal_clk {
@@ -382,3 +392,7 @@ spi-cpha; }; }; + +&pcie { + status = "okay"; +};
arch/arm/boot/dts/r8a7791.dtsi +24 -0
@@ -836,4 +836,28 @@ #size-cells = <0>; status = "disabled"; }; + + pcie: pcie at fe000000 { + compatible = "renesas,pcie-r8a7791"; + reg = <0 0xfe000000 0 0x80000>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000 + 0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000 + 0x02000000 0 0x30000000 0 0x30000000 0 0x08000000 + 0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>; + /* Map all possible DDR as inbound ranges */ + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000 + 0x43000000 2 0x00000000 2 0x00000000 1 0x00000000>; + interrupts = <0 116 IRQ_TYPE_LEVEL_HIGH + 0 117 IRQ_TYPE_LEVEL_HIGH + 0 118 IRQ_TYPE_LEVEL_HIGH>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic 0 116 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>; + clock-names = "pcie", "pcie_bus"; + status = "disabled"; + }; };
Signature · 1 line
1.9.0
PATCH v5 7/9 ARM: shmobile: Add PCIe device tree nodes for R8A7791 Koelsch board
Quoted 1 line · Phil Edworthy
This patch adds the device tree nodes for the R8A7791 Koelsch board
Please split this patch into two patches.
1. A patch that updates arch/arm/boot/dts/r8a7791.dtsi
I suggest calling that patch
"ARM: shmobile: r8a7791: Add PCI device nodes"
2. A patch that updates arch/arm/boot/dts/r8a7791-koelsch.dts
I suggest calling that patch
"ARM: shmobile: koelsch: Add PCI device nodes"
Quoted 82 lines
Signed-off-by Phil Edworthy <[email protected]>---
v5:
- Renesas SoCs compatible string has peripheral before device name
- Add PCIe bus clock reference
- Add additional interrupt bindings
- Use dma-ranges property to specify inbound memory regions--- arch/arm/boot/dts/r8a7791-koelsch.dts | 14 ++++++++++++++ arch/arm/boot/dts/r8a7791.dtsi | 24 ++++++++++++++++++++++++ 2 files changed, 38 insertions(+)arch/arm/boot/dts/r8a7791-koelsch.dts +14
-0@@ -204,6 +204,16 @@ states = <3300000 1 1800000 0>; }; + + clocks { + /* External PCIe bus clock */ + pcie_bus_clk: pcie_bus_clk { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <100000000>; + clock-output-names = "pcie_bus"; + }; + }; }; &extal_clk {@@ -382,3 +392,7 @@ spi-cpha; }; }; + +&pcie { + status = "okay"; +};arch/arm/boot/dts/r8a7791.dtsi +24
-0@@ -836,4 +836,28 @@ #size-cells = <0>; status = "disabled"; }; + + pcie: pcie at fe000000 { + compatible = "renesas,pcie-r8a7791"; + reg = <0 0xfe000000 0 0x80000>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000 + 0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000 + 0x02000000 0 0x30000000 0 0x30000000 0 0x08000000 + 0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>; + /* Map all possible DDR as inbound ranges */ + dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x80000000 + 0x43000000 2 0x00000000 2 0x00000000 1 0x00000000>; + interrupts = <0 116 IRQ_TYPE_LEVEL_HIGH + 0 117 IRQ_TYPE_LEVEL_HIGH + 0 118 IRQ_TYPE_LEVEL_HIGH>; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &gic 0 116 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>; + clock-names = "pcie", "pcie_bus"; + status = "disabled"; + }; };Signature · 6 lines
1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v5 8/9 ARM: koelsch: Add PCIe to defconfig
In reply to Phil Edworthy--- arch/arm/configs/koelsch_defconfig | 3 +++ 1 file changed, 3 insertions(+)
arch/arm/configs/koelsch_defconfig +3 -0
@@ -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
PATCH v5 8/9 ARM: koelsch: Add PCIe to defconfig
Please update the subject of this patch to:
ARM: shmobile: koelsch: Add PCIe to defconfig
Quoted 27 lines · Phil Edworthy
Signed-off-by Phil Edworthy <[email protected]>--- arch/arm/configs/koelsch_defconfig | 3 +++ 1 file changed, 3 insertions(+)arch/arm/configs/koelsch_defconfig +3
-0@@ -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=8Signature · 6 lines
1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH v5 9/9 ARM: koelsch: Add HAVE_ARM_ARCH_TIMER to defconfig
In reply to Phil EdworthyThis 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
@@ -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
PATCH v5 9/9 ARM: koelsch: Add HAVE_ARM_ARCH_TIMER to defconfig
Please update the subject of this patch to:
ARM: shmobile: koelsch: Add HAVE_ARM_ARCH_TIMER to defconfig
Quoted 27 lines · Phil Edworthy
This is fixes a boot problem when the R-Car PCIe driver is enabled.
Signed-off-by Phil Edworthy <[email protected]>--- arch/arm/configs/koelsch_defconfig | 1 + 1 file changed, 1 insertion(+)arch/arm/configs/koelsch_defconfig +1
-0@@ -15,6 +15,7 @@ CONFIG_MACH_KOELSCH=y CONFIG_CPU_BPREDICT_DISABLE=y CONFIG_PL310_ERRATA_588369=y CONFIG_ARM_ERRATA_754322=y +CONFIG_HAVE_ARM_ARCH_TIMER=y CONFIG_PCI=y CONFIG_PCI_MSI=y CONFIG_PCI_RCAR_GEN2_PCIE=ySignature · 6 lines
1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-sh" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Magnus Damm
maintainerPATCH v5 9/9 ARM: koelsch: Add HAVE_ARM_ARCH_TIMER to defconfig
In reply to Phil EdworthyQuoted 12 lines · Phil Edworthy
This is fixes a boot problem when the R-Car PCIe driver is enabled.
Signed-off-by Phil Edworthy <[email protected]>--- arch/arm/configs/koelsch_defconfig | 1 + 1 file changed, 1 insertion(+)arch/arm/configs/koelsch_defconfig +0
-0
arch/arm/configs/koelsch_defconfig CONFIG_MACH_KOELSCH=y · line 18
Quoted 4 lines
arch/arm/configs/koelsch_defconfig +1
-0@@ -15,6 +15,7 @@ CONFIG_MACH_KOELSCH=y CONFIG_CPU_BPREDICT_DISABLE=y CONFIG_PL310_ERRATA_588369=y CONFIG_ARM_ERRATA_754322=y +CONFIG_HAVE_ARM_ARCH_TIMER=y
Hi Phil,
Thanks for your patches! I appreciate that you send out a whole series with broken out patches, that makes it easier to see what is going on.
However, regarding this particular patch I'm not so sure if your fix is correct. The issue is most likely there, no doubt about that, but this "select" does not match well with how we currently handle timers for the rest of the SoCs in mach-shmobile. We for instance want to be able to boot with CMT only.
So here's a gentle "NAK" on this particular patch. I think this shows that either deferred probing or a different init ordering is needed somehow.
Thanks,
/ magnus
PATCH v5 9/9 ARM: koelsch: Add HAVE_ARM_ARCH_TIMER to defconfig
Hi Magnus,
Quoted 1 line · Magnus
Subject: Re: [PATCH v5 9/9] ARM: koelsch: Add
HAVE_ARM_ARCH_TIMERto
defconfig
Quoted 11 lines
Review
Quoted 8 lines · Phil Edworthy
This is fixes a boot problem when the R-Car PCIe driver is enabled.
Signed-off-by Phil Edworthy <[email protected]>--- arch/arm/configs/koelsch_defconfig | 1 + 1 file changed, 1 insertion(+)(quoted diff) +0
-0
b/arch/arm/configs/koelsch_defconfig
Quoted 20 lines
arch/arm/configs/koelsch_defconfig CONFIG_MACH_KOELSCH=y · line 18
Quoted 8 lines
index ec14547..67666b6 100644
arch/arm/configs/koelsch_defconfig +1
-0@@ -15,6 +15,7 @@ CONFIG_MACH_KOELSCH=y CONFIG_CPU_BPREDICT_DISABLE=y CONFIG_PL310_ERRATA_588369=y CONFIG_ARM_ERRATA_754322=y +CONFIG_HAVE_ARM_ARCH_TIMER=yHi Phil,
Thanks for your patches! I appreciate that you send out a whole series with broken out patches, that makes it easier to see what is going on.
However, regarding this particular patch I'm not so sure if your fix is correct. The issue is most likely there, no doubt about that, but this "select" does not match well with how we currently handle timers for the rest of the SoCs in mach-shmobile. We for instance want to be able to boot with CMT only.
Quoted 3 lines
So here's a gentle "NAK" on this particular patch. I think this shows that either deferred probing or a different init ordering is needed somehow.
When reading your comments, I realised that since I changed the driver to use module_platform_driver instead of subsys_initcall, we no longer need this patch.
Thanks
Phil