[PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Vidya Sagar]

PCIe host controller in Tegra SoCs has 1GB of aperture available
for mapping end points config space, IO and BARs. In that, currently
256MB is being reserved for mapping end points configuration space
which leaves less memory space available for mapping end points BARs
on some of the platforms.
This patch series attempts to map only 4K space from 1GB aperture to
access end points configuration space.

Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
to use for BAR mapping) physical space as well as kernel virtual mapping space,
it saves only kernel virtual address space in T30, T124, T132 and T210.

NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
For older platforms (T20, T30, T124, T132, T210), this change works fine without any
DT modifications

Testing Done on T124, T210 & T186:
 Enumeration and basic functionality of immediate devices
 Enumeration of devices behind a PCIe switch
 Complete 4K configuration space access

Vidya Sagar (2):
  PCI: tegra: refactor config space mapping code
  ARM64: tegra: limit PCIe config space mapping to 4K for T186

 arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
 drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
 2 files changed, 44 insertions(+), 89 deletions(-)

-- 
2.7.4

[PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Vidya Sagar]

PCIe host controller in Tegra SoCs has 1GB of aperture available
for mapping end points config space, IO and BARs. In that, currently
256MB is being reserved for mapping end points configuration space
which leaves less memory space available for mapping end points BARs
on some of the platforms.
This patch series attempts to map only 4K space from 1GB aperture to
access end points configuration space.

Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
to use for BAR mapping) physical space as well as kernel virtual mapping space,
it saves only kernel virtual address space in T30, T124, T132 and T210.

NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
For older platforms (T20, T30, T124, T132, T210), this change works fine without any
DT modifications

Testing Done on T124, T210 & T186:
 Enumeration and basic functionality of immediate devices
 Enumeration of devices behind a PCIe switch
 Complete 4K configuration space access

Vidya Sagar (2):
  PCI: tegra: refactor config space mapping code
  ARM64: tegra: limit PCIe config space mapping to 4K for T186

 arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
 drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
 2 files changed, 44 insertions(+), 89 deletions(-)

-- 
2.7.4

[PATCH V3 1/2] PCI: tegra: refactor config space mapping code

[Vidya Sagar]

use only 4K space from available 1GB PCIe aperture to access
end points configuration space by dynamically moving AFI_AXI_BAR
base address and always making sure that the desired location
to be accessed for generating required config space access falls
in the 4K space reserved for this purpose. This would give more
space for mapping end point device's BARs on some of Tegra platforms

Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
---
V3:
* added a new soc_data entry 'use_4k_conf_space' to decide whether to use first 4K chunk (T20, T186)
* or last 4K chunk (T30, T124, T132 and T210) of the available 256MB region
V2:
* restored tegra_pcie_conf_offset() after extending it to include bus number
* removed tegra_pcie_bus_alloc() and merged some of its contents with tegra_pcie_add_bus()
* replaced ioremap() with devm_ioremap()

 drivers/pci/host/pci-tegra.c | 125 ++++++++++++++-----------------------------
 1 file changed, 40 insertions(+), 85 deletions(-)

diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index af8b05614f87..aac484518fb8 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -257,6 +257,7 @@ struct tegra_pcie_soc {
 	bool has_gen2;
 	bool force_pca_enable;
 	bool program_uphy;
+	bool use_4k_conf_space;
 };
 
 static inline struct tegra_msi *to_tegra_msi(struct msi_controller *chip)
