Groups > linux.kernel > #1308403 > unrolled thread

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

Started by	Tomasz Nowicki <tn@semihalf.com>
First post	2016-01-13 14:30 +0100
Last post	2016-01-15 00:00 +0100
Articles	20 on this page of 27 — 7 participants

Back to article view | Back to linux.kernel

  [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI Tomasz Nowicki <tn@semihalf.com> - 2016-01-13 14:30 +0100
    [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources Tomasz Nowicki <tn@semihalf.com> - 2016-01-13 14:30 +0100
      Re: [PATCH V3 18/21] ACPI, PCI: Refine the way to handle  translation_offset for ACPI resources Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-01-14 13:20 +0100
    [PATCH V3 02/21] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory Tomasz Nowicki <tn@semihalf.com> - 2016-01-13 14:30 +0100
    [PATCH V3 17/21] acpi, mcfg: Add default PCI config accessors implementation and initial support for related quirks. Tomasz Nowicki <tn@semihalf.com> - 2016-01-13 14:30 +0100
    [PATCH V3 13/21] pci, acpi: Provide generic way to assign bus domain number. Tomasz Nowicki <tn@semihalf.com> - 2016-01-13 14:30 +0100
    [PATCH V3 06/21] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y Tomasz Nowicki <tn@semihalf.com> - 2016-01-13 14:30 +0100
    Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Tomasz Nowicki <tn@semihalf.com> - 2016-01-13 16:30 +0100
    Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Sinan Kaya <okaya@codeaurora.org> - 2016-01-13 16:30 +0100
    Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Graeme Gregory <gg@slimlogic.co.uk> - 2016-01-14 14:50 +0100
      Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Mark Salter <msalter@redhat.com> - 2016-01-14 15:10 +0100
        Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Graeme Gregory <gg@slimlogic.co.uk> - 2016-01-14 15:20 +0100
          Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Mark Salter <msalter@redhat.com> - 2016-01-14 15:30 +0100
      Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Catalin Marinas <catalin.marinas@arm.com> - 2016-01-14 15:10 +0100
        Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Mark Salter <msalter@redhat.com> - 2016-01-14 15:20 +0100
          Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Catalin Marinas <catalin.marinas@arm.com> - 2016-01-14 16:00 +0100
            Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Mark Salter <msalter@redhat.com> - 2016-01-14 16:10 +0100
    Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Sinan Kaya <okaya@codeaurora.org> - 2016-01-14 16:40 +0100
      Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-01-14 17:20 +0100
        Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Mark Salter <msalter@redhat.com> - 2016-01-14 17:40 +0100
          Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-01-14 18:10 +0100
            Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Mark Salter <msalter@redhat.com> - 2016-01-14 18:40 +0100
              Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> - 2016-01-14 19:00 +0100
                Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Mark Salter <msalter@redhat.com> - 2016-01-14 19:50 +0100
    Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Mark Salter <msalter@redhat.com> - 2016-01-14 16:40 +0100
      Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Jeremy Linton <jeremy.linton@arm.com> - 2016-01-15 00:00 +0100
    Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI  hostbridge init based on ACPI Jeremy Linton <jeremy.linton@arm.com> - 2016-01-15 00:00 +0100

Page 1 of 2 [1] 2 Next page →

#1308403 — [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Tomasz Nowicki <tn@semihalf.com>
Date	2016-01-13 14:30 +0100
Subject	[PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qQtES-hT-3@gated-at.bofh.it>

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 and can be found here:
git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v3)

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 server and QEMU.
Any help in reviewing and testing is very appreciated.

v2 -> v3
- fix legacy IRQ assigning and IO ports registration
- remove reference to arch specific companion device for ia64
- move ACPI PCI host controller driver to pci_root.c
- drop generic domain assignment for x86 and ia64 as I am not
  able to run all necessary test variants
- drop patch which cleaned legacy IRQ assignment since it belongs to
  Mathew's series:
  https://patchwork.ozlabs.org/patch/557504/
- extend MCFG quirk code
- rebased to 4.4

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

Liu Jiang (1):
  ACPI, PCI: Refine the way to handle translation_offset for ACPI
    resources

Tomasz Nowicki (20):
  x86, pci: Reorder logic of pci_mmconfig_insert() function
  x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code
    out of arch/x86/ directory
  pci, acpi, mcfg: Provide generic implementation of MCFG code
    initialization.
  x86, pci: mmconfig_{32,64}.c code refactoring - remove code
    duplication.
  x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM
    driver.
  XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y
  pci, acpi, mcfg: Provide default RAW ACPI PCI config space accessors.
  arm64, acpi: Use empty PCI config space accessors from mcfg.c file.
  pci, acpi, ecam: Add flag to indicate whether ECAM region was hot
    added or not.
  x86, pci: Cleanup platform specific MCFG data using previously added
    ECAM hot_added flag.
  pci, acpi: Move ACPI host bridge device companion assignment to core
    code.
  x86, ia64, pci: Remove ACPI companion device from platform specific
    data.
  pci, acpi: Provide generic way to assign bus domain number.
  x86, ia64: Include acpi_pci_{add|remove}_bus to the default
    pcibios_{add|remove}_bus implementation.
  acpi, mcfg: Implement two calls that might be used to inject/remove
    MCFG region.
  x86, acpi, pci: Use equivalent function introduced in previous patch.
  acpi, mcfg: Add default PCI config accessors implementation and
    initial support for related quirks.
  pci, acpi: Support for ACPI based generic PCI host controller init
  pci, acpi: Match PCI config space accessors against platfrom specific
    quirks.
  arm64, pci, acpi: Start using ACPI based PCI host bridge driver for
    ARM64.

 arch/arm64/Kconfig                 |   7 ++
 arch/arm64/kernel/pci.c            |  25 ----
 arch/ia64/hp/common/sba_iommu.c    |   2 +-
 arch/ia64/include/asm/pci.h        |   1 -
 arch/ia64/pci/pci.c                |  52 +++-----
 arch/ia64/sn/kernel/io_acpi_init.c |   4 +-
 arch/x86/Kconfig                   |   4 +
 arch/x86/include/asm/pci.h         |   3 -
 arch/x86/include/asm/pci_x86.h     |  28 +----
 arch/x86/pci/acpi.c                |  41 ++----
 arch/x86/pci/common.c              |  10 --
 arch/x86/pci/irq.c                 |  10 --
 arch/x86/pci/mmconfig-shared.c     | 250 ++++++-------------------------------
 arch/x86/pci/mmconfig_32.c         |  11 +-
 arch/x86/pci/mmconfig_64.c         |  67 +---------
 arch/x86/pci/numachip.c            |   1 +
 drivers/acpi/Kconfig               |   5 +
 drivers/acpi/Makefile              |   1 +
 drivers/acpi/mcfg.c                | 201 +++++++++++++++++++++++++++++
 drivers/acpi/pci_root.c            | 136 +++++++++++++++++++-
 drivers/acpi/resource.c            |  12 +-
 drivers/pci/Kconfig                |  10 ++
 drivers/pci/Makefile               |   5 +
 drivers/pci/ecam.c                 | 234 ++++++++++++++++++++++++++++++++++
 drivers/pci/pci.c                  |  29 ++++-
 drivers/pci/probe.c                |   5 +
 drivers/xen/pci.c                  |   7 +-
 include/acpi/acpi_bus.h            |   1 +
 include/asm-generic/vmlinux.lds.h  |   7 ++
 include/linux/acpi.h               |   2 +
 include/linux/ecam.h               |  62 +++++++++
 include/linux/pci-acpi.h           |  17 +++
 32 files changed, 802 insertions(+), 448 deletions(-)
 create mode 100644 drivers/acpi/mcfg.c
 create mode 100644 drivers/pci/ecam.c
 create mode 100644 include/linux/ecam.h

-- 
1.9.1

[toc] | [next] | [standalone]

#1308404 — [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources

From	Tomasz Nowicki <tn@semihalf.com>
Date	2016-01-13 14:30 +0100
Subject	[PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
Message-ID	<qQtEU-hT-55@gated-at.bofh.it>
In reply to	#1308403

From: Liu Jiang <jiang.liu@linux.intel.com>

Some architectures, such as IA64 and ARM64, have no instructions to
directly access PCI IO ports, so they map PCI IO ports into PCI MMIO
address space. Typically PCI host bridges on those architectures take
the responsibility to map (translate) PCI IO port transactions into
Memory-Mapped IO transactions. ACPI specification provides support
of such a usage case by using resource translation_offset.

But current ACPI resource parsing interface isn't neutral enough,
it still has some special logic for IA64. So refine the ACPI resource
parsing interface and IA64 code to neutrally handle translation_offset
by:
1) ACPI resource parsing interface doesn't do any translation, it just
   save the translation_offset to be used by arch code.
2) Arch code will do the mapping(translation) based on arch specific
   information. Typically it does:
2.a) Translate per PCI domain IO port address space into system global
   IO port address space.
