Groups > linux.kernel > #1293002 > unrolled thread

[PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

Started by	Tomasz Nowicki <tn@semihalf.com>
First post	2015-12-16 16:20 +0100
Last post	2015-12-21 23:50 +0100
Articles	11 on this page of 51 — 10 participants

Back to article view | Back to linux.kernel

  [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
    [PATCH V2 12/23] pci, acpi: Move ACPI host bridge device companion assignment to core code. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
    [PATCH V2 20/23] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
    [PATCH V2 01/23] x86, pci: Reorder logic of pci_mmconfig_insert() function Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
    [PATCH V2 21/23] pci, acpi: Support for ACPI based PCI hostbridge init Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
      Re: [PATCH V2 21/23] pci, acpi: Support for ACPI based PCI hostbridge init Arnd Bergmann <arnd@arndb.de> - 2015-12-18 13:50 +0100
        Re: [PATCH V2 21/23] pci, acpi: Support for ACPI based PCI hostbridge  init Tomasz Nowicki <tn@semihalf.com> - 2015-12-21 11:30 +0100
    [PATCH V2 19/23] acpi, mcfg: Add default PCI config accessors implementation and initial support for related quirks. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
    [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
      RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2015-12-21 12:50 +0100
        Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks. Arnd Bergmann <arnd@arndb.de> - 2015-12-21 15:20 +0100
          Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks. Arnd Bergmann <arnd@arndb.de> - 2015-12-21 23:50 +0100
            Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Jon Masters <jcm@redhat.com> - 2015-12-22 00:30 +0100
          Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors against platfrom specific quirks. Jon Masters <jcm@redhat.com> - 2015-12-22 00:20 +0100
            Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Tomasz Nowicki <tn@semihalf.com> - 2015-12-22 09:50 +0100
            RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2015-12-22 10:40 +0100
              Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Jon Masters <jcm@redhat.com> - 2015-12-22 17:40 +0100
                Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Jon Masters <jcm@redhat.com> - 2015-12-22 17:50 +0100
                  RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2015-12-22 19:00 +0100
        Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Tomasz Nowicki <tn@semihalf.com> - 2015-12-22 11:30 +0100
          RE: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Gabriele Paoloni <gabriele.paoloni@huawei.com> - 2015-12-22 15:50 +0100
            Re: [PATCH V2 22/23] pci, acpi: Match PCI config space accessors  against platfrom specific quirks. Hanjun Guo <hanjun.guo@linaro.org> - 2015-12-23 10:40 +0100
    [PATCH V2 09/23] pci, acpi, ecam: Add flag to indicate whether ECAM region was hot added or not. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:20 +0100
    [PATCH V2 18/23] x86, acpi, pci: Use equivalent function introduced in previous patch. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 14/23] pci, acpi: Provide generic way to assign bus domain number. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 05/23] x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM driver. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 11/23] arm64, pci: Remove useless boot time IRQ assignment when booting with DT. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 13/23] x86, ia64, pci: Remove ACPI companion device from platform specific data. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 10/23] x86, pci: Cleanup platform specific MCFG data using previously added ECAM hot_added flag. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 16/23] x86, ia64: Include acpi_pci_{add|remove}_bus to the default pcibios_{add|remove}_bus implementation. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 06/23] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
      Re: [PATCH V2 06/23] XEN / PCI: Remove the dependence on arch x86  when PCI_MMCONFIG=y Tomasz Nowicki <tn@semihalf.com> - 2015-12-17 11:30 +0100
        Re: [PATCH V2 06/23] XEN / PCI: Remove the dependence on arch x86  when PCI_MMCONFIG=y Tomasz Nowicki <tn@semihalf.com> - 2015-12-17 11:50 +0100
      Re: [PATCH V2 06/23] XEN / PCI: Remove the dependence on arch x86  when PCI_MMCONFIG=y Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-12-21 19:20 +0100
        Re: [PATCH V2 06/23] XEN / PCI: Remove the dependence on arch x86  when PCI_MMCONFIG=y Tomasz Nowicki <tn@semihalf.com> - 2015-12-22 09:40 +0100
    [PATCH V2 15/23] x86, ia64, pci: Convert arches to use PCI_DOMAINS_GENERIC. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 08/23] arm64, acpi: Use empty PCI config space accessors from mcfg.c file. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 03/23] pci, acpi, mcfg: Provide generic implementation of MCFG code initialization. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 07/23] pci, acpi, mcfg: Provide default RAW ACPI PCI config space accessors. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 17/23] acpi, mcfg: Implement two calls that might be used to inject/remove MCFG region. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 04/23] x86, pci: mmconfig_{32,64}.c code refactoring - remove code duplication. Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    [PATCH V2 02/23] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory Tomasz Nowicki <tn@semihalf.com> - 2015-12-16 16:30 +0100
    Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Sinan Kaya <okaya@codeaurora.org> - 2015-12-17 22:30 +0100
      Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Tomasz Nowicki <tn@semihalf.com> - 2015-12-18 13:30 +0100
        Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI okaya@codeaurora.org - 2015-12-18 20:00 +0100
          Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Tomasz Nowicki <tn@semihalf.com> - 2015-12-21 11:40 +0100
          Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2015-12-21 13:10 +0100
            Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Tomasz Nowicki <tn@semihalf.com> - 2015-12-21 13:50 +0100
              Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI Arnd Bergmann <arnd@arndb.de> - 2015-12-21 15:20 +0100
                Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Okaya@codeaurora.org - 2015-12-21 16:30 +0100
                  Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI Arnd Bergmann <arnd@arndb.de> - 2015-12-21 23:50 +0100

Page 3 of 3 — ← Prev page 1 2 [3]

#1293032 — [PATCH V2 04/23] x86, pci: mmconfig_{32,64}.c code refactoring - remove code duplication.

From	Tomasz Nowicki <tn@semihalf.com>
Date	2015-12-16 16:30 +0100
Subject	[PATCH V2 04/23] x86, pci: mmconfig_{32,64}.c code refactoring - remove code duplication.
Message-ID	<qGmbG-3tz-59@gated-at.bofh.it>
In reply to	#1293002

mmconfig_64.c version is going to be default implementation for low-level
operation on mmconfig regions. However, now it initializes raw_pci_ext_ops pointer which is specific for
x86 only. Moreover, mmconfig_32.c is doing the same thing at the same time.
So lets move it to mmconfig_shared.c so it becomes common for both and
mmconfig_64.c turns out to be purely arch agnostic.

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
---
 arch/x86/include/asm/pci_x86.h |  5 +++++
 arch/x86/pci/mmconfig-shared.c | 10 ++++++++--
 arch/x86/pci/mmconfig_32.c     | 10 ++--------
 arch/x86/pci/mmconfig_64.c     | 11 ++---------
 4 files changed, 17 insertions(+), 19 deletions(-)

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index c1c0f37..0482807 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -130,6 +130,11 @@ extern void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg);
 extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
 			       phys_addr_t addr);
 