@@ -274,6 +275,8 @@ struct tegra_pcie {
 	struct list_head buses;
 	struct resource *cs;
 
+	void __iomem *cfg_va_base;
+
 	struct resource io;
 	struct resource pio;
 	struct resource mem;
@@ -322,7 +325,6 @@ struct tegra_pcie_port {
 };
 
 struct tegra_pcie_bus {
-	struct vm_struct *area;
 	struct list_head list;
 	unsigned int nr;
 };
@@ -362,69 +364,17 @@ static inline u32 pads_readl(struct tegra_pcie *pcie, unsigned long offset)
  *
  * Mapping the whole extended configuration space would require 256 MiB of
  * virtual address space, only a small part of which will actually be used.
- * To work around this, a 1 MiB of virtual addresses are allocated per bus
- * when the bus is first accessed. When the physical range is mapped, the
- * the bus number bits are hidden so that the extended register number bits
- * appear as bits [19:16]. Therefore the virtual mapping looks like this:
- *
- *    [19:16] extended register number
- *    [15:11] device number
- *    [10: 8] function number
- *    [ 7: 0] register number
- *
- * This is achieved by stitching together 16 chunks of 64 KiB of physical
- * address space via the MMU.
+ * To work around this, a 4K of region is used to generate required
+ * configuration transaction with relevant B:D:F values. This is achieved by
+ * dynamically programming base address and size of AFI_AXI_BAR used for
+ * end point config space mapping to make sure that the address (access to
+ * which generates correct config transaction) falls in this 4K region
  */
-static unsigned long tegra_pcie_conf_offset(unsigned int devfn, int where)
-{
-	return ((where & 0xf00) << 8) | (PCI_SLOT(devfn) << 11) |
-	       (PCI_FUNC(devfn) << 8) | (where & 0xfc);
-}
-
-static struct tegra_pcie_bus *tegra_pcie_bus_alloc(struct tegra_pcie *pcie,
-						   unsigned int busnr)
+static unsigned long tegra_pcie_conf_offset(unsigned char b, unsigned int devfn,
+					    int where)
 {
-	struct device *dev = pcie->dev;
-	pgprot_t prot = pgprot_noncached(PAGE_KERNEL);
-	phys_addr_t cs = pcie->cs->start;
-	struct tegra_pcie_bus *bus;
-	unsigned int i;
-	int err;
-
-	bus = kzalloc(sizeof(*bus), GFP_KERNEL);
-	if (!bus)
-		return ERR_PTR(-ENOMEM);
-
-	INIT_LIST_HEAD(&bus->list);
-	bus->nr = busnr;
-
-	/* allocate 1 MiB of virtual addresses */
-	bus->area = get_vm_area(SZ_1M, VM_IOREMAP);
-	if (!bus->area) {
-		err = -ENOMEM;
-		goto free;
-	}
-
-	/* map each of the 16 chunks of 64 KiB each */
-	for (i = 0; i < 16; i++) {
-		unsigned long virt = (unsigned long)bus->area->addr +
-				     i * SZ_64K;
-		phys_addr_t phys = cs + i * SZ_16M + busnr * SZ_64K;
-
-		err = ioremap_page_range(virt, virt + SZ_64K, phys, prot);
-		if (err < 0) {
-			dev_err(dev, "ioremap_page_range() failed: %d\n", err);
-			goto unmap;
-		}
-	}
-
-	return bus;
-
-unmap:
-	vunmap(bus->area->addr);
-free:
-	kfree(bus);
-	return ERR_PTR(err);
+	return (b << 16) | (PCI_SLOT(devfn) << 11) | (PCI_FUNC(devfn) << 8) |
+	       (((where & 0xf00) >> 8) << 24) | (where & 0xff);
 }
 
 static int tegra_pcie_add_bus(struct pci_bus *bus)
@@ -433,10 +383,13 @@ static int tegra_pcie_add_bus(struct pci_bus *bus)
 	struct tegra_pcie *pcie = pci_host_bridge_priv(host);
 	struct tegra_pcie_bus *b;
 
-	b = tegra_pcie_bus_alloc(pcie, bus->number);
-	if (IS_ERR(b))
+	b = kzalloc(sizeof(*b), GFP_KERNEL);
+	if (!b)
 		return PTR_ERR(b);
 
+	INIT_LIST_HEAD(&b->list);
+	b->nr = bus->number;
+
 	list_add_tail(&b->list, &pcie->buses);
 
 	return 0;
@@ -450,7 +403,6 @@ static void tegra_pcie_remove_bus(struct pci_bus *child)
 
 	list_for_each_entry_safe(bus, tmp, &pcie->buses, list) {
 		if (bus->nr == child->number) {
-			vunmap(bus->area->addr);
 			list_del(&bus->list);
 			kfree(bus);
 			break;
@@ -464,8 +416,9 @@ static void __iomem *tegra_pcie_map_bus(struct pci_bus *bus,
 {
 	struct pci_host_bridge *host = pci_find_host_bridge(bus);
 	struct tegra_pcie *pcie = pci_host_bridge_priv(host);
-	struct device *dev = pcie->dev;
 	void __iomem *addr = NULL;
+	u32 val = 0;
+	u32 offset = 0;
 
 	if (bus->number == 0) {
 		unsigned int slot = PCI_SLOT(devfn);
@@ -478,19 +431,11 @@ static void __iomem *tegra_pcie_map_bus(struct pci_bus *bus,
 			}
 		}
 	} else {
-		struct tegra_pcie_bus *b;
-
-		list_for_each_entry(b, &pcie->buses, list)
-			if (b->nr == bus->number)
-				addr = (void __iomem *)b->area->addr;
-
-		if (!addr) {
-			dev_err(dev, "failed to map cfg. space for bus %u\n",
-				bus->number);
-			return NULL;
-		}
-
-		addr += tegra_pcie_conf_offset(devfn, where);
+		offset = tegra_pcie_conf_offset(bus->number, devfn, where);
+		addr = pcie->cfg_va_base + (offset & (SZ_4K - 1));
+		val = offset & ~(SZ_4K - 1);
+		afi_writel(pcie, pcie->cs->start - val, AFI_AXI_BAR0_START);
+		afi_writel(pcie, (val + SZ_4K) >> 12, AFI_AXI_BAR0_SZ);
 	}
 
 	return addr;
@@ -724,10 +669,6 @@ static void tegra_pcie_setup_translations(struct tegra_pcie *pcie)
 
 	/* Bar 0: type 1 extended configuration space */
 	fpci_bar = 0xfe100000;
-	size = resource_size(pcie->cs);
-	axi_address = pcie->cs->start;
-	afi_writel(pcie, axi_address, AFI_AXI_BAR0_START);
-	afi_writel(pcie, size >> 12, AFI_AXI_BAR0_SZ);
 	afi_writel(pcie, fpci_bar, AFI_FPCI_BAR0);
 
 	/* Bar 1: downstream IO bar */
@@ -1284,6 +1225,7 @@ static int tegra_pcie_get_resources(struct tegra_pcie *pcie)
 	struct platform_device *pdev = to_platform_device(dev);
 	struct resource *pads, *afi, *res;
 	const struct tegra_pcie_soc *soc = pcie->soc;
+	u32 axi_addr = 0;
 	int err;
 
 	err = tegra_pcie_clocks_get(pcie);
@@ -1333,13 +1275,21 @@ static int tegra_pcie_get_resources(struct tegra_pcie *pcie)
 		goto poweroff;
 	}
 
-	pcie->cs = devm_request_mem_region(dev, res->start,
-					   resource_size(res), res->name);
+	axi_addr = pcie->soc->use_4k_conf_space ?
+		   res->start : res->end - SZ_4K + 1;
+	pcie->cs = devm_request_mem_region(dev, axi_addr, SZ_4K, res->name);
 	if (!pcie->cs) {
 		err = -EADDRNOTAVAIL;
 		goto poweroff;
 	}
 
+	pcie->cfg_va_base = devm_ioremap(dev, pcie->cs->start, SZ_4K);
+	if (!pcie->cfg_va_base) {
+		dev_err(pcie->dev, "failed to ioremap config space\n");
+		err = -EADDRNOTAVAIL;
+		goto poweroff;
+	}
+
 	/* request interrupt */
 	err = platform_get_irq_byname(pdev, "intr");
 	if (err < 0) {
@@ -2130,6 +2080,7 @@ static const struct tegra_pcie_soc tegra20_pcie = {
 	.has_gen2 = false,
 	.force_pca_enable = false,
 	.program_uphy = true,
+	.use_4k_conf_space = true,
 };
 
 static const struct tegra_pcie_soc tegra30_pcie = {
@@ -2146,6 +2097,7 @@ static const struct tegra_pcie_soc tegra30_pcie = {
 	.has_gen2 = false,
 	.force_pca_enable = false,
 	.program_uphy = true,
+	.use_4k_conf_space = false,
 };
 
 static const struct tegra_pcie_soc tegra124_pcie = {
@@ -2161,6 +2113,7 @@ static const struct tegra_pcie_soc tegra124_pcie = {
 	.has_gen2 = true,
 	.force_pca_enable = false,
 	.program_uphy = true,
+	.use_4k_conf_space = false,
 };
 
 static const struct tegra_pcie_soc tegra210_pcie = {
@@ -2176,6 +2129,7 @@ static const struct tegra_pcie_soc tegra210_pcie = {
 	.has_gen2 = true,
 	.force_pca_enable = true,
 	.program_uphy = true,
+	.use_4k_conf_space = false,
 };
 
 static const struct tegra_pcie_soc tegra186_pcie = {
@@ -2192,6 +2146,7 @@ static const struct tegra_pcie_soc tegra186_pcie = {
 	.has_gen2 = true,
 	.force_pca_enable = false,
 	.program_uphy = false,
+	.use_4k_conf_space = true,
 };
 
 static const struct of_device_id tegra_pcie_of_match[] = {
-- 
2.7.4

[PATCH V3 1/2] PCI: tegra: refactor config space mapping code

[Vidya Sagar]

use only 4K space from available 1GB PCIe aperture to access
end points configuration space by dynamically moving AFI_AXI_BAR
base address and always making sure that the desired location
to be accessed for generating required config space access falls
in the 4K space reserved for this purpose. This would give more
space for mapping end point device's BARs on some of Tegra platforms

Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
---
V3:
* added a new soc_data entry 'use_4k_conf_space' to decide whether to use first 4K chunk (T20, T186)
* or last 4K chunk (T30, T124, T132 and T210) of the available 256MB region
V2:
* restored tegra_pcie_conf_offset() after extending it to include bus number
* removed tegra_pcie_bus_alloc() and merged some of its contents with tegra_pcie_add_bus()
* replaced ioremap() with devm_ioremap()

 drivers/pci/host/pci-tegra.c | 125 ++++++++++++++-----------------------------
 1 file changed, 40 insertions(+), 85 deletions(-)

diff --git a/drivers/pci/host/pci-tegra.c b/drivers/pci/host/pci-tegra.c
index af8b05614f87..aac484518fb8 100644
--- a/drivers/pci/host/pci-tegra.c
+++ b/drivers/pci/host/pci-tegra.c
@@ -257,6 +257,7 @@ struct tegra_pcie_soc {
 	bool has_gen2;
 	bool force_pca_enable;
 	bool program_uphy;
+	bool use_4k_conf_space;
 };
 
 static inline struct tegra_msi *to_tegra_msi(struct msi_controller *chip)
@@ -274,6 +275,8 @@ struct tegra_pcie {
 	struct list_head buses;
 	struct resource *cs;
 
+	void __iomem *cfg_va_base;
+
 	struct resource io;
 	struct resource pio;
 	struct resource mem;
@@ -322,7 +325,6 @@ struct tegra_pcie_port {
 };
 
 struct tegra_pcie_bus {
-	struct vm_struct *area;
 	struct list_head list;
 	unsigned int nr;
 };
@@ -362,69 +364,17 @@ static inline u32 pads_readl(struct tegra_pcie *pcie, unsigned long offset)
  *
  * Mapping the whole extended configuration space would require 256 MiB of
  * virtual address space, only a small part of which will actually be used.
- * To work around this, a 1 MiB of virtual addresses are allocated per bus
- * when the bus is first accessed. When the physical range is mapped, the
- * the bus number bits are hidden so that the extended register number bits
- * appear as bits [19:16]. Therefore the virtual mapping looks like this:
- *
- *    [19:16] extended register number
- *    [15:11] device number
- *    [10: 8] function number
- *    [ 7: 0] register number
- *
- * This is achieved by stitching together 16 chunks of 64 KiB of physical
- * address space via the MMU.
+ * To work around this, a 4K of region is used to generate required
+ * configuration transaction with relevant B:D:F values. This is achieved by
+ * dynamically programming base address and size of AFI_AXI_BAR used for
+ * end point config space mapping to make sure that the address (access to
+ * which generates correct config transaction) falls in this 4K region
  */
-static unsigned long tegra_pcie_conf_offset(unsigned int devfn, int where)
-{
-	return ((where & 0xf00) << 8) | (PCI_SLOT(devfn) << 11) |
-	       (PCI_FUNC(devfn) << 8) | (where & 0xfc);
-}
-
-static struct tegra_pcie_bus *tegra_pcie_bus_alloc(struct tegra_pcie *pcie,
-						   unsigned int busnr)
+static unsigned long tegra_pcie_conf_offset(unsigned char b, unsigned int devfn,
+					    int where)
 {
-	struct device *dev = pcie->dev;
-	pgprot_t prot = pgprot_noncached(PAGE_KERNEL);
-	phys_addr_t cs = pcie->cs->start;
-	struct tegra_pcie_bus *bus;
-	unsigned int i;
-	int err;
-
-	bus = kzalloc(sizeof(*bus), GFP_KERNEL);
-	if (!bus)
-		return ERR_PTR(-ENOMEM);
-
-	INIT_LIST_HEAD(&bus->list);
-	bus->nr = busnr;
-
-	/* allocate 1 MiB of virtual addresses */
-	bus->area = get_vm_area(SZ_1M, VM_IOREMAP);
-	if (!bus->area) {
-		err = -ENOMEM;
-		goto free;
-	}
-
-	/* map each of the 16 chunks of 64 KiB each */
-	for (i = 0; i < 16; i++) {
-		unsigned long virt = (unsigned long)bus->area->addr +
-				     i * SZ_64K;
-		phys_addr_t phys = cs + i * SZ_16M + busnr * SZ_64K;
-
-		err = ioremap_page_range(virt, virt + SZ_64K, phys, prot);
-		if (err < 0) {
-			dev_err(dev, "ioremap_page_range() failed: %d\n", err);
-			goto unmap;
-		}
-	}
-
-	return bus;
-
-unmap:
-	vunmap(bus->area->addr);
-free:
-	kfree(bus);
-	return ERR_PTR(err);
+	return (b << 16) | (PCI_SLOT(devfn) << 11) | (PCI_FUNC(devfn) << 8) |
+	       (((where & 0xf00) >> 8) << 24) | (where & 0xff);
 }
 
 static int tegra_pcie_add_bus(struct pci_bus *bus)
@@ -433,10 +383,13 @@ static int tegra_pcie_add_bus(struct pci_bus *bus)
 	struct tegra_pcie *pcie = pci_host_bridge_priv(host);
 	struct tegra_pcie_bus *b;
 
-	b = tegra_pcie_bus_alloc(pcie, bus->number);
-	if (IS_ERR(b))
+	b = kzalloc(sizeof(*b), GFP_KERNEL);
+	if (!b)
 		return PTR_ERR(b);
 
+	INIT_LIST_HEAD(&b->list);
+	b->nr = bus->number;
+
 	list_add_tail(&b->list, &pcie->buses);
 
 	return 0;
@@ -450,7 +403,6 @@ static void tegra_pcie_remove_bus(struct pci_bus *child)
 
 	list_for_each_entry_safe(bus, tmp, &pcie->buses, list) {
 		if (bus->nr == child->number) {
-			vunmap(bus->area->addr);
 			list_del(&bus->list);
 			kfree(bus);
 			break;
@@ -464,8 +416,9 @@ static void __iomem *tegra_pcie_map_bus(struct pci_bus *bus,
 {
 	struct pci_host_bridge *host = pci_find_host_bridge(bus);
 	struct tegra_pcie *pcie = pci_host_bridge_priv(host);
-	struct device *dev = pcie->dev;
 	void __iomem *addr = NULL;
+	u32 val = 0;
+	u32 offset = 0;
 
 	if (bus->number == 0) {
 		unsigned int slot = PCI_SLOT(devfn);
@@ -478,19 +431,11 @@ static void __iomem *tegra_pcie_map_bus(struct pci_bus *bus,
 			}
 		}
 	} else {
-		struct tegra_pcie_bus *b;
-
-		list_for_each_entry(b, &pcie->buses, list)
-			if (b->nr == bus->number)
-				addr = (void __iomem *)b->area->addr;
-
-		if (!addr) {
-			dev_err(dev, "failed to map cfg. space for bus %u\n",
-				bus->number);
-			return NULL;
-		}
-
-		addr += tegra_pcie_conf_offset(devfn, where);
+		offset = tegra_pcie_conf_offset(bus->number, devfn, where);
+		addr = pcie->cfg_va_base + (offset & (SZ_4K - 1));
+		val = offset & ~(SZ_4K - 1);
+		afi_writel(pcie, pcie->cs->start - val, AFI_AXI_BAR0_START);
+		afi_writel(pcie, (val + SZ_4K) >> 12, AFI_AXI_BAR0_SZ);
 	}
 
 	return addr;
@@ -724,10 +669,6 @@ static void tegra_pcie_setup_translations(struct tegra_pcie *pcie)
 
 	/* Bar 0: type 1 extended configuration space */
 	fpci_bar = 0xfe100000;
-	size = resource_size(pcie->cs);
-	axi_address = pcie->cs->start;
-	afi_writel(pcie, axi_address, AFI_AXI_BAR0_START);
-	afi_writel(pcie, size >> 12, AFI_AXI_BAR0_SZ);
 	afi_writel(pcie, fpci_bar, AFI_FPCI_BAR0);
 
 	/* Bar 1: downstream IO bar */
@@ -1284,6 +1225,7 @@ static int tegra_pcie_get_resources(struct tegra_pcie *pcie)
 	struct platform_device *pdev = to_platform_device(dev);
 	struct resource *pads, *afi, *res;
 	const struct tegra_pcie_soc *soc = pcie->soc;
+	u32 axi_addr = 0;
 	int err;
 
 	err = tegra_pcie_clocks_get(pcie);
@@ -1333,13 +1275,21 @@ static int tegra_pcie_get_resources(struct tegra_pcie *pcie)
 		goto poweroff;
 	}
 
-	pcie->cs = devm_request_mem_region(dev, res->start,
-					   resource_size(res), res->name);
+	axi_addr = pcie->soc->use_4k_conf_space ?
+		   res->start : res->end - SZ_4K + 1;
+	pcie->cs = devm_request_mem_region(dev, axi_addr, SZ_4K, res->name);
 	if (!pcie->cs) {
 		err = -EADDRNOTAVAIL;
 		goto poweroff;
 	}
 
+	pcie->cfg_va_base = devm_ioremap(dev, pcie->cs->start, SZ_4K);
+	if (!pcie->cfg_va_base) {
+		dev_err(pcie->dev, "failed to ioremap config space\n");
+		err = -EADDRNOTAVAIL;
+		goto poweroff;
+	}
+
 	/* request interrupt */
 	err = platform_get_irq_byname(pdev, "intr");
 	if (err < 0) {
@@ -2130,6 +2080,7 @@ static const struct tegra_pcie_soc tegra20_pcie = {
 	.has_gen2 = false,
 	.force_pca_enable = false,
 	.program_uphy = true,
+	.use_4k_conf_space = true,
 };
 
 static const struct tegra_pcie_soc tegra30_pcie = {
@@ -2146,6 +2097,7 @@ static const struct tegra_pcie_soc tegra30_pcie = {
 	.has_gen2 = false,
 	.force_pca_enable = false,
 	.program_uphy = true,
+	.use_4k_conf_space = false,
 };
 
 static const struct tegra_pcie_soc tegra124_pcie = {
@@ -2161,6 +2113,7 @@ static const struct tegra_pcie_soc tegra124_pcie = {
 	.has_gen2 = true,
 	.force_pca_enable = false,
 	.program_uphy = true,
+	.use_4k_conf_space = false,
 };
 
 static const struct tegra_pcie_soc tegra210_pcie = {
@@ -2176,6 +2129,7 @@ static const struct tegra_pcie_soc tegra210_pcie = {
 	.has_gen2 = true,
 	.force_pca_enable = true,
 	.program_uphy = true,
+	.use_4k_conf_space = false,
 };
 
 static const struct tegra_pcie_soc tegra186_pcie = {
@@ -2192,6 +2146,7 @@ static const struct tegra_pcie_soc tegra186_pcie = {
 	.has_gen2 = true,
 	.force_pca_enable = false,
 	.program_uphy = false,
+	.use_4k_conf_space = true,
 };
 
 static const struct of_device_id tegra_pcie_of_match[] = {
-- 
2.7.4

[PATCH V3 2/2] ARM64: tegra: limit PCIe config space mapping to 4K for T186

[Vidya Sagar]

reduces PCIe config space mapping size from its current 256MB
to 4K to have only 4K of virtual memory mapping and to be
in line with driver implementation

Signed-off-by: Vidya Sagar <vidyas-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
V3:
* no change in this patch

 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 7c3a2bdd4644..c64550c32d72 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -361,7 +361,7 @@
 		device_type = "pci";
 		reg = <0x0 0x10003000 0x0 0x00000800   /* PADS registers */
 		       0x0 0x10003800 0x0 0x00000800   /* AFI registers */
-		       0x0 0x40000000 0x0 0x10000000>; /* configuration space */
+		       0x0 0x40000000 0x0 0x00001000>; /* configuration space */
 		reg-names = "pads", "afi", "cs";
 
 		interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */
@@ -379,9 +379,9 @@
 		ranges = <0x82000000 0 0x10000000 0x0 0x10000000 0 0x00001000   /* port 0 configuration space */
 			  0x82000000 0 0x10001000 0x0 0x10001000 0 0x00001000   /* port 1 configuration space */
 			  0x82000000 0 0x10004000 0x0 0x10004000 0 0x00001000   /* port 2 configuration space */
-			  0x81000000 0 0x0        0x0 0x50000000 0 0x00010000   /* downstream I/O (64 KiB) */
-			  0x82000000 0 0x50100000 0x0 0x50100000 0 0x07F00000   /* non-prefetchable memory (127 MiB) */
-			  0xc2000000 0 0x58000000 0x0 0x58000000 0 0x28000000>; /* prefetchable memory (640 MiB) */
+			  0x81000000 0 0x0        0x0 0x40001000 0 0x00010000   /* downstream I/O (64 KiB) */
+			  0x82000000 0 0x40100000 0x0 0x40100000 0 0x07F00000   /* non-prefetchable memory (127 MiB) */
+			  0xc2000000 0 0x48000000 0x0 0x48000000 0 0x38000000>; /* prefetchable memory (896 MiB) */
 
 		clocks = <&bpmp TEGRA186_CLK_AFI>,
 			 <&bpmp TEGRA186_CLK_PCIE>,
-- 
2.7.4

[PATCH V3 2/2] ARM64: tegra: limit PCIe config space mapping to 4K for T186

[Vidya Sagar]

reduces PCIe config space mapping size from its current 256MB
to 4K to have only 4K of virtual memory mapping and to be
in line with driver implementation

Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
---
V3:
* no change in this patch

 arch/arm64/boot/dts/nvidia/tegra186.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 7c3a2bdd4644..c64550c32d72 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -361,7 +361,7 @@
 		device_type = "pci";
 		reg = <0x0 0x10003000 0x0 0x00000800   /* PADS registers */
 		       0x0 0x10003800 0x0 0x00000800   /* AFI registers */
-		       0x0 0x40000000 0x0 0x10000000>; /* configuration space */
+		       0x0 0x40000000 0x0 0x00001000>; /* configuration space */
 		reg-names = "pads", "afi", "cs";
 
 		interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>, /* controller interrupt */
@@ -379,9 +379,9 @@
 		ranges = <0x82000000 0 0x10000000 0x0 0x10000000 0 0x00001000   /* port 0 configuration space */
 			  0x82000000 0 0x10001000 0x0 0x10001000 0 0x00001000   /* port 1 configuration space */
 			  0x82000000 0 0x10004000 0x0 0x10004000 0 0x00001000   /* port 2 configuration space */
-			  0x81000000 0 0x0        0x0 0x50000000 0 0x00010000   /* downstream I/O (64 KiB) */
-			  0x82000000 0 0x50100000 0x0 0x50100000 0 0x07F00000   /* non-prefetchable memory (127 MiB) */
-			  0xc2000000 0 0x58000000 0x0 0x58000000 0 0x28000000>; /* prefetchable memory (640 MiB) */
+			  0x81000000 0 0x0        0x0 0x40001000 0 0x00010000   /* downstream I/O (64 KiB) */
+			  0x82000000 0 0x40100000 0x0 0x40100000 0 0x07F00000   /* non-prefetchable memory (127 MiB) */
+			  0xc2000000 0 0x48000000 0x0 0x48000000 0 0x38000000>; /* prefetchable memory (896 MiB) */
 
 		clocks = <&bpmp TEGRA186_CLK_AFI>,
 			 <&bpmp TEGRA186_CLK_PCIE>,
-- 
2.7.4

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Bjorn Helgaas]

On Tue, Oct 24, 2017 at 12:14:47PM +0530, Vidya Sagar wrote:
> PCIe host controller in Tegra SoCs has 1GB of aperture available
> for mapping end points config space, IO and BARs. In that, currently
> 256MB is being reserved for mapping end points configuration space
> which leaves less memory space available for mapping end points BARs
> on some of the platforms.
> This patch series attempts to map only 4K space from 1GB aperture to
> access end points configuration space.
> 
> Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
> to use for BAR mapping) physical space as well as kernel virtual mapping space,
> it saves only kernel virtual address space in T30, T124, T132 and T210.
> 
> NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
> merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
> For older platforms (T20, T30, T124, T132, T210), this change works fine without any
> DT modifications
> 
> Testing Done on T124, T210 & T186:
>  Enumeration and basic functionality of immediate devices
>  Enumeration of devices behind a PCIe switch
>  Complete 4K configuration space access
> 
> Vidya Sagar (2):
>   PCI: tegra: refactor config space mapping code
>   ARM64: tegra: limit PCIe config space mapping to 4K for T186
> 
>  arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
>  drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
>  2 files changed, 44 insertions(+), 89 deletions(-)

Seems OK to me; waiting for Thierry's ack.

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Bjorn Helgaas]

On Tue, Oct 24, 2017 at 12:14:47PM +0530, Vidya Sagar wrote:
> PCIe host controller in Tegra SoCs has 1GB of aperture available
> for mapping end points config space, IO and BARs. In that, currently
> 256MB is being reserved for mapping end points configuration space
> which leaves less memory space available for mapping end points BARs
> on some of the platforms.
> This patch series attempts to map only 4K space from 1GB aperture to
> access end points configuration space.
> 
> Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
> to use for BAR mapping) physical space as well as kernel virtual mapping space,
> it saves only kernel virtual address space in T30, T124, T132 and T210.
> 
> NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
> merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
> For older platforms (T20, T30, T124, T132, T210), this change works fine without any
> DT modifications
> 
> Testing Done on T124, T210 & T186:
>  Enumeration and basic functionality of immediate devices
>  Enumeration of devices behind a PCIe switch
>  Complete 4K configuration space access
> 
> Vidya Sagar (2):
>   PCI: tegra: refactor config space mapping code
>   ARM64: tegra: limit PCIe config space mapping to 4K for T186
> 
>  arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
>  drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
>  2 files changed, 44 insertions(+), 89 deletions(-)

Seems OK to me; waiting for Thierry's ack.

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Bjorn Helgaas]

On Tue, Oct 24, 2017 at 03:15:12PM -0500, Bjorn Helgaas wrote:
> On Tue, Oct 24, 2017 at 12:14:47PM +0530, Vidya Sagar wrote:
> > PCIe host controller in Tegra SoCs has 1GB of aperture available
> > for mapping end points config space, IO and BARs. In that, currently
> > 256MB is being reserved for mapping end points configuration space
> > which leaves less memory space available for mapping end points BARs
> > on some of the platforms.
> > This patch series attempts to map only 4K space from 1GB aperture to
> > access end points configuration space.
> > 
> > Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
> > to use for BAR mapping) physical space as well as kernel virtual mapping space,
> > it saves only kernel virtual address space in T30, T124, T132 and T210.
> > 
> > NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
> > merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
> > For older platforms (T20, T30, T124, T132, T210), this change works fine without any
> > DT modifications
> > 
> > Testing Done on T124, T210 & T186:
> >  Enumeration and basic functionality of immediate devices
> >  Enumeration of devices behind a PCIe switch
> >  Complete 4K configuration space access
> > 
> > Vidya Sagar (2):
> >   PCI: tegra: refactor config space mapping code
> >   ARM64: tegra: limit PCIe config space mapping to 4K for T186
> > 
> >  arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
> >  drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
> >  2 files changed, 44 insertions(+), 89 deletions(-)
> 
> Seems OK to me; waiting for Thierry's ack.

Dropping for lack of an ack.  Please repost if/when Thierry acks it.

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Vidya Sagar]

Thierry, Can you please Ack it so that we can target it for next release?

On Tuesday 07 November 2017 01:21 AM, Bjorn Helgaas wrote:
> On Tue, Oct 24, 2017 at 03:15:12PM -0500, Bjorn Helgaas wrote:
>> On Tue, Oct 24, 2017 at 12:14:47PM +0530, Vidya Sagar wrote:
>>> PCIe host controller in Tegra SoCs has 1GB of aperture available
>>> for mapping end points config space, IO and BARs. In that, currently
>>> 256MB is being reserved for mapping end points configuration space
>>> which leaves less memory space available for mapping end points BARs
>>> on some of the platforms.
>>> This patch series attempts to map only 4K space from 1GB aperture to
>>> access end points configuration space.
>>>
>>> Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
>>> to use for BAR mapping) physical space as well as kernel virtual mapping space,
>>> it saves only kernel virtual address space in T30, T124, T132 and T210.
>>>
>>> NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
>>> merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
>>> For older platforms (T20, T30, T124, T132, T210), this change works fine without any
>>> DT modifications
>>>
>>> Testing Done on T124, T210 & T186:
>>>   Enumeration and basic functionality of immediate devices
>>>   Enumeration of devices behind a PCIe switch
>>>   Complete 4K configuration space access
>>>
>>> Vidya Sagar (2):
>>>    PCI: tegra: refactor config space mapping code
>>>    ARM64: tegra: limit PCIe config space mapping to 4K for T186
>>>
>>>   arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
>>>   drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
>>>   2 files changed, 44 insertions(+), 89 deletions(-)
>> Seems OK to me; waiting for Thierry's ack.
> Dropping for lack of an ack.  Please repost if/when Thierry acks it.

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Vidya Sagar]

Thierry, Can you please Ack it so that we can target it for next release?

On Tuesday 07 November 2017 01:21 AM, Bjorn Helgaas wrote:
> On Tue, Oct 24, 2017 at 03:15:12PM -0500, Bjorn Helgaas wrote:
>> On Tue, Oct 24, 2017 at 12:14:47PM +0530, Vidya Sagar wrote:
>>> PCIe host controller in Tegra SoCs has 1GB of aperture available
>>> for mapping end points config space, IO and BARs. In that, currently
>>> 256MB is being reserved for mapping end points configuration space
>>> which leaves less memory space available for mapping end points BARs
>>> on some of the platforms.
>>> This patch series attempts to map only 4K space from 1GB aperture to
>>> access end points configuration space.
>>>
>>> Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
>>> to use for BAR mapping) physical space as well as kernel virtual mapping space,
>>> it saves only kernel virtual address space in T30, T124, T132 and T210.
>>>
>>> NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
>>> merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
>>> For older platforms (T20, T30, T124, T132, T210), this change works fine without any
>>> DT modifications
>>>
>>> Testing Done on T124, T210 & T186:
>>>   Enumeration and basic functionality of immediate devices
>>>   Enumeration of devices behind a PCIe switch
>>>   Complete 4K configuration space access
>>>
>>> Vidya Sagar (2):
>>>    PCI: tegra: refactor config space mapping code
>>>    ARM64: tegra: limit PCIe config space mapping to 4K for T186
>>>
>>>   arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
>>>   drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
>>>   2 files changed, 44 insertions(+), 89 deletions(-)
>> Seems OK to me; waiting for Thierry's ack.
> Dropping for lack of an ack.  Please repost if/when Thierry acks it.

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]

On Thu, Dec 14, 2017 at 10:37:22AM +0000, Lorenzo Pieralisi wrote:
> On Tue, Dec 12, 2017 at 01:22:52PM +0100, Thierry Reding wrote:
> 
> [...]
> 
> > > > > Hi Bjorn,
> > > > > 
> > > > > there's a bunch of PCI related patches for Tegra floating around on the
> > > > > lists. I'm wondering if you'd be okay if I pick those up into the Tegra
> > > > > tree after they've been reviewed and send you a pull request later on
> > > > > (say around v4.15-rc6). That would allow me to get things cooking in
> > > > > linux-next for a bit and get broader testing in addition to the
> > > > > flexibility to patch things up if they break.
> > > > 
> > > > Lorenzo will be merging the Tegra stuff, so this is more a question
> > > > for him.
> > > > 
> > > > Just to clarify, I think your questions is about putting those patches
> > > > in
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git#for-next.
> > > > If you put them there they will show up in linux-next, and then when
> > > > Lorenzo merges them, you'll have to coordinate so they don't get
> > > > merged into linux-next twice (once via the usual PCI tree route and
> > > > again via the Tegra tree).
> > > > 
> > > > If you wait until after they've been reviewed to put them into the
> > > > Tegra tree, I'm not sure what the gain is, because I assume Lorenzo
> > > > would merge them at about that same point.
> > > 
> > > I think that after the review, the Tegra patches that are considered for
> > > upstream they should go to -next via the PCI tree as any other platform PCI
> > > patches; the relevant patches need ACKs from the respective platform
> > > maintainer - I am getting to them as fast as I can.
> > 
> > Just to clarify: I wasn't suggesting that these patches are merged for
> > v4.16 via the Tegra tree, only that I carry them in the Tegra tree for a
> > little while so that we can get broader testing and fix things up in
> > case they break. My proposal was to then send a pull request for
> > inclusion in the PCI tree. linux-next can deal with this type of
> > scenario just fine because it will simply see the same branch twice and
> > ignore the second one.
> > 
> > If you prefer to merge directly via the PCI tree that works for me too.
> 
> We would end up merging the patches into -next at the same time, so there
> is not much point in queuing them via Tegra if they go via the PCI tree
> eventually; we should not add to -next patches that are not ready to
> be merged anyway.
> 
> I need your help (ACKs) though to queue them up - I review the patches
> but I can neither test them nor get access to HW TRMs so for some of them
> there is not much I can do.

I've sent out a small series of patches that apply on top of this patch
which clean up and fix a couple of issues with this patch. Feel free to
squash those into this patch if you prefer.

Acked-by: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2957 bytes --]

On Thu, Dec 14, 2017 at 10:37:22AM +0000, Lorenzo Pieralisi wrote:
> On Tue, Dec 12, 2017 at 01:22:52PM +0100, Thierry Reding wrote:
> 
> [...]
> 
> > > > > Hi Bjorn,
> > > > > 
> > > > > there's a bunch of PCI related patches for Tegra floating around on the
> > > > > lists. I'm wondering if you'd be okay if I pick those up into the Tegra
> > > > > tree after they've been reviewed and send you a pull request later on
> > > > > (say around v4.15-rc6). That would allow me to get things cooking in
> > > > > linux-next for a bit and get broader testing in addition to the
> > > > > flexibility to patch things up if they break.
> > > > 
> > > > Lorenzo will be merging the Tegra stuff, so this is more a question
> > > > for him.
> > > > 
> > > > Just to clarify, I think your questions is about putting those patches
> > > > in
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git#for-next.
> > > > If you put them there they will show up in linux-next, and then when
> > > > Lorenzo merges them, you'll have to coordinate so they don't get
> > > > merged into linux-next twice (once via the usual PCI tree route and
> > > > again via the Tegra tree).
> > > > 
> > > > If you wait until after they've been reviewed to put them into the
> > > > Tegra tree, I'm not sure what the gain is, because I assume Lorenzo
> > > > would merge them at about that same point.
> > > 
> > > I think that after the review, the Tegra patches that are considered for
> > > upstream they should go to -next via the PCI tree as any other platform PCI
> > > patches; the relevant patches need ACKs from the respective platform
> > > maintainer - I am getting to them as fast as I can.
> > 
> > Just to clarify: I wasn't suggesting that these patches are merged for
> > v4.16 via the Tegra tree, only that I carry them in the Tegra tree for a
> > little while so that we can get broader testing and fix things up in
> > case they break. My proposal was to then send a pull request for
> > inclusion in the PCI tree. linux-next can deal with this type of
> > scenario just fine because it will simply see the same branch twice and
> > ignore the second one.
> > 
> > If you prefer to merge directly via the PCI tree that works for me too.
> 
> We would end up merging the patches into -next at the same time, so there
> is not much point in queuing them via Tegra if they go via the PCI tree
> eventually; we should not add to -next patches that are not ready to
> be merged anyway.
> 
> I need your help (ACKs) though to queue them up - I review the patches
> but I can neither test them nor get access to HW TRMs so for some of them
> there is not much I can do.

I've sent out a small series of patches that apply on top of this patch
which clean up and fix a couple of issues with this patch. Feel free to
squash those into this patch if you prefer.

Acked-by: Thierry Reding <treding@nvidia.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Lorenzo Pieralisi]

On Tue, Dec 12, 2017 at 01:22:52PM +0100, Thierry Reding wrote:

[...]

> > > > Hi Bjorn,
> > > > 
> > > > there's a bunch of PCI related patches for Tegra floating around on the
> > > > lists. I'm wondering if you'd be okay if I pick those up into the Tegra
> > > > tree after they've been reviewed and send you a pull request later on
> > > > (say around v4.15-rc6). That would allow me to get things cooking in
> > > > linux-next for a bit and get broader testing in addition to the
> > > > flexibility to patch things up if they break.
> > > 
> > > Lorenzo will be merging the Tegra stuff, so this is more a question
> > > for him.
> > > 
> > > Just to clarify, I think your questions is about putting those patches
> > > in
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git#for-next.
> > > If you put them there they will show up in linux-next, and then when
> > > Lorenzo merges them, you'll have to coordinate so they don't get
> > > merged into linux-next twice (once via the usual PCI tree route and
> > > again via the Tegra tree).
> > > 
> > > If you wait until after they've been reviewed to put them into the
> > > Tegra tree, I'm not sure what the gain is, because I assume Lorenzo
> > > would merge them at about that same point.
> > 
> > I think that after the review, the Tegra patches that are considered for
> > upstream they should go to -next via the PCI tree as any other platform PCI
> > patches; the relevant patches need ACKs from the respective platform
> > maintainer - I am getting to them as fast as I can.
> 
> Just to clarify: I wasn't suggesting that these patches are merged for
> v4.16 via the Tegra tree, only that I carry them in the Tegra tree for a
> little while so that we can get broader testing and fix things up in
> case they break. My proposal was to then send a pull request for
> inclusion in the PCI tree. linux-next can deal with this type of
> scenario just fine because it will simply see the same branch twice and
> ignore the second one.
> 
> If you prefer to merge directly via the PCI tree that works for me too.

We would end up merging the patches into -next at the same time, so there
is not much point in queuing them via Tegra if they go via the PCI tree
eventually; we should not add to -next patches that are not ready to
be merged anyway.

I need your help (ACKs) though to queue them up - I review the patches
but I can neither test them nor get access to HW TRMs so for some of them
there is not much I can do.

Thanks,
Lorenzo

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Lorenzo Pieralisi]

On Tue, Dec 12, 2017 at 01:22:52PM +0100, Thierry Reding wrote:

[...]

> > > > Hi Bjorn,
> > > > 
> > > > there's a bunch of PCI related patches for Tegra floating around on the
> > > > lists. I'm wondering if you'd be okay if I pick those up into the Tegra
> > > > tree after they've been reviewed and send you a pull request later on
> > > > (say around v4.15-rc6). That would allow me to get things cooking in
> > > > linux-next for a bit and get broader testing in addition to the
> > > > flexibility to patch things up if they break.
> > > 
> > > Lorenzo will be merging the Tegra stuff, so this is more a question
> > > for him.
> > > 
> > > Just to clarify, I think your questions is about putting those patches
> > > in
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git#for-next.
> > > If you put them there they will show up in linux-next, and then when
> > > Lorenzo merges them, you'll have to coordinate so they don't get
> > > merged into linux-next twice (once via the usual PCI tree route and
> > > again via the Tegra tree).
> > > 
> > > If you wait until after they've been reviewed to put them into the
> > > Tegra tree, I'm not sure what the gain is, because I assume Lorenzo
> > > would merge them at about that same point.
> > 
> > I think that after the review, the Tegra patches that are considered for
> > upstream they should go to -next via the PCI tree as any other platform PCI
> > patches; the relevant patches need ACKs from the respective platform
> > maintainer - I am getting to them as fast as I can.
> 
> Just to clarify: I wasn't suggesting that these patches are merged for
> v4.16 via the Tegra tree, only that I carry them in the Tegra tree for a
> little while so that we can get broader testing and fix things up in
> case they break. My proposal was to then send a pull request for
> inclusion in the PCI tree. linux-next can deal with this type of
> scenario just fine because it will simply see the same branch twice and
> ignore the second one.
> 
> If you prefer to merge directly via the PCI tree that works for me too.

We would end up merging the patches into -next at the same time, so there
is not much point in queuing them via Tegra if they go via the PCI tree
eventually; we should not add to -next patches that are not ready to
be merged anyway.

I need your help (ACKs) though to queue them up - I review the patches
but I can neither test them nor get access to HW TRMs so for some of them
there is not much I can do.

Thanks,
Lorenzo

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3946 bytes --]

On Tue, Dec 12, 2017 at 11:01:58AM +0000, Lorenzo Pieralisi wrote:
> On Mon, Dec 11, 2017 at 11:54:53AM -0600, Bjorn Helgaas wrote:
> > [+cc Lorenzo]
> > 
> > On Mon, Dec 11, 2017 at 11:54:31AM +0100, Thierry Reding wrote:
> > > On Mon, Dec 04, 2017 at 11:23:48PM +0530, Vidya Sagar wrote:
> > > > PCIe host controller in Tegra SoCs has 1GB of aperture available
> > > > for mapping end points config space, IO and BARs. In that, currently
> > > > 256MB is being reserved for mapping end points configuration space
> > > > which leaves less memory space available for mapping end points BARs
> > > > on some of the platforms.
> > > > This patch series attempts to map only 4K space from 1GB aperture to
> > > > access end points configuration space.
> > > > 
> > > > Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
> > > > to use for BAR mapping) physical space as well as kernel virtual mapping space,
> > > > it saves only kernel virtual address space in T30, T124, T132 and T210.
> > > > 
> > > > NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
> > > > merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
> > > > For older platforms (T20, T30, T124, T132, T210), this change works fine without any
> > > > DT modifications
> > > > 
> > > > Testing Done on T124, T210 & T186:
> > > >  Enumeration and basic functionality of immediate devices
> > > >  Enumeration of devices behind a PCIe switch
> > > >  Complete 4K configuration space access
> > > > 
> > > > Vidya Sagar (2):
> > > >   PCI: tegra: refactor config space mapping code
> > > >   ARM64: tegra: limit PCIe config space mapping to 4K for T186
> > > > 
> > > >  arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
> > > >  drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
> > > >  2 files changed, 44 insertions(+), 89 deletions(-)
> > > 
> > > Hi Bjorn,
> > > 
> > > there's a bunch of PCI related patches for Tegra floating around on the
> > > lists. I'm wondering if you'd be okay if I pick those up into the Tegra
> > > tree after they've been reviewed and send you a pull request later on
> > > (say around v4.15-rc6). That would allow me to get things cooking in
> > > linux-next for a bit and get broader testing in addition to the
> > > flexibility to patch things up if they break.
> > 
> > Lorenzo will be merging the Tegra stuff, so this is more a question
> > for him.
> > 
> > Just to clarify, I think your questions is about putting those patches
> > in
> > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git#for-next.
> > If you put them there they will show up in linux-next, and then when
> > Lorenzo merges them, you'll have to coordinate so they don't get
> > merged into linux-next twice (once via the usual PCI tree route and
> > again via the Tegra tree).
> > 
> > If you wait until after they've been reviewed to put them into the
> > Tegra tree, I'm not sure what the gain is, because I assume Lorenzo
> > would merge them at about that same point.
> 
> I think that after the review, the Tegra patches that are considered for
> upstream they should go to -next via the PCI tree as any other platform PCI
> patches; the relevant patches need ACKs from the respective platform
> maintainer - I am getting to them as fast as I can.

Just to clarify: I wasn't suggesting that these patches are merged for
v4.16 via the Tegra tree, only that I carry them in the Tegra tree for a
little while so that we can get broader testing and fix things up in
case they break. My proposal was to then send a pull request for
inclusion in the PCI tree. linux-next can deal with this type of
scenario just fine because it will simply see the same branch twice and
ignore the second one.

If you prefer to merge directly via the PCI tree that works for me too.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 3946 bytes --]

On Tue, Dec 12, 2017 at 11:01:58AM +0000, Lorenzo Pieralisi wrote:
> On Mon, Dec 11, 2017 at 11:54:53AM -0600, Bjorn Helgaas wrote:
> > [+cc Lorenzo]
> > 
> > On Mon, Dec 11, 2017 at 11:54:31AM +0100, Thierry Reding wrote:
> > > On Mon, Dec 04, 2017 at 11:23:48PM +0530, Vidya Sagar wrote:
> > > > PCIe host controller in Tegra SoCs has 1GB of aperture available
> > > > for mapping end points config space, IO and BARs. In that, currently
> > > > 256MB is being reserved for mapping end points configuration space
> > > > which leaves less memory space available for mapping end points BARs
> > > > on some of the platforms.
> > > > This patch series attempts to map only 4K space from 1GB aperture to
> > > > access end points configuration space.
> > > > 
> > > > Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
> > > > to use for BAR mapping) physical space as well as kernel virtual mapping space,
> > > > it saves only kernel virtual address space in T30, T124, T132 and T210.
> > > > 
> > > > NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
> > > > merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
> > > > For older platforms (T20, T30, T124, T132, T210), this change works fine without any
> > > > DT modifications
> > > > 
> > > > Testing Done on T124, T210 & T186:
> > > >  Enumeration and basic functionality of immediate devices
> > > >  Enumeration of devices behind a PCIe switch
> > > >  Complete 4K configuration space access
> > > > 
> > > > Vidya Sagar (2):
> > > >   PCI: tegra: refactor config space mapping code
> > > >   ARM64: tegra: limit PCIe config space mapping to 4K for T186
> > > > 
> > > >  arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
> > > >  drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
> > > >  2 files changed, 44 insertions(+), 89 deletions(-)
> > > 
> > > Hi Bjorn,
> > > 
> > > there's a bunch of PCI related patches for Tegra floating around on the
> > > lists. I'm wondering if you'd be okay if I pick those up into the Tegra
> > > tree after they've been reviewed and send you a pull request later on
> > > (say around v4.15-rc6). That would allow me to get things cooking in
> > > linux-next for a bit and get broader testing in addition to the
> > > flexibility to patch things up if they break.
> > 
> > Lorenzo will be merging the Tegra stuff, so this is more a question
> > for him.
> > 
> > Just to clarify, I think your questions is about putting those patches
> > in
> > git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git#for-next.
> > If you put them there they will show up in linux-next, and then when
> > Lorenzo merges them, you'll have to coordinate so they don't get
> > merged into linux-next twice (once via the usual PCI tree route and
> > again via the Tegra tree).
> > 
> > If you wait until after they've been reviewed to put them into the
> > Tegra tree, I'm not sure what the gain is, because I assume Lorenzo
> > would merge them at about that same point.
> 
> I think that after the review, the Tegra patches that are considered for
> upstream they should go to -next via the PCI tree as any other platform PCI
> patches; the relevant patches need ACKs from the respective platform
> maintainer - I am getting to them as fast as I can.