2.b) Setup MMIO address mapping for IO ports.
void handle_io_resource(struct resource_entry *io_entry)
{
	struct resource *mmio_res;

	mmio_res = kzalloc(sizeof(*mmio_res), GFP_KERNEL);
	mmio_res->flags = IORESOURCE_MEM;
	mmio_res->start = io_entry->offset + io_entry->res->start;
	mmio_res->end = io_entry->offset + io_entry->res->end;
	insert_resource(&iomem_resource, mmio_res)

	base = map_to_system_ioport_address(entry);
	io_entry->offset = base;
	io_entry->res->start += base;
	io_entry->res->end += base;
}

Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
---
 arch/ia64/pci/pci.c     | 26 ++++++++++++++++----------
 drivers/acpi/resource.c | 12 +++++-------
 2 files changed, 21 insertions(+), 17 deletions(-)

diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index be4c9ef..c75356b 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -154,7 +154,7 @@ static int add_io_space(struct device *dev, struct pci_root_info *info,
 	struct resource_entry *iospace;
 	struct resource *resource, *res = entry->res;
 	char *name;
-	unsigned long base, min, max, base_port;
+	unsigned long base_mmio, base_port;
 	unsigned int sparse = 0, space_nr, len;
 
 	len = strlen(info->common.name) + 32;
@@ -172,12 +172,10 @@ static int add_io_space(struct device *dev, struct pci_root_info *info,
 		goto free_resource;
 
 	name = (char *)(iospace + 1);
-	min = res->start - entry->offset;
-	max = res->end - entry->offset;
-	base = __pa(io_space[space_nr].mmio_base);
+	base_mmio = __pa(io_space[space_nr].mmio_base);
 	base_port = IO_SPACE_BASE(space_nr);
 	snprintf(name, len, "%s I/O Ports %08lx-%08lx", info->common.name,
-		 base_port + min, base_port + max);
+		 base_port + res->start, base_port + res->end);
 
 	/*
 	 * The SDM guarantees the legacy 0-64K space is sparse, but if the
@@ -190,19 +188,27 @@ static int add_io_space(struct device *dev, struct pci_root_info *info,
 	resource = iospace->res;
 	resource->name  = name;
 	resource->flags = IORESOURCE_MEM;
-	resource->start = base + (sparse ? IO_SPACE_SPARSE_ENCODING(min) : min);
-	resource->end   = base + (sparse ? IO_SPACE_SPARSE_ENCODING(max) : max);
+	resource->start = base_mmio;
+	resource->end = base_mmio;
+	if (sparse) {
+		resource->start += IO_SPACE_SPARSE_ENCODING(res->start);
+		resource->end += IO_SPACE_SPARSE_ENCODING(res->end);
+	} else {
+		resource->start += res->start;
+		resource->end += res->end;
+	}
 	if (insert_resource(&iomem_resource, resource)) {
 		dev_err(dev,
 			"can't allocate host bridge io space resource  %pR\n",
 			resource);
 		goto free_resource;
 	}
+	resource_list_add_tail(iospace, &info->io_resources);
 
+	/* Adjust base of original IO port resource descriptor */
 	entry->offset = base_port;
-	res->start = min + base_port;
-	res->end = max + base_port;
-	resource_list_add_tail(iospace, &info->io_resources);
+	res->start += base_port;
+	res->end += base_port;
 
 	return 0;
 
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index cdc5c25..6578f68 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -190,8 +190,7 @@ static bool acpi_decode_space(struct resource_win *win,
 {
 	u8 iodec = attr->granularity == 0xfff ? ACPI_DECODE_10 : ACPI_DECODE_16;
 	bool wp = addr->info.mem.write_protect;
-	u64 len = attr->address_length;
-	u64 start, end, offset = 0;
+	u64 len = attr->address_length, offset = 0;
 	struct resource *res = &win->res;
 
 	/*
@@ -215,14 +214,13 @@ static bool acpi_decode_space(struct resource_win *win,
 	else if (attr->translation_offset)
 		pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
 			 attr->translation_offset);
-	start = attr->minimum + offset;
-	end = attr->maximum + offset;
 
 	win->offset = offset;
-	res->start = start;
-	res->end = end;
+	res->start = attr->minimum;
+	res->end = attr->maximum;
 	if (sizeof(resource_size_t) < sizeof(u64) &&
-	    (offset != win->offset || start != res->start || end != res->end)) {
+	    (offset != win->offset || attr->minimum != res->start ||
+	     attr->maximum != res->end)) {
 		pr_warn("acpi resource window ([%#llx-%#llx] ignored, not CPU addressable)\n",
 			attr->minimum, attr->maximum);
 		return false;
-- 
1.9.1

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

#1309216 — Re: [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources

From	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Date	2016-01-14 13:20 +0100
Subject	Re: [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
Message-ID	<qQP2G-6Qm-3@gated-at.bofh.it>
In reply to	#1308404

Gerry, Tomasz,

On Wed, Jan 13, 2016 at 02:21:04PM +0100, Tomasz Nowicki wrote:
> From: Liu Jiang <jiang.liu@linux.intel.com>
> 
> Some architectures, such as IA64 and ARM64, have no instructions to
> directly access PCI IO ports, so they map PCI IO ports into PCI MMIO
> address space. Typically PCI host bridges on those architectures take
> the responsibility to map (translate) PCI IO port transactions into
> Memory-Mapped IO transactions. ACPI specification provides support
> of such a usage case by using resource translation_offset.
> 
> But current ACPI resource parsing interface isn't neutral enough,
> it still has some special logic for IA64. So refine the ACPI resource
> parsing interface and IA64 code to neutrally handle translation_offset
> by:
> 1) ACPI resource parsing interface doesn't do any translation, it just
>    save the translation_offset to be used by arch code.
> 2) Arch code will do the mapping(translation) based on arch specific
>    information. Typically it does:
> 2.a) Translate per PCI domain IO port address space into system global
>    IO port address space.
> 2.b) Setup MMIO address mapping for IO ports.
> void handle_io_resource(struct resource_entry *io_entry)
> {
> 	struct resource *mmio_res;
> 
> 	mmio_res = kzalloc(sizeof(*mmio_res), GFP_KERNEL);
> 	mmio_res->flags = IORESOURCE_MEM;
> 	mmio_res->start = io_entry->offset + io_entry->res->start;
> 	mmio_res->end = io_entry->offset + io_entry->res->end;
> 	insert_resource(&iomem_resource, mmio_res)
> 
> 	base = map_to_system_ioport_address(entry);
> 	io_entry->offset = base;
> 	io_entry->res->start += base;
> 	io_entry->res->end += base;
> }
> 
> Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
> ---
>  arch/ia64/pci/pci.c     | 26 ++++++++++++++++----------
>  drivers/acpi/resource.c | 12 +++++-------
>  2 files changed, 21 insertions(+), 17 deletions(-)

I still do not understand what TranslationType argument means in the
ACPI specifications Resource descriptors (if you do not check it in
generic code that info is not propagated to arches through the resources
so basically we ignore it - I do not think we can do anything else given
that on ia64 it is missing from ACPI tables), but this patch makes sense
to me (it needs testing/reviewing for ia64 though):

Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
> index be4c9ef..c75356b 100644
> --- a/arch/ia64/pci/pci.c
> +++ b/arch/ia64/pci/pci.c
> @@ -154,7 +154,7 @@ static int add_io_space(struct device *dev, struct pci_root_info *info,
>  	struct resource_entry *iospace;
>  	struct resource *resource, *res = entry->res;
>  	char *name;
> -	unsigned long base, min, max, base_port;
> +	unsigned long base_mmio, base_port;
>  	unsigned int sparse = 0, space_nr, len;
>  
>  	len = strlen(info->common.name) + 32;
> @@ -172,12 +172,10 @@ static int add_io_space(struct device *dev, struct pci_root_info *info,
>  		goto free_resource;
>  
>  	name = (char *)(iospace + 1);
> -	min = res->start - entry->offset;
> -	max = res->end - entry->offset;
> -	base = __pa(io_space[space_nr].mmio_base);
> +	base_mmio = __pa(io_space[space_nr].mmio_base);
>  	base_port = IO_SPACE_BASE(space_nr);
>  	snprintf(name, len, "%s I/O Ports %08lx-%08lx", info->common.name,
> -		 base_port + min, base_port + max);
> +		 base_port + res->start, base_port + res->end);
>  
>  	/*
>  	 * The SDM guarantees the legacy 0-64K space is sparse, but if the
> @@ -190,19 +188,27 @@ static int add_io_space(struct device *dev, struct pci_root_info *info,
>  	resource = iospace->res;
>  	resource->name  = name;
>  	resource->flags = IORESOURCE_MEM;
> -	resource->start = base + (sparse ? IO_SPACE_SPARSE_ENCODING(min) : min);
> -	resource->end   = base + (sparse ? IO_SPACE_SPARSE_ENCODING(max) : max);
> +	resource->start = base_mmio;
> +	resource->end = base_mmio;
> +	if (sparse) {
> +		resource->start += IO_SPACE_SPARSE_ENCODING(res->start);
> +		resource->end += IO_SPACE_SPARSE_ENCODING(res->end);
> +	} else {
> +		resource->start += res->start;
> +		resource->end += res->end;
> +	}
>  	if (insert_resource(&iomem_resource, resource)) {
>  		dev_err(dev,
>  			"can't allocate host bridge io space resource  %pR\n",
>  			resource);
>  		goto free_resource;
>  	}
> +	resource_list_add_tail(iospace, &info->io_resources);
>  
> +	/* Adjust base of original IO port resource descriptor */
>  	entry->offset = base_port;
> -	res->start = min + base_port;
> -	res->end = max + base_port;
> -	resource_list_add_tail(iospace, &info->io_resources);
> +	res->start += base_port;
> +	res->end += base_port;
>  
>  	return 0;
>  
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index cdc5c25..6578f68 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -190,8 +190,7 @@ static bool acpi_decode_space(struct resource_win *win,
>  {
>  	u8 iodec = attr->granularity == 0xfff ? ACPI_DECODE_10 : ACPI_DECODE_16;
>  	bool wp = addr->info.mem.write_protect;
> -	u64 len = attr->address_length;
> -	u64 start, end, offset = 0;
> +	u64 len = attr->address_length, offset = 0;
>  	struct resource *res = &win->res;
>  
>  	/*
> @@ -215,14 +214,13 @@ static bool acpi_decode_space(struct resource_win *win,
>  	else if (attr->translation_offset)
>  		pr_debug("ACPI: translation_offset(%lld) is invalid for non-bridge device.\n",
>  			 attr->translation_offset);
> -	start = attr->minimum + offset;
> -	end = attr->maximum + offset;
>  
>  	win->offset = offset;
> -	res->start = start;
> -	res->end = end;
> +	res->start = attr->minimum;
> +	res->end = attr->maximum;
>  	if (sizeof(resource_size_t) < sizeof(u64) &&
> -	    (offset != win->offset || start != res->start || end != res->end)) {
> +	    (offset != win->offset || attr->minimum != res->start ||
> +	     attr->maximum != res->end)) {
>  		pr_warn("acpi resource window ([%#llx-%#llx] ignored, not CPU addressable)\n",
>  			attr->minimum, attr->maximum);
>  		return false;
> -- 
> 1.9.1
>

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

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

From	Tomasz Nowicki <tn@semihalf.com>
Date	2016-01-13 14:30 +0100
Subject	[PATCH V3 02/21] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory
Message-ID	<qQtEU-hT-57@gated-at.bofh.it>
In reply to	#1308403

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>
Tested-by: Jeremy Linton <jeremy.linton@arm.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 1991aea..7c603e4 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -166,6 +166,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

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

#1308406 — [PATCH V3 17/21] acpi, mcfg: Add default PCI config accessors implementation and initial support for related quirks.

From	Tomasz Nowicki <tn@semihalf.com>
Date	2016-01-13 14:30 +0100
Subject	[PATCH V3 17/21] acpi, mcfg: Add default PCI config accessors implementation and initial support for related quirks.
Message-ID	<qQtEU-hT-59@gated-at.bofh.it>
In reply to	#1308403

We use generic accessors from access.c by default. However, we already
know platforms that need special handling while accessing to PCI config
space. These platforms will need different accessors set matched against
platform ID, domain, bus touple. Therefore we are going to add (in future)
DECLARE_ACPI_MCFG_FIXUP which will register platform specific custom
accessors. For now we let pci_mcfg_get_ops takes domain and bus arguments
and left some space for matching algorithm.

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
 drivers/acpi/mcfg.c      | 30 ++++++++++++++++++++++++++++++
 include/linux/pci-acpi.h |  8 ++++++++
 2 files changed, 38 insertions(+)

diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index dca4c4e..dfc2d14 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -34,6 +34,36 @@ int __weak raw_pci_write(unsigned int domain, unsigned int bus,
 	return PCIBIOS_DEVICE_NOT_FOUND;
 }
 
+void __iomem *
+pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
+{
+	struct pci_mmcfg_region *cfg;
+
+	cfg = pci_mmconfig_lookup(pci_domain_nr(bus), bus->number);
+	if (cfg && cfg->virt)
+		return cfg->virt +
+			(PCI_MMCFG_BUS_OFFSET(bus->number) | (devfn << 12)) +
+			offset;
+	return NULL;
+}
+
+/* Default generic PCI config accessors */
+static struct pci_ops default_pci_mcfg_ops = {
+	.map_bus = pci_mcfg_dev_base,
+	.read = pci_generic_config_read,
+	.write = pci_generic_config_write,
+};
+
+struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
+{
+	/*
+	 * TODO: Match against platform specific quirks and return
+	 * corresponding PCI config space accessor set.
+	 */
+
+	return &default_pci_mcfg_ops;
+}
+
 int __init acpi_parse_mcfg(struct acpi_table_header *header)
 {
 	struct acpi_table_mcfg *mcfg;
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index c277415..45807a6 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -82,10 +82,18 @@ void acpi_pci_remove_bus(struct pci_bus *bus);
 #ifdef	CONFIG_PCI_MMCONFIG
 int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci);
 void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci);
+struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root);
+void __iomem *
+pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset);
 #else
 static inline int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci)
 { return 0; }
 static inline void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci) { }