+int pci_mmcfg_read(unsigned int seg, unsigned int bus, unsigned int devfn,
+		   int reg, int len, u32 *value);
+int pci_mmcfg_write(unsigned int seg, unsigned int bus, unsigned int devfn,
+		    int reg, int len, u32 value);
+
 /*
  * AMD Fam10h CPUs are buggy, and cannot access MMIO config space
  * on their northbrige except through the * %eax register. As such, you MUST
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index ce2c2e4..980f304 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -29,6 +29,11 @@
 static bool pci_mmcfg_running_state;
 static bool pci_mmcfg_arch_init_failed;
 
+const struct pci_raw_ops pci_mmcfg = {
+	.read =		pci_mmcfg_read,
+	.write =	pci_mmcfg_write,
+};
+
 static const char *__init pci_mmcfg_e7520(void)
 {
 	u32 win;
@@ -512,9 +517,10 @@ static void __init __pci_mmcfg_init(int early)
 		}
 	}
 
-	if (pci_mmcfg_arch_init())
+	if (pci_mmcfg_arch_init()) {
+		raw_pci_ext_ops = &pci_mmcfg;
 		pci_probe = (pci_probe & ~PCI_PROBE_MASK) | PCI_PROBE_MMCONF;
-	else {
+	} else {
 		free_all_mmcfg();
 		pci_mmcfg_arch_init_failed = true;
 	}
diff --git a/arch/x86/pci/mmconfig_32.c b/arch/x86/pci/mmconfig_32.c
index 246f135..2ded56f 100644
--- a/arch/x86/pci/mmconfig_32.c
+++ b/arch/x86/pci/mmconfig_32.c
@@ -50,7 +50,7 @@ static void pci_exp_set_dev_base(unsigned int base, int bus, int devfn)
 	}
 }
 
-static int pci_mmcfg_read(unsigned int seg, unsigned int bus,
+int pci_mmcfg_read(unsigned int seg, unsigned int bus,
 			  unsigned int devfn, int reg, int len, u32 *value)
 {
 	unsigned long flags;
@@ -89,7 +89,7 @@ err:		*value = -1;
 	return 0;
 }
 
-static int pci_mmcfg_write(unsigned int seg, unsigned int bus,
+int pci_mmcfg_write(unsigned int seg, unsigned int bus,
 			   unsigned int devfn, int reg, int len, u32 value)
 {
 	unsigned long flags;
@@ -126,15 +126,9 @@ static int pci_mmcfg_write(unsigned int seg, unsigned int bus,
 	return 0;
 }
 
-const struct pci_raw_ops pci_mmcfg = {
-	.read =		pci_mmcfg_read,
-	.write =	pci_mmcfg_write,
-};
-
 int __init pci_mmcfg_arch_init(void)
 {
 	printk(KERN_INFO "PCI: Using MMCONFIG for extended config space\n");
-	raw_pci_ext_ops = &pci_mmcfg;
 	return 1;
 }
 
diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
index b14fcd3..d0c48eb 100644
--- a/arch/x86/pci/mmconfig_64.c
+++ b/arch/x86/pci/mmconfig_64.c
@@ -25,7 +25,7 @@ static char __iomem *pci_dev_base(unsigned int seg, unsigned int bus, unsigned i
 	return NULL;
 }
 
-static int pci_mmcfg_read(unsigned int seg, unsigned int bus,
+int pci_mmcfg_read(unsigned int seg, unsigned int bus,
 			  unsigned int devfn, int reg, int len, u32 *value)
 {
 	char __iomem *addr;
@@ -59,7 +59,7 @@ err:		*value = -1;
 	return 0;
 }
 
-static int pci_mmcfg_write(unsigned int seg, unsigned int bus,
+int pci_mmcfg_write(unsigned int seg, unsigned int bus,
 			   unsigned int devfn, int reg, int len, u32 value)
 {
 	char __iomem *addr;
@@ -91,11 +91,6 @@ static int pci_mmcfg_write(unsigned int seg, unsigned int bus,
 	return 0;
 }
 
-const struct pci_raw_ops pci_mmcfg = {
-	.read =		pci_mmcfg_read,
-	.write =	pci_mmcfg_write,
-};
-
 static void __iomem *mcfg_ioremap(struct pci_mmcfg_region *cfg)
 {
 	void __iomem *addr;
@@ -121,8 +116,6 @@ int __init pci_mmcfg_arch_init(void)
 			return 0;
 		}
 
-	raw_pci_ext_ops = &pci_mmcfg;
-
 	return 1;
 }
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1293033 — [PATCH V2 02/23] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory

From	Tomasz Nowicki <tn@semihalf.com>
Date	2015-12-16 16:30 +0100
Subject	[PATCH V2 02/23] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory
Message-ID	<qGmbG-3tz-63@gated-at.bofh.it>
In reply to	#1293002

ECAM standard and MCFG table are architecture independent and it makes
sense to share common code across all architectures. Both are going to
corresponding files - ecam.c and mcfg.c

While we are here, rename pci_parse_mcfg to acpi_parse_mcfg.
We already have acpi_parse_mcfg prototype which is used nowhere.
At the same time, we need pci_parse_mcfg been global so acpi_parse_mcfg
can be used perfectly here.

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
---
 arch/x86/Kconfig               |   3 +
 arch/x86/include/asm/pci_x86.h |  21 -----
 arch/x86/pci/acpi.c            |   1 +
 arch/x86/pci/mmconfig-shared.c | 205 +----------------------------------------
 arch/x86/pci/mmconfig_32.c     |   1 +
 arch/x86/pci/mmconfig_64.c     |   1 +
 arch/x86/pci/numachip.c        |   1 +
 drivers/acpi/Makefile          |   1 +
 drivers/acpi/mcfg.c            |  59 ++++++++++++
 drivers/pci/Kconfig            |   7 ++
 drivers/pci/Makefile           |   5 +
 drivers/pci/ecam.c             | 175 +++++++++++++++++++++++++++++++++++
 drivers/xen/pci.c              |   1 +
 include/linux/acpi.h           |   2 +
 include/linux/ecam.h           |  37 ++++++++
 15 files changed, 299 insertions(+), 221 deletions(-)
 create mode 100644 drivers/acpi/mcfg.c
 create mode 100644 drivers/pci/ecam.c
 create mode 100644 include/linux/ecam.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index db3622f..350bd52 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -128,6 +128,7 @@ config X86
 	select HAVE_MIXED_BREAKPOINTS_REGS
 	select HAVE_OPROFILE
 	select HAVE_OPTPROBES
+	select HAVE_PCI_ECAM
 	select HAVE_PCSPKR_PLATFORM
 	select HAVE_PERF_EVENTS
 	select HAVE_PERF_EVENTS_NMI
@@ -2365,6 +2366,7 @@ config PCI_DIRECT
 
 config PCI_MMCONFIG
 	def_bool y
+	select PCI_ECAM
 	depends on X86_32 && PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || PCI_GOANY)
 
 config PCI_OLPC
@@ -2382,6 +2384,7 @@ config PCI_DOMAINS
 
 config PCI_MMCONFIG
 	bool "Support mmconfig PCI config space access"
+	select PCI_ECAM
 	depends on X86_64 && PCI && ACPI
 
 config PCI_CNB20LE_QUIRK
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 16fd8e9..c1c0f37 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -123,33 +123,12 @@ extern int pci_legacy_init(void);
 extern int pcibios_fixup_irq(struct pci_dev *dev, u8 pin);
 
 /* pci-mmconfig.c */
-
-/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
-#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
-
-struct pci_mmcfg_region {
-	struct list_head list;
-	struct resource res;
-	u64 address;
-	char __iomem *virt;
-	u16 segment;
-	u8 start_bus;
-	u8 end_bus;
-	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
-};
-
 extern int __init pci_mmcfg_arch_init(void);
 extern void __init pci_mmcfg_arch_free(void);
 extern int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg);
 extern void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg);
 extern int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
 			       phys_addr_t addr);
-extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
-extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
-
-extern struct list_head pci_mmcfg_list;
-
-#define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
 
 /*
  * AMD Fam10h CPUs are buggy, and cannot access MMIO config space
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index dda4bc1..64caf2b 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -5,6 +5,7 @@
 #include <linux/dmi.h>
 #include <linux/slab.h>
 #include <linux/pci-acpi.h>
+#include <linux/ecam.h>
 #include <asm/numa.h>
 #include <asm/pci_x86.h>
 
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index c8bb9b0..ce2c2e4 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -18,6 +18,7 @@
 #include <linux/slab.h>
 #include <linux/mutex.h>
 #include <linux/rculist.h>
+#include <linux/ecam.h>
 #include <asm/e820.h>
 #include <asm/pci_x86.h>
 #include <asm/acpi.h>
@@ -27,103 +28,6 @@
 /* Indicate if the mmcfg resources have been placed into the resource table. */
 static bool pci_mmcfg_running_state;
 static bool pci_mmcfg_arch_init_failed;
-static DEFINE_MUTEX(pci_mmcfg_lock);
-
-LIST_HEAD(pci_mmcfg_list);
-
-static void __init pci_mmconfig_remove(struct pci_mmcfg_region *cfg)
-{
-	if (cfg->res.parent)
-		release_resource(&cfg->res);
-	list_del(&cfg->list);
-	kfree(cfg);
-}
-
-static void __init free_all_mmcfg(void)
-{
-	struct pci_mmcfg_region *cfg, *tmp;
-
-	pci_mmcfg_arch_free();
-	list_for_each_entry_safe(cfg, tmp, &pci_mmcfg_list, list)
-		pci_mmconfig_remove(cfg);
-}
-
-static void list_add_sorted(struct pci_mmcfg_region *new)
-{
-	struct pci_mmcfg_region *cfg;
-
-	/* keep list sorted by segment and starting bus number */
-	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list) {
-		if (cfg->segment > new->segment ||
-		    (cfg->segment == new->segment &&
-		     cfg->start_bus >= new->start_bus)) {
-			list_add_tail_rcu(&new->list, &cfg->list);
-			return;
-		}
-	}
-	list_add_tail_rcu(&new->list, &pci_mmcfg_list);
-}
-
-static struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
-						   int end, u64 addr)
-{
-	struct pci_mmcfg_region *new;
-	struct resource *res;
-
-	if (addr == 0)
-		return NULL;
-
-	new = kzalloc(sizeof(*new), GFP_KERNEL);
-	if (!new)
-		return NULL;
-
-	new->address = addr;
-	new->segment = segment;
-	new->start_bus = start;
-	new->end_bus = end;
-
-	res = &new->res;
-	res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
-	res->end = addr + PCI_MMCFG_BUS_OFFSET(end + 1) - 1;
-	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
-	snprintf(new->name, PCI_MMCFG_RESOURCE_NAME_LEN,
-		 "PCI MMCONFIG %04x [bus %02x-%02x]", segment, start, end);
-	res->name = new->name;
-
-	return new;
-}
-
-static struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
-							int end, u64 addr)
-{
-	struct pci_mmcfg_region *new;
-
-	new = pci_mmconfig_alloc(segment, start, end, addr);
-	if (new) {
-		mutex_lock(&pci_mmcfg_lock);
-		list_add_sorted(new);
-		mutex_unlock(&pci_mmcfg_lock);
-
-		pr_info(PREFIX
-		       "MMCONFIG for domain %04x [bus %02x-%02x] at %pR "
-		       "(base %#lx)\n",
-		       segment, start, end, &new->res, (unsigned long)addr);
-	}
-
-	return new;
-}
-
-struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus)
-{
-	struct pci_mmcfg_region *cfg;
-
-	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
-		if (cfg->segment == segment &&
-		    cfg->start_bus <= bus && bus <= cfg->end_bus)
-			return cfg;
-
-	return NULL;
-}
 
 static const char *__init pci_mmcfg_e7520(void)
 {
@@ -543,8 +447,8 @@ static void __init pci_mmcfg_reject_broken(int early)
 	}
 }
 
-static int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
-					struct acpi_mcfg_allocation *cfg)
+int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
+				 struct acpi_mcfg_allocation *cfg)
 {
 	int year;
 
@@ -566,50 +470,6 @@ static int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
 	return -EINVAL;
 }
 