Just to clarify: I wasn't suggesting that these patches are merged for
v4.16 via the Tegra tree, only that I carry them in the Tegra tree for a
little while so that we can get broader testing and fix things up in
case they break. My proposal was to then send a pull request for
inclusion in the PCI tree. linux-next can deal with this type of
scenario just fine because it will simply see the same branch twice and
ignore the second one.

If you prefer to merge directly via the PCI tree that works for me too.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Lorenzo Pieralisi]

On Mon, Dec 11, 2017 at 11:54:53AM -0600, Bjorn Helgaas wrote:
> [+cc Lorenzo]
> 
> On Mon, Dec 11, 2017 at 11:54:31AM +0100, Thierry Reding wrote:
> > On Mon, Dec 04, 2017 at 11:23:48PM +0530, Vidya Sagar wrote:
> > > PCIe host controller in Tegra SoCs has 1GB of aperture available
> > > for mapping end points config space, IO and BARs. In that, currently
> > > 256MB is being reserved for mapping end points configuration space
> > > which leaves less memory space available for mapping end points BARs
> > > on some of the platforms.
> > > This patch series attempts to map only 4K space from 1GB aperture to
> > > access end points configuration space.
> > > 
> > > Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
> > > to use for BAR mapping) physical space as well as kernel virtual mapping space,
> > > it saves only kernel virtual address space in T30, T124, T132 and T210.
> > > 
> > > NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
> > > merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
> > > For older platforms (T20, T30, T124, T132, T210), this change works fine without any
> > > DT modifications
> > > 
> > > Testing Done on T124, T210 & T186:
> > >  Enumeration and basic functionality of immediate devices
> > >  Enumeration of devices behind a PCIe switch
> > >  Complete 4K configuration space access
> > > 
> > > Vidya Sagar (2):
> > >   PCI: tegra: refactor config space mapping code
> > >   ARM64: tegra: limit PCIe config space mapping to 4K for T186
> > > 
> > >  arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
> > >  drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
> > >  2 files changed, 44 insertions(+), 89 deletions(-)
> > 
> > Hi Bjorn,
> > 
> > there's a bunch of PCI related patches for Tegra floating around on the
> > lists. I'm wondering if you'd be okay if I pick those up into the Tegra
> > tree after they've been reviewed and send you a pull request later on
> > (say around v4.15-rc6). That would allow me to get things cooking in
> > linux-next for a bit and get broader testing in addition to the
> > flexibility to patch things up if they break.
> 
> Lorenzo will be merging the Tegra stuff, so this is more a question
> for him.
> 
> Just to clarify, I think your questions is about putting those patches
> in
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git#for-next.
> If you put them there they will show up in linux-next, and then when
> Lorenzo merges them, you'll have to coordinate so they don't get
> merged into linux-next twice (once via the usual PCI tree route and
> again via the Tegra tree).
> 
> If you wait until after they've been reviewed to put them into the
> Tegra tree, I'm not sure what the gain is, because I assume Lorenzo
> would merge them at about that same point.