+static inline struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
+{ return NULL; }
+static inline void __iomem *
+pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
+{ return NULL; }
 #endif
 
 #ifdef	CONFIG_ACPI_PCI_SLOT
-- 
1.9.1

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

#1308409 — [PATCH V3 13/21] pci, acpi: Provide generic way to assign bus domain number.

From	Tomasz Nowicki <tn@semihalf.com>
Date	2016-01-13 14:30 +0100
Subject	[PATCH V3 13/21] pci, acpi: Provide generic way to assign bus domain number.
Message-ID	<qQtEU-hT-67@gated-at.bofh.it>
In reply to	#1308403

As we now have valid PCI host bridge device reference we can
introduce code that is going to find its bus domain number using
ACPI _SEG method.

Note that _SEG method is optional, therefore _SEG absence means
that all PCI buses belong to domain 0.

Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
---
 drivers/pci/pci.c | 29 +++++++++++++++++++++++++----
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 7274006..39a985b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -25,6 +25,7 @@
 #include <linux/device.h>
 #include <linux/pm_runtime.h>
 #include <linux/pci_hotplug.h>
+#include <linux/acpi.h>
 #include <asm-generic/pci-bridge.h>
 #include <asm/setup.h>
 #include <linux/aer.h>
@@ -4796,14 +4797,34 @@ void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
 	 * API and update the use_dt_domains value to keep track of method we
 	 * are using to assign domain numbers (use_dt_domains = 0).
 	 *