-static int __init pci_parse_mcfg(struct acpi_table_header *header)
-{
-	struct acpi_table_mcfg *mcfg;
-	struct acpi_mcfg_allocation *cfg_table, *cfg;
-	unsigned long i;
-	int entries;
-
-	if (!header)
-		return -EINVAL;
-
-	mcfg = (struct acpi_table_mcfg *)header;
-
-	/* how many config structures do we have */
-	free_all_mmcfg();
-	entries = 0;
-	i = header->length - sizeof(struct acpi_table_mcfg);
-	while (i >= sizeof(struct acpi_mcfg_allocation)) {
-		entries++;
-		i -= sizeof(struct acpi_mcfg_allocation);
-	}
-	if (entries == 0) {
-		pr_err(PREFIX "MMCONFIG has no entries\n");
-		return -ENODEV;
-	}
-
-	cfg_table = (struct acpi_mcfg_allocation *) &mcfg[1];
-	for (i = 0; i < entries; i++) {
-		cfg = &cfg_table[i];
-		if (acpi_mcfg_check_entry(mcfg, cfg)) {
-			free_all_mmcfg();
-			return -ENODEV;
-		}
-
-		if (pci_mmconfig_add(cfg->pci_segment, cfg->start_bus_number,
-				   cfg->end_bus_number, cfg->address) == NULL) {
-			pr_warn(PREFIX "no memory for MCFG entries\n");
-			free_all_mmcfg();
-			return -ENOMEM;
-		}
-	}
-
-	return 0;
-}
-
 #ifdef CONFIG_ACPI_APEI
 extern int (*arch_apei_filter_addr)(int (*func)(__u64 start, __u64 size,
 				     void *data), void *data);
@@ -668,7 +528,7 @@ void __init pci_mmcfg_early_init(void)
 		if (pci_mmcfg_check_hostbridge())
 			known_bridge = 1;
 		else
-			acpi_sfi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
+			acpi_sfi_table_parse(ACPI_SIG_MCFG, acpi_parse_mcfg);
 		__pci_mmcfg_init(1);
 
 		set_apei_filter();
@@ -686,7 +546,7 @@ void __init pci_mmcfg_late_init(void)
 
 	/* MMCONFIG hasn't been enabled yet, try again */
 	if (pci_probe & PCI_PROBE_MASK & ~PCI_PROBE_MMCONF) {
-		acpi_sfi_table_parse(ACPI_SIG_MCFG, pci_parse_mcfg);
+		acpi_sfi_table_parse(ACPI_SIG_MCFG, acpi_parse_mcfg);
 		__pci_mmcfg_init(0);
 	}
 }
@@ -720,38 +580,6 @@ static int __init pci_mmcfg_late_insert_resources(void)
  */
 late_initcall(pci_mmcfg_late_insert_resources);
 
-static int pci_mmconfig_inject(struct pci_mmcfg_region *cfg)
-{
-	struct pci_mmcfg_region *cfg_conflict;
-	int err = 0;
-
-	mutex_lock(&pci_mmcfg_lock);
-	cfg_conflict = pci_mmconfig_lookup(cfg->segment, cfg->start_bus);
-	if (cfg_conflict) {
-		if (cfg_conflict->end_bus < cfg->end_bus)
-			pr_info(FW_INFO "MMCONFIG for "
-				"domain %04x [bus %02x-%02x] "
-				"only partially covers this bridge\n",
-				cfg_conflict->segment, cfg_conflict->start_bus,
-				cfg_conflict->end_bus);
-		err = -EEXIST;
-		goto out;
-	}
-
-	if (pci_mmcfg_arch_map(cfg)) {
-		pr_warn("fail to map MMCONFIG %pR.\n", &cfg->res);
-		err = -ENOMEM;
-		goto out;
-	} else {
-		list_add_sorted(cfg);
-		pr_info("MMCONFIG at %pR (base %#lx)\n",
-			&cfg->res, (unsigned long)cfg->address);
-	}
-out:
-	mutex_unlock(&pci_mmcfg_lock);
-	return err;
-}
-
 /* Add MMCFG information for host bridges */
 int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
 			phys_addr_t addr)
@@ -808,26 +636,3 @@ error:
 	kfree(cfg);
 	return rc;
 }
-
-/* Delete MMCFG information for host bridges */
-int pci_mmconfig_delete(u16 seg, u8 start, u8 end)
-{
-	struct pci_mmcfg_region *cfg;
-
-	mutex_lock(&pci_mmcfg_lock);
-	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
-		if (cfg->segment == seg && cfg->start_bus == start &&
-		    cfg->end_bus == end) {
-			list_del_rcu(&cfg->list);
-			synchronize_rcu();
-			pci_mmcfg_arch_unmap(cfg);
-			if (cfg->res.parent)
-				release_resource(&cfg->res);
-			mutex_unlock(&pci_mmcfg_lock);
-			kfree(cfg);
-			return 0;
-		}
-	mutex_unlock(&pci_mmcfg_lock);
-
-	return -ENOENT;
-}
diff --git a/arch/x86/pci/mmconfig_32.c b/arch/x86/pci/mmconfig_32.c
index 43984bc..246f135 100644
--- a/arch/x86/pci/mmconfig_32.c
+++ b/arch/x86/pci/mmconfig_32.c
@@ -12,6 +12,7 @@
 #include <linux/pci.h>
 #include <linux/init.h>
 #include <linux/rcupdate.h>
+#include <linux/ecam.h>
 #include <asm/e820.h>
 #include <asm/pci_x86.h>
 
diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
index bea5249..b14fcd3 100644
--- a/arch/x86/pci/mmconfig_64.c
+++ b/arch/x86/pci/mmconfig_64.c
@@ -10,6 +10,7 @@
 #include <linux/acpi.h>
 #include <linux/bitmap.h>
 #include <linux/rcupdate.h>
+#include <linux/ecam.h>
 #include <asm/e820.h>
 #include <asm/pci_x86.h>
 
diff --git a/arch/x86/pci/numachip.c b/arch/x86/pci/numachip.c
index 2e565e6..55fbd18 100644
--- a/arch/x86/pci/numachip.c
+++ b/arch/x86/pci/numachip.c
@@ -13,6 +13,7 @@
  *
  */
 
+#include <linux/ecam.h>
 #include <linux/pci.h>
 #include <asm/pci_x86.h>
 
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 96b3183..265eb90 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_ACPI_BUTTON)	+= button.o
 obj-$(CONFIG_ACPI_FAN)		+= fan.o
 obj-$(CONFIG_ACPI_VIDEO)	+= video.o
 obj-$(CONFIG_ACPI_PCI_SLOT)	+= pci_slot.o
+obj-$(CONFIG_PCI_MMCONFIG)	+= mcfg.o
 obj-$(CONFIG_ACPI_PROCESSOR)	+= processor.o
 obj-y				+= container.o
 obj-$(CONFIG_ACPI_THERMAL)	+= thermal.o
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
new file mode 100644
index 0000000..5ecef20
--- /dev/null
+++ b/drivers/acpi/mcfg.c
@@ -0,0 +1,59 @@
+/*
+ * MCFG ACPI table parser.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/acpi.h>
+#include <linux/ecam.h>
+
+#include <asm/pci_x86.h> /* Temp hack before refactoring arch-specific calls */
+
+#define	PREFIX	"MCFG: "
+
+int __init acpi_parse_mcfg(struct acpi_table_header *header)
+{
+	struct acpi_table_mcfg *mcfg;
+	struct acpi_mcfg_allocation *cfg_table, *cfg;
+	unsigned long i;
+	int entries;
+
+	if (!header)
+		return -EINVAL;
+
+	mcfg = (struct acpi_table_mcfg *)header;
+
+	/* how many config structures do we have */
+	free_all_mmcfg();
+	entries = 0;
+	i = header->length - sizeof(struct acpi_table_mcfg);
+	while (i >= sizeof(struct acpi_mcfg_allocation)) {
+		entries++;
+		i -= sizeof(struct acpi_mcfg_allocation);
+	}
+	if (entries == 0) {
+		pr_err(PREFIX "MCFG table has no entries\n");
+		return -ENODEV;
+	}
+
+	cfg_table = (struct acpi_mcfg_allocation *) &mcfg[1];
+	for (i = 0; i < entries; i++) {
+		cfg = &cfg_table[i];
+		if (acpi_mcfg_check_entry(mcfg, cfg)) {
+			free_all_mmcfg();
+			return -ENODEV;
+		}
+
+		if (pci_mmconfig_add(cfg->pci_segment, cfg->start_bus_number,
+				 cfg->end_bus_number, cfg->address) == NULL) {
+			pr_warn(PREFIX "no memory for MCFG entries\n");
+			free_all_mmcfg();
+			return -ENOMEM;
+		}
+	}
+
+	return 0;
+}
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 73de4ef..9950248 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -26,6 +26,13 @@ config PCI_MSI_IRQ_DOMAIN
 	depends on PCI_MSI
 	select GENERIC_MSI_IRQ_DOMAIN
 
+config PCI_ECAM
+	bool "Enhanced Configuration Access Mechanism (ECAM)"
+	depends on PCI && HAVE_PCI_ECAM
+
+config HAVE_PCI_ECAM
+	bool
+
 config PCI_DEBUG
 	bool "PCI Debugging"
 	depends on PCI && DEBUG_KERNEL
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index 8417f55..c41acf1 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -30,6 +30,11 @@ obj-$(CONFIG_PCI_ATS) += ats.o
 obj-$(CONFIG_PCI_IOV) += iov.o
 
 #