I think that after the review, the Tegra patches that are considered for
upstream they should go to -next via the PCI tree as any other platform PCI
patches; the relevant patches need ACKs from the respective platform
maintainer - I am getting to them as fast as I can.

> This cycle isn't going to be ideal timing with all the holidays
> coming up.  I know I'm going to be traveling and on vacation quite a
> bit in the rc5, 6, 7 timeframe.

Yes timing is not ideal - I won't be able to review anything in the -rc5
week either but apart from that I should be online.

Lorenzo

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Lorenzo Pieralisi]

On Mon, Dec 11, 2017 at 11:54:53AM -0600, Bjorn Helgaas wrote:
> [+cc Lorenzo]
> 
> On Mon, Dec 11, 2017 at 11:54:31AM +0100, Thierry Reding wrote:
> > On Mon, Dec 04, 2017 at 11:23:48PM +0530, Vidya Sagar wrote:
> > > PCIe host controller in Tegra SoCs has 1GB of aperture available
> > > for mapping end points config space, IO and BARs. In that, currently
> > > 256MB is being reserved for mapping end points configuration space
> > > which leaves less memory space available for mapping end points BARs
> > > on some of the platforms.
> > > This patch series attempts to map only 4K space from 1GB aperture to
> > > access end points configuration space.
> > > 
> > > Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
> > > to use for BAR mapping) physical space as well as kernel virtual mapping space,
> > > it saves only kernel virtual address space in T30, T124, T132 and T210.
> > > 
> > > NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
> > > merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
> > > For older platforms (T20, T30, T124, T132, T210), this change works fine without any
> > > DT modifications
> > > 
> > > Testing Done on T124, T210 & T186:
> > >  Enumeration and basic functionality of immediate devices
> > >  Enumeration of devices behind a PCIe switch
> > >  Complete 4K configuration space access
> > > 
> > > Vidya Sagar (2):
> > >   PCI: tegra: refactor config space mapping code
> > >   ARM64: tegra: limit PCIe config space mapping to 4K for T186
> > > 
> > >  arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
> > >  drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
> > >  2 files changed, 44 insertions(+), 89 deletions(-)
> > 
> > Hi Bjorn,
> > 
> > there's a bunch of PCI related patches for Tegra floating around on the
> > lists. I'm wondering if you'd be okay if I pick those up into the Tegra
> > tree after they've been reviewed and send you a pull request later on
> > (say around v4.15-rc6). That would allow me to get things cooking in
> > linux-next for a bit and get broader testing in addition to the
> > flexibility to patch things up if they break.
> 
> Lorenzo will be merging the Tegra stuff, so this is more a question
> for him.
> 
> Just to clarify, I think your questions is about putting those patches
> in
> git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git#for-next.
> If you put them there they will show up in linux-next, and then when
> Lorenzo merges them, you'll have to coordinate so they don't get
> merged into linux-next twice (once via the usual PCI tree route and
> again via the Tegra tree).
> 
> If you wait until after they've been reviewed to put them into the
> Tegra tree, I'm not sure what the gain is, because I assume Lorenzo
> would merge them at about that same point.