+	 * IF ACPI, we expect non-DT method (use_dt_domains == -1)
+	 * and call _SEG method for corresponding host bridge device.
+	 * If _SEG method does not exist, following ACPI spec (6.5.6)
+	 * all PCI buses belong to domain 0.
+	 *
 	 * All other combinations imply we have a platform that is trying
-	 * to mix domain numbers obtained from DT and pci_get_new_domain_nr(),
-	 * which is a recipe for domain mishandling and it is prevented by
-	 * invalidating the domain value (domain = -1) and printing a
-	 * corresponding error.
+	 * to mix domain numbers obtained from DT, ACPI and
+	 * pci_get_new_domain_nr(), which is a recipe for domain mishandling and
+	 * it is prevented by invalidating the domain value (domain = -1) and
+	 * printing a corresponding error.
 	 */
+
 	if (domain >= 0 && use_dt_domains) {
 		use_dt_domains = 1;
+#ifdef CONFIG_ACPI
+	} else if (!acpi_disabled && use_dt_domains == -1) {
+		struct acpi_device *acpi_dev = to_acpi_device(parent);
+		unsigned long long segment = 0;
+		acpi_status status;
+
+		status = acpi_evaluate_integer(acpi_dev->handle,
+					       METHOD_NAME__SEG, NULL,
+					       &segment);
+		if (ACPI_FAILURE(status) && status != AE_NOT_FOUND)
+			dev_err(&acpi_dev->dev,  "can't evaluate _SEG\n");
+
+		domain = segment;
+#endif
 	} else if (domain < 0 && use_dt_domains != 1) {
 		use_dt_domains = 0;
 		domain = pci_get_new_domain_nr();
-- 
1.9.1

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

#1308411 — [PATCH V3 06/21] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y

From	Tomasz Nowicki <tn@semihalf.com>
Date	2016-01-13 14:30 +0100
Subject	[PATCH V3 06/21] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y
Message-ID	<qQtEU-hT-71@gated-at.bofh.it>
In reply to	#1308403

In drivers/xen/pci.c, there are arch x86 dependent codes when
CONFIG_PCI_MMCONFIG is enabled, since CONFIG_PCI_MMCONFIG
depends on ACPI, so this will prevent XEN PCI running on other
architectures using ACPI with PCI_MMCONFIG enabled (such as ARM64).

Fortunatly, it can be sloved in a simple way. In drivers/xen/pci.c,
the only x86 dependent code is if ((pci_probe & PCI_PROBE_MMCONF) == 0),
and it's defined in asm/pci_x86.h, the code means that
if the PCI resource is not probed in PCI_PROBE_MMCONF way, just
ingnore the xen mcfg init. Actually this is duplicate, because
if PCI resource is not probed in PCI_PROBE_MMCONF way, the
pci_mmconfig_list will be empty, and the if (list_empty())
after it will do the same job.

So just remove the arch related code and the head file, this
will be no functional change for x86, and also makes xen/pci.c
usable for other architectures.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
CC: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
---
 drivers/xen/pci.c | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index 6785ebb..9a8dbe3 100644
--- a/drivers/xen/pci.c
+++ b/drivers/xen/pci.c
@@ -28,9 +28,6 @@
 #include <asm/xen/hypervisor.h>
 #include <asm/xen/hypercall.h>
 #include "../pci/pci.h"
-#ifdef CONFIG_PCI_MMCONFIG
-#include <asm/pci_x86.h>
-#endif
 
 static bool __read_mostly pci_seg_supported = true;
 
@@ -222,9 +219,6 @@ static int __init xen_mcfg_late(void)
 	if (!xen_initial_domain())
 		return 0;
 
-	if ((pci_probe & PCI_PROBE_MMCONF) == 0)
-		return 0;
-
 	if (list_empty(&pci_mmcfg_list))
 		return 0;
 
-- 
1.9.1

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

#1308500 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Tomasz Nowicki <tn@semihalf.com>
Date	2016-01-13 16:30 +0100
Subject	Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qQvx0-1Cf-3@gated-at.bofh.it>
In reply to	#1308403

On 13.01.2016 16:24, Sinan Kaya wrote:
> on an ARM64 server with some nits.
>
> I started seeing these on an ACPI system. I didn't have these before when I tested Tomasz's
> branch yesterday. It must have been introduced after a rebase or a recent change.
>
> _#_dmesg_|_grep_of_irq
> [    3.130774] pci 0002:00:00.0: of_irq_parse_pci() failed with rc=-22
> [    4.182526] pci 0002:00:00.0: of_irq_parse_pci() failed with rc=-22
> [    5.187764] pci 0002:00:00.0: of_irq_parse_pci() failed with rc=-22
> [    5.868518] pci 0003:00:00.0: of_irq_parse_pci() failed with rc=-22
> [    5.910629] pci 0003:00:00.0: of_irq_parse_pci() failed with rc=-22
> [    6.732817] pci 0006:00:00.0: of_irq_parse_pci() failed with rc=-22
> [    7.777698] pci 0006:00:00.0: of_irq_parse_pci() failed with rc=-22
> [    8.782882] pci 0006:00:00.0: of_irq_parse_pci() failed with rc=-22
> / #

You got this because I had dropped patch from the previous series:
https://patchwork.ozlabs.org/patch/557504/
and this is expected.

Tomasz

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

#1308508 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Sinan Kaya <okaya@codeaurora.org>
Date	2016-01-13 16:30 +0100
Subject	Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qQvx0-1Cf-5@gated-at.bofh.it>
In reply to	#1308403

On 1/13/2016 8:20 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 and can be found here:
> git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v3)
> 
> 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 server and QEMU.
> Any help in reviewing and testing is very appreciated.
> 
> v2 -> v3
> - fix legacy IRQ assigning and IO ports registration
> - remove reference to arch specific companion device for ia64
> - move ACPI PCI host controller driver to pci_root.c
> - drop generic domain assignment for x86 and ia64 as I am not
>   able to run all necessary test variants
> - drop patch which cleaned legacy IRQ assignment since it belongs to
>   Mathew's series:
>   https://patchwork.ozlabs.org/patch/557504/
> - extend MCFG quirk code
> - rebased to 4.4
> 
> 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
> 
> Liu Jiang (1):
>   ACPI, PCI: Refine the way to handle translation_offset for ACPI
>     resources
> 
> Tomasz Nowicki (20):
>   x86, pci: Reorder logic of pci_mmconfig_insert() function
>   x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code
>     out of arch/x86/ directory
>   pci, acpi, mcfg: Provide generic implementation of MCFG code
>     initialization.
>   x86, pci: mmconfig_{32,64}.c code refactoring - remove code
>     duplication.
>   x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM
>     driver.
>   XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y
>   pci, acpi, mcfg: Provide default RAW ACPI PCI config space accessors.
>   arm64, acpi: Use empty PCI config space accessors from mcfg.c file.
>   pci, acpi, ecam: Add flag to indicate whether ECAM region was hot
>     added or not.
>   x86, pci: Cleanup platform specific MCFG data using previously added
>     ECAM hot_added flag.
>   pci, acpi: Move ACPI host bridge device companion assignment to core
>     code.
>   x86, ia64, pci: Remove ACPI companion device from platform specific
>     data.
>   pci, acpi: Provide generic way to assign bus domain number.
>   x86, ia64: Include acpi_pci_{add|remove}_bus to the default
>     pcibios_{add|remove}_bus implementation.
>   acpi, mcfg: Implement two calls that might be used to inject/remove
>     MCFG region.
>   x86, acpi, pci: Use equivalent function introduced in previous patch.
>   acpi, mcfg: Add default PCI config accessors implementation and
>     initial support for related quirks.
>   pci, acpi: Support for ACPI based generic PCI host controller init
>   pci, acpi: Match PCI config space accessors against platfrom specific
>     quirks.
>   arm64, pci, acpi: Start using ACPI based PCI host bridge driver for
>     ARM64.
> 
>  arch/arm64/Kconfig                 |   7 ++
>  arch/arm64/kernel/pci.c            |  25 ----
>  arch/ia64/hp/common/sba_iommu.c    |   2 +-
>  arch/ia64/include/asm/pci.h        |   1 -
>  arch/ia64/pci/pci.c                |  52 +++-----
>  arch/ia64/sn/kernel/io_acpi_init.c |   4 +-
>  arch/x86/Kconfig                   |   4 +
>  arch/x86/include/asm/pci.h         |   3 -
>  arch/x86/include/asm/pci_x86.h     |  28 +----
>  arch/x86/pci/acpi.c                |  41 ++----
>  arch/x86/pci/common.c              |  10 --
>  arch/x86/pci/irq.c                 |  10 --
>  arch/x86/pci/mmconfig-shared.c     | 250 ++++++-------------------------------
>  arch/x86/pci/mmconfig_32.c         |  11 +-
>  arch/x86/pci/mmconfig_64.c         |  67 +---------
>  arch/x86/pci/numachip.c            |   1 +
>  drivers/acpi/Kconfig               |   5 +
>  drivers/acpi/Makefile              |   1 +
>  drivers/acpi/mcfg.c                | 201 +++++++++++++++++++++++++++++
>  drivers/acpi/pci_root.c            | 136 +++++++++++++++++++-
>  drivers/acpi/resource.c            |  12 +-
>  drivers/pci/Kconfig                |  10 ++
>  drivers/pci/Makefile               |   5 +
>  drivers/pci/ecam.c                 | 234 ++++++++++++++++++++++++++++++++++
>  drivers/pci/pci.c                  |  29 ++++-
>  drivers/pci/probe.c                |   5 +
>  drivers/xen/pci.c                  |   7 +-
>  include/acpi/acpi_bus.h            |   1 +
>  include/asm-generic/vmlinux.lds.h  |   7 ++
>  include/linux/acpi.h               |   2 +
>  include/linux/ecam.h               |  62 +++++++++
>  include/linux/pci-acpi.h           |  17 +++
>  32 files changed, 802 insertions(+), 448 deletions(-)
>  create mode 100644 drivers/acpi/mcfg.c
>  create mode 100644 drivers/pci/ecam.c
>  create mode 100644 include/linux/ecam.h
> 