+# Enhanced Configuration Access Mechanism (ECAM)
+#
+obj-$(CONFIG_PCI_ECAM)	+= ecam.o
+
+#
 # ACPI Related PCI FW Functions
 # ACPI _DSM provided firmware instance and string name
 #
diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
new file mode 100644
index 0000000..d221dba
--- /dev/null
+++ b/drivers/pci/ecam.c
@@ -0,0 +1,175 @@
+/*
+ * Arch agnostic direct PCI config space access via
+ * ECAM (Enhanced Configuration Access Mechanism)
+ *
+ * Per-architecture code takes care of the mappings, region validation and
+ * accesses themselves.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/mutex.h>
+#include <linux/rculist.h>
+#include <linux/ecam.h>
+
+#include <asm/io.h>
+#include <asm/pci_x86.h> /* Temp hack before refactoring arch-specific calls */
+
+#define PREFIX "PCI: "
+
+static DEFINE_MUTEX(pci_mmcfg_lock);
+
+LIST_HEAD(pci_mmcfg_list);
+
+static void __init pci_mmconfig_remove(struct pci_mmcfg_region *cfg)
+{
+	if (cfg->res.parent)
+		release_resource(&cfg->res);
+	list_del(&cfg->list);
+	kfree(cfg);
+}
+
+void __init free_all_mmcfg(void)
+{
+	struct pci_mmcfg_region *cfg, *tmp;
+
+	pci_mmcfg_arch_free();
+	list_for_each_entry_safe(cfg, tmp, &pci_mmcfg_list, list)
+		pci_mmconfig_remove(cfg);
+}
+
+void list_add_sorted(struct pci_mmcfg_region *new)
+{
+	struct pci_mmcfg_region *cfg;
+
+	/* keep list sorted by segment and starting bus number */
+	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list) {
+		if (cfg->segment > new->segment ||
+		    (cfg->segment == new->segment &&
+		     cfg->start_bus >= new->start_bus)) {
+			list_add_tail_rcu(&new->list, &cfg->list);
+			return;
+		}
+	}
+	list_add_tail_rcu(&new->list, &pci_mmcfg_list);
+}
+
+struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
+					    int end, u64 addr)
+{
+	struct pci_mmcfg_region *new;
+	struct resource *res;
+
+	if (addr == 0)
+		return NULL;
+
+	new = kzalloc(sizeof(*new), GFP_KERNEL);
+	if (!new)
+		return NULL;
+
+	new->address = addr;
+	new->segment = segment;
+	new->start_bus = start;
+	new->end_bus = end;
+
+	res = &new->res;
+	res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
+	res->end = addr + PCI_MMCFG_BUS_OFFSET(end + 1) - 1;
+	res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+	snprintf(new->name, PCI_MMCFG_RESOURCE_NAME_LEN,
+		 "PCI MMCONFIG %04x [bus %02x-%02x]", segment, start, end);
+	res->name = new->name;
+
+	return new;
+}
+
+struct pci_mmcfg_region *pci_mmconfig_add(int segment, int start,
+					  int end, u64 addr)
+{
+	struct pci_mmcfg_region *new;
+
+	new = pci_mmconfig_alloc(segment, start, end, addr);
+	if (new) {
+		mutex_lock(&pci_mmcfg_lock);
+		list_add_sorted(new);
+		mutex_unlock(&pci_mmcfg_lock);
+
+		pr_info(PREFIX
+		       "MMCONFIG for domain %04x [bus %02x-%02x] at %pR "
+		       "(base %#lx)\n",
+		       segment, start, end, &new->res, (unsigned long)addr);
+	}
+
+	return new;
+}
+
+struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus)
+{
+	struct pci_mmcfg_region *cfg;
+
+	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
+		if (cfg->segment == segment &&
+		    cfg->start_bus <= bus && bus <= cfg->end_bus)
+			return cfg;
+
+	return NULL;
+}
+
+/* Delete MMCFG information for host bridges */
+int pci_mmconfig_delete(u16 seg, u8 start, u8 end)
+{
+	struct pci_mmcfg_region *cfg;
+
+	mutex_lock(&pci_mmcfg_lock);
+	list_for_each_entry_rcu(cfg, &pci_mmcfg_list, list)
+		if (cfg->segment == seg && cfg->start_bus == start &&
+		    cfg->end_bus == end) {
+			list_del_rcu(&cfg->list);
+			synchronize_rcu();
+			pci_mmcfg_arch_unmap(cfg);
+			if (cfg->res.parent)
+				release_resource(&cfg->res);
+			mutex_unlock(&pci_mmcfg_lock);
+			kfree(cfg);
+			return 0;
+		}
+	mutex_unlock(&pci_mmcfg_lock);
+
+	return -ENOENT;
+}
+
+int pci_mmconfig_inject(struct pci_mmcfg_region *cfg)
+{
+	struct pci_mmcfg_region *cfg_conflict;
+	int err = 0;
+
+	mutex_lock(&pci_mmcfg_lock);
+	cfg_conflict = pci_mmconfig_lookup(cfg->segment, cfg->start_bus);
+	if (cfg_conflict) {
+		if (cfg_conflict->end_bus < cfg->end_bus)
+			pr_info(FW_INFO "MMCONFIG for "
+				"domain %04x [bus %02x-%02x] "
+				"only partially covers this bridge\n",
+				cfg_conflict->segment, cfg_conflict->start_bus,
+				cfg_conflict->end_bus);
+		err = -EEXIST;
+		goto out;
+	}
+
+	if (pci_mmcfg_arch_map(cfg)) {
+		pr_warn("fail to map MMCONFIG %pR.\n", &cfg->res);
+		err = -ENOMEM;
+		goto out;
+	} else {
+		list_add_sorted(cfg);
+		pr_info("MMCONFIG at %pR (base %#lx)\n",
+			&cfg->res, (unsigned long)cfg->address);
+
+	}
+out:
+	mutex_unlock(&pci_mmcfg_lock);
+	return err;
+}
diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index 7494dbe..6785ebb 100644
--- a/drivers/xen/pci.c
+++ b/drivers/xen/pci.c
@@ -20,6 +20,7 @@
 #include <linux/pci.h>
 #include <linux/acpi.h>
 #include <linux/pci-acpi.h>
+#include <linux/ecam.h>
 #include <xen/xen.h>
 #include <xen/interface/physdev.h>
 #include <xen/interface/xen.h>
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index cc91c15..e95eab2 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -162,6 +162,8 @@ int acpi_table_parse_madt(enum acpi_madt_type id,
 			  acpi_tbl_entry_handler handler,
 			  unsigned int max_entries);
 int acpi_parse_mcfg (struct acpi_table_header *header);
+int acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
+			  struct acpi_mcfg_allocation *cfg);
 void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
 
 /* the following four functions are architecture-dependent */
diff --git a/include/linux/ecam.h b/include/linux/ecam.h
new file mode 100644
index 0000000..dec3b52
--- /dev/null
+++ b/include/linux/ecam.h
@@ -0,0 +1,37 @@
+#ifndef __ECAM_H
+#define __ECAM_H
+#ifdef __KERNEL__
+
+#include <linux/types.h>
+#include <linux/acpi.h>
+
+/* "PCI MMCONFIG %04x [bus %02x-%02x]" */
+#define PCI_MMCFG_RESOURCE_NAME_LEN (22 + 4 + 2 + 2)
+
+struct pci_mmcfg_region {
+	struct list_head list;
+	struct resource res;
+	u64 address;
+	char __iomem *virt;
+	u16 segment;
+	u8 start_bus;
+	u8 end_bus;
+	char name[PCI_MMCFG_RESOURCE_NAME_LEN];
+};
+
+struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
+struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
+						   int end, u64 addr);
+int pci_mmconfig_inject(struct pci_mmcfg_region *cfg);
+struct pci_mmcfg_region *pci_mmconfig_add(int segment, int start,
+						 int end, u64 addr);
+void list_add_sorted(struct pci_mmcfg_region *new);
+void free_all_mmcfg(void);
+int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
+
+extern struct list_head pci_mmcfg_list;
+
+#define PCI_MMCFG_BUS_OFFSET(bus)      ((bus) << 20)
+
+#endif  /* __KERNEL__ */
+#endif  /* __ECAM_H */
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1294276 — Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Sinan Kaya <okaya@codeaurora.org>
Date	2015-12-17 22:30 +0100
Subject	Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qGOhA-4Td-5@gated-at.bofh.it>
In reply to	#1293002

Hi Tomasz,

On 12/16/2015 10:16 AM, Tomasz Nowicki wrote:
> From the functionality point of view this series might be split into the
> following logic parts:
> 1. Make MMCONFIG code arch-agnostic which allows all architectures to collect
>    PCI config regions and used when necessary.
> 2. Move non-arch specific bits to the core code.
> 3. Use MMCONFIG code and implement generic ACPI based PCI host
>    controller driver.
> 4. Enable above driver on ARM64
> 
> Patches has been built on top of 4.4-rc4 and can be found here:
> git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v2)
> 
> NOTE, this patch set depends on Matthew's patches:
> http://www.spinics.net/lists/linux-pci/msg45950.html
> https://github.com/Vality/linux/tree/pci-fixes
> 
> This has been tested on Cavium ThunderX 1 socket server and QEMU.
> Any help in reviewing and testing is very appreciated.
> 
> v1 -> v2
> - moved non-arch specific piece of code to dirver/acpi/ directory
> - fixed IO resource handling
> - introduced PCI config accessors quirks matching
> - moved ACPI_COMPANION_SET to generic code
> 