I think that after the review, the Tegra patches that are considered for
upstream they should go to -next via the PCI tree as any other platform PCI
patches; the relevant patches need ACKs from the respective platform
maintainer - I am getting to them as fast as I can.

> This cycle isn't going to be ideal timing with all the holidays
> coming up.  I know I'm going to be traveling and on vacation quite a
> bit in the rc5, 6, 7 timeframe.

Yes timing is not ideal - I won't be able to review anything in the -rc5
week either but apart from that I should be online.

Lorenzo

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Bjorn Helgaas]

[+cc Lorenzo]

On Mon, Dec 11, 2017 at 11:54:31AM +0100, Thierry Reding wrote:
> On Mon, Dec 04, 2017 at 11:23:48PM +0530, Vidya Sagar wrote:
> > PCIe host controller in Tegra SoCs has 1GB of aperture available
> > for mapping end points config space, IO and BARs. In that, currently
> > 256MB is being reserved for mapping end points configuration space
> > which leaves less memory space available for mapping end points BARs
> > on some of the platforms.
> > This patch series attempts to map only 4K space from 1GB aperture to
> > access end points configuration space.
> > 
> > Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
> > to use for BAR mapping) physical space as well as kernel virtual mapping space,
> > it saves only kernel virtual address space in T30, T124, T132 and T210.
> > 
> > NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
> > merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
> > For older platforms (T20, T30, T124, T132, T210), this change works fine without any
> > DT modifications
> > 
> > Testing Done on T124, T210 & T186:
> >  Enumeration and basic functionality of immediate devices
> >  Enumeration of devices behind a PCIe switch
> >  Complete 4K configuration space access
> > 
> > Vidya Sagar (2):
> >   PCI: tegra: refactor config space mapping code
> >   ARM64: tegra: limit PCIe config space mapping to 4K for T186
> > 
> >  arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
> >  drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
> >  2 files changed, 44 insertions(+), 89 deletions(-)
> 
> Hi Bjorn,
> 
> there's a bunch of PCI related patches for Tegra floating around on the
> lists. I'm wondering if you'd be okay if I pick those up into the Tegra
> tree after they've been reviewed and send you a pull request later on
> (say around v4.15-rc6). That would allow me to get things cooking in
> linux-next for a bit and get broader testing in addition to the
> flexibility to patch things up if they break.