Tested-by: Sinan Kaya <okaya@codeaurora.org>

on an ARM64 server with some nits.

I started seeing these on an ACPI system. I didn't have these before when I tested Tomasz's
branch yesterday. It must have been introduced after a rebase or a recent change.

_#_dmesg_|_grep_of_irq
[    3.130774] pci 0002:00:00.0: of_irq_parse_pci() failed with rc=-22
[    4.182526] pci 0002:00:00.0: of_irq_parse_pci() failed with rc=-22
[    5.187764] pci 0002:00:00.0: of_irq_parse_pci() failed with rc=-22
[    5.868518] pci 0003:00:00.0: of_irq_parse_pci() failed with rc=-22
[    5.910629] pci 0003:00:00.0: of_irq_parse_pci() failed with rc=-22
[    6.732817] pci 0006:00:00.0: of_irq_parse_pci() failed with rc=-22
[    7.777698] pci 0006:00:00.0: of_irq_parse_pci() failed with rc=-22
[    8.782882] pci 0006:00:00.0: of_irq_parse_pci() failed with rc=-22
/ #

I'm also seeing an IO resource free problem with ACPI hotplug. The mappings created by pci_remap_iospace 
are not being freed in ACPI root port free function. Second call to pci_remap_iospace fails after a hotplug
insertion as the kernel mapping already exists. I had a chat with Tomasz about this. 
We'll discuss the issue later.


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

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