Just tested your series. I'm seeing a resource assignment problem below. 
The bus addresses show as memory addresses and memory addresses show as 
bus addresses and IO resource did not show up.


Tomasz V2

[    2.520852] ACPI: PCI Interrupt Link [LN1C] (IRQs *238)
[    2.535472] ACPI: PCI Interrupt Link [LN1D] (IRQs *239)
[    2.550562] ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
[    2.567813] acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    2.591270] acpi PNP0A08:02: _OSC: platform does not support [PCIeHotplug]
[    2.611144] acpi PNP0A08:02: _OSC: OS now controls [PME AER PCIeCapability]
[    2.630299] ACPI: IORT: can't find node related to (null) device
[    2.647184]_acpi_PNP0A08:02:_PCI_host_bridge_to_bus_0002:00
[    2.662663] pci_bus 0002:00: root bus resource [mem 0x00100000-0x3fffffff window] (bus address [0xfffff5ff00100000-0xfffff5ff3fffffff])
[    2.703561] pci_bus 0002:00: root bus resource [mem 0x40000000-0x7fffffff window] (bus address [0xfffff5fe80000000-0xfffff5febfffffff])
[    2.737737] pci_bus 0002:00: root bus resource [mem 0x80000000-0xffffffff window] (bus address [0xfffff5fe00000000-0xfffff5fe7fffffff])
[    2.794961] pci_bus 0002:00: root bus resource [bus 00-1f]

Mark Salter's patches

[    2.730011] ACPI: PCI Interrupt Link [LN1C] (IRQs *238)
[    2.744648] ACPI: PCI Interrupt Link [LN1D] (IRQs *239)
[    2.759330] ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
[    2.783295] acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
[    2.806726] acpi PNP0A08:02: _OSC: platform does not support [PCIeHotplug]
[    2.826005] acpi PNP0A08:02: _OSC: OS now controls [PME AER PCIeCapability]
[    2.845361] PCI host bridge to bus 0002:00
[    2.856719]_pci_bus_0002:00:_root_bus_resource_[bus_00-1f]
[    2.872056] pci_bus 0002:00: root bus resource [mem 0xa0100100000-0xa013fffffff] (bus address [0x00100000-0x3fffffff])
[    2.902008] pci_bus 0002:00: root bus resource [mem 0xa0200000000-0xa023fffffff] (bus address [0x40000000-0x7fffffff])
[    2.932396] pci_bus 0002:00: root bus resource [mem 0xa0300000000-0xa037fffffff] (bus address [0x80000000-0xffffffff])
[    2.983827] pci_bus 0002:00: root bus resource [io  0x0000-0xffff]

Here is how the ACPI table looks like:

		QWORDMemory(			// Consumed-And-prodced resource(all of memory space)
			ResourceProducer,	// bit 0 of general flags is 0
			PosDecode,		// positive Decode:  		_DEC
			MinFixed,		// Range is fixed:   		_MIF
			MaxFixed,		// Range is fixed:   		_MAF
			NonCacheable,		// 				_MEM
			ReadWrite,		// 				_RW
			0x00000000,		// Granularity: 	   	_GRA
			0x00100000,		// Min - PCI Memory start: 	_MIN
			0x3FFFFFFF,		// Max - PCI Memory end:   	_MAX
			0xA0100000000,		// Translation: 		_TRA
			0x3FF00000,		// Range Length: 		_LEN
			,			// Optional field left blank
			,			// Optional field left blank
			MEM0,			// Name declaration for this descriptor
			AddressRangeMemory,
			TypeStatic
			) 


Any thoughts?


-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1294743 — Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Tomasz Nowicki <tn@semihalf.com>
Date	2015-12-18 13:30 +0100
Subject	Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qH2kx-5zs-11@gated-at.bofh.it>
In reply to	#1294276

On 17.12.2015 22:24, Sinan Kaya wrote:
> Hi Tomasz,
>
> On 12/16/2015 10:16 AM, Tomasz Nowicki wrote:
>>  From the functionality point of view this series might be split into the
>> following logic parts:
>> 1. Make MMCONFIG code arch-agnostic which allows all architectures to collect
>>     PCI config regions and used when necessary.
>> 2. Move non-arch specific bits to the core code.
>> 3. Use MMCONFIG code and implement generic ACPI based PCI host
>>     controller driver.
>> 4. Enable above driver on ARM64
>>
>> Patches has been built on top of 4.4-rc4 and can be found here:
>> git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v2)
>>
>> NOTE, this patch set depends on Matthew's patches:
>> http://www.spinics.net/lists/linux-pci/msg45950.html
>> https://github.com/Vality/linux/tree/pci-fixes
>>
>> This has been tested on Cavium ThunderX 1 socket server and QEMU.
>> Any help in reviewing and testing is very appreciated.
>>
>> v1 -> v2
>> - moved non-arch specific piece of code to dirver/acpi/ directory
>> - fixed IO resource handling
>> - introduced PCI config accessors quirks matching
>> - moved ACPI_COMPANION_SET to generic code
>>
>
> Just tested your series. I'm seeing a resource assignment problem below.
> The bus addresses show as memory addresses and memory addresses show as
> bus addresses and IO resource did not show up.
>
>
> Tomasz V2
>
> [    2.520852] ACPI: PCI Interrupt Link [LN1C] (IRQs *238)
> [    2.535472] ACPI: PCI Interrupt Link [LN1D] (IRQs *239)
> [    2.550562] ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
> [    2.567813] acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
> [    2.591270] acpi PNP0A08:02: _OSC: platform does not support [PCIeHotplug]
> [    2.611144] acpi PNP0A08:02: _OSC: OS now controls [PME AER PCIeCapability]
> [    2.630299] ACPI: IORT: can't find node related to (null) device
> [    2.647184]_acpi_PNP0A08:02:_PCI_host_bridge_to_bus_0002:00
> [    2.662663] pci_bus 0002:00: root bus resource [mem 0x00100000-0x3fffffff window] (bus address [0xfffff5ff00100000-0xfffff5ff3fffffff])
> [    2.703561] pci_bus 0002:00: root bus resource [mem 0x40000000-0x7fffffff window] (bus address [0xfffff5fe80000000-0xfffff5febfffffff])
> [    2.737737] pci_bus 0002:00: root bus resource [mem 0x80000000-0xffffffff window] (bus address [0xfffff5fe00000000-0xfffff5fe7fffffff])
> [    2.794961] pci_bus 0002:00: root bus resource [bus 00-1f]
>
> Mark Salter's patches
>
> [    2.730011] ACPI: PCI Interrupt Link [LN1C] (IRQs *238)
> [    2.744648] ACPI: PCI Interrupt Link [LN1D] (IRQs *239)
> [    2.759330] ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
> [    2.783295] acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
> [    2.806726] acpi PNP0A08:02: _OSC: platform does not support [PCIeHotplug]
> [    2.826005] acpi PNP0A08:02: _OSC: OS now controls [PME AER PCIeCapability]
> [    2.845361] PCI host bridge to bus 0002:00
> [    2.856719]_pci_bus_0002:00:_root_bus_resource_[bus_00-1f]
> [    2.872056] pci_bus 0002:00: root bus resource [mem 0xa0100100000-0xa013fffffff] (bus address [0x00100000-0x3fffffff])
> [    2.902008] pci_bus 0002:00: root bus resource [mem 0xa0200000000-0xa023fffffff] (bus address [0x40000000-0x7fffffff])
> [    2.932396] pci_bus 0002:00: root bus resource [mem 0xa0300000000-0xa037fffffff] (bus address [0x80000000-0xffffffff])
> [    2.983827] pci_bus 0002:00: root bus resource [io  0x0000-0xffff]
>
> Here is how the ACPI table looks like:
>
> 		QWORDMemory(			// Consumed-And-prodced resource(all of memory space)
> 			ResourceProducer,	// bit 0 of general flags is 0
> 			PosDecode,		// positive Decode:  		_DEC
> 			MinFixed,		// Range is fixed:   		_MIF
> 			MaxFixed,		// Range is fixed:   		_MAF
> 			NonCacheable,		// 				_MEM
> 			ReadWrite,		// 				_RW
> 			0x00000000,		// Granularity: 	   	_GRA
> 			0x00100000,		// Min - PCI Memory start: 	_MIN
> 			0x3FFFFFFF,		// Max - PCI Memory end:   	_MAX
> 			0xA0100000000,		// Translation: 		_TRA
> 			0x3FF00000,		// Range Length: 		_LEN
> 			,			// Optional field left blank
> 			,			// Optional field left blank
> 			MEM0,			// Name declaration for this descriptor
> 			AddressRangeMemory,
> 			TypeStatic
> 			)
>
>
> Any thoughts?
>
>

Yes, this is because of:
[PATCH V2 20/23] ACPI, PCI: Refine the way to handle translation_offset 
for ACPI resources
which should have RFC tag. I posted this patch to re-trigger discussion 
on this.

The patch does not add Translation offset to the MMIO type resource 
start address and for acpi_pci_probe_root_resources(ci) causes problems 
like that. Indeed MMIO has to be fixed.

But IO resource type is more problematic. Actually, how 
acpi_decode_space() should parse resources and which ACPI IO descriptor 
should be used for ARM64: QWORDIO (offset == 0 vs offset != 0), DWordIO 
(TypeStatic vs TypeTranslation) + backward compatibility with IA64...

Please refer to:
https://lkml.org/lkml/2015/11/5/581