Lorenzo will be merging the Tegra stuff, so this is more a question
for him.

Just to clarify, I think your questions is about putting those patches
in
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git#for-next.
If you put them there they will show up in linux-next, and then when
Lorenzo merges them, you'll have to coordinate so they don't get
merged into linux-next twice (once via the usual PCI tree route and
again via the Tegra tree).

If you wait until after they've been reviewed to put them into the
Tegra tree, I'm not sure what the gain is, because I assume Lorenzo
would merge them at about that same point.

This cycle isn't going to be ideal timing with all the holidays
coming up.  I know I'm going to be traveling and on vacation quite a
bit in the rc5, 6, 7 timeframe.

Bjorn

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]

On Mon, Dec 04, 2017 at 11:23:48PM +0530, Vidya Sagar wrote:
> PCIe host controller in Tegra SoCs has 1GB of aperture available
> for mapping end points config space, IO and BARs. In that, currently
> 256MB is being reserved for mapping end points configuration space
> which leaves less memory space available for mapping end points BARs
> on some of the platforms.
> This patch series attempts to map only 4K space from 1GB aperture to
> access end points configuration space.
> 
> Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
> to use for BAR mapping) physical space as well as kernel virtual mapping space,
> it saves only kernel virtual address space in T30, T124, T132 and T210.
> 
> NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
> merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
> For older platforms (T20, T30, T124, T132, T210), this change works fine without any
> DT modifications
> 
> Testing Done on T124, T210 & T186:
>  Enumeration and basic functionality of immediate devices
>  Enumeration of devices behind a PCIe switch
>  Complete 4K configuration space access
> 
> Vidya Sagar (2):
>   PCI: tegra: refactor config space mapping code
>   ARM64: tegra: limit PCIe config space mapping to 4K for T186
> 
>  arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
>  drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
>  2 files changed, 44 insertions(+), 89 deletions(-)