#1309290 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Graeme Gregory <gg@slimlogic.co.uk>
Date	2016-01-14 14:50 +0100
Subject	Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qQQrM-7NG-31@gated-at.bofh.it>
In reply to	#1308403

On Wed, Jan 13, 2016 at 02:20:46PM +0100, 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 and can be found here:
> git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v3)
> 
> 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 server and QEMU.
> Any help in reviewing and testing is very appreciated.

I have tested this on my AMD Overdrive so

Tested-by: Graeme Gregory <graeme.gregory@linaro.org>

But to actually get my r8169 network card working I also need the
following patch.

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 2fbf840..40e24e2 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1717,7 +1717,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
        set_dev_node(&dev->dev, pcibus_to_node(bus));
        dev->dev.dma_mask = &dev->dma_mask;
        dev->dev.dma_parms = &dev->dma_parms;
-       dev->dev.coherent_dma_mask = 0xffffffffull;
+       dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
        pci_dma_configure(dev);

        pci_set_dma_max_seg_size(dev, 65536);

I suspect we need to set coherent_dma_mask somewhere in the platform but I do
not know where this should happen. Hopefully an ARM64 expert can help.

Graeme

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

#1309294 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Mark Salter <msalter@redhat.com>
Date	2016-01-14 15:10 +0100
Subject	Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qQQL7-8bA-1@gated-at.bofh.it>
In reply to	#1309290

On Thu, 2016-01-14 at 13:44 +0000, Graeme Gregory wrote:
> On Wed, Jan 13, 2016 at 02:20:46PM +0100, 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 and can be found here:
> > git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v3)
> > 
> > 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 server and QEMU.
> > Any help in reviewing and testing is very appreciated.
> 
> I have tested this on my AMD Overdrive so
> 
> Tested-by: Graeme Gregory <graeme.gregory@linaro.org>
> 
> But to actually get my r8169 network card working I also need the
> following patch.
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 2fbf840..40e24e2 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1717,7 +1717,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
>         set_dev_node(&dev->dev, pcibus_to_node(bus));
>         dev->dev.dma_mask = &dev->dma_mask;
>         dev->dev.dma_parms = &dev->dma_parms;
> -       dev->dev.coherent_dma_mask = 0xffffffffull;
> +       dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
>         pci_dma_configure(dev);
> 
>         pci_set_dma_max_seg_size(dev, 65536);
> 
> I suspect we need to set coherent_dma_mask somewhere in the platform but I do
> not know where this should happen. Hopefully an ARM64 expert can help.

I've run into a number of cards which don't work on some arm64 machines where there are
no DMA address below 4G. For the realtek card you can use r8169.use_dac=1 on the cmdline
to get it to work.

> 
> Graeme
>

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

#1309313 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Graeme Gregory <gg@slimlogic.co.uk>
Date	2016-01-14 15:20 +0100
Subject	Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qQQUP-8fS-33@gated-at.bofh.it>
In reply to	#1309294

On Thu, Jan 14, 2016 at 09:01:40AM -0500, Mark Salter wrote:
> On Thu, 2016-01-14 at 13:44 +0000, Graeme Gregory wrote:
> > On Wed, Jan 13, 2016 at 02:20:46PM +0100, 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 and can be found here:
> > > git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v3)
> > > 
> > > 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 server and QEMU.
> > > Any help in reviewing and testing is very appreciated.
> > 
> > I have tested this on my AMD Overdrive so
> > 
> > Tested-by: Graeme Gregory <graeme.gregory@linaro.org>
> > 
> > But to actually get my r8169 network card working I also need the
> > following patch.
> > 
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 2fbf840..40e24e2 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -1717,7 +1717,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
> >         set_dev_node(&dev->dev, pcibus_to_node(bus));
> >         dev->dev.dma_mask = &dev->dma_mask;
> >         dev->dev.dma_parms = &dev->dma_parms;
> > -       dev->dev.coherent_dma_mask = 0xffffffffull;
> > +       dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
> >         pci_dma_configure(dev);
> > 
> >         pci_set_dma_max_seg_size(dev, 65536);
> > 
> > I suspect we need to set coherent_dma_mask somewhere in the platform but I do
> > not know where this should happen. Hopefully an ARM64 expert can help.
> 
> I've run into a number of cards which don't work on some arm64 machines where there are
> no DMA address below 4G. For the realtek card you can use r8169.use_dac=1 on the cmdline
> to get it to work.
> 
I need r8169.use_dac=1 and this patch to get card to work.

Graeme

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

#1309321 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Mark Salter <msalter@redhat.com>
Date	2016-01-14 15:30 +0100
Subject	Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qQR4t-8kt-9@gated-at.bofh.it>
In reply to	#1309313

On Thu, 2016-01-14 at 14:15 +0000, Graeme Gregory wrote:
> On Thu, Jan 14, 2016 at 09:01:40AM -0500, Mark Salter wrote:
> > On Thu, 2016-01-14 at 13:44 +0000, Graeme Gregory wrote:
> > > On Wed, Jan 13, 2016 at 02:20:46PM +0100, 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 and can be found here:
> > > > git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v3)
> > > > 
> > > > 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 server and QEMU.
> > > > Any help in reviewing and testing is very appreciated.
> > > 
> > > I have tested this on my AMD Overdrive so
> > > 
> > > Tested-by: Graeme Gregory <graeme.gregory@linaro.org>
> > > 
> > > But to actually get my r8169 network card working I also need the
> > > following patch.
> > > 
> > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > > index 2fbf840..40e24e2 100644
> > > --- a/drivers/pci/probe.c
> > > +++ b/drivers/pci/probe.c
> > > @@ -1717,7 +1717,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
> > >         set_dev_node(&dev->dev, pcibus_to_node(bus));
> > >         dev->dev.dma_mask = &dev->dma_mask;
> > >         dev->dev.dma_parms = &dev->dma_parms;
> > > -       dev->dev.coherent_dma_mask = 0xffffffffull;
> > > +       dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
> > >         pci_dma_configure(dev);
> > > 
> > >         pci_set_dma_max_seg_size(dev, 65536);
> > > 
> > > I suspect we need to set coherent_dma_mask somewhere in the platform but I do
> > > not know where this should happen. Hopefully an ARM64 expert can help.
> > 
> > I've run into a number of cards which don't work on some arm64 machines where there are
> > no DMA address below 4G. For the realtek card you can use r8169.use_dac=1 on the cmdline
> > to get it to work.
> > 
> I need r8169.use_dac=1 and this patch to get card to work.
> 

Hmm. I didn't need a patch in the past but I don't think I've used that card with
this patch series. I will try that when I get a chance...

> Graeme
>

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

#1309298 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Catalin Marinas <catalin.marinas@arm.com>
Date	2016-01-14 15:10 +0100
Subject	Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qQQL8-8bA-9@gated-at.bofh.it>
In reply to	#1309290

On Thu, Jan 14, 2016 at 01:44:40PM +0000, Graeme Gregory wrote:
> On Wed, Jan 13, 2016 at 02:20:46PM +0100, 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 and can be found here:
> > git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v3)
> > 
> > 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 server and QEMU.
> > Any help in reviewing and testing is very appreciated.
> 
> I have tested this on my AMD Overdrive so
> 
> Tested-by: Graeme Gregory <graeme.gregory@linaro.org>
> 
> But to actually get my r8169 network card working I also need the
> following patch.
> 
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 2fbf840..40e24e2 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1717,7 +1717,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
>         set_dev_node(&dev->dev, pcibus_to_node(bus));
>         dev->dev.dma_mask = &dev->dma_mask;
>         dev->dev.dma_parms = &dev->dma_parms;
> -       dev->dev.coherent_dma_mask = 0xffffffffull;
> +       dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
>         pci_dma_configure(dev);
> 
>         pci_set_dma_max_seg_size(dev, 65536);