As Lorenzo pointed out, we *all* need to agree upon the IO resource ACPI 
descriptor and its parsing method.

Any comments are very appreciated!

Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1295095 — Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	okaya@codeaurora.org
Date	2015-12-18 20:00 +0100
Subject	Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qH8pY-U5-13@gated-at.bofh.it>
In reply to	#1294743

> On 17.12.2015 22:24, Sinan Kaya wrote:
>> Hi Tomasz,
>>
>> On 12/16/2015 10:16 AM, Tomasz Nowicki wrote:
>>>  From the functionality point of view this series might be split into
>>> the
>>> following logic parts:
>>> 1. Make MMCONFIG code arch-agnostic which allows all architectures to
>>> collect
>>>     PCI config regions and used when necessary.
>>> 2. Move non-arch specific bits to the core code.
>>> 3. Use MMCONFIG code and implement generic ACPI based PCI host
>>>     controller driver.
>>> 4. Enable above driver on ARM64
>>>
>>> Patches has been built on top of 4.4-rc4 and can be found here:
>>> git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v2)
>>>
>>> NOTE, this patch set depends on Matthew's patches:
>>> http://www.spinics.net/lists/linux-pci/msg45950.html
>>> https://github.com/Vality/linux/tree/pci-fixes
>>>
>>> This has been tested on Cavium ThunderX 1 socket server and QEMU.
>>> Any help in reviewing and testing is very appreciated.
>>>
>>> v1 -> v2
>>> - moved non-arch specific piece of code to dirver/acpi/ directory
>>> - fixed IO resource handling
>>> - introduced PCI config accessors quirks matching
>>> - moved ACPI_COMPANION_SET to generic code
>>>
>>
>> Just tested your series. I'm seeing a resource assignment problem below.
>> The bus addresses show as memory addresses and memory addresses show as
>> bus addresses and IO resource did not show up.
>>
>>
>> Tomasz V2
>>
>> [    2.520852] ACPI: PCI Interrupt Link [LN1C] (IRQs *238)
>> [    2.535472] ACPI: PCI Interrupt Link [LN1D] (IRQs *239)
>> [    2.550562] ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
>> [    2.567813] acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM
>> ClockPM Segments MSI]
>> [    2.591270] acpi PNP0A08:02: _OSC: platform does not support
>> [PCIeHotplug]
>> [    2.611144] acpi PNP0A08:02: _OSC: OS now controls [PME AER
>> PCIeCapability]
>> [    2.630299] ACPI: IORT: can't find node related to (null) device
>> [    2.647184]_acpi_PNP0A08:02:_PCI_host_bridge_to_bus_0002:00
>> [    2.662663] pci_bus 0002:00: root bus resource [mem
>> 0x00100000-0x3fffffff window] (bus address
>> [0xfffff5ff00100000-0xfffff5ff3fffffff])
>> [    2.703561] pci_bus 0002:00: root bus resource [mem
>> 0x40000000-0x7fffffff window] (bus address
>> [0xfffff5fe80000000-0xfffff5febfffffff])
>> [    2.737737] pci_bus 0002:00: root bus resource [mem
>> 0x80000000-0xffffffff window] (bus address
>> [0xfffff5fe00000000-0xfffff5fe7fffffff])
>> [    2.794961] pci_bus 0002:00: root bus resource [bus 00-1f]
>>
>> Mark Salter's patches
>>
>> [    2.730011] ACPI: PCI Interrupt Link [LN1C] (IRQs *238)
>> [    2.744648] ACPI: PCI Interrupt Link [LN1D] (IRQs *239)
>> [    2.759330] ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
>> [    2.783295] acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM
>> ClockPM Segments MSI]
>> [    2.806726] acpi PNP0A08:02: _OSC: platform does not support
>> [PCIeHotplug]
>> [    2.826005] acpi PNP0A08:02: _OSC: OS now controls [PME AER
>> PCIeCapability]
>> [    2.845361] PCI host bridge to bus 0002:00
>> [    2.856719]_pci_bus_0002:00:_root_bus_resource_[bus_00-1f]
>> [    2.872056] pci_bus 0002:00: root bus resource [mem
>> 0xa0100100000-0xa013fffffff] (bus address [0x00100000-0x3fffffff])
>> [    2.902008] pci_bus 0002:00: root bus resource [mem
>> 0xa0200000000-0xa023fffffff] (bus address [0x40000000-0x7fffffff])
>> [    2.932396] pci_bus 0002:00: root bus resource [mem
>> 0xa0300000000-0xa037fffffff] (bus address [0x80000000-0xffffffff])
>> [    2.983827] pci_bus 0002:00: root bus resource [io  0x0000-0xffff]
>>
>> Here is how the ACPI table looks like:
>>
>> 		QWORDMemory(			// Consumed-And-prodced resource(all of memory space)
>> 			ResourceProducer,	// bit 0 of general flags is 0
>> 			PosDecode,		// positive Decode:  		_DEC
>> 			MinFixed,		// Range is fixed:   		_MIF
>> 			MaxFixed,		// Range is fixed:   		_MAF
>> 			NonCacheable,		// 				_MEM
>> 			ReadWrite,		// 				_RW
>> 			0x00000000,		// Granularity: 	   	_GRA
>> 			0x00100000,		// Min - PCI Memory start: 	_MIN
>> 			0x3FFFFFFF,		// Max - PCI Memory end:   	_MAX
>> 			0xA0100000000,		// Translation: 		_TRA
>> 			0x3FF00000,		// Range Length: 		_LEN
>> 			,			// Optional field left blank
>> 			,			// Optional field left blank
>> 			MEM0,			// Name declaration for this descriptor
>> 			AddressRangeMemory,
>> 			TypeStatic
>> 			)
>>
>>
>> Any thoughts?
>>
>>
>
> Yes, this is because of:
> [PATCH V2 20/23] ACPI, PCI: Refine the way to handle translation_offset
> for ACPI resources
> which should have RFC tag. I posted this patch to re-trigger discussion
> on this.
>
> The patch does not add Translation offset to the MMIO type resource
> start address and for acpi_pci_probe_root_resources(ci) causes problems
> like that. Indeed MMIO has to be fixed.

OK. I assume you'll post a patch for this soon similar to what Liu Jiang
is doing in IA64 directory (arch/ia64/pci/pci.c) as I can't proceed with
my testing without this bugfix.
>
> But IO resource type is more problematic. Actually, how
> acpi_decode_space() should parse resources and which ACPI IO descriptor
> should be used for ARM64: QWORDIO (offset == 0 vs offset != 0), DWordIO
> (TypeStatic vs TypeTranslation) + backward compatibility with IA64...
>
> Please refer to:
> https://lkml.org/lkml/2015/11/5/581
>
> As Lorenzo pointed out, we *all* need to agree upon the IO resource ACPI
> descriptor and its parsing method.

Here is what I have as an IO resource.

		QWORDIO(			//Consumed-And-produced resource
			ResourceProducer,	// bit 0 of general flags is 0
			MinFixed,		// Range is fixed
			MaxFixed,		// Range is fixed
			PosDecode,
			EntireRange,
			0x0000,			// Granularity
			0x1000,		// Min, 0 is not accepted
			0x10FFF,		// Max
			0x8FFFFFEF000,	// Translation
			0x10000,		// Range Length
			,, PI00
		 )

I don't have any type specified.

I agree with Lorenzo's assessment. The min and max values represent the
PCI IO bus addresses. The translation offset is added to these values to
figure out the CPU view of the PCI IO range.

The endpoints BAR addresses are programmed with IO addresses ranging
between 0x1000 and 0x10FFF for this example above.

Here is another question. Chris Covington and I asked this question on a
private email to you but we didn't hear back.

We were referring to a Linaro IO hack patch as we were not sure whether
this was a limitation of the hack or a general expectation for ARM64 PCI
in general.

I'll repeat it here.

I have multiple root ports with the same IO port configuration in the
current ACPI table.

Root port 0 = IO range 0x1000-0x10FFF
Root port 1 = IO range 0x1000-0x10FFF
Root port 2 = IO range 0x1000-0x10FFF

Each root port can have the same IO address range configuration, are we
expecting IO port numbers to be unique across the whole system for ARM64?

Something like

Root port 0 = IO range 0x1000-0x10FFF
Root port 1 = IO range 0x11000-0x20FFF
Root port 2 = IO range 0x21000-0x30FFF

since the IO addresses are being remapped into PCI IO range printed during
boot.

PCI I/O : 0xffff7ffffae00000 - 0xffff7ffffbe00000   (    16 MB)

and each root port would remap to 64k of the 16MB range.

>
> Any comments are very appreciated!
>
> Tomasz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1295898 — Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Tomasz Nowicki <tn@semihalf.com>
Date	2015-12-21 11:40 +0100
Subject	Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qI62K-5iw-21@gated-at.bofh.it>
In reply to	#1295095