Hi Bjorn,

there's a bunch of PCI related patches for Tegra floating around on the
lists. I'm wondering if you'd be okay if I pick those up into the Tegra
tree after they've been reviewed and send you a pull request later on
(say around v4.15-rc6). That would allow me to get things cooking in
linux-next for a bit and get broader testing in addition to the
flexibility to patch things up if they break.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]

On Mon, Dec 04, 2017 at 11:23:48PM +0530, Vidya Sagar wrote:
> PCIe host controller in Tegra SoCs has 1GB of aperture available
> for mapping end points config space, IO and BARs. In that, currently
> 256MB is being reserved for mapping end points configuration space
> which leaves less memory space available for mapping end points BARs
> on some of the platforms.
> This patch series attempts to map only 4K space from 1GB aperture to
> access end points configuration space.
> 
> Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
> to use for BAR mapping) physical space as well as kernel virtual mapping space,
> it saves only kernel virtual address space in T30, T124, T132 and T210.
> 
> NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
> merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
> For older platforms (T20, T30, T124, T132, T210), this change works fine without any
> DT modifications
> 
> Testing Done on T124, T210 & T186:
>  Enumeration and basic functionality of immediate devices
>  Enumeration of devices behind a PCIe switch
>  Complete 4K configuration space access
> 
> Vidya Sagar (2):
>   PCI: tegra: refactor config space mapping code
>   ARM64: tegra: limit PCIe config space mapping to 4K for T186
> 
>  arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
>  drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
>  2 files changed, 44 insertions(+), 89 deletions(-)