With OF, we get the coherent_dma_mask set by of_dma_configure(). But I
have no idea how you do this with ACPI.

-- 
Catalin

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

#1309310 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Mark Salter <msalter@redhat.com>
Date	2016-01-14 15:20 +0100
Subject	Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qQQUO-8fS-27@gated-at.bofh.it>
In reply to	#1309298

On Thu, 2016-01-14 at 14:00 +0000, Catalin Marinas wrote:
> On Thu, Jan 14, 2016 at 01:44:40PM +0000, Graeme Gregory wrote:
> > On Wed, Jan 13, 2016 at 02:20:46PM +0100, 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 and can be found here:
> > > git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v3)
> > > 
> > > 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 server and QEMU.
> > > Any help in reviewing and testing is very appreciated.
> > 
> > I have tested this on my AMD Overdrive so
> > 
> > Tested-by: Graeme Gregory <graeme.gregory@linaro.org>
> > 
> > But to actually get my r8169 network card working I also need the
> > following patch.
> > 
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 2fbf840..40e24e2 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -1717,7 +1717,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
> >         set_dev_node(&dev->dev, pcibus_to_node(bus));
> >         dev->dev.dma_mask = &dev->dma_mask;
> >         dev->dev.dma_parms = &dev->dma_parms;
> > -       dev->dev.coherent_dma_mask = 0xffffffffull;
> > +       dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
> >         pci_dma_configure(dev);
> > 
> >         pci_set_dma_max_seg_size(dev, 65536);
> 
> With OF, we get the coherent_dma_mask set by of_dma_configure(). But I
> have no idea how you do this with ACPI.
> 
That doesn't get called for a PCI device (not listed in DT) does it?

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

#1309353 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Catalin Marinas <catalin.marinas@arm.com>
Date	2016-01-14 16:00 +0100
Subject	Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qQRxw-8vf-21@gated-at.bofh.it>
In reply to	#1309310

On Thu, Jan 14, 2016 at 09:09:59AM -0500, Mark Salter wrote:
> On Thu, 2016-01-14 at 14:00 +0000, Catalin Marinas wrote:
> > On Thu, Jan 14, 2016 at 01:44:40PM +0000, Graeme Gregory wrote:
> > > On Wed, Jan 13, 2016 at 02:20:46PM +0100, 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 and can be found here:
> > > > git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v3)
> > > > 
> > > > 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 server and QEMU.
> > > > Any help in reviewing and testing is very appreciated.
> > > 
> > > I have tested this on my AMD Overdrive so
> > > 
> > > Tested-by: Graeme Gregory <graeme.gregory@linaro.org>
> > > 
> > > But to actually get my r8169 network card working I also need the
> > > following patch.
> > > 
> > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > > index 2fbf840..40e24e2 100644
> > > --- a/drivers/pci/probe.c
> > > +++ b/drivers/pci/probe.c
> > > @@ -1717,7 +1717,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
> > >         set_dev_node(&dev->dev, pcibus_to_node(bus));
> > >         dev->dev.dma_mask = &dev->dma_mask;
> > >         dev->dev.dma_parms = &dev->dma_parms;
> > > -       dev->dev.coherent_dma_mask = 0xffffffffull;
> > > +       dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
> > >         pci_dma_configure(dev);
> > > 
> > >         pci_set_dma_max_seg_size(dev, 65536);
> > 
> > With OF, we get the coherent_dma_mask set by of_dma_configure(). But I
> > have no idea how you do this with ACPI.
> 
> That doesn't get called for a PCI device (not listed in DT) does it?

pci_device_add
  pci_dma_configure
    of_dma_configure(&dev->dev, bridge->parent->of_node);

So it gets configured based on the bridge information the device is
attached to.

-- 
Catalin

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

#1309365 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Mark Salter <msalter@redhat.com>
Date	2016-01-14 16:10 +0100
Subject	Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qQRHc-nE-13@gated-at.bofh.it>
In reply to	#1309353

On Thu, 2016-01-14 at 14:50 +0000, Catalin Marinas wrote:
> On Thu, Jan 14, 2016 at 09:09:59AM -0500, Mark Salter wrote:
> > On Thu, 2016-01-14 at 14:00 +0000, Catalin Marinas wrote:
> > > On Thu, Jan 14, 2016 at 01:44:40PM +0000, Graeme Gregory wrote:
> > > > On Wed, Jan 13, 2016 at 02:20:46PM +0100, 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 and can be found here:
> > > > > git@github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v3)
> > > > > 
> > > > > 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 server and QEMU.
> > > > > Any help in reviewing and testing is very appreciated.
> > > > 
> > > > I have tested this on my AMD Overdrive so
> > > > 
> > > > Tested-by: Graeme Gregory <graeme.gregory@linaro.org>
> > > > 
> > > > But to actually get my r8169 network card working I also need the
> > > > following patch.
> > > > 
> > > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > > > index 2fbf840..40e24e2 100644
> > > > --- a/drivers/pci/probe.c
> > > > +++ b/drivers/pci/probe.c
> > > > @@ -1717,7 +1717,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
> > > >         set_dev_node(&dev->dev, pcibus_to_node(bus));
> > > >         dev->dev.dma_mask = &dev->dma_mask;
> > > >         dev->dev.dma_parms = &dev->dma_parms;
> > > > -       dev->dev.coherent_dma_mask = 0xffffffffull;
> > > > +       dev->dev.coherent_dma_mask = DMA_BIT_MASK(64);
> > > >         pci_dma_configure(dev);
> > > > 
> > > >         pci_set_dma_max_seg_size(dev, 65536);
> > > 
> > > With OF, we get the coherent_dma_mask set by of_dma_configure(). But I
> > > have no idea how you do this with ACPI.
> > 
> > That doesn't get called for a PCI device (not listed in DT) does it?
> 
> pci_device_add
>   pci_dma_configure
>     of_dma_configure(&dev->dev, bridge->parent->of_node);
> 
> So it gets configured based on the bridge information the device is
> attached to.
> 

Oh right. And there is an ACPI path in pci_dma_configure but it only sets the
coherency. But I still don't know why Graeme is having issues. I just tried
an r8169 card on Mustang and Seattle with this patch series in a 4.4 kernel
and it worked fine with r8169.use_dac=1.

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

#1309414 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Sinan Kaya <okaya@codeaurora.org>
Date	2016-01-14 16:40 +0100
Subject	Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qQSae-yO-25@gated-at.bofh.it>
In reply to	#1308403