On 18.12.2015 19:56, okaya@codeaurora.org wrote:
>> On 17.12.2015 22:24, Sinan Kaya wrote:
>>> Hi Tomasz,
>>>
>>> On 12/16/2015 10:16 AM, Tomasz Nowicki wrote:
>>>>   From the functionality point of view this series might be split into
>>>> the
>>>> following logic parts:
>>>> 1. Make MMCONFIG code arch-agnostic which allows all architectures to
>>>> collect
>>>>      PCI config regions and used when necessary.
>>>> 2. Move non-arch specific bits to the core code.
>>>> 3. Use MMCONFIG code and implement generic ACPI based PCI host
>>>>      controller driver.
>>>> 4. Enable above driver on ARM64
>>>>
>>>> Patches has been built on top of 4.4-rc4 and can be found here:
>>>> git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v2)
>>>>
>>>> NOTE, this patch set depends on Matthew's patches:
>>>> http://www.spinics.net/lists/linux-pci/msg45950.html
>>>> https://github.com/Vality/linux/tree/pci-fixes
>>>>
>>>> This has been tested on Cavium ThunderX 1 socket server and QEMU.
>>>> Any help in reviewing and testing is very appreciated.
>>>>
>>>> v1 -> v2
>>>> - moved non-arch specific piece of code to dirver/acpi/ directory
>>>> - fixed IO resource handling
>>>> - introduced PCI config accessors quirks matching
>>>> - moved ACPI_COMPANION_SET to generic code
>>>>
>>>
>>> Just tested your series. I'm seeing a resource assignment problem below.
>>> The bus addresses show as memory addresses and memory addresses show as
>>> bus addresses and IO resource did not show up.
>>>
>>>
>>> Tomasz V2
>>>
>>> [    2.520852] ACPI: PCI Interrupt Link [LN1C] (IRQs *238)
>>> [    2.535472] ACPI: PCI Interrupt Link [LN1D] (IRQs *239)
>>> [    2.550562] ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
>>> [    2.567813] acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM
>>> ClockPM Segments MSI]
>>> [    2.591270] acpi PNP0A08:02: _OSC: platform does not support
>>> [PCIeHotplug]
>>> [    2.611144] acpi PNP0A08:02: _OSC: OS now controls [PME AER
>>> PCIeCapability]
>>> [    2.630299] ACPI: IORT: can't find node related to (null) device
>>> [    2.647184]_acpi_PNP0A08:02:_PCI_host_bridge_to_bus_0002:00
>>> [    2.662663] pci_bus 0002:00: root bus resource [mem
>>> 0x00100000-0x3fffffff window] (bus address
>>> [0xfffff5ff00100000-0xfffff5ff3fffffff])
>>> [    2.703561] pci_bus 0002:00: root bus resource [mem
>>> 0x40000000-0x7fffffff window] (bus address
>>> [0xfffff5fe80000000-0xfffff5febfffffff])
>>> [    2.737737] pci_bus 0002:00: root bus resource [mem
>>> 0x80000000-0xffffffff window] (bus address
>>> [0xfffff5fe00000000-0xfffff5fe7fffffff])
>>> [    2.794961] pci_bus 0002:00: root bus resource [bus 00-1f]
>>>
>>> Mark Salter's patches
>>>
>>> [    2.730011] ACPI: PCI Interrupt Link [LN1C] (IRQs *238)
>>> [    2.744648] ACPI: PCI Interrupt Link [LN1D] (IRQs *239)
>>> [    2.759330] ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 00-1f])
>>> [    2.783295] acpi PNP0A08:02: _OSC: OS supports [ExtendedConfig ASPM
>>> ClockPM Segments MSI]
>>> [    2.806726] acpi PNP0A08:02: _OSC: platform does not support
>>> [PCIeHotplug]
>>> [    2.826005] acpi PNP0A08:02: _OSC: OS now controls [PME AER
>>> PCIeCapability]
>>> [    2.845361] PCI host bridge to bus 0002:00
>>> [    2.856719]_pci_bus_0002:00:_root_bus_resource_[bus_00-1f]
>>> [    2.872056] pci_bus 0002:00: root bus resource [mem
>>> 0xa0100100000-0xa013fffffff] (bus address [0x00100000-0x3fffffff])
>>> [    2.902008] pci_bus 0002:00: root bus resource [mem
>>> 0xa0200000000-0xa023fffffff] (bus address [0x40000000-0x7fffffff])
>>> [    2.932396] pci_bus 0002:00: root bus resource [mem
>>> 0xa0300000000-0xa037fffffff] (bus address [0x80000000-0xffffffff])
>>> [    2.983827] pci_bus 0002:00: root bus resource [io  0x0000-0xffff]
>>>
>>> Here is how the ACPI table looks like:
>>>
>>> 		QWORDMemory(			// Consumed-And-prodced resource(all of memory space)
>>> 			ResourceProducer,	// bit 0 of general flags is 0
>>> 			PosDecode,		// positive Decode:  		_DEC
>>> 			MinFixed,		// Range is fixed:   		_MIF
>>> 			MaxFixed,		// Range is fixed:   		_MAF
>>> 			NonCacheable,		// 				_MEM
>>> 			ReadWrite,		// 				_RW
>>> 			0x00000000,		// Granularity: 	   	_GRA
>>> 			0x00100000,		// Min - PCI Memory start: 	_MIN
>>> 			0x3FFFFFFF,		// Max - PCI Memory end:   	_MAX
>>> 			0xA0100000000,		// Translation: 		_TRA
>>> 			0x3FF00000,		// Range Length: 		_LEN
>>> 			,			// Optional field left blank
>>> 			,			// Optional field left blank
>>> 			MEM0,			// Name declaration for this descriptor
>>> 			AddressRangeMemory,
>>> 			TypeStatic
>>> 			)
>>>
>>>
>>> Any thoughts?
>>>
>>>
>>
>> Yes, this is because of:
>> [PATCH V2 20/23] ACPI, PCI: Refine the way to handle translation_offset
>> for ACPI resources
>> which should have RFC tag. I posted this patch to re-trigger discussion
>> on this.
>>
>> The patch does not add Translation offset to the MMIO type resource
>> start address and for acpi_pci_probe_root_resources(ci) causes problems
>> like that. Indeed MMIO has to be fixed.
>
> OK. I assume you'll post a patch for this soon similar to what Liu Jiang
> is doing in IA64 directory (arch/ia64/pci/pci.c) as I can't proceed with
> my testing without this bugfix.
>>
>> But IO resource type is more problematic. Actually, how
>> acpi_decode_space() should parse resources and which ACPI IO descriptor
>> should be used for ARM64: QWORDIO (offset == 0 vs offset != 0), DWordIO
>> (TypeStatic vs TypeTranslation) + backward compatibility with IA64...
>>
>> Please refer to:
>> https://lkml.org/lkml/2015/11/5/581
>>
>> As Lorenzo pointed out, we *all* need to agree upon the IO resource ACPI
>> descriptor and its parsing method.
>
> Here is what I have as an IO resource.
>
> 		QWORDIO(			//Consumed-And-produced resource
> 			ResourceProducer,	// bit 0 of general flags is 0
> 			MinFixed,		// Range is fixed
> 			MaxFixed,		// Range is fixed
> 			PosDecode,
> 			EntireRange,
> 			0x0000,			// Granularity
> 			0x1000,		// Min, 0 is not accepted
> 			0x10FFF,		// Max
> 			0x8FFFFFEF000,	// Translation
> 			0x10000,		// Range Length
> 			,, PI00
> 		 )
>
> I don't have any type specified.
>
> I agree with Lorenzo's assessment. The min and max values represent the
> PCI IO bus addresses. The translation offset is added to these values to
> figure out the CPU view of the PCI IO range.
>
> The endpoints BAR addresses are programmed with IO addresses ranging
> between 0x1000 and 0x10FFF for this example above.
>
> Here is another question. Chris Covington and I asked this question on a
> private email to you but we didn't hear back.

I have not seen any mails like that in my mail box, unless you sent it 
to linaro one, which is not accessible for me any more. Please use @semihalf

>
> We were referring to a Linaro IO hack patch as we were not sure whether
> this was a limitation of the hack or a general expectation for ARM64 PCI
> in general.
>
> I'll repeat it here.
>
> I have multiple root ports with the same IO port configuration in the
> current ACPI table.
>
> Root port 0 = IO range 0x1000-0x10FFF
> Root port 1 = IO range 0x1000-0x10FFF
> Root port 2 = IO range 0x1000-0x10FFF
>
> Each root port can have the same IO address range configuration, are we
> expecting IO port numbers to be unique across the whole system for ARM64?

Looking at pci_register_io_range which is currently used on ARM64 I 
would say, no you can't have the same CPU addressable IO ranges.

pci_register_io_range does not allow to use regions which overlap each 
other.

Bjorn, Arnd, Will, any opinion on this apart from current code restrictions?

Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1295939 — Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Date	2015-12-21 13:10 +0100
Subject	Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qI7rP-6j3-7@gated-at.bofh.it>
In reply to	#1295095

On Fri, Dec 18, 2015 at 06:56:39PM +0000, okaya@codeaurora.org wrote:

[...]

> Here is what I have as an IO resource.
> 
> 		QWORDIO(			//Consumed-And-produced resource
> 			ResourceProducer,	// bit 0 of general flags is 0
> 			MinFixed,		// Range is fixed
> 			MaxFixed,		// Range is fixed
> 			PosDecode,
> 			EntireRange,
> 			0x0000,			// Granularity
> 			0x1000,		// Min, 0 is not accepted
> 			0x10FFF,		// Max
> 			0x8FFFFFEF000,	// Translation
> 			0x10000,		// Range Length
> 			,, PI00
> 		 )
> 
> I don't have any type specified.
> 
> I agree with Lorenzo's assessment. The min and max values represent the
> PCI IO bus addresses. The translation offset is added to these values to
> figure out the CPU view of the PCI IO range.
> 
> The endpoints BAR addresses are programmed with IO addresses ranging
> between 0x1000 and 0x10FFF for this example above.
> 
> Here is another question. Chris Covington and I asked this question on a
> private email to you but we didn't hear back.
> 
> We were referring to a Linaro IO hack patch as we were not sure whether
> this was a limitation of the hack or a general expectation for ARM64 PCI
> in general.
> 
> I'll repeat it here.
> 
> I have multiple root ports with the same IO port configuration in the
> current ACPI table.
> 
> Root port 0 = IO range 0x1000-0x10FFF
> Root port 1 = IO range 0x1000-0x10FFF
> Root port 2 = IO range 0x1000-0x10FFF

It is fine. You end up mapping for each of those a 4k window of the
virtual address space allocated to IO and that's what you will have in
the kernel PCI resources (not in the HW BARs though). If that was a problem
it would be even for the current DT host controllers eg:

arch/arm64/boot/dts/apm/apm-storm.dtsi

it should not be (again I will let Arnd comment on this since he may be
aware of issues encountered on other arches/platforms).

Lorenzo

> 
> Each root port can have the same IO address range configuration, are we
> expecting IO port numbers to be unique across the whole system for ARM64?
> 
> Something like
> 
> Root port 0 = IO range 0x1000-0x10FFF
> Root port 1 = IO range 0x11000-0x20FFF
> Root port 2 = IO range 0x21000-0x30FFF
> 
> since the IO addresses are being remapped into PCI IO range printed during
> boot.
> 
> PCI I/O : 0xffff7ffffae00000 - 0xffff7ffffbe00000   (    16 MB)
> 
> and each root port would remap to 64k of the 16MB range.
> 
> >
> > Any comments are very appreciated!
> >
> > Tomasz
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1295959 — Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Tomasz Nowicki <tn@semihalf.com>
Date	2015-12-21 13:50 +0100
Subject	Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qI84y-6zh-13@gated-at.bofh.it>
In reply to	#1295939

On 21.12.2015 13:10, Lorenzo Pieralisi wrote:
> On Fri, Dec 18, 2015 at 06:56:39PM +0000, okaya@codeaurora.org wrote:
>
> [...]
>
>> Here is what I have as an IO resource.
>>
>> 		QWORDIO(			//Consumed-And-produced resource
>> 			ResourceProducer,	// bit 0 of general flags is 0
>> 			MinFixed,		// Range is fixed
>> 			MaxFixed,		// Range is fixed
>> 			PosDecode,
>> 			EntireRange,
>> 			0x0000,			// Granularity
>> 			0x1000,		// Min, 0 is not accepted
>> 			0x10FFF,		// Max
>> 			0x8FFFFFEF000,	// Translation
>> 			0x10000,		// Range Length
>> 			,, PI00
>> 		 )
>>
>> I don't have any type specified.
>>
>> I agree with Lorenzo's assessment. The min and max values represent the
>> PCI IO bus addresses. The translation offset is added to these values to
>> figure out the CPU view of the PCI IO range.
>>
>> The endpoints BAR addresses are programmed with IO addresses ranging
>> between 0x1000 and 0x10FFF for this example above.
>>
>> Here is another question. Chris Covington and I asked this question on a
>> private email to you but we didn't hear back.
>>
>> We were referring to a Linaro IO hack patch as we were not sure whether
>> this was a limitation of the hack or a general expectation for ARM64 PCI
>> in general.
>>
>> I'll repeat it here.
>>
>> I have multiple root ports with the same IO port configuration in the
>> current ACPI table.
>>
>> Root port 0 = IO range 0x1000-0x10FFF
>> Root port 1 = IO range 0x1000-0x10FFF
>> Root port 2 = IO range 0x1000-0x10FFF
>
> It is fine. You end up mapping for each of those a 4k window of the
> virtual address space allocated to IO and that's what you will have in
> the kernel PCI resources (not in the HW BARs though). If that was a problem
> it would be even for the current DT host controllers eg:
>
> arch/arm64/boot/dts/apm/apm-storm.dtsi
>
> it should not be (again I will let Arnd comment on this since he may be
> aware of issues encountered on other arches/platforms).
>

Root port 0 = IO range 0x1000-0x10FFF
Root port 1 = IO range 0x1000-0x10FFF
Root port 2 = IO range 0x1000-0x10FFF

If above ranges are mapped into different CPU windows, then yes, it is fine.

Tomasz

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1295994

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-12-21 15:20 +0100
Message-ID	<qI9tE-7wV-5@gated-at.bofh.it>
In reply to	#1295959

On Monday 21 December 2015, Tomasz Nowicki wrote:
> On 21.12.2015 13:10, Lorenzo Pieralisi wrote:
> > On Fri, Dec 18, 2015 at 06:56:39PM +0000, okaya@codeaurora.org wrote:

> >> I have multiple root ports with the same IO port configuration in the
> >> current ACPI table.
> >>
> >> Root port 0 = IO range 0x1000-0x10FFF
> >> Root port 1 = IO range 0x1000-0x10FFF
> >> Root port 2 = IO range 0x1000-0x10FFF
> >
> > It is fine. You end up mapping for each of those a 4k window of the
> > virtual address space allocated to IO and that's what you will have in
> > the kernel PCI resources (not in the HW BARs though). If that was a problem
> > it would be even for the current DT host controllers eg:
> >
> > arch/arm64/boot/dts/apm/apm-storm.dtsi
> >
> > it should not be (again I will let Arnd comment on this since he may be
> > aware of issues encountered on other arches/platforms).
> >
> 
> Root port 0 = IO range 0x1000-0x10FFF
> Root port 1 = IO range 0x1000-0x10FFF
> Root port 2 = IO range 0x1000-0x10FFF
> 
> If above ranges are mapped into different CPU windows, then yes, it is fine.

Ideally, they should all be the same CPU address so we only have to map the window
once, each device gets an address below 64K, and you can have legacy port numbers
(below 4K) on any bus, which is required to make certain GPUs work.

I haven't actually seen anyone do that on ARM though, every implementation so
far has a separate mapping per host bridge, and we can cope with that too,
and we can live with either overlapping bus addresses or unique bus addresses,
any of them can be expressed by the PCI core in Linux, we just have to make sure
that we correctly translate the firmware tables into our internal structures.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296034 — Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Okaya@codeaurora.org
Date	2015-12-21 16:30 +0100
Subject	Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qIazo-8bx-3@gated-at.bofh.it>
In reply to	#1295994

> On Monday 21 December 2015, Tomasz Nowicki wrote:
>> On 21.12.2015 13:10, Lorenzo Pieralisi wrote:
>> > On Fri, Dec 18, 2015 at 06:56:39PM +0000, okaya@codeaurora.org wrote:
>
>> >> I have multiple root ports with the same IO port configuration in the
>> >> current ACPI table.
>> >>
>> >> Root port 0 = IO range 0x1000-0x10FFF
>> >> Root port 1 = IO range 0x1000-0x10FFF
>> >> Root port 2 = IO range 0x1000-0x10FFF
>> >
>> > It is fine. You end up mapping for each of those a 4k window of the
>> > virtual address space allocated to IO and that's what you will have in
>> > the kernel PCI resources (not in the HW BARs though). If that was a
>> problem
>> > it would be even for the current DT host controllers eg:
>> >
>> > arch/arm64/boot/dts/apm/apm-storm.dtsi
>> >
>> > it should not be (again I will let Arnd comment on this since he may
>> be
>> > aware of issues encountered on other arches/platforms).
>> >
>>
>> Root port 0 = IO range 0x1000-0x10FFF
>> Root port 1 = IO range 0x1000-0x10FFF
>> Root port 2 = IO range 0x1000-0x10FFF
>>
>> If above ranges are mapped into different CPU windows, then yes, it is
>> fine.
>
> Ideally, they should all be the same CPU address so we only have to map
> the window
> once, each device gets an address below 64K, and you can have legacy port
> numbers
> (below 4K) on any bus, which is required to make certain GPUs work.
>
> I haven't actually seen anyone do that on ARM though, every implementation
> so
> far has a separate mapping per host bridge, and we can cope with that too,
> and we can live with either overlapping bus addresses or unique bus
> addresses,
> any of them can be expressed by the PCI core in Linux, we just have to
> make sure
> that we correctly translate the firmware tables into our internal
> structures.
>
> 	Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Thanks, I won't be touching the acpi tables then and I will assume the
hack had a problem. It was trying to remap the io range of the second root
port  to the first port io address map.

I was getting a warning from resource.c

Btw, when I tested the io ranges before, kernel didn't accept anything
below 1k like 0. That is why my range starts at 1k.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1296266

From	Arnd Bergmann <arnd@arndb.de>
Date	2015-12-21 23:50 +0100
Message-ID	<qIhrc-43h-11@gated-at.bofh.it>
In reply to	#1296034

On Monday 21 December 2015, Okaya@codeaurora.org wrote:
> Thanks, I won't be touching the acpi tables then and I will assume the
> hack had a problem. It was trying to remap the io range of the second root
> port  to the first port io address map.

If all domains share the same I/O space, you should only map it once
of course.

> I was getting a warning from resource.c
> 
> Btw, when I tested the io ranges before, kernel didn't accept anything
> below 1k like 0. That is why my range starts at 1k.

This is PCIBIOS_MIN_IO, it defines what I/O port numbers can be dynamically
assigned to PCI devices, but you should still map the entire 64K area per
domain, including the first 4K that can be used for legacy ISA compatibility.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

csiph-web

[PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

Contents

#1293032 — [PATCH V2 04/23] x86, pci: mmconfig_{32,64}.c code refactoring - remove code duplication.

#1293033 — [PATCH V2 02/23] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory

#1294276 — Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1294743 — Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1295095 — Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1295898 — Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1295939 — Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1295959 — Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1295994

#1296034 — Re: [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1296266