Hi Bjorn,

there's a bunch of PCI related patches for Tegra floating around on the
lists. I'm wondering if you'd be okay if I pick those up into the Tegra
tree after they've been reviewed and send you a pull request later on
(say around v4.15-rc6). That would allow me to get things cooking in
linux-next for a bit and get broader testing in addition to the
flexibility to patch things up if they break.

Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Vidya Sagar]

PCIe host controller in Tegra SoCs has 1GB of aperture available
for mapping end points config space, IO and BARs. In that, currently
256MB is being reserved for mapping end points configuration space
which leaves less memory space available for mapping end points BARs
on some of the platforms.
This patch series attempts to map only 4K space from 1GB aperture to
access end points configuration space.

Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
to use for BAR mapping) physical space as well as kernel virtual mapping space,
it saves only kernel virtual address space in T30, T124, T132 and T210.

NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
For older platforms (T20, T30, T124, T132, T210), this change works fine without any
DT modifications

Testing Done on T124, T210 & T186:
 Enumeration and basic functionality of immediate devices
 Enumeration of devices behind a PCIe switch
 Complete 4K configuration space access

Vidya Sagar (2):
  PCI: tegra: refactor config space mapping code
  ARM64: tegra: limit PCIe config space mapping to 4K for T186

 arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
 drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
 2 files changed, 44 insertions(+), 89 deletions(-)

-- 
2.7.4

[PATCH V3 0/2] Tegra PCIe end point config space map code refactoring

[Vidya Sagar]

PCIe host controller in Tegra SoCs has 1GB of aperture available
for mapping end points config space, IO and BARs. In that, currently
256MB is being reserved for mapping end points configuration space
which leaves less memory space available for mapping end points BARs
on some of the platforms.
This patch series attempts to map only 4K space from 1GB aperture to
access end points configuration space.

Currently, this change can benefit T20 and T186 in saving (i.e. repurposed
to use for BAR mapping) physical space as well as kernel virtual mapping space,
it saves only kernel virtual address space in T30, T124, T132 and T210.

NOTE: Since T186 PCIe DT entry is not yet present in main line (it is currently
merged to 'for-4.15/arm64/dt' branch), nothing gets broken with this change for T186.
For older platforms (T20, T30, T124, T132, T210), this change works fine without any
DT modifications

Testing Done on T124, T210 & T186:
 Enumeration and basic functionality of immediate devices
 Enumeration of devices behind a PCIe switch
 Complete 4K configuration space access

Vidya Sagar (2):
  PCI: tegra: refactor config space mapping code
  ARM64: tegra: limit PCIe config space mapping to 4K for T186

 arch/arm64/boot/dts/nvidia/tegra186.dtsi |   8 +-
 drivers/pci/host/pci-tegra.c             | 125 ++++++++++---------------------
 2 files changed, 44 insertions(+), 89 deletions(-)

-- 
2.7.4