On 1/14/2016 10:29 AM, Mark Salter wrote:
On Wed, 2016-01-13 at 14:20 +0100, Tomasz Nowicki wrote:
> IO resources on Mustang get disabled unless I do:
> 
> @@ -126,9 +126,10 @@ static void acpi_dev_ioresource_flags(struct
> resource *res, u64 len, if (!acpi_dev_resource_len_valid(res->start,
> res->end, len, true)) res->flags |= IORESOURCE_DISABLED |
> IORESOURCE_UNSET;
> 
> +#if 0 if (res->end >= 0x10003) res->flags |= IORESOURCE_DISABLED |
> IORESOURCE_UNSET; - +#endif
> 
> res->end is way beyond 0x10003 on Mustang:
> 
> pci_bus 0000:00: root bus resource [io  0x0000-0xffff window] (bus
> address [0x10000000-0x1000ffff])
> 
> 

Join the club. I complained about this and I got the message that we just do what Intel does. 
See Arnd Bergmann's reply.

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

1/12/2016 9:30 AM

It is an artificial limit coming from the x86 world introduced into common code.

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


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

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

#1309451 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Date	2016-01-14 17:20 +0100
Subject	Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qQSMV-14b-3@gated-at.bofh.it>
In reply to	#1309414

On Thu, Jan 14, 2016 at 10:38:19AM -0500, Sinan Kaya wrote:
> On 1/14/2016 10:29 AM, Mark Salter wrote:
> On Wed, 2016-01-13 at 14:20 +0100, Tomasz Nowicki wrote:
> > IO resources on Mustang get disabled unless I do:
> > 
> > @@ -126,9 +126,10 @@ static void acpi_dev_ioresource_flags(struct
> > resource *res, u64 len, if (!acpi_dev_resource_len_valid(res->start,
> > res->end, len, true)) res->flags |= IORESOURCE_DISABLED |
> > IORESOURCE_UNSET;
> > 
> > +#if 0 if (res->end >= 0x10003) res->flags |= IORESOURCE_DISABLED |
> > IORESOURCE_UNSET; - +#endif
> > 
> > res->end is way beyond 0x10003 on Mustang:
> > 
> > pci_bus 0000:00: root bus resource [io  0x0000-0xffff window] (bus
> > address [0x10000000-0x1000ffff])
> > 
> > 
> 
> Join the club. I complained about this and I got the message that we
> just do what Intel does.  See Arnd Bergmann's reply.
> 
> [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI
> hostbridge init based on ACPI
> 
> 1/12/2016 9:30 AM
> 
> It is an artificial limit coming from the x86 world introduced into
> common code.

Guys, I think you are mixing things up here, we discussed this to
death, read the archives please.

The ACPI IO descriptors AddressMinimum/AddressMaximum describe
the IO space PCI bus addresses. The AddressTranslation field
provides the PCI IO space -> CPU physical address translation, or
put it differently, the secondary to primary bus translation in
ACPI jargon, that's how ACPI tables must be written for IO space,
at least that's what IA64 does (and on ia64 IO space is memory
mapped, as on arm64).

I bet APM IO descriptors specify the *CPU* physical address in
the AddressMinimum field, and that's where the problem lies.

Jiang's patch:

https://lkml.org/lkml/2015/12/16/249

parses the IO descriptors and stores the AddressMinimum, AddressMaximum
in the IO resource (with AddressTranslation as offset which must be the
*CPU* physical address mapping IO), from the log above it seems to me in
AddressMinimum APM specifies the *CPU* physical address generating IO
cycles.

All in all, I was right to fear this would happen, and I already
raised the point within the ACPI spec working group, ACPI IO
descriptors specification is ambiguous and we must agree on how
they have to be specified once for all.

Lorenzo

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

#1309467 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

From	Mark Salter <msalter@redhat.com>
Date	2016-01-14 17:40 +0100
Subject	Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
Message-ID	<qQT6h-1dw-7@gated-at.bofh.it>
In reply to	#1309451

On Thu, 2016-01-14 at 16:12 +0000, Lorenzo Pieralisi wrote:
> On Thu, Jan 14, 2016 at 10:38:19AM -0500, Sinan Kaya wrote:
> > On 1/14/2016 10:29 AM, Mark Salter wrote:
> > On Wed, 2016-01-13 at 14:20 +0100, Tomasz Nowicki wrote:
> > > IO resources on Mustang get disabled unless I do:
> > > 
> > > @@ -126,9 +126,10 @@ static void acpi_dev_ioresource_flags(struct
> > > resource *res, u64 len, if (!acpi_dev_resource_len_valid(res->start,
> > > res->end, len, true)) res->flags |= IORESOURCE_DISABLED |
> > > IORESOURCE_UNSET;
> > > 
> > > +#if 0 if (res->end >= 0x10003) res->flags |= IORESOURCE_DISABLED |
> > > IORESOURCE_UNSET; - +#endif
> > > 
> > > res->end is way beyond 0x10003 on Mustang:
> > > 
> > > pci_bus 0000:00: root bus resource [io  0x0000-0xffff window] (bus
> > > address [0x10000000-0x1000ffff])
> > > 
> > > 
> > 
> > Join the club. I complained about this and I got the message that we
> > just do what Intel does.  See Arnd Bergmann's reply.
> > 
> > [PATCH V2 00/23] MMCONFIG refactoring and support for ARM64 PCI
> > hostbridge init based on ACPI
> > 
> > 1/12/2016 9:30 AM
> > 
> > It is an artificial limit coming from the x86 world introduced into
> > common code.
> 
> Guys, I think you are mixing things up here, we discussed this to
> death, read the archives please.
> 
> The ACPI IO descriptors AddressMinimum/AddressMaximum describe
> the IO space PCI bus addresses. The AddressTranslation field
> provides the PCI IO space -> CPU physical address translation, or
> put it differently, the secondary to primary bus translation in
> ACPI jargon, that's how ACPI tables must be written for IO space,
> at least that's what IA64 does (and on ia64 IO space is memory
> mapped, as on arm64).
> 
> I bet APM IO descriptors specify the *CPU* physical address in
> the AddressMinimum field, and that's where the problem lies.
> 

You would lose that bet. AddressMinimum/Maximum describe the
PCI bus addresses.

                QWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
                    0x0000000000000000, // Granularity
                    0x0000000010000000, // Range Minimum
                    0x000000001000FFFF, // Range Maximum
                    0x000000E000000000, // Translation Offset
                    0x0000000000010000, // Length
                    ,, , TypeStatic)


> Jiang's patch:
> 
> https://lkml.org/lkml/2015/12/16/249
> 
> parses the IO descriptors and stores the AddressMinimum, AddressMaximum
> in the IO resource (with AddressTranslation as offset which must be the
> *CPU* physical address mapping IO), from the log above it seems to me in
> AddressMinimum APM specifies the *CPU* physical address generating IO
> cycles.
> 
> All in all, I was right to fear this would happen, and I already
> raised the point within the ACPI spec working group, ACPI IO
> descriptors specification is ambiguous and we must agree on how
> they have to be specified once for all.
> 
> Lorenzo

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

Page 1 of 2 [1] 2 Next page →

csiph-web

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

Contents

#1308403 — [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1308404 — [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources

#1309216 — Re: [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources

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

#1308406 — [PATCH V3 17/21] acpi, mcfg: Add default PCI config accessors implementation and initial support for related quirks.

#1308409 — [PATCH V3 13/21] pci, acpi: Provide generic way to assign bus domain number.

#1308411 — [PATCH V3 06/21] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y

#1308500 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1308508 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1309290 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1309294 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1309313 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1309321 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1309298 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1309310 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1309353 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1309365 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1309414 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1309451 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI

#1309467 — Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI