* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
>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 at 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
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 01/21] x86, pci: Reorder logic of pci_mmconfig_insert() function
2016-01-13 13:20 ` Tomasz Nowicki
(?)
@ 2016-01-13 13:20 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: jchandra, jcm, linaro-acpi, linux-pci, Liviu.Dudau, ddaney,
Tomasz Nowicki, linux-kernel, linux-acpi, robert.richter,
Suravee.Suthikulpanit, msalter, wangyijing, Tomasz Nowicki, tglx,
mw, linux-arm-kernel
This patch is the first step for MMCONFIG refactoring process.
Code that uses pci_mmcfg_lock will be moved to common file and become
accessible for all architectures. pci_mmconfig_insert() cannot be moved
so easily since it is mixing generic mmconfig code with x86 specific logic
inside of mutual exclusive block guarded by pci_mmcfg_lock.
To get rid of that constraint, we reorder actions as follow:
1. sanity check for mmconfig region presence, if we already have such
region it doesn't make snese to alloc new mmconfig list entry
2. mmconfig entry allocation, no need to lock
3. insertion to iomem_resource has its own lock, no need to wrap it into mutex
4. insertion to mmconfig list can be done as the final step in separate
function (candidate for further refactoring) and needs another mmconfig
lookup to avoid race condition.
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/x86/pci/mmconfig-shared.c | 101 +++++++++++++++++++++++------------------
1 file changed, 58 insertions(+), 43 deletions(-)
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index dd30b7e..c8bb9b0 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -720,6 +720,38 @@ 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)
@@ -734,63 +766,46 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
if (start > end)
return -EINVAL;
- mutex_lock(&pci_mmcfg_lock);
+ rcu_read_lock();
cfg = pci_mmconfig_lookup(seg, start);
- if (cfg) {
- if (cfg->end_bus < end)
- dev_info(dev, FW_INFO
- "MMCONFIG for "
- "domain %04x [bus %02x-%02x] "
- "only partially covers this bridge\n",
- cfg->segment, cfg->start_bus, cfg->end_bus);
- mutex_unlock(&pci_mmcfg_lock);
+ rcu_read_unlock();
+ if (cfg)
return -EEXIST;
- }
- if (!addr) {
- mutex_unlock(&pci_mmcfg_lock);
+ if (!addr)
return -EINVAL;
- }
- rc = -EBUSY;
cfg = pci_mmconfig_alloc(seg, start, end, addr);
- if (cfg == NULL) {
+ if (!cfg) {
dev_warn(dev, "fail to add MMCONFIG (out of memory)\n");
- rc = -ENOMEM;
- } else if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
+ return -ENOMEM;
+ }
+
+ rc = -EBUSY;
+ if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
dev_warn(dev, FW_BUG "MMCONFIG %pR isn't reserved\n",
&cfg->res);
- } else {
- /* Insert resource if it's not in boot stage */
- if (pci_mmcfg_running_state)
- tmp = insert_resource_conflict(&iomem_resource,
- &cfg->res);
-
- if (tmp) {
- dev_warn(dev,
- "MMCONFIG %pR conflicts with "
- "%s %pR\n",
- &cfg->res, tmp->name, tmp);
- } else if (pci_mmcfg_arch_map(cfg)) {
- dev_warn(dev, "fail to map MMCONFIG %pR.\n",
- &cfg->res);
- } else {
- list_add_sorted(cfg);
- dev_info(dev, "MMCONFIG at %pR (base %#lx)\n",
- &cfg->res, (unsigned long)addr);
- cfg = NULL;
- rc = 0;
- }
+ goto error;
}
- if (cfg) {
- if (cfg->res.parent)
- release_resource(&cfg->res);
- kfree(cfg);
+ /* Insert resource if it's not in boot stage */
+ if (pci_mmcfg_running_state)
+ tmp = insert_resource_conflict(&iomem_resource, &cfg->res);
+
+ if (tmp) {
+ dev_warn(dev, "MMCONFIG %pR conflicts with %s %pR\n",
+ &cfg->res, tmp->name, tmp);
+ goto error;
}
- mutex_unlock(&pci_mmcfg_lock);
+ rc = pci_mmconfig_inject(cfg);
+ if (!rc)
+ return 0;
+error:
+ if (cfg->res.parent)
+ release_resource(&cfg->res);
+ kfree(cfg);
return rc;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 01/21] x86, pci: Reorder logic of pci_mmconfig_insert() function
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
This patch is the first step for MMCONFIG refactoring process.
Code that uses pci_mmcfg_lock will be moved to common file and become
accessible for all architectures. pci_mmconfig_insert() cannot be moved
so easily since it is mixing generic mmconfig code with x86 specific logic
inside of mutual exclusive block guarded by pci_mmcfg_lock.
To get rid of that constraint, we reorder actions as follow:
1. sanity check for mmconfig region presence, if we already have such
region it doesn't make snese to alloc new mmconfig list entry
2. mmconfig entry allocation, no need to lock
3. insertion to iomem_resource has its own lock, no need to wrap it into mutex
4. insertion to mmconfig list can be done as the final step in separate
function (candidate for further refactoring) and needs another mmconfig
lookup to avoid race condition.
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/x86/pci/mmconfig-shared.c | 101 +++++++++++++++++++++++------------------
1 file changed, 58 insertions(+), 43 deletions(-)
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index dd30b7e..c8bb9b0 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -720,6 +720,38 @@ 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)
@@ -734,63 +766,46 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
if (start > end)
return -EINVAL;
- mutex_lock(&pci_mmcfg_lock);
+ rcu_read_lock();
cfg = pci_mmconfig_lookup(seg, start);
- if (cfg) {
- if (cfg->end_bus < end)
- dev_info(dev, FW_INFO
- "MMCONFIG for "
- "domain %04x [bus %02x-%02x] "
- "only partially covers this bridge\n",
- cfg->segment, cfg->start_bus, cfg->end_bus);
- mutex_unlock(&pci_mmcfg_lock);
+ rcu_read_unlock();
+ if (cfg)
return -EEXIST;
- }
- if (!addr) {
- mutex_unlock(&pci_mmcfg_lock);
+ if (!addr)
return -EINVAL;
- }
- rc = -EBUSY;
cfg = pci_mmconfig_alloc(seg, start, end, addr);
- if (cfg == NULL) {
+ if (!cfg) {
dev_warn(dev, "fail to add MMCONFIG (out of memory)\n");
- rc = -ENOMEM;
- } else if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
+ return -ENOMEM;
+ }
+
+ rc = -EBUSY;
+ if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
dev_warn(dev, FW_BUG "MMCONFIG %pR isn't reserved\n",
&cfg->res);
- } else {
- /* Insert resource if it's not in boot stage */
- if (pci_mmcfg_running_state)
- tmp = insert_resource_conflict(&iomem_resource,
- &cfg->res);
-
- if (tmp) {
- dev_warn(dev,
- "MMCONFIG %pR conflicts with "
- "%s %pR\n",
- &cfg->res, tmp->name, tmp);
- } else if (pci_mmcfg_arch_map(cfg)) {
- dev_warn(dev, "fail to map MMCONFIG %pR.\n",
- &cfg->res);
- } else {
- list_add_sorted(cfg);
- dev_info(dev, "MMCONFIG at %pR (base %#lx)\n",
- &cfg->res, (unsigned long)addr);
- cfg = NULL;
- rc = 0;
- }
+ goto error;
}
- if (cfg) {
- if (cfg->res.parent)
- release_resource(&cfg->res);
- kfree(cfg);
+ /* Insert resource if it's not in boot stage */
+ if (pci_mmcfg_running_state)
+ tmp = insert_resource_conflict(&iomem_resource, &cfg->res);
+
+ if (tmp) {
+ dev_warn(dev, "MMCONFIG %pR conflicts with %s %pR\n",
+ &cfg->res, tmp->name, tmp);
+ goto error;
}
- mutex_unlock(&pci_mmcfg_lock);
+ rc = pci_mmconfig_inject(cfg);
+ if (!rc)
+ return 0;
+error:
+ if (cfg->res.parent)
+ release_resource(&cfg->res);
+ kfree(cfg);
return rc;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 01/21] x86, pci: Reorder logic of pci_mmconfig_insert() function
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki, Tomasz Nowicki
This patch is the first step for MMCONFIG refactoring process.
Code that uses pci_mmcfg_lock will be moved to common file and become
accessible for all architectures. pci_mmconfig_insert() cannot be moved
so easily since it is mixing generic mmconfig code with x86 specific logic
inside of mutual exclusive block guarded by pci_mmcfg_lock.
To get rid of that constraint, we reorder actions as follow:
1. sanity check for mmconfig region presence, if we already have such
region it doesn't make snese to alloc new mmconfig list entry
2. mmconfig entry allocation, no need to lock
3. insertion to iomem_resource has its own lock, no need to wrap it into mutex
4. insertion to mmconfig list can be done as the final step in separate
function (candidate for further refactoring) and needs another mmconfig
lookup to avoid race condition.
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
---
arch/x86/pci/mmconfig-shared.c | 101 +++++++++++++++++++++++------------------
1 file changed, 58 insertions(+), 43 deletions(-)
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index dd30b7e..c8bb9b0 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -720,6 +720,38 @@ 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)
@@ -734,63 +766,46 @@ int pci_mmconfig_insert(struct device *dev, u16 seg, u8 start, u8 end,
if (start > end)
return -EINVAL;
- mutex_lock(&pci_mmcfg_lock);
+ rcu_read_lock();
cfg = pci_mmconfig_lookup(seg, start);
- if (cfg) {
- if (cfg->end_bus < end)
- dev_info(dev, FW_INFO
- "MMCONFIG for "
- "domain %04x [bus %02x-%02x] "
- "only partially covers this bridge\n",
- cfg->segment, cfg->start_bus, cfg->end_bus);
- mutex_unlock(&pci_mmcfg_lock);
+ rcu_read_unlock();
+ if (cfg)
return -EEXIST;
- }
- if (!addr) {
- mutex_unlock(&pci_mmcfg_lock);
+ if (!addr)
return -EINVAL;
- }
- rc = -EBUSY;
cfg = pci_mmconfig_alloc(seg, start, end, addr);
- if (cfg == NULL) {
+ if (!cfg) {
dev_warn(dev, "fail to add MMCONFIG (out of memory)\n");
- rc = -ENOMEM;
- } else if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
+ return -ENOMEM;
+ }
+
+ rc = -EBUSY;
+ if (!pci_mmcfg_check_reserved(dev, cfg, 0)) {
dev_warn(dev, FW_BUG "MMCONFIG %pR isn't reserved\n",
&cfg->res);
- } else {
- /* Insert resource if it's not in boot stage */
- if (pci_mmcfg_running_state)
- tmp = insert_resource_conflict(&iomem_resource,
- &cfg->res);
-
- if (tmp) {
- dev_warn(dev,
- "MMCONFIG %pR conflicts with "
- "%s %pR\n",
- &cfg->res, tmp->name, tmp);
- } else if (pci_mmcfg_arch_map(cfg)) {
- dev_warn(dev, "fail to map MMCONFIG %pR.\n",
- &cfg->res);
- } else {
- list_add_sorted(cfg);
- dev_info(dev, "MMCONFIG at %pR (base %#lx)\n",
- &cfg->res, (unsigned long)addr);
- cfg = NULL;
- rc = 0;
- }
+ goto error;
}
- if (cfg) {
- if (cfg->res.parent)
- release_resource(&cfg->res);
- kfree(cfg);
+ /* Insert resource if it's not in boot stage */
+ if (pci_mmcfg_running_state)
+ tmp = insert_resource_conflict(&iomem_resource, &cfg->res);
+
+ if (tmp) {
+ dev_warn(dev, "MMCONFIG %pR conflicts with %s %pR\n",
+ &cfg->res, tmp->name, tmp);
+ goto error;
}
- mutex_unlock(&pci_mmcfg_lock);
+ rc = pci_mmconfig_inject(cfg);
+ if (!rc)
+ return 0;
+error:
+ if (cfg->res.parent)
+ release_resource(&cfg->res);
+ kfree(cfg);
return rc;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 02/21] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 13:20 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
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
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 02/21] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 03/21] pci, acpi, mcfg: Provide generic implementation of MCFG code initialization.
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 13:20 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
First function acpi_mcfg_check_entry() does not apply any quirks by default.
Last two functions are required by ACPI subsystem to make PCI config
space accessible. Generic code assume to do nothing for early init call but
late init call does as follow:
- parse MCFG table and add regions to ECAM resource list
- map regions
- add regions to iomem_resource
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/acpi/mcfg.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index 5ecef20..fad9917 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -57,3 +57,29 @@ int __init acpi_parse_mcfg(struct acpi_table_header *header)
return 0;
}
+
+int __init __weak acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
+ struct acpi_mcfg_allocation *cfg)
+{
+ return 0;
+}
+
+void __init __weak pci_mmcfg_early_init(void)
+{
+
+}
+
+void __init __weak pci_mmcfg_late_init(void)
+{
+ struct pci_mmcfg_region *cfg;
+
+ acpi_table_parse(ACPI_SIG_MCFG, acpi_parse_mcfg);
+
+ if (list_empty(&pci_mmcfg_list))
+ return;
+ if (!pci_mmcfg_arch_init())
+ free_all_mmcfg();
+
+ list_for_each_entry(cfg, &pci_mmcfg_list, list)
+ insert_resource(&iomem_resource, &cfg->res);
+}
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 03/21] pci, acpi, mcfg: Provide generic implementation of MCFG code initialization.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
First function acpi_mcfg_check_entry() does not apply any quirks by default.
Last two functions are required by ACPI subsystem to make PCI config
space accessible. Generic code assume to do nothing for early init call but
late init call does as follow:
- parse MCFG table and add regions to ECAM resource list
- map regions
- add regions to iomem_resource
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/acpi/mcfg.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index 5ecef20..fad9917 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -57,3 +57,29 @@ int __init acpi_parse_mcfg(struct acpi_table_header *header)
return 0;
}
+
+int __init __weak acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
+ struct acpi_mcfg_allocation *cfg)
+{
+ return 0;
+}
+
+void __init __weak pci_mmcfg_early_init(void)
+{
+
+}
+
+void __init __weak pci_mmcfg_late_init(void)
+{
+ struct pci_mmcfg_region *cfg;
+
+ acpi_table_parse(ACPI_SIG_MCFG, acpi_parse_mcfg);
+
+ if (list_empty(&pci_mmcfg_list))
+ return;
+ if (!pci_mmcfg_arch_init())
+ free_all_mmcfg();
+
+ list_for_each_entry(cfg, &pci_mmcfg_list, list)
+ insert_resource(&iomem_resource, &cfg->res);
+}
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 04/21] x86, pci: mmconfig_{32,64}.c code refactoring - remove code duplication.
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 13:20 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
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>
Tested-by: Jeremy Linton <jeremy.linton@arm.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
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 04/21] x86, pci: mmconfig_{32, 64}.c code refactoring - remove code duplication.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
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>
Tested-by: Jeremy Linton <jeremy.linton@arm.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
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 05/21] x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM driver.
2016-01-13 13:20 ` Tomasz Nowicki
(?)
@ 2016-01-13 13:20 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: jchandra, jcm, linaro-acpi, linux-pci, Liviu.Dudau, ddaney,
linux-kernel, linux-acpi, robert.richter, Suravee.Suthikulpanit,
msalter, wangyijing, Tomasz Nowicki, tglx, mw, linux-arm-kernel
Hosts with custom ECAM hooks (like 32bit x86) should select
ARCH_HAS_CUSTOM_PCI_ECAM. Otherwise, host will use generic version
provided by this patch (like 64bit x86 does).
Note, we leaved x86-specific PCI config accessors in corresponding files.
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 | 1 +
arch/x86/include/asm/pci_x86.h | 4 ---
arch/x86/pci/mmconfig_64.c | 55 ---------------------------------------
drivers/acpi/mcfg.c | 2 --
drivers/pci/Kconfig | 3 +++
drivers/pci/ecam.c | 59 +++++++++++++++++++++++++++++++++++++++++-
include/linux/ecam.h | 6 +++++
7 files changed, 68 insertions(+), 62 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 350bd52..102d7d1 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -30,6 +30,7 @@ config X86
select ARCH_HAS_PMEM_API if X86_64
select ARCH_HAS_MMIO_FLUSH
select ARCH_HAS_SG_CHAIN
+ select ARCH_HAS_CUSTOM_PCI_ECAM if X86_32
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
select ARCH_MIGHT_HAVE_PC_PARPORT
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 0482807..be091b4 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -123,10 +123,6 @@ extern int pci_legacy_init(void);
extern int pcibios_fixup_irq(struct pci_dev *dev, u8 pin);
/* pci-mmconfig.c */
-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);
diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
index d0c48eb..fd356cc 100644
--- a/arch/x86/pci/mmconfig_64.c
+++ b/arch/x86/pci/mmconfig_64.c
@@ -90,58 +90,3 @@ int pci_mmcfg_write(unsigned int seg, unsigned int bus,
return 0;
}
-
-static void __iomem *mcfg_ioremap(struct pci_mmcfg_region *cfg)
-{
- void __iomem *addr;
- u64 start, size;
- int num_buses;
-
- start = cfg->address + PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
- num_buses = cfg->end_bus - cfg->start_bus + 1;
- size = PCI_MMCFG_BUS_OFFSET(num_buses);
- addr = ioremap_nocache(start, size);
- if (addr)
- addr -= PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
- return addr;
-}
-
-int __init pci_mmcfg_arch_init(void)
-{
- struct pci_mmcfg_region *cfg;
-
- list_for_each_entry(cfg, &pci_mmcfg_list, list)
- if (pci_mmcfg_arch_map(cfg)) {
- pci_mmcfg_arch_free();
- return 0;
- }
-
- return 1;
-}
-
-void __init pci_mmcfg_arch_free(void)
-{
- struct pci_mmcfg_region *cfg;
-
- list_for_each_entry(cfg, &pci_mmcfg_list, list)
- pci_mmcfg_arch_unmap(cfg);
-}
-
-int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg)
-{
- cfg->virt = mcfg_ioremap(cfg);
- if (!cfg->virt) {
- pr_err(PREFIX "can't map MMCONFIG at %pR\n", &cfg->res);
- return -ENOMEM;
- }
-
- return 0;
-}
-
-void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg)
-{
- if (cfg && cfg->virt) {
- iounmap(cfg->virt + PCI_MMCFG_BUS_OFFSET(cfg->start_bus));
- cfg->virt = NULL;
- }
-}
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index fad9917..745b83e 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -10,8 +10,6 @@
#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)
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 9950248..b2e27c8 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -33,6 +33,9 @@ config PCI_ECAM
config HAVE_PCI_ECAM
bool
+config ARCH_HAS_CUSTOM_PCI_ECAM
+ bool
+
config PCI_DEBUG
bool "PCI Debugging"
depends on PCI && DEBUG_KERNEL
diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
index d221dba..8a5eef7 100644
--- a/drivers/pci/ecam.c
+++ b/drivers/pci/ecam.c
@@ -16,7 +16,6 @@
#include <linux/ecam.h>
#include <asm/io.h>
-#include <asm/pci_x86.h> /* Temp hack before refactoring arch-specific calls */
#define PREFIX "PCI: "
@@ -24,6 +23,64 @@ static DEFINE_MUTEX(pci_mmcfg_lock);
LIST_HEAD(pci_mmcfg_list);
+#ifndef CONFIG_ARCH_HAS_CUSTOM_PCI_ECAM
+
+static void __iomem *mcfg_ioremap(struct pci_mmcfg_region *cfg)
+{
+ void __iomem *addr;
+ u64 start, size;
+ int num_buses;
+
+ start = cfg->address + PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
+ num_buses = cfg->end_bus - cfg->start_bus + 1;
+ size = PCI_MMCFG_BUS_OFFSET(num_buses);
+ addr = ioremap_nocache(start, size);
+ if (addr)
+ addr -= PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
+ return addr;
+}
+
+int __init pci_mmcfg_arch_init(void)
+{
+ struct pci_mmcfg_region *cfg;
+
+ list_for_each_entry(cfg, &pci_mmcfg_list, list)
+ if (pci_mmcfg_arch_map(cfg)) {
+ pci_mmcfg_arch_free();
+ return 0;
+ }
+
+ return 1;
+}
+
+void __init pci_mmcfg_arch_free(void)
+{
+ struct pci_mmcfg_region *cfg;
+
+ list_for_each_entry(cfg, &pci_mmcfg_list, list)
+ pci_mmcfg_arch_unmap(cfg);
+}
+
+int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg)
+{
+ cfg->virt = mcfg_ioremap(cfg);
+ if (!cfg->virt) {
+ pr_err(PREFIX "can't map MMCONFIG at %pR\n", &cfg->res);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg)
+{
+ if (cfg && cfg->virt) {
+ iounmap(cfg->virt + PCI_MMCFG_BUS_OFFSET(cfg->start_bus));
+ cfg->virt = NULL;
+ }
+}
+#endif
+
static void __init pci_mmconfig_remove(struct pci_mmcfg_region *cfg)
{
if (cfg->res.parent)
diff --git a/include/linux/ecam.h b/include/linux/ecam.h
index dec3b52..813acd1 100644
--- a/include/linux/ecam.h
+++ b/include/linux/ecam.h
@@ -29,6 +29,12 @@ void list_add_sorted(struct pci_mmcfg_region *new);
void free_all_mmcfg(void);
int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
+/* Arch specific calls */
+int pci_mmcfg_arch_init(void);
+void pci_mmcfg_arch_free(void);
+int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg);
+void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg);
+
extern struct list_head pci_mmcfg_list;
#define PCI_MMCFG_BUS_OFFSET(bus) ((bus) << 20)
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 05/21] x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM driver.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
Hosts with custom ECAM hooks (like 32bit x86) should select
ARCH_HAS_CUSTOM_PCI_ECAM. Otherwise, host will use generic version
provided by this patch (like 64bit x86 does).
Note, we leaved x86-specific PCI config accessors in corresponding files.
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 | 1 +
arch/x86/include/asm/pci_x86.h | 4 ---
arch/x86/pci/mmconfig_64.c | 55 ---------------------------------------
drivers/acpi/mcfg.c | 2 --
drivers/pci/Kconfig | 3 +++
drivers/pci/ecam.c | 59 +++++++++++++++++++++++++++++++++++++++++-
include/linux/ecam.h | 6 +++++
7 files changed, 68 insertions(+), 62 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 350bd52..102d7d1 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -30,6 +30,7 @@ config X86
select ARCH_HAS_PMEM_API if X86_64
select ARCH_HAS_MMIO_FLUSH
select ARCH_HAS_SG_CHAIN
+ select ARCH_HAS_CUSTOM_PCI_ECAM if X86_32
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
select ARCH_MIGHT_HAVE_PC_PARPORT
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 0482807..be091b4 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -123,10 +123,6 @@ extern int pci_legacy_init(void);
extern int pcibios_fixup_irq(struct pci_dev *dev, u8 pin);
/* pci-mmconfig.c */
-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);
diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
index d0c48eb..fd356cc 100644
--- a/arch/x86/pci/mmconfig_64.c
+++ b/arch/x86/pci/mmconfig_64.c
@@ -90,58 +90,3 @@ int pci_mmcfg_write(unsigned int seg, unsigned int bus,
return 0;
}
-
-static void __iomem *mcfg_ioremap(struct pci_mmcfg_region *cfg)
-{
- void __iomem *addr;
- u64 start, size;
- int num_buses;
-
- start = cfg->address + PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
- num_buses = cfg->end_bus - cfg->start_bus + 1;
- size = PCI_MMCFG_BUS_OFFSET(num_buses);
- addr = ioremap_nocache(start, size);
- if (addr)
- addr -= PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
- return addr;
-}
-
-int __init pci_mmcfg_arch_init(void)
-{
- struct pci_mmcfg_region *cfg;
-
- list_for_each_entry(cfg, &pci_mmcfg_list, list)
- if (pci_mmcfg_arch_map(cfg)) {
- pci_mmcfg_arch_free();
- return 0;
- }
-
- return 1;
-}
-
-void __init pci_mmcfg_arch_free(void)
-{
- struct pci_mmcfg_region *cfg;
-
- list_for_each_entry(cfg, &pci_mmcfg_list, list)
- pci_mmcfg_arch_unmap(cfg);
-}
-
-int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg)
-{
- cfg->virt = mcfg_ioremap(cfg);
- if (!cfg->virt) {
- pr_err(PREFIX "can't map MMCONFIG at %pR\n", &cfg->res);
- return -ENOMEM;
- }
-
- return 0;
-}
-
-void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg)
-{
- if (cfg && cfg->virt) {
- iounmap(cfg->virt + PCI_MMCFG_BUS_OFFSET(cfg->start_bus));
- cfg->virt = NULL;
- }
-}
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index fad9917..745b83e 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -10,8 +10,6 @@
#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)
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 9950248..b2e27c8 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -33,6 +33,9 @@ config PCI_ECAM
config HAVE_PCI_ECAM
bool
+config ARCH_HAS_CUSTOM_PCI_ECAM
+ bool
+
config PCI_DEBUG
bool "PCI Debugging"
depends on PCI && DEBUG_KERNEL
diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
index d221dba..8a5eef7 100644
--- a/drivers/pci/ecam.c
+++ b/drivers/pci/ecam.c
@@ -16,7 +16,6 @@
#include <linux/ecam.h>
#include <asm/io.h>
-#include <asm/pci_x86.h> /* Temp hack before refactoring arch-specific calls */
#define PREFIX "PCI: "
@@ -24,6 +23,64 @@ static DEFINE_MUTEX(pci_mmcfg_lock);
LIST_HEAD(pci_mmcfg_list);
+#ifndef CONFIG_ARCH_HAS_CUSTOM_PCI_ECAM
+
+static void __iomem *mcfg_ioremap(struct pci_mmcfg_region *cfg)
+{
+ void __iomem *addr;
+ u64 start, size;
+ int num_buses;
+
+ start = cfg->address + PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
+ num_buses = cfg->end_bus - cfg->start_bus + 1;
+ size = PCI_MMCFG_BUS_OFFSET(num_buses);
+ addr = ioremap_nocache(start, size);
+ if (addr)
+ addr -= PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
+ return addr;
+}
+
+int __init pci_mmcfg_arch_init(void)
+{
+ struct pci_mmcfg_region *cfg;
+
+ list_for_each_entry(cfg, &pci_mmcfg_list, list)
+ if (pci_mmcfg_arch_map(cfg)) {
+ pci_mmcfg_arch_free();
+ return 0;
+ }
+
+ return 1;
+}
+
+void __init pci_mmcfg_arch_free(void)
+{
+ struct pci_mmcfg_region *cfg;
+
+ list_for_each_entry(cfg, &pci_mmcfg_list, list)
+ pci_mmcfg_arch_unmap(cfg);
+}
+
+int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg)
+{
+ cfg->virt = mcfg_ioremap(cfg);
+ if (!cfg->virt) {
+ pr_err(PREFIX "can't map MMCONFIG at %pR\n", &cfg->res);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg)
+{
+ if (cfg && cfg->virt) {
+ iounmap(cfg->virt + PCI_MMCFG_BUS_OFFSET(cfg->start_bus));
+ cfg->virt = NULL;
+ }
+}
+#endif
+
static void __init pci_mmconfig_remove(struct pci_mmcfg_region *cfg)
{
if (cfg->res.parent)
diff --git a/include/linux/ecam.h b/include/linux/ecam.h
index dec3b52..813acd1 100644
--- a/include/linux/ecam.h
+++ b/include/linux/ecam.h
@@ -29,6 +29,12 @@ void list_add_sorted(struct pci_mmcfg_region *new);
void free_all_mmcfg(void);
int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
+/* Arch specific calls */
+int pci_mmcfg_arch_init(void);
+void pci_mmcfg_arch_free(void);
+int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg);
+void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg);
+
extern struct list_head pci_mmcfg_list;
#define PCI_MMCFG_BUS_OFFSET(bus) ((bus) << 20)
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 05/21] x86, pci, ecam: mmconfig_64.c becomes default implementation for ECAM driver.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
Hosts with custom ECAM hooks (like 32bit x86) should select
ARCH_HAS_CUSTOM_PCI_ECAM. Otherwise, host will use generic version
provided by this patch (like 64bit x86 does).
Note, we leaved x86-specific PCI config accessors in corresponding files.
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 | 1 +
arch/x86/include/asm/pci_x86.h | 4 ---
arch/x86/pci/mmconfig_64.c | 55 ---------------------------------------
drivers/acpi/mcfg.c | 2 --
drivers/pci/Kconfig | 3 +++
drivers/pci/ecam.c | 59 +++++++++++++++++++++++++++++++++++++++++-
include/linux/ecam.h | 6 +++++
7 files changed, 68 insertions(+), 62 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 350bd52..102d7d1 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -30,6 +30,7 @@ config X86
select ARCH_HAS_PMEM_API if X86_64
select ARCH_HAS_MMIO_FLUSH
select ARCH_HAS_SG_CHAIN
+ select ARCH_HAS_CUSTOM_PCI_ECAM if X86_32
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
select ARCH_MIGHT_HAVE_PC_PARPORT
diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index 0482807..be091b4 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -123,10 +123,6 @@ extern int pci_legacy_init(void);
extern int pcibios_fixup_irq(struct pci_dev *dev, u8 pin);
/* pci-mmconfig.c */
-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);
diff --git a/arch/x86/pci/mmconfig_64.c b/arch/x86/pci/mmconfig_64.c
index d0c48eb..fd356cc 100644
--- a/arch/x86/pci/mmconfig_64.c
+++ b/arch/x86/pci/mmconfig_64.c
@@ -90,58 +90,3 @@ int pci_mmcfg_write(unsigned int seg, unsigned int bus,
return 0;
}
-
-static void __iomem *mcfg_ioremap(struct pci_mmcfg_region *cfg)
-{
- void __iomem *addr;
- u64 start, size;
- int num_buses;
-
- start = cfg->address + PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
- num_buses = cfg->end_bus - cfg->start_bus + 1;
- size = PCI_MMCFG_BUS_OFFSET(num_buses);
- addr = ioremap_nocache(start, size);
- if (addr)
- addr -= PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
- return addr;
-}
-
-int __init pci_mmcfg_arch_init(void)
-{
- struct pci_mmcfg_region *cfg;
-
- list_for_each_entry(cfg, &pci_mmcfg_list, list)
- if (pci_mmcfg_arch_map(cfg)) {
- pci_mmcfg_arch_free();
- return 0;
- }
-
- return 1;
-}
-
-void __init pci_mmcfg_arch_free(void)
-{
- struct pci_mmcfg_region *cfg;
-
- list_for_each_entry(cfg, &pci_mmcfg_list, list)
- pci_mmcfg_arch_unmap(cfg);
-}
-
-int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg)
-{
- cfg->virt = mcfg_ioremap(cfg);
- if (!cfg->virt) {
- pr_err(PREFIX "can't map MMCONFIG at %pR\n", &cfg->res);
- return -ENOMEM;
- }
-
- return 0;
-}
-
-void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg)
-{
- if (cfg && cfg->virt) {
- iounmap(cfg->virt + PCI_MMCFG_BUS_OFFSET(cfg->start_bus));
- cfg->virt = NULL;
- }
-}
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index fad9917..745b83e 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -10,8 +10,6 @@
#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)
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 9950248..b2e27c8 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -33,6 +33,9 @@ config PCI_ECAM
config HAVE_PCI_ECAM
bool
+config ARCH_HAS_CUSTOM_PCI_ECAM
+ bool
+
config PCI_DEBUG
bool "PCI Debugging"
depends on PCI && DEBUG_KERNEL
diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
index d221dba..8a5eef7 100644
--- a/drivers/pci/ecam.c
+++ b/drivers/pci/ecam.c
@@ -16,7 +16,6 @@
#include <linux/ecam.h>
#include <asm/io.h>
-#include <asm/pci_x86.h> /* Temp hack before refactoring arch-specific calls */
#define PREFIX "PCI: "
@@ -24,6 +23,64 @@ static DEFINE_MUTEX(pci_mmcfg_lock);
LIST_HEAD(pci_mmcfg_list);
+#ifndef CONFIG_ARCH_HAS_CUSTOM_PCI_ECAM
+
+static void __iomem *mcfg_ioremap(struct pci_mmcfg_region *cfg)
+{
+ void __iomem *addr;
+ u64 start, size;
+ int num_buses;
+
+ start = cfg->address + PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
+ num_buses = cfg->end_bus - cfg->start_bus + 1;
+ size = PCI_MMCFG_BUS_OFFSET(num_buses);
+ addr = ioremap_nocache(start, size);
+ if (addr)
+ addr -= PCI_MMCFG_BUS_OFFSET(cfg->start_bus);
+ return addr;
+}
+
+int __init pci_mmcfg_arch_init(void)
+{
+ struct pci_mmcfg_region *cfg;
+
+ list_for_each_entry(cfg, &pci_mmcfg_list, list)
+ if (pci_mmcfg_arch_map(cfg)) {
+ pci_mmcfg_arch_free();
+ return 0;
+ }
+
+ return 1;
+}
+
+void __init pci_mmcfg_arch_free(void)
+{
+ struct pci_mmcfg_region *cfg;
+
+ list_for_each_entry(cfg, &pci_mmcfg_list, list)
+ pci_mmcfg_arch_unmap(cfg);
+}
+
+int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg)
+{
+ cfg->virt = mcfg_ioremap(cfg);
+ if (!cfg->virt) {
+ pr_err(PREFIX "can't map MMCONFIG at %pR\n", &cfg->res);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg)
+{
+ if (cfg && cfg->virt) {
+ iounmap(cfg->virt + PCI_MMCFG_BUS_OFFSET(cfg->start_bus));
+ cfg->virt = NULL;
+ }
+}
+#endif
+
static void __init pci_mmconfig_remove(struct pci_mmcfg_region *cfg)
{
if (cfg->res.parent)
diff --git a/include/linux/ecam.h b/include/linux/ecam.h
index dec3b52..813acd1 100644
--- a/include/linux/ecam.h
+++ b/include/linux/ecam.h
@@ -29,6 +29,12 @@ void list_add_sorted(struct pci_mmcfg_region *new);
void free_all_mmcfg(void);
int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
+/* Arch specific calls */
+int pci_mmcfg_arch_init(void);
+void pci_mmcfg_arch_free(void);
+int pci_mmcfg_arch_map(struct pci_mmcfg_region *cfg);
+void pci_mmcfg_arch_unmap(struct pci_mmcfg_region *cfg);
+
extern struct list_head pci_mmcfg_list;
#define PCI_MMCFG_BUS_OFFSET(bus) ((bus) << 20)
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 06/21] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y
2016-01-13 13:20 ` Tomasz Nowicki
(?)
@ 2016-01-13 13:20 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: jchandra, jcm, linaro-acpi, linux-pci, Konrad Rzeszutek Wilk,
Liviu.Dudau, ddaney, linux-kernel, linux-acpi, robert.richter,
Suravee.Suthikulpanit, msalter, wangyijing, Tomasz Nowicki, tglx,
mw, Boris Ostrovsky, linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 06/21] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 06/21] XEN / PCI: Remove the dependence on arch x86 when PCI_MMCONFIG=y
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki, Konrad Rzeszutek Wilk, Boris Ostrovsky
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
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 07/21] pci, acpi, mcfg: Provide default RAW ACPI PCI config space accessors.
2016-01-13 13:20 ` Tomasz Nowicki
(?)
@ 2016-01-13 13:20 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: jchandra, jcm, linaro-acpi, linux-pci, Liviu.Dudau, ddaney,
linux-kernel, linux-acpi, robert.richter, Suravee.Suthikulpanit,
msalter, wangyijing, Tomasz Nowicki, tglx, mw, linux-arm-kernel
Lets keep RAW ACPI PCI config space accessors empty by default,
since we are note sure if they are necessary accross all archs.
Once we sort this out, we can provide generic version or let
architectures to overwrite, like now x86.
Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/acpi/mcfg.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index 745b83e..3e1e7be 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -9,9 +9,30 @@
#include <linux/acpi.h>
#include <linux/ecam.h>
+#include <linux/pci.h>
#define PREFIX "MCFG: "
+/*
+ * raw_pci_read/write - raw ACPI PCI config space accessors.
+ *
+ * By defauly (__weak) these accessors are empty and should be overwritten
+ * by architectures which support operations on ACPI PCI_Config regions,
+ * see osl.c file.
+ */
+
+int __weak raw_pci_read(unsigned int domain, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 *val)
+{
+ return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+int __weak raw_pci_write(unsigned int domain, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 val)
+{
+ return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
int __init acpi_parse_mcfg(struct acpi_table_header *header)
{
struct acpi_table_mcfg *mcfg;
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 07/21] pci, acpi, mcfg: Provide default RAW ACPI PCI config space accessors.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
Lets keep RAW ACPI PCI config space accessors empty by default,
since we are note sure if they are necessary accross all archs.
Once we sort this out, we can provide generic version or let
architectures to overwrite, like now x86.
Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/acpi/mcfg.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index 745b83e..3e1e7be 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -9,9 +9,30 @@
#include <linux/acpi.h>
#include <linux/ecam.h>
+#include <linux/pci.h>
#define PREFIX "MCFG: "
+/*
+ * raw_pci_read/write - raw ACPI PCI config space accessors.
+ *
+ * By defauly (__weak) these accessors are empty and should be overwritten
+ * by architectures which support operations on ACPI PCI_Config regions,
+ * see osl.c file.
+ */
+
+int __weak raw_pci_read(unsigned int domain, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 *val)
+{
+ return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+int __weak raw_pci_write(unsigned int domain, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 val)
+{
+ return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
int __init acpi_parse_mcfg(struct acpi_table_header *header)
{
struct acpi_table_mcfg *mcfg;
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 07/21] pci, acpi, mcfg: Provide default RAW ACPI PCI config space accessors.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
Lets keep RAW ACPI PCI config space accessors empty by default,
since we are note sure if they are necessary accross all archs.
Once we sort this out, we can provide generic version or let
architectures to overwrite, like now x86.
Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/acpi/mcfg.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index 745b83e..3e1e7be 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -9,9 +9,30 @@
#include <linux/acpi.h>
#include <linux/ecam.h>
+#include <linux/pci.h>
#define PREFIX "MCFG: "
+/*
+ * raw_pci_read/write - raw ACPI PCI config space accessors.
+ *
+ * By defauly (__weak) these accessors are empty and should be overwritten
+ * by architectures which support operations on ACPI PCI_Config regions,
+ * see osl.c file.
+ */
+
+int __weak raw_pci_read(unsigned int domain, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 *val)
+{
+ return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+int __weak raw_pci_write(unsigned int domain, unsigned int bus,
+ unsigned int devfn, int reg, int len, u32 val)
+{
+ return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
int __init acpi_parse_mcfg(struct acpi_table_header *header)
{
struct acpi_table_mcfg *mcfg;
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 08/21] arm64, acpi: Use empty PCI config space accessors from mcfg.c file.
2016-01-13 13:20 ` Tomasz Nowicki
(?)
@ 2016-01-13 13:20 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: jchandra, jcm, linaro-acpi, linux-pci, Liviu.Dudau, ddaney,
linux-kernel, linux-acpi, robert.richter, Suravee.Suthikulpanit,
msalter, wangyijing, Tomasz Nowicki, tglx, mw, linux-arm-kernel
We can now use previously prepared empty ACPI RAW accessors
and cleanup a bit before adding full support for PCI host bridge driver.
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/arm64/Kconfig | 6 ++++++
arch/arm64/kernel/pci.c | 15 ---------------
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 871f217..d65d315 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -92,6 +92,7 @@ config ARM64
select SPARSE_IRQ
select SYSCTL_EXCEPTION_TRACE
select HAVE_CONTEXT_TRACKING
+ select HAVE_PCI_ECAM
help
ARM 64-bit (AArch64) Linux support.
@@ -207,6 +208,11 @@ source "drivers/pci/Kconfig"
source "drivers/pci/pcie/Kconfig"
source "drivers/pci/hotplug/Kconfig"
+config PCI_MMCONFIG
+ def_bool y
+ select PCI_ECAM
+ depends on ACPI
+
endmenu
menu "Kernel Features"
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index b3d098b..023b983 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -61,21 +61,6 @@ int pcibios_add_device(struct pci_dev *dev)
return 0;
}
-/*
- * raw_pci_read/write - Platform-specific PCI config space access.
- */
-int raw_pci_read(unsigned int domain, unsigned int bus,
- unsigned int devfn, int reg, int len, u32 *val)
-{
- return -ENXIO;
-}
-
-int raw_pci_write(unsigned int domain, unsigned int bus,
- unsigned int devfn, int reg, int len, u32 val)
-{
- return -ENXIO;
-}
-
#ifdef CONFIG_ACPI
/* Root bridge scanning */
struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 08/21] arm64, acpi: Use empty PCI config space accessors from mcfg.c file.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
We can now use previously prepared empty ACPI RAW accessors
and cleanup a bit before adding full support for PCI host bridge driver.
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/arm64/Kconfig | 6 ++++++
arch/arm64/kernel/pci.c | 15 ---------------
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 871f217..d65d315 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -92,6 +92,7 @@ config ARM64
select SPARSE_IRQ
select SYSCTL_EXCEPTION_TRACE
select HAVE_CONTEXT_TRACKING
+ select HAVE_PCI_ECAM
help
ARM 64-bit (AArch64) Linux support.
@@ -207,6 +208,11 @@ source "drivers/pci/Kconfig"
source "drivers/pci/pcie/Kconfig"
source "drivers/pci/hotplug/Kconfig"
+config PCI_MMCONFIG
+ def_bool y
+ select PCI_ECAM
+ depends on ACPI
+
endmenu
menu "Kernel Features"
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index b3d098b..023b983 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -61,21 +61,6 @@ int pcibios_add_device(struct pci_dev *dev)
return 0;
}
-/*
- * raw_pci_read/write - Platform-specific PCI config space access.
- */
-int raw_pci_read(unsigned int domain, unsigned int bus,
- unsigned int devfn, int reg, int len, u32 *val)
-{
- return -ENXIO;
-}
-
-int raw_pci_write(unsigned int domain, unsigned int bus,
- unsigned int devfn, int reg, int len, u32 val)
-{
- return -ENXIO;
-}
-
#ifdef CONFIG_ACPI
/* Root bridge scanning */
struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 08/21] arm64, acpi: Use empty PCI config space accessors from mcfg.c file.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
We can now use previously prepared empty ACPI RAW accessors
and cleanup a bit before adding full support for PCI host bridge driver.
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/arm64/Kconfig | 6 ++++++
arch/arm64/kernel/pci.c | 15 ---------------
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 871f217..d65d315 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -92,6 +92,7 @@ config ARM64
select SPARSE_IRQ
select SYSCTL_EXCEPTION_TRACE
select HAVE_CONTEXT_TRACKING
+ select HAVE_PCI_ECAM
help
ARM 64-bit (AArch64) Linux support.
@@ -207,6 +208,11 @@ source "drivers/pci/Kconfig"
source "drivers/pci/pcie/Kconfig"
source "drivers/pci/hotplug/Kconfig"
+config PCI_MMCONFIG
+ def_bool y
+ select PCI_ECAM
+ depends on ACPI
+
endmenu
menu "Kernel Features"
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index b3d098b..023b983 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -61,21 +61,6 @@ int pcibios_add_device(struct pci_dev *dev)
return 0;
}
-/*
- * raw_pci_read/write - Platform-specific PCI config space access.
- */
-int raw_pci_read(unsigned int domain, unsigned int bus,
- unsigned int devfn, int reg, int len, u32 *val)
-{
- return -ENXIO;
-}
-
-int raw_pci_write(unsigned int domain, unsigned int bus,
- unsigned int devfn, int reg, int len, u32 val)
-{
- return -ENXIO;
-}
-
#ifdef CONFIG_ACPI
/* Root bridge scanning */
struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 09/21] pci, acpi, ecam: Add flag to indicate whether ECAM region was hot added or not.
2016-01-13 13:20 ` Tomasz Nowicki
(?)
@ 2016-01-13 13:20 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: jchandra, jcm, linaro-acpi, linux-pci, Liviu.Dudau, ddaney,
linux-kernel, linux-acpi, robert.richter, Suravee.Suthikulpanit,
msalter, wangyijing, Tomasz Nowicki, tglx, mw, linux-arm-kernel
There are two ways we can get ECAM (aka MCFG) regions using ACPI,
from MCFG static table and from _CBA method. We cannot remove static
regions, however regions coming from _CBA should be removed while removing
bridge device.
In the light of above we need flag to mark hot added ECAM entries
so that user should use pci_mmconfig_inject while adding regions from
_CBA method.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/pci/ecam.c | 2 ++
include/linux/ecam.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
index 8a5eef7..da35b4c 100644
--- a/drivers/pci/ecam.c
+++ b/drivers/pci/ecam.c
@@ -131,6 +131,7 @@ struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
new->segment = segment;
new->start_bus = start;
new->end_bus = end;
+ new->hot_added = false;
res = &new->res;
res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
@@ -221,6 +222,7 @@ int pci_mmconfig_inject(struct pci_mmcfg_region *cfg)
err = -ENOMEM;
goto out;
} else {
+ cfg->hot_added = true;
list_add_sorted(cfg);
pr_info("MMCONFIG at %pR (base %#lx)\n",
&cfg->res, (unsigned long)cfg->address);
diff --git a/include/linux/ecam.h b/include/linux/ecam.h
index 813acd1..e0f322e 100644
--- a/include/linux/ecam.h
+++ b/include/linux/ecam.h
@@ -17,6 +17,7 @@ struct pci_mmcfg_region {
u8 start_bus;
u8 end_bus;
char name[PCI_MMCFG_RESOURCE_NAME_LEN];
+ bool hot_added;
};
struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 09/21] pci, acpi, ecam: Add flag to indicate whether ECAM region was hot added or not.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
There are two ways we can get ECAM (aka MCFG) regions using ACPI,
from MCFG static table and from _CBA method. We cannot remove static
regions, however regions coming from _CBA should be removed while removing
bridge device.
In the light of above we need flag to mark hot added ECAM entries
so that user should use pci_mmconfig_inject while adding regions from
_CBA method.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/pci/ecam.c | 2 ++
include/linux/ecam.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
index 8a5eef7..da35b4c 100644
--- a/drivers/pci/ecam.c
+++ b/drivers/pci/ecam.c
@@ -131,6 +131,7 @@ struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
new->segment = segment;
new->start_bus = start;
new->end_bus = end;
+ new->hot_added = false;
res = &new->res;
res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
@@ -221,6 +222,7 @@ int pci_mmconfig_inject(struct pci_mmcfg_region *cfg)
err = -ENOMEM;
goto out;
} else {
+ cfg->hot_added = true;
list_add_sorted(cfg);
pr_info("MMCONFIG at %pR (base %#lx)\n",
&cfg->res, (unsigned long)cfg->address);
diff --git a/include/linux/ecam.h b/include/linux/ecam.h
index 813acd1..e0f322e 100644
--- a/include/linux/ecam.h
+++ b/include/linux/ecam.h
@@ -17,6 +17,7 @@ struct pci_mmcfg_region {
u8 start_bus;
u8 end_bus;
char name[PCI_MMCFG_RESOURCE_NAME_LEN];
+ bool hot_added;
};
struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 09/21] pci, acpi, ecam: Add flag to indicate whether ECAM region was hot added or not.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
There are two ways we can get ECAM (aka MCFG) regions using ACPI,
from MCFG static table and from _CBA method. We cannot remove static
regions, however regions coming from _CBA should be removed while removing
bridge device.
In the light of above we need flag to mark hot added ECAM entries
so that user should use pci_mmconfig_inject while adding regions from
_CBA method.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/pci/ecam.c | 2 ++
include/linux/ecam.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/pci/ecam.c b/drivers/pci/ecam.c
index 8a5eef7..da35b4c 100644
--- a/drivers/pci/ecam.c
+++ b/drivers/pci/ecam.c
@@ -131,6 +131,7 @@ struct pci_mmcfg_region *pci_mmconfig_alloc(int segment, int start,
new->segment = segment;
new->start_bus = start;
new->end_bus = end;
+ new->hot_added = false;
res = &new->res;
res->start = addr + PCI_MMCFG_BUS_OFFSET(start);
@@ -221,6 +222,7 @@ int pci_mmconfig_inject(struct pci_mmcfg_region *cfg)
err = -ENOMEM;
goto out;
} else {
+ cfg->hot_added = true;
list_add_sorted(cfg);
pr_info("MMCONFIG at %pR (base %#lx)\n",
&cfg->res, (unsigned long)cfg->address);
diff --git a/include/linux/ecam.h b/include/linux/ecam.h
index 813acd1..e0f322e 100644
--- a/include/linux/ecam.h
+++ b/include/linux/ecam.h
@@ -17,6 +17,7 @@ struct pci_mmcfg_region {
u8 start_bus;
u8 end_bus;
char name[PCI_MMCFG_RESOURCE_NAME_LEN];
+ bool hot_added;
};
struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 10/21] x86, pci: Cleanup platform specific MCFG data using previously added ECAM hot_added flag.
2016-01-13 13:20 ` Tomasz Nowicki
(?)
@ 2016-01-13 13:20 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: jchandra, jcm, linaro-acpi, linux-pci, Liviu.Dudau, ddaney,
linux-kernel, linux-acpi, robert.richter, Suravee.Suthikulpanit,
msalter, wangyijing, Tomasz Nowicki, tglx, mw, linux-arm-kernel
Now that we have hot_added flag and all information in struct acpi_pci_root
we need, we can get rid of arch specific mcfg data from struct pci_root_info.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
---
arch/x86/pci/acpi.c | 36 ++++++++++++++----------------------
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 64caf2b..56714a9 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -12,11 +12,6 @@
struct pci_root_info {
struct acpi_pci_root_info common;
struct pci_sysdata sd;
-#ifdef CONFIG_PCI_MMCONFIG
- bool mcfg_added;
- u8 start_bus;
- u8 end_bus;
-#endif
};
static bool pci_use_crs = true;
@@ -180,16 +175,13 @@ static int check_segment(u16 seg, struct device *dev, char *estr)
static int setup_mcfg_map(struct acpi_pci_root_info *ci)
{
- int result, seg;
- struct pci_root_info *info;
+ int result, seg, start, end;
struct acpi_pci_root *root = ci->root;
struct device *dev = &ci->bridge->dev;
- info = container_of(ci, struct pci_root_info, common);
- info->start_bus = (u8)root->secondary.start;
- info->end_bus = (u8)root->secondary.end;
- info->mcfg_added = false;
- seg = info->sd.domain;
+ seg = root->segment;
+ start = root->secondary.start;
+ end = root->secondary.end;
/* return success if MMCFG is not in use */
if (raw_pci_ext_ops && raw_pci_ext_ops != &pci_mmcfg)
@@ -198,13 +190,11 @@ static int setup_mcfg_map(struct acpi_pci_root_info *ci)
if (!(pci_probe & PCI_PROBE_MMCONF))
return check_segment(seg, dev, "MMCONFIG is disabled,");
- result = pci_mmconfig_insert(dev, seg, info->start_bus, info->end_bus,
- root->mcfg_addr);
+ result = pci_mmconfig_insert(dev, seg, start, end, root->mcfg_addr);
if (result == 0) {
/* enable MMCFG if it hasn't been enabled yet */
if (raw_pci_ext_ops == NULL)
raw_pci_ext_ops = &pci_mmcfg;
- info->mcfg_added = true;
} else if (result != -EEXIST)
return check_segment(seg, dev,
"fail to add MMCONFIG information,");
@@ -214,14 +204,16 @@ static int setup_mcfg_map(struct acpi_pci_root_info *ci)
static void teardown_mcfg_map(struct acpi_pci_root_info *ci)
{
- struct pci_root_info *info;
+ struct acpi_pci_root *root = ci->root;
+ struct pci_mmcfg_region *cfg;
- info = container_of(ci, struct pci_root_info, common);
- if (info->mcfg_added) {
- pci_mmconfig_delete(info->sd.domain,
- info->start_bus, info->end_bus);
- info->mcfg_added = false;
- }
+ cfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
+ if (!cfg)
+ return;
+
+ if (cfg->hot_added)
+ pci_mmconfig_delete(root->segment, root->secondary.start,
+ root->secondary.end);
}
#else
static int setup_mcfg_map(struct acpi_pci_root_info *ci)
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 10/21] x86, pci: Cleanup platform specific MCFG data using previously added ECAM hot_added flag.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
Now that we have hot_added flag and all information in struct acpi_pci_root
we need, we can get rid of arch specific mcfg data from struct pci_root_info.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
---
arch/x86/pci/acpi.c | 36 ++++++++++++++----------------------
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 64caf2b..56714a9 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -12,11 +12,6 @@
struct pci_root_info {
struct acpi_pci_root_info common;
struct pci_sysdata sd;
-#ifdef CONFIG_PCI_MMCONFIG
- bool mcfg_added;
- u8 start_bus;
- u8 end_bus;
-#endif
};
static bool pci_use_crs = true;
@@ -180,16 +175,13 @@ static int check_segment(u16 seg, struct device *dev, char *estr)
static int setup_mcfg_map(struct acpi_pci_root_info *ci)
{
- int result, seg;
- struct pci_root_info *info;
+ int result, seg, start, end;
struct acpi_pci_root *root = ci->root;
struct device *dev = &ci->bridge->dev;
- info = container_of(ci, struct pci_root_info, common);
- info->start_bus = (u8)root->secondary.start;
- info->end_bus = (u8)root->secondary.end;
- info->mcfg_added = false;
- seg = info->sd.domain;
+ seg = root->segment;
+ start = root->secondary.start;
+ end = root->secondary.end;
/* return success if MMCFG is not in use */
if (raw_pci_ext_ops && raw_pci_ext_ops != &pci_mmcfg)
@@ -198,13 +190,11 @@ static int setup_mcfg_map(struct acpi_pci_root_info *ci)
if (!(pci_probe & PCI_PROBE_MMCONF))
return check_segment(seg, dev, "MMCONFIG is disabled,");
- result = pci_mmconfig_insert(dev, seg, info->start_bus, info->end_bus,
- root->mcfg_addr);
+ result = pci_mmconfig_insert(dev, seg, start, end, root->mcfg_addr);
if (result == 0) {
/* enable MMCFG if it hasn't been enabled yet */
if (raw_pci_ext_ops == NULL)
raw_pci_ext_ops = &pci_mmcfg;
- info->mcfg_added = true;
} else if (result != -EEXIST)
return check_segment(seg, dev,
"fail to add MMCONFIG information,");
@@ -214,14 +204,16 @@ static int setup_mcfg_map(struct acpi_pci_root_info *ci)
static void teardown_mcfg_map(struct acpi_pci_root_info *ci)
{
- struct pci_root_info *info;
+ struct acpi_pci_root *root = ci->root;
+ struct pci_mmcfg_region *cfg;
- info = container_of(ci, struct pci_root_info, common);
- if (info->mcfg_added) {
- pci_mmconfig_delete(info->sd.domain,
- info->start_bus, info->end_bus);
- info->mcfg_added = false;
- }
+ cfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
+ if (!cfg)
+ return;
+
+ if (cfg->hot_added)
+ pci_mmconfig_delete(root->segment, root->secondary.start,
+ root->secondary.end);
}
#else
static int setup_mcfg_map(struct acpi_pci_root_info *ci)
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 10/21] x86, pci: Cleanup platform specific MCFG data using previously added ECAM hot_added flag.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
Now that we have hot_added flag and all information in struct acpi_pci_root
we need, we can get rid of arch specific mcfg data from struct pci_root_info.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
---
arch/x86/pci/acpi.c | 36 ++++++++++++++----------------------
1 file changed, 14 insertions(+), 22 deletions(-)
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 64caf2b..56714a9 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -12,11 +12,6 @@
struct pci_root_info {
struct acpi_pci_root_info common;
struct pci_sysdata sd;
-#ifdef CONFIG_PCI_MMCONFIG
- bool mcfg_added;
- u8 start_bus;
- u8 end_bus;
-#endif
};
static bool pci_use_crs = true;
@@ -180,16 +175,13 @@ static int check_segment(u16 seg, struct device *dev, char *estr)
static int setup_mcfg_map(struct acpi_pci_root_info *ci)
{
- int result, seg;
- struct pci_root_info *info;
+ int result, seg, start, end;
struct acpi_pci_root *root = ci->root;
struct device *dev = &ci->bridge->dev;
- info = container_of(ci, struct pci_root_info, common);
- info->start_bus = (u8)root->secondary.start;
- info->end_bus = (u8)root->secondary.end;
- info->mcfg_added = false;
- seg = info->sd.domain;
+ seg = root->segment;
+ start = root->secondary.start;
+ end = root->secondary.end;
/* return success if MMCFG is not in use */
if (raw_pci_ext_ops && raw_pci_ext_ops != &pci_mmcfg)
@@ -198,13 +190,11 @@ static int setup_mcfg_map(struct acpi_pci_root_info *ci)
if (!(pci_probe & PCI_PROBE_MMCONF))
return check_segment(seg, dev, "MMCONFIG is disabled,");
- result = pci_mmconfig_insert(dev, seg, info->start_bus, info->end_bus,
- root->mcfg_addr);
+ result = pci_mmconfig_insert(dev, seg, start, end, root->mcfg_addr);
if (result == 0) {
/* enable MMCFG if it hasn't been enabled yet */
if (raw_pci_ext_ops == NULL)
raw_pci_ext_ops = &pci_mmcfg;
- info->mcfg_added = true;
} else if (result != -EEXIST)
return check_segment(seg, dev,
"fail to add MMCONFIG information,");
@@ -214,14 +204,16 @@ static int setup_mcfg_map(struct acpi_pci_root_info *ci)
static void teardown_mcfg_map(struct acpi_pci_root_info *ci)
{
- struct pci_root_info *info;
+ struct acpi_pci_root *root = ci->root;
+ struct pci_mmcfg_region *cfg;
- info = container_of(ci, struct pci_root_info, common);
- if (info->mcfg_added) {
- pci_mmconfig_delete(info->sd.domain,
- info->start_bus, info->end_bus);
- info->mcfg_added = false;
- }
+ cfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
+ if (!cfg)
+ return;
+
+ if (cfg->hot_added)
+ pci_mmconfig_delete(root->segment, root->secondary.start,
+ root->secondary.end);
}
#else
static int setup_mcfg_map(struct acpi_pci_root_info *ci)
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 13:20 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
Currently we have two platforms (x86 & ia64) capable of PCI ACPI host
bridge initialization. They both use sysdata pill to pass down parent
device reference and both relay on NULL parent in pci_create_root_bus()
to validate sysdata content.
It looks hacky and prevent us from getting some frimware specific
info for PCI host controller e.g. bus domain number.
However, it seems we can overcome that blocker by passing down parent
device via pci_create_root_bus parameter (as the ACPI device type)
and using ACPI_COMPANION_SET in core code for ACPI boot method.
ACPI_COMPANION_SET is safe to run for all cases DT, ACPI and DT&ACPI.
Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
drivers/acpi/pci_root.c | 5 ++++-
drivers/pci/probe.c | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index ae3fe4e..a65c8c2 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -846,7 +846,10 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
pci_acpi_root_add_resources(info);
pci_add_resource(&info->resources, &root->secondary);
- bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
+
+ /* Root bridge device needs to be sure of parent ACPI type */
+ ACPI_COMPANION_SET(&device->dev, device);
+ bus = pci_create_root_bus(&device->dev, busnum, ops->pci_ops,
sysdata, &info->resources);
if (!bus)
goto out_release_info;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 553a029..cad836f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2107,6 +2107,8 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
bridge->dev.parent = parent;
bridge->dev.release = pci_release_host_bridge_dev;
dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
+ ACPI_COMPANION_SET(&bridge->dev,
+ parent ? to_acpi_device_node(parent->fwnode) : NULL);
error = pcibios_root_bridge_prepare(bridge);
if (error) {
kfree(bridge);
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
Currently we have two platforms (x86 & ia64) capable of PCI ACPI host
bridge initialization. They both use sysdata pill to pass down parent
device reference and both relay on NULL parent in pci_create_root_bus()
to validate sysdata content.
It looks hacky and prevent us from getting some frimware specific
info for PCI host controller e.g. bus domain number.
However, it seems we can overcome that blocker by passing down parent
device via pci_create_root_bus parameter (as the ACPI device type)
and using ACPI_COMPANION_SET in core code for ACPI boot method.
ACPI_COMPANION_SET is safe to run for all cases DT, ACPI and DT&ACPI.
Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
drivers/acpi/pci_root.c | 5 ++++-
drivers/pci/probe.c | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index ae3fe4e..a65c8c2 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -846,7 +846,10 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
pci_acpi_root_add_resources(info);
pci_add_resource(&info->resources, &root->secondary);
- bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
+
+ /* Root bridge device needs to be sure of parent ACPI type */
+ ACPI_COMPANION_SET(&device->dev, device);
+ bus = pci_create_root_bus(&device->dev, busnum, ops->pci_ops,
sysdata, &info->resources);
if (!bus)
goto out_release_info;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 553a029..cad836f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2107,6 +2107,8 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
bridge->dev.parent = parent;
bridge->dev.release = pci_release_host_bridge_dev;
dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
+ ACPI_COMPANION_SET(&bridge->dev,
+ parent ? to_acpi_device_node(parent->fwnode) : NULL);
error = pcibios_root_bridge_prepare(bridge);
if (error) {
kfree(bridge);
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* Re: [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-19 16:02 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-19 16:02 UTC (permalink / raw)
To: Tomasz Nowicki
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On Wed, Jan 13, 2016 at 02:20:57PM +0100, Tomasz Nowicki wrote:
> Currently we have two platforms (x86 & ia64) capable of PCI ACPI host
> bridge initialization. They both use sysdata pill to pass down parent
pill ?
> device reference and both relay on NULL parent in pci_create_root_bus()
s/relay/rely
> to validate sysdata content.
>
> It looks hacky and prevent us from getting some frimware specific
"prevents us from getting some firmware..."
> info for PCI host controller e.g. bus domain number.
> However, it seems we can overcome that blocker by passing down parent
It does not seem, either this patch overcomes the issue and it is
accepted, or it does not and it is discarded.
> device via pci_create_root_bus parameter (as the ACPI device type)
I do not understand what you mean by "as the ACPI device type".
> and using ACPI_COMPANION_SET in core code for ACPI boot method.
> ACPI_COMPANION_SET is safe to run for all cases DT, ACPI and DT&ACPI.
>
> Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> ---
> drivers/acpi/pci_root.c | 5 ++++-
> drivers/pci/probe.c | 2 ++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index ae3fe4e..a65c8c2 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -846,7 +846,10 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>
> pci_acpi_root_add_resources(info);
> pci_add_resource(&info->resources, &root->secondary);
> - bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
> +
> + /* Root bridge device needs to be sure of parent ACPI type */
> + ACPI_COMPANION_SET(&device->dev, device);
I do not understand why the code above is needed, can you elaborate
please ?
Thanks,
Lorenzo
> + bus = pci_create_root_bus(&device->dev, busnum, ops->pci_ops,
> sysdata, &info->resources);
> if (!bus)
> goto out_release_info;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 553a029..cad836f 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -2107,6 +2107,8 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> bridge->dev.parent = parent;
> bridge->dev.release = pci_release_host_bridge_dev;
> dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
> + ACPI_COMPANION_SET(&bridge->dev,
> + parent ? to_acpi_device_node(parent->fwnode) : NULL);
> error = pcibios_root_bridge_prepare(bridge);
> if (error) {
> kfree(bridge);
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
@ 2016-01-19 16:02 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-19 16:02 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jan 13, 2016 at 02:20:57PM +0100, Tomasz Nowicki wrote:
> Currently we have two platforms (x86 & ia64) capable of PCI ACPI host
> bridge initialization. They both use sysdata pill to pass down parent
pill ?
> device reference and both relay on NULL parent in pci_create_root_bus()
s/relay/rely
> to validate sysdata content.
>
> It looks hacky and prevent us from getting some frimware specific
"prevents us from getting some firmware..."
> info for PCI host controller e.g. bus domain number.
> However, it seems we can overcome that blocker by passing down parent
It does not seem, either this patch overcomes the issue and it is
accepted, or it does not and it is discarded.
> device via pci_create_root_bus parameter (as the ACPI device type)
I do not understand what you mean by "as the ACPI device type".
> and using ACPI_COMPANION_SET in core code for ACPI boot method.
> ACPI_COMPANION_SET is safe to run for all cases DT, ACPI and DT&ACPI.
>
> Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> ---
> drivers/acpi/pci_root.c | 5 ++++-
> drivers/pci/probe.c | 2 ++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index ae3fe4e..a65c8c2 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -846,7 +846,10 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>
> pci_acpi_root_add_resources(info);
> pci_add_resource(&info->resources, &root->secondary);
> - bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
> +
> + /* Root bridge device needs to be sure of parent ACPI type */
> + ACPI_COMPANION_SET(&device->dev, device);
I do not understand why the code above is needed, can you elaborate
please ?
Thanks,
Lorenzo
> + bus = pci_create_root_bus(&device->dev, busnum, ops->pci_ops,
> sysdata, &info->resources);
> if (!bus)
> goto out_release_info;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 553a029..cad836f 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -2107,6 +2107,8 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> bridge->dev.parent = parent;
> bridge->dev.release = pci_release_host_bridge_dev;
> dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
> + ACPI_COMPANION_SET(&bridge->dev,
> + parent ? to_acpi_device_node(parent->fwnode) : NULL);
> error = pcibios_root_bridge_prepare(bridge);
> if (error) {
> kfree(bridge);
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
2016-01-19 16:02 ` Lorenzo Pieralisi
@ 2016-01-20 11:20 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-20 11:20 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On 19.01.2016 17:02, Lorenzo Pieralisi wrote:
> On Wed, Jan 13, 2016 at 02:20:57PM +0100, Tomasz Nowicki wrote:
[...]
>> device via pci_create_root_bus parameter (as the ACPI device type)
>
> I do not understand what you mean by "as the ACPI device type".
See below.
>
>> and using ACPI_COMPANION_SET in core code for ACPI boot method.
>> ACPI_COMPANION_SET is safe to run for all cases DT, ACPI and DT&ACPI.
>>
>> Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> ---
>> drivers/acpi/pci_root.c | 5 ++++-
>> drivers/pci/probe.c | 2 ++
>> 2 files changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
>> index ae3fe4e..a65c8c2 100644
>> --- a/drivers/acpi/pci_root.c
>> +++ b/drivers/acpi/pci_root.c
>> @@ -846,7 +846,10 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>>
>> pci_acpi_root_add_resources(info);
>> pci_add_resource(&info->resources, &root->secondary);
>> - bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
>> +
>> + /* Root bridge device needs to be sure of parent ACPI type */
>> + ACPI_COMPANION_SET(&device->dev, device);
>
> I do not understand why the code above is needed, can you elaborate
> please ?
>
This makes sure that device->dev can be identified as ACPI device, so we
can use to_acpi_device_node() and assign companion safely below.
>
>> + bus = pci_create_root_bus(&device->dev, busnum, ops->pci_ops,
>> sysdata, &info->resources);
>> if (!bus)
>> goto out_release_info;
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 553a029..cad836f 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -2107,6 +2107,8 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
>> bridge->dev.parent = parent;
>> bridge->dev.release = pci_release_host_bridge_dev;
>> dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
>> + ACPI_COMPANION_SET(&bridge->dev,
>> + parent ? to_acpi_device_node(parent->fwnode) : NULL);
pci_create_root_bus() can be called with DT device, then
ACPI_COMPANION_SET assign no companion to bridge device.
Thanks,
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
@ 2016-01-20 11:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-20 11:20 UTC (permalink / raw)
To: linux-arm-kernel
On 19.01.2016 17:02, Lorenzo Pieralisi wrote:
> On Wed, Jan 13, 2016 at 02:20:57PM +0100, Tomasz Nowicki wrote:
[...]
>> device via pci_create_root_bus parameter (as the ACPI device type)
>
> I do not understand what you mean by "as the ACPI device type".
See below.
>
>> and using ACPI_COMPANION_SET in core code for ACPI boot method.
>> ACPI_COMPANION_SET is safe to run for all cases DT, ACPI and DT&ACPI.
>>
>> Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> ---
>> drivers/acpi/pci_root.c | 5 ++++-
>> drivers/pci/probe.c | 2 ++
>> 2 files changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
>> index ae3fe4e..a65c8c2 100644
>> --- a/drivers/acpi/pci_root.c
>> +++ b/drivers/acpi/pci_root.c
>> @@ -846,7 +846,10 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>>
>> pci_acpi_root_add_resources(info);
>> pci_add_resource(&info->resources, &root->secondary);
>> - bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
>> +
>> + /* Root bridge device needs to be sure of parent ACPI type */
>> + ACPI_COMPANION_SET(&device->dev, device);
>
> I do not understand why the code above is needed, can you elaborate
> please ?
>
This makes sure that device->dev can be identified as ACPI device, so we
can use to_acpi_device_node() and assign companion safely below.
>
>> + bus = pci_create_root_bus(&device->dev, busnum, ops->pci_ops,
>> sysdata, &info->resources);
>> if (!bus)
>> goto out_release_info;
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 553a029..cad836f 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -2107,6 +2107,8 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
>> bridge->dev.parent = parent;
>> bridge->dev.release = pci_release_host_bridge_dev;
>> dev_set_name(&bridge->dev, "pci%04x:%02x", pci_domain_nr(b), bus);
>> + ACPI_COMPANION_SET(&bridge->dev,
>> + parent ? to_acpi_device_node(parent->fwnode) : NULL);
pci_create_root_bus() can be called with DT device, then
ACPI_COMPANION_SET assign no companion to bridge device.
Thanks,
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
2016-01-20 11:20 ` Tomasz Nowicki
@ 2016-01-20 12:38 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-20 12:38 UTC (permalink / raw)
To: Tomasz Nowicki
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On Wed, Jan 20, 2016 at 12:20:07PM +0100, Tomasz Nowicki wrote:
> On 19.01.2016 17:02, Lorenzo Pieralisi wrote:
> >On Wed, Jan 13, 2016 at 02:20:57PM +0100, Tomasz Nowicki wrote:
> [...]
> >>device via pci_create_root_bus parameter (as the ACPI device type)
> >
> >I do not understand what you mean by "as the ACPI device type".
>
> See below.
>
> >
> >>and using ACPI_COMPANION_SET in core code for ACPI boot method.
> >>ACPI_COMPANION_SET is safe to run for all cases DT, ACPI and DT&ACPI.
> >>
> >>Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >>Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> >>---
> >> drivers/acpi/pci_root.c | 5 ++++-
> >> drivers/pci/probe.c | 2 ++
> >> 2 files changed, 6 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> >>index ae3fe4e..a65c8c2 100644
> >>--- a/drivers/acpi/pci_root.c
> >>+++ b/drivers/acpi/pci_root.c
> >>@@ -846,7 +846,10 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
> >>
> >> pci_acpi_root_add_resources(info);
> >> pci_add_resource(&info->resources, &root->secondary);
> >>- bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
> >>+
> >>+ /* Root bridge device needs to be sure of parent ACPI type */
> >>+ ACPI_COMPANION_SET(&device->dev, device);
> >
> >I do not understand why the code above is needed, can you elaborate
> >please ?
> >
>
> This makes sure that device->dev can be identified as ACPI device,
> so we can use to_acpi_device_node() and assign companion safely
> below.
I do not follow. If you refer to the fwnode handle type, that is
already set by ACPI core code (before acpi_pci_root_add() is called,
in acpi_init_device_object()).
Did you add the code above to solve a real issue you encountered ?
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
@ 2016-01-20 12:38 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-20 12:38 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jan 20, 2016 at 12:20:07PM +0100, Tomasz Nowicki wrote:
> On 19.01.2016 17:02, Lorenzo Pieralisi wrote:
> >On Wed, Jan 13, 2016 at 02:20:57PM +0100, Tomasz Nowicki wrote:
> [...]
> >>device via pci_create_root_bus parameter (as the ACPI device type)
> >
> >I do not understand what you mean by "as the ACPI device type".
>
> See below.
>
> >
> >>and using ACPI_COMPANION_SET in core code for ACPI boot method.
> >>ACPI_COMPANION_SET is safe to run for all cases DT, ACPI and DT&ACPI.
> >>
> >>Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> >>Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> >>---
> >> drivers/acpi/pci_root.c | 5 ++++-
> >> drivers/pci/probe.c | 2 ++
> >> 2 files changed, 6 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> >>index ae3fe4e..a65c8c2 100644
> >>--- a/drivers/acpi/pci_root.c
> >>+++ b/drivers/acpi/pci_root.c
> >>@@ -846,7 +846,10 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
> >>
> >> pci_acpi_root_add_resources(info);
> >> pci_add_resource(&info->resources, &root->secondary);
> >>- bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
> >>+
> >>+ /* Root bridge device needs to be sure of parent ACPI type */
> >>+ ACPI_COMPANION_SET(&device->dev, device);
> >
> >I do not understand why the code above is needed, can you elaborate
> >please ?
> >
>
> This makes sure that device->dev can be identified as ACPI device,
> so we can use to_acpi_device_node() and assign companion safely
> below.
I do not follow. If you refer to the fwnode handle type, that is
already set by ACPI core code (before acpi_pci_root_add() is called,
in acpi_init_device_object()).
Did you add the code above to solve a real issue you encountered ?
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
2016-01-20 12:38 ` Lorenzo Pieralisi
@ 2016-01-20 13:40 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-20 13:40 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On 20.01.2016 13:38, Lorenzo Pieralisi wrote:
> On Wed, Jan 20, 2016 at 12:20:07PM +0100, Tomasz Nowicki wrote:
>> On 19.01.2016 17:02, Lorenzo Pieralisi wrote:
>>> On Wed, Jan 13, 2016 at 02:20:57PM +0100, Tomasz Nowicki wrote:
>> [...]
>>>> device via pci_create_root_bus parameter (as the ACPI device type)
>>>
>>> I do not understand what you mean by "as the ACPI device type".
>>
>> See below.
>>
>>>
>>>> and using ACPI_COMPANION_SET in core code for ACPI boot method.
>>>> ACPI_COMPANION_SET is safe to run for all cases DT, ACPI and DT&ACPI.
>>>>
>>>> Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>>>> ---
>>>> drivers/acpi/pci_root.c | 5 ++++-
>>>> drivers/pci/probe.c | 2 ++
>>>> 2 files changed, 6 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
>>>> index ae3fe4e..a65c8c2 100644
>>>> --- a/drivers/acpi/pci_root.c
>>>> +++ b/drivers/acpi/pci_root.c
>>>> @@ -846,7 +846,10 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>>>>
>>>> pci_acpi_root_add_resources(info);
>>>> pci_add_resource(&info->resources, &root->secondary);
>>>> - bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
>>>> +
>>>> + /* Root bridge device needs to be sure of parent ACPI type */
>>>> + ACPI_COMPANION_SET(&device->dev, device);
>>>
>>> I do not understand why the code above is needed, can you elaborate
>>> please ?
>>>
>>
>> This makes sure that device->dev can be identified as ACPI device,
>> so we can use to_acpi_device_node() and assign companion safely
>> below.
>
> I do not follow. If you refer to the fwnode handle type, that is
> already set by ACPI core code (before acpi_pci_root_add() is called,
> in acpi_init_device_object()).
acpi_init_device_object() sets ACPI fwnode handle type only for
"device", but not for "device->dev" which is what is passed as an
argument to pci_create_root_bus().
Without ACPI_COMPANION_SET(&device->dev, device) here, no one can be
sure if we have ACPI device in pci_create_root_bus().
>
> Did you add the code above to solve a real issue you encountered ?
Yes. You can try to run series with this patch:
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 88c9d20..1b74bf6 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -967,7 +967,11 @@ struct pci_bus *acpi_pci_root_create(struct
acpi_pci_root *root,
pci_add_resource(&info->resources, &root->secondary);
- /* Root bridge device needs to be sure of parent ACPI type */
- ACPI_COMPANION_SET(&device->dev, device);
+ if (to_acpi_device_node(device->dev.fwnode) == NULL)
+ pr_err("NON-ACPI TYPE\n");
+ else
+ pr_err("ACPI TYPE\n");
+
bus = pci_create_root_bus(&device->dev, busnum, ops->pci_ops,
sysdata, &info->resources);
Thanks,
Tomasz
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
@ 2016-01-20 13:40 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-20 13:40 UTC (permalink / raw)
To: linux-arm-kernel
On 20.01.2016 13:38, Lorenzo Pieralisi wrote:
> On Wed, Jan 20, 2016 at 12:20:07PM +0100, Tomasz Nowicki wrote:
>> On 19.01.2016 17:02, Lorenzo Pieralisi wrote:
>>> On Wed, Jan 13, 2016 at 02:20:57PM +0100, Tomasz Nowicki wrote:
>> [...]
>>>> device via pci_create_root_bus parameter (as the ACPI device type)
>>>
>>> I do not understand what you mean by "as the ACPI device type".
>>
>> See below.
>>
>>>
>>>> and using ACPI_COMPANION_SET in core code for ACPI boot method.
>>>> ACPI_COMPANION_SET is safe to run for all cases DT, ACPI and DT&ACPI.
>>>>
>>>> Suggested-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>>>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>>>> ---
>>>> drivers/acpi/pci_root.c | 5 ++++-
>>>> drivers/pci/probe.c | 2 ++
>>>> 2 files changed, 6 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
>>>> index ae3fe4e..a65c8c2 100644
>>>> --- a/drivers/acpi/pci_root.c
>>>> +++ b/drivers/acpi/pci_root.c
>>>> @@ -846,7 +846,10 @@ struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
>>>>
>>>> pci_acpi_root_add_resources(info);
>>>> pci_add_resource(&info->resources, &root->secondary);
>>>> - bus = pci_create_root_bus(NULL, busnum, ops->pci_ops,
>>>> +
>>>> + /* Root bridge device needs to be sure of parent ACPI type */
>>>> + ACPI_COMPANION_SET(&device->dev, device);
>>>
>>> I do not understand why the code above is needed, can you elaborate
>>> please ?
>>>
>>
>> This makes sure that device->dev can be identified as ACPI device,
>> so we can use to_acpi_device_node() and assign companion safely
>> below.
>
> I do not follow. If you refer to the fwnode handle type, that is
> already set by ACPI core code (before acpi_pci_root_add() is called,
> in acpi_init_device_object()).
acpi_init_device_object() sets ACPI fwnode handle type only for
"device", but not for "device->dev" which is what is passed as an
argument to pci_create_root_bus().
Without ACPI_COMPANION_SET(&device->dev, device) here, no one can be
sure if we have ACPI device in pci_create_root_bus().
>
> Did you add the code above to solve a real issue you encountered ?
Yes. You can try to run series with this patch:
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 88c9d20..1b74bf6 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -967,7 +967,11 @@ struct pci_bus *acpi_pci_root_create(struct
acpi_pci_root *root,
pci_add_resource(&info->resources, &root->secondary);
- /* Root bridge device needs to be sure of parent ACPI type */
- ACPI_COMPANION_SET(&device->dev, device);
+ if (to_acpi_device_node(device->dev.fwnode) == NULL)
+ pr_err("NON-ACPI TYPE\n");
+ else
+ pr_err("ACPI TYPE\n");
+
bus = pci_create_root_bus(&device->dev, busnum, ops->pci_ops,
sysdata, &info->resources);
Thanks,
Tomasz
^ permalink raw reply related [flat|nested] 184+ messages in thread* Re: [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
2016-01-20 13:40 ` Tomasz Nowicki
@ 2016-01-20 14:22 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-20 14:22 UTC (permalink / raw)
To: Tomasz Nowicki
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On Wed, Jan 20, 2016 at 02:40:08PM +0100, Tomasz Nowicki wrote:
[...]
> >>>>+ /* Root bridge device needs to be sure of parent ACPI type */
> >>>>+ ACPI_COMPANION_SET(&device->dev, device);
> >>>
> >>>I do not understand why the code above is needed, can you elaborate
> >>>please ?
> >>>
> >>
> >>This makes sure that device->dev can be identified as ACPI device,
> >>so we can use to_acpi_device_node() and assign companion safely
> >>below.
> >
> >I do not follow. If you refer to the fwnode handle type, that is
> >already set by ACPI core code (before acpi_pci_root_add() is called,
> >in acpi_init_device_object()).
>
> acpi_init_device_object() sets ACPI fwnode handle type only for
> "device", but not for "device->dev" which is what is passed as an
> argument to pci_create_root_bus().
>
> Without ACPI_COMPANION_SET(&device->dev, device) here, no one can be
> sure if we have ACPI device in pci_create_root_bus().
Ok, got it. The question is whether this should be done in ACPI
core instead (is there a reason why it should *not* be done ?), but I
now understand your point.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
@ 2016-01-20 14:22 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-20 14:22 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jan 20, 2016 at 02:40:08PM +0100, Tomasz Nowicki wrote:
[...]
> >>>>+ /* Root bridge device needs to be sure of parent ACPI type */
> >>>>+ ACPI_COMPANION_SET(&device->dev, device);
> >>>
> >>>I do not understand why the code above is needed, can you elaborate
> >>>please ?
> >>>
> >>
> >>This makes sure that device->dev can be identified as ACPI device,
> >>so we can use to_acpi_device_node() and assign companion safely
> >>below.
> >
> >I do not follow. If you refer to the fwnode handle type, that is
> >already set by ACPI core code (before acpi_pci_root_add() is called,
> >in acpi_init_device_object()).
>
> acpi_init_device_object() sets ACPI fwnode handle type only for
> "device", but not for "device->dev" which is what is passed as an
> argument to pci_create_root_bus().
>
> Without ACPI_COMPANION_SET(&device->dev, device) here, no one can be
> sure if we have ACPI device in pci_create_root_bus().
Ok, got it. The question is whether this should be done in ACPI
core instead (is there a reason why it should *not* be done ?), but I
now understand your point.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
2016-01-20 14:22 ` Lorenzo Pieralisi
@ 2016-01-20 14:41 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-20 14:41 UTC (permalink / raw)
To: Lorenzo Pieralisi, rjw
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, hanjun.guo, okaya,
jiang.liu, Stefano.Stabellini, robert.richter, mw, Liviu.Dudau,
ddaney, tglx, wangyijing, Suravee.Suthikulpanit, msalter,
linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On 20.01.2016 15:22, Lorenzo Pieralisi wrote:
> On Wed, Jan 20, 2016 at 02:40:08PM +0100, Tomasz Nowicki wrote:
>
> [...]
>
>>>>>> + /* Root bridge device needs to be sure of parent ACPI type */
>>>>>> + ACPI_COMPANION_SET(&device->dev, device);
>>>>>
>>>>> I do not understand why the code above is needed, can you elaborate
>>>>> please ?
>>>>>
>>>>
>>>> This makes sure that device->dev can be identified as ACPI device,
>>>> so we can use to_acpi_device_node() and assign companion safely
>>>> below.
>>>
>>> I do not follow. If you refer to the fwnode handle type, that is
>>> already set by ACPI core code (before acpi_pci_root_add() is called,
>>> in acpi_init_device_object()).
>>
>> acpi_init_device_object() sets ACPI fwnode handle type only for
>> "device", but not for "device->dev" which is what is passed as an
>> argument to pci_create_root_bus().
>>
>> Without ACPI_COMPANION_SET(&device->dev, device) here, no one can be
>> sure if we have ACPI device in pci_create_root_bus().
>
> Ok, got it. The question is whether this should be done in ACPI
> core instead (is there a reason why it should *not* be done ?), but I
> now understand your point.
>
I am not able to answer that question, but I see lots of changes in this
area made by Rafael.
Rafael, can you please shed some light on this?
Thanks,
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
@ 2016-01-20 14:41 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-20 14:41 UTC (permalink / raw)
To: linux-arm-kernel
On 20.01.2016 15:22, Lorenzo Pieralisi wrote:
> On Wed, Jan 20, 2016 at 02:40:08PM +0100, Tomasz Nowicki wrote:
>
> [...]
>
>>>>>> + /* Root bridge device needs to be sure of parent ACPI type */
>>>>>> + ACPI_COMPANION_SET(&device->dev, device);
>>>>>
>>>>> I do not understand why the code above is needed, can you elaborate
>>>>> please ?
>>>>>
>>>>
>>>> This makes sure that device->dev can be identified as ACPI device,
>>>> so we can use to_acpi_device_node() and assign companion safely
>>>> below.
>>>
>>> I do not follow. If you refer to the fwnode handle type, that is
>>> already set by ACPI core code (before acpi_pci_root_add() is called,
>>> in acpi_init_device_object()).
>>
>> acpi_init_device_object() sets ACPI fwnode handle type only for
>> "device", but not for "device->dev" which is what is passed as an
>> argument to pci_create_root_bus().
>>
>> Without ACPI_COMPANION_SET(&device->dev, device) here, no one can be
>> sure if we have ACPI device in pci_create_root_bus().
>
> Ok, got it. The question is whether this should be done in ACPI
> core instead (is there a reason why it should *not* be done ?), but I
> now understand your point.
>
I am not able to answer that question, but I see lots of changes in this
area made by Rafael.
Rafael, can you please shed some light on this?
Thanks,
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
2016-01-20 14:41 ` Tomasz Nowicki
(?)
@ 2016-01-27 17:42 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-27 17:42 UTC (permalink / raw)
To: Tomasz Nowicki
Cc: rjw, bhelgaas, arnd, will.deacon, catalin.marinas, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On Wed, Jan 20, 2016 at 03:41:56PM +0100, Tomasz Nowicki wrote:
> On 20.01.2016 15:22, Lorenzo Pieralisi wrote:
> >On Wed, Jan 20, 2016 at 02:40:08PM +0100, Tomasz Nowicki wrote:
> >
> >[...]
> >
> >>>>>>+ /* Root bridge device needs to be sure of parent ACPI type */
> >>>>>>+ ACPI_COMPANION_SET(&device->dev, device);
> >>>>>
> >>>>>I do not understand why the code above is needed, can you elaborate
> >>>>>please ?
> >>>>>
> >>>>
> >>>>This makes sure that device->dev can be identified as ACPI device,
> >>>>so we can use to_acpi_device_node() and assign companion safely
> >>>>below.
> >>>
> >>>I do not follow. If you refer to the fwnode handle type, that is
> >>>already set by ACPI core code (before acpi_pci_root_add() is called,
> >>>in acpi_init_device_object()).
> >>
> >>acpi_init_device_object() sets ACPI fwnode handle type only for
> >>"device", but not for "device->dev" which is what is passed as an
> >>argument to pci_create_root_bus().
> >>
> >>Without ACPI_COMPANION_SET(&device->dev, device) here, no one can be
> >>sure if we have ACPI device in pci_create_root_bus().
> >
> >Ok, got it. The question is whether this should be done in ACPI
> >core instead (is there a reason why it should *not* be done ?), but I
> >now understand your point.
> >
>
> I am not able to answer that question, but I see lots of changes in
> this area made by Rafael.
I had a further look and I am not sure why the fwnode_handle* in the
dev member of the acpi_device is not made to point at the fwnode member
of the acpi_device by *default* (acpi_init_device_object() ?), probably
because it is never used as such but certainly Rafael knows, so I would
ask him to clarify please it is unclear to me.
I do not see anything wrong in what you are doing in this patch.
Rafael, any comments ?
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
@ 2016-01-27 17:42 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-27 17:42 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jan 20, 2016 at 03:41:56PM +0100, Tomasz Nowicki wrote:
> On 20.01.2016 15:22, Lorenzo Pieralisi wrote:
> >On Wed, Jan 20, 2016 at 02:40:08PM +0100, Tomasz Nowicki wrote:
> >
> >[...]
> >
> >>>>>>+ /* Root bridge device needs to be sure of parent ACPI type */
> >>>>>>+ ACPI_COMPANION_SET(&device->dev, device);
> >>>>>
> >>>>>I do not understand why the code above is needed, can you elaborate
> >>>>>please ?
> >>>>>
> >>>>
> >>>>This makes sure that device->dev can be identified as ACPI device,
> >>>>so we can use to_acpi_device_node() and assign companion safely
> >>>>below.
> >>>
> >>>I do not follow. If you refer to the fwnode handle type, that is
> >>>already set by ACPI core code (before acpi_pci_root_add() is called,
> >>>in acpi_init_device_object()).
> >>
> >>acpi_init_device_object() sets ACPI fwnode handle type only for
> >>"device", but not for "device->dev" which is what is passed as an
> >>argument to pci_create_root_bus().
> >>
> >>Without ACPI_COMPANION_SET(&device->dev, device) here, no one can be
> >>sure if we have ACPI device in pci_create_root_bus().
> >
> >Ok, got it. The question is whether this should be done in ACPI
> >core instead (is there a reason why it should *not* be done ?), but I
> >now understand your point.
> >
>
> I am not able to answer that question, but I see lots of changes in
> this area made by Rafael.
I had a further look and I am not sure why the fwnode_handle* in the
dev member of the acpi_device is not made to point at the fwnode member
of the acpi_device by *default* (acpi_init_device_object() ?), probably
because it is never used as such but certainly Rafael knows, so I would
ask him to clarify please it is unclear to me.
I do not see anything wrong in what you are doing in this patch.
Rafael, any comments ?
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 11/21] pci, acpi: Move ACPI host bridge device companion assignment to core code.
@ 2016-01-27 17:42 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-27 17:42 UTC (permalink / raw)
To: Tomasz Nowicki, rjw
Cc: rjw, bhelgaas, arnd, will.deacon, catalin.marinas, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On Wed, Jan 20, 2016 at 03:41:56PM +0100, Tomasz Nowicki wrote:
> On 20.01.2016 15:22, Lorenzo Pieralisi wrote:
> >On Wed, Jan 20, 2016 at 02:40:08PM +0100, Tomasz Nowicki wrote:
> >
> >[...]
> >
> >>>>>>+ /* Root bridge device needs to be sure of parent ACPI type */
> >>>>>>+ ACPI_COMPANION_SET(&device->dev, device);
> >>>>>
> >>>>>I do not understand why the code above is needed, can you elaborate
> >>>>>please ?
> >>>>>
> >>>>
> >>>>This makes sure that device->dev can be identified as ACPI device,
> >>>>so we can use to_acpi_device_node() and assign companion safely
> >>>>below.
> >>>
> >>>I do not follow. If you refer to the fwnode handle type, that is
> >>>already set by ACPI core code (before acpi_pci_root_add() is called,
> >>>in acpi_init_device_object()).
> >>
> >>acpi_init_device_object() sets ACPI fwnode handle type only for
> >>"device", but not for "device->dev" which is what is passed as an
> >>argument to pci_create_root_bus().
> >>
> >>Without ACPI_COMPANION_SET(&device->dev, device) here, no one can be
> >>sure if we have ACPI device in pci_create_root_bus().
> >
> >Ok, got it. The question is whether this should be done in ACPI
> >core instead (is there a reason why it should *not* be done ?), but I
> >now understand your point.
> >
>
> I am not able to answer that question, but I see lots of changes in
> this area made by Rafael.
I had a further look and I am not sure why the fwnode_handle* in the
dev member of the acpi_device is not made to point at the fwnode member
of the acpi_device by *default* (acpi_init_device_object() ?), probably
because it is never used as such but certainly Rafael knows, so I would
ask him to clarify please it is unclear to me.
I do not see anything wrong in what you are doing in this patch.
Rafael, any comments ?
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 12/21] x86, ia64, pci: Remove ACPI companion device from platform specific data.
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 13:20 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
Since PCI core code is setting ACPI companion device for us now,
platform specific ACPI companion device setting turns out to be dead now.
Therefore we can get rid of it, including related companion reference
from PCI sysdata structure.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
arch/ia64/hp/common/sba_iommu.c | 2 +-
arch/ia64/include/asm/pci.h | 1 -
arch/ia64/pci/pci.c | 16 ----------------
arch/ia64/sn/kernel/io_acpi_init.c | 4 ++--
arch/x86/include/asm/pci.h | 3 ---
arch/x86/pci/acpi.c | 2 --
arch/x86/pci/irq.c | 10 ----------
7 files changed, 3 insertions(+), 35 deletions(-)
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index a6d6190..78e4444 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -1981,7 +1981,7 @@ sba_connect_bus(struct pci_bus *bus)
if (PCI_CONTROLLER(bus)->iommu)
return;
- handle = acpi_device_handle(PCI_CONTROLLER(bus)->companion);
+ handle = acpi_device_handle(ACPI_COMPANION(bus->bridge));
if (!handle)
return;
diff --git a/arch/ia64/include/asm/pci.h b/arch/ia64/include/asm/pci.h
index 07039d1..5050748 100644
--- a/arch/ia64/include/asm/pci.h
+++ b/arch/ia64/include/asm/pci.h
@@ -65,7 +65,6 @@ extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
#define pci_legacy_write platform_pci_legacy_write
struct pci_controller {
- struct acpi_device *companion;
void *iommu;
int segment;
int node; /* nearest node with memory or NUMA_NO_NODE for global allocation */
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 8f6ac2f..978d6af 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -301,28 +301,12 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
}
info->controller.segment = root->segment;
- info->controller.companion = device;
info->controller.node = acpi_get_node(device->handle);
INIT_LIST_HEAD(&info->io_resources);
return acpi_pci_root_create(root, &pci_acpi_root_ops,
&info->common, &info->controller);
}
-int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
-{
- /*
- * We pass NULL as parent to pci_create_root_bus(), so if it is not NULL
- * here, pci_create_root_bus() has been called by someone else and
- * sysdata is likely to be different from what we expect. Let it go in
- * that case.
- */
- if (!bridge->dev.parent) {
- struct pci_controller *controller = bridge->bus->sysdata;
- ACPI_COMPANION_SET(&bridge->dev, controller->companion);
- }
- return 0;
-}
-
void pcibios_fixup_device_resources(struct pci_dev *dev)
{
int idx;
diff --git a/arch/ia64/sn/kernel/io_acpi_init.c b/arch/ia64/sn/kernel/io_acpi_init.c
index 0640739..bcfddc2 100644
--- a/arch/ia64/sn/kernel/io_acpi_init.c
+++ b/arch/ia64/sn/kernel/io_acpi_init.c
@@ -132,7 +132,7 @@ sn_get_bussoft_ptr(struct pci_bus *bus)
struct acpi_resource_vendor_typed *vendor;
- handle = acpi_device_handle(PCI_CONTROLLER(bus)->companion);
+ handle = acpi_device_handle(ACPI_COMPANION(bus->bridge));
status = acpi_get_vendor_resource(handle, METHOD_NAME__CRS,
&sn_uuid, &buffer);
if (ACPI_FAILURE(status)) {
@@ -360,7 +360,7 @@ sn_acpi_get_pcidev_info(struct pci_dev *dev, struct pcidev_info **pcidev_info,
acpi_status status;
struct acpi_buffer name_buffer = { ACPI_ALLOCATE_BUFFER, NULL };
- rootbus_handle = acpi_device_handle(PCI_CONTROLLER(dev)->companion);
+ rootbus_handle = acpi_device_handle(ACPI_COMPANION(dev->bus->bridge));
status = acpi_evaluate_integer(rootbus_handle, METHOD_NAME__SEG, NULL,
&segment);
if (ACPI_SUCCESS(status)) {
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 4625943..a98c022 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -14,9 +14,6 @@
struct pci_sysdata {
int domain; /* PCI domain */
int node; /* NUMA node */
-#ifdef CONFIG_ACPI
- struct acpi_device *companion; /* ACPI companion device */
-#endif
#ifdef CONFIG_X86_64
void *iommu; /* IOMMU private data */
#endif
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 56714a9..286e0f5 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -333,7 +333,6 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
struct pci_sysdata sd = {
.domain = domain,
.node = node,
- .companion = root->device
};
memcpy(bus->sysdata, &sd, sizeof(sd));
@@ -348,7 +347,6 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
else {
info->sd.domain = domain;
info->sd.node = node;
- info->sd.companion = root->device;
bus = acpi_pci_root_create(root, &acpi_pci_root_ops,
&info->common, &info->sd);
}
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 7032798..cc62226 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1153,16 +1153,6 @@ void __init pcibios_irq_init(void)
int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
{
- /*
- * We pass NULL as parent to pci_create_root_bus(), so if it is not NULL
- * here, pci_create_root_bus() has been called by someone else and
- * sysdata is likely to be different from what we expect. Let it go in
- * that case.
- */
- if (!bridge->dev.parent) {
- struct pci_sysdata *sd = bridge->bus->sysdata;
- ACPI_COMPANION_SET(&bridge->dev, sd->companion);
- }
bridge->map_irq = pci_map_irq;
return 0;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 12/21] x86, ia64, pci: Remove ACPI companion device from platform specific data.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
Since PCI core code is setting ACPI companion device for us now,
platform specific ACPI companion device setting turns out to be dead now.
Therefore we can get rid of it, including related companion reference
from PCI sysdata structure.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
arch/ia64/hp/common/sba_iommu.c | 2 +-
arch/ia64/include/asm/pci.h | 1 -
arch/ia64/pci/pci.c | 16 ----------------
arch/ia64/sn/kernel/io_acpi_init.c | 4 ++--
arch/x86/include/asm/pci.h | 3 ---
arch/x86/pci/acpi.c | 2 --
arch/x86/pci/irq.c | 10 ----------
7 files changed, 3 insertions(+), 35 deletions(-)
diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c
index a6d6190..78e4444 100644
--- a/arch/ia64/hp/common/sba_iommu.c
+++ b/arch/ia64/hp/common/sba_iommu.c
@@ -1981,7 +1981,7 @@ sba_connect_bus(struct pci_bus *bus)
if (PCI_CONTROLLER(bus)->iommu)
return;
- handle = acpi_device_handle(PCI_CONTROLLER(bus)->companion);
+ handle = acpi_device_handle(ACPI_COMPANION(bus->bridge));
if (!handle)
return;
diff --git a/arch/ia64/include/asm/pci.h b/arch/ia64/include/asm/pci.h
index 07039d1..5050748 100644
--- a/arch/ia64/include/asm/pci.h
+++ b/arch/ia64/include/asm/pci.h
@@ -65,7 +65,6 @@ extern int pci_mmap_legacy_page_range(struct pci_bus *bus,
#define pci_legacy_write platform_pci_legacy_write
struct pci_controller {
- struct acpi_device *companion;
void *iommu;
int segment;
int node; /* nearest node with memory or NUMA_NO_NODE for global allocation */
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 8f6ac2f..978d6af 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -301,28 +301,12 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
}
info->controller.segment = root->segment;
- info->controller.companion = device;
info->controller.node = acpi_get_node(device->handle);
INIT_LIST_HEAD(&info->io_resources);
return acpi_pci_root_create(root, &pci_acpi_root_ops,
&info->common, &info->controller);
}
-int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
-{
- /*
- * We pass NULL as parent to pci_create_root_bus(), so if it is not NULL
- * here, pci_create_root_bus() has been called by someone else and
- * sysdata is likely to be different from what we expect. Let it go in
- * that case.
- */
- if (!bridge->dev.parent) {
- struct pci_controller *controller = bridge->bus->sysdata;
- ACPI_COMPANION_SET(&bridge->dev, controller->companion);
- }
- return 0;
-}
-
void pcibios_fixup_device_resources(struct pci_dev *dev)
{
int idx;
diff --git a/arch/ia64/sn/kernel/io_acpi_init.c b/arch/ia64/sn/kernel/io_acpi_init.c
index 0640739..bcfddc2 100644
--- a/arch/ia64/sn/kernel/io_acpi_init.c
+++ b/arch/ia64/sn/kernel/io_acpi_init.c
@@ -132,7 +132,7 @@ sn_get_bussoft_ptr(struct pci_bus *bus)
struct acpi_resource_vendor_typed *vendor;
- handle = acpi_device_handle(PCI_CONTROLLER(bus)->companion);
+ handle = acpi_device_handle(ACPI_COMPANION(bus->bridge));
status = acpi_get_vendor_resource(handle, METHOD_NAME__CRS,
&sn_uuid, &buffer);
if (ACPI_FAILURE(status)) {
@@ -360,7 +360,7 @@ sn_acpi_get_pcidev_info(struct pci_dev *dev, struct pcidev_info **pcidev_info,
acpi_status status;
struct acpi_buffer name_buffer = { ACPI_ALLOCATE_BUFFER, NULL };
- rootbus_handle = acpi_device_handle(PCI_CONTROLLER(dev)->companion);
+ rootbus_handle = acpi_device_handle(ACPI_COMPANION(dev->bus->bridge));
status = acpi_evaluate_integer(rootbus_handle, METHOD_NAME__SEG, NULL,
&segment);
if (ACPI_SUCCESS(status)) {
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 4625943..a98c022 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -14,9 +14,6 @@
struct pci_sysdata {
int domain; /* PCI domain */
int node; /* NUMA node */
-#ifdef CONFIG_ACPI
- struct acpi_device *companion; /* ACPI companion device */
-#endif
#ifdef CONFIG_X86_64
void *iommu; /* IOMMU private data */
#endif
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 56714a9..286e0f5 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -333,7 +333,6 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
struct pci_sysdata sd = {
.domain = domain,
.node = node,
- .companion = root->device
};
memcpy(bus->sysdata, &sd, sizeof(sd));
@@ -348,7 +347,6 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
else {
info->sd.domain = domain;
info->sd.node = node;
- info->sd.companion = root->device;
bus = acpi_pci_root_create(root, &acpi_pci_root_ops,
&info->common, &info->sd);
}
diff --git a/arch/x86/pci/irq.c b/arch/x86/pci/irq.c
index 7032798..cc62226 100644
--- a/arch/x86/pci/irq.c
+++ b/arch/x86/pci/irq.c
@@ -1153,16 +1153,6 @@ void __init pcibios_irq_init(void)
int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
{
- /*
- * We pass NULL as parent to pci_create_root_bus(), so if it is not NULL
- * here, pci_create_root_bus() has been called by someone else and
- * sysdata is likely to be different from what we expect. Let it go in
- * that case.
- */
- if (!bridge->dev.parent) {
- struct pci_sysdata *sd = bridge->bus->sysdata;
- ACPI_COMPANION_SET(&bridge->dev, sd->companion);
- }
bridge->map_irq = pci_map_irq;
return 0;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 13/21] pci, acpi: Provide generic way to assign bus domain number.
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 13:20 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
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
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 13/21] pci, acpi: Provide generic way to assign bus domain number.
@ 2016-01-13 13:20 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:20 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 184+ messages in thread* Re: [PATCH V3 13/21] pci, acpi: Provide generic way to assign bus domain number.
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-21 18:22 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-21 18:22 UTC (permalink / raw)
To: Tomasz Nowicki
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
Hi Tomasz,
On Wed, Jan 13, 2016 at 02:20:59PM +0100, Tomasz Nowicki wrote:
[...]
> @@ -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
I think you can reshuffle a bit the code to make it easier to follow.
How about this ? (on top of mainline, I just compiled it do not
take it verbatim):
-- >8 --
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d1a7105..467a316 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -7,6 +7,7 @@
* Copyright 1997 -- 2000 Martin Mares <mj@ucw.cz>
*/
+#include <linux/acpi.h>
#include <linux/kernel.h>
#include <linux/delay.h>
#include <linux/init.h>
@@ -4769,7 +4770,27 @@ int pci_get_new_domain_nr(void)
}
#ifdef CONFIG_PCI_DOMAINS_GENERIC
-void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
+/* Feel free to add this to drivers/acpi as a helper */
+#ifdef CONFIG_ACPI
+int pci_bus_acpi_domain_nr(struct device *parent)
+{
+ 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");
+
+ return segment;
+}
+#else
+int pci_bus_acpi_domain_nr(struct device *parent) { return -1; }
+#endif
+
+int pci_bus_of_domain_nr(struct device *parent)
{
static int use_dt_domains = -1;
int domain = of_get_pci_domain_nr(parent->of_node);
@@ -4811,7 +4832,13 @@ void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
domain = -1;
}
- bus->domain_nr = domain;
+ return domain;
+}
+
+void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
+{
+ bus->domain_nr = acpi_disabled ? pci_bus_of_domain_nr(parent) :
+ pci_bus_acpi_domain_nr(parent);
}
#endif
#endif
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 13/21] pci, acpi: Provide generic way to assign bus domain number.
@ 2016-01-21 18:22 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-21 18:22 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomasz,
On Wed, Jan 13, 2016 at 02:20:59PM +0100, Tomasz Nowicki wrote:
[...]
> @@ -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
I think you can reshuffle a bit the code to make it easier to follow.
How about this ? (on top of mainline, I just compiled it do not
take it verbatim):
-- >8 --
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index d1a7105..467a316 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -7,6 +7,7 @@
* Copyright 1997 -- 2000 Martin Mares <mj@ucw.cz>
*/
+#include <linux/acpi.h>
#include <linux/kernel.h>
#include <linux/delay.h>
#include <linux/init.h>
@@ -4769,7 +4770,27 @@ int pci_get_new_domain_nr(void)
}
#ifdef CONFIG_PCI_DOMAINS_GENERIC
-void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
+/* Feel free to add this to drivers/acpi as a helper */
+#ifdef CONFIG_ACPI
+int pci_bus_acpi_domain_nr(struct device *parent)
+{
+ 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");
+
+ return segment;
+}
+#else
+int pci_bus_acpi_domain_nr(struct device *parent) { return -1; }
+#endif
+
+int pci_bus_of_domain_nr(struct device *parent)
{
static int use_dt_domains = -1;
int domain = of_get_pci_domain_nr(parent->of_node);
@@ -4811,7 +4832,13 @@ void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
domain = -1;
}
- bus->domain_nr = domain;
+ return domain;
+}
+
+void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
+{
+ bus->domain_nr = acpi_disabled ? pci_bus_of_domain_nr(parent) :
+ pci_bus_acpi_domain_nr(parent);
}
#endif
#endif
^ permalink raw reply related [flat|nested] 184+ messages in thread* Re: [PATCH V3 13/21] pci, acpi: Provide generic way to assign bus domain number.
2016-01-21 18:22 ` Lorenzo Pieralisi
@ 2016-01-21 18:38 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-21 18:38 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On 21.01.2016 19:22, Lorenzo Pieralisi wrote:
> Hi Tomasz,
>
> On Wed, Jan 13, 2016 at 02:20:59PM +0100, Tomasz Nowicki wrote:
>
> [...]
>
>> @@ -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
>
> I think you can reshuffle a bit the code to make it easier to follow.
>
> How about this ? (on top of mainline, I just compiled it do not
> take it verbatim):
>
> -- >8 --
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index d1a7105..467a316 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -7,6 +7,7 @@
> * Copyright 1997 -- 2000 Martin Mares <mj@ucw.cz>
> */
>
> +#include <linux/acpi.h>
> #include <linux/kernel.h>
> #include <linux/delay.h>
> #include <linux/init.h>
> @@ -4769,7 +4770,27 @@ int pci_get_new_domain_nr(void)
> }
>
> #ifdef CONFIG_PCI_DOMAINS_GENERIC
> -void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
> +/* Feel free to add this to drivers/acpi as a helper */
> +#ifdef CONFIG_ACPI
> +int pci_bus_acpi_domain_nr(struct device *parent)
> +{
> + 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");
> +
> + return segment;
> +}
> +#else
> +int pci_bus_acpi_domain_nr(struct device *parent) { return -1; }
> +#endif
> +
> +int pci_bus_of_domain_nr(struct device *parent)
> {
> static int use_dt_domains = -1;
> int domain = of_get_pci_domain_nr(parent->of_node);
> @@ -4811,7 +4832,13 @@ void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
> domain = -1;
> }
>
> - bus->domain_nr = domain;
> + return domain;
> +}
> +
> +void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
> +{
> + bus->domain_nr = acpi_disabled ? pci_bus_of_domain_nr(parent) :
> + pci_bus_acpi_domain_nr(parent);
> }
> #endif
> #endif
>
It looks nice, I will integrate your patch. Thanks!
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 13/21] pci, acpi: Provide generic way to assign bus domain number.
@ 2016-01-21 18:38 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-21 18:38 UTC (permalink / raw)
To: linux-arm-kernel
On 21.01.2016 19:22, Lorenzo Pieralisi wrote:
> Hi Tomasz,
>
> On Wed, Jan 13, 2016 at 02:20:59PM +0100, Tomasz Nowicki wrote:
>
> [...]
>
>> @@ -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
>
> I think you can reshuffle a bit the code to make it easier to follow.
>
> How about this ? (on top of mainline, I just compiled it do not
> take it verbatim):
>
> -- >8 --
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index d1a7105..467a316 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -7,6 +7,7 @@
> * Copyright 1997 -- 2000 Martin Mares <mj@ucw.cz>
> */
>
> +#include <linux/acpi.h>
> #include <linux/kernel.h>
> #include <linux/delay.h>
> #include <linux/init.h>
> @@ -4769,7 +4770,27 @@ int pci_get_new_domain_nr(void)
> }
>
> #ifdef CONFIG_PCI_DOMAINS_GENERIC
> -void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
> +/* Feel free to add this to drivers/acpi as a helper */
> +#ifdef CONFIG_ACPI
> +int pci_bus_acpi_domain_nr(struct device *parent)
> +{
> + 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");
> +
> + return segment;
> +}
> +#else
> +int pci_bus_acpi_domain_nr(struct device *parent) { return -1; }
> +#endif
> +
> +int pci_bus_of_domain_nr(struct device *parent)
> {
> static int use_dt_domains = -1;
> int domain = of_get_pci_domain_nr(parent->of_node);
> @@ -4811,7 +4832,13 @@ void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
> domain = -1;
> }
>
> - bus->domain_nr = domain;
> + return domain;
> +}
> +
> +void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
> +{
> + bus->domain_nr = acpi_disabled ? pci_bus_of_domain_nr(parent) :
> + pci_bus_acpi_domain_nr(parent);
> }
> #endif
> #endif
>
It looks nice, I will integrate your patch. Thanks!
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 13/21] pci, acpi: Provide generic way to assign bus domain number.
2016-01-21 18:38 ` Tomasz Nowicki
@ 2016-01-22 11:25 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-22 11:25 UTC (permalink / raw)
To: Tomasz Nowicki
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On Thu, Jan 21, 2016 at 07:38:51PM +0100, Tomasz Nowicki wrote:
[...]
> >I think you can reshuffle a bit the code to make it easier to follow.
> >
> >How about this ? (on top of mainline, I just compiled it do not
> >take it verbatim):
> >
> >-- >8 --
> >diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> >index d1a7105..467a316 100644
> >--- a/drivers/pci/pci.c
> >+++ b/drivers/pci/pci.c
> >@@ -7,6 +7,7 @@
> > * Copyright 1997 -- 2000 Martin Mares <mj@ucw.cz>
> > */
> >
> >+#include <linux/acpi.h>
> > #include <linux/kernel.h>
> > #include <linux/delay.h>
> > #include <linux/init.h>
> >@@ -4769,7 +4770,27 @@ int pci_get_new_domain_nr(void)
> > }
> >
> > #ifdef CONFIG_PCI_DOMAINS_GENERIC
> >-void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
> >+/* Feel free to add this to drivers/acpi as a helper */
> >+#ifdef CONFIG_ACPI
> >+int pci_bus_acpi_domain_nr(struct device *parent)
> >+{
> >+ 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");
> >+
> >+ return segment;
> >+}
> >+#else
> >+int pci_bus_acpi_domain_nr(struct device *parent) { return -1; }
> >+#endif
> >+
> >+int pci_bus_of_domain_nr(struct device *parent)
> > {
> > static int use_dt_domains = -1;
> > int domain = of_get_pci_domain_nr(parent->of_node);
> >@@ -4811,7 +4832,13 @@ void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
> > domain = -1;
> > }
> >
> >- bus->domain_nr = domain;
> >+ return domain;
> >+}
> >+
> >+void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
> >+{
> >+ bus->domain_nr = acpi_disabled ? pci_bus_of_domain_nr(parent) :
> >+ pci_bus_acpi_domain_nr(parent);
> > }
> > #endif
> > #endif
> >
>
> It looks nice, I will integrate your patch. Thanks!
While at it, as I mentioned, please move the ACPI helper function to
drivers/acpi, thanks.
Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 13/21] pci, acpi: Provide generic way to assign bus domain number.
@ 2016-01-22 11:25 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-22 11:25 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 21, 2016 at 07:38:51PM +0100, Tomasz Nowicki wrote:
[...]
> >I think you can reshuffle a bit the code to make it easier to follow.
> >
> >How about this ? (on top of mainline, I just compiled it do not
> >take it verbatim):
> >
> >-- >8 --
> >diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> >index d1a7105..467a316 100644
> >--- a/drivers/pci/pci.c
> >+++ b/drivers/pci/pci.c
> >@@ -7,6 +7,7 @@
> > * Copyright 1997 -- 2000 Martin Mares <mj@ucw.cz>
> > */
> >
> >+#include <linux/acpi.h>
> > #include <linux/kernel.h>
> > #include <linux/delay.h>
> > #include <linux/init.h>
> >@@ -4769,7 +4770,27 @@ int pci_get_new_domain_nr(void)
> > }
> >
> > #ifdef CONFIG_PCI_DOMAINS_GENERIC
> >-void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
> >+/* Feel free to add this to drivers/acpi as a helper */
> >+#ifdef CONFIG_ACPI
> >+int pci_bus_acpi_domain_nr(struct device *parent)
> >+{
> >+ 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");
> >+
> >+ return segment;
> >+}
> >+#else
> >+int pci_bus_acpi_domain_nr(struct device *parent) { return -1; }
> >+#endif
> >+
> >+int pci_bus_of_domain_nr(struct device *parent)
> > {
> > static int use_dt_domains = -1;
> > int domain = of_get_pci_domain_nr(parent->of_node);
> >@@ -4811,7 +4832,13 @@ void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
> > domain = -1;
> > }
> >
> >- bus->domain_nr = domain;
> >+ return domain;
> >+}
> >+
> >+void pci_bus_assign_domain_nr(struct pci_bus *bus, struct device *parent)
> >+{
> >+ bus->domain_nr = acpi_disabled ? pci_bus_of_domain_nr(parent) :
> >+ pci_bus_acpi_domain_nr(parent);
> > }
> > #endif
> > #endif
> >
>
> It looks nice, I will integrate your patch. Thanks!
While at it, as I mentioned, please move the ACPI helper function to
drivers/acpi, thanks.
Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 14/21] x86, ia64: Include acpi_pci_{add|remove}_bus to the default pcibios_{add|remove}_bus implementation.
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 13:21 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
Arches in subject are the only one who use pcibios_{add|remove}_bus hooks
and implement it in the same way. Moreover ARM64 is going to do the same.
So it seams that acpi_pci_{add|remove}_bus is generic enough to be default
option for pcibios_{add|remove}_bus hooks. Also, it is always safe to run
acpi_pci_{add|remove}_bus as they have empty stubs for !ACPI case and
return if ACPI has been switched off in run time.
After all we can remove x86 and ia64 pcibios_{add|remove}_bus
implementation.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
arch/ia64/pci/pci.c | 10 ----------
arch/x86/pci/common.c | 10 ----------
drivers/pci/probe.c | 3 +++
3 files changed, 3 insertions(+), 20 deletions(-)
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 978d6af..be4c9ef 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -358,16 +358,6 @@ void pcibios_fixup_bus(struct pci_bus *b)
platform_pci_fixup_bus(b);
}
-void pcibios_add_bus(struct pci_bus *bus)
-{
- acpi_pci_add_bus(bus);
-}
-
-void pcibios_remove_bus(struct pci_bus *bus)
-{
- acpi_pci_remove_bus(bus);
-}
-
void pcibios_set_master (struct pci_dev *dev)
{
/* No special bus mastering setup handling */
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index eccd4d9..ed3236d 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -171,16 +171,6 @@ void pcibios_fixup_bus(struct pci_bus *b)
pcibios_fixup_device_resources(dev);
}
-void pcibios_add_bus(struct pci_bus *bus)
-{
- acpi_pci_add_bus(bus);
-}
-
-void pcibios_remove_bus(struct pci_bus *bus)
-{
- acpi_pci_remove_bus(bus);
-}
-
/*
* Only use DMI information to set this if nothing was passed
* on the kernel command line (which was parsed earlier).
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index cad836f..2fbf840 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -12,6 +12,7 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/cpumask.h>
+#include <linux/pci-acpi.h>
#include <linux/pci-aspm.h>
#include <linux/aer.h>
#include <linux/acpi.h>
@@ -2067,10 +2068,12 @@ int __weak pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
void __weak pcibios_add_bus(struct pci_bus *bus)
{
+ acpi_pci_add_bus(bus);
}
void __weak pcibios_remove_bus(struct pci_bus *bus)
{
+ acpi_pci_remove_bus(bus);
}
struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 14/21] x86, ia64: Include acpi_pci_{add|remove}_bus to the default pcibios_{add|remove}_bus implementation.
@ 2016-01-13 13:21 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Arches in subject are the only one who use pcibios_{add|remove}_bus hooks
and implement it in the same way. Moreover ARM64 is going to do the same.
So it seams that acpi_pci_{add|remove}_bus is generic enough to be default
option for pcibios_{add|remove}_bus hooks. Also, it is always safe to run
acpi_pci_{add|remove}_bus as they have empty stubs for !ACPI case and
return if ACPI has been switched off in run time.
After all we can remove x86 and ia64 pcibios_{add|remove}_bus
implementation.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
arch/ia64/pci/pci.c | 10 ----------
arch/x86/pci/common.c | 10 ----------
drivers/pci/probe.c | 3 +++
3 files changed, 3 insertions(+), 20 deletions(-)
diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
index 978d6af..be4c9ef 100644
--- a/arch/ia64/pci/pci.c
+++ b/arch/ia64/pci/pci.c
@@ -358,16 +358,6 @@ void pcibios_fixup_bus(struct pci_bus *b)
platform_pci_fixup_bus(b);
}
-void pcibios_add_bus(struct pci_bus *bus)
-{
- acpi_pci_add_bus(bus);
-}
-
-void pcibios_remove_bus(struct pci_bus *bus)
-{
- acpi_pci_remove_bus(bus);
-}
-
void pcibios_set_master (struct pci_dev *dev)
{
/* No special bus mastering setup handling */
diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index eccd4d9..ed3236d 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -171,16 +171,6 @@ void pcibios_fixup_bus(struct pci_bus *b)
pcibios_fixup_device_resources(dev);
}
-void pcibios_add_bus(struct pci_bus *bus)
-{
- acpi_pci_add_bus(bus);
-}
-
-void pcibios_remove_bus(struct pci_bus *bus)
-{
- acpi_pci_remove_bus(bus);
-}
-
/*
* Only use DMI information to set this if nothing was passed
* on the kernel command line (which was parsed earlier).
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index cad836f..2fbf840 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -12,6 +12,7 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/cpumask.h>
+#include <linux/pci-acpi.h>
#include <linux/pci-aspm.h>
#include <linux/aer.h>
#include <linux/acpi.h>
@@ -2067,10 +2068,12 @@ int __weak pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
void __weak pcibios_add_bus(struct pci_bus *bus)
{
+ acpi_pci_add_bus(bus);
}
void __weak pcibios_remove_bus(struct pci_bus *bus)
{
+ acpi_pci_remove_bus(bus);
}
struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* Re: [PATCH V3 14/21] x86, ia64: Include acpi_pci_{add|remove}_bus to the default pcibios_{add|remove}_bus implementation.
2016-01-13 13:21 ` Tomasz Nowicki
@ 2016-01-14 16:33 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-14 16:33 UTC (permalink / raw)
To: Tomasz Nowicki
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On Wed, Jan 13, 2016 at 02:21:00PM +0100, Tomasz Nowicki wrote:
> Arches in subject are the only one who use pcibios_{add|remove}_bus hooks
"x86 and ia64 are the only arches that implement..."
> and implement it in the same way. Moreover ARM64 is going to do the same.
"implement them"
> So it seams that acpi_pci_{add|remove}_bus is generic enough to be default
s/seams/seems
> option for pcibios_{add|remove}_bus hooks. Also, it is always safe to run
> acpi_pci_{add|remove}_bus as they have empty stubs for !ACPI case and
> return if ACPI has been switched off in run time.
>
> After all we can remove x86 and ia64 pcibios_{add|remove}_bus
> implementation.
I think you should rephrase the commit log and fix the typos.
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> ---
> arch/ia64/pci/pci.c | 10 ----------
> arch/x86/pci/common.c | 10 ----------
> drivers/pci/probe.c | 3 +++
> 3 files changed, 3 insertions(+), 20 deletions(-)
Patch seems fine to me, I do not see why moving the acpi calls into
generic code would create issues (and why it has not been done before)
as you mentioned in the commit log, so:
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
> index 978d6af..be4c9ef 100644
> --- a/arch/ia64/pci/pci.c
> +++ b/arch/ia64/pci/pci.c
> @@ -358,16 +358,6 @@ void pcibios_fixup_bus(struct pci_bus *b)
> platform_pci_fixup_bus(b);
> }
>
> -void pcibios_add_bus(struct pci_bus *bus)
> -{
> - acpi_pci_add_bus(bus);
> -}
> -
> -void pcibios_remove_bus(struct pci_bus *bus)
> -{
> - acpi_pci_remove_bus(bus);
> -}
> -
> void pcibios_set_master (struct pci_dev *dev)
> {
> /* No special bus mastering setup handling */
> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
> index eccd4d9..ed3236d 100644
> --- a/arch/x86/pci/common.c
> +++ b/arch/x86/pci/common.c
> @@ -171,16 +171,6 @@ void pcibios_fixup_bus(struct pci_bus *b)
> pcibios_fixup_device_resources(dev);
> }
>
> -void pcibios_add_bus(struct pci_bus *bus)
> -{
> - acpi_pci_add_bus(bus);
> -}
> -
> -void pcibios_remove_bus(struct pci_bus *bus)
> -{
> - acpi_pci_remove_bus(bus);
> -}
> -
> /*
> * Only use DMI information to set this if nothing was passed
> * on the kernel command line (which was parsed earlier).
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index cad836f..2fbf840 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -12,6 +12,7 @@
> #include <linux/slab.h>
> #include <linux/module.h>
> #include <linux/cpumask.h>
> +#include <linux/pci-acpi.h>
> #include <linux/pci-aspm.h>
> #include <linux/aer.h>
> #include <linux/acpi.h>
> @@ -2067,10 +2068,12 @@ int __weak pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
>
> void __weak pcibios_add_bus(struct pci_bus *bus)
> {
> + acpi_pci_add_bus(bus);
> }
>
> void __weak pcibios_remove_bus(struct pci_bus *bus)
> {
> + acpi_pci_remove_bus(bus);
> }
>
> struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 14/21] x86, ia64: Include acpi_pci_{add|remove}_bus to the default pcibios_{add|remove}_bus implementation.
@ 2016-01-14 16:33 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-14 16:33 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jan 13, 2016 at 02:21:00PM +0100, Tomasz Nowicki wrote:
> Arches in subject are the only one who use pcibios_{add|remove}_bus hooks
"x86 and ia64 are the only arches that implement..."
> and implement it in the same way. Moreover ARM64 is going to do the same.
"implement them"
> So it seams that acpi_pci_{add|remove}_bus is generic enough to be default
s/seams/seems
> option for pcibios_{add|remove}_bus hooks. Also, it is always safe to run
> acpi_pci_{add|remove}_bus as they have empty stubs for !ACPI case and
> return if ACPI has been switched off in run time.
>
> After all we can remove x86 and ia64 pcibios_{add|remove}_bus
> implementation.
I think you should rephrase the commit log and fix the typos.
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> ---
> arch/ia64/pci/pci.c | 10 ----------
> arch/x86/pci/common.c | 10 ----------
> drivers/pci/probe.c | 3 +++
> 3 files changed, 3 insertions(+), 20 deletions(-)
Patch seems fine to me, I do not see why moving the acpi calls into
generic code would create issues (and why it has not been done before)
as you mentioned in the commit log, so:
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> diff --git a/arch/ia64/pci/pci.c b/arch/ia64/pci/pci.c
> index 978d6af..be4c9ef 100644
> --- a/arch/ia64/pci/pci.c
> +++ b/arch/ia64/pci/pci.c
> @@ -358,16 +358,6 @@ void pcibios_fixup_bus(struct pci_bus *b)
> platform_pci_fixup_bus(b);
> }
>
> -void pcibios_add_bus(struct pci_bus *bus)
> -{
> - acpi_pci_add_bus(bus);
> -}
> -
> -void pcibios_remove_bus(struct pci_bus *bus)
> -{
> - acpi_pci_remove_bus(bus);
> -}
> -
> void pcibios_set_master (struct pci_dev *dev)
> {
> /* No special bus mastering setup handling */
> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
> index eccd4d9..ed3236d 100644
> --- a/arch/x86/pci/common.c
> +++ b/arch/x86/pci/common.c
> @@ -171,16 +171,6 @@ void pcibios_fixup_bus(struct pci_bus *b)
> pcibios_fixup_device_resources(dev);
> }
>
> -void pcibios_add_bus(struct pci_bus *bus)
> -{
> - acpi_pci_add_bus(bus);
> -}
> -
> -void pcibios_remove_bus(struct pci_bus *bus)
> -{
> - acpi_pci_remove_bus(bus);
> -}
> -
> /*
> * Only use DMI information to set this if nothing was passed
> * on the kernel command line (which was parsed earlier).
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index cad836f..2fbf840 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -12,6 +12,7 @@
> #include <linux/slab.h>
> #include <linux/module.h>
> #include <linux/cpumask.h>
> +#include <linux/pci-acpi.h>
> #include <linux/pci-aspm.h>
> #include <linux/aer.h>
> #include <linux/acpi.h>
> @@ -2067,10 +2068,12 @@ int __weak pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
>
> void __weak pcibios_add_bus(struct pci_bus *bus)
> {
> + acpi_pci_add_bus(bus);
> }
>
> void __weak pcibios_remove_bus(struct pci_bus *bus)
> {
> + acpi_pci_remove_bus(bus);
> }
>
> struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> --
> 1.9.1
>
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 14/21] x86, ia64: Include acpi_pci_{add|remove}_bus to the default pcibios_{add|remove}_bus implementation.
2016-01-14 16:33 ` Lorenzo Pieralisi
@ 2016-01-14 17:45 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-14 17:45 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On 01/14/2016 05:33 PM, Lorenzo Pieralisi wrote:
> On Wed, Jan 13, 2016 at 02:21:00PM +0100, Tomasz Nowicki wrote:
>> Arches in subject are the only one who use pcibios_{add|remove}_bus hooks
> "x86 and ia64 are the only arches that implement..."
>
>> and implement it in the same way. Moreover ARM64 is going to do the same.
> "implement them"
>
>> So it seams that acpi_pci_{add|remove}_bus is generic enough to be default
> s/seams/seems
>
>> option for pcibios_{add|remove}_bus hooks. Also, it is always safe to run
>> acpi_pci_{add|remove}_bus as they have empty stubs for !ACPI case and
>> return if ACPI has been switched off in run time.
>>
>> After all we can remove x86 and ia64 pcibios_{add|remove}_bus
>> implementation.
> I think you should rephrase the commit log and fix the typos.
yes, I will.
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> ---
>> arch/ia64/pci/pci.c | 10 ----------
>> arch/x86/pci/common.c | 10 ----------
>> drivers/pci/probe.c | 3 +++
>> 3 files changed, 3 insertions(+), 20 deletions(-)
> Patch seems fine to me, I do not see why moving the acpi calls into
> generic code would create issues (and why it has not been done before)
> as you mentioned in the commit log, so:
>
> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Thanks,
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 14/21] x86, ia64: Include acpi_pci_{add|remove}_bus to the default pcibios_{add|remove}_bus implementation.
@ 2016-01-14 17:45 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-14 17:45 UTC (permalink / raw)
To: linux-arm-kernel
On 01/14/2016 05:33 PM, Lorenzo Pieralisi wrote:
> On Wed, Jan 13, 2016 at 02:21:00PM +0100, Tomasz Nowicki wrote:
>> Arches in subject are the only one who use pcibios_{add|remove}_bus hooks
> "x86 and ia64 are the only arches that implement..."
>
>> and implement it in the same way. Moreover ARM64 is going to do the same.
> "implement them"
>
>> So it seams that acpi_pci_{add|remove}_bus is generic enough to be default
> s/seams/seems
>
>> option for pcibios_{add|remove}_bus hooks. Also, it is always safe to run
>> acpi_pci_{add|remove}_bus as they have empty stubs for !ACPI case and
>> return if ACPI has been switched off in run time.
>>
>> After all we can remove x86 and ia64 pcibios_{add|remove}_bus
>> implementation.
> I think you should rephrase the commit log and fix the typos.
yes, I will.
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> ---
>> arch/ia64/pci/pci.c | 10 ----------
>> arch/x86/pci/common.c | 10 ----------
>> drivers/pci/probe.c | 3 +++
>> 3 files changed, 3 insertions(+), 20 deletions(-)
> Patch seems fine to me, I do not see why moving the acpi calls into
> generic code would create issues (and why it has not been done before)
> as you mentioned in the commit log, so:
>
> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Thanks,
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 15/21] acpi, mcfg: Implement two calls that might be used to inject/remove MCFG region.
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 13:21 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
Lets abstract two calls which allow to inject and remove MCFG regions
which may come from DSDT table. These calls will be used for x86 and ARM64
PCI host bridge driver in the later patches.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
drivers/acpi/mcfg.c | 38 ++++++++++++++++++++++++++++++++++++++
include/linux/pci-acpi.h | 9 +++++++++
2 files changed, 47 insertions(+)
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index 3e1e7be..dca4c4e 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -10,6 +10,7 @@
#include <linux/acpi.h>
#include <linux/ecam.h>
#include <linux/pci.h>
+#include <linux/pci-acpi.h>
#define PREFIX "MCFG: "
@@ -77,6 +78,43 @@ int __init acpi_parse_mcfg(struct acpi_table_header *header)
return 0;
}
+int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci)
+{
+ struct pci_mmcfg_region *cfg;
+ struct acpi_pci_root *root;
+ int seg, start, end, err;
+
+ root = ci->root;
+ seg = root->segment;
+ start = root->secondary.start;
+ end = root->secondary.end;
+
+ cfg = pci_mmconfig_lookup(seg, start);
+ if (cfg)
+ return 0;
+
+ cfg = pci_mmconfig_alloc(seg, start, end, root->mcfg_addr);
+ if (!cfg)
+ return -ENOMEM;
+
+ err = pci_mmconfig_inject(cfg);
+ return err;
+}
+
+void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci)
+{
+ struct acpi_pci_root *root = ci->root;
+ struct pci_mmcfg_region *cfg;
+
+ cfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
+ if (!cfg)
+ return;
+
+ if (cfg->hot_added)
+ pci_mmconfig_delete(root->segment, root->secondary.start,
+ root->secondary.end);
+}
+
int __init __weak acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
struct acpi_mcfg_allocation *cfg)
{
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index 89ab057..c277415 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -79,6 +79,15 @@ extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
void acpi_pci_add_bus(struct pci_bus *bus);
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);
+#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) { }
+#endif
+
#ifdef CONFIG_ACPI_PCI_SLOT
void acpi_pci_slot_init(void);
void acpi_pci_slot_enumerate(struct pci_bus *bus);
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 15/21] acpi, mcfg: Implement two calls that might be used to inject/remove MCFG region.
@ 2016-01-13 13:21 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Lets abstract two calls which allow to inject and remove MCFG regions
which may come from DSDT table. These calls will be used for x86 and ARM64
PCI host bridge driver in the later patches.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
drivers/acpi/mcfg.c | 38 ++++++++++++++++++++++++++++++++++++++
include/linux/pci-acpi.h | 9 +++++++++
2 files changed, 47 insertions(+)
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index 3e1e7be..dca4c4e 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -10,6 +10,7 @@
#include <linux/acpi.h>
#include <linux/ecam.h>
#include <linux/pci.h>
+#include <linux/pci-acpi.h>
#define PREFIX "MCFG: "
@@ -77,6 +78,43 @@ int __init acpi_parse_mcfg(struct acpi_table_header *header)
return 0;
}
+int pci_mmcfg_setup_map(struct acpi_pci_root_info *ci)
+{
+ struct pci_mmcfg_region *cfg;
+ struct acpi_pci_root *root;
+ int seg, start, end, err;
+
+ root = ci->root;
+ seg = root->segment;
+ start = root->secondary.start;
+ end = root->secondary.end;
+
+ cfg = pci_mmconfig_lookup(seg, start);
+ if (cfg)
+ return 0;
+
+ cfg = pci_mmconfig_alloc(seg, start, end, root->mcfg_addr);
+ if (!cfg)
+ return -ENOMEM;
+
+ err = pci_mmconfig_inject(cfg);
+ return err;
+}
+
+void pci_mmcfg_teardown_map(struct acpi_pci_root_info *ci)
+{
+ struct acpi_pci_root *root = ci->root;
+ struct pci_mmcfg_region *cfg;
+
+ cfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
+ if (!cfg)
+ return;
+
+ if (cfg->hot_added)
+ pci_mmconfig_delete(root->segment, root->secondary.start,
+ root->secondary.end);
+}
+
int __init __weak acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
struct acpi_mcfg_allocation *cfg)
{
diff --git a/include/linux/pci-acpi.h b/include/linux/pci-acpi.h
index 89ab057..c277415 100644
--- a/include/linux/pci-acpi.h
+++ b/include/linux/pci-acpi.h
@@ -79,6 +79,15 @@ extern struct pci_bus *acpi_pci_root_create(struct acpi_pci_root *root,
void acpi_pci_add_bus(struct pci_bus *bus);
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);
+#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) { }
+#endif
+
#ifdef CONFIG_ACPI_PCI_SLOT
void acpi_pci_slot_init(void);
void acpi_pci_slot_enumerate(struct pci_bus *bus);
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 16/21] x86, acpi, pci: Use equivalent function introduced in previous patch.
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 13:21 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
arch/x86/pci/acpi.c | 20 +-------------------
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 286e0f5..c4d79d2 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -201,29 +201,11 @@ static int setup_mcfg_map(struct acpi_pci_root_info *ci)
return 0;
}
-
-static void teardown_mcfg_map(struct acpi_pci_root_info *ci)
-{
- struct acpi_pci_root *root = ci->root;
- struct pci_mmcfg_region *cfg;
-
- cfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
- if (!cfg)
- return;
-
- if (cfg->hot_added)
- pci_mmconfig_delete(root->segment, root->secondary.start,
- root->secondary.end);
-}
#else
static int setup_mcfg_map(struct acpi_pci_root_info *ci)
{
return 0;
}
-
-static void teardown_mcfg_map(struct acpi_pci_root_info *ci)
-{
-}
#endif
static int pci_acpi_root_get_node(struct acpi_pci_root *root)
@@ -251,7 +233,7 @@ static int pci_acpi_root_init_info(struct acpi_pci_root_info *ci)
static void pci_acpi_root_release_info(struct acpi_pci_root_info *ci)
{
- teardown_mcfg_map(ci);
+ pci_mmcfg_teardown_map(ci);
kfree(container_of(ci, struct pci_root_info, common));
}
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 16/21] x86, acpi, pci: Use equivalent function introduced in previous patch.
@ 2016-01-13 13:21 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
arch/x86/pci/acpi.c | 20 +-------------------
1 file changed, 1 insertion(+), 19 deletions(-)
diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index 286e0f5..c4d79d2 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -201,29 +201,11 @@ static int setup_mcfg_map(struct acpi_pci_root_info *ci)
return 0;
}
-
-static void teardown_mcfg_map(struct acpi_pci_root_info *ci)
-{
- struct acpi_pci_root *root = ci->root;
- struct pci_mmcfg_region *cfg;
-
- cfg = pci_mmconfig_lookup(root->segment, root->secondary.start);
- if (!cfg)
- return;
-
- if (cfg->hot_added)
- pci_mmconfig_delete(root->segment, root->secondary.start,
- root->secondary.end);
-}
#else
static int setup_mcfg_map(struct acpi_pci_root_info *ci)
{
return 0;
}
-
-static void teardown_mcfg_map(struct acpi_pci_root_info *ci)
-{
-}
#endif
static int pci_acpi_root_get_node(struct acpi_pci_root *root)
@@ -251,7 +233,7 @@ static int pci_acpi_root_init_info(struct acpi_pci_root_info *ci)
static void pci_acpi_root_release_info(struct acpi_pci_root_info *ci)
{
- teardown_mcfg_map(ci);
+ pci_mmcfg_teardown_map(ci);
kfree(container_of(ci, struct pci_root_info, common));
}
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 17/21] acpi, mcfg: Add default PCI config accessors implementation and initial support for related quirks.
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 13:21 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
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
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 17/21] acpi, mcfg: Add default PCI config accessors implementation and initial support for related quirks.
@ 2016-01-13 13:21 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 13:21 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm
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
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
@ 2016-01-13 13:21 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply related [flat|nested] 184+ messages in thread* Re: [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
2016-01-13 13:21 ` Tomasz Nowicki
(?)
@ 2016-01-14 12:13 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-14 12:13 UTC (permalink / raw)
To: Tomasz Nowicki
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
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
>
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
@ 2016-01-14 12:13 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-14 12:13 UTC (permalink / raw)
To: linux-arm-kernel
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
>
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
@ 2016-01-14 12:13 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-14 12:13 UTC (permalink / raw)
To: Tomasz Nowicki, jiang.liu
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
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
>
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
2016-01-13 13:21 ` Tomasz Nowicki
(?)
@ 2016-01-19 12:20 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-19 12:20 UTC (permalink / raw)
To: Tomasz Nowicki
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
Gerry,
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.
This patch fixes IO space handling on IA64 and should go in as a fix.
IA64 PCI IO space is currently broken (Hanjun tested this on an IA64 box).
The first broken commit is:
3772aea7d6f3 ("ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge")
because acpi core code checks (in acpi_dev_ioresource_flags()) the
resource.end>=0x10003, which fails on ia64 - currently resource.end is
set in acpi_decode_space() to:
AddressMaximum + AddressTranslation
where AddressTranslation is the CPU physical address mapping IO space
on IA64, the >=0x10003 check in acpi_dev_ioresource_flags always
triggers and the IO resource is then disabled.
Do you want me to re-send this patch as a fix, with updated commit log ?
Thanks,
Lorenzo
> 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
>
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
@ 2016-01-19 12:20 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-19 12:20 UTC (permalink / raw)
To: linux-arm-kernel
Gerry,
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.
This patch fixes IO space handling on IA64 and should go in as a fix.
IA64 PCI IO space is currently broken (Hanjun tested this on an IA64 box).
The first broken commit is:
3772aea7d6f3 ("ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge")
because acpi core code checks (in acpi_dev_ioresource_flags()) the
resource.end>=0x10003, which fails on ia64 - currently resource.end is
set in acpi_decode_space() to:
AddressMaximum + AddressTranslation
where AddressTranslation is the CPU physical address mapping IO space
on IA64, the >=0x10003 check in acpi_dev_ioresource_flags always
triggers and the IO resource is then disabled.
Do you want me to re-send this patch as a fix, with updated commit log ?
Thanks,
Lorenzo
> 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
>
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
@ 2016-01-19 12:20 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-19 12:20 UTC (permalink / raw)
To: Tomasz Nowicki, jiang.liu
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
Gerry,
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.
This patch fixes IO space handling on IA64 and should go in as a fix.
IA64 PCI IO space is currently broken (Hanjun tested this on an IA64 box).
The first broken commit is:
3772aea7d6f3 ("ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge")
because acpi core code checks (in acpi_dev_ioresource_flags()) the
resource.end>=0x10003, which fails on ia64 - currently resource.end is
set in acpi_decode_space() to:
AddressMaximum + AddressTranslation
where AddressTranslation is the CPU physical address mapping IO space
on IA64, the >=0x10003 check in acpi_dev_ioresource_flags always
triggers and the IO resource is then disabled.
Do you want me to re-send this patch as a fix, with updated commit log ?
Thanks,
Lorenzo
> 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
>
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
2016-01-19 12:20 ` Lorenzo Pieralisi
@ 2016-01-25 9:52 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-25 9:52 UTC (permalink / raw)
To: Tomasz Nowicki, jiang.liu
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, Stefano.Stabellini, robert.richter, mw, Liviu.Dudau,
ddaney, tglx, wangyijing, Suravee.Suthikulpanit, msalter,
linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On Tue, Jan 19, 2016 at 12:20:26PM +0000, Lorenzo Pieralisi wrote:
> Gerry,
>
> 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.
>
> This patch fixes IO space handling on IA64 and should go in as a fix.
>
> IA64 PCI IO space is currently broken (Hanjun tested this on an IA64 box).
>
> The first broken commit is:
>
> 3772aea7d6f3 ("ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge")
>
> because acpi core code checks (in acpi_dev_ioresource_flags()) the
> resource.end>=0x10003, which fails on ia64 - currently resource.end is
> set in acpi_decode_space() to:
>
> AddressMaximum + AddressTranslation
>
> where AddressTranslation is the CPU physical address mapping IO space
> on IA64, the >=0x10003 check in acpi_dev_ioresource_flags always
> triggers and the IO resource is then disabled.
>
> Do you want me to re-send this patch as a fix, with updated commit log ?
Two more points to discuss here. IA64, in its prepare_resources() callback
calls acpi_pci_probe_root_resources() in turn. That function parses the
_CRS and validate the resources (acpi_pci_root_validate_resources()).
That does not make sense IMO, because IA64 changes the IO port resources
after calling acpi_pci_probe_root_resources(), hence the validation
carried out in acpi_pci_probe_root_resources(), at least for IO ports
seems wrong (what's the point of validating the CRS against
ioport_resource if we change the _CRS IO space resources afterwards ?).
Second point: we are aware that by removing the offset addition in
acpi_decode_space(), if for any reason on x86 or IA64 a resource has
that offset !=0 (speaking in terms of memory resources for instance)
we are in trouble. Jiang mentioned that on x86 and IA64 offset is always
0x0 for memory resources, but just want to make sure we are all aware
of this potential pitfall.
Comments appreciated, it is time to a) fix IA64 and b) get this _CRS
parsing consolidation done.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
@ 2016-01-25 9:52 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-25 9:52 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jan 19, 2016 at 12:20:26PM +0000, Lorenzo Pieralisi wrote:
> Gerry,
>
> 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.
>
> This patch fixes IO space handling on IA64 and should go in as a fix.
>
> IA64 PCI IO space is currently broken (Hanjun tested this on an IA64 box).
>
> The first broken commit is:
>
> 3772aea7d6f3 ("ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge")
>
> because acpi core code checks (in acpi_dev_ioresource_flags()) the
> resource.end>=0x10003, which fails on ia64 - currently resource.end is
> set in acpi_decode_space() to:
>
> AddressMaximum + AddressTranslation
>
> where AddressTranslation is the CPU physical address mapping IO space
> on IA64, the >=0x10003 check in acpi_dev_ioresource_flags always
> triggers and the IO resource is then disabled.
>
> Do you want me to re-send this patch as a fix, with updated commit log ?
Two more points to discuss here. IA64, in its prepare_resources() callback
calls acpi_pci_probe_root_resources() in turn. That function parses the
_CRS and validate the resources (acpi_pci_root_validate_resources()).
That does not make sense IMO, because IA64 changes the IO port resources
after calling acpi_pci_probe_root_resources(), hence the validation
carried out in acpi_pci_probe_root_resources(), at least for IO ports
seems wrong (what's the point of validating the CRS against
ioport_resource if we change the _CRS IO space resources afterwards ?).
Second point: we are aware that by removing the offset addition in
acpi_decode_space(), if for any reason on x86 or IA64 a resource has
that offset !=0 (speaking in terms of memory resources for instance)
we are in trouble. Jiang mentioned that on x86 and IA64 offset is always
0x0 for memory resources, but just want to make sure we are all aware
of this potential pitfall.
Comments appreciated, it is time to a) fix IA64 and b) get this _CRS
parsing consolidation done.
Thanks,
Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
2016-01-25 9:52 ` Lorenzo Pieralisi
(?)
@ 2016-01-25 16:57 ` Mark Salter
-1 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-25 16:57 UTC (permalink / raw)
To: Lorenzo Pieralisi, Tomasz Nowicki, jiang.liu
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, Stefano.Stabellini, robert.richter, mw, Liviu.Dudau,
ddaney, tglx, wangyijing, Suravee.Suthikulpanit, linux-pci,
linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi,
jchandra, jcm
On Mon, 2016-01-25 at 09:52 +0000, Lorenzo Pieralisi wrote:
> On Tue, Jan 19, 2016 at 12:20:26PM +0000, Lorenzo Pieralisi wrote:
> > Gerry,
> >
> > 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.
> >
> > This patch fixes IO space handling on IA64 and should go in as a fix.
> >
> > IA64 PCI IO space is currently broken (Hanjun tested this on an IA64 box).
> >
> > The first broken commit is:
> >
> > 3772aea7d6f3 ("ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge")
> >
> > because acpi core code checks (in acpi_dev_ioresource_flags()) the
> > resource.end>=0x10003, which fails on ia64 - currently resource.end is
> > set in acpi_decode_space() to:
> >
> > AddressMaximum + AddressTranslation
> >
> > where AddressTranslation is the CPU physical address mapping IO space
> > on IA64, the >=0x10003 check in acpi_dev_ioresource_flags always
> > triggers and the IO resource is then disabled.
> >
> > Do you want me to re-send this patch as a fix, with updated commit log ?
>
> Two more points to discuss here. IA64, in its prepare_resources() callback
> calls acpi_pci_probe_root_resources() in turn. That function parses the
> _CRS and validate the resources (acpi_pci_root_validate_resources()).
>
> That does not make sense IMO, because IA64 changes the IO port resources
> after calling acpi_pci_probe_root_resources(), hence the validation
> carried out in acpi_pci_probe_root_resources(), at least for IO ports
> seems wrong (what's the point of validating the CRS against
> ioport_resource if we change the _CRS IO space resources afterwards ?).
>
I agree that acpi_pci_root_validate_resources() is doing the wrong thing
generally. The current code (without this patch series) is checking CPU
bus address range for PCI IO window against ioport_resource which is based
on ioport cookies made up by the kernel. This patch takes out the addition
of the translation offset so the check is now PCI bus io address range
validated against the cookies in ioport_resource. I think that works by
chance because all ia64 PCI segments use the same PCI bus io address
range based at zero. So the PCI bus io addresses will always look valid
against ia64 IO space zero in the ioport_resource list. The PCI ioports
actually get installed after ia64 changes the resource to hold the
cookie. Interestingly, ia64 also installs an iomem resource for the CPU
bus address of the ioport range window. The generic ACPI PCI host
code should probably do the same in pci_acpi_root_prepare_resource().
And at some point, it might make sense to consolidate the ia64 ioport
cookie handling with that done by the devicetree interfaces used by
the generic ACPI PCI host code.
> Second point: we are aware that by removing the offset addition in
> acpi_decode_space(), if for any reason on x86 or IA64 a resource has
> that offset !=0 (speaking in terms of memory resources for instance)
> we are in trouble. Jiang mentioned that on x86 and IA64 offset is always
> 0x0 for memory resources, but just want to make sure we are all aware
> of this potential pitfall.
I think that has always been the case. At least for x86 which doesn't
appear to have ever used the offset in _CRS. In any case, it still
leaves us with the same problem where acpi_pci_root_validate_resources()
is validating PCI bus addresses against something different (cookies/cpu
iospace for ioport, CPU bus for iomem).
>
> Comments appreciated, it is time to a) fix IA64 and b) get this _CRS
> parsing consolidation done.
>
> Thanks,
> Lorenzo
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
@ 2016-01-25 16:57 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-25 16:57 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2016-01-25 at 09:52 +0000, Lorenzo Pieralisi wrote:
> On Tue, Jan 19, 2016 at 12:20:26PM +0000, Lorenzo Pieralisi wrote:
> > Gerry,
> >
> > 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.
> >
> > This patch fixes IO space handling on IA64 and should go in as a fix.
> >
> > IA64 PCI IO space is currently broken (Hanjun tested this on an IA64 box).
> >
> > The first broken commit is:
> >
> > 3772aea7d6f3 ("ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge")
> >
> > because acpi core code checks (in acpi_dev_ioresource_flags()) the
> > resource.end>=0x10003, which fails on ia64 - currently resource.end is
> > set in acpi_decode_space() to:
> >
> > AddressMaximum + AddressTranslation
> >
> > where AddressTranslation is the CPU physical address mapping IO space
> > on IA64, the >=0x10003 check in acpi_dev_ioresource_flags always
> > triggers and the IO resource is then disabled.
> >
> > Do you want me to re-send this patch as a fix, with updated commit log ?
>
> Two more points to discuss here. IA64, in its prepare_resources() callback
> calls acpi_pci_probe_root_resources() in turn. That function parses the
> _CRS and validate the resources (acpi_pci_root_validate_resources()).
>
> That does not make sense IMO, because IA64 changes the IO port resources
> after calling acpi_pci_probe_root_resources(), hence the validation
> carried out in acpi_pci_probe_root_resources(), at least for IO ports
> seems wrong (what's the point of validating the CRS against
> ioport_resource if we change the _CRS IO space resources afterwards ?).
>
I agree that acpi_pci_root_validate_resources() is doing the wrong thing
generally. The current code (without this patch series) is checking CPU
bus address range for PCI IO window against ioport_resource which is based
on ioport cookies made up by the kernel. This patch takes out the addition
of the translation offset so the check is now PCI bus io address range
validated against the cookies in ioport_resource. I think that works by
chance because all ia64 PCI segments use the same PCI bus io address
range based at zero. So the PCI bus io addresses will always look valid
against ia64 IO space zero in the ioport_resource list. The PCI ioports
actually get installed after ia64 changes the resource to hold the
cookie. Interestingly, ia64 also installs an iomem resource for the CPU
bus address of the ioport range window. The generic ACPI PCI host?
code should probably do the same in pci_acpi_root_prepare_resource().
And at some point, it might make sense to consolidate the ia64 ioport
cookie handling with that done by the devicetree interfaces used by
the generic ACPI PCI host code.
> Second point: we are aware that by removing the offset addition in
> acpi_decode_space(), if for any reason on x86 or IA64 a resource has
> that offset !=0 (speaking in terms of memory resources for instance)
> we are in trouble. Jiang mentioned that on x86 and IA64 offset is always
> 0x0 for memory resources, but just want to make sure we are all aware
> of this potential pitfall.
I think that has always been the case. At least for x86 which doesn't
appear to have ever used the offset in _CRS. In any case, it still
leaves us with the same problem where acpi_pci_root_validate_resources()
is validating PCI bus addresses against something different (cookies/cpu
iospace for ioport, CPU bus for iomem).
>
> Comments appreciated, it is time to a) fix IA64 and b) get this _CRS
> parsing consolidation done.
>
> Thanks,
> Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
@ 2016-01-25 16:57 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-25 16:57 UTC (permalink / raw)
To: Lorenzo Pieralisi, Tomasz Nowicki, jiang.liu
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, Stefano.Stabellini, robert.richter, mw, Liviu.Dudau,
ddaney, tglx, wangyijing, Suravee.Suthikulpanit, linux-pci,
linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi,
jchandra, jcm
On Mon, 2016-01-25 at 09:52 +0000, Lorenzo Pieralisi wrote:
> On Tue, Jan 19, 2016 at 12:20:26PM +0000, Lorenzo Pieralisi wrote:
> > Gerry,
> >
> > 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.
> >
> > This patch fixes IO space handling on IA64 and should go in as a fix.
> >
> > IA64 PCI IO space is currently broken (Hanjun tested this on an IA64 box).
> >
> > The first broken commit is:
> >
> > 3772aea7d6f3 ("ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge")
> >
> > because acpi core code checks (in acpi_dev_ioresource_flags()) the
> > resource.end>=0x10003, which fails on ia64 - currently resource.end is
> > set in acpi_decode_space() to:
> >
> > AddressMaximum + AddressTranslation
> >
> > where AddressTranslation is the CPU physical address mapping IO space
> > on IA64, the >=0x10003 check in acpi_dev_ioresource_flags always
> > triggers and the IO resource is then disabled.
> >
> > Do you want me to re-send this patch as a fix, with updated commit log ?
>
> Two more points to discuss here. IA64, in its prepare_resources() callback
> calls acpi_pci_probe_root_resources() in turn. That function parses the
> _CRS and validate the resources (acpi_pci_root_validate_resources()).
>
> That does not make sense IMO, because IA64 changes the IO port resources
> after calling acpi_pci_probe_root_resources(), hence the validation
> carried out in acpi_pci_probe_root_resources(), at least for IO ports
> seems wrong (what's the point of validating the CRS against
> ioport_resource if we change the _CRS IO space resources afterwards ?).
>
I agree that acpi_pci_root_validate_resources() is doing the wrong thing
generally. The current code (without this patch series) is checking CPU
bus address range for PCI IO window against ioport_resource which is based
on ioport cookies made up by the kernel. This patch takes out the addition
of the translation offset so the check is now PCI bus io address range
validated against the cookies in ioport_resource. I think that works by
chance because all ia64 PCI segments use the same PCI bus io address
range based at zero. So the PCI bus io addresses will always look valid
against ia64 IO space zero in the ioport_resource list. The PCI ioports
actually get installed after ia64 changes the resource to hold the
cookie. Interestingly, ia64 also installs an iomem resource for the CPU
bus address of the ioport range window. The generic ACPI PCI host
code should probably do the same in pci_acpi_root_prepare_resource().
And at some point, it might make sense to consolidate the ia64 ioport
cookie handling with that done by the devicetree interfaces used by
the generic ACPI PCI host code.
> Second point: we are aware that by removing the offset addition in
> acpi_decode_space(), if for any reason on x86 or IA64 a resource has
> that offset !=0 (speaking in terms of memory resources for instance)
> we are in trouble. Jiang mentioned that on x86 and IA64 offset is always
> 0x0 for memory resources, but just want to make sure we are all aware
> of this potential pitfall.
I think that has always been the case. At least for x86 which doesn't
appear to have ever used the offset in _CRS. In any case, it still
leaves us with the same problem where acpi_pci_root_validate_resources()
is validating PCI bus addresses against something different (cookies/cpu
iospace for ioport, CPU bus for iomem).
>
> Comments appreciated, it is time to a) fix IA64 and b) get this _CRS
> parsing consolidation done.
>
> Thanks,
> Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
2016-01-19 12:20 ` Lorenzo Pieralisi
@ 2016-01-28 10:23 ` Hanjun Guo
-1 siblings, 0 replies; 184+ messages in thread
From: Hanjun Guo @ 2016-01-28 10:23 UTC (permalink / raw)
To: Lorenzo Pieralisi, Tomasz Nowicki, jiang.liu
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, okaya,
Stefano.Stabellini, robert.richter, mw, Liviu.Dudau, ddaney,
tglx, wangyijing, Suravee.Suthikulpanit, msalter, linux-pci,
linux-arm-kernel, linux-acpi, linux-kernel, linaro-acpi,
jchandra, jcm
Hi Lorenzo,
On 2016/1/19 20:20, Lorenzo Pieralisi wrote:
> Gerry,
>
> 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.
>
> This patch fixes IO space handling on IA64 and should go in as a fix.
>
> IA64 PCI IO space is currently broken (Hanjun tested this on an IA64 box).
>
> The first broken commit is:
>
> 3772aea7d6f3 ("ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge")
>
> because acpi core code checks (in acpi_dev_ioresource_flags()) the
> resource.end>=0x10003, which fails on ia64 - currently resource.end is
> set in acpi_decode_space() to:
>
> AddressMaximum + AddressTranslation
>
> where AddressTranslation is the CPU physical address mapping IO space
> on IA64, the >=0x10003 check in acpi_dev_ioresource_flags always
> triggers and the IO resource is then disabled.
>
> Do you want me to re-send this patch as a fix, with updated commit log ?
I talked to Gerry offline, he is busy these days, he said it's pretty
OK for you to resend this patch and fix the problem.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 18/21] ACPI, PCI: Refine the way to handle translation_offset for ACPI resources
@ 2016-01-28 10:23 ` Hanjun Guo
0 siblings, 0 replies; 184+ messages in thread
From: Hanjun Guo @ 2016-01-28 10:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi Lorenzo,
On 2016/1/19 20:20, Lorenzo Pieralisi wrote:
> Gerry,
>
> 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.
>
> This patch fixes IO space handling on IA64 and should go in as a fix.
>
> IA64 PCI IO space is currently broken (Hanjun tested this on an IA64 box).
>
> The first broken commit is:
>
> 3772aea7d6f3 ("ia64/PCI/ACPI: Use common ACPI resource parsing interface for host bridge")
>
> because acpi core code checks (in acpi_dev_ioresource_flags()) the
> resource.end>=0x10003, which fails on ia64 - currently resource.end is
> set in acpi_decode_space() to:
>
> AddressMaximum + AddressTranslation
>
> where AddressTranslation is the CPU physical address mapping IO space
> on IA64, the >=0x10003 check in acpi_dev_ioresource_flags always
> triggers and the IO resource is then disabled.
>
> Do you want me to re-send this patch as a fix, with updated commit log ?
I talked to Gerry offline, he is busy these days, he said it's pretty
OK for you to resend this patch and fix the problem.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 13:21 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
Because of two patch series:
1. Jiang Liu's common interface to support PCI host controller init
2. MMCONFIG refactoring (part of this patch set)
now we can think about generic ACPI based PCI host controller init
implementation out of arch/ directory.
These calls use information from MCFG table (PCI config space regions)
and _CRS method (IO/irq resources) to initialize PCI hostbridge.
TBD: We are still not sure whether we should reassign resources
after PCI bus enumeration or trust firmware to do all that work for
us properly.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Liviu Dudau <Liviu.Dudau@arm.com>
CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
CC: Will Deacon <will.deacon@arm.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/acpi/Kconfig | 5 ++
drivers/acpi/pci_root.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 136 insertions(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index c3664be..e315061 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -335,6 +335,11 @@ config ACPI_PCI_SLOT
i.e., segment/bus/device/function tuples, with physical slots in
the system. If you are unsure, say N.
+config ACPI_PCI_HOST_GENERIC
+ bool "Generic ACPI PCI host controller"
+ help
+ Say Y here if you want to support generic ACPI PCI host controller.
+
config X86_PM_TIMER
bool "Power Management Timer Support" if EXPERT
depends on X86
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index a65c8c2..d483e2a 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -24,6 +24,7 @@
#include <linux/init.h>
#include <linux/types.h>
#include <linux/mutex.h>
+#include <linux/of_address.h>
#include <linux/pm.h>
#include <linux/pm_runtime.h>
#include <linux/pci.h>
@@ -514,6 +515,136 @@ static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm)
}
}
+#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
+static int pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
+{
+ if (pci_dev_msi_enabled(dev))
+ return 0;
+
+ acpi_pci_irq_enable(dev);
+ return dev->irq;
+}
+
+static void pci_mcfg_release_info(struct acpi_pci_root_info *ci)
+{
+ pci_mmcfg_teardown_map(ci);
+ kfree(ci);
+}
+
+static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
+{
+ struct list_head *list = &ci->resources;
+ struct acpi_device *device = ci->bridge;
+ struct resource_entry *entry, *tmp;
+ unsigned long flags;
+ int ret;
+
+ flags = IORESOURCE_IO | IORESOURCE_MEM;
+ ret = acpi_dev_get_resources(device, list,
+ acpi_dev_filter_resource_type_cb,
+ (void *)flags);
+ if (ret < 0) {
+ dev_warn(&device->dev,
+ "failed to parse _CRS method, error code %d\n", ret);
+ return ret;
+ } else if (ret == 0)
+ dev_dbg(&device->dev,
+ "no IO and memory resources present in _CRS\n");
+
+ resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
+ resource_size_t cpu_addr, length;
+ struct resource *res = entry->res;
+
+ if (entry->res->flags & IORESOURCE_DISABLED)
+ resource_list_destroy_entry(entry);
+ else
+ res->name = ci->name;
+
+ /* PCI -> CPU space translation */
+ cpu_addr = res->start + entry->offset;
+ length = res->end - res->start + 1;
+
+ if (res->flags & IORESOURCE_MEM) {
+ res->start = cpu_addr;
+ res->end = cpu_addr + length - 1;
+ } else if (res->flags & IORESOURCE_IO) {
+ resource_size_t pci_addr = res->start;
+ unsigned long port;
+
+ if (pci_register_io_range(cpu_addr, length)) {
+ resource_list_destroy_entry(entry);
+ continue;
+ }
+
+ port = pci_address_to_pio(cpu_addr);
+ if (port == (unsigned long)-1) {
+ resource_list_destroy_entry(entry);
+ continue;
+ }
+
+ res->start = port;
+ res->end = port + length - 1;
+ entry->offset = port - pci_addr;
+
+ if (pci_remap_iospace(res, cpu_addr) < 0)
+ resource_list_destroy_entry(entry);
+ }
+ }
+ return ret;
+}
+
+static struct acpi_pci_root_ops acpi_pci_root_ops = {
+ .init_info = pci_mmcfg_setup_map,
+ .release_info = pci_mcfg_release_info,
+ .prepare_resources = pci_acpi_root_prepare_resources,
+};
+
+/* Root bridge scanning */
+struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
+{
+ int node = acpi_get_node(root->device->handle);
+ int domain = root->segment;
+ int busnum = root->secondary.start;
+ struct acpi_pci_root_info *info;
+ struct pci_host_bridge *bridge;
+ struct pci_bus *bus, *child;
+
+ if (domain && !pci_domains_supported) {
+ pr_warn("PCI %04x:%02x: multiple domains not supported.\n",
+ domain, busnum);
+ return NULL;
+ }
+
+ info = kzalloc_node(sizeof(*info), GFP_KERNEL, node);
+ if (!info) {
+ dev_err(&root->device->dev,
+ "pci_bus %04x:%02x: ignored (out of memory)\n",
+ domain, busnum);
+ return NULL;
+ }
+
+ acpi_pci_root_ops.pci_ops = pci_mcfg_get_ops(root);
+ bus = acpi_pci_root_create(root, &acpi_pci_root_ops, info, root);
+ if (!bus)
+ return NULL;
+
+ bridge = pci_find_host_bridge(bus);
+ bridge->map_irq = pcibios_map_irq;
+
+ pci_bus_size_bridges(bus);
+ pci_bus_assign_resources(bus);
+
+ /*
+ * After the PCI-E bus has been walked and all devices discovered,
+ * configure any settings of the fabric that might be necessary.
+ */
+ list_for_each_entry(child, &bus->children, node)
+ pcie_bus_configure_settings(child);
+
+ return bus;
+}
+#endif /* CONFIG_ARCH_PCI_HOST_GENERIC_ACPI */
+
static int acpi_pci_root_add(struct acpi_device *device,
const struct acpi_device_id *not_used)
{
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
@ 2016-01-13 13:21 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Because of two patch series:
1. Jiang Liu's common interface to support PCI host controller init
2. MMCONFIG refactoring (part of this patch set)
now we can think about generic ACPI based PCI host controller init
implementation out of arch/ directory.
These calls use information from MCFG table (PCI config space regions)
and _CRS method (IO/irq resources) to initialize PCI hostbridge.
TBD: We are still not sure whether we should reassign resources
after PCI bus enumeration or trust firmware to do all that work for
us properly.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Liviu Dudau <Liviu.Dudau@arm.com>
CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
CC: Will Deacon <will.deacon@arm.com>
Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Tested-by: Jeremy Linton <jeremy.linton@arm.com>
---
drivers/acpi/Kconfig | 5 ++
drivers/acpi/pci_root.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 136 insertions(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index c3664be..e315061 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -335,6 +335,11 @@ config ACPI_PCI_SLOT
i.e., segment/bus/device/function tuples, with physical slots in
the system. If you are unsure, say N.
+config ACPI_PCI_HOST_GENERIC
+ bool "Generic ACPI PCI host controller"
+ help
+ Say Y here if you want to support generic ACPI PCI host controller.
+
config X86_PM_TIMER
bool "Power Management Timer Support" if EXPERT
depends on X86
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index a65c8c2..d483e2a 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -24,6 +24,7 @@
#include <linux/init.h>
#include <linux/types.h>
#include <linux/mutex.h>
+#include <linux/of_address.h>
#include <linux/pm.h>
#include <linux/pm_runtime.h>
#include <linux/pci.h>
@@ -514,6 +515,136 @@ static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm)
}
}
+#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
+static int pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
+{
+ if (pci_dev_msi_enabled(dev))
+ return 0;
+
+ acpi_pci_irq_enable(dev);
+ return dev->irq;
+}
+
+static void pci_mcfg_release_info(struct acpi_pci_root_info *ci)
+{
+ pci_mmcfg_teardown_map(ci);
+ kfree(ci);
+}
+
+static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
+{
+ struct list_head *list = &ci->resources;
+ struct acpi_device *device = ci->bridge;
+ struct resource_entry *entry, *tmp;
+ unsigned long flags;
+ int ret;
+
+ flags = IORESOURCE_IO | IORESOURCE_MEM;
+ ret = acpi_dev_get_resources(device, list,
+ acpi_dev_filter_resource_type_cb,
+ (void *)flags);
+ if (ret < 0) {
+ dev_warn(&device->dev,
+ "failed to parse _CRS method, error code %d\n", ret);
+ return ret;
+ } else if (ret == 0)
+ dev_dbg(&device->dev,
+ "no IO and memory resources present in _CRS\n");
+
+ resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
+ resource_size_t cpu_addr, length;
+ struct resource *res = entry->res;
+
+ if (entry->res->flags & IORESOURCE_DISABLED)
+ resource_list_destroy_entry(entry);
+ else
+ res->name = ci->name;
+
+ /* PCI -> CPU space translation */
+ cpu_addr = res->start + entry->offset;
+ length = res->end - res->start + 1;
+
+ if (res->flags & IORESOURCE_MEM) {
+ res->start = cpu_addr;
+ res->end = cpu_addr + length - 1;
+ } else if (res->flags & IORESOURCE_IO) {
+ resource_size_t pci_addr = res->start;
+ unsigned long port;
+
+ if (pci_register_io_range(cpu_addr, length)) {
+ resource_list_destroy_entry(entry);
+ continue;
+ }
+
+ port = pci_address_to_pio(cpu_addr);
+ if (port == (unsigned long)-1) {
+ resource_list_destroy_entry(entry);
+ continue;
+ }
+
+ res->start = port;
+ res->end = port + length - 1;
+ entry->offset = port - pci_addr;
+
+ if (pci_remap_iospace(res, cpu_addr) < 0)
+ resource_list_destroy_entry(entry);
+ }
+ }
+ return ret;
+}
+
+static struct acpi_pci_root_ops acpi_pci_root_ops = {
+ .init_info = pci_mmcfg_setup_map,
+ .release_info = pci_mcfg_release_info,
+ .prepare_resources = pci_acpi_root_prepare_resources,
+};
+
+/* Root bridge scanning */
+struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
+{
+ int node = acpi_get_node(root->device->handle);
+ int domain = root->segment;
+ int busnum = root->secondary.start;
+ struct acpi_pci_root_info *info;
+ struct pci_host_bridge *bridge;
+ struct pci_bus *bus, *child;
+
+ if (domain && !pci_domains_supported) {
+ pr_warn("PCI %04x:%02x: multiple domains not supported.\n",
+ domain, busnum);
+ return NULL;
+ }
+
+ info = kzalloc_node(sizeof(*info), GFP_KERNEL, node);
+ if (!info) {
+ dev_err(&root->device->dev,
+ "pci_bus %04x:%02x: ignored (out of memory)\n",
+ domain, busnum);
+ return NULL;
+ }
+
+ acpi_pci_root_ops.pci_ops = pci_mcfg_get_ops(root);
+ bus = acpi_pci_root_create(root, &acpi_pci_root_ops, info, root);
+ if (!bus)
+ return NULL;
+
+ bridge = pci_find_host_bridge(bus);
+ bridge->map_irq = pcibios_map_irq;
+
+ pci_bus_size_bridges(bus);
+ pci_bus_assign_resources(bus);
+
+ /*
+ * After the PCI-E bus has been walked and all devices discovered,
+ * configure any settings of the fabric that might be necessary.
+ */
+ list_for_each_entry(child, &bus->children, node)
+ pcie_bus_configure_settings(child);
+
+ return bus;
+}
+#endif /* CONFIG_ARCH_PCI_HOST_GENERIC_ACPI */
+
static int acpi_pci_root_add(struct acpi_device *device,
const struct acpi_device_id *not_used)
{
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* Re: [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
2016-01-13 13:21 ` Tomasz Nowicki
@ 2016-01-15 9:57 ` Hanjun Guo
-1 siblings, 0 replies; 184+ messages in thread
From: Hanjun Guo @ 2016-01-15 9:57 UTC (permalink / raw)
To: Tomasz Nowicki, bhelgaas, arnd, will.deacon, catalin.marinas,
rjw, Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm
Hi Tomasz,
On 2016/1/13 21:21, Tomasz Nowicki wrote:
> Because of two patch series:
> 1. Jiang Liu's common interface to support PCI host controller init
> 2. MMCONFIG refactoring (part of this patch set)
> now we can think about generic ACPI based PCI host controller init
> implementation out of arch/ directory.
>
> These calls use information from MCFG table (PCI config space regions)
> and _CRS method (IO/irq resources) to initialize PCI hostbridge.
>
> TBD: We are still not sure whether we should reassign resources
> after PCI bus enumeration or trust firmware to do all that work for
> us properly.
>
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> CC: Arnd Bergmann <arnd@arndb.de>
> CC: Catalin Marinas <catalin.marinas@arm.com>
> CC: Liviu Dudau <Liviu.Dudau@arm.com>
> CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
> CC: Will Deacon <will.deacon@arm.com>
> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> Tested-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> drivers/acpi/Kconfig | 5 ++
> drivers/acpi/pci_root.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 136 insertions(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index c3664be..e315061 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -335,6 +335,11 @@ config ACPI_PCI_SLOT
> i.e., segment/bus/device/function tuples, with physical slots in
> the system. If you are unsure, say N.
>
> +config ACPI_PCI_HOST_GENERIC
> + bool "Generic ACPI PCI host controller"
> + help
> + Say Y here if you want to support generic ACPI PCI host controller.
Since x86 and IA64 will not use ACPI_PCI_HOST_GENERIC in this
patch, it should be defined as
config ACPI_PCI_HOST_GENERIC
bool
and select for ARCHs, or will default y on x86 and IA64 too.
Compiling the kernel on a IA64 machine, will send out the
result when it's ready.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
@ 2016-01-15 9:57 ` Hanjun Guo
0 siblings, 0 replies; 184+ messages in thread
From: Hanjun Guo @ 2016-01-15 9:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomasz,
On 2016/1/13 21:21, Tomasz Nowicki wrote:
> Because of two patch series:
> 1. Jiang Liu's common interface to support PCI host controller init
> 2. MMCONFIG refactoring (part of this patch set)
> now we can think about generic ACPI based PCI host controller init
> implementation out of arch/ directory.
>
> These calls use information from MCFG table (PCI config space regions)
> and _CRS method (IO/irq resources) to initialize PCI hostbridge.
>
> TBD: We are still not sure whether we should reassign resources
> after PCI bus enumeration or trust firmware to do all that work for
> us properly.
>
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> CC: Arnd Bergmann <arnd@arndb.de>
> CC: Catalin Marinas <catalin.marinas@arm.com>
> CC: Liviu Dudau <Liviu.Dudau@arm.com>
> CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
> CC: Will Deacon <will.deacon@arm.com>
> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> Tested-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> drivers/acpi/Kconfig | 5 ++
> drivers/acpi/pci_root.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 136 insertions(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index c3664be..e315061 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -335,6 +335,11 @@ config ACPI_PCI_SLOT
> i.e., segment/bus/device/function tuples, with physical slots in
> the system. If you are unsure, say N.
>
> +config ACPI_PCI_HOST_GENERIC
> + bool "Generic ACPI PCI host controller"
> + help
> + Say Y here if you want to support generic ACPI PCI host controller.
Since x86 and IA64 will not use ACPI_PCI_HOST_GENERIC in this
patch, it should be defined as
config ACPI_PCI_HOST_GENERIC
bool
and select for ARCHs, or will default y on x86 and IA64 too.
Compiling the kernel on a IA64 machine, will send out the
result when it's ready.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
2016-01-15 9:57 ` Hanjun Guo
@ 2016-01-18 9:57 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-18 9:57 UTC (permalink / raw)
To: Hanjun Guo, bhelgaas, arnd, will.deacon, catalin.marinas, rjw,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm
On 15.01.2016 10:57, Hanjun Guo wrote:
> Hi Tomasz,
>
> On 2016/1/13 21:21, Tomasz Nowicki wrote:
>> Because of two patch series:
>> 1. Jiang Liu's common interface to support PCI host controller init
>> 2. MMCONFIG refactoring (part of this patch set)
>> now we can think about generic ACPI based PCI host controller init
>> implementation out of arch/ directory.
>>
>> These calls use information from MCFG table (PCI config space regions)
>> and _CRS method (IO/irq resources) to initialize PCI hostbridge.
>>
>> TBD: We are still not sure whether we should reassign resources
>> after PCI bus enumeration or trust firmware to do all that work for
>> us properly.
>>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>> CC: Arnd Bergmann <arnd@arndb.de>
>> CC: Catalin Marinas <catalin.marinas@arm.com>
>> CC: Liviu Dudau <Liviu.Dudau@arm.com>
>> CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
>> CC: Will Deacon <will.deacon@arm.com>
>> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>> Tested-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>> drivers/acpi/Kconfig | 5 ++
>> drivers/acpi/pci_root.c | 131
>> ++++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 136 insertions(+)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index c3664be..e315061 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -335,6 +335,11 @@ config ACPI_PCI_SLOT
>> i.e., segment/bus/device/function tuples, with physical slots in
>> the system. If you are unsure, say N.
>>
>> +config ACPI_PCI_HOST_GENERIC
>> + bool "Generic ACPI PCI host controller"
>> + help
>> + Say Y here if you want to support generic ACPI PCI host
>> controller.
>
> Since x86 and IA64 will not use ACPI_PCI_HOST_GENERIC in this
> patch, it should be defined as
>
> config ACPI_PCI_HOST_GENERIC
> bool
>
> and select for ARCHs, or will default y on x86 and IA64 too.
Right, I will fix that in v4.
>
> Compiling the kernel on a IA64 machine, will send out the
> result when it's ready.
>
Thanks,
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
@ 2016-01-18 9:57 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-18 9:57 UTC (permalink / raw)
To: linux-arm-kernel
On 15.01.2016 10:57, Hanjun Guo wrote:
> Hi Tomasz,
>
> On 2016/1/13 21:21, Tomasz Nowicki wrote:
>> Because of two patch series:
>> 1. Jiang Liu's common interface to support PCI host controller init
>> 2. MMCONFIG refactoring (part of this patch set)
>> now we can think about generic ACPI based PCI host controller init
>> implementation out of arch/ directory.
>>
>> These calls use information from MCFG table (PCI config space regions)
>> and _CRS method (IO/irq resources) to initialize PCI hostbridge.
>>
>> TBD: We are still not sure whether we should reassign resources
>> after PCI bus enumeration or trust firmware to do all that work for
>> us properly.
>>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>> CC: Arnd Bergmann <arnd@arndb.de>
>> CC: Catalin Marinas <catalin.marinas@arm.com>
>> CC: Liviu Dudau <Liviu.Dudau@arm.com>
>> CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
>> CC: Will Deacon <will.deacon@arm.com>
>> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>> Tested-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>> drivers/acpi/Kconfig | 5 ++
>> drivers/acpi/pci_root.c | 131
>> ++++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 136 insertions(+)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index c3664be..e315061 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -335,6 +335,11 @@ config ACPI_PCI_SLOT
>> i.e., segment/bus/device/function tuples, with physical slots in
>> the system. If you are unsure, say N.
>>
>> +config ACPI_PCI_HOST_GENERIC
>> + bool "Generic ACPI PCI host controller"
>> + help
>> + Say Y here if you want to support generic ACPI PCI host
>> controller.
>
> Since x86 and IA64 will not use ACPI_PCI_HOST_GENERIC in this
> patch, it should be defined as
>
> config ACPI_PCI_HOST_GENERIC
> bool
>
> and select for ARCHs, or will default y on x86 and IA64 too.
Right, I will fix that in v4.
>
> Compiling the kernel on a IA64 machine, will send out the
> result when it's ready.
>
Thanks,
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
2016-01-13 13:21 ` Tomasz Nowicki
(?)
@ 2016-01-18 9:25 ` liudongdong (C)
-1 siblings, 0 replies; 184+ messages in thread
From: liudongdong (C) @ 2016-01-18 9:25 UTC (permalink / raw)
To: Tomasz Nowicki, bhelgaas, arnd, will.deacon, catalin.marinas,
rjw, hanjun.guo, Lorenzo.Pieralisi, okaya, jiang.liu,
Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm
Hi Tomasz,
在 2016/1/13 21:21, Tomasz Nowicki 写道:
> Because of two patch series:
> 1. Jiang Liu's common interface to support PCI host controller init
> 2. MMCONFIG refactoring (part of this patch set)
> now we can think about generic ACPI based PCI host controller init
> implementation out of arch/ directory.
>
> These calls use information from MCFG table (PCI config space regions)
> and _CRS method (IO/irq resources) to initialize PCI hostbridge.
>
> TBD: We are still not sure whether we should reassign resources
> after PCI bus enumeration or trust firmware to do all that work for
> us properly.
>
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> CC: Arnd Bergmann <arnd@arndb.de>
> CC: Catalin Marinas <catalin.marinas@arm.com>
> CC: Liviu Dudau <Liviu.Dudau@arm.com>
> CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
> CC: Will Deacon <will.deacon@arm.com>
> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> Tested-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> drivers/acpi/Kconfig | 5 ++
> drivers/acpi/pci_root.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 136 insertions(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index c3664be..e315061 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -335,6 +335,11 @@ config ACPI_PCI_SLOT
> i.e., segment/bus/device/function tuples, with physical slots in
> the system. If you are unsure, say N.
>
> +config ACPI_PCI_HOST_GENERIC
> + bool "Generic ACPI PCI host controller"
> + help
> + Say Y here if you want to support generic ACPI PCI host controller.
> +
> config X86_PM_TIMER
> bool "Power Management Timer Support" if EXPERT
> depends on X86
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index a65c8c2..d483e2a 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -24,6 +24,7 @@
> #include <linux/init.h>
> #include <linux/types.h>
> #include <linux/mutex.h>
> +#include <linux/of_address.h>
> #include <linux/pm.h>
> #include <linux/pm_runtime.h>
> #include <linux/pci.h>
> @@ -514,6 +515,136 @@ static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm)
> }
> }
>
> +#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
> +static int pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
> +{
> + if (pci_dev_msi_enabled(dev))
> + return 0;
> +
> + acpi_pci_irq_enable(dev);
> + return dev->irq;
> +}
> +
> +static void pci_mcfg_release_info(struct acpi_pci_root_info *ci)
> +{
> + pci_mmcfg_teardown_map(ci);
> + kfree(ci);
> +}
> +
> +static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
> +{
> + struct list_head *list = &ci->resources;
> + struct acpi_device *device = ci->bridge;
> + struct resource_entry *entry, *tmp;
> + unsigned long flags;
> + int ret;
> +
> + flags = IORESOURCE_IO | IORESOURCE_MEM;
> + ret = acpi_dev_get_resources(device, list,
> + acpi_dev_filter_resource_type_cb,
> + (void *)flags);
> + if (ret < 0) {
> + dev_warn(&device->dev,
> + "failed to parse _CRS method, error code %d\n", ret);
> + return ret;
> + } else if (ret == 0)
> + dev_dbg(&device->dev,
> + "no IO and memory resources present in _CRS\n");
> +
> + resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
> + resource_size_t cpu_addr, length;
> + struct resource *res = entry->res;
> +
> + if (entry->res->flags & IORESOURCE_DISABLED)
> + resource_list_destroy_entry(entry);
> + else
> + res->name = ci->name;
> +
> + /* PCI -> CPU space translation */
> + cpu_addr = res->start + entry->offset;
> + length = res->end - res->start + 1;
I see here is different from V2 patch,
in V2 patch, 0x0000022004000000 is cpu addr.
but in V3 patch, 0x0000022004000000 is pci addr.
which one is right ?
0x0000022004000000 is the value of AddressMinimum.
AddressMinimum evaluates to a 64-bit integer that specifies the lowest possible base address of the Memory range
QWordMemory ( // 64-bit BAR Windows
ResourceProducer, PosDecode,
MinFixed, MaxFixed,
Cacheable, ReadWrite,
0x000000000000000, // Granularity
0x0000022004000000, // Min Base Address
0x000002200fffffff, // Max Base Address
0x0000021ff9000000, // Translate
0x000000000c000000 // Length
)
Thanks
Dongdong
> +
> + if (res->flags & IORESOURCE_MEM) {
> + res->start = cpu_addr;
> + res->end = cpu_addr + length - 1;
> + } else if (res->flags & IORESOURCE_IO) {
> + resource_size_t pci_addr = res->start;
> + unsigned long port;
> +
> + if (pci_register_io_range(cpu_addr, length)) {
> + resource_list_destroy_entry(entry);
> + continue;
> + }
> +
> + port = pci_address_to_pio(cpu_addr);
> + if (port == (unsigned long)-1) {
> + resource_list_destroy_entry(entry);
> + continue;
> + }
> +
> + res->start = port;
> + res->end = port + length - 1;
> + entry->offset = port - pci_addr;
> +
> + if (pci_remap_iospace(res, cpu_addr) < 0)
> + resource_list_destroy_entry(entry);
> + }
> + }
> + return ret;
> +}
> +
> +static struct acpi_pci_root_ops acpi_pci_root_ops = {
> + .init_info = pci_mmcfg_setup_map,
> + .release_info = pci_mcfg_release_info,
> + .prepare_resources = pci_acpi_root_prepare_resources,
> +};
> +
> +/* Root bridge scanning */
> +struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> +{
> + int node = acpi_get_node(root->device->handle);
> + int domain = root->segment;
> + int busnum = root->secondary.start;
> + struct acpi_pci_root_info *info;
> + struct pci_host_bridge *bridge;
> + struct pci_bus *bus, *child;
> +
> + if (domain && !pci_domains_supported) {
> + pr_warn("PCI %04x:%02x: multiple domains not supported.\n",
> + domain, busnum);
> + return NULL;
> + }
> +
> + info = kzalloc_node(sizeof(*info), GFP_KERNEL, node);
> + if (!info) {
> + dev_err(&root->device->dev,
> + "pci_bus %04x:%02x: ignored (out of memory)\n",
> + domain, busnum);
> + return NULL;
> + }
> +
> + acpi_pci_root_ops.pci_ops = pci_mcfg_get_ops(root);
> + bus = acpi_pci_root_create(root, &acpi_pci_root_ops, info, root);
> + if (!bus)
> + return NULL;
> +
> + bridge = pci_find_host_bridge(bus);
> + bridge->map_irq = pcibios_map_irq;
> +
> + pci_bus_size_bridges(bus);
> + pci_bus_assign_resources(bus);
> +
> + /*
> + * After the PCI-E bus has been walked and all devices discovered,
> + * configure any settings of the fabric that might be necessary.
> + */
> + list_for_each_entry(child, &bus->children, node)
> + pcie_bus_configure_settings(child);
> +
> + return bus;
> +}
> +#endif /* CONFIG_ARCH_PCI_HOST_GENERIC_ACPI */
> +
> static int acpi_pci_root_add(struct acpi_device *device,
> const struct acpi_device_id *not_used)
> {
>
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
@ 2016-01-18 9:25 ` liudongdong (C)
0 siblings, 0 replies; 184+ messages in thread
From: liudongdong (C) @ 2016-01-18 9:25 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomasz,
? 2016/1/13 21:21, Tomasz Nowicki ??:
> Because of two patch series:
> 1. Jiang Liu's common interface to support PCI host controller init
> 2. MMCONFIG refactoring (part of this patch set)
> now we can think about generic ACPI based PCI host controller init
> implementation out of arch/ directory.
>
> These calls use information from MCFG table (PCI config space regions)
> and _CRS method (IO/irq resources) to initialize PCI hostbridge.
>
> TBD: We are still not sure whether we should reassign resources
> after PCI bus enumeration or trust firmware to do all that work for
> us properly.
>
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> CC: Arnd Bergmann <arnd@arndb.de>
> CC: Catalin Marinas <catalin.marinas@arm.com>
> CC: Liviu Dudau <Liviu.Dudau@arm.com>
> CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
> CC: Will Deacon <will.deacon@arm.com>
> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> Tested-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> drivers/acpi/Kconfig | 5 ++
> drivers/acpi/pci_root.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 136 insertions(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index c3664be..e315061 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -335,6 +335,11 @@ config ACPI_PCI_SLOT
> i.e., segment/bus/device/function tuples, with physical slots in
> the system. If you are unsure, say N.
>
> +config ACPI_PCI_HOST_GENERIC
> + bool "Generic ACPI PCI host controller"
> + help
> + Say Y here if you want to support generic ACPI PCI host controller.
> +
> config X86_PM_TIMER
> bool "Power Management Timer Support" if EXPERT
> depends on X86
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index a65c8c2..d483e2a 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -24,6 +24,7 @@
> #include <linux/init.h>
> #include <linux/types.h>
> #include <linux/mutex.h>
> +#include <linux/of_address.h>
> #include <linux/pm.h>
> #include <linux/pm_runtime.h>
> #include <linux/pci.h>
> @@ -514,6 +515,136 @@ static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm)
> }
> }
>
> +#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
> +static int pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
> +{
> + if (pci_dev_msi_enabled(dev))
> + return 0;
> +
> + acpi_pci_irq_enable(dev);
> + return dev->irq;
> +}
> +
> +static void pci_mcfg_release_info(struct acpi_pci_root_info *ci)
> +{
> + pci_mmcfg_teardown_map(ci);
> + kfree(ci);
> +}
> +
> +static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
> +{
> + struct list_head *list = &ci->resources;
> + struct acpi_device *device = ci->bridge;
> + struct resource_entry *entry, *tmp;
> + unsigned long flags;
> + int ret;
> +
> + flags = IORESOURCE_IO | IORESOURCE_MEM;
> + ret = acpi_dev_get_resources(device, list,
> + acpi_dev_filter_resource_type_cb,
> + (void *)flags);
> + if (ret < 0) {
> + dev_warn(&device->dev,
> + "failed to parse _CRS method, error code %d\n", ret);
> + return ret;
> + } else if (ret == 0)
> + dev_dbg(&device->dev,
> + "no IO and memory resources present in _CRS\n");
> +
> + resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
> + resource_size_t cpu_addr, length;
> + struct resource *res = entry->res;
> +
> + if (entry->res->flags & IORESOURCE_DISABLED)
> + resource_list_destroy_entry(entry);
> + else
> + res->name = ci->name;
> +
> + /* PCI -> CPU space translation */
> + cpu_addr = res->start + entry->offset;
> + length = res->end - res->start + 1;
I see here is different from V2 patch,
in V2 patch, 0x0000022004000000 is cpu addr.
but in V3 patch, 0x0000022004000000 is pci addr.
which one is right ?
0x0000022004000000 is the value of AddressMinimum.
AddressMinimum evaluates to a 64-bit integer that specifies the lowest possible base address of the Memory range
QWordMemory ( // 64-bit BAR Windows
ResourceProducer, PosDecode,
MinFixed, MaxFixed,
Cacheable, ReadWrite,
0x000000000000000, // Granularity
0x0000022004000000, // Min Base Address
0x000002200fffffff, // Max Base Address
0x0000021ff9000000, // Translate
0x000000000c000000 // Length
)
Thanks
Dongdong
> +
> + if (res->flags & IORESOURCE_MEM) {
> + res->start = cpu_addr;
> + res->end = cpu_addr + length - 1;
> + } else if (res->flags & IORESOURCE_IO) {
> + resource_size_t pci_addr = res->start;
> + unsigned long port;
> +
> + if (pci_register_io_range(cpu_addr, length)) {
> + resource_list_destroy_entry(entry);
> + continue;
> + }
> +
> + port = pci_address_to_pio(cpu_addr);
> + if (port == (unsigned long)-1) {
> + resource_list_destroy_entry(entry);
> + continue;
> + }
> +
> + res->start = port;
> + res->end = port + length - 1;
> + entry->offset = port - pci_addr;
> +
> + if (pci_remap_iospace(res, cpu_addr) < 0)
> + resource_list_destroy_entry(entry);
> + }
> + }
> + return ret;
> +}
> +
> +static struct acpi_pci_root_ops acpi_pci_root_ops = {
> + .init_info = pci_mmcfg_setup_map,
> + .release_info = pci_mcfg_release_info,
> + .prepare_resources = pci_acpi_root_prepare_resources,
> +};
> +
> +/* Root bridge scanning */
> +struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> +{
> + int node = acpi_get_node(root->device->handle);
> + int domain = root->segment;
> + int busnum = root->secondary.start;
> + struct acpi_pci_root_info *info;
> + struct pci_host_bridge *bridge;
> + struct pci_bus *bus, *child;
> +
> + if (domain && !pci_domains_supported) {
> + pr_warn("PCI %04x:%02x: multiple domains not supported.\n",
> + domain, busnum);
> + return NULL;
> + }
> +
> + info = kzalloc_node(sizeof(*info), GFP_KERNEL, node);
> + if (!info) {
> + dev_err(&root->device->dev,
> + "pci_bus %04x:%02x: ignored (out of memory)\n",
> + domain, busnum);
> + return NULL;
> + }
> +
> + acpi_pci_root_ops.pci_ops = pci_mcfg_get_ops(root);
> + bus = acpi_pci_root_create(root, &acpi_pci_root_ops, info, root);
> + if (!bus)
> + return NULL;
> +
> + bridge = pci_find_host_bridge(bus);
> + bridge->map_irq = pcibios_map_irq;
> +
> + pci_bus_size_bridges(bus);
> + pci_bus_assign_resources(bus);
> +
> + /*
> + * After the PCI-E bus has been walked and all devices discovered,
> + * configure any settings of the fabric that might be necessary.
> + */
> + list_for_each_entry(child, &bus->children, node)
> + pcie_bus_configure_settings(child);
> +
> + return bus;
> +}
> +#endif /* CONFIG_ARCH_PCI_HOST_GENERIC_ACPI */
> +
> static int acpi_pci_root_add(struct acpi_device *device,
> const struct acpi_device_id *not_used)
> {
>
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
@ 2016-01-18 9:25 ` liudongdong (C)
0 siblings, 0 replies; 184+ messages in thread
From: liudongdong (C) @ 2016-01-18 9:25 UTC (permalink / raw)
To: Tomasz Nowicki, bhelgaas, arnd, will.deacon, catalin.marinas,
rjw, hanjun.guo, Lorenzo.Pieralisi, okaya, jiang.liu,
Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm
Hi Tomasz,
在 2016/1/13 21:21, Tomasz Nowicki 写道:
> Because of two patch series:
> 1. Jiang Liu's common interface to support PCI host controller init
> 2. MMCONFIG refactoring (part of this patch set)
> now we can think about generic ACPI based PCI host controller init
> implementation out of arch/ directory.
>
> These calls use information from MCFG table (PCI config space regions)
> and _CRS method (IO/irq resources) to initialize PCI hostbridge.
>
> TBD: We are still not sure whether we should reassign resources
> after PCI bus enumeration or trust firmware to do all that work for
> us properly.
>
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> CC: Arnd Bergmann <arnd@arndb.de>
> CC: Catalin Marinas <catalin.marinas@arm.com>
> CC: Liviu Dudau <Liviu.Dudau@arm.com>
> CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
> CC: Will Deacon <will.deacon@arm.com>
> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> Tested-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> drivers/acpi/Kconfig | 5 ++
> drivers/acpi/pci_root.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 136 insertions(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index c3664be..e315061 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -335,6 +335,11 @@ config ACPI_PCI_SLOT
> i.e., segment/bus/device/function tuples, with physical slots in
> the system. If you are unsure, say N.
>
> +config ACPI_PCI_HOST_GENERIC
> + bool "Generic ACPI PCI host controller"
> + help
> + Say Y here if you want to support generic ACPI PCI host controller.
> +
> config X86_PM_TIMER
> bool "Power Management Timer Support" if EXPERT
> depends on X86
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index a65c8c2..d483e2a 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -24,6 +24,7 @@
> #include <linux/init.h>
> #include <linux/types.h>
> #include <linux/mutex.h>
> +#include <linux/of_address.h>
> #include <linux/pm.h>
> #include <linux/pm_runtime.h>
> #include <linux/pci.h>
> @@ -514,6 +515,136 @@ static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm)
> }
> }
>
> +#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
> +static int pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
> +{
> + if (pci_dev_msi_enabled(dev))
> + return 0;
> +
> + acpi_pci_irq_enable(dev);
> + return dev->irq;
> +}
> +
> +static void pci_mcfg_release_info(struct acpi_pci_root_info *ci)
> +{
> + pci_mmcfg_teardown_map(ci);
> + kfree(ci);
> +}
> +
> +static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
> +{
> + struct list_head *list = &ci->resources;
> + struct acpi_device *device = ci->bridge;
> + struct resource_entry *entry, *tmp;
> + unsigned long flags;
> + int ret;
> +
> + flags = IORESOURCE_IO | IORESOURCE_MEM;
> + ret = acpi_dev_get_resources(device, list,
> + acpi_dev_filter_resource_type_cb,
> + (void *)flags);
> + if (ret < 0) {
> + dev_warn(&device->dev,
> + "failed to parse _CRS method, error code %d\n", ret);
> + return ret;
> + } else if (ret == 0)
> + dev_dbg(&device->dev,
> + "no IO and memory resources present in _CRS\n");
> +
> + resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
> + resource_size_t cpu_addr, length;
> + struct resource *res = entry->res;
> +
> + if (entry->res->flags & IORESOURCE_DISABLED)
> + resource_list_destroy_entry(entry);
> + else
> + res->name = ci->name;
> +
> + /* PCI -> CPU space translation */
> + cpu_addr = res->start + entry->offset;
> + length = res->end - res->start + 1;
I see here is different from V2 patch,
in V2 patch, 0x0000022004000000 is cpu addr.
but in V3 patch, 0x0000022004000000 is pci addr.
which one is right ?
0x0000022004000000 is the value of AddressMinimum.
AddressMinimum evaluates to a 64-bit integer that specifies the lowest possible base address of the Memory range
QWordMemory ( // 64-bit BAR Windows
ResourceProducer, PosDecode,
MinFixed, MaxFixed,
Cacheable, ReadWrite,
0x000000000000000, // Granularity
0x0000022004000000, // Min Base Address
0x000002200fffffff, // Max Base Address
0x0000021ff9000000, // Translate
0x000000000c000000 // Length
)
Thanks
Dongdong
> +
> + if (res->flags & IORESOURCE_MEM) {
> + res->start = cpu_addr;
> + res->end = cpu_addr + length - 1;
> + } else if (res->flags & IORESOURCE_IO) {
> + resource_size_t pci_addr = res->start;
> + unsigned long port;
> +
> + if (pci_register_io_range(cpu_addr, length)) {
> + resource_list_destroy_entry(entry);
> + continue;
> + }
> +
> + port = pci_address_to_pio(cpu_addr);
> + if (port == (unsigned long)-1) {
> + resource_list_destroy_entry(entry);
> + continue;
> + }
> +
> + res->start = port;
> + res->end = port + length - 1;
> + entry->offset = port - pci_addr;
> +
> + if (pci_remap_iospace(res, cpu_addr) < 0)
> + resource_list_destroy_entry(entry);
> + }
> + }
> + return ret;
> +}
> +
> +static struct acpi_pci_root_ops acpi_pci_root_ops = {
> + .init_info = pci_mmcfg_setup_map,
> + .release_info = pci_mcfg_release_info,
> + .prepare_resources = pci_acpi_root_prepare_resources,
> +};
> +
> +/* Root bridge scanning */
> +struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> +{
> + int node = acpi_get_node(root->device->handle);
> + int domain = root->segment;
> + int busnum = root->secondary.start;
> + struct acpi_pci_root_info *info;
> + struct pci_host_bridge *bridge;
> + struct pci_bus *bus, *child;
> +
> + if (domain && !pci_domains_supported) {
> + pr_warn("PCI %04x:%02x: multiple domains not supported.\n",
> + domain, busnum);
> + return NULL;
> + }
> +
> + info = kzalloc_node(sizeof(*info), GFP_KERNEL, node);
> + if (!info) {
> + dev_err(&root->device->dev,
> + "pci_bus %04x:%02x: ignored (out of memory)\n",
> + domain, busnum);
> + return NULL;
> + }
> +
> + acpi_pci_root_ops.pci_ops = pci_mcfg_get_ops(root);
> + bus = acpi_pci_root_create(root, &acpi_pci_root_ops, info, root);
> + if (!bus)
> + return NULL;
> +
> + bridge = pci_find_host_bridge(bus);
> + bridge->map_irq = pcibios_map_irq;
> +
> + pci_bus_size_bridges(bus);
> + pci_bus_assign_resources(bus);
> +
> + /*
> + * After the PCI-E bus has been walked and all devices discovered,
> + * configure any settings of the fabric that might be necessary.
> + */
> + list_for_each_entry(child, &bus->children, node)
> + pcie_bus_configure_settings(child);
> +
> + return bus;
> +}
> +#endif /* CONFIG_ARCH_PCI_HOST_GENERIC_ACPI */
> +
> static int acpi_pci_root_add(struct acpi_device *device,
> const struct acpi_device_id *not_used)
> {
>
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
2016-01-18 9:25 ` liudongdong (C)
@ 2016-01-18 10:34 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-18 10:34 UTC (permalink / raw)
To: liudongdong (C),
bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm
On 18.01.2016 10:25, liudongdong (C) wrote:
> I see here is different from V2 patch,
> in V2 patch, 0x0000022004000000 is cpu addr.
> but in V3 patch, 0x0000022004000000 is pci addr.
> which one is right ?
You are right, I look back at v2 and see bug there. But v3 fixes it, for
MEM & IO we always need to calculate this way:
CPU address defined as: cpu_addr = res->start + entry->offset;
PCI address: pci_addr = res->start;
>
> 0x0000022004000000 is the value of AddressMinimum.
> AddressMinimum evaluates to a 64-bit integer that specifies the lowest
> possible base address of the Memory range
> QWordMemory ( // 64-bit BAR Windows
> ResourceProducer, PosDecode,
> MinFixed, MaxFixed,
> Cacheable, ReadWrite,
> 0x000000000000000, // Granularity
> 0x0000022004000000, // Min Base Address
> 0x000002200fffffff, // Max Base Address
> 0x0000021ff9000000, // Translate
> 0x000000000c000000 // Length
> )
For your case:
cpu_addr = 0x0000022004000000 + 0x0000021ff9000000:
pci_addr = 0x0000022004000000;
Regards,
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
@ 2016-01-18 10:34 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-18 10:34 UTC (permalink / raw)
To: linux-arm-kernel
On 18.01.2016 10:25, liudongdong (C) wrote:
> I see here is different from V2 patch,
> in V2 patch, 0x0000022004000000 is cpu addr.
> but in V3 patch, 0x0000022004000000 is pci addr.
> which one is right ?
You are right, I look back at v2 and see bug there. But v3 fixes it, for
MEM & IO we always need to calculate this way:
CPU address defined as: cpu_addr = res->start + entry->offset;
PCI address: pci_addr = res->start;
>
> 0x0000022004000000 is the value of AddressMinimum.
> AddressMinimum evaluates to a 64-bit integer that specifies the lowest
> possible base address of the Memory range
> QWordMemory ( // 64-bit BAR Windows
> ResourceProducer, PosDecode,
> MinFixed, MaxFixed,
> Cacheable, ReadWrite,
> 0x000000000000000, // Granularity
> 0x0000022004000000, // Min Base Address
> 0x000002200fffffff, // Max Base Address
> 0x0000021ff9000000, // Translate
> 0x000000000c000000 // Length
> )
For your case:
cpu_addr = 0x0000022004000000 + 0x0000021ff9000000:
pci_addr = 0x0000022004000000;
Regards,
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
2016-01-13 13:21 ` Tomasz Nowicki
@ 2016-01-19 11:58 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-19 11:58 UTC (permalink / raw)
To: Tomasz Nowicki
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On Wed, Jan 13, 2016 at 02:21:05PM +0100, Tomasz Nowicki wrote:
> Because of two patch series:
> 1. Jiang Liu's common interface to support PCI host controller init
> 2. MMCONFIG refactoring (part of this patch set)
> now we can think about generic ACPI based PCI host controller init
> implementation out of arch/ directory.
>
> These calls use information from MCFG table (PCI config space regions)
> and _CRS method (IO/irq resources) to initialize PCI hostbridge.
>
> TBD: We are still not sure whether we should reassign resources
> after PCI bus enumeration or trust firmware to do all that work for
> us properly.
We should claim resources and assign unassigned ones. I put together a
patch for resource claiming instead of reinventing the wheel, waiting
for feedback:
https://patchwork.ozlabs.org/patch/545669/
If we merge the code with no resources claiming, we may end up in
situations where claiming can trigger regressions so we won't be able
to do it anymore.
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> CC: Arnd Bergmann <arnd@arndb.de>
> CC: Catalin Marinas <catalin.marinas@arm.com>
> CC: Liviu Dudau <Liviu.Dudau@arm.com>
> CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
> CC: Will Deacon <will.deacon@arm.com>
> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> Tested-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> drivers/acpi/Kconfig | 5 ++
> drivers/acpi/pci_root.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 136 insertions(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index c3664be..e315061 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -335,6 +335,11 @@ config ACPI_PCI_SLOT
> i.e., segment/bus/device/function tuples, with physical slots in
> the system. If you are unsure, say N.
>
> +config ACPI_PCI_HOST_GENERIC
> + bool "Generic ACPI PCI host controller"
> + help
> + Say Y here if you want to support generic ACPI PCI host controller.
You should add a proper description here.
> +
> config X86_PM_TIMER
> bool "Power Management Timer Support" if EXPERT
> depends on X86
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index a65c8c2..d483e2a 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -24,6 +24,7 @@
> #include <linux/init.h>
> #include <linux/types.h>
> #include <linux/mutex.h>
> +#include <linux/of_address.h>
We should move the IO space management to PCI core instead of having
it in OF core, code carrying out PIO mapping does not depend on OF
as far as I can see.
> #include <linux/pm.h>
> #include <linux/pm_runtime.h>
> #include <linux/pci.h>
> @@ -514,6 +515,136 @@ static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm)
> }
> }
>
> +#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
> +static int pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
> +{
> + if (pci_dev_msi_enabled(dev))
> + return 0;
> +
> + acpi_pci_irq_enable(dev);
> + return dev->irq;
> +}
> +
> +static void pci_mcfg_release_info(struct acpi_pci_root_info *ci)
> +{
> + pci_mmcfg_teardown_map(ci);
> + kfree(ci);
> +}
> +
> +static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
> +{
> + struct list_head *list = &ci->resources;
> + struct acpi_device *device = ci->bridge;
> + struct resource_entry *entry, *tmp;
> + unsigned long flags;
> + int ret;
> +
> + flags = IORESOURCE_IO | IORESOURCE_MEM;
> + ret = acpi_dev_get_resources(device, list,
> + acpi_dev_filter_resource_type_cb,
> + (void *)flags);
> + if (ret < 0) {
> + dev_warn(&device->dev,
> + "failed to parse _CRS method, error code %d\n", ret);
> + return ret;
> + } else if (ret == 0)
> + dev_dbg(&device->dev,
> + "no IO and memory resources present in _CRS\n");
^^^^
what's the point in carrying on then ?
> +
> + resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
> + resource_size_t cpu_addr, length;
> + struct resource *res = entry->res;
> +
> + if (entry->res->flags & IORESOURCE_DISABLED)
> + resource_list_destroy_entry(entry);
> + else
> + res->name = ci->name;
> +
> + /* PCI -> CPU space translation */
> + cpu_addr = res->start + entry->offset;
> + length = res->end - res->start + 1;
> +
> + if (res->flags & IORESOURCE_MEM) {
> + res->start = cpu_addr;
> + res->end = cpu_addr + length - 1;
> + } else if (res->flags & IORESOURCE_IO) {
> + resource_size_t pci_addr = res->start;
> + unsigned long port;
> +
> + if (pci_register_io_range(cpu_addr, length)) {
> + resource_list_destroy_entry(entry);
> + continue;
> + }
> +
> + port = pci_address_to_pio(cpu_addr);
> + if (port == (unsigned long)-1) {
> + resource_list_destroy_entry(entry);
> + continue;
> + }
> +
> + res->start = port;
> + res->end = port + length - 1;
> + entry->offset = port - pci_addr;
> +
> + if (pci_remap_iospace(res, cpu_addr) < 0)
> + resource_list_destroy_entry(entry);
> + }
> + }
> + return ret;
> +}
> +
> +static struct acpi_pci_root_ops acpi_pci_root_ops = {
> + .init_info = pci_mmcfg_setup_map,
> + .release_info = pci_mcfg_release_info,
> + .prepare_resources = pci_acpi_root_prepare_resources,
> +};
> +
> +/* Root bridge scanning */
> +struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> +{
> + int node = acpi_get_node(root->device->handle);
> + int domain = root->segment;
> + int busnum = root->secondary.start;
> + struct acpi_pci_root_info *info;
> + struct pci_host_bridge *bridge;
> + struct pci_bus *bus, *child;
> +
> + if (domain && !pci_domains_supported) {
> + pr_warn("PCI %04x:%02x: multiple domains not supported.\n",
> + domain, busnum);
> + return NULL;
> + }
> +
> + info = kzalloc_node(sizeof(*info), GFP_KERNEL, node);
> + if (!info) {
> + dev_err(&root->device->dev,
> + "pci_bus %04x:%02x: ignored (out of memory)\n",
> + domain, busnum);
> + return NULL;
> + }
> +
> + acpi_pci_root_ops.pci_ops = pci_mcfg_get_ops(root);
> + bus = acpi_pci_root_create(root, &acpi_pci_root_ops, info, root);
> + if (!bus)
> + return NULL;
^^^
Leaking memory here.
> +
> + bridge = pci_find_host_bridge(bus);
> + bridge->map_irq = pcibios_map_irq;
It would be nice to use map_irq for that, but Matthew's series seems
stuck in review mode, either we take that series on and make some
progress on it or you should add the irq mapping code to arm64 arch
code, *temporarily* :)
Also, we should claim resources here.
> +
> + pci_bus_size_bridges(bus);
> + pci_bus_assign_resources(bus);
> +
> + /*
> + * After the PCI-E bus has been walked and all devices discovered,
> + * configure any settings of the fabric that might be necessary.
> + */
> + list_for_each_entry(child, &bus->children, node)
> + pcie_bus_configure_settings(child);
> +
> + return bus;
> +}
> +#endif /* CONFIG_ARCH_PCI_HOST_GENERIC_ACPI */
^^^
does not match the #ifdef
Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
@ 2016-01-19 11:58 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-19 11:58 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jan 13, 2016 at 02:21:05PM +0100, Tomasz Nowicki wrote:
> Because of two patch series:
> 1. Jiang Liu's common interface to support PCI host controller init
> 2. MMCONFIG refactoring (part of this patch set)
> now we can think about generic ACPI based PCI host controller init
> implementation out of arch/ directory.
>
> These calls use information from MCFG table (PCI config space regions)
> and _CRS method (IO/irq resources) to initialize PCI hostbridge.
>
> TBD: We are still not sure whether we should reassign resources
> after PCI bus enumeration or trust firmware to do all that work for
> us properly.
We should claim resources and assign unassigned ones. I put together a
patch for resource claiming instead of reinventing the wheel, waiting
for feedback:
https://patchwork.ozlabs.org/patch/545669/
If we merge the code with no resources claiming, we may end up in
situations where claiming can trigger regressions so we won't be able
to do it anymore.
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> CC: Arnd Bergmann <arnd@arndb.de>
> CC: Catalin Marinas <catalin.marinas@arm.com>
> CC: Liviu Dudau <Liviu.Dudau@arm.com>
> CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
> CC: Will Deacon <will.deacon@arm.com>
> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> Tested-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> drivers/acpi/Kconfig | 5 ++
> drivers/acpi/pci_root.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 136 insertions(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index c3664be..e315061 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -335,6 +335,11 @@ config ACPI_PCI_SLOT
> i.e., segment/bus/device/function tuples, with physical slots in
> the system. If you are unsure, say N.
>
> +config ACPI_PCI_HOST_GENERIC
> + bool "Generic ACPI PCI host controller"
> + help
> + Say Y here if you want to support generic ACPI PCI host controller.
You should add a proper description here.
> +
> config X86_PM_TIMER
> bool "Power Management Timer Support" if EXPERT
> depends on X86
> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
> index a65c8c2..d483e2a 100644
> --- a/drivers/acpi/pci_root.c
> +++ b/drivers/acpi/pci_root.c
> @@ -24,6 +24,7 @@
> #include <linux/init.h>
> #include <linux/types.h>
> #include <linux/mutex.h>
> +#include <linux/of_address.h>
We should move the IO space management to PCI core instead of having
it in OF core, code carrying out PIO mapping does not depend on OF
as far as I can see.
> #include <linux/pm.h>
> #include <linux/pm_runtime.h>
> #include <linux/pci.h>
> @@ -514,6 +515,136 @@ static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm)
> }
> }
>
> +#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
> +static int pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
> +{
> + if (pci_dev_msi_enabled(dev))
> + return 0;
> +
> + acpi_pci_irq_enable(dev);
> + return dev->irq;
> +}
> +
> +static void pci_mcfg_release_info(struct acpi_pci_root_info *ci)
> +{
> + pci_mmcfg_teardown_map(ci);
> + kfree(ci);
> +}
> +
> +static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
> +{
> + struct list_head *list = &ci->resources;
> + struct acpi_device *device = ci->bridge;
> + struct resource_entry *entry, *tmp;
> + unsigned long flags;
> + int ret;
> +
> + flags = IORESOURCE_IO | IORESOURCE_MEM;
> + ret = acpi_dev_get_resources(device, list,
> + acpi_dev_filter_resource_type_cb,
> + (void *)flags);
> + if (ret < 0) {
> + dev_warn(&device->dev,
> + "failed to parse _CRS method, error code %d\n", ret);
> + return ret;
> + } else if (ret == 0)
> + dev_dbg(&device->dev,
> + "no IO and memory resources present in _CRS\n");
^^^^
what's the point in carrying on then ?
> +
> + resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
> + resource_size_t cpu_addr, length;
> + struct resource *res = entry->res;
> +
> + if (entry->res->flags & IORESOURCE_DISABLED)
> + resource_list_destroy_entry(entry);
> + else
> + res->name = ci->name;
> +
> + /* PCI -> CPU space translation */
> + cpu_addr = res->start + entry->offset;
> + length = res->end - res->start + 1;
> +
> + if (res->flags & IORESOURCE_MEM) {
> + res->start = cpu_addr;
> + res->end = cpu_addr + length - 1;
> + } else if (res->flags & IORESOURCE_IO) {
> + resource_size_t pci_addr = res->start;
> + unsigned long port;
> +
> + if (pci_register_io_range(cpu_addr, length)) {
> + resource_list_destroy_entry(entry);
> + continue;
> + }
> +
> + port = pci_address_to_pio(cpu_addr);
> + if (port == (unsigned long)-1) {
> + resource_list_destroy_entry(entry);
> + continue;
> + }
> +
> + res->start = port;
> + res->end = port + length - 1;
> + entry->offset = port - pci_addr;
> +
> + if (pci_remap_iospace(res, cpu_addr) < 0)
> + resource_list_destroy_entry(entry);
> + }
> + }
> + return ret;
> +}
> +
> +static struct acpi_pci_root_ops acpi_pci_root_ops = {
> + .init_info = pci_mmcfg_setup_map,
> + .release_info = pci_mcfg_release_info,
> + .prepare_resources = pci_acpi_root_prepare_resources,
> +};
> +
> +/* Root bridge scanning */
> +struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> +{
> + int node = acpi_get_node(root->device->handle);
> + int domain = root->segment;
> + int busnum = root->secondary.start;
> + struct acpi_pci_root_info *info;
> + struct pci_host_bridge *bridge;
> + struct pci_bus *bus, *child;
> +
> + if (domain && !pci_domains_supported) {
> + pr_warn("PCI %04x:%02x: multiple domains not supported.\n",
> + domain, busnum);
> + return NULL;
> + }
> +
> + info = kzalloc_node(sizeof(*info), GFP_KERNEL, node);
> + if (!info) {
> + dev_err(&root->device->dev,
> + "pci_bus %04x:%02x: ignored (out of memory)\n",
> + domain, busnum);
> + return NULL;
> + }
> +
> + acpi_pci_root_ops.pci_ops = pci_mcfg_get_ops(root);
> + bus = acpi_pci_root_create(root, &acpi_pci_root_ops, info, root);
> + if (!bus)
> + return NULL;
^^^
Leaking memory here.
> +
> + bridge = pci_find_host_bridge(bus);
> + bridge->map_irq = pcibios_map_irq;
It would be nice to use map_irq for that, but Matthew's series seems
stuck in review mode, either we take that series on and make some
progress on it or you should add the irq mapping code to arm64 arch
code, *temporarily* :)
Also, we should claim resources here.
> +
> + pci_bus_size_bridges(bus);
> + pci_bus_assign_resources(bus);
> +
> + /*
> + * After the PCI-E bus has been walked and all devices discovered,
> + * configure any settings of the fabric that might be necessary.
> + */
> + list_for_each_entry(child, &bus->children, node)
> + pcie_bus_configure_settings(child);
> +
> + return bus;
> +}
> +#endif /* CONFIG_ARCH_PCI_HOST_GENERIC_ACPI */
^^^
does not match the #ifdef
Lorenzo
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
2016-01-19 11:58 ` Lorenzo Pieralisi
@ 2016-01-20 15:01 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-20 15:01 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
okaya, jiang.liu, Stefano.Stabellini, robert.richter, mw,
Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
msalter, linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
On 19.01.2016 12:58, Lorenzo Pieralisi wrote:
> On Wed, Jan 13, 2016 at 02:21:05PM +0100, Tomasz Nowicki wrote:
>> Because of two patch series:
>> 1. Jiang Liu's common interface to support PCI host controller init
>> 2. MMCONFIG refactoring (part of this patch set)
>> now we can think about generic ACPI based PCI host controller init
>> implementation out of arch/ directory.
>>
>> These calls use information from MCFG table (PCI config space regions)
>> and _CRS method (IO/irq resources) to initialize PCI hostbridge.
>>
>> TBD: We are still not sure whether we should reassign resources
>> after PCI bus enumeration or trust firmware to do all that work for
>> us properly.
>
> We should claim resources and assign unassigned ones. I put together a
> patch for resource claiming instead of reinventing the wheel, waiting
> for feedback:
>
> https://patchwork.ozlabs.org/patch/545669/
>
> If we merge the code with no resources claiming, we may end up in
> situations where claiming can trigger regressions so we won't be able
> to do it anymore.
>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>> CC: Arnd Bergmann <arnd@arndb.de>
>> CC: Catalin Marinas <catalin.marinas@arm.com>
>> CC: Liviu Dudau <Liviu.Dudau@arm.com>
>> CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
>> CC: Will Deacon <will.deacon@arm.com>
>> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>> Tested-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>> drivers/acpi/Kconfig | 5 ++
>> drivers/acpi/pci_root.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 136 insertions(+)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index c3664be..e315061 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -335,6 +335,11 @@ config ACPI_PCI_SLOT
>> i.e., segment/bus/device/function tuples, with physical slots in
>> the system. If you are unsure, say N.
>>
>> +config ACPI_PCI_HOST_GENERIC
>> + bool "Generic ACPI PCI host controller"
>> + help
>> + Say Y here if you want to support generic ACPI PCI host controller.
>
> You should add a proper description here.
Will do.
>
>> +
>> config X86_PM_TIMER
>> bool "Power Management Timer Support" if EXPERT
>> depends on X86
>> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
>> index a65c8c2..d483e2a 100644
>> --- a/drivers/acpi/pci_root.c
>> +++ b/drivers/acpi/pci_root.c
>> @@ -24,6 +24,7 @@
>> #include <linux/init.h>
>> #include <linux/types.h>
>> #include <linux/mutex.h>
>> +#include <linux/of_address.h>
>
> We should move the IO space management to PCI core instead of having
> it in OF core, code carrying out PIO mapping does not depend on OF
> as far as I can see.
Yes, this should be cleaned up, I will add another patch in the next series.
>
>> #include <linux/pm.h>
>> #include <linux/pm_runtime.h>
>> #include <linux/pci.h>
>> @@ -514,6 +515,136 @@ static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm)
>> }
>> }
>>
>> +#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
>> +static int pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
>> +{
>> + if (pci_dev_msi_enabled(dev))
>> + return 0;
>> +
>> + acpi_pci_irq_enable(dev);
>> + return dev->irq;
>> +}
>> +
>> +static void pci_mcfg_release_info(struct acpi_pci_root_info *ci)
>> +{
>> + pci_mmcfg_teardown_map(ci);
>> + kfree(ci);
>> +}
>> +
>> +static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
>> +{
>> + struct list_head *list = &ci->resources;
>> + struct acpi_device *device = ci->bridge;
>> + struct resource_entry *entry, *tmp;
>> + unsigned long flags;
>> + int ret;
>> +
>> + flags = IORESOURCE_IO | IORESOURCE_MEM;
>> + ret = acpi_dev_get_resources(device, list,
>> + acpi_dev_filter_resource_type_cb,
>> + (void *)flags);
>> + if (ret < 0) {
>> + dev_warn(&device->dev,
>> + "failed to parse _CRS method, error code %d\n", ret);
>> + return ret;
>> + } else if (ret == 0)
>> + dev_dbg(&device->dev,
>> + "no IO and memory resources present in _CRS\n");
> ^^^^
> what's the point in carrying on then ?
There is no point, hence resource_list_for_each_entry_safe will not
iterate &ci->resources and simply return. If you like I can add here
return to make code more readable.
>
>> +
>> + resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
>> + resource_size_t cpu_addr, length;
>> + struct resource *res = entry->res;
>> +
>> + if (entry->res->flags & IORESOURCE_DISABLED)
>> + resource_list_destroy_entry(entry);
>> + else
>> + res->name = ci->name;
>> +
>> + /* PCI -> CPU space translation */
>> + cpu_addr = res->start + entry->offset;
>> + length = res->end - res->start + 1;
>> +
>> + if (res->flags & IORESOURCE_MEM) {
>> + res->start = cpu_addr;
>> + res->end = cpu_addr + length - 1;
>> + } else if (res->flags & IORESOURCE_IO) {
>> + resource_size_t pci_addr = res->start;
>> + unsigned long port;
>> +
>> + if (pci_register_io_range(cpu_addr, length)) {
>> + resource_list_destroy_entry(entry);
>> + continue;
>> + }
>> +
>> + port = pci_address_to_pio(cpu_addr);
>> + if (port == (unsigned long)-1) {
>> + resource_list_destroy_entry(entry);
>> + continue;
>> + }
>> +
>> + res->start = port;
>> + res->end = port + length - 1;
>> + entry->offset = port - pci_addr;
>> +
>> + if (pci_remap_iospace(res, cpu_addr) < 0)
>> + resource_list_destroy_entry(entry);
>> + }
>> + }
>> + return ret;
>> +}
>> +
>> +static struct acpi_pci_root_ops acpi_pci_root_ops = {
>> + .init_info = pci_mmcfg_setup_map,
>> + .release_info = pci_mcfg_release_info,
>> + .prepare_resources = pci_acpi_root_prepare_resources,
>> +};
>> +
>> +/* Root bridge scanning */
>> +struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>> +{
>> + int node = acpi_get_node(root->device->handle);
>> + int domain = root->segment;
>> + int busnum = root->secondary.start;
>> + struct acpi_pci_root_info *info;
>> + struct pci_host_bridge *bridge;
>> + struct pci_bus *bus, *child;
>> +
>> + if (domain && !pci_domains_supported) {
>> + pr_warn("PCI %04x:%02x: multiple domains not supported.\n",
>> + domain, busnum);
>> + return NULL;
>> + }
>> +
>> + info = kzalloc_node(sizeof(*info), GFP_KERNEL, node);
>> + if (!info) {
>> + dev_err(&root->device->dev,
>> + "pci_bus %04x:%02x: ignored (out of memory)\n",
>> + domain, busnum);
>> + return NULL;
>> + }
>> +
>> + acpi_pci_root_ops.pci_ops = pci_mcfg_get_ops(root);
>> + bus = acpi_pci_root_create(root, &acpi_pci_root_ops, info, root);
>> + if (!bus)
>> + return NULL;
> ^^^
> Leaking memory here.
No leak here. See acpi_pci_root_create->__acpi_pci_root_release_info
>
>> +
>> + bridge = pci_find_host_bridge(bus);
>> + bridge->map_irq = pcibios_map_irq;
>
> It would be nice to use map_irq for that, but Matthew's series seems
> stuck in review mode, either we take that series on and make some
> progress on it or you should add the irq mapping code to arm64 arch
> code, *temporarily* :)
Right, I decided to decouple this and Matthew's series.
>
> Also, we should claim resources here.
Let me investigate it more and get back to you.
>
>> +
>> + pci_bus_size_bridges(bus);
>> + pci_bus_assign_resources(bus);
>> +
>> + /*
>> + * After the PCI-E bus has been walked and all devices discovered,
>> + * configure any settings of the fabric that might be necessary.
>> + */
>> + list_for_each_entry(child, &bus->children, node)
>> + pcie_bus_configure_settings(child);
>> +
>> + return bus;
>> +}
>> +#endif /* CONFIG_ARCH_PCI_HOST_GENERIC_ACPI */
> ^^^
> does not match the #ifdef
Fixed.
Thanks,
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 19/21] pci, acpi: Support for ACPI based generic PCI host controller init
@ 2016-01-20 15:01 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-20 15:01 UTC (permalink / raw)
To: linux-arm-kernel
On 19.01.2016 12:58, Lorenzo Pieralisi wrote:
> On Wed, Jan 13, 2016 at 02:21:05PM +0100, Tomasz Nowicki wrote:
>> Because of two patch series:
>> 1. Jiang Liu's common interface to support PCI host controller init
>> 2. MMCONFIG refactoring (part of this patch set)
>> now we can think about generic ACPI based PCI host controller init
>> implementation out of arch/ directory.
>>
>> These calls use information from MCFG table (PCI config space regions)
>> and _CRS method (IO/irq resources) to initialize PCI hostbridge.
>>
>> TBD: We are still not sure whether we should reassign resources
>> after PCI bus enumeration or trust firmware to do all that work for
>> us properly.
>
> We should claim resources and assign unassigned ones. I put together a
> patch for resource claiming instead of reinventing the wheel, waiting
> for feedback:
>
> https://patchwork.ozlabs.org/patch/545669/
>
> If we merge the code with no resources claiming, we may end up in
> situations where claiming can trigger regressions so we won't be able
> to do it anymore.
>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>> CC: Arnd Bergmann <arnd@arndb.de>
>> CC: Catalin Marinas <catalin.marinas@arm.com>
>> CC: Liviu Dudau <Liviu.Dudau@arm.com>
>> CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
>> CC: Will Deacon <will.deacon@arm.com>
>> Tested-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
>> Tested-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>> drivers/acpi/Kconfig | 5 ++
>> drivers/acpi/pci_root.c | 131 ++++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 136 insertions(+)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index c3664be..e315061 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -335,6 +335,11 @@ config ACPI_PCI_SLOT
>> i.e., segment/bus/device/function tuples, with physical slots in
>> the system. If you are unsure, say N.
>>
>> +config ACPI_PCI_HOST_GENERIC
>> + bool "Generic ACPI PCI host controller"
>> + help
>> + Say Y here if you want to support generic ACPI PCI host controller.
>
> You should add a proper description here.
Will do.
>
>> +
>> config X86_PM_TIMER
>> bool "Power Management Timer Support" if EXPERT
>> depends on X86
>> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
>> index a65c8c2..d483e2a 100644
>> --- a/drivers/acpi/pci_root.c
>> +++ b/drivers/acpi/pci_root.c
>> @@ -24,6 +24,7 @@
>> #include <linux/init.h>
>> #include <linux/types.h>
>> #include <linux/mutex.h>
>> +#include <linux/of_address.h>
>
> We should move the IO space management to PCI core instead of having
> it in OF core, code carrying out PIO mapping does not depend on OF
> as far as I can see.
Yes, this should be cleaned up, I will add another patch in the next series.
>
>> #include <linux/pm.h>
>> #include <linux/pm_runtime.h>
>> #include <linux/pci.h>
>> @@ -514,6 +515,136 @@ static void negotiate_os_control(struct acpi_pci_root *root, int *no_aspm)
>> }
>> }
>>
>> +#ifdef CONFIG_ACPI_PCI_HOST_GENERIC
>> +static int pcibios_map_irq(struct pci_dev *dev, u8 slot, u8 pin)
>> +{
>> + if (pci_dev_msi_enabled(dev))
>> + return 0;
>> +
>> + acpi_pci_irq_enable(dev);
>> + return dev->irq;
>> +}
>> +
>> +static void pci_mcfg_release_info(struct acpi_pci_root_info *ci)
>> +{
>> + pci_mmcfg_teardown_map(ci);
>> + kfree(ci);
>> +}
>> +
>> +static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
>> +{
>> + struct list_head *list = &ci->resources;
>> + struct acpi_device *device = ci->bridge;
>> + struct resource_entry *entry, *tmp;
>> + unsigned long flags;
>> + int ret;
>> +
>> + flags = IORESOURCE_IO | IORESOURCE_MEM;
>> + ret = acpi_dev_get_resources(device, list,
>> + acpi_dev_filter_resource_type_cb,
>> + (void *)flags);
>> + if (ret < 0) {
>> + dev_warn(&device->dev,
>> + "failed to parse _CRS method, error code %d\n", ret);
>> + return ret;
>> + } else if (ret == 0)
>> + dev_dbg(&device->dev,
>> + "no IO and memory resources present in _CRS\n");
> ^^^^
> what's the point in carrying on then ?
There is no point, hence resource_list_for_each_entry_safe will not
iterate &ci->resources and simply return. If you like I can add here
return to make code more readable.
>
>> +
>> + resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
>> + resource_size_t cpu_addr, length;
>> + struct resource *res = entry->res;
>> +
>> + if (entry->res->flags & IORESOURCE_DISABLED)
>> + resource_list_destroy_entry(entry);
>> + else
>> + res->name = ci->name;
>> +
>> + /* PCI -> CPU space translation */
>> + cpu_addr = res->start + entry->offset;
>> + length = res->end - res->start + 1;
>> +
>> + if (res->flags & IORESOURCE_MEM) {
>> + res->start = cpu_addr;
>> + res->end = cpu_addr + length - 1;
>> + } else if (res->flags & IORESOURCE_IO) {
>> + resource_size_t pci_addr = res->start;
>> + unsigned long port;
>> +
>> + if (pci_register_io_range(cpu_addr, length)) {
>> + resource_list_destroy_entry(entry);
>> + continue;
>> + }
>> +
>> + port = pci_address_to_pio(cpu_addr);
>> + if (port == (unsigned long)-1) {
>> + resource_list_destroy_entry(entry);
>> + continue;
>> + }
>> +
>> + res->start = port;
>> + res->end = port + length - 1;
>> + entry->offset = port - pci_addr;
>> +
>> + if (pci_remap_iospace(res, cpu_addr) < 0)
>> + resource_list_destroy_entry(entry);
>> + }
>> + }
>> + return ret;
>> +}
>> +
>> +static struct acpi_pci_root_ops acpi_pci_root_ops = {
>> + .init_info = pci_mmcfg_setup_map,
>> + .release_info = pci_mcfg_release_info,
>> + .prepare_resources = pci_acpi_root_prepare_resources,
>> +};
>> +
>> +/* Root bridge scanning */
>> +struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>> +{
>> + int node = acpi_get_node(root->device->handle);
>> + int domain = root->segment;
>> + int busnum = root->secondary.start;
>> + struct acpi_pci_root_info *info;
>> + struct pci_host_bridge *bridge;
>> + struct pci_bus *bus, *child;
>> +
>> + if (domain && !pci_domains_supported) {
>> + pr_warn("PCI %04x:%02x: multiple domains not supported.\n",
>> + domain, busnum);
>> + return NULL;
>> + }
>> +
>> + info = kzalloc_node(sizeof(*info), GFP_KERNEL, node);
>> + if (!info) {
>> + dev_err(&root->device->dev,
>> + "pci_bus %04x:%02x: ignored (out of memory)\n",
>> + domain, busnum);
>> + return NULL;
>> + }
>> +
>> + acpi_pci_root_ops.pci_ops = pci_mcfg_get_ops(root);
>> + bus = acpi_pci_root_create(root, &acpi_pci_root_ops, info, root);
>> + if (!bus)
>> + return NULL;
> ^^^
> Leaking memory here.
No leak here. See acpi_pci_root_create->__acpi_pci_root_release_info
>
>> +
>> + bridge = pci_find_host_bridge(bus);
>> + bridge->map_irq = pcibios_map_irq;
>
> It would be nice to use map_irq for that, but Matthew's series seems
> stuck in review mode, either we take that series on and make some
> progress on it or you should add the irq mapping code to arm64 arch
> code, *temporarily* :)
Right, I decided to decouple this and Matthew's series.
>
> Also, we should claim resources here.
Let me investigate it more and get back to you.
>
>> +
>> + pci_bus_size_bridges(bus);
>> + pci_bus_assign_resources(bus);
>> +
>> + /*
>> + * After the PCI-E bus has been walked and all devices discovered,
>> + * configure any settings of the fabric that might be necessary.
>> + */
>> + list_for_each_entry(child, &bus->children, node)
>> + pcie_bus_configure_settings(child);
>> +
>> + return bus;
>> +}
>> +#endif /* CONFIG_ARCH_PCI_HOST_GENERIC_ACPI */
> ^^^
> does not match the #ifdef
Fixed.
Thanks,
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 13:21 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
Some platforms may not be fully compliant with generic set of PCI config
accessors. For these cases we implement the way to overwrite accessors
set prior to PCI buses enumeration. Algorithm traverses available quirk
list, matches against <platform ID (DMI), domain, bus number> tuple and
returns corresponding accessors. All quirks can be defined using:
DECLARE_ACPI_MCFG_FIXUP() and keep self contained. Example,
static const struct dmi_system_id foo_dmi[] = {
{
.ident = "<Platform ident string>",
.callback = <handler>,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "<system vendor>"),
DMI_MATCH(DMI_PRODUCT_NAME, "<product name>"),
DMI_MATCH(DMI_PRODUCT_VERSION, "product version"),
},
},
{ }
};
static struct pci_ops foo_ecam_pci_ops = {
.map_bus = pci_mcfg_dev_base,
.read = foo_ecam_config_read,
.write = foo_ecam_config_write,
};
DECLARE_ACPI_MCFG_FIXUP(foo_dmi, NULL, &foo_ecam_pci_ops, <domain_nr>, <bus_nr>);
More custom (non-DMI) matching can be done via an alternative call.
Note that there is possibility to assign quirk related private data to
root->sysdata which will be available along read/wriate accessor, example:
static int boo_match(struct pci_mcfg_fixup *fixup, struct acpi_pci_root *root)
{
return [condition] ? 1 : 0;
}
int boo_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *val)
{
struct acpi_pci_root *root = bus->sysdata;
struct boo_priv_data *boo_data = root->sysdata;
[..]
}
static struct pci_ops boo_ecam_pci_ops = {
.map_bus = pci_mcfg_dev_base,
.read = boo_ecam_config_read,
.write = boo_ecam_config_write,
};
DECLARE_ACPI_MCFG_FIXUP(NULL, boo_match, &boo_ecam_pci_ops, <domain_nr>, <bus_nr>);
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
drivers/acpi/mcfg.c | 33 +++++++++++++++++++++++++++++++--
include/acpi/acpi_bus.h | 1 +
include/asm-generic/vmlinux.lds.h | 7 +++++++
include/linux/ecam.h | 18 ++++++++++++++++++
4 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index dfc2d14..ec5fe7b 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -8,6 +8,7 @@
*/
#include <linux/acpi.h>
+#include <linux/dmi.h>
#include <linux/ecam.h>
#include <linux/pci.h>
#include <linux/pci-acpi.h>
@@ -34,6 +35,29 @@ int __weak raw_pci_write(unsigned int domain, unsigned int bus,
return PCIBIOS_DEVICE_NOT_FOUND;
}
+extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
+
+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root *root)
+{
+ struct pci_mcfg_fixup *f;
+ int bus_num = root->secondary.start;
+ int domain = root->segment;
+
+ /*
+ * First match against PCI topology <domain:bus> then use DMI or
+ * custom match handler.
+ */
+ for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
+ if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
+ (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
+ (f->system ? dmi_check_system(f->system) : 0 ||
+ f->match ? f->match(f, root) : 0))
+ return f->ops;
+ }
+ return NULL;
+}
+
void __iomem *
pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
{
@@ -56,10 +80,15 @@ static struct pci_ops default_pci_mcfg_ops = {
struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
{
+ struct pci_ops *pci_mcfg_ops_quirk;
+
/*
- * TODO: Match against platform specific quirks and return
- * corresponding PCI config space accessor set.
+ * Match against platform specific quirks and return corresponding
+ * PCI config space accessor set.
*/
+ pci_mcfg_ops_quirk = pci_mcfg_check_quirks(root);
+ if (pci_mcfg_ops_quirk)
+ return pci_mcfg_ops_quirk;
return &default_pci_mcfg_ops;
}
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index ad0a5ff..ea4d2b5 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -554,6 +554,7 @@ struct acpi_pci_root {
struct pci_bus *bus;
u16 segment;
struct resource secondary; /* downstream bus range */
+ void *sysdata;
u32 osc_support_set; /* _OSC state of support bits */
u32 osc_control_set; /* _OSC state of control bits */
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index c4bd0e2..c93fc97 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -298,6 +298,13 @@
VMLINUX_SYMBOL(__end_pci_fixups_suspend_late) = .; \
} \
\
+ /* ACPI MCFG quirks */ \
+ .acpi_fixup : AT(ADDR(.acpi_fixup) - LOAD_OFFSET) { \
+ VMLINUX_SYMBOL(__start_acpi_mcfg_fixups) = .; \
+ *(.acpi_fixup_mcfg) \
+ VMLINUX_SYMBOL(__end_acpi_mcfg_fixups) = .; \
+ } \
+ \
/* Built-in firmware blobs */ \
.builtin_fw : AT(ADDR(.builtin_fw) - LOAD_OFFSET) { \
VMLINUX_SYMBOL(__start_builtin_fw) = .; \
diff --git a/include/linux/ecam.h b/include/linux/ecam.h
index e0f322e..21215be 100644
--- a/include/linux/ecam.h
+++ b/include/linux/ecam.h
@@ -20,6 +20,24 @@ struct pci_mmcfg_region {
bool hot_added;
};
+struct pci_mcfg_fixup {
+ const struct dmi_system_id *system;
+ int (*match)(struct pci_mcfg_fixup *, struct acpi_pci_root *);
+ struct pci_ops *ops;
+ int domain;
+ int bus_num;
+};
+
+#define PCI_MCFG_DOMAIN_ANY -1
+#define PCI_MCFG_BUS_ANY -1
+
+/* Designate a routine to fix up buggy MCFG */
+#define DECLARE_ACPI_MCFG_FIXUP(system, match, ops, dom, bus) \
+ static const struct pci_mcfg_fixup __mcfg_fixup_##system##dom##bus\
+ __used __attribute__((__section__(".acpi_fixup_mcfg"), \
+ aligned((sizeof(void *))))) = \
+ { system, match, ops, dom, bus };
+
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);
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
@ 2016-01-13 13:21 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Some platforms may not be fully compliant with generic set of PCI config
accessors. For these cases we implement the way to overwrite accessors
set prior to PCI buses enumeration. Algorithm traverses available quirk
list, matches against <platform ID (DMI), domain, bus number> tuple and
returns corresponding accessors. All quirks can be defined using:
DECLARE_ACPI_MCFG_FIXUP() and keep self contained. Example,
static const struct dmi_system_id foo_dmi[] = {
{
.ident = "<Platform ident string>",
.callback = <handler>,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "<system vendor>"),
DMI_MATCH(DMI_PRODUCT_NAME, "<product name>"),
DMI_MATCH(DMI_PRODUCT_VERSION, "product version"),
},
},
{ }
};
static struct pci_ops foo_ecam_pci_ops = {
.map_bus = pci_mcfg_dev_base,
.read = foo_ecam_config_read,
.write = foo_ecam_config_write,
};
DECLARE_ACPI_MCFG_FIXUP(foo_dmi, NULL, &foo_ecam_pci_ops, <domain_nr>, <bus_nr>);
More custom (non-DMI) matching can be done via an alternative call.
Note that there is possibility to assign quirk related private data to
root->sysdata which will be available along read/wriate accessor, example:
static int boo_match(struct pci_mcfg_fixup *fixup, struct acpi_pci_root *root)
{
return [condition] ? 1 : 0;
}
int boo_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *val)
{
struct acpi_pci_root *root = bus->sysdata;
struct boo_priv_data *boo_data = root->sysdata;
[..]
}
static struct pci_ops boo_ecam_pci_ops = {
.map_bus = pci_mcfg_dev_base,
.read = boo_ecam_config_read,
.write = boo_ecam_config_write,
};
DECLARE_ACPI_MCFG_FIXUP(NULL, boo_match, &boo_ecam_pci_ops, <domain_nr>, <bus_nr>);
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
---
drivers/acpi/mcfg.c | 33 +++++++++++++++++++++++++++++++--
include/acpi/acpi_bus.h | 1 +
include/asm-generic/vmlinux.lds.h | 7 +++++++
include/linux/ecam.h | 18 ++++++++++++++++++
4 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index dfc2d14..ec5fe7b 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -8,6 +8,7 @@
*/
#include <linux/acpi.h>
+#include <linux/dmi.h>
#include <linux/ecam.h>
#include <linux/pci.h>
#include <linux/pci-acpi.h>
@@ -34,6 +35,29 @@ int __weak raw_pci_write(unsigned int domain, unsigned int bus,
return PCIBIOS_DEVICE_NOT_FOUND;
}
+extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
+
+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root *root)
+{
+ struct pci_mcfg_fixup *f;
+ int bus_num = root->secondary.start;
+ int domain = root->segment;
+
+ /*
+ * First match against PCI topology <domain:bus> then use DMI or
+ * custom match handler.
+ */
+ for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
+ if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
+ (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
+ (f->system ? dmi_check_system(f->system) : 0 ||
+ f->match ? f->match(f, root) : 0))
+ return f->ops;
+ }
+ return NULL;
+}
+
void __iomem *
pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
{
@@ -56,10 +80,15 @@ static struct pci_ops default_pci_mcfg_ops = {
struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
{
+ struct pci_ops *pci_mcfg_ops_quirk;
+
/*
- * TODO: Match against platform specific quirks and return
- * corresponding PCI config space accessor set.
+ * Match against platform specific quirks and return corresponding
+ * PCI config space accessor set.
*/
+ pci_mcfg_ops_quirk = pci_mcfg_check_quirks(root);
+ if (pci_mcfg_ops_quirk)
+ return pci_mcfg_ops_quirk;
return &default_pci_mcfg_ops;
}
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index ad0a5ff..ea4d2b5 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -554,6 +554,7 @@ struct acpi_pci_root {
struct pci_bus *bus;
u16 segment;
struct resource secondary; /* downstream bus range */
+ void *sysdata;
u32 osc_support_set; /* _OSC state of support bits */
u32 osc_control_set; /* _OSC state of control bits */
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index c4bd0e2..c93fc97 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -298,6 +298,13 @@
VMLINUX_SYMBOL(__end_pci_fixups_suspend_late) = .; \
} \
\
+ /* ACPI MCFG quirks */ \
+ .acpi_fixup : AT(ADDR(.acpi_fixup) - LOAD_OFFSET) { \
+ VMLINUX_SYMBOL(__start_acpi_mcfg_fixups) = .; \
+ *(.acpi_fixup_mcfg) \
+ VMLINUX_SYMBOL(__end_acpi_mcfg_fixups) = .; \
+ } \
+ \
/* Built-in firmware blobs */ \
.builtin_fw : AT(ADDR(.builtin_fw) - LOAD_OFFSET) { \
VMLINUX_SYMBOL(__start_builtin_fw) = .; \
diff --git a/include/linux/ecam.h b/include/linux/ecam.h
index e0f322e..21215be 100644
--- a/include/linux/ecam.h
+++ b/include/linux/ecam.h
@@ -20,6 +20,24 @@ struct pci_mmcfg_region {
bool hot_added;
};
+struct pci_mcfg_fixup {
+ const struct dmi_system_id *system;
+ int (*match)(struct pci_mcfg_fixup *, struct acpi_pci_root *);
+ struct pci_ops *ops;
+ int domain;
+ int bus_num;
+};
+
+#define PCI_MCFG_DOMAIN_ANY -1
+#define PCI_MCFG_BUS_ANY -1
+
+/* Designate a routine to fix up buggy MCFG */
+#define DECLARE_ACPI_MCFG_FIXUP(system, match, ops, dom, bus) \
+ static const struct pci_mcfg_fixup __mcfg_fixup_##system##dom##bus\
+ __used __attribute__((__section__(".acpi_fixup_mcfg"), \
+ aligned((sizeof(void *))))) = \
+ { system, match, ops, dom, bus };
+
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);
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* Re: [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
2016-01-13 13:21 ` Tomasz Nowicki
@ 2016-01-14 15:36 ` Mark Salter
-1 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 15:36 UTC (permalink / raw)
To: Tomasz Nowicki, bhelgaas, arnd, will.deacon, catalin.marinas,
rjw, hanjun.guo, Lorenzo.Pieralisi, okaya, jiang.liu,
Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm
On Wed, 2016-01-13 at 14:21 +0100, Tomasz Nowicki wrote:
> Some platforms may not be fully compliant with generic set of PCI config
> accessors. For these cases we implement the way to overwrite accessors
> set prior to PCI buses enumeration. Algorithm traverses available quirk
> list, matches against <platform ID (DMI), domain, bus number> tuple and
> returns corresponding accessors. All quirks can be defined using:
> DECLARE_ACPI_MCFG_FIXUP() and keep self contained. Example,
>
> static const struct dmi_system_id foo_dmi[] = {
> {
> .ident = "<Platform ident string>",
> .callback = <handler>,
> .matches = {
> DMI_MATCH(DMI_SYS_VENDOR, "<system vendor>"),
> DMI_MATCH(DMI_PRODUCT_NAME, "<product name>"),
> DMI_MATCH(DMI_PRODUCT_VERSION, "product version"),
> },
> },
> { }
> };
>
> static struct pci_ops foo_ecam_pci_ops = {
> .map_bus = pci_mcfg_dev_base,
> .read = foo_ecam_config_read,
> .write = foo_ecam_config_write,
> };
> DECLARE_ACPI_MCFG_FIXUP(foo_dmi, NULL, &foo_ecam_pci_ops, <domain_nr>, <bus_nr>);
>
> More custom (non-DMI) matching can be done via an alternative call.
> Note that there is possibility to assign quirk related private data to
> root->sysdata which will be available along read/wriate accessor, example:
>
> static int boo_match(struct pci_mcfg_fixup *fixup, struct acpi_pci_root *root)
> {
> return [condition] ? 1 : 0;
> }
>
> int boo_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
> int where, int size, u32 *val)
> {
> struct acpi_pci_root *root = bus->sysdata;
> struct boo_priv_data *boo_data = root->sysdata;
>
> [..]
> }
>
> static struct pci_ops boo_ecam_pci_ops = {
> .map_bus = pci_mcfg_dev_base,
> .read = boo_ecam_config_read,
> .write = boo_ecam_config_write,
> };
> DECLARE_ACPI_MCFG_FIXUP(NULL, boo_match, &boo_ecam_pci_ops, <domain_nr>, <bus_nr>);
>
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> ---
> drivers/acpi/mcfg.c | 33 +++++++++++++++++++++++++++++++--
> include/acpi/acpi_bus.h | 1 +
> include/asm-generic/vmlinux.lds.h | 7 +++++++
> include/linux/ecam.h | 18 ++++++++++++++++++
> 4 files changed, 57 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
> index dfc2d14..ec5fe7b 100644
> --- a/drivers/acpi/mcfg.c
> +++ b/drivers/acpi/mcfg.c
> @@ -8,6 +8,7 @@
> */
>
> #include <linux/acpi.h>
> +#include <linux/dmi.h>
> #include <linux/ecam.h>
> #include <linux/pci.h>
> #include <linux/pci-acpi.h>
> @@ -34,6 +35,29 @@ int __weak raw_pci_write(unsigned int domain, unsigned int bus,
> return PCIBIOS_DEVICE_NOT_FOUND;
> }
>
> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
> +extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
> +
> +static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root *root)
> +{
> + struct pci_mcfg_fixup *f;
> + int bus_num = root->secondary.start;
> + int domain = root->segment;
> +
> + /*
> + * First match against PCI topology <domain:bus> then use DMI or
> + * custom match handler.
> + */
> + for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
> + if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
> + (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
> + (f->system ? dmi_check_system(f->system) : 0 ||
> + f->match ? f->match(f, root) : 0))
> + return f->ops;
I think this would be better as:
(f->system ? dmi_check_system(f->system) : 1 &&
f->match ? f->match(f, root) : 1))
return f->ops;
Otherwise, one has to call dmi_check_system() from f->match() if
access to root is needed.
> + }
> + return NULL;
> +}
> +
> void __iomem *
> pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
> {
> @@ -56,10 +80,15 @@ static struct pci_ops default_pci_mcfg_ops = {
>
> struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
> {
> + struct pci_ops *pci_mcfg_ops_quirk;
> +
> /*
> - * TODO: Match against platform specific quirks and return
> - * corresponding PCI config space accessor set.
> + * Match against platform specific quirks and return corresponding
> + * PCI config space accessor set.
> */
> + pci_mcfg_ops_quirk = pci_mcfg_check_quirks(root);
> + if (pci_mcfg_ops_quirk)
> + return pci_mcfg_ops_quirk;
>
> return &default_pci_mcfg_ops;
> }
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index ad0a5ff..ea4d2b5 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -554,6 +554,7 @@ struct acpi_pci_root {
> struct pci_bus *bus;
> u16 segment;
> struct resource secondary; /* downstream bus range */
> + void *sysdata;
>
> u32 osc_support_set; /* _OSC state of support bits */
> u32 osc_control_set; /* _OSC state of control bits */
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index c4bd0e2..c93fc97 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -298,6 +298,13 @@
> VMLINUX_SYMBOL(__end_pci_fixups_suspend_late) = .; \
> } \
> \
> + /* ACPI MCFG quirks */ \
> + .acpi_fixup : AT(ADDR(.acpi_fixup) - LOAD_OFFSET) { \
> + VMLINUX_SYMBOL(__start_acpi_mcfg_fixups) = .; \
> + *(.acpi_fixup_mcfg) \
> + VMLINUX_SYMBOL(__end_acpi_mcfg_fixups) = .; \
> + } \
> + \
> /* Built-in firmware blobs */ \
> .builtin_fw : AT(ADDR(.builtin_fw) - LOAD_OFFSET) { \
> VMLINUX_SYMBOL(__start_builtin_fw) = .; \
> diff --git a/include/linux/ecam.h b/include/linux/ecam.h
> index e0f322e..21215be 100644
> --- a/include/linux/ecam.h
> +++ b/include/linux/ecam.h
> @@ -20,6 +20,24 @@ struct pci_mmcfg_region {
> bool hot_added;
> };
>
> +struct pci_mcfg_fixup {
> + const struct dmi_system_id *system;
> + int (*match)(struct pci_mcfg_fixup *, struct acpi_pci_root *);
> + struct pci_ops *ops;
> + int domain;
> + int bus_num;
> +};
> +
> +#define PCI_MCFG_DOMAIN_ANY -1
> +#define PCI_MCFG_BUS_ANY -1
> +
> +/* Designate a routine to fix up buggy MCFG */
> +#define DECLARE_ACPI_MCFG_FIXUP(system, match, ops, dom, bus) \
> + static const struct pci_mcfg_fixup __mcfg_fixup_##system##dom##bus\
> + __used __attribute__((__section__(".acpi_fixup_mcfg"), \
> + aligned((sizeof(void *))))) = \
> + { system, match, ops, dom, bus };
> +
> 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);
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
@ 2016-01-14 15:36 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 15:36 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 2016-01-13 at 14:21 +0100, Tomasz Nowicki wrote:
> Some platforms may not be fully compliant with generic set of PCI config
> accessors. For these cases we implement the way to overwrite accessors
> set prior to PCI buses enumeration. Algorithm traverses available quirk
> list, matches against <platform ID (DMI), domain, bus number> tuple and
> returns corresponding accessors. All quirks can be defined using:
> DECLARE_ACPI_MCFG_FIXUP() and keep self contained. Example,
>
> static const struct dmi_system_id foo_dmi[] = {
> ????????{
> ????????????????.ident = "<Platform ident string>",
> ????????????????.callback = <handler>,
> ????????????????.matches = {
> ????????????????????????DMI_MATCH(DMI_SYS_VENDOR, "<system vendor>"),
> ????????????????????????DMI_MATCH(DMI_PRODUCT_NAME, "<product name>"),
> ????????????????????????DMI_MATCH(DMI_PRODUCT_VERSION, "product version"),
> ????????????????},
> ????????},
> ????????{ }
> };
>
> static struct pci_ops foo_ecam_pci_ops = {
> ????????.map_bus = pci_mcfg_dev_base,
> ????????.read = foo_ecam_config_read,
> ????????.write = foo_ecam_config_write,
> };
> DECLARE_ACPI_MCFG_FIXUP(foo_dmi, NULL, &foo_ecam_pci_ops, <domain_nr>, <bus_nr>);
>
> More custom (non-DMI) matching can be done via an alternative call.
> Note that there is possibility to assign quirk related private data to
> root->sysdata which will be available along read/wriate accessor, example:
>
> static int boo_match(struct pci_mcfg_fixup *fixup, struct acpi_pci_root *root)
> {
> ????????return [condition] ? 1 : 0;
> }
>
> int boo_ecam_config_read(struct pci_bus *bus, unsigned int devfn,
> ??????????????????????????int where, int size, u32 *val)
> {
> ????????struct acpi_pci_root *root = bus->sysdata;
> ????????struct boo_priv_data *boo_data = root->sysdata;
>
> ????????[..]
> }
>
> static struct pci_ops boo_ecam_pci_ops = {
> .map_bus = pci_mcfg_dev_base,
> .read = boo_ecam_config_read,
> .write = boo_ecam_config_write,
> };
> DECLARE_ACPI_MCFG_FIXUP(NULL, boo_match, &boo_ecam_pci_ops, <domain_nr>, <bus_nr>);
>
> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
> ---
> ?drivers/acpi/mcfg.c???????????????| 33 +++++++++++++++++++++++++++++++--
> ?include/acpi/acpi_bus.h???????????|??1 +
> ?include/asm-generic/vmlinux.lds.h |??7 +++++++
> ?include/linux/ecam.h??????????????| 18 ++++++++++++++++++
> ?4 files changed, 57 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
> index dfc2d14..ec5fe7b 100644
> --- a/drivers/acpi/mcfg.c
> +++ b/drivers/acpi/mcfg.c
> @@ -8,6 +8,7 @@
> ? */
> ?
> ?#include <linux/acpi.h>
> +#include <linux/dmi.h>
> ?#include <linux/ecam.h>
> ?#include <linux/pci.h>
> ?#include <linux/pci-acpi.h>
> @@ -34,6 +35,29 @@ int __weak raw_pci_write(unsigned int domain, unsigned int bus,
> ? return PCIBIOS_DEVICE_NOT_FOUND;
> ?}
> ?
> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
> +extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
> +
> +static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root *root)
> +{
> + struct pci_mcfg_fixup *f;
> + int bus_num = root->secondary.start;
> + int domain = root->segment;
> +
> + /*
> + ?* First match against PCI topology <domain:bus> then use DMI or
> + ?* custom match handler.
> + ?*/
> + for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
> + if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
> + ????(f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
> + ????(f->system ? dmi_check_system(f->system) : 0 ||
> + ?????f->match ? f->match(f, root) : 0))
> + return f->ops;
I think this would be better as:
????(f->system ? dmi_check_system(f->system) : 1 &&
?????f->match ? f->match(f, root) : 1))
return f->ops;
Otherwise, one has to call dmi_check_system() from f->match() if
access to root is needed.
??
> + }
> + return NULL;
> +}
> +
> ?void __iomem *
> ?pci_mcfg_dev_base(struct pci_bus *bus, unsigned int devfn, int offset)
> ?{
> @@ -56,10 +80,15 @@ static struct pci_ops default_pci_mcfg_ops = {
> ?
> ?struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
> ?{
> + struct pci_ops *pci_mcfg_ops_quirk;
> +
> ? /*
> - ?* TODO: Match against platform specific quirks and return
> - ?* corresponding PCI config space accessor set.
> + ?* Match against platform specific quirks and return corresponding
> + ?* PCI config space accessor set.
> ? ?*/
> + pci_mcfg_ops_quirk = pci_mcfg_check_quirks(root);
> + if (pci_mcfg_ops_quirk)
> + return pci_mcfg_ops_quirk;
> ?
> ? return &default_pci_mcfg_ops;
> ?}
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index ad0a5ff..ea4d2b5 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -554,6 +554,7 @@ struct acpi_pci_root {
> ? struct pci_bus *bus;
> ? u16 segment;
> ? struct resource secondary; /* downstream bus range */
> + void *sysdata;
> ?
> ? u32 osc_support_set; /* _OSC state of support bits */
> ? u32 osc_control_set; /* _OSC state of control bits */
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index c4bd0e2..c93fc97 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -298,6 +298,13 @@
> ? VMLINUX_SYMBOL(__end_pci_fixups_suspend_late) = .; \
> ? } \
> ? \
> + /* ACPI MCFG quirks */ \
> + .acpi_fixup????????: AT(ADDR(.acpi_fixup) - LOAD_OFFSET) { \
> + VMLINUX_SYMBOL(__start_acpi_mcfg_fixups) = .; \
> + *(.acpi_fixup_mcfg) \
> + VMLINUX_SYMBOL(__end_acpi_mcfg_fixups) = .; \
> + } \
> + \
> ? /* Built-in firmware blobs */ \
> ? .builtin_fw????????: AT(ADDR(.builtin_fw) - LOAD_OFFSET) { \
> ? VMLINUX_SYMBOL(__start_builtin_fw) = .; \
> diff --git a/include/linux/ecam.h b/include/linux/ecam.h
> index e0f322e..21215be 100644
> --- a/include/linux/ecam.h
> +++ b/include/linux/ecam.h
> @@ -20,6 +20,24 @@ struct pci_mmcfg_region {
> ? bool hot_added;
> ?};
> ?
> +struct pci_mcfg_fixup {
> + const struct dmi_system_id *system;
> + int (*match)(struct pci_mcfg_fixup *, struct acpi_pci_root *);
> + struct pci_ops *ops;
> + int domain;
> + int bus_num;
> +};
> +
> +#define PCI_MCFG_DOMAIN_ANY -1
> +#define PCI_MCFG_BUS_ANY -1
> +
> +/* Designate a routine to fix up buggy MCFG */
> +#define DECLARE_ACPI_MCFG_FIXUP(system, match, ops, dom, bus) \
> + static const struct pci_mcfg_fixup __mcfg_fixup_##system##dom##bus\
> + ?__used __attribute__((__section__(".acpi_fixup_mcfg"), \
> + aligned((sizeof(void *))))) = \
> + { system, match, ops, dom, bus };
> +
> ?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);
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
2016-01-14 15:36 ` Mark Salter
@ 2016-01-18 12:41 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-18 12:41 UTC (permalink / raw)
To: Mark Salter, bhelgaas, arnd, will.deacon, catalin.marinas, rjw,
hanjun.guo, Lorenzo.Pieralisi, okaya, jiang.liu,
Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm
On 14.01.2016 16:36, Mark Salter wrote:
>> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
>> >+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
>> >+
>> >+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root *root)
>> >+{
>> >+ struct pci_mcfg_fixup *f;
>> >+ int bus_num = root->secondary.start;
>> >+ int domain = root->segment;
>> >+
>> >+ /*
>> >+ * First match against PCI topology <domain:bus> then use DMI or
>> >+ * custom match handler.
>> >+ */
>> >+ for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
>> >+ if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>> >+ (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>> >+ (f->system ? dmi_check_system(f->system) : 0 ||
>> >+ f->match ? f->match(f, root) : 0))
>> >+ return f->ops;
> I think this would be better as:
>
> (f->system ? dmi_check_system(f->system) : 1 &&
> f->match ? f->match(f, root) : 1))
> return f->ops;
>
> Otherwise, one has to call dmi_check_system() from f->match() if
> access to root is needed.
Makes a lot of sense to me, I will modify as you suggested.
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
@ 2016-01-18 12:41 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-18 12:41 UTC (permalink / raw)
To: linux-arm-kernel
On 14.01.2016 16:36, Mark Salter wrote:
>> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
>> >+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
>> >+
>> >+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root *root)
>> >+{
>> >+ struct pci_mcfg_fixup *f;
>> >+ int bus_num = root->secondary.start;
>> >+ int domain = root->segment;
>> >+
>> >+ /*
>> >+ * First match against PCI topology <domain:bus> then use DMI or
>> >+ * custom match handler.
>> >+ */
>> >+ for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
>> >+ if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>> >+ (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>> >+ (f->system ? dmi_check_system(f->system) : 0 ||
>> >+ f->match ? f->match(f, root) : 0))
>> >+ return f->ops;
> I think this would be better as:
>
> (f->system ? dmi_check_system(f->system) : 1 &&
> f->match ? f->match(f, root) : 1))
> return f->ops;
>
> Otherwise, one has to call dmi_check_system() from f->match() if
> access to root is needed.
Makes a lot of sense to me, I will modify as you suggested.
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
2016-01-18 12:41 ` Tomasz Nowicki
(?)
@ 2016-01-19 1:49 ` liudongdong (C)
-1 siblings, 0 replies; 184+ messages in thread
From: liudongdong (C) @ 2016-01-19 1:49 UTC (permalink / raw)
To: Tomasz Nowicki, Mark Salter, bhelgaas, arnd, will.deacon,
catalin.marinas, rjw, hanjun.guo, Lorenzo.Pieralisi, okaya,
jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm, Zhou Wang,
Gabriele Paoloni
Hi Tomasz, Mark
在 2016/1/18 20:41, Tomasz Nowicki 写道:
> On 14.01.2016 16:36, Mark Salter wrote:
>>> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
>>> >+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
>>> >+
>>> >+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root *root)
>>> >+{
>>> >+ struct pci_mcfg_fixup *f;
>>> >+ int bus_num = root->secondary.start;
>>> >+ int domain = root->segment;
>>> >+
>>> >+ /*
>>> >+ * First match against PCI topology <domain:bus> then use DMI or
>>> >+ * custom match handler.
>>> >+ */
>>> >+ for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
>>> >+ if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>>> >+ (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>>> >+ (f->system ? dmi_check_system(f->system) : 0 ||
>>> >+ f->match ? f->match(f, root) : 0))
>>> >+ return f->ops;
>> I think this would be better as:
>>
>> (f->system ? dmi_check_system(f->system) : 1 &&
>> f->match ? f->match(f, root) : 1))
>> return f->ops;
>>
>> Otherwise, one has to call dmi_check_system() from f->match() if
>> access to root is needed.
>
Non-DMI, we need not to call dmi_check_system() from f->match(),
we can use _HID to decide to hook the pci_ops or not.
Device (PCI1)
{
Name (_HID, "HISI0080") // PCI Express Root Bridge
Name (_CID, "PNP0A03") // Compatible PCI Root Bridge
...
}
static const struct acpi_device_id hisi_pcie_ids[] = {
{"HISI0080", 0},
{"", 0},
};
static int hisi_pcie_match(struct pci_mcfg_fixup *fixup, struct acpi_pci_root *root)
{
int ret;
struct acpi_device *device;
device = root->device;
ret = acpi_match_device_ids(device, hisi_pcie_ids);
if (ret)
return 0;
......
return 1;
}
static struct pci_ops hisi_ecam_pci_ops = {
.map_bus = pci_mcfg_dev_base,
.read = hisi_pci_read,
.write = hisi_pci_write,
};
DECLARE_ACPI_MCFG_FIXUP(NULL, hisi_pcie_match, &hisi_ecam_pci_ops,
PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
Thanks
Dongdong
> Makes a lot of sense to me, I will modify as you suggested.
>
> 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
>
> .
>
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
@ 2016-01-19 1:49 ` liudongdong (C)
0 siblings, 0 replies; 184+ messages in thread
From: liudongdong (C) @ 2016-01-19 1:49 UTC (permalink / raw)
To: linux-arm-kernel
Hi Tomasz, Mark
? 2016/1/18 20:41, Tomasz Nowicki ??:
> On 14.01.2016 16:36, Mark Salter wrote:
>>> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
>>> >+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
>>> >+
>>> >+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root *root)
>>> >+{
>>> >+ struct pci_mcfg_fixup *f;
>>> >+ int bus_num = root->secondary.start;
>>> >+ int domain = root->segment;
>>> >+
>>> >+ /*
>>> >+ * First match against PCI topology <domain:bus> then use DMI or
>>> >+ * custom match handler.
>>> >+ */
>>> >+ for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
>>> >+ if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>>> >+ (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>>> >+ (f->system ? dmi_check_system(f->system) : 0 ||
>>> >+ f->match ? f->match(f, root) : 0))
>>> >+ return f->ops;
>> I think this would be better as:
>>
>> (f->system ? dmi_check_system(f->system) : 1 &&
>> f->match ? f->match(f, root) : 1))
>> return f->ops;
>>
>> Otherwise, one has to call dmi_check_system() from f->match() if
>> access to root is needed.
>
Non-DMI, we need not to call dmi_check_system() from f->match(),
we can use _HID to decide to hook the pci_ops or not.
Device (PCI1)
{
Name (_HID, "HISI0080") // PCI Express Root Bridge
Name (_CID, "PNP0A03") // Compatible PCI Root Bridge
...
}
static const struct acpi_device_id hisi_pcie_ids[] = {
{"HISI0080", 0},
{"", 0},
};
static int hisi_pcie_match(struct pci_mcfg_fixup *fixup, struct acpi_pci_root *root)
{
int ret;
struct acpi_device *device;
device = root->device;
ret = acpi_match_device_ids(device, hisi_pcie_ids);
if (ret)
return 0;
......
return 1;
}
static struct pci_ops hisi_ecam_pci_ops = {
.map_bus = pci_mcfg_dev_base,
.read = hisi_pci_read,
.write = hisi_pci_write,
};
DECLARE_ACPI_MCFG_FIXUP(NULL, hisi_pcie_match, &hisi_ecam_pci_ops,
PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
Thanks
Dongdong
> Makes a lot of sense to me, I will modify as you suggested.
>
> Tomasz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
@ 2016-01-19 1:49 ` liudongdong (C)
0 siblings, 0 replies; 184+ messages in thread
From: liudongdong (C) @ 2016-01-19 1:49 UTC (permalink / raw)
To: Tomasz Nowicki, Mark Salter, bhelgaas, arnd, will.deacon,
catalin.marinas, rjw, hanjun.guo, Lorenzo.Pieralisi, okaya,
jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm, Zhou Wang,
Gabriele Paoloni
Hi Tomasz, Mark
在 2016/1/18 20:41, Tomasz Nowicki 写道:
> On 14.01.2016 16:36, Mark Salter wrote:
>>> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
>>> >+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
>>> >+
>>> >+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root *root)
>>> >+{
>>> >+ struct pci_mcfg_fixup *f;
>>> >+ int bus_num = root->secondary.start;
>>> >+ int domain = root->segment;
>>> >+
>>> >+ /*
>>> >+ * First match against PCI topology <domain:bus> then use DMI or
>>> >+ * custom match handler.
>>> >+ */
>>> >+ for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
>>> >+ if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>>> >+ (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>>> >+ (f->system ? dmi_check_system(f->system) : 0 ||
>>> >+ f->match ? f->match(f, root) : 0))
>>> >+ return f->ops;
>> I think this would be better as:
>>
>> (f->system ? dmi_check_system(f->system) : 1 &&
>> f->match ? f->match(f, root) : 1))
>> return f->ops;
>>
>> Otherwise, one has to call dmi_check_system() from f->match() if
>> access to root is needed.
>
Non-DMI, we need not to call dmi_check_system() from f->match(),
we can use _HID to decide to hook the pci_ops or not.
Device (PCI1)
{
Name (_HID, "HISI0080") // PCI Express Root Bridge
Name (_CID, "PNP0A03") // Compatible PCI Root Bridge
...
}
static const struct acpi_device_id hisi_pcie_ids[] = {
{"HISI0080", 0},
{"", 0},
};
static int hisi_pcie_match(struct pci_mcfg_fixup *fixup, struct acpi_pci_root *root)
{
int ret;
struct acpi_device *device;
device = root->device;
ret = acpi_match_device_ids(device, hisi_pcie_ids);
if (ret)
return 0;
......
return 1;
}
static struct pci_ops hisi_ecam_pci_ops = {
.map_bus = pci_mcfg_dev_base,
.read = hisi_pci_read,
.write = hisi_pci_write,
};
DECLARE_ACPI_MCFG_FIXUP(NULL, hisi_pcie_match, &hisi_ecam_pci_ops,
PCI_MCFG_DOMAIN_ANY, PCI_MCFG_BUS_ANY);
Thanks
Dongdong
> Makes a lot of sense to me, I will modify as you suggested.
>
> 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
>
> .
>
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
2016-01-19 1:49 ` liudongdong (C)
(?)
@ 2016-01-19 7:55 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-19 7:55 UTC (permalink / raw)
To: liudongdong (C),
Mark Salter, bhelgaas, arnd, will.deacon, catalin.marinas, rjw,
hanjun.guo, Lorenzo.Pieralisi, okaya, jiang.liu,
Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm, Zhou Wang,
Gabriele Paoloni
On 19.01.2016 02:49, liudongdong (C) wrote:
> Hi Tomasz, Mark
>
> 在 2016/1/18 20:41, Tomasz Nowicki 写道:
>> On 14.01.2016 16:36, Mark Salter wrote:
>>>> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
>>>> >+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
>>>> >+
>>>> >+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root
>>>> *root)
>>>> >+{
>>>> >+ struct pci_mcfg_fixup *f;
>>>> >+ int bus_num = root->secondary.start;
>>>> >+ int domain = root->segment;
>>>> >+
>>>> >+ /*
>>>> >+ * First match against PCI topology <domain:bus> then use DMI or
>>>> >+ * custom match handler.
>>>> >+ */
>>>> >+ for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>> f++) {
>>>> >+ if ((f->domain == domain || f->domain ==
>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>> >+ (f->bus_num == bus_num || f->bus_num ==
>>>> PCI_MCFG_BUS_ANY) &&
>>>> >+ (f->system ? dmi_check_system(f->system) : 0 ||
>>>> >+ f->match ? f->match(f, root) : 0))
>>>> >+ return f->ops;
>>> I think this would be better as:
>>>
>>> (f->system ? dmi_check_system(f->system) : 1 &&
>>> f->match ? f->match(f, root) : 1))
>>> return f->ops;
>>>
>>> Otherwise, one has to call dmi_check_system() from f->match() if
>>> access to root is needed.
>>
>
> Non-DMI, we need not to call dmi_check_system() from f->match(),
> we can use _HID to decide to hook the pci_ops or not.
Sorry, but I dont understand your point. Can you elaborate?
With Mark modification, you can use the following cases to identify
platform:
1. DMI only
2. f->match() only (_HID can be used there)
3. DMI and f->match()
DMI used to be very convenient way to recognise platform, sometimes it
is not enough, hence f->match() alternative.
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
@ 2016-01-19 7:55 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-19 7:55 UTC (permalink / raw)
To: linux-arm-kernel
On 19.01.2016 02:49, liudongdong (C) wrote:
> Hi Tomasz, Mark
>
> ? 2016/1/18 20:41, Tomasz Nowicki ??:
>> On 14.01.2016 16:36, Mark Salter wrote:
>>>> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
>>>> >+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
>>>> >+
>>>> >+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root
>>>> *root)
>>>> >+{
>>>> >+ struct pci_mcfg_fixup *f;
>>>> >+ int bus_num = root->secondary.start;
>>>> >+ int domain = root->segment;
>>>> >+
>>>> >+ /*
>>>> >+ * First match against PCI topology <domain:bus> then use DMI or
>>>> >+ * custom match handler.
>>>> >+ */
>>>> >+ for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>> f++) {
>>>> >+ if ((f->domain == domain || f->domain ==
>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>> >+ (f->bus_num == bus_num || f->bus_num ==
>>>> PCI_MCFG_BUS_ANY) &&
>>>> >+ (f->system ? dmi_check_system(f->system) : 0 ||
>>>> >+ f->match ? f->match(f, root) : 0))
>>>> >+ return f->ops;
>>> I think this would be better as:
>>>
>>> (f->system ? dmi_check_system(f->system) : 1 &&
>>> f->match ? f->match(f, root) : 1))
>>> return f->ops;
>>>
>>> Otherwise, one has to call dmi_check_system() from f->match() if
>>> access to root is needed.
>>
>
> Non-DMI, we need not to call dmi_check_system() from f->match(),
> we can use _HID to decide to hook the pci_ops or not.
Sorry, but I dont understand your point. Can you elaborate?
With Mark modification, you can use the following cases to identify
platform:
1. DMI only
2. f->match() only (_HID can be used there)
3. DMI and f->match()
DMI used to be very convenient way to recognise platform, sometimes it
is not enough, hence f->match() alternative.
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
@ 2016-01-19 7:55 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-19 7:55 UTC (permalink / raw)
To: liudongdong (C),
Mark Salter, bhelgaas, arnd, will.deacon, catalin.marinas, rjw,
hanjun.guo, Lorenzo.Pieralisi, okaya, jiang.liu,
Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm, Zhou Wang,
Gabriele Paoloni
On 19.01.2016 02:49, liudongdong (C) wrote:
> Hi Tomasz, Mark
>
> 在 2016/1/18 20:41, Tomasz Nowicki 写道:
>> On 14.01.2016 16:36, Mark Salter wrote:
>>>> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
>>>> >+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
>>>> >+
>>>> >+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root
>>>> *root)
>>>> >+{
>>>> >+ struct pci_mcfg_fixup *f;
>>>> >+ int bus_num = root->secondary.start;
>>>> >+ int domain = root->segment;
>>>> >+
>>>> >+ /*
>>>> >+ * First match against PCI topology <domain:bus> then use DMI or
>>>> >+ * custom match handler.
>>>> >+ */
>>>> >+ for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>> f++) {
>>>> >+ if ((f->domain == domain || f->domain ==
>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>> >+ (f->bus_num == bus_num || f->bus_num ==
>>>> PCI_MCFG_BUS_ANY) &&
>>>> >+ (f->system ? dmi_check_system(f->system) : 0 ||
>>>> >+ f->match ? f->match(f, root) : 0))
>>>> >+ return f->ops;
>>> I think this would be better as:
>>>
>>> (f->system ? dmi_check_system(f->system) : 1 &&
>>> f->match ? f->match(f, root) : 1))
>>> return f->ops;
>>>
>>> Otherwise, one has to call dmi_check_system() from f->match() if
>>> access to root is needed.
>>
>
> Non-DMI, we need not to call dmi_check_system() from f->match(),
> we can use _HID to decide to hook the pci_ops or not.
Sorry, but I dont understand your point. Can you elaborate?
With Mark modification, you can use the following cases to identify
platform:
1. DMI only
2. f->match() only (_HID can be used there)
3. DMI and f->match()
DMI used to be very convenient way to recognise platform, sometimes it
is not enough, hence f->match() alternative.
Tomasz
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
2016-01-19 7:55 ` Tomasz Nowicki
(?)
@ 2016-01-19 8:52 ` liudongdong (C)
-1 siblings, 0 replies; 184+ messages in thread
From: liudongdong (C) @ 2016-01-19 8:52 UTC (permalink / raw)
To: Tomasz Nowicki, Mark Salter, bhelgaas, arnd, will.deacon,
catalin.marinas, rjw, hanjun.guo, Lorenzo.Pieralisi, okaya,
jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm, Zhou Wang,
Gabriele Paoloni
在 2016/1/19 15:55, Tomasz Nowicki 写道:
> On 19.01.2016 02:49, liudongdong (C) wrote:
>> Hi Tomasz, Mark
>>
>> 在 2016/1/18 20:41, Tomasz Nowicki 写道:
>>> On 14.01.2016 16:36, Mark Salter wrote:
>>>>> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
>>>>> >+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
>>>>> >+
>>>>> >+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root
>>>>> *root)
>>>>> >+{
>>>>> >+ struct pci_mcfg_fixup *f;
>>>>> >+ int bus_num = root->secondary.start;
>>>>> >+ int domain = root->segment;
>>>>> >+
>>>>> >+ /*
>>>>> >+ * First match against PCI topology <domain:bus> then use DMI or
>>>>> >+ * custom match handler.
>>>>> >+ */
>>>>> >+ for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>>> f++) {
>>>>> >+ if ((f->domain == domain || f->domain ==
>>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>>> >+ (f->bus_num == bus_num || f->bus_num ==
>>>>> PCI_MCFG_BUS_ANY) &&
>>>>> >+ (f->system ? dmi_check_system(f->system) : 0 ||
>>>>> >+ f->match ? f->match(f, root) : 0))
>>>>> >+ return f->ops;
>>>> I think this would be better as:
>>>>
>>>> (f->system ? dmi_check_system(f->system) : 1 &&
>>>> f->match ? f->match(f, root) : 1))
>>>> return f->ops;
>>>>
>>>> Otherwise, one has to call dmi_check_system() from f->match() if
>>>> access to root is needed.
>>>
>>
>> Non-DMI, we need not to call dmi_check_system() from f->match(),
>> we can use _HID to decide to hook the pci_ops or not.
>
> Sorry, but I dont understand your point. Can you elaborate?
>
> With Mark modification, you can use the following cases to identify platform:
> 1. DMI only
> 2. f->match() only (_HID can be used there)
> 3. DMI and f->match()
>
> DMI used to be very convenient way to recognise platform, sometimes it is not enough, hence f->match() alternative.
>
Yes, you are right, I was wrong.
In my case, I can use the second point.
2. f->match() only (_HID can be used there)
Thanks
Dongdong
> Tomasz
>
>
>
> .
>
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
@ 2016-01-19 8:52 ` liudongdong (C)
0 siblings, 0 replies; 184+ messages in thread
From: liudongdong (C) @ 2016-01-19 8:52 UTC (permalink / raw)
To: linux-arm-kernel
? 2016/1/19 15:55, Tomasz Nowicki ??:
> On 19.01.2016 02:49, liudongdong (C) wrote:
>> Hi Tomasz, Mark
>>
>> ? 2016/1/18 20:41, Tomasz Nowicki ??:
>>> On 14.01.2016 16:36, Mark Salter wrote:
>>>>> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
>>>>> >+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
>>>>> >+
>>>>> >+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root
>>>>> *root)
>>>>> >+{
>>>>> >+ struct pci_mcfg_fixup *f;
>>>>> >+ int bus_num = root->secondary.start;
>>>>> >+ int domain = root->segment;
>>>>> >+
>>>>> >+ /*
>>>>> >+ * First match against PCI topology <domain:bus> then use DMI or
>>>>> >+ * custom match handler.
>>>>> >+ */
>>>>> >+ for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>>> f++) {
>>>>> >+ if ((f->domain == domain || f->domain ==
>>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>>> >+ (f->bus_num == bus_num || f->bus_num ==
>>>>> PCI_MCFG_BUS_ANY) &&
>>>>> >+ (f->system ? dmi_check_system(f->system) : 0 ||
>>>>> >+ f->match ? f->match(f, root) : 0))
>>>>> >+ return f->ops;
>>>> I think this would be better as:
>>>>
>>>> (f->system ? dmi_check_system(f->system) : 1 &&
>>>> f->match ? f->match(f, root) : 1))
>>>> return f->ops;
>>>>
>>>> Otherwise, one has to call dmi_check_system() from f->match() if
>>>> access to root is needed.
>>>
>>
>> Non-DMI, we need not to call dmi_check_system() from f->match(),
>> we can use _HID to decide to hook the pci_ops or not.
>
> Sorry, but I dont understand your point. Can you elaborate?
>
> With Mark modification, you can use the following cases to identify platform:
> 1. DMI only
> 2. f->match() only (_HID can be used there)
> 3. DMI and f->match()
>
> DMI used to be very convenient way to recognise platform, sometimes it is not enough, hence f->match() alternative.
>
Yes, you are right, I was wrong.
In my case, I can use the second point.
2. f->match() only (_HID can be used there)
Thanks
Dongdong
> Tomasz
>
>
>
> .
>
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 20/21] pci, acpi: Match PCI config space accessors against platfrom specific quirks.
@ 2016-01-19 8:52 ` liudongdong (C)
0 siblings, 0 replies; 184+ messages in thread
From: liudongdong (C) @ 2016-01-19 8:52 UTC (permalink / raw)
To: Tomasz Nowicki, Mark Salter, bhelgaas, arnd, will.deacon,
catalin.marinas, rjw, hanjun.guo, Lorenzo.Pieralisi, okaya,
jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm, Zhou Wang,
Gabriele Paoloni
在 2016/1/19 15:55, Tomasz Nowicki 写道:
> On 19.01.2016 02:49, liudongdong (C) wrote:
>> Hi Tomasz, Mark
>>
>> 在 2016/1/18 20:41, Tomasz Nowicki 写道:
>>> On 14.01.2016 16:36, Mark Salter wrote:
>>>>> +extern struct pci_mcfg_fixup __start_acpi_mcfg_fixups[];
>>>>> >+extern struct pci_mcfg_fixup __end_acpi_mcfg_fixups[];
>>>>> >+
>>>>> >+static struct pci_ops *pci_mcfg_check_quirks(struct acpi_pci_root
>>>>> *root)
>>>>> >+{
>>>>> >+ struct pci_mcfg_fixup *f;
>>>>> >+ int bus_num = root->secondary.start;
>>>>> >+ int domain = root->segment;
>>>>> >+
>>>>> >+ /*
>>>>> >+ * First match against PCI topology <domain:bus> then use DMI or
>>>>> >+ * custom match handler.
>>>>> >+ */
>>>>> >+ for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups;
>>>>> f++) {
>>>>> >+ if ((f->domain == domain || f->domain ==
>>>>> PCI_MCFG_DOMAIN_ANY) &&
>>>>> >+ (f->bus_num == bus_num || f->bus_num ==
>>>>> PCI_MCFG_BUS_ANY) &&
>>>>> >+ (f->system ? dmi_check_system(f->system) : 0 ||
>>>>> >+ f->match ? f->match(f, root) : 0))
>>>>> >+ return f->ops;
>>>> I think this would be better as:
>>>>
>>>> (f->system ? dmi_check_system(f->system) : 1 &&
>>>> f->match ? f->match(f, root) : 1))
>>>> return f->ops;
>>>>
>>>> Otherwise, one has to call dmi_check_system() from f->match() if
>>>> access to root is needed.
>>>
>>
>> Non-DMI, we need not to call dmi_check_system() from f->match(),
>> we can use _HID to decide to hook the pci_ops or not.
>
> Sorry, but I dont understand your point. Can you elaborate?
>
> With Mark modification, you can use the following cases to identify platform:
> 1. DMI only
> 2. f->match() only (_HID can be used there)
> 3. DMI and f->match()
>
> DMI used to be very convenient way to recognise platform, sometimes it is not enough, hence f->match() alternative.
>
Yes, you are right, I was wrong.
In my case, I can use the second point.
2. f->match() only (_HID can be used there)
Thanks
Dongdong
> Tomasz
>
>
>
> .
>
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH] pci, acpi: QDF2xxx 32 bit config space accessors
2016-01-13 13:21 ` Tomasz Nowicki
(?)
(?)
@ 2016-01-19 19:54 ` Christopher Covington
2016-01-19 20:19 ` Christopher Covington
2016-02-05 16:00 ` [PATCH v2] acpi: pci: QDF2432 " Christopher Covington
-1 siblings, 2 replies; 184+ messages in thread
From: Christopher Covington @ 2016-01-19 19:54 UTC (permalink / raw)
To: Tomasz Nowicki, Rafael J. Wysocki, Len Brown, linux-acpi, linux-kernel
Cc: linux-arm-msm, Timur Tabi, Jon Masters, Mark Langsdorf,
Sinan Kaya, Christopher Covington
Qualcomm Technologies QDF2xxx SoCs require 32 bit accessors to be used
for the PCI configuration space. Register the appropriate quirk.
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
This patch depends on Tomasz Nowicki's ACPI support for PCI:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/thread.html#399200
drivers/acpi/mcfg.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index ec5fe7b..dee4964 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -78,6 +78,29 @@ static struct pci_ops default_pci_mcfg_ops = {
.write = pci_generic_config_write,
};
+static const struct dmi_system_id qcom_qdf2xxx[] = {
+ {
+ .ident = "Qualcomm Technologies QDF2xxx",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Qualcomm"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "QDF2"),
+ },
+ },
+ { }
+};
+
+static struct pci_ops qcom_qdf2xxx_pci_mcfg_ops = {
+ .map_bus = pci_mcfg_dev_base,
+ .read = pci_generic_config_read32,
+ .write = pci_generic_config_write32,
+};
+
+DECLARE_ACPI_MCFG_FIXUP(qcom_qdf2xxx,
+ NULL,
+ &qcom_qdf2xxx_pci_mcfg_ops,
+ PCI_MCFG_DOMAIN_ANY,
+ PCI_MCFG_BUS_ANY);
+
struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
{
struct pci_ops *pci_mcfg_ops_quirk;
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related [flat|nested] 184+ messages in thread* Re: [PATCH] pci, acpi: QDF2xxx 32 bit config space accessors
2016-01-19 19:54 ` [PATCH] pci, acpi: QDF2xxx 32 bit config space accessors Christopher Covington
@ 2016-01-19 20:19 ` Christopher Covington
2016-02-05 16:00 ` [PATCH v2] acpi: pci: QDF2432 " Christopher Covington
1 sibling, 0 replies; 184+ messages in thread
From: Christopher Covington @ 2016-01-19 20:19 UTC (permalink / raw)
To: Jon Masters
Cc: Tomasz Nowicki, Rafael J. Wysocki, Len Brown, linux-acpi,
linux-kernel, linux-arm-msm, Timur Tabi, Mark Langsdorf,
Sinan Kaya
[Fixing Jon's email; sorry for the typo.]
On 01/19/2016 02:54 PM, Christopher Covington wrote:
> Qualcomm Technologies QDF2xxx SoCs require 32 bit accessors to be used
> for the PCI configuration space. Register the appropriate quirk.
>
> Signed-off-by: Christopher Covington <cov@codeaurora.org>
> ---
> This patch depends on Tomasz Nowicki's ACPI support for PCI:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-January/thread.html#399200
>
> drivers/acpi/mcfg.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
> index ec5fe7b..dee4964 100644
> --- a/drivers/acpi/mcfg.c
> +++ b/drivers/acpi/mcfg.c
> @@ -78,6 +78,29 @@ static struct pci_ops default_pci_mcfg_ops = {
> .write = pci_generic_config_write,
> };
>
> +static const struct dmi_system_id qcom_qdf2xxx[] = {
> + {
> + .ident = "Qualcomm Technologies QDF2xxx",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Qualcomm"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "QDF2"),
> + },
> + },
> + { }
> +};
> +
> +static struct pci_ops qcom_qdf2xxx_pci_mcfg_ops = {
> + .map_bus = pci_mcfg_dev_base,
> + .read = pci_generic_config_read32,
> + .write = pci_generic_config_write32,
> +};
> +
> +DECLARE_ACPI_MCFG_FIXUP(qcom_qdf2xxx,
> + NULL,
> + &qcom_qdf2xxx_pci_mcfg_ops,
> + PCI_MCFG_DOMAIN_ANY,
> + PCI_MCFG_BUS_ANY);
> +
> struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
> {
> struct pci_ops *pci_mcfg_ops_quirk;
>
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH v2] acpi: pci: QDF2432 32 bit config space accessors
2016-01-19 19:54 ` [PATCH] pci, acpi: QDF2xxx 32 bit config space accessors Christopher Covington
2016-01-19 20:19 ` Christopher Covington
@ 2016-02-05 16:00 ` Christopher Covington
1 sibling, 0 replies; 184+ messages in thread
From: Christopher Covington @ 2016-02-05 16:00 UTC (permalink / raw)
To: Rafael J. Wysocki, Len Brown, linux-acpi, linux-kernel
Cc: Tomasz Nowicki, linux-arm-msm, Timur Tabi, Jon Masters,
Mark Langsdorf, Christopher Covington
Qualcomm Technologies QDF2432 SoCs require 32 bit accessors to be used
for the PCI configuration space. Register the appropriate quirk.
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
Dependent on Tomasz Nowicki's ACPI support for PCI:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-February/thread.html#405148
v1 -> v2: Rebase and use full product name
drivers/acpi/mcfg.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/drivers/acpi/mcfg.c b/drivers/acpi/mcfg.c
index 4663f70..18e792b 100644
--- a/drivers/acpi/mcfg.c
+++ b/drivers/acpi/mcfg.c
@@ -78,6 +78,29 @@ static struct pci_ops default_pci_mcfg_ops = {
.write = pci_generic_config_write,
};
+static const struct dmi_system_id qcom_qdf2432[] = {
+ {
+ .ident = "Qualcomm Technologies QDF2432",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Qualcomm"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "QDF2432"),
+ },
+ },
+ { }
+};
+
+static struct pci_ops qcom_qdf2432_pci_mcfg_ops = {
+ .map_bus = pci_mcfg_dev_base,
+ .read = pci_generic_config_read32,
+ .write = pci_generic_config_write32,
+};
+
+DECLARE_ACPI_MCFG_FIXUP(qcom_qdf2432,
+ NULL,
+ &qcom_qdf2432_pci_mcfg_ops,
+ PCI_MCFG_DOMAIN_ANY,
+ PCI_MCFG_BUS_ANY);
+
struct pci_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
{
struct pci_ops *pci_mcfg_ops_quirk;
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related [flat|nested] 184+ messages in thread
* [PATCH V3 21/21] arm64, pci, acpi: Start using ACPI based PCI host bridge driver for ARM64.
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 13:21 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
Tomasz Nowicki
Lets get rid of empty PCI init stub, related ACPI header and
go with full-blown PCI host bridge driver.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Liviu Dudau <Liviu.Dudau@arm.com>
CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
CC: Will Deacon <will.deacon@arm.com>
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/pci.c | 10 ----------
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index d65d315..573bebc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2,6 +2,7 @@ config ARM64
def_bool y
select ACPI_CCA_REQUIRED if ACPI
select ACPI_GENERIC_GSI if ACPI
+ select ACPI_PCI_HOST_GENERIC if ACPI
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 023b983..a0929a6 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -10,7 +10,6 @@
*
*/
-#include <linux/acpi.h>
#include <linux/init.h>
#include <linux/io.h>
#include <linux/kernel.h>
@@ -60,12 +59,3 @@ int pcibios_add_device(struct pci_dev *dev)
return 0;
}
-
-#ifdef CONFIG_ACPI
-/* Root bridge scanning */
-struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
-{
- /* TODO: Should be revisited when implementing PCI on ACPI */
- return NULL;
-}
-#endif
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 21/21] arm64, pci, acpi: Start using ACPI based PCI host bridge driver for ARM64.
@ 2016-01-13 13:21 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 13:21 UTC (permalink / raw)
To: linux-arm-kernel
Lets get rid of empty PCI init stub, related ACPI header and
go with full-blown PCI host bridge driver.
Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
CC: Arnd Bergmann <arnd@arndb.de>
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Liviu Dudau <Liviu.Dudau@arm.com>
CC: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
CC: Will Deacon <will.deacon@arm.com>
---
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/pci.c | 10 ----------
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index d65d315..573bebc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -2,6 +2,7 @@ config ARM64
def_bool y
select ACPI_CCA_REQUIRED if ACPI
select ACPI_GENERIC_GSI if ACPI
+ select ACPI_PCI_HOST_GENERIC if ACPI
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
index 023b983..a0929a6 100644
--- a/arch/arm64/kernel/pci.c
+++ b/arch/arm64/kernel/pci.c
@@ -10,7 +10,6 @@
*
*/
-#include <linux/acpi.h>
#include <linux/init.h>
#include <linux/io.h>
#include <linux/kernel.h>
@@ -60,12 +59,3 @@ int pcibios_add_device(struct pci_dev *dev)
return 0;
}
-
-#ifdef CONFIG_ACPI
-/* Root bridge scanning */
-struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
-{
- /* TODO: Should be revisited when implementing PCI on ACPI */
- return NULL;
-}
-#endif
--
1.9.1
^ permalink raw reply related [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-13 15:24 ` Sinan Kaya
-1 siblings, 0 replies; 184+ messages in thread
From: Sinan Kaya @ 2016-01-13 15:24 UTC (permalink / raw)
To: Tomasz Nowicki, bhelgaas, arnd, will.deacon, catalin.marinas,
rjw, hanjun.guo, Lorenzo.Pieralisi, jiang.liu,
Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm
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
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-13 15:24 ` Sinan Kaya
0 siblings, 0 replies; 184+ messages in thread
From: Sinan Kaya @ 2016-01-13 15:24 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-13 15:24 ` Sinan Kaya
@ 2016-01-13 15:27 ` Tomasz Nowicki
-1 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 15:27 UTC (permalink / raw)
To: Sinan Kaya, bhelgaas, arnd, will.deacon, catalin.marinas, rjw,
hanjun.guo, Lorenzo.Pieralisi, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm
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
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-13 15:27 ` Tomasz Nowicki
0 siblings, 0 replies; 184+ messages in thread
From: Tomasz Nowicki @ 2016-01-13 15:27 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-14 13:44 ` Graeme Gregory
-1 siblings, 0 replies; 184+ messages in thread
From: Graeme Gregory @ 2016-01-14 13:44 UTC (permalink / raw)
To: Tomasz Nowicki
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini,
robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm
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
^ permalink raw reply related [flat|nested] 184+ messages in thread* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 13:44 ` Graeme Gregory
0 siblings, 0 replies; 184+ messages in thread
From: Graeme Gregory @ 2016-01-14 13:44 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply related [flat|nested] 184+ messages in thread* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 13:44 ` Graeme Gregory
@ 2016-01-14 14:00 ` Catalin Marinas
-1 siblings, 0 replies; 184+ messages in thread
From: Catalin Marinas @ 2016-01-14 14:00 UTC (permalink / raw)
To: Graeme Gregory
Cc: Tomasz Nowicki, linaro-acpi, linux-pci, will.deacon, okaya,
wangyijing, Lorenzo.Pieralisi, ddaney, linux-acpi,
robert.richter, jcm, arnd, Stefano.Stabellini, Liviu.Dudau,
msalter, bhelgaas, tglx, mw, linux-arm-kernel, jchandra, rjw,
linux-kernel, hanjun.guo, Suravee.Suthikulpanit, jiang.liu
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
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 14:00 ` Catalin Marinas
0 siblings, 0 replies; 184+ messages in thread
From: Catalin Marinas @ 2016-01-14 14:00 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 14:00 ` Catalin Marinas
(?)
@ 2016-01-14 14:09 ` Mark Salter
-1 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 14:09 UTC (permalink / raw)
To: Catalin Marinas, Graeme Gregory
Cc: Tomasz Nowicki, linaro-acpi, linux-pci, will.deacon, okaya,
wangyijing, Lorenzo.Pieralisi, ddaney, linux-acpi,
robert.richter, jcm, arnd, Stefano.Stabellini, Liviu.Dudau,
bhelgaas, tglx, mw, linux-arm-kernel, jchandra, rjw,
linux-kernel, hanjun.guo, Suravee.Suthikulpanit, jiang.liu
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?
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 14:09 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 14:09 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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?
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 14:09 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 14:09 UTC (permalink / raw)
To: Catalin Marinas, Graeme Gregory
Cc: Tomasz Nowicki, linaro-acpi, linux-pci, will.deacon, okaya,
wangyijing, Lorenzo.Pieralisi, ddaney, linux-acpi,
robert.richter, jcm, arnd, Stefano.Stabellini, Liviu.Dudau,
bhelgaas, tglx, mw, linux-arm-kernel, jchandra, rjw,
linux-kernel, hanjun.guo, Suravee.Suthikulpanit, jiang.liu
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?
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 14:09 ` Mark Salter
(?)
@ 2016-01-14 14:50 ` Catalin Marinas
-1 siblings, 0 replies; 184+ messages in thread
From: Catalin Marinas @ 2016-01-14 14:50 UTC (permalink / raw)
To: Mark Salter
Cc: linaro-acpi, linux-pci, will.deacon, okaya, Graeme Gregory,
wangyijing, Lorenzo.Pieralisi, Tomasz Nowicki, ddaney,
linux-acpi, robert.richter, jcm, arnd, Stefano.Stabellini,
Liviu.Dudau, bhelgaas, tglx, mw, linux-arm-kernel, jchandra, rjw,
linux-kernel, hanjun.guo, Suravee.Suthikulpanit, jiang.liu
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
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 14:50 ` Catalin Marinas
0 siblings, 0 replies; 184+ messages in thread
From: Catalin Marinas @ 2016-01-14 14:50 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 14:50 ` Catalin Marinas
0 siblings, 0 replies; 184+ messages in thread
From: Catalin Marinas @ 2016-01-14 14:50 UTC (permalink / raw)
To: Mark Salter
Cc: Graeme Gregory, linaro-acpi, linux-pci, will.deacon, okaya,
wangyijing, Lorenzo.Pieralisi, Tomasz Nowicki, ddaney,
linux-acpi, robert.richter, jcm, arnd, Stefano.Stabellini,
Liviu.Dudau, bhelgaas, tglx, mw, linux-arm-kernel, jchandra, rjw,
linux-kernel, hanjun.guo, Suravee.Suthikulpanit, jiang.liu
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
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 14:50 ` Catalin Marinas
@ 2016-01-14 14:59 ` Mark Salter
-1 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 14:59 UTC (permalink / raw)
To: Catalin Marinas
Cc: Graeme Gregory, linaro-acpi, linux-pci, will.deacon, okaya,
wangyijing, Lorenzo.Pieralisi, Tomasz Nowicki, ddaney,
linux-acpi, robert.richter, jcm, arnd, Stefano.Stabellini,
Liviu.Dudau, bhelgaas, tglx, mw, linux-arm-kernel, jchandra, rjw,
linux-kernel, hanjun.guo, Suravee.Suthikulpanit, jiang.liu
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.
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 14:59 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 14:59 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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.
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 13:44 ` Graeme Gregory
@ 2016-01-14 14:01 ` Mark Salter
-1 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 14:01 UTC (permalink / raw)
To: Graeme Gregory, Tomasz Nowicki
Cc: bhelgaas, arnd, will.deacon, catalin.marinas, rjw, hanjun.guo,
Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini,
robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm
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
>
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 14:01 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 14:01 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
>
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 14:01 ` Mark Salter
@ 2016-01-14 14:15 ` Graeme Gregory
-1 siblings, 0 replies; 184+ messages in thread
From: Graeme Gregory @ 2016-01-14 14:15 UTC (permalink / raw)
To: Mark Salter
Cc: Tomasz Nowicki, linaro-acpi, catalin.marinas, will.deacon, okaya,
wangyijing, Lorenzo.Pieralisi, ddaney, linux-acpi,
robert.richter, linux-pci, jcm, arnd, Stefano.Stabellini,
Liviu.Dudau, bhelgaas, tglx, mw, linux-arm-kernel, jchandra, rjw,
linux-kernel, hanjun.guo, Suravee.Suthikulpanit, jiang.liu
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
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 14:15 ` Graeme Gregory
0 siblings, 0 replies; 184+ messages in thread
From: Graeme Gregory @ 2016-01-14 14:15 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 14:15 ` Graeme Gregory
@ 2016-01-14 14:24 ` Mark Salter
-1 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 14:24 UTC (permalink / raw)
To: Graeme Gregory
Cc: Tomasz Nowicki, linaro-acpi, catalin.marinas, will.deacon, okaya,
wangyijing, Lorenzo.Pieralisi, ddaney, linux-acpi,
robert.richter, linux-pci, jcm, arnd, Stefano.Stabellini,
Liviu.Dudau, bhelgaas, tglx, mw, linux-arm-kernel, jchandra, rjw,
linux-kernel, hanjun.guo, Suravee.Suthikulpanit, jiang.liu
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
>
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 14:24 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 14:24 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
>
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 14:24 ` Mark Salter
(?)
@ 2016-01-15 12:12 ` Graeme Gregory
-1 siblings, 0 replies; 184+ messages in thread
From: Graeme Gregory @ 2016-01-15 12:12 UTC (permalink / raw)
To: Mark Salter
Cc: linaro-acpi, catalin.marinas, will.deacon, okaya, wangyijing,
Lorenzo.Pieralisi, Tomasz Nowicki, ddaney, linux-acpi,
robert.richter, linux-pci, jcm, arnd, Stefano.Stabellini,
Liviu.Dudau, bhelgaas, tglx, mw, linux-arm-kernel, jchandra, rjw,
linux-kernel, hanjun.guo, Suravee.Suthikulpanit, jiang.liu
On Thu, Jan 14, 2016 at 09:24:41AM -0500, Mark Salter wrote:
> 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...
>
>From my previous debugging on this issue I was getting an address bigger
than 32bits. As r8169 is a whole range of chips are guess they are not
all equal?
I can stick debug stuff in if someone tells me where to put them.
Graeme
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-15 12:12 ` Graeme Gregory
0 siblings, 0 replies; 184+ messages in thread
From: Graeme Gregory @ 2016-01-15 12:12 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 14, 2016 at 09:24:41AM -0500, Mark Salter wrote:
> 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 at 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...
>
>From my previous debugging on this issue I was getting an address bigger
than 32bits. As r8169 is a whole range of chips are guess they are not
all equal?
I can stick debug stuff in if someone tells me where to put them.
Graeme
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-15 12:12 ` Graeme Gregory
0 siblings, 0 replies; 184+ messages in thread
From: Graeme Gregory @ 2016-01-15 12:12 UTC (permalink / raw)
To: Mark Salter
Cc: linaro-acpi, linux-pci, will.deacon, okaya, wangyijing,
Lorenzo.Pieralisi, Tomasz Nowicki, ddaney, linux-acpi,
robert.richter, catalin.marinas, jcm, arnd, Stefano.Stabellini,
Liviu.Dudau, bhelgaas, tglx, mw, linux-arm-kernel, jchandra, rjw,
linux-kernel, hanjun.guo, Suravee.Suthikulpanit, jiang.liu
On Thu, Jan 14, 2016 at 09:24:41AM -0500, Mark Salter wrote:
> 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...
>
>From my previous debugging on this issue I was getting an address bigger
than 32bits. As r8169 is a whole range of chips are guess they are not
all equal?
I can stick debug stuff in if someone tells me where to put them.
Graeme
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-15 12:12 ` Graeme Gregory
(?)
@ 2016-01-18 14:04 ` Graeme Gregory
-1 siblings, 0 replies; 184+ messages in thread
From: Graeme Gregory @ 2016-01-18 14:04 UTC (permalink / raw)
To: Mark Salter
Cc: linaro-acpi, catalin.marinas, will.deacon, okaya, wangyijing,
Lorenzo.Pieralisi, Tomasz Nowicki, ddaney, linux-acpi,
robert.richter, linux-pci, jcm, arnd, Stefano.Stabellini,
Liviu.Dudau, bhelgaas, tglx, mw, linux-arm-kernel, jchandra, rjw,
linux-kernel, hanjun.guo, Suravee.Suthikulpanit, jiang.liu
On Fri, Jan 15, 2016 at 12:12:31PM +0000, Graeme Gregory wrote:
> On Thu, Jan 14, 2016 at 09:24:41AM -0500, Mark Salter wrote:
> > 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...
> >
>
> From my previous debugging on this issue I was getting an address bigger
> than 32bits. As r8169 is a whole range of chips are guess they are not
> all equal?
>
> I can stick debug stuff in if someone tells me where to put them.
>
After some private debugging with Mark it turned out that the difference
between our configurations was I did not have.
CONFIG_DMA_CMA=y
With this enabled then the card works without coherent mask hack.
Thanks
Graeme
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-18 14:04 ` Graeme Gregory
0 siblings, 0 replies; 184+ messages in thread
From: Graeme Gregory @ 2016-01-18 14:04 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Jan 15, 2016 at 12:12:31PM +0000, Graeme Gregory wrote:
> On Thu, Jan 14, 2016 at 09:24:41AM -0500, Mark Salter wrote:
> > 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 at 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...
> >
>
> From my previous debugging on this issue I was getting an address bigger
> than 32bits. As r8169 is a whole range of chips are guess they are not
> all equal?
>
> I can stick debug stuff in if someone tells me where to put them.
>
After some private debugging with Mark it turned out that the difference
between our configurations was I did not have.
CONFIG_DMA_CMA=y
With this enabled then the card works without coherent mask hack.
Thanks
Graeme
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-18 14:04 ` Graeme Gregory
0 siblings, 0 replies; 184+ messages in thread
From: Graeme Gregory @ 2016-01-18 14:04 UTC (permalink / raw)
To: Mark Salter
Cc: linaro-acpi, catalin.marinas, will.deacon, okaya, wangyijing,
Lorenzo.Pieralisi, Tomasz Nowicki, ddaney, linux-acpi,
robert.richter, linux-pci, jcm, arnd, Stefano.Stabellini,
Liviu.Dudau, bhelgaas, tglx, mw, linux-arm-kernel, jchandra, rjw,
linux-kernel, hanjun.guo, Suravee.Suthikulpanit, jiang.liu
On Fri, Jan 15, 2016 at 12:12:31PM +0000, Graeme Gregory wrote:
> On Thu, Jan 14, 2016 at 09:24:41AM -0500, Mark Salter wrote:
> > 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...
> >
>
> From my previous debugging on this issue I was getting an address bigger
> than 32bits. As r8169 is a whole range of chips are guess they are not
> all equal?
>
> I can stick debug stuff in if someone tells me where to put them.
>
After some private debugging with Mark it turned out that the difference
between our configurations was I did not have.
CONFIG_DMA_CMA=y
With this enabled then the card works without coherent mask hack.
Thanks
Graeme
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-18 14:04 ` Graeme Gregory
@ 2016-01-19 20:25 ` Bjorn Helgaas
-1 siblings, 0 replies; 184+ messages in thread
From: Bjorn Helgaas @ 2016-01-19 20:25 UTC (permalink / raw)
To: Graeme Gregory
Cc: Mark Salter, linaro-acpi, catalin.marinas, will.deacon, okaya,
wangyijing, Lorenzo.Pieralisi, Tomasz Nowicki, ddaney,
linux-acpi, robert.richter, linux-pci, jcm, arnd,
Stefano.Stabellini, Liviu.Dudau, bhelgaas, tglx, mw,
linux-arm-kernel, jchandra, rjw, linux-kernel, hanjun.guo,
Suravee.Suthikulpanit, jiang.liu
On Mon, Jan 18, 2016 at 02:04:05PM +0000, Graeme Gregory wrote:
> On Fri, Jan 15, 2016 at 12:12:31PM +0000, Graeme Gregory wrote:
> > On Thu, Jan 14, 2016 at 09:24:41AM -0500, Mark Salter wrote:
> > > 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...
> > >
> >
> > From my previous debugging on this issue I was getting an address bigger
> > than 32bits. As r8169 is a whole range of chips are guess they are not
> > all equal?
> >
> > I can stick debug stuff in if someone tells me where to put them.
> >
>
> After some private debugging with Mark it turned out that the difference
> between our configurations was I did not have.
>
> CONFIG_DMA_CMA=y
>
> With this enabled then the card works without coherent mask hack.
I didn't follow the whole discussion here, but is this a case where
the driver could fail more gracefully than it did? Can we do anything
to make this easier for the next person who trips over the same problem?
Bjorn
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-19 20:25 ` Bjorn Helgaas
0 siblings, 0 replies; 184+ messages in thread
From: Bjorn Helgaas @ 2016-01-19 20:25 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, Jan 18, 2016 at 02:04:05PM +0000, Graeme Gregory wrote:
> On Fri, Jan 15, 2016 at 12:12:31PM +0000, Graeme Gregory wrote:
> > On Thu, Jan 14, 2016 at 09:24:41AM -0500, Mark Salter wrote:
> > > 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 at 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...
> > >
> >
> > From my previous debugging on this issue I was getting an address bigger
> > than 32bits. As r8169 is a whole range of chips are guess they are not
> > all equal?
> >
> > I can stick debug stuff in if someone tells me where to put them.
> >
>
> After some private debugging with Mark it turned out that the difference
> between our configurations was I did not have.
>
> CONFIG_DMA_CMA=y
>
> With this enabled then the card works without coherent mask hack.
I didn't follow the whole discussion here, but is this a case where
the driver could fail more gracefully than it did? Can we do anything
to make this easier for the next person who trips over the same problem?
Bjorn
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-19 20:25 ` Bjorn Helgaas
@ 2016-01-19 20:40 ` Russell King - ARM Linux
-1 siblings, 0 replies; 184+ messages in thread
From: Russell King - ARM Linux @ 2016-01-19 20:40 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Graeme Gregory, linaro-acpi, linux-pci, will.deacon, okaya,
wangyijing, Lorenzo.Pieralisi, Tomasz Nowicki, ddaney,
linux-acpi, robert.richter, catalin.marinas, jcm, arnd,
Stefano.Stabellini, Liviu.Dudau, Mark Salter, bhelgaas, tglx, mw,
linux-arm-kernel, jchandra, rjw, linux-kernel, hanjun.guo,
Suravee.Suthikulpanit, jiang.liu
On Tue, Jan 19, 2016 at 02:25:13PM -0600, Bjorn Helgaas wrote:
> On Mon, Jan 18, 2016 at 02:04:05PM +0000, Graeme Gregory wrote:
> > After some private debugging with Mark it turned out that the difference
> > between our configurations was I did not have.
> >
> > CONFIG_DMA_CMA=y
> >
> > With this enabled then the card works without coherent mask hack.
>
> I didn't follow the whole discussion here, but is this a case where
> the driver could fail more gracefully than it did? Can we do anything
> to make this easier for the next person who trips over the same problem?
I've not followed the discussion at all, but reading what was in the
quoted parts of the mail makes me somewhat suspicious.
The way PCI drivers (or in fact any driver) are supposed to work is:
- the bus code sets up a default mask (32-bit DMA in the case of PCI)
- the driver calls dma_set_mask() or similar function with the mask
the _driver_ wants to use. Arch DMA code decides whether the mask
can be supported, and if it can, it re-sets the DMA mask. If the
mask can't be supported, it returns an error.
The driver is doing things correctly:
if ((sizeof(dma_addr_t) > 4) &&
!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) && use_dac) {
tp->cp_cmd |= PCIDAC;
dev->features |= NETIF_F_HIGHDMA;
} else {
rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
which says: if the size of a DMA address supports 64-bit, and we can
set a 64-bit DMA address mask (iow, the platform allows it), and
we're permitted to use DAC, use DAC, otherwise try to set a 32-bit
DMA mask.
It shouldn't matter one bit what the mask is before that point.
However, what the driver fails to do is to deal with the coherent
mask - it appears to be missing a call to pci_set_consistent_dma_mask().
That may be where the issue is.
It may be worth doing what I did with the DMA API, and introducing
pci_set_mask_and_coherent() which sets both masks together - which
will probably allow some PCI driver code to be simplified.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-19 20:40 ` Russell King - ARM Linux
0 siblings, 0 replies; 184+ messages in thread
From: Russell King - ARM Linux @ 2016-01-19 20:40 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jan 19, 2016 at 02:25:13PM -0600, Bjorn Helgaas wrote:
> On Mon, Jan 18, 2016 at 02:04:05PM +0000, Graeme Gregory wrote:
> > After some private debugging with Mark it turned out that the difference
> > between our configurations was I did not have.
> >
> > CONFIG_DMA_CMA=y
> >
> > With this enabled then the card works without coherent mask hack.
>
> I didn't follow the whole discussion here, but is this a case where
> the driver could fail more gracefully than it did? Can we do anything
> to make this easier for the next person who trips over the same problem?
I've not followed the discussion at all, but reading what was in the
quoted parts of the mail makes me somewhat suspicious.
The way PCI drivers (or in fact any driver) are supposed to work is:
- the bus code sets up a default mask (32-bit DMA in the case of PCI)
- the driver calls dma_set_mask() or similar function with the mask
the _driver_ wants to use. Arch DMA code decides whether the mask
can be supported, and if it can, it re-sets the DMA mask. If the
mask can't be supported, it returns an error.
The driver is doing things correctly:
if ((sizeof(dma_addr_t) > 4) &&
!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) && use_dac) {
tp->cp_cmd |= PCIDAC;
dev->features |= NETIF_F_HIGHDMA;
} else {
rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
which says: if the size of a DMA address supports 64-bit, and we can
set a 64-bit DMA address mask (iow, the platform allows it), and
we're permitted to use DAC, use DAC, otherwise try to set a 32-bit
DMA mask.
It shouldn't matter one bit what the mask is before that point.
However, what the driver fails to do is to deal with the coherent
mask - it appears to be missing a call to pci_set_consistent_dma_mask().
That may be where the issue is.
It may be worth doing what I did with the DMA API, and introducing
pci_set_mask_and_coherent() which sets both masks together - which
will probably allow some PCI driver code to be simplified.
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-19 20:40 ` Russell King - ARM Linux
(?)
@ 2016-01-19 23:37 ` Mark Salter
-1 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-19 23:37 UTC (permalink / raw)
To: Russell King - ARM Linux, Bjorn Helgaas
Cc: Graeme Gregory, linaro-acpi, linux-pci, will.deacon, okaya,
wangyijing, Lorenzo.Pieralisi, Tomasz Nowicki, ddaney,
linux-acpi, robert.richter, catalin.marinas, jcm, arnd,
Stefano.Stabellini, Liviu.Dudau, bhelgaas, tglx, mw,
linux-arm-kernel, jchandra, rjw, linux-kernel, hanjun.guo,
Suravee.Suthikulpanit, jiang.liu
On Tue, 2016-01-19 at 20:40 +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 19, 2016 at 02:25:13PM -0600, Bjorn Helgaas wrote:
> > On Mon, Jan 18, 2016 at 02:04:05PM +0000, Graeme Gregory wrote:
> > > After some private debugging with Mark it turned out that the difference
> > > between our configurations was I did not have.
> > >
> > > CONFIG_DMA_CMA=y
> > >
> > > With this enabled then the card works without coherent mask hack.
> >
> > I didn't follow the whole discussion here, but is this a case where
> > the driver could fail more gracefully than it did? Can we do anything
> > to make this easier for the next person who trips over the same problem?
>
> I've not followed the discussion at all, but reading what was in the
> quoted parts of the mail makes me somewhat suspicious.
>
> The way PCI drivers (or in fact any driver) are supposed to work is:
>
> - the bus code sets up a default mask (32-bit DMA in the case of PCI)
> - the driver calls dma_set_mask() or similar function with the mask
> the _driver_ wants to use. Arch DMA code decides whether the mask
> can be supported, and if it can, it re-sets the DMA mask. If the
> mask can't be supported, it returns an error.
>
> The driver is doing things correctly:
>
> if ((sizeof(dma_addr_t) > 4) &&
> !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) && use_dac) {
> tp->cp_cmd |= PCIDAC;
> dev->features |= NETIF_F_HIGHDMA;
> } else {
> rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
>
> which says: if the size of a DMA address supports 64-bit, and we can
> set a 64-bit DMA address mask (iow, the platform allows it), and
> we're permitted to use DAC, use DAC, otherwise try to set a 32-bit
> DMA mask.
>
> It shouldn't matter one bit what the mask is before that point.
>
> However, what the driver fails to do is to deal with the coherent
> mask - it appears to be missing a call to pci_set_consistent_dma_mask().
> That may be where the issue is.
It is.
The driver works with devicetree because of_dma_configure() sets up dma
and coherent mask for PCI devices based on root bridge info in the DT.
So the driver gets by without setting coherent mask explicitly. In the
ACPI case, the coherent mask doesn't get set because there isn't DMA
info in the ACPI tables (I think IORT table/IOMMU support will add this
in the future). Using CONFIG_DMA_CMA avoids the issue by allowing CMA
memory to be used for DMA while avoiding a check against coherent mask.
>
> It may be worth doing what I did with the DMA API, and introducing
> pci_set_mask_and_coherent() which sets both masks together - which
> will probably allow some PCI driver code to be simplified.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-19 23:37 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-19 23:37 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, 2016-01-19 at 20:40 +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 19, 2016 at 02:25:13PM -0600, Bjorn Helgaas wrote:
> > On Mon, Jan 18, 2016 at 02:04:05PM +0000, Graeme Gregory wrote:
> > > After some private debugging with Mark it turned out that the difference
> > > between our configurations was I did not have.
> > >
> > > CONFIG_DMA_CMA=y
> > >
> > > With this enabled then the card works without coherent mask hack.
> >
> > I didn't follow the whole discussion here, but is this a case where
> > the driver could fail more gracefully than it did???Can we do anything
> > to make this easier for the next person who trips over the same problem?
>
> I've not followed the discussion at all, but reading what was in the
> quoted parts of the mail makes me somewhat suspicious.
>
> The way PCI drivers (or in fact any driver) are supposed to work is:
>
> - the bus code sets up a default mask (32-bit DMA in the case of PCI)
> - the driver calls dma_set_mask() or similar function with the mask
> ? the _driver_ wants to use.??Arch DMA code decides whether the mask
> ? can be supported, and if it can, it re-sets the DMA mask.??If the
> ? mask can't be supported, it returns an error.
>
> The driver is doing things correctly:
>
> ????????if ((sizeof(dma_addr_t) > 4) &&
> ????????????!pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) && use_dac) {
> ????????????????tp->cp_cmd |= PCIDAC;
> ????????????????dev->features |= NETIF_F_HIGHDMA;
> ????????} else {
> ????????????????rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
>
> which says: if the size of a DMA address supports 64-bit, and we can
> set a 64-bit DMA address mask (iow, the platform allows it), and
> we're permitted to use DAC, use DAC, otherwise try to set a 32-bit
> DMA mask.
>
> It shouldn't matter one bit what the mask is before that point.
>
> However, what the driver fails to do is to deal with the coherent
> mask - it appears to be missing a call to pci_set_consistent_dma_mask().
> That may be where the issue is.
It is.
The driver works with devicetree because of_dma_configure() sets up dma
and coherent mask for PCI devices based on root bridge info in the DT.
So the driver gets by without setting coherent mask explicitly. In the
ACPI case, the coherent mask doesn't get set because there isn't DMA
info in the ACPI tables (I think IORT table/IOMMU support will add this
in the future). Using CONFIG_DMA_CMA avoids the issue by allowing CMA
memory to be used for DMA while avoiding a check against coherent mask.
>
> It may be worth doing what I did with the DMA API, and introducing
> pci_set_mask_and_coherent() which sets both masks together - which
> will probably allow some PCI driver code to be simplified.
>
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-19 23:37 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-19 23:37 UTC (permalink / raw)
To: Russell King - ARM Linux, Bjorn Helgaas
Cc: Graeme Gregory, linaro-acpi, linux-pci, will.deacon, okaya,
wangyijing, Lorenzo.Pieralisi, Tomasz Nowicki, ddaney,
linux-acpi, robert.richter, catalin.marinas, jcm, arnd,
Stefano.Stabellini, Liviu.Dudau, bhelgaas, tglx, mw,
linux-arm-kernel, jchandra, rjw, linux-kernel, hanjun.guo,
Suravee.Suthikulpanit, jiang.liu
On Tue, 2016-01-19 at 20:40 +0000, Russell King - ARM Linux wrote:
> On Tue, Jan 19, 2016 at 02:25:13PM -0600, Bjorn Helgaas wrote:
> > On Mon, Jan 18, 2016 at 02:04:05PM +0000, Graeme Gregory wrote:
> > > After some private debugging with Mark it turned out that the difference
> > > between our configurations was I did not have.
> > >
> > > CONFIG_DMA_CMA=y
> > >
> > > With this enabled then the card works without coherent mask hack.
> >
> > I didn't follow the whole discussion here, but is this a case where
> > the driver could fail more gracefully than it did? Can we do anything
> > to make this easier for the next person who trips over the same problem?
>
> I've not followed the discussion at all, but reading what was in the
> quoted parts of the mail makes me somewhat suspicious.
>
> The way PCI drivers (or in fact any driver) are supposed to work is:
>
> - the bus code sets up a default mask (32-bit DMA in the case of PCI)
> - the driver calls dma_set_mask() or similar function with the mask
> the _driver_ wants to use. Arch DMA code decides whether the mask
> can be supported, and if it can, it re-sets the DMA mask. If the
> mask can't be supported, it returns an error.
>
> The driver is doing things correctly:
>
> if ((sizeof(dma_addr_t) > 4) &&
> !pci_set_dma_mask(pdev, DMA_BIT_MASK(64)) && use_dac) {
> tp->cp_cmd |= PCIDAC;
> dev->features |= NETIF_F_HIGHDMA;
> } else {
> rc = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
>
> which says: if the size of a DMA address supports 64-bit, and we can
> set a 64-bit DMA address mask (iow, the platform allows it), and
> we're permitted to use DAC, use DAC, otherwise try to set a 32-bit
> DMA mask.
>
> It shouldn't matter one bit what the mask is before that point.
>
> However, what the driver fails to do is to deal with the coherent
> mask - it appears to be missing a call to pci_set_consistent_dma_mask().
> That may be where the issue is.
It is.
The driver works with devicetree because of_dma_configure() sets up dma
and coherent mask for PCI devices based on root bridge info in the DT.
So the driver gets by without setting coherent mask explicitly. In the
ACPI case, the coherent mask doesn't get set because there isn't DMA
info in the ACPI tables (I think IORT table/IOMMU support will add this
in the future). Using CONFIG_DMA_CMA avoids the issue by allowing CMA
memory to be used for DMA while avoiding a check against coherent mask.
>
> It may be worth doing what I did with the DMA API, and introducing
> pci_set_mask_and_coherent() which sets both masks together - which
> will probably allow some PCI driver code to be simplified.
>
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-14 15:29 ` Mark Salter
-1 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 15:29 UTC (permalink / raw)
To: Tomasz Nowicki, bhelgaas, arnd, will.deacon, catalin.marinas,
rjw, hanjun.guo, Lorenzo.Pieralisi, okaya, jiang.liu,
Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm
On Wed, 2016-01-13 at 14:20 +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.
>
> 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
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])
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 15:29 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 15:29 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, 2016-01-13 at 14:20 +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 at 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
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])
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 15:29 ` Mark Salter
@ 2016-01-14 15:38 ` Sinan Kaya
-1 siblings, 0 replies; 184+ messages in thread
From: Sinan Kaya @ 2016-01-14 15:38 UTC (permalink / raw)
To: Mark Salter, Tomasz Nowicki, bhelgaas, arnd, will.deacon,
catalin.marinas, rjw, hanjun.guo, Lorenzo.Pieralisi, jiang.liu,
Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm
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
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 15:38 ` Sinan Kaya
0 siblings, 0 replies; 184+ messages in thread
From: Sinan Kaya @ 2016-01-14 15:38 UTC (permalink / raw)
To: linux-arm-kernel
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 at 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
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 15:38 ` Sinan Kaya
@ 2016-01-14 16:12 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-14 16:12 UTC (permalink / raw)
To: Sinan Kaya
Cc: Mark Salter, Tomasz Nowicki, bhelgaas, arnd, will.deacon,
catalin.marinas, rjw, hanjun.guo, jiang.liu, Stefano.Stabellini,
robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm
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
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 16:12 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-14 16:12 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 16:12 ` Lorenzo Pieralisi
(?)
@ 2016-01-14 16:38 ` Mark Salter
-1 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 16:38 UTC (permalink / raw)
To: Lorenzo Pieralisi, Sinan Kaya
Cc: Tomasz Nowicki, bhelgaas, arnd, will.deacon, catalin.marinas,
rjw, hanjun.guo, jiang.liu, Stefano.Stabellini, robert.richter,
mw, Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 16:38 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 16:38 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 16:38 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 16:38 UTC (permalink / raw)
To: Lorenzo Pieralisi, Sinan Kaya
Cc: Tomasz Nowicki, bhelgaas, arnd, will.deacon, catalin.marinas,
rjw, hanjun.guo, jiang.liu, Stefano.Stabellini, robert.richter,
mw, Liviu.Dudau, ddaney, tglx, wangyijing, Suravee.Suthikulpanit,
linux-pci, linux-arm-kernel, linux-acpi, linux-kernel,
linaro-acpi, jchandra, jcm
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
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 16:38 ` Mark Salter
@ 2016-01-14 17:07 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-14 17:07 UTC (permalink / raw)
To: Mark Salter
Cc: Sinan Kaya, Tomasz Nowicki, bhelgaas, arnd, will.deacon,
catalin.marinas, rjw, hanjun.guo, jiang.liu, Stefano.Stabellini,
robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm
On Thu, Jan 14, 2016 at 11:38:44AM -0500, Mark Salter wrote:
[...]
> You would lose that bet. AddressMinimum/Maximum describe the
> PCI bus addresses.
In the mainline DT (APM Mustang), the CPU physical address corresponding
to IO space is 0xe010000000, PCI bus address is 0x0.
> QWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
> 0x0000000000000000, // Granularity
> 0x0000000010000000, // Range Minimum
> 0x000000001000FFFF, // Range Maximum
> 0x000000E000000000, // Translation Offset
See above, I will get the APM specifications to countercheck.
I agree with you we have to verify if this IO space limitation is
real or it is just an x86ism, in which case we remove that check.
Lorenzo
> 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
>
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 17:07 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-14 17:07 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 14, 2016 at 11:38:44AM -0500, Mark Salter wrote:
[...]
> You would lose that bet. AddressMinimum/Maximum describe the
> PCI bus addresses.
In the mainline DT (APM Mustang), the CPU physical address corresponding
to IO space is 0xe010000000, PCI bus address is 0x0.
> ? ? ? ? ? ? ? ? QWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
> ????????????????????0x0000000000000000, // Granularity
> ????????????????????0x0000000010000000, // Range Minimum
> ????????????????????0x000000001000FFFF, // Range Maximum
> ????????????????????0x000000E000000000, // Translation Offset
See above, I will get the APM specifications to countercheck.
I agree with you we have to verify if this IO space limitation is
real or it is just an x86ism, in which case we remove that check.
Lorenzo
> ????????????????????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
>
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 17:07 ` Lorenzo Pieralisi
@ 2016-01-14 17:32 ` Mark Salter
-1 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 17:32 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Sinan Kaya, Tomasz Nowicki, bhelgaas, arnd, will.deacon,
catalin.marinas, rjw, hanjun.guo, jiang.liu, Stefano.Stabellini,
robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm
On Thu, 2016-01-14 at 17:07 +0000, Lorenzo Pieralisi wrote:
> On Thu, Jan 14, 2016 at 11:38:44AM -0500, Mark Salter wrote:
>
> [...]
>
> > You would lose that bet. AddressMinimum/Maximum describe the
> > PCI bus addresses.
>
> In the mainline DT (APM Mustang), the CPU physical address corresponding
> to IO space is 0xe010000000, PCI bus address is 0x0.
>
> > QWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
> > 0x0000000000000000, // Granularity
> > 0x0000000010000000, // Range Minimum
>
>
> > 0x000000001000FFFF, // Range Maximum
> > 0x000000E000000000, // Translation Offset
>
> See above, I will get the APM specifications to countercheck.
The spec won't help other than to verify that the PCIe bridge supports a 32-bit
IO address space. The firmware sets the PCI bus base @ 0x10000000 with a CPU base
address for that window @ 0xe010000000. The pci-xgene.c driver sets the PCI
bus IO base address to whatever DT tells it too. For ACPI, we have to use whatever
the firmware set it to and described it in the ACPI table.
When I looked at this a while back, neither ACPI nor PCI had anything which
disallowed 32-bit IO space on the PCI bus. The 16-bit limit is an x86 limit
in the instruction set.
>
> I agree with you we have to verify if this IO space limitation is
> real or it is just an x86ism, in which case we remove that check.
>
> Lorenzo
> > 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
> >
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 17:32 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 17:32 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 2016-01-14 at 17:07 +0000, Lorenzo Pieralisi wrote:
> On Thu, Jan 14, 2016 at 11:38:44AM -0500, Mark Salter wrote:
>
> [...]
>
> > You would lose that bet. AddressMinimum/Maximum describe the
> > PCI bus addresses.
>
> In the mainline DT (APM Mustang), the CPU physical address corresponding
> to IO space is 0xe010000000, PCI bus address is 0x0.
>
> > ? ? ? ? ? ? ? ? QWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
> > ????????????????????0x0000000000000000, // Granularity
> > ????????????????????0x0000000010000000, // Range Minimum
>
>
> > ????????????????????0x000000001000FFFF, // Range Maximum
> > ????????????????????0x000000E000000000, // Translation Offset
>
> See above, I will get the APM specifications to countercheck.
The spec won't help other than to verify that the PCIe bridge supports a 32-bit
IO address space. The firmware sets the PCI bus base @ 0x10000000 with a CPU base
address for that window @ 0xe010000000. The pci-xgene.c driver sets the PCI
bus IO base address to whatever DT tells it too. For ACPI, we have to use whatever
the firmware set it to and described it in the ACPI table.
When I looked at this a while back, neither ACPI nor PCI had anything which
disallowed 32-bit IO space on the PCI bus. The 16-bit limit is an x86 limit
in the instruction set.
>
> I agree with you we have to verify if this IO space limitation is
> real or it is just an x86ism, in which case we remove that check.
>
> Lorenzo
> > ????????????????????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
> >
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 17:32 ` Mark Salter
(?)
@ 2016-01-14 17:59 ` Lorenzo Pieralisi
-1 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-14 17:59 UTC (permalink / raw)
To: Mark Salter
Cc: Sinan Kaya, Tomasz Nowicki, bhelgaas, arnd, will.deacon,
catalin.marinas, rjw, hanjun.guo, jiang.liu, Stefano.Stabellini,
robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm
On Thu, Jan 14, 2016 at 12:32:03PM -0500, Mark Salter wrote:
> On Thu, 2016-01-14 at 17:07 +0000, Lorenzo Pieralisi wrote:
> > On Thu, Jan 14, 2016 at 11:38:44AM -0500, Mark Salter wrote:
> >
> > [...]
> >
> > > You would lose that bet. AddressMinimum/Maximum describe the
> > > PCI bus addresses.
> >
> > In the mainline DT (APM Mustang), the CPU physical address corresponding
> > to IO space is 0xe010000000, PCI bus address is 0x0.
> >
> > > QWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
> > > 0x0000000000000000, // Granularity
> > > 0x0000000010000000, // Range Minimum
> >
> >
> > > 0x000000001000FFFF, // Range Maximum
> > > 0x000000E000000000, // Translation Offset
> >
> > See above, I will get the APM specifications to countercheck.
>
> The spec won't help other than to verify that the PCIe bridge supports
> a 32-bit IO address space. The firmware sets the PCI bus base @
> 0x10000000 with a CPU base address for that window @ 0xe010000000. The
> pci-xgene.c driver sets the PCI bus IO base address to whatever DT
> tells it too. For ACPI, we have to use whatever the firmware set it to
> and described it in the ACPI table.
It makes sense, thank you for clarifying (and sorry for jumping
to conclusions, I am a bit worried about the ACPI IO space descriptors
specification and usage on arm64).
> When I looked at this a while back, neither ACPI nor PCI had anything
> which disallowed 32-bit IO space on the PCI bus. The 16-bit limit is
> an x86 limit in the instruction set.
We should ask Jiang to remove that check or to make it x86 only (does
current mainline - where the offset is added to the resource start/end -
work on ia64 ?)
Thanks,
Lorenzo
>
> >
> > I agree with you we have to verify if this IO space limitation is
> > real or it is just an x86ism, in which case we remove that check.
> >
> > Lorenzo
> > > 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
> > >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 17:59 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-14 17:59 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Jan 14, 2016 at 12:32:03PM -0500, Mark Salter wrote:
> On Thu, 2016-01-14 at 17:07 +0000, Lorenzo Pieralisi wrote:
> > On Thu, Jan 14, 2016 at 11:38:44AM -0500, Mark Salter wrote:
> >
> > [...]
> >
> > > You would lose that bet. AddressMinimum/Maximum describe the
> > > PCI bus addresses.
> >
> > In the mainline DT (APM Mustang), the CPU physical address corresponding
> > to IO space is 0xe010000000, PCI bus address is 0x0.
> >
> > > ? ? ? ? ? ? ? ? QWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
> > > ????????????????????0x0000000000000000, // Granularity
> > > ????????????????????0x0000000010000000, // Range Minimum
> >
> >
> > > ????????????????????0x000000001000FFFF, // Range Maximum
> > > ????????????????????0x000000E000000000, // Translation Offset
> >
> > See above, I will get the APM specifications to countercheck.
>
> The spec won't help other than to verify that the PCIe bridge supports
> a 32-bit IO address space. The firmware sets the PCI bus base @
> 0x10000000 with a CPU base address for that window @ 0xe010000000. The
> pci-xgene.c driver sets the PCI bus IO base address to whatever DT
> tells it too. For ACPI, we have to use whatever the firmware set it to
> and described it in the ACPI table.
It makes sense, thank you for clarifying (and sorry for jumping
to conclusions, I am a bit worried about the ACPI IO space descriptors
specification and usage on arm64).
> When I looked at this a while back, neither ACPI nor PCI had anything
> which disallowed 32-bit IO space on the PCI bus. The 16-bit limit is
> an x86 limit in the instruction set.
We should ask Jiang to remove that check or to make it x86 only (does
current mainline - where the offset is added to the resource start/end -
work on ia64 ?)
Thanks,
Lorenzo
>
> >
> > I agree with you we have to verify if this IO space limitation is
> > real or it is just an x86ism, in which case we remove that check.
> >
> > Lorenzo
> > > ????????????????????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
> > >
>
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 17:59 ` Lorenzo Pieralisi
0 siblings, 0 replies; 184+ messages in thread
From: Lorenzo Pieralisi @ 2016-01-14 17:59 UTC (permalink / raw)
To: Mark Salter
Cc: Sinan Kaya, Tomasz Nowicki, bhelgaas, arnd, will.deacon,
catalin.marinas, rjw, hanjun.guo, jiang.liu, Stefano.Stabellini,
robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm
On Thu, Jan 14, 2016 at 12:32:03PM -0500, Mark Salter wrote:
> On Thu, 2016-01-14 at 17:07 +0000, Lorenzo Pieralisi wrote:
> > On Thu, Jan 14, 2016 at 11:38:44AM -0500, Mark Salter wrote:
> >
> > [...]
> >
> > > You would lose that bet. AddressMinimum/Maximum describe the
> > > PCI bus addresses.
> >
> > In the mainline DT (APM Mustang), the CPU physical address corresponding
> > to IO space is 0xe010000000, PCI bus address is 0x0.
> >
> > > QWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
> > > 0x0000000000000000, // Granularity
> > > 0x0000000010000000, // Range Minimum
> >
> >
> > > 0x000000001000FFFF, // Range Maximum
> > > 0x000000E000000000, // Translation Offset
> >
> > See above, I will get the APM specifications to countercheck.
>
> The spec won't help other than to verify that the PCIe bridge supports
> a 32-bit IO address space. The firmware sets the PCI bus base @
> 0x10000000 with a CPU base address for that window @ 0xe010000000. The
> pci-xgene.c driver sets the PCI bus IO base address to whatever DT
> tells it too. For ACPI, we have to use whatever the firmware set it to
> and described it in the ACPI table.
It makes sense, thank you for clarifying (and sorry for jumping
to conclusions, I am a bit worried about the ACPI IO space descriptors
specification and usage on arm64).
> When I looked at this a while back, neither ACPI nor PCI had anything
> which disallowed 32-bit IO space on the PCI bus. The 16-bit limit is
> an x86 limit in the instruction set.
We should ask Jiang to remove that check or to make it x86 only (does
current mainline - where the offset is added to the resource start/end -
work on ia64 ?)
Thanks,
Lorenzo
>
> >
> > I agree with you we have to verify if this IO space limitation is
> > real or it is just an x86ism, in which case we remove that check.
> >
> > Lorenzo
> > > 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
> > >
>
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 17:59 ` Lorenzo Pieralisi
@ 2016-01-14 18:44 ` Mark Salter
-1 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 18:44 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Sinan Kaya, Tomasz Nowicki, bhelgaas, arnd, will.deacon,
catalin.marinas, rjw, hanjun.guo, jiang.liu, Stefano.Stabellini,
robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, linux-pci, linux-arm-kernel, linux-acpi,
linux-kernel, linaro-acpi, jchandra, jcm
On Thu, 2016-01-14 at 17:59 +0000, Lorenzo Pieralisi wrote:
> On Thu, Jan 14, 2016 at 12:32:03PM -0500, Mark Salter wrote:
> > On Thu, 2016-01-14 at 17:07 +0000, Lorenzo Pieralisi wrote:
> > > On Thu, Jan 14, 2016 at 11:38:44AM -0500, Mark Salter wrote:
> > >
> > > [...]
> > >
> > > > You would lose that bet. AddressMinimum/Maximum describe the
> > > > PCI bus addresses.
> > >
> > > In the mainline DT (APM Mustang), the CPU physical address corresponding
> > > to IO space is 0xe010000000, PCI bus address is 0x0.
> > >
> > > > QWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
> > > > 0x0000000000000000, // Granularity
> > > > 0x0000000010000000, // Range Minimum
> > >
> > >
> > > > 0x000000001000FFFF, // Range Maximum
> > > > 0x000000E000000000, // Translation Offset
> > >
> > > See above, I will get the APM specifications to countercheck.
> >
> > The spec won't help other than to verify that the PCIe bridge supports
> > a 32-bit IO address space. The firmware sets the PCI bus base @
> > 0x10000000 with a CPU base address for that window @ 0xe010000000. The
> > pci-xgene.c driver sets the PCI bus IO base address to whatever DT
> > tells it too. For ACPI, we have to use whatever the firmware set it to
> > and described it in the ACPI table.
>
> It makes sense, thank you for clarifying (and sorry for jumping
> to conclusions, I am a bit worried about the ACPI IO space descriptors
> specification and usage on arm64).
>
> > When I looked at this a while back, neither ACPI nor PCI had anything
> > which disallowed 32-bit IO space on the PCI bus. The 16-bit limit is
> > an x86 limit in the instruction set.
>
> We should ask Jiang to remove that check or to make it x86 only (does
> current mainline - where the offset is added to the resource start/end -
> work on ia64 ?)
I think current mainline ia64 would work only for IO spaces which don't
exceed 64KiB in size. Otherwise it would trip on the same check disabling
Mustang IO space. ia64-specific code supports multiple IO spaces but they
all are expected to start at PCI bus address zero. At least my reading of
that code leads me to believe it is broken otherwise. In any case, those
IO spaces on the PCI bus could exceed 64K in size and any of those which do
would get caught by the 64K check in generic code and disabled.
>
> Thanks,
> Lorenzo
>
> >
> > >
> > > I agree with you we have to verify if this IO space limitation is
> > > real or it is just an x86ism, in which case we remove that check.
> > >
> > > Lorenzo
> > > > 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
> > > >
> >
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 18:44 ` Mark Salter
0 siblings, 0 replies; 184+ messages in thread
From: Mark Salter @ 2016-01-14 18:44 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, 2016-01-14 at 17:59 +0000, Lorenzo Pieralisi wrote:
> On Thu, Jan 14, 2016 at 12:32:03PM -0500, Mark Salter wrote:
> > On Thu, 2016-01-14 at 17:07 +0000, Lorenzo Pieralisi wrote:
> > > On Thu, Jan 14, 2016 at 11:38:44AM -0500, Mark Salter wrote:
> > >
> > > [...]
> > >
> > > > You would lose that bet. AddressMinimum/Maximum describe the
> > > > PCI bus addresses.
> > >
> > > In the mainline DT (APM Mustang), the CPU physical address corresponding
> > > to IO space is 0xe010000000, PCI bus address is 0x0.
> > >
> > > > ? ? ? ? ? ? ? ? QWordIO (ResourceProducer, MinFixed, MaxFixed, PosDecode, EntireRange,
> > > > ????????????????????0x0000000000000000, // Granularity
> > > > ????????????????????0x0000000010000000, // Range Minimum
> > >
> > >
> > > > ????????????????????0x000000001000FFFF, // Range Maximum
> > > > ????????????????????0x000000E000000000, // Translation Offset
> > >
> > > See above, I will get the APM specifications to countercheck.
> >
> > The spec won't help other than to verify that the PCIe bridge supports
> > a 32-bit IO address space. The firmware sets the PCI bus base @
> > 0x10000000 with a CPU base address for that window @ 0xe010000000. The
> > pci-xgene.c driver sets the PCI bus IO base address to whatever DT
> > tells it too. For ACPI, we have to use whatever the firmware set it to
> > and described it in the ACPI table.
>
> It makes sense, thank you for clarifying (and sorry for jumping
> to conclusions, I am a bit worried about the ACPI IO space descriptors
> specification and usage on arm64).
>
> > When I looked at this a while back, neither ACPI nor PCI had anything
> > which disallowed 32-bit IO space on the PCI bus. The 16-bit limit is
> > an x86 limit in the instruction set.
>
> We should ask Jiang to remove that check or to make it x86 only (does
> current mainline - where the offset is added to the resource start/end -
> work on ia64 ?)
I think current mainline ia64 would work only for IO spaces which don't
exceed 64KiB in size. Otherwise it would trip on the same check disabling
Mustang IO space. ia64-specific code supports multiple IO spaces but they
all are expected to start at PCI bus address zero. At least my reading of
that code leads me to believe it is broken otherwise. In any case, those
IO spaces on the PCI bus could exceed 64K in size and any of those which do
would get caught by the 64K check in generic code and disabled.
>
> Thanks,
> Lorenzo
>
> >
> > >
> > > I agree with you we have to verify if this IO space limitation is
> > > real or it is just an x86ism, in which case we remove that check.
> > >
> > > Lorenzo
> > > > ????????????????????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
> > > >
> >
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-14 15:29 ` Mark Salter
@ 2016-01-14 22:51 ` Jeremy Linton
-1 siblings, 0 replies; 184+ messages in thread
From: Jeremy Linton @ 2016-01-14 22:51 UTC (permalink / raw)
To: Mark Salter, Tomasz Nowicki, bhelgaas, arnd, will.deacon,
catalin.marinas, rjw, hanjun.guo, Lorenzo.Pieralisi, okaya,
jiang.liu, Stefano.Stabellini
Cc: jchandra, linaro-acpi, linux-pci, Liviu.Dudau, ddaney,
linux-kernel, linux-acpi, robert.richter, Suravee.Suthikulpanit,
jcm, wangyijing, tglx, mw, linux-arm-kernel
On 01/14/2016 09:29 AM, Mark Salter 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])
Juno is throwing "No Space" errors too with the following acpi definition.
DWordIo ( // IO window
ResourceProducer,
MinFixed,
MaxFixed,
PosDecode,
EntireRange,
0x00000000,// Granularity
0x00000000,// Min Base Address
0x007fffff,// Max Base Address
0x5f800000, // Translate
0x00800000, // Length
,
,
,
TypeTranslation
)
Although, my reading of the ACPI dword section is suspect...
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 22:51 ` Jeremy Linton
0 siblings, 0 replies; 184+ messages in thread
From: Jeremy Linton @ 2016-01-14 22:51 UTC (permalink / raw)
To: linux-arm-kernel
On 01/14/2016 09:29 AM, Mark Salter 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])
Juno is throwing "No Space" errors too with the following acpi definition.
DWordIo ( // IO window
ResourceProducer,
MinFixed,
MaxFixed,
PosDecode,
EntireRange,
0x00000000,// Granularity
0x00000000,// Min Base Address
0x007fffff,// Max Base Address
0x5f800000, // Translate
0x00800000, // Length
,
,
,
TypeTranslation
)
Although, my reading of the ACPI dword section is suspect...
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-14 22:55 ` Jeremy Linton
-1 siblings, 0 replies; 184+ messages in thread
From: Jeremy Linton @ 2016-01-14 22:55 UTC (permalink / raw)
To: Tomasz Nowicki, bhelgaas, arnd, will.deacon, catalin.marinas,
rjw, hanjun.guo, Lorenzo.Pieralisi, okaya, jiang.liu,
Stefano.Stabellini
Cc: jchandra, jcm, linaro-acpi, linux-pci, Liviu.Dudau, ddaney,
linux-kernel, linux-acpi, robert.richter, Suravee.Suthikulpanit,
msalter, wangyijing, tglx, mw, linux-arm-kernel
On 01/13/2016 07: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)
I boot tested this on JunoR2 with a recent build of Tianocore EDK2.
It works enough to boot the machine with PCIe attached sata, and
ethernet, but is throwing messages like:
[ 1.094643] pci 0000:00:00.0: BAR 13: no space for [io size 0x2000]
[ 1.101022] pci 0000:00:00.0: BAR 13: failed to assign [io size 0x2000]
Its also throwing:
[ 1.029958] pci 0000:00:00.0: of_irq_parse_pci() failed with rc=-22
[ 1.052784] pci 0000:00:00.0: of_irq_parse_pci() failed with rc=-22
(see other response for the DwordIo resource i'm using).
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-14 22:55 ` Jeremy Linton
0 siblings, 0 replies; 184+ messages in thread
From: Jeremy Linton @ 2016-01-14 22:55 UTC (permalink / raw)
To: linux-arm-kernel
On 01/13/2016 07: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 at github.com:semihalf-nowicki-tomasz/linux.git (pci-acpi-v3)
I boot tested this on JunoR2 with a recent build of Tianocore EDK2.
It works enough to boot the machine with PCIe attached sata, and
ethernet, but is throwing messages like:
[ 1.094643] pci 0000:00:00.0: BAR 13: no space for [io size 0x2000]
[ 1.101022] pci 0000:00:00.0: BAR 13: failed to assign [io size 0x2000]
Its also throwing:
[ 1.029958] pci 0000:00:00.0: of_irq_parse_pci() failed with rc=-22
[ 1.052784] pci 0000:00:00.0: of_irq_parse_pci() failed with rc=-22
(see other response for the DwordIo resource i'm using).
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-01-15 11:00 ` Hanjun Guo
-1 siblings, 0 replies; 184+ messages in thread
From: Hanjun Guo @ 2016-01-15 11:00 UTC (permalink / raw)
To: Tomasz Nowicki, bhelgaas, arnd, will.deacon, catalin.marinas,
rjw, Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm
On 2016/1/13 21:20, 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
Tested this patch set (and Matthew's) on a HP RX2660 IA64 machine,
with the CONFIG_ACPI_PCI_HOST_GENERIC disabled on IA64 ( it's a minor
comment needs to be addressed in my previous email), it can boot
the system ok with NIC working properly, with the /pro/ioports [1] and
the boot log [2] if anyone needs refer to it.
For this patch set, on IA64 machine,
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Thanks
Hanjun
[1]
node11:~ # cat /proc/ioports
000003c0-000003df : vga+
01000000-0100ffff : PCI Bus 0000:00
01001000-010010ff : 0000:00:03.0
02000000-0200ffff : PCI Bus 0000:01
02001000-020010ff : 0000:01:01.0
03000000-0300ffff : PCI Bus 0000:02
03001000-0300103f : 0000:02:01.1
03001040-0300107f : 0000:02:01.0
04000000-0400ffff : PCI Bus 0000:03
04001000-040010ff : 0000:03:01.1
04001100-040011ff : 0000:03:01.0
05000000-0500ffff : PCI Bus 0000:04
05001000-0500103f : 0000:04:01.1
05001040-0500107f : 0000:04:01.0
[2] boot log
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys cpuacct
Linux version 4.4.0.1-0.7-default (root@node11) (gcc version 4.3.4
[gcc-4_3-branch revision 152973] (SUSE Linux) ) #60 SMP Fri Jan 15
17:19:02 EST 2016
EFI v2.00 by HP:
efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fde6000 SMBIOS=0x3ee7c000
HCDP=0x3fde4000
booting generic kernel on platform hpzx1
PCDP: v3 at 0x3fde4000
PCDP: VGA console
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x000000003FDE6000 000028 (v02 HP )
ACPI: XSDT 0x000000003FDE602C 0000BC (v01 HP rx2660 00000000 HP
00000000)
ACPI: FACP 0x000000003FDF7268 0000F4 (v03 HP rx2660 00000000 HP
00000000)
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 32/16
(20150930/tbfadt-623)
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 32/16
(20150930/tbfadt-623)
ACPI: DSDT 0x000000003FDE61C8 00E566 (v01 HP rx2660 00000007 INTL
20050309)
ACPI: FACS 0x000000003FDF7360 000040
ACPI: SPCR 0x000000003FDF73A0 000050 (v01 HP 00000000 HP
00000000)
ACPI: DBGP 0x000000003FDF73F0 000034 (v01 HP rx2660 00000000 HP
00000000)
ACPI: APIC 0x000000003FDF7810 0000E8 (v01 HP rx2660 00000000 HP
00000000)
ACPI: SPMI 0x000000003FDF7428 000050 (v04 HP rx2660 00000000 HP
00000000)
ACPI: CPEP 0x000000003FDF76E0 000034 (v01 HP rx2660 00000000 HP
00000000)
ACPI: SSDT 0x000000003FDF4738 0004B3 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF4BF8 000456 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF5058 000866 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF58C8 000866 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF6138 000866 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF69A8 000138 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF6AE8 0000E0 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF6BD8 00013C (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF6D18 0000E0 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF6E08 00013C (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF6F48 0000E0 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF7038 00013C (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF7178 0000E0 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: Local APIC address c0000000fee00000
4 CPUs available, 8 CPUs total
SMP: Allowing 8 CPUs, 4 hotplug CPUs
Reserving 512MB of memory at 128MB for crashkernel (System RAM: 16347MB)
Initial ramdisk at: 0xe0000100fe2af000 (13610859 bytes)
SAL 3.20: HP version 4.11
SAL Platform features: None
SAL: AP wakeup using external interrupt vector 0xff
MCA related initialization done
Virtual mem_map starts at 0xa07fffffc7c80000
Zone ranges:
DMA [mem 0x0000000001000000-0x00000000ffffffff]
Normal [mem 0x0000000100000000-0x00000100ffffffff]
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x0000000001000000-0x000000003e67ffff]
node 0: [mem 0x000000003eaf0000-0x000000003ee6ffff]
node 0: [mem 0x000000003fc00000-0x000000003fd6ffff]
node 0: [mem 0x0000000100000000-0x00000003ffffffff]
node 0: [mem 0x0000010040000000-0x00000100ff1effff]
node 0: [mem 0x00000100ff200000-0x00000100ffffffff]
Initmem setup node 0 [mem 0x0000000001000000-0x00000100ffffffff]
On node 0 totalpages: 261558
free_area_init_node: node 0, pgdat e000000001a00000, node_mem_map
a07fffffc7c83800
DMA zone: 56 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 15799 pages, LIFO batch:1
Normal zone: 14336 pages used for memmap
Normal zone: 245759 pages, LIFO batch:1
pcpu-alloc: s33560 r8192 d220392 u262144 alloc=4*65536
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7
Built 1 zonelists in Node order, mobility grouping on. Total pages: 247166
Policy zone: Normal
Kernel command line:
BOOT_IMAGE=dev000:\efi\SuSE\vmlinuz-4.4.0.1-0.7-default
root=/dev/disk/by-id/scsi-35000cca00a9965f4-part2 splash=silent
crashkernel=1024M-:512M
PID hash table entries: 4096 (order: -1, 32768 bytes)
Sorting __ex_table...
Memory: 16146944K/16739712K available (10928K kernel code, 5820K rwdata,
1828K rodata, 1280K init, 8346K bss, 592768K reserved, 0K cma-reserved)
Hierarchical RCU implementation.
Build-time adjustment of leaf fanout to 64.
RCU restricting CPUs from NR_CPUS=4096 to nr_cpu_ids=8.
RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=8
NR_IRQS:1024
ACPI: Local APIC address c0000000fee00000
GSI 25 (level, low) -> CPU 0 (0x0000) vector 49
CPU 0: base freq=266.116MHz, ITC ratio=6/4, ITC freq=399.174MHz+/-150ppm
clocksource: itc: mask: 0xffffffffffffffff max_cycles: 0x5c0fd820f3,
max_idle_ns: 440795212316 ns
Console: colour VGA+ 80x25
console [tty0] enabled
Calibrating delay loop... 2834.43 BogoMIPS (lpj=5668864)
pid_max: default: 32768 minimum: 301
ACPI: Core revision 20150930
ACPI: 14 ACPI AML tables successfully acquired and loaded
Security Framework initialized
SELinux: Disabled at boot.
AppArmor: AppArmor disabled by boot time parameter
Dentry cache hash table entries: 2097152 (order: 8, 16777216 bytes)
Inode-cache hash table entries: 1048576 (order: 7, 8388608 bytes)
Mount-cache hash table entries: 32768 (order: 2, 262144 bytes)
Mountpoint-cache hash table entries: 32768 (order: 2, 262144 bytes)
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys net_cls
Boot processor id 0x0/0x0
Fixed BSP b0 value from CPU 1
CPU 1: synchronized ITC with CPU 0 (last diff -6 cycles, maxerr 172 cycles)
CPU 1: base freq=266.116MHz, ITC ratio=6/4, ITC freq=399.174MHz+/-150ppm
CPU 2: synchronized ITC with CPU 0 (last diff -6 cycles, maxerr 173 cycles)
CPU 2: base freq=266.116MHz, ITC ratio=6/4, ITC freq=399.174MHz+/-150ppm
CPU 3: synchronized ITC with CPU 0 (last diff -6 cycles, maxerr 173 cycles)
CPU 3: base freq=266.116MHz, ITC ratio=6/4, ITC freq=399.174MHz+/-150ppm
Brought up 4 CPUs
Total of 4 processors activated (11337.72 BogoMIPS).
devtmpfs: initialized
SMBIOS 2.4 present.
DMI: hp server rx2660 , BIOS 04.11
10/20/2008
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 7645041785100000 ns
NET: Registered protocol family 16
ACPI: bus type PCI registered
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
\_SB_:_OSC invalid UUID
_OSC request data:1 e
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOSAPIC for interrupt routing
ACPI: PCI Root Bridge [L000] (domain 0000 [bus 00])
acpi HWP0002:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments
MSI]
acpi HWP0002:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
debug: resource flag 0x200201, name PCI Bus 0000:00 with resouce
[0xff5e2000 - 0xff5e2007]
debug: resource flag 0x200105, name PCI Bus 0000:00 with resouce
[0x1000000 - 0x100ffff]debug: resource flag 0x200201, name PCI Bus
0000:00 with resouce [0xa0000 - 0xfffff]
debug: resource flag 0x200201, name PCI Bus 0000:00 with resouce
[0x80000000 - 0x8fffffff]debug: resource flag 0x200201, name PCI Bus
0000:00 with resouce [0x80004000000 - 0x800ffffffff]
acpi HWP0002:00: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x1000000-0x100ffff window] (bus
address [0x0000-0xffff])
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000fffff window]
pci_bus 0000:00: root bus resource [mem 0x80000000-0x8fffffff window]
pci_bus 0000:00: root bus resource [mem 0x80004000000-0x800ffffffff window]
pci_bus 0000:00: root bus resource [bus 00]
pci 0000:00:01.0: [103c:1303] type 00 class 0xff0000
pci 0000:00:01.1: [103c:1302] type 00 class 0x078000
pci 0000:00:01.1: reg 0x14: [mem 0x88034000-0x88034fff 64bit]
pci 0000:00:01.1: reg 0x1c: [mem 0x80080000000-0x8008001ffff 64bit pref]
pci 0000:00:01.2: [103c:1048] type 00 class 0x070002
pci 0000:00:01.2: reg 0x14: [mem 0x88033000-0x88033fff 64bit]
pci 0000:00:02.0: [1033:0035] type 00 class 0x0c0310
pci 0000:00:02.0: reg 0x10: [mem 0x88032000-0x88032fff]
pci 0000:00:02.0: supports D1 D2
pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
pci 0000:00:02.1: [1033:0035] type 00 class 0x0c0310
pci 0000:00:02.1: reg 0x10: [mem 0x88031000-0x88031fff]
pci 0000:00:02.1: supports D1 D2
pci 0000:00:02.1: PME# supported from D0 D1 D2 D3hot
pci 0000:00:02.2: [1033:00e0] type 00 class 0x0c0320
pci 0000:00:02.2: reg 0x10: [mem 0x88030000-0x880300ff]
pci 0000:00:02.2: supports D1 D2
pci 0000:00:02.2: PME# supported from D0 D1 D2 D3hot
pci 0000:00:03.0: [1002:515e] type 00 class 0x030000
pci 0000:00:03.0: reg 0x10: [mem 0x80000000-0x87ffffff pref]
pci 0000:00:03.0: reg 0x14: [io 0x1001000-0x10010ff]
pci 0000:00:03.0: reg 0x18: [mem 0x88020000-0x8802ffff]
pci 0000:00:03.0: reg 0x30: [mem 0x88000000-0x8801ffff pref]
pci 0000:00:03.0: supports D1 D2
ACPI: PCI Root Bridge [L002] (domain 0000 [bus 01])
acpi HWP0002:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments
MSI]
acpi HWP0002:01: _OSC failed (AE_NOT_FOUND); disabling ASPM
debug: resource flag 0x200105, name PCI Bus 0000:01 with resouce
[0x2000000 - 0x200ffff]
debug: resource flag 0x200201, name PCI Bus 0000:01 with resouce
[0xa0000000 - 0xafffffff]debug: resource flag 0x200201, name PCI Bus
0000:01 with resouce [0x80204000000 - 0x802ffffffff]
acpi HWP0002:01: PCI host bridge to bus 0000:01
pci_bus 0000:01: root bus resource [io 0x2000000-0x200ffff window] (bus
address [0x0000-0xffff])
pci_bus 0000:01: root bus resource [mem 0xa0000000-0xafffffff window]
pci_bus 0000:01: root bus resource [mem 0x80204000000-0x802ffffffff window]
pci_bus 0000:01: root bus resource [bus 01]
pci 0000:01:01.0: [1000:0054] type 00 class 0x010000
pci 0000:01:01.0: reg 0x10: [io 0x2001000-0x20010ff]
pci 0000:01:01.0: reg 0x14: [mem 0xa0470000-0xa0473fff 64bit]
pci 0000:01:01.0: reg 0x1c: [mem 0xa0460000-0xa046ffff 64bit]
pci 0000:01:01.0: reg 0x30: [mem 0xa0000000-0xa03fffff pref]
pci 0000:01:01.0: supports D1 D2
pci 0000:01:02.0: [14e4:1648] type 00 class 0x020000
pci 0000:01:02.0: reg 0x10: [mem 0xa0450000-0xa045ffff 64bit]
pci 0000:01:02.0: reg 0x30: [mem 0xa0420000-0xa043ffff pref]
pci 0000:01:02.0: PME# supported from D3hot D3cold
pci 0000:01:02.1: [14e4:1648] type 00 class 0x020000
pci 0000:01:02.1: reg 0x10: [mem 0xa0440000-0xa044ffff 64bit]
pci 0000:01:02.1: reg 0x30: [mem 0xa0400000-0xa041ffff pref]
pci 0000:01:02.1: PME# supported from D3hot D3cold
ACPI: PCI Root Bridge [L003] (domain 0000 [bus 02])
acpi HWP0002:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments
MSI]
acpi HWP0002:02: _OSC failed (AE_NOT_FOUND); disabling ASPM
debug: resource flag 0x200105, name PCI Bus 0000:02 with resouce
[0x3000000 - 0x300ffff]
debug: resource flag 0x200201, name PCI Bus 0000:02 with resouce
[0xb0000000 - 0xbfffffff]debug: resource flag 0x200201, name PCI Bus
0000:02 with resouce [0x80304000000 - 0x803ffffffff]
acpi HWP0002:02: PCI host bridge to bus 0000:02
pci_bus 0000:02: root bus resource [io 0x3000000-0x300ffff window] (bus
address [0x0000-0xffff])
pci_bus 0000:02: root bus resource [mem 0xb0000000-0xbfffffff window]
pci_bus 0000:02: root bus resource [mem 0x80304000000-0x803ffffffff window]
pci_bus 0000:02: root bus resource [bus 02]
pci 0000:02:01.0: [8086:1079] type 00 class 0x020000
pci 0000:02:01.0: reg 0x10: [mem 0xb0120000-0xb013ffff 64bit]
pci 0000:02:01.0: reg 0x18: [mem 0xb00c0000-0xb00fffff 64bit]
pci 0000:02:01.0: reg 0x20: [io 0x3001040-0x300107f]
pci 0000:02:01.0: reg 0x30: [mem 0xb0080000-0xb00bffff pref]
pci 0000:02:01.0: PME# supported from D0 D3hot
pci 0000:02:01.1: [8086:1079] type 00 class 0x020000
pci 0000:02:01.1: reg 0x10: [mem 0xb0100000-0xb011ffff 64bit]
pci 0000:02:01.1: reg 0x18: [mem 0xb0040000-0xb007ffff 64bit]
pci 0000:02:01.1: reg 0x20: [io 0x3001000-0x300103f]
pci 0000:02:01.1: reg 0x30: [mem 0xb0000000-0xb003ffff pref]
pci 0000:02:01.1: PME# supported from D0 D3hot
ACPI: PCI Root Bridge [L006] (domain 0000 [bus 03])
acpi HWP0002:03: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments
MSI]
acpi HWP0002:03: _OSC failed (AE_NOT_FOUND); disabling ASPM
debug: resource flag 0x200105, name PCI Bus 0000:03 with resouce
[0x4000000 - 0x400ffff]
debug: resource flag 0x200201, name PCI Bus 0000:03 with resouce
[0xe0000000 - 0xefffffff]debug: resource flag 0x200201, name PCI Bus
0000:03 with resouce [0x80604000000 - 0x806ffffffff]
acpi HWP0002:03: PCI host bridge to bus 0000:03
pci_bus 0000:03: root bus resource [io 0x4000000-0x400ffff window] (bus
address [0x0000-0xffff])
pci_bus 0000:03: root bus resource [mem 0xe0000000-0xefffffff window]
pci_bus 0000:03: root bus resource [mem 0x80604000000-0x806ffffffff window]
pci_bus 0000:03: root bus resource [bus 03]
pci 0000:03:01.0: [1000:0030] type 00 class 0x010000
pci 0000:03:01.0: reg 0x10: [io 0x4001100-0x40011ff]
pci 0000:03:01.0: reg 0x14: [mem 0xe0260000-0xe027ffff 64bit]
pci 0000:03:01.0: reg 0x1c: [mem 0xe0240000-0xe025ffff 64bit]
pci 0000:03:01.0: reg 0x30: [mem 0xe0100000-0xe01fffff pref]
pci 0000:03:01.0: supports D1 D2
pci 0000:03:01.1: [1000:0030] type 00 class 0x010000
pci 0000:03:01.1: reg 0x10: [io 0x4001000-0x40010ff]
pci 0000:03:01.1: reg 0x14: [mem 0xe0220000-0xe023ffff 64bit]
pci 0000:03:01.1: reg 0x1c: [mem 0xe0200000-0xe021ffff 64bit]
pci 0000:03:01.1: reg 0x30: [mem 0xe0000000-0xe00fffff pref]
pci 0000:03:01.1: supports D1 D2
ACPI: PCI Root Bridge [L007] (domain 0000 [bus 04])
acpi HWP0002:04: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments
MSI]
acpi HWP0002:04: _OSC failed (AE_NOT_FOUND); disabling ASPM
debug: resource flag 0x200105, name PCI Bus 0000:04 with resouce
[0x5000000 - 0x500ffff]
debug: resource flag 0x200201, name PCI Bus 0000:04 with resouce
[0xf0000000 - 0xfdffffff]debug: resource flag 0x200201, name PCI Bus
0000:04 with resouce [0x80704000000 - 0x807ffffffff]
acpi HWP0002:04: PCI host bridge to bus 0000:04
pci_bus 0000:04: root bus resource [io 0x5000000-0x500ffff window] (bus
address [0x0000-0xffff])
pci_bus 0000:04: root bus resource [mem 0xf0000000-0xfdffffff window]
pci_bus 0000:04: root bus resource [mem 0x80704000000-0x807ffffffff window]
pci_bus 0000:04: root bus resource [bus 04]
pci 0000:04:01.0: [8086:1079] type 00 class 0x020000
pci 0000:04:01.0: reg 0x10: [mem 0xf0120000-0xf013ffff 64bit]
pci 0000:04:01.0: reg 0x18: [mem 0xf00c0000-0xf00fffff 64bit]
pci 0000:04:01.0: reg 0x20: [io 0x5001040-0x500107f]
pci 0000:04:01.0: reg 0x30: [mem 0xf0080000-0xf00bffff pref]
pci 0000:04:01.0: PME# supported from D0 D3hot
pci 0000:04:01.1: [8086:1079] type 00 class 0x020000
pci 0000:04:01.1: reg 0x10: [mem 0xf0100000-0xf011ffff 64bit]
pci 0000:04:01.1: reg 0x18: [mem 0xf0040000-0xf007ffff 64bit]
pci 0000:04:01.1: reg 0x20: [io 0x5001000-0x500103f]
pci 0000:04:01.1: reg 0x30: [mem 0xf0000000-0xf003ffff pref]
pci 0000:04:01.1: PME# supported from D0 D3hot
ACPI: Enabled 2 GPEs in block 10 to 1F
vgaarb: setting as boot device: PCI:0000:00:03.0
vgaarb: device added: PCI:0000:00:03.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:00:03.0
IOC: zx2 2.0 HPA 0xfed01000 IOVA space 1024Mb at 0x40000000
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
clocksource: Switched to clocksource itc
pnp: PnP ACPI init
GSI 24 (level, low) -> CPU 1 (0x0200) vector 50
pnp 00:00: Plug and Play ACPI device, IDs PNP0501 (active)
pnp: PnP ACPI: found 1 devices
NET: Registered protocol family 2
TCP established hash table entries: 131072 (order: 4, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 4, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
UDP hash table entries: 8192 (order: 2, 262144 bytes)
UDP-Lite hash table entries: 8192 (order: 2, 262144 bytes)
NET: Registered protocol family 1
GSI 17 (level, low) -> CPU 2 (0x0400) vector 51
GSI 17 (level, low) -> CPU 2 (0x0400) vector 51 unregistered
GSI 18 (level, low) -> CPU 3 (0x0600) vector 51
GSI 18 (level, low) -> CPU 3 (0x0600) vector 51 unregistered
GSI 19 (level, low) -> CPU 0 (0x0000) vector 51
GSI 19 (level, low) -> CPU 0 (0x0000) vector 51 unregistered
pci 0000:00:03.0: Video device with shadowed ROM
PCI: CLS 128 bytes, default 128
Unpacking initramfs...
Freeing initrd memory: 13248kB freed
perfmon: version 2.0 IRQ 238
perfmon: Montecito PMU detected, 27 PMCs, 35 PMDs, 12 counters (47 bits)
PAL Information Facility v0.5
perfmon: added sampling format default_format
perfmon_default_smpl: default_format v2.0 registered
futex hash table entries: 2048 (order: 2, 262144 bytes)
audit: initializing netlink subsys (disabled)
audit: type=2000 audit(1452897622.516:1): initialized
HugeTLB registered 256 MB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.6.0
VFS: Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
00:00: ttyS0 at MMIO 0xff5e2000 (irq = 50, base_baud = 115200) is a 16550A
GSI 16 (level, low) -> CPU 1 (0x0200) vector 51
0000:00:01.2: ttyS1 at MMIO 0x88033000 (irq = 54, base_baud = 115200) is
a 16550A
EFI Time Services Driver v0.4
libphy: Fixed MDIO Bus: probed
mousedev: PS/2 mouse device common for all mice
EFI Variables Facility v0.08 2004-May-17
registered taskstats version 1
Freeing unused kernel memory: 1280K (e000000004d80000 - e000000004ec0000)
thermal LNXTHERM:00: registered as thermal_zone0
ACPI: Thermal Zone [THM0] (27 C)
SCSI subsystem initialized
Fusion MPT base driver 3.04.20
Copyright (c) 1999-2008 LSI Corporation
Fusion MPT SPI Host driver 3.04.20
GSI 49 (level, low) -> CPU 2 (0x0400) vector 52
mptbase: ioc0: Initiating bringup
ioc0: LSI53C1030 C0: Capabilities={Initiator,Target}
scsi host0: ioc0: LSI53C1030 C0, FwRev=01032346h, Ports=1, MaxQ=255, IRQ=55
GSI 50 (level, low) -> CPU 3 (0x0600) vector 53
mptbase: ioc1: Initiating bringup
ioc1: LSI53C1030 C0: Capabilities={Initiator,Target}
scsi host1: ioc1: LSI53C1030 C0, FwRev=01032346h, Ports=1, MaxQ=255, IRQ=56
random: nonblocking pool is initialized
Fusion MPT SAS Host driver 3.04.20
GSI 27 (level, low) -> CPU 0 (0x0000) vector 54
mptbase: ioc2: Initiating bringup
ioc2: LSISAS1068 B0: Capabilities={Initiator}
scsi host2: ioc2: LSISAS1068 B0, FwRev=01172a00h, Ports=1, MaxQ=163, IRQ=57
mptsas: ioc2: attaching ssp device: fw_channel 0, fw_id 8, phy 0,
sas_addr 0x5000cca00a9965f5
scsi 2:0:0:0: Direct-Access HP DG0146FARVU HPD6 PQ: 0 ANSI: 5
mptsas: ioc2: attaching ssp device: fw_channel 0, fw_id 7, phy 1,
sas_addr 0x5000cca00a99675d
scsi 2:0:1:0: Direct-Access HP DG0146FARVU HPD6 PQ: 0 ANSI: 5
udevd (181): /proc/181/oom_adj is deprecated, please use
/proc/181/oom_score_adj instead.
udevd version 128 started
sd 2:0:0:0: [sda] 286749488 512-byte logical blocks: (146 GB/136 GiB)
sd 2:0:1:0: [sdb] 286749488 512-byte logical blocks: (146 GB/136 GiB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: eb 00 10 08
sd 2:0:1:0: [sdb] Write Protect is off
sd 2:0:1:0: [sdb] Mode Sense: eb 00 10 08
sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports
DPO and FUA
sd 2:0:1:0: [sdb] Write cache: disabled, read cache: enabled, supports
DPO and FUA
sda: sda1 sda2
sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7
sd 2:0:0:0: [sda] Attached SCSI disk
sd 2:0:1:0: [sdb] Attached SCSI disk
EXT4-fs (sda2): mounting ext3 file system using the ext4 subsystem
EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts:
acl,user_xattr
EXT4-fs (sda2): re-mounted. Opts: acl,user_xattr
udevd version 128 started
ipmi message handler version 39.2
e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
e1000: Copyright (c) 1999-2006 Intel Corporation.
GSI 38 (level, low) -> CPU 1 (0x0200) vector 55
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
ACPI: Power Button [PWRF]
input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
ACPI: Sleep Button [SLPF]
e1000 0000:02:01.0 eth0: (PCI-X:133MHz:64-bit) 00:24:81:77:73:a4
e1000 0000:02:01.0 eth0: Intel(R) PRO/1000 Network Connection
GSI 39 (level, low) -> CPU 2 (0x0400) vector 56
ipmi_si IPI0001:00: ipmi_si: probing via ACPI
ipmi_si IPI0001:00: [mem 0xff5bc000-0xff5bc003] regsize 1 spacing 1 irq 0
ipmi_si: Adding ACPI-specified kcs state machine
IPMI System Interface driver.
ipmi_si: probing via SPMI
ipmi_si: SPMI: mem 0xff5bc000 regsize 1 spacing 1 irq 0
ipmi_si: Adding SPMI-specified kcs state machine duplicate interface
ipmi_si: Trying ACPI-specified kcs state machine at mem address
0xff5bc000, slave address 0x0, irq 0
e1000 0000:02:01.1 eth1: (PCI-X:133MHz:64-bit) 00:24:81:77:73:a5
e1000 0000:02:01.1 eth1: Intel(R) PRO/1000 Network Connection
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti
<giometti@linux.it>
Fusion MPT misc device (ioctl) driver 3.04.20
GSI 60 (level, low) -> CPU 3 (0x0600) vector 57
mptctl: Registered with Fusion MPT base driver
mptctl: /dev/mptctl @ (major,minor=10,220)
sd 2:0:0:0: Attached scsi generic sg0 type 0
sd 2:0:1:0: Attached scsi generic sg1 type 0
PTP clock support registered
ipmi_si IPI0001:00: Found new BMC (man_id: 0x00000b, prod_id: 0x8201,
dev_id: 0x32)
ipmi_si IPI0001:00: IPMI kcs interface initialized
ACPI: bus type USB registered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
tg3.c:v3.137 (May 11, 2014)
GSI 29 (level, low) -> CPU 0 (0x0000) vector 58
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
e1000 0000:04:01.0 eth2: (PCI-X:133MHz:64-bit) 00:24:81:77:75:70
e1000 0000:04:01.0 eth2: Intel(R) PRO/1000 Network Connection
GSI 61 (level, low) -> CPU 1 (0x0200) vector 59
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ehci-pci: EHCI PCI platform driver
GSI 19 (level, low) -> CPU 2 (0x0400) vector 60
ehci-pci 0000:00:02.2: EHCI Host Controller
ehci-pci 0000:00:02.2: new USB bus registered, assigned bus number 1
ehci-pci 0000:00:02.2: irq 53, io mem 0x88030000
ehci-pci 0000:00:02.2: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 4.4.0.1-0.7-default ehci_hcd
usb usb1: SerialNumber: 0000:00:02.2
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 5 ports detected
ohci-pci: OHCI PCI platform driver
GSI 17 (level, low) -> CPU 3 (0x0600) vector 61
ohci-pci 0000:00:02.0: OHCI PCI host controller
ohci-pci 0000:00:02.0: new USB bus registered, assigned bus number 2
ohci-pci 0000:00:02.0: irq 51, io mem 0x88032000
e1000 0000:04:01.1 eth3: (PCI-X:133MHz:64-bit) 00:24:81:77:75:71
e1000 0000:04:01.1 eth3: Intel(R) PRO/1000 Network Connection
e1000 0000:02:01.0 eth0_rename: renamed from eth0
usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OHCI PCI host controller
usb usb2: Manufacturer: Linux 4.4.0.1-0.7-default ohci_hcd
usb usb2: SerialNumber: 0000:00:02.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
GSI 18 (level, low) -> CPU 0 (0x0000) vector 62
ohci-pci 0000:00:02.1: OHCI PCI host controller
ohci-pci 0000:00:02.1: new USB bus registered, assigned bus number 3
ohci-pci 0000:00:02.1: irq 52, io mem 0x88031000
e1000 0000:02:01.1 eth1_rename: renamed from eth1
e1000 0000:04:01.1 eth5: renamed from eth3
e1000 0000:04:01.0 eth4: renamed from eth2
tg3 0000:01:02.0 eth0: Tigon3 [partno(BCM95700A6) rev 2100]
(PCIX:66MHz:64-bit) MAC address 00:22:64:94:09:3f
tg3 0000:01:02.0 eth0: attached PHY is 5704 (10/100/1000Base-T Ethernet)
(WireSpeed[1], EEE[0])
tg3 0000:01:02.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
tg3 0000:01:02.0 eth0: dma_rwctrl[769f0000] dma_mask[64-bit]
e1000 0000:02:01.1 eth3: renamed from eth1_rename
GSI 30 (level, low) -> CPU 1 (0x0200) vector 63
usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: OHCI PCI host controller
usb usb3: Manufacturer: Linux 4.4.0.1-0.7-default ohci_hcd
usb usb3: SerialNumber: 0000:00:02.1
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
e1000 0000:02:01.0 eth2: renamed from eth0_rename
tg3 0000:01:02.1 eth1: Tigon3 [partno(BCM95700A6) rev 2100]
(PCIX:66MHz:64-bit) MAC address 00:22:64:94:09:3e
tg3 0000:01:02.1 eth1: attached PHY is 5704 (10/100/1000Base-T Ethernet)
(WireSpeed[1], EEE[0])
tg3 0000:01:02.1 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
tg3 0000:01:02.1 eth1: dma_rwctrl[769f0000] dma_mask[64-bit]
usb 1-2: new high-speed USB device number 3 using ehci-pci
usb 2-1: new full-speed USB device number 2 using ohci-pci
Adding 2104448k swap on /dev/sdb2. Priority:-1 extents:1 across:2104448k
usb 1-2: New USB device found, idVendor=03f0, idProduct=0126
usb 1-2: New USB device strings: Mfr=51, Product=80, SerialNumber=67
usb 1-2: Product: INTEGRITY SERVER
usb 1-2: Manufacturer: HEWLETT PACKARD
usb 1-2: SerialNumber: A60020000001
usb 2-1: New USB device found, idVendor=03f0, idProduct=1126
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=63
usb 2-1: Product: Virtual Management Device
usb 2-1: Manufacturer: HP
usb 2-1: SerialNumber: 0022649407fa
hidraw: raw HID events driver (C) Jiri Kosina
usb-storage 1-2:1.0: USB Mass Storage device detected
scsi host3: usb-storage 1-2:1.0
usbcore: registered new interface driver usb-storage
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usb 3-2: new low-speed USB device number 2 using ohci-pci
input: HP Virtual Management Device as
/devices/LNXSYSTM:00/LNXSYBUS:00/HWP0001:00/HWP0002:00/pci0000:00/0000:00:02.0/usb2/2-1/2-1:1.0/0003:03F0:1126.0001/input/input2
hid-generic 0003:03F0:1126.0001: input,hidraw0: USB HID v1.11 Keyboard
[HP Virtual Management Device] on usb-0000:00:02.0-1/input0
input: HP Virtual Management Device as
/devices/LNXSYSTM:00/LNXSYBUS:00/HWP0001:00/HWP0002:00/pci0000:00/0000:00:02.0/usb2/2-1/2-1:1.1/0003:03F0:1126.0002/input/input3
hid-generic 0003:03F0:1126.0002: input,hidraw1: USB HID v1.01 Mouse [HP
Virtual Management Device] on usb-0000:00:02.0-1/input1
usb 3-2: New USB device found, idVendor=0557, idProduct=2221
usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-2: Product: UC-10KM V1.3.121
usb 3-2: Manufacturer: ATEN
usb 3-2: SerialNumber: USB Composite device
input: ATEN UC-10KM V1.3.121 as
/devices/LNXSYSTM:00/LNXSYBUS:00/HWP0001:00/HWP0002:00/pci0000:00/0000:00:02.1/usb3/3-2/3-2:1.0/0003:0557:2221.0003/input/input4
hid-generic 0003:0557:2221.0003: input,hidraw2: USB HID v1.10 Keyboard
[ATEN UC-10KM V1.3.121] on usb-0000:00:02.1-2/input0
input: ATEN UC-10KM V1.3.121 as
/devices/LNXSYSTM:00/LNXSYBUS:00/HWP0001:00/HWP0002:00/pci0000:00/0000:00:02.1/usb3/3-2/3-2:1.1/0003:0557:2221.0004/input/input5
hid-generic 0003:0557:2221.0004: input,hidraw3: USB HID v1.10 Mouse
[ATEN UC-10KM V1.3.121] on usb-0000:00:02.1-2/input1
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.34.0-ioctl (2015-10-28) initialised:
dm-devel@redhat.com
loop: module loaded
scsi 3:0:0:0: CD-ROM TEAC DVD-ROM DW-224EV K.DA PQ: 0 ANSI: 0
scsi 3:0:0:0: Attached scsi generic sg2 type 5
sr 3:0:0:0: [sr0] scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda tray
cdrom: Uniform CD-ROM driver Revision: 3.20
sr 3:0:0:0: Attached scsi CD-ROM sr0
fuse init (API version 7.23)
ip_local_port_range: prefer different parity for start/end values.
hangcheck_timer: disagrees about version of symbol module_layout
tg3 0000:01:02.0 eth0: Link is up at 1000 Mbps, full duplex
tg3 0000:01:02.0 eth0: Flow control is off for TX and off for RX
NET: Registered protocol family 10
IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
tg3 0000:01:02.1 eth1: Link is up at 1000 Mbps, full duplex
tg3 0000:01:02.1 eth1: Flow control is off for TX and off for RX
IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: starting 90-second grace period (net a0000001014af100)
GSI 20 (level, low) -> CPU 2 (0x0400) vector 64
gnome-settings-(4170): floating-point assist fault at ip
2000000006b7bdc2, isr 0000020000001001
gnome-settings-(4170): floating-point assist fault at ip
2000000006b7bdc2, isr 0000020000001001
gnome-settings-(4170): floating-point assist fault at ip
2000000006b7bdc2, isr 0000020000001001
gnome-settings-(4170): floating-point assist fault at ip
2000000006b7bdc2, isr 0000020000001001
gnome-settings-(4170): floating-point assist fault at ip
2000000006b7bdc2, isr 0000020000001001
gdm-simple-gree(4179): unaligned access to 0x600fffffffadf34c,
ip=0x20000000012216a0
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-15 11:00 ` Hanjun Guo
0 siblings, 0 replies; 184+ messages in thread
From: Hanjun Guo @ 2016-01-15 11:00 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/13 21:20, 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 at 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
Tested this patch set (and Matthew's) on a HP RX2660 IA64 machine,
with the CONFIG_ACPI_PCI_HOST_GENERIC disabled on IA64 ( it's a minor
comment needs to be addressed in my previous email), it can boot
the system ok with NIC working properly, with the /pro/ioports [1] and
the boot log [2] if anyone needs refer to it.
For this patch set, on IA64 machine,
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Thanks
Hanjun
[1]
node11:~ # cat /proc/ioports
000003c0-000003df : vga+
01000000-0100ffff : PCI Bus 0000:00
01001000-010010ff : 0000:00:03.0
02000000-0200ffff : PCI Bus 0000:01
02001000-020010ff : 0000:01:01.0
03000000-0300ffff : PCI Bus 0000:02
03001000-0300103f : 0000:02:01.1
03001040-0300107f : 0000:02:01.0
04000000-0400ffff : PCI Bus 0000:03
04001000-040010ff : 0000:03:01.1
04001100-040011ff : 0000:03:01.0
05000000-0500ffff : PCI Bus 0000:04
05001000-0500103f : 0000:04:01.1
05001040-0500107f : 0000:04:01.0
[2] boot log
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys cpuacct
Linux version 4.4.0.1-0.7-default (root at node11) (gcc version 4.3.4
[gcc-4_3-branch revision 152973] (SUSE Linux) ) #60 SMP Fri Jan 15
17:19:02 EST 2016
EFI v2.00 by HP:
efi: SALsystab=0x3ee7a000 ACPI 2.0=0x3fde6000 SMBIOS=0x3ee7c000
HCDP=0x3fde4000
booting generic kernel on platform hpzx1
PCDP: v3 at 0x3fde4000
PCDP: VGA console
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x000000003FDE6000 000028 (v02 HP )
ACPI: XSDT 0x000000003FDE602C 0000BC (v01 HP rx2660 00000000 HP
00000000)
ACPI: FACP 0x000000003FDF7268 0000F4 (v03 HP rx2660 00000000 HP
00000000)
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 32/16
(20150930/tbfadt-623)
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 32/16
(20150930/tbfadt-623)
ACPI: DSDT 0x000000003FDE61C8 00E566 (v01 HP rx2660 00000007 INTL
20050309)
ACPI: FACS 0x000000003FDF7360 000040
ACPI: SPCR 0x000000003FDF73A0 000050 (v01 HP 00000000 HP
00000000)
ACPI: DBGP 0x000000003FDF73F0 000034 (v01 HP rx2660 00000000 HP
00000000)
ACPI: APIC 0x000000003FDF7810 0000E8 (v01 HP rx2660 00000000 HP
00000000)
ACPI: SPMI 0x000000003FDF7428 000050 (v04 HP rx2660 00000000 HP
00000000)
ACPI: CPEP 0x000000003FDF76E0 000034 (v01 HP rx2660 00000000 HP
00000000)
ACPI: SSDT 0x000000003FDF4738 0004B3 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF4BF8 000456 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF5058 000866 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF58C8 000866 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF6138 000866 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF69A8 000138 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF6AE8 0000E0 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF6BD8 00013C (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF6D18 0000E0 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF6E08 00013C (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF6F48 0000E0 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF7038 00013C (v01 HP rx2660 00000006 INTL
20050309)
ACPI: SSDT 0x000000003FDF7178 0000E0 (v01 HP rx2660 00000006 INTL
20050309)
ACPI: Local APIC address c0000000fee00000
4 CPUs available, 8 CPUs total
SMP: Allowing 8 CPUs, 4 hotplug CPUs
Reserving 512MB of memory at 128MB for crashkernel (System RAM: 16347MB)
Initial ramdisk at: 0xe0000100fe2af000 (13610859 bytes)
SAL 3.20: HP version 4.11
SAL Platform features: None
SAL: AP wakeup using external interrupt vector 0xff
MCA related initialization done
Virtual mem_map starts at 0xa07fffffc7c80000
Zone ranges:
DMA [mem 0x0000000001000000-0x00000000ffffffff]
Normal [mem 0x0000000100000000-0x00000100ffffffff]
Movable zone start for each node
Early memory node ranges
node 0: [mem 0x0000000001000000-0x000000003e67ffff]
node 0: [mem 0x000000003eaf0000-0x000000003ee6ffff]
node 0: [mem 0x000000003fc00000-0x000000003fd6ffff]
node 0: [mem 0x0000000100000000-0x00000003ffffffff]
node 0: [mem 0x0000010040000000-0x00000100ff1effff]
node 0: [mem 0x00000100ff200000-0x00000100ffffffff]
Initmem setup node 0 [mem 0x0000000001000000-0x00000100ffffffff]
On node 0 totalpages: 261558
free_area_init_node: node 0, pgdat e000000001a00000, node_mem_map
a07fffffc7c83800
DMA zone: 56 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 15799 pages, LIFO batch:1
Normal zone: 14336 pages used for memmap
Normal zone: 245759 pages, LIFO batch:1
pcpu-alloc: s33560 r8192 d220392 u262144 alloc=4*65536
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7
Built 1 zonelists in Node order, mobility grouping on. Total pages: 247166
Policy zone: Normal
Kernel command line:
BOOT_IMAGE=dev000:\efi\SuSE\vmlinuz-4.4.0.1-0.7-default
root=/dev/disk/by-id/scsi-35000cca00a9965f4-part2 splash=silent
crashkernel=1024M-:512M
PID hash table entries: 4096 (order: -1, 32768 bytes)
Sorting __ex_table...
Memory: 16146944K/16739712K available (10928K kernel code, 5820K rwdata,
1828K rodata, 1280K init, 8346K bss, 592768K reserved, 0K cma-reserved)
Hierarchical RCU implementation.
Build-time adjustment of leaf fanout to 64.
RCU restricting CPUs from NR_CPUS=4096 to nr_cpu_ids=8.
RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=8
NR_IRQS:1024
ACPI: Local APIC address c0000000fee00000
GSI 25 (level, low) -> CPU 0 (0x0000) vector 49
CPU 0: base freq=266.116MHz, ITC ratio=6/4, ITC freq=399.174MHz+/-150ppm
clocksource: itc: mask: 0xffffffffffffffff max_cycles: 0x5c0fd820f3,
max_idle_ns: 440795212316 ns
Console: colour VGA+ 80x25
console [tty0] enabled
Calibrating delay loop... 2834.43 BogoMIPS (lpj=5668864)
pid_max: default: 32768 minimum: 301
ACPI: Core revision 20150930
ACPI: 14 ACPI AML tables successfully acquired and loaded
Security Framework initialized
SELinux: Disabled at boot.
AppArmor: AppArmor disabled by boot time parameter
Dentry cache hash table entries: 2097152 (order: 8, 16777216 bytes)
Inode-cache hash table entries: 1048576 (order: 7, 8388608 bytes)
Mount-cache hash table entries: 32768 (order: 2, 262144 bytes)
Mountpoint-cache hash table entries: 32768 (order: 2, 262144 bytes)
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
Initializing cgroup subsys net_cls
Boot processor id 0x0/0x0
Fixed BSP b0 value from CPU 1
CPU 1: synchronized ITC with CPU 0 (last diff -6 cycles, maxerr 172 cycles)
CPU 1: base freq=266.116MHz, ITC ratio=6/4, ITC freq=399.174MHz+/-150ppm
CPU 2: synchronized ITC with CPU 0 (last diff -6 cycles, maxerr 173 cycles)
CPU 2: base freq=266.116MHz, ITC ratio=6/4, ITC freq=399.174MHz+/-150ppm
CPU 3: synchronized ITC with CPU 0 (last diff -6 cycles, maxerr 173 cycles)
CPU 3: base freq=266.116MHz, ITC ratio=6/4, ITC freq=399.174MHz+/-150ppm
Brought up 4 CPUs
Total of 4 processors activated (11337.72 BogoMIPS).
devtmpfs: initialized
SMBIOS 2.4 present.
DMI: hp server rx2660 , BIOS 04.11
10/20/2008
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 7645041785100000 ns
NET: Registered protocol family 16
ACPI: bus type PCI registered
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
\_SB_:_OSC invalid UUID
_OSC request data:1 e
ACPI: Interpreter enabled
ACPI: (supports S0 S5)
ACPI: Using IOSAPIC for interrupt routing
ACPI: PCI Root Bridge [L000] (domain 0000 [bus 00])
acpi HWP0002:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments
MSI]
acpi HWP0002:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
debug: resource flag 0x200201, name PCI Bus 0000:00 with resouce
[0xff5e2000 - 0xff5e2007]
debug: resource flag 0x200105, name PCI Bus 0000:00 with resouce
[0x1000000 - 0x100ffff]debug: resource flag 0x200201, name PCI Bus
0000:00 with resouce [0xa0000 - 0xfffff]
debug: resource flag 0x200201, name PCI Bus 0000:00 with resouce
[0x80000000 - 0x8fffffff]debug: resource flag 0x200201, name PCI Bus
0000:00 with resouce [0x80004000000 - 0x800ffffffff]
acpi HWP0002:00: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0x1000000-0x100ffff window] (bus
address [0x0000-0xffff])
pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000fffff window]
pci_bus 0000:00: root bus resource [mem 0x80000000-0x8fffffff window]
pci_bus 0000:00: root bus resource [mem 0x80004000000-0x800ffffffff window]
pci_bus 0000:00: root bus resource [bus 00]
pci 0000:00:01.0: [103c:1303] type 00 class 0xff0000
pci 0000:00:01.1: [103c:1302] type 00 class 0x078000
pci 0000:00:01.1: reg 0x14: [mem 0x88034000-0x88034fff 64bit]
pci 0000:00:01.1: reg 0x1c: [mem 0x80080000000-0x8008001ffff 64bit pref]
pci 0000:00:01.2: [103c:1048] type 00 class 0x070002
pci 0000:00:01.2: reg 0x14: [mem 0x88033000-0x88033fff 64bit]
pci 0000:00:02.0: [1033:0035] type 00 class 0x0c0310
pci 0000:00:02.0: reg 0x10: [mem 0x88032000-0x88032fff]
pci 0000:00:02.0: supports D1 D2
pci 0000:00:02.0: PME# supported from D0 D1 D2 D3hot
pci 0000:00:02.1: [1033:0035] type 00 class 0x0c0310
pci 0000:00:02.1: reg 0x10: [mem 0x88031000-0x88031fff]
pci 0000:00:02.1: supports D1 D2
pci 0000:00:02.1: PME# supported from D0 D1 D2 D3hot
pci 0000:00:02.2: [1033:00e0] type 00 class 0x0c0320
pci 0000:00:02.2: reg 0x10: [mem 0x88030000-0x880300ff]
pci 0000:00:02.2: supports D1 D2
pci 0000:00:02.2: PME# supported from D0 D1 D2 D3hot
pci 0000:00:03.0: [1002:515e] type 00 class 0x030000
pci 0000:00:03.0: reg 0x10: [mem 0x80000000-0x87ffffff pref]
pci 0000:00:03.0: reg 0x14: [io 0x1001000-0x10010ff]
pci 0000:00:03.0: reg 0x18: [mem 0x88020000-0x8802ffff]
pci 0000:00:03.0: reg 0x30: [mem 0x88000000-0x8801ffff pref]
pci 0000:00:03.0: supports D1 D2
ACPI: PCI Root Bridge [L002] (domain 0000 [bus 01])
acpi HWP0002:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments
MSI]
acpi HWP0002:01: _OSC failed (AE_NOT_FOUND); disabling ASPM
debug: resource flag 0x200105, name PCI Bus 0000:01 with resouce
[0x2000000 - 0x200ffff]
debug: resource flag 0x200201, name PCI Bus 0000:01 with resouce
[0xa0000000 - 0xafffffff]debug: resource flag 0x200201, name PCI Bus
0000:01 with resouce [0x80204000000 - 0x802ffffffff]
acpi HWP0002:01: PCI host bridge to bus 0000:01
pci_bus 0000:01: root bus resource [io 0x2000000-0x200ffff window] (bus
address [0x0000-0xffff])
pci_bus 0000:01: root bus resource [mem 0xa0000000-0xafffffff window]
pci_bus 0000:01: root bus resource [mem 0x80204000000-0x802ffffffff window]
pci_bus 0000:01: root bus resource [bus 01]
pci 0000:01:01.0: [1000:0054] type 00 class 0x010000
pci 0000:01:01.0: reg 0x10: [io 0x2001000-0x20010ff]
pci 0000:01:01.0: reg 0x14: [mem 0xa0470000-0xa0473fff 64bit]
pci 0000:01:01.0: reg 0x1c: [mem 0xa0460000-0xa046ffff 64bit]
pci 0000:01:01.0: reg 0x30: [mem 0xa0000000-0xa03fffff pref]
pci 0000:01:01.0: supports D1 D2
pci 0000:01:02.0: [14e4:1648] type 00 class 0x020000
pci 0000:01:02.0: reg 0x10: [mem 0xa0450000-0xa045ffff 64bit]
pci 0000:01:02.0: reg 0x30: [mem 0xa0420000-0xa043ffff pref]
pci 0000:01:02.0: PME# supported from D3hot D3cold
pci 0000:01:02.1: [14e4:1648] type 00 class 0x020000
pci 0000:01:02.1: reg 0x10: [mem 0xa0440000-0xa044ffff 64bit]
pci 0000:01:02.1: reg 0x30: [mem 0xa0400000-0xa041ffff pref]
pci 0000:01:02.1: PME# supported from D3hot D3cold
ACPI: PCI Root Bridge [L003] (domain 0000 [bus 02])
acpi HWP0002:02: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments
MSI]
acpi HWP0002:02: _OSC failed (AE_NOT_FOUND); disabling ASPM
debug: resource flag 0x200105, name PCI Bus 0000:02 with resouce
[0x3000000 - 0x300ffff]
debug: resource flag 0x200201, name PCI Bus 0000:02 with resouce
[0xb0000000 - 0xbfffffff]debug: resource flag 0x200201, name PCI Bus
0000:02 with resouce [0x80304000000 - 0x803ffffffff]
acpi HWP0002:02: PCI host bridge to bus 0000:02
pci_bus 0000:02: root bus resource [io 0x3000000-0x300ffff window] (bus
address [0x0000-0xffff])
pci_bus 0000:02: root bus resource [mem 0xb0000000-0xbfffffff window]
pci_bus 0000:02: root bus resource [mem 0x80304000000-0x803ffffffff window]
pci_bus 0000:02: root bus resource [bus 02]
pci 0000:02:01.0: [8086:1079] type 00 class 0x020000
pci 0000:02:01.0: reg 0x10: [mem 0xb0120000-0xb013ffff 64bit]
pci 0000:02:01.0: reg 0x18: [mem 0xb00c0000-0xb00fffff 64bit]
pci 0000:02:01.0: reg 0x20: [io 0x3001040-0x300107f]
pci 0000:02:01.0: reg 0x30: [mem 0xb0080000-0xb00bffff pref]
pci 0000:02:01.0: PME# supported from D0 D3hot
pci 0000:02:01.1: [8086:1079] type 00 class 0x020000
pci 0000:02:01.1: reg 0x10: [mem 0xb0100000-0xb011ffff 64bit]
pci 0000:02:01.1: reg 0x18: [mem 0xb0040000-0xb007ffff 64bit]
pci 0000:02:01.1: reg 0x20: [io 0x3001000-0x300103f]
pci 0000:02:01.1: reg 0x30: [mem 0xb0000000-0xb003ffff pref]
pci 0000:02:01.1: PME# supported from D0 D3hot
ACPI: PCI Root Bridge [L006] (domain 0000 [bus 03])
acpi HWP0002:03: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments
MSI]
acpi HWP0002:03: _OSC failed (AE_NOT_FOUND); disabling ASPM
debug: resource flag 0x200105, name PCI Bus 0000:03 with resouce
[0x4000000 - 0x400ffff]
debug: resource flag 0x200201, name PCI Bus 0000:03 with resouce
[0xe0000000 - 0xefffffff]debug: resource flag 0x200201, name PCI Bus
0000:03 with resouce [0x80604000000 - 0x806ffffffff]
acpi HWP0002:03: PCI host bridge to bus 0000:03
pci_bus 0000:03: root bus resource [io 0x4000000-0x400ffff window] (bus
address [0x0000-0xffff])
pci_bus 0000:03: root bus resource [mem 0xe0000000-0xefffffff window]
pci_bus 0000:03: root bus resource [mem 0x80604000000-0x806ffffffff window]
pci_bus 0000:03: root bus resource [bus 03]
pci 0000:03:01.0: [1000:0030] type 00 class 0x010000
pci 0000:03:01.0: reg 0x10: [io 0x4001100-0x40011ff]
pci 0000:03:01.0: reg 0x14: [mem 0xe0260000-0xe027ffff 64bit]
pci 0000:03:01.0: reg 0x1c: [mem 0xe0240000-0xe025ffff 64bit]
pci 0000:03:01.0: reg 0x30: [mem 0xe0100000-0xe01fffff pref]
pci 0000:03:01.0: supports D1 D2
pci 0000:03:01.1: [1000:0030] type 00 class 0x010000
pci 0000:03:01.1: reg 0x10: [io 0x4001000-0x40010ff]
pci 0000:03:01.1: reg 0x14: [mem 0xe0220000-0xe023ffff 64bit]
pci 0000:03:01.1: reg 0x1c: [mem 0xe0200000-0xe021ffff 64bit]
pci 0000:03:01.1: reg 0x30: [mem 0xe0000000-0xe00fffff pref]
pci 0000:03:01.1: supports D1 D2
ACPI: PCI Root Bridge [L007] (domain 0000 [bus 04])
acpi HWP0002:04: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments
MSI]
acpi HWP0002:04: _OSC failed (AE_NOT_FOUND); disabling ASPM
debug: resource flag 0x200105, name PCI Bus 0000:04 with resouce
[0x5000000 - 0x500ffff]
debug: resource flag 0x200201, name PCI Bus 0000:04 with resouce
[0xf0000000 - 0xfdffffff]debug: resource flag 0x200201, name PCI Bus
0000:04 with resouce [0x80704000000 - 0x807ffffffff]
acpi HWP0002:04: PCI host bridge to bus 0000:04
pci_bus 0000:04: root bus resource [io 0x5000000-0x500ffff window] (bus
address [0x0000-0xffff])
pci_bus 0000:04: root bus resource [mem 0xf0000000-0xfdffffff window]
pci_bus 0000:04: root bus resource [mem 0x80704000000-0x807ffffffff window]
pci_bus 0000:04: root bus resource [bus 04]
pci 0000:04:01.0: [8086:1079] type 00 class 0x020000
pci 0000:04:01.0: reg 0x10: [mem 0xf0120000-0xf013ffff 64bit]
pci 0000:04:01.0: reg 0x18: [mem 0xf00c0000-0xf00fffff 64bit]
pci 0000:04:01.0: reg 0x20: [io 0x5001040-0x500107f]
pci 0000:04:01.0: reg 0x30: [mem 0xf0080000-0xf00bffff pref]
pci 0000:04:01.0: PME# supported from D0 D3hot
pci 0000:04:01.1: [8086:1079] type 00 class 0x020000
pci 0000:04:01.1: reg 0x10: [mem 0xf0100000-0xf011ffff 64bit]
pci 0000:04:01.1: reg 0x18: [mem 0xf0040000-0xf007ffff 64bit]
pci 0000:04:01.1: reg 0x20: [io 0x5001000-0x500103f]
pci 0000:04:01.1: reg 0x30: [mem 0xf0000000-0xf003ffff pref]
pci 0000:04:01.1: PME# supported from D0 D3hot
ACPI: Enabled 2 GPEs in block 10 to 1F
vgaarb: setting as boot device: PCI:0000:00:03.0
vgaarb: device added: PCI:0000:00:03.0,decodes=io+mem,owns=io+mem,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:00:03.0
IOC: zx2 2.0 HPA 0xfed01000 IOVA space 1024Mb at 0x40000000
NetLabel: Initializing
NetLabel: domain hash size = 128
NetLabel: protocols = UNLABELED CIPSOv4
NetLabel: unlabeled traffic allowed by default
clocksource: Switched to clocksource itc
pnp: PnP ACPI init
GSI 24 (level, low) -> CPU 1 (0x0200) vector 50
pnp 00:00: Plug and Play ACPI device, IDs PNP0501 (active)
pnp: PnP ACPI: found 1 devices
NET: Registered protocol family 2
TCP established hash table entries: 131072 (order: 4, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 4, 1048576 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
UDP hash table entries: 8192 (order: 2, 262144 bytes)
UDP-Lite hash table entries: 8192 (order: 2, 262144 bytes)
NET: Registered protocol family 1
GSI 17 (level, low) -> CPU 2 (0x0400) vector 51
GSI 17 (level, low) -> CPU 2 (0x0400) vector 51 unregistered
GSI 18 (level, low) -> CPU 3 (0x0600) vector 51
GSI 18 (level, low) -> CPU 3 (0x0600) vector 51 unregistered
GSI 19 (level, low) -> CPU 0 (0x0000) vector 51
GSI 19 (level, low) -> CPU 0 (0x0000) vector 51 unregistered
pci 0000:00:03.0: Video device with shadowed ROM
PCI: CLS 128 bytes, default 128
Unpacking initramfs...
Freeing initrd memory: 13248kB freed
perfmon: version 2.0 IRQ 238
perfmon: Montecito PMU detected, 27 PMCs, 35 PMDs, 12 counters (47 bits)
PAL Information Facility v0.5
perfmon: added sampling format default_format
perfmon_default_smpl: default_format v2.0 registered
futex hash table entries: 2048 (order: 2, 262144 bytes)
audit: initializing netlink subsys (disabled)
audit: type=2000 audit(1452897622.516:1): initialized
HugeTLB registered 256 MB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.6.0
VFS: Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
00:00: ttyS0 at MMIO 0xff5e2000 (irq = 50, base_baud = 115200) is a 16550A
GSI 16 (level, low) -> CPU 1 (0x0200) vector 51
0000:00:01.2: ttyS1 at MMIO 0x88033000 (irq = 54, base_baud = 115200) is
a 16550A
EFI Time Services Driver v0.4
libphy: Fixed MDIO Bus: probed
mousedev: PS/2 mouse device common for all mice
EFI Variables Facility v0.08 2004-May-17
registered taskstats version 1
Freeing unused kernel memory: 1280K (e000000004d80000 - e000000004ec0000)
thermal LNXTHERM:00: registered as thermal_zone0
ACPI: Thermal Zone [THM0] (27 C)
SCSI subsystem initialized
Fusion MPT base driver 3.04.20
Copyright (c) 1999-2008 LSI Corporation
Fusion MPT SPI Host driver 3.04.20
GSI 49 (level, low) -> CPU 2 (0x0400) vector 52
mptbase: ioc0: Initiating bringup
ioc0: LSI53C1030 C0: Capabilities={Initiator,Target}
scsi host0: ioc0: LSI53C1030 C0, FwRev=01032346h, Ports=1, MaxQ=255, IRQ=55
GSI 50 (level, low) -> CPU 3 (0x0600) vector 53
mptbase: ioc1: Initiating bringup
ioc1: LSI53C1030 C0: Capabilities={Initiator,Target}
scsi host1: ioc1: LSI53C1030 C0, FwRev=01032346h, Ports=1, MaxQ=255, IRQ=56
random: nonblocking pool is initialized
Fusion MPT SAS Host driver 3.04.20
GSI 27 (level, low) -> CPU 0 (0x0000) vector 54
mptbase: ioc2: Initiating bringup
ioc2: LSISAS1068 B0: Capabilities={Initiator}
scsi host2: ioc2: LSISAS1068 B0, FwRev=01172a00h, Ports=1, MaxQ=163, IRQ=57
mptsas: ioc2: attaching ssp device: fw_channel 0, fw_id 8, phy 0,
sas_addr 0x5000cca00a9965f5
scsi 2:0:0:0: Direct-Access HP DG0146FARVU HPD6 PQ: 0 ANSI: 5
mptsas: ioc2: attaching ssp device: fw_channel 0, fw_id 7, phy 1,
sas_addr 0x5000cca00a99675d
scsi 2:0:1:0: Direct-Access HP DG0146FARVU HPD6 PQ: 0 ANSI: 5
udevd (181): /proc/181/oom_adj is deprecated, please use
/proc/181/oom_score_adj instead.
udevd version 128 started
sd 2:0:0:0: [sda] 286749488 512-byte logical blocks: (146 GB/136 GiB)
sd 2:0:1:0: [sdb] 286749488 512-byte logical blocks: (146 GB/136 GiB)
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: eb 00 10 08
sd 2:0:1:0: [sdb] Write Protect is off
sd 2:0:1:0: [sdb] Mode Sense: eb 00 10 08
sd 2:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports
DPO and FUA
sd 2:0:1:0: [sdb] Write cache: disabled, read cache: enabled, supports
DPO and FUA
sda: sda1 sda2
sdb: sdb1 sdb2 sdb3 sdb4 sdb5 sdb6 sdb7
sd 2:0:0:0: [sda] Attached SCSI disk
sd 2:0:1:0: [sdb] Attached SCSI disk
EXT4-fs (sda2): mounting ext3 file system using the ext4 subsystem
EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts:
acl,user_xattr
EXT4-fs (sda2): re-mounted. Opts: acl,user_xattr
udevd version 128 started
ipmi message handler version 39.2
e1000: Intel(R) PRO/1000 Network Driver - version 7.3.21-k8-NAPI
e1000: Copyright (c) 1999-2006 Intel Corporation.
GSI 38 (level, low) -> CPU 1 (0x0200) vector 55
input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0
ACPI: Power Button [PWRF]
input: Sleep Button as /devices/LNXSYSTM:00/LNXSLPBN:00/input/input1
ACPI: Sleep Button [SLPF]
e1000 0000:02:01.0 eth0: (PCI-X:133MHz:64-bit) 00:24:81:77:73:a4
e1000 0000:02:01.0 eth0: Intel(R) PRO/1000 Network Connection
GSI 39 (level, low) -> CPU 2 (0x0400) vector 56
ipmi_si IPI0001:00: ipmi_si: probing via ACPI
ipmi_si IPI0001:00: [mem 0xff5bc000-0xff5bc003] regsize 1 spacing 1 irq 0
ipmi_si: Adding ACPI-specified kcs state machine
IPMI System Interface driver.
ipmi_si: probing via SPMI
ipmi_si: SPMI: mem 0xff5bc000 regsize 1 spacing 1 irq 0
ipmi_si: Adding SPMI-specified kcs state machine duplicate interface
ipmi_si: Trying ACPI-specified kcs state machine at mem address
0xff5bc000, slave address 0x0, irq 0
e1000 0000:02:01.1 eth1: (PCI-X:133MHz:64-bit) 00:24:81:77:73:a5
e1000 0000:02:01.1 eth1: Intel(R) PRO/1000 Network Connection
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti
<giometti@linux.it>
Fusion MPT misc device (ioctl) driver 3.04.20
GSI 60 (level, low) -> CPU 3 (0x0600) vector 57
mptctl: Registered with Fusion MPT base driver
mptctl: /dev/mptctl @ (major,minor=10,220)
sd 2:0:0:0: Attached scsi generic sg0 type 0
sd 2:0:1:0: Attached scsi generic sg1 type 0
PTP clock support registered
ipmi_si IPI0001:00: Found new BMC (man_id: 0x00000b, prod_id: 0x8201,
dev_id: 0x32)
ipmi_si IPI0001:00: IPMI kcs interface initialized
ACPI: bus type USB registered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
tg3.c:v3.137 (May 11, 2014)
GSI 29 (level, low) -> CPU 0 (0x0000) vector 58
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
e1000 0000:04:01.0 eth2: (PCI-X:133MHz:64-bit) 00:24:81:77:75:70
e1000 0000:04:01.0 eth2: Intel(R) PRO/1000 Network Connection
GSI 61 (level, low) -> CPU 1 (0x0200) vector 59
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ehci-pci: EHCI PCI platform driver
GSI 19 (level, low) -> CPU 2 (0x0400) vector 60
ehci-pci 0000:00:02.2: EHCI Host Controller
ehci-pci 0000:00:02.2: new USB bus registered, assigned bus number 1
ehci-pci 0000:00:02.2: irq 53, io mem 0x88030000
ehci-pci 0000:00:02.2: USB 2.0 started, EHCI 1.00
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: EHCI Host Controller
usb usb1: Manufacturer: Linux 4.4.0.1-0.7-default ehci_hcd
usb usb1: SerialNumber: 0000:00:02.2
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 5 ports detected
ohci-pci: OHCI PCI platform driver
GSI 17 (level, low) -> CPU 3 (0x0600) vector 61
ohci-pci 0000:00:02.0: OHCI PCI host controller
ohci-pci 0000:00:02.0: new USB bus registered, assigned bus number 2
ohci-pci 0000:00:02.0: irq 51, io mem 0x88032000
e1000 0000:04:01.1 eth3: (PCI-X:133MHz:64-bit) 00:24:81:77:75:71
e1000 0000:04:01.1 eth3: Intel(R) PRO/1000 Network Connection
e1000 0000:02:01.0 eth0_rename: renamed from eth0
usb usb2: New USB device found, idVendor=1d6b, idProduct=0001
usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb2: Product: OHCI PCI host controller
usb usb2: Manufacturer: Linux 4.4.0.1-0.7-default ohci_hcd
usb usb2: SerialNumber: 0000:00:02.0
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 3 ports detected
GSI 18 (level, low) -> CPU 0 (0x0000) vector 62
ohci-pci 0000:00:02.1: OHCI PCI host controller
ohci-pci 0000:00:02.1: new USB bus registered, assigned bus number 3
ohci-pci 0000:00:02.1: irq 52, io mem 0x88031000
e1000 0000:02:01.1 eth1_rename: renamed from eth1
e1000 0000:04:01.1 eth5: renamed from eth3
e1000 0000:04:01.0 eth4: renamed from eth2
tg3 0000:01:02.0 eth0: Tigon3 [partno(BCM95700A6) rev 2100]
(PCIX:66MHz:64-bit) MAC address 00:22:64:94:09:3f
tg3 0000:01:02.0 eth0: attached PHY is 5704 (10/100/1000Base-T Ethernet)
(WireSpeed[1], EEE[0])
tg3 0000:01:02.0 eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
tg3 0000:01:02.0 eth0: dma_rwctrl[769f0000] dma_mask[64-bit]
e1000 0000:02:01.1 eth3: renamed from eth1_rename
GSI 30 (level, low) -> CPU 1 (0x0200) vector 63
usb usb3: New USB device found, idVendor=1d6b, idProduct=0001
usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb3: Product: OHCI PCI host controller
usb usb3: Manufacturer: Linux 4.4.0.1-0.7-default ohci_hcd
usb usb3: SerialNumber: 0000:00:02.1
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
e1000 0000:02:01.0 eth2: renamed from eth0_rename
tg3 0000:01:02.1 eth1: Tigon3 [partno(BCM95700A6) rev 2100]
(PCIX:66MHz:64-bit) MAC address 00:22:64:94:09:3e
tg3 0000:01:02.1 eth1: attached PHY is 5704 (10/100/1000Base-T Ethernet)
(WireSpeed[1], EEE[0])
tg3 0000:01:02.1 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
tg3 0000:01:02.1 eth1: dma_rwctrl[769f0000] dma_mask[64-bit]
usb 1-2: new high-speed USB device number 3 using ehci-pci
usb 2-1: new full-speed USB device number 2 using ohci-pci
Adding 2104448k swap on /dev/sdb2. Priority:-1 extents:1 across:2104448k
usb 1-2: New USB device found, idVendor=03f0, idProduct=0126
usb 1-2: New USB device strings: Mfr=51, Product=80, SerialNumber=67
usb 1-2: Product: INTEGRITY SERVER
usb 1-2: Manufacturer: HEWLETT PACKARD
usb 1-2: SerialNumber: A60020000001
usb 2-1: New USB device found, idVendor=03f0, idProduct=1126
usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=63
usb 2-1: Product: Virtual Management Device
usb 2-1: Manufacturer: HP
usb 2-1: SerialNumber: 0022649407fa
hidraw: raw HID events driver (C) Jiri Kosina
usb-storage 1-2:1.0: USB Mass Storage device detected
scsi host3: usb-storage 1-2:1.0
usbcore: registered new interface driver usb-storage
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usb 3-2: new low-speed USB device number 2 using ohci-pci
input: HP Virtual Management Device as
/devices/LNXSYSTM:00/LNXSYBUS:00/HWP0001:00/HWP0002:00/pci0000:00/0000:00:02.0/usb2/2-1/2-1:1.0/0003:03F0:1126.0001/input/input2
hid-generic 0003:03F0:1126.0001: input,hidraw0: USB HID v1.11 Keyboard
[HP Virtual Management Device] on usb-0000:00:02.0-1/input0
input: HP Virtual Management Device as
/devices/LNXSYSTM:00/LNXSYBUS:00/HWP0001:00/HWP0002:00/pci0000:00/0000:00:02.0/usb2/2-1/2-1:1.1/0003:03F0:1126.0002/input/input3
hid-generic 0003:03F0:1126.0002: input,hidraw1: USB HID v1.01 Mouse [HP
Virtual Management Device] on usb-0000:00:02.0-1/input1
usb 3-2: New USB device found, idVendor=0557, idProduct=2221
usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-2: Product: UC-10KM V1.3.121
usb 3-2: Manufacturer: ATEN
usb 3-2: SerialNumber: USB Composite device
input: ATEN UC-10KM V1.3.121 as
/devices/LNXSYSTM:00/LNXSYBUS:00/HWP0001:00/HWP0002:00/pci0000:00/0000:00:02.1/usb3/3-2/3-2:1.0/0003:0557:2221.0003/input/input4
hid-generic 0003:0557:2221.0003: input,hidraw2: USB HID v1.10 Keyboard
[ATEN UC-10KM V1.3.121] on usb-0000:00:02.1-2/input0
input: ATEN UC-10KM V1.3.121 as
/devices/LNXSYSTM:00/LNXSYBUS:00/HWP0001:00/HWP0002:00/pci0000:00/0000:00:02.1/usb3/3-2/3-2:1.1/0003:0557:2221.0004/input/input5
hid-generic 0003:0557:2221.0004: input,hidraw3: USB HID v1.10 Mouse
[ATEN UC-10KM V1.3.121] on usb-0000:00:02.1-2/input1
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.34.0-ioctl (2015-10-28) initialised:
dm-devel at redhat.com
loop: module loaded
scsi 3:0:0:0: CD-ROM TEAC DVD-ROM DW-224EV K.DA PQ: 0 ANSI: 0
scsi 3:0:0:0: Attached scsi generic sg2 type 5
sr 3:0:0:0: [sr0] scsi3-mmc drive: 24x/24x cd/rw xa/form2 cdda tray
cdrom: Uniform CD-ROM driver Revision: 3.20
sr 3:0:0:0: Attached scsi CD-ROM sr0
fuse init (API version 7.23)
ip_local_port_range: prefer different parity for start/end values.
hangcheck_timer: disagrees about version of symbol module_layout
tg3 0000:01:02.0 eth0: Link is up at 1000 Mbps, full duplex
tg3 0000:01:02.0 eth0: Flow control is off for TX and off for RX
NET: Registered protocol family 10
IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
tg3 0000:01:02.1 eth1: Link is up at 1000 Mbps, full duplex
tg3 0000:01:02.1 eth1: Flow control is off for TX and off for RX
IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Installing knfsd (copyright (C) 1996 okir at monad.swb.de).
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: starting 90-second grace period (net a0000001014af100)
GSI 20 (level, low) -> CPU 2 (0x0400) vector 64
gnome-settings-(4170): floating-point assist fault at ip
2000000006b7bdc2, isr 0000020000001001
gnome-settings-(4170): floating-point assist fault at ip
2000000006b7bdc2, isr 0000020000001001
gnome-settings-(4170): floating-point assist fault at ip
2000000006b7bdc2, isr 0000020000001001
gnome-settings-(4170): floating-point assist fault at ip
2000000006b7bdc2, isr 0000020000001001
gnome-settings-(4170): floating-point assist fault at ip
2000000006b7bdc2, isr 0000020000001001
gdm-simple-gree(4179): unaligned access to 0x600fffffffadf34c,
ip=0x20000000012216a0
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-15 11:00 ` Hanjun Guo
@ 2016-01-18 14:37 ` Hanjun Guo
-1 siblings, 0 replies; 184+ messages in thread
From: Hanjun Guo @ 2016-01-18 14:37 UTC (permalink / raw)
To: Tomasz Nowicki, bhelgaas, arnd, will.deacon, catalin.marinas,
rjw, Lorenzo.Pieralisi, okaya, jiang.liu, Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm
On 2016/1/15 19:00, Hanjun Guo wrote:
> On 2016/1/13 21:20, 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
>
> Tested this patch set (and Matthew's) on a HP RX2660 IA64 machine,
> with the CONFIG_ACPI_PCI_HOST_GENERIC disabled on IA64 ( it's a minor
> comment needs to be addressed in my previous email), it can boot
> the system ok with NIC working properly, with the /pro/ioports [1] and
> the boot log [2] if anyone needs refer to it.
>
> For this patch set, on IA64 machine,
>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
I tested this patch set on x86 server with CONFIG_ACPI_PCI_HOST_GENERIC
disabled today, also booted ok with NIC working properly.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 184+ messages in thread
* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-18 14:37 ` Hanjun Guo
0 siblings, 0 replies; 184+ messages in thread
From: Hanjun Guo @ 2016-01-18 14:37 UTC (permalink / raw)
To: linux-arm-kernel
On 2016/1/15 19:00, Hanjun Guo wrote:
> On 2016/1/13 21:20, 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 at 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
>
> Tested this patch set (and Matthew's) on a HP RX2660 IA64 machine,
> with the CONFIG_ACPI_PCI_HOST_GENERIC disabled on IA64 ( it's a minor
> comment needs to be addressed in my previous email), it can boot
> the system ok with NIC working properly, with the /pro/ioports [1] and
> the boot log [2] if anyone needs refer to it.
>
> For this patch set, on IA64 machine,
>
> Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
I tested this patch set on x86 server with CONFIG_ACPI_PCI_HOST_GENERIC
disabled today, also booted ok with NIC working properly.
Thanks
Hanjun
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-13 13:20 ` Tomasz Nowicki
(?)
@ 2016-01-29 6:43 ` liudongdong (C)
-1 siblings, 0 replies; 184+ messages in thread
From: liudongdong (C) @ 2016-01-29 6:43 UTC (permalink / raw)
To: Tomasz Nowicki, bhelgaas, arnd, will.deacon, catalin.marinas,
rjw, hanjun.guo, Lorenzo.Pieralisi, okaya, jiang.liu,
Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
liudongdong3
在 2016/1/13 21:20, Tomasz Nowicki 写道:
>>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
Based on the patchset and add the Hip05 ACPI specific quirks.
Tested on the HiSilicon ARM64 D02 board.
I made a test based on Intel 82599 networking card,it can work ok.
this is the bootup log which contains PCIe host and Intel 82599 networking card part.
Tested-by: Dongdong Liu <liudongdong3@huawei.com>
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from command line
EFI stub: Exiting boot services and installing virtual address map...
GMAC ExitBootServicesEvent
SMMU ExitBootServicesEvent
Booting Linux on physical CPU 0x20000
Initializing cgroup subsys cpu
Linux version 4.4.0-rc2+ (l00290354@linux-ioko) (gcc version 4.9.3 20150211 (prerelease) (20150316) ) #194 SMP PREEMPT Thu Jan 28 09:51:15 CST 2016
Boot CPU: AArch64 Processor [411fd071]
earlycon: Early serial console at MMIO32 0x80300000 (options '')
bootconsole [uart0] enabled
efi: Getting EFI parameters from FDT:
EFI v2.50 by ARM Versatile Express EFI Jan 13 2016 20:43:10
efi: SMBIOS=0x7aae0000 SMBIOS 3.0=0x7aac0000 ACPI=0x7ab20000 ACPI 2.0=0x7ab20014
cma: Reserved 16 MiB at 0x000000007e800000
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x000000007AB20014 000024 (v02 HISI )
ACPI: XSDT 0x000000007AB100E8 00006C (v01 HISI HISI-D02 20140727 01000013)
ACPI: FACP 0x000000007AA80000 00010C (v05 HISI HISI-D02 20140727 HISI 00000099)
ACPI: Override [DSDT-HISI-D02], this is unsafe: tainting kernel
Disabling lock debugging due to kernel taint
ACPI: DSDT 0x000000007AA10000 Logical table override, new table: 0xFFFFFFC0009CB8B8
ACPI: DSDT 0xFFFFFFC0009CB8B8 0015B5 (v01 HISI HISI-D02 20140727 INTL 20150619)
ACPI: DBG2 0x000000007AAA0000 00005A (v00 HISI HISI-D02 20140727 HISI 00000099)
ACPI: GTDT 0x000000007AA70000 000060 (v02 HISI HISI-D02 20140727 HISI 00000099)
ACPI: APIC 0x000000007AA60000 000564 (v01 HISI HISI-D02 20140727 HISI 00000099)
ACPI: MCFG 0x000000007AA50000 00004C (v01 HISI HISI-D02 20140727 HISI 00000099)
ACPI: SLIT 0x000000007AA40000 0001BC (v01 HISI HISI-D02 20140727 HISI 00000099)
ACPI: SPCR 0x000000007AA30000 000050 (v02 HISI HISI-D02 20140727 HISI 00000099)
ACPI: SRAT 0x000000007AA20000 0001B0 (v03 HISI HISI-D02 20140727 HISI 00000099)
ACPI: IORT 0x000000007AA00000 0001FC (v00 INTEL TEMPLATE 00000000 INTL 20150619)
psci: probing for conduit method from ACPI.
NOTICE: [psci_smc_handler]:[349L] PSCI_VERSION CALL
NOTICE: [psci_version]:[101L] PSCI_MAJOR_VER: 10000: PSCI_MINOR_VER: 0
0008;<54
psci: PSCIv1.0 detected in firmware.
psci: Using standard PSCI v0.2 function IDs
0008;<54
psci: MIGRATE_INFO_TYPE not supported.
0008;<54
0008;<54
PERCPU: Embedded 15 pages/cpu @ffffffd1ffedb000 s24576 r8192 d28672 u61440
Detected PIPT I-cache on CPU0
CPU features: enabling workaround for ARM erratum 832075
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2063376
Kernel command line: dtb=hip05-d02.dtb console=ttyS0,115200 earlycon=uart8250,mmio32,0x80300000 initrd=filesystem.cpio.gz acpi=force
log_buf_len individual max cpu contribution: 4096 bytes
log_buf_len total cpu_extra contributions: 61440 bytes
log_buf_len min size: 16384 bytes
log_buf_len: 131072 bytes
early log buf free: 12732(77%)
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
software IO TLB [mem 0x76a00000-0x7aa00000] (64MB) mapped at [ffffffc076a00000-ffffffc07a9fffff]
Memory: 8052312K/8384512K available (6074K kernel code, 519K rwdata, 2556K rodata, 572K init, 212K bss, 315816K reserved, 16384K cma-reserved)
Virtual kernel memory layout:
vmalloc : 0xffffff8000000000 - 0xffffffbdbfff0000 ( 246 GB)
vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 GB maximum)
0xffffffbdc0000000 - 0xffffffbe08000000 ( 1152 MB actual)
fixed : 0xffffffbffa7fd000 - 0xffffffbffac00000 ( 4108 KB)
PCI I/O : 0xffffffbffae00000 - 0xffffffbffbe00000 ( 16 MB)
modules : 0xffffffbffc000000 - 0xffffffc000000000 ( 64 MB)
memory : 0xffffffc000000000 - 0xffffffd200000000 ( 73728 MB)
.init : 0xffffffc0008f0000 - 0xffffffc00097f000 ( 572 KB)
.text : 0xffffffc000080000 - 0xffffffc0008efa34 ( 8639 KB)
.data : 0xffffffc000994000 - 0xffffffc000a15c00 ( 519 KB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=1
Preemptible hierarchical RCU implementation.
Build-time adjustment of leaf fanout to 64.
RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=16.
RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=16
NR_IRQS:64 nr_irqs:64 0
GIC: Using split EOI/Deactivate mode
ITS@0x8c000000
ITS: allocated 65536 Devices @11f6c80000 (psz 4K, shr 1)
ITS: allocated 512 Virtual CPUs @11f6c0d000 (psz 4K, shr 1)
ITS: allocated 512 Interrupt Collections @11f6c0e000 (psz 4K, shr 1)
ITS@0xc6000000
ITS: allocated 65536 Devices @11f6d00000 (psz 4K, shr 1)
ITS: allocated 512 Virtual CPUs @11f6c0f000 (psz 4K, shr 1)
ITS: allocated 512 Interrupt Collections @11f6c30000 (psz 4K, shr 1)
ITS@0xa3000000
ITS: allocated 65536 Devices @11f6d80000 (psz 4K, shr 1)
ITS: allocated 512 Virtual CPUs @11f6c33000 (psz 4K, shr 1)
ITS: allocated 512 Interrupt Collections @11f6c34000 (psz 4K, shr 1)
ITS@0xb7000000
ITS: allocated 65536 Devices @11f6e00000 (psz 4K, shr 1)
ITS: allocated 512 Virtual CPUs @11f6c35000 (psz 4K, shr 1)
ITS: allocated 512 Interrupt Collections @11f6c36000 (psz 4K, shr 1)
GIC: using LPI property table @0x00000011f6c60000
ITS: Allocated 1792 chunks for LPIs
CPU0: found redistributor 20000 region 0:0x000000008d100000
CPU0: using LPI pending table @0x00000011f6c70000
Architected cp15 timer(s) running at 50.00MHz (phys).
clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xb8812736b, max_idle_ns: 440795202655 ns
sched_clock: 56 bits at 50MHz, resolution 20ns, wraps every 4398046511100ns
Console: colour dummy device 80x25
Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=200000)
pid_max: default: 32768 minimum: 301
ACPI: Core revision 20150930
ACPI: 1 ACPI AML tables successfully acquired and loaded
Security Framework initialized
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes)
Initializing cgroup subsys memory
Initializing cgroup subsys hugetlb
Remapping and enabling EFI services.
EFI remap 0x000000007aab0000 => 0000000040000000
EFI remap 0x000000007aaf0000 => 0000000040040000
EFI remap 0x000000007ab00000 => 0000000040050000
EFI remap 0x000000007ab30000 => 0000000040060000
EFI remap 0x000000007ab70000 => 00000000400a0000
EFI remap 0x000000007aba0000 => 00000000400c0000
EFI remap 0x000000007fb90000 => 00000000400d0000
EFI remap 0x000000007fbb0000 => 00000000400e0000
EFI remap 0x0000000080300000 => 0000000040110000
EFI remap 0x00000000a00f0000 => 0000000040120000
ASID allocator initialised with 65536 entries
PCI/MSI: ITS@0x8c000000 domain created
PCI/MSI: ITS@0xc6000000 domain created
PCI/MSI: ITS@0xa3000000 domain created
PCI/MSI: ITS@0xb7000000 domain created
Platform MSI: irqchip@000000008c000000 domain created
Platform MSI: irqchip@00000000c6000000 domain created
Platform MSI: irqchip@00000000a3000000 domain created
Platform MSI: irqchip@00000000b7000000 domain created
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20001 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x1
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x1
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c080
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d190
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20002 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x1
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x1
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c100
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d3a0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20003 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x1
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x1
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c180
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d5b0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20100 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x1
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x3
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c200
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d7c0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20101 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x3
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x3
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c280
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d9d0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20102 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x3
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x3
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c300
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3dbe0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20103 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x3
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x3
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c380
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3ddf0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20200 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x3
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x7
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c400
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e000
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20201 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x7
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x7
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c480
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e210
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20202 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x7
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x7
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c500
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e420
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20203 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x7
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x7
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c580
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e630
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20300 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x7
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0xf
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c600
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e840
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20301 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0xf
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0xf
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c680
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3ea50
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20302 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0xf
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0xf
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c700
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3ec60
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20303 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0xf
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0xf
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c780
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3ee70
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
Detected PIPT I-cache on CPU1
CPU1: found redistributor 20001 region 0:0x000000008d130000
CPU1: using LPI pending table @0x00000011f6400000
CPU1: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU2
CPU2: found redistributor 20002 region 0:0x000000008d160000
CPU2: using LPI pending table @0x00000011f6430000
CPU2: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU3
CPU3: found redistributor 20003 region 0:0x000000008d190000
CPU3: using LPI pending table @0x00000011f6460000
CPU3: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU4
CPU4: found redistributor 20100 region 0:0x000000008d1c0000
CPU4: using LPI pending table @0x00000011f64a0000
CPU4: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU5
CPU5: found redistributor 20101 region 0:0x000000008d1f0000
CPU5: using LPI pending table @0x00000011f64d0000
CPU5: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU6
CPU6: found redistributor 20102 region 0:0x000000008d220000
CPU6: using LPI pending table @0x00000011f6500000
CPU6: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU7
CPU7: found redistributor 20103 region 0:0x000000008d250000
CPU7: using LPI pending table @0x00000011f6540000
CPU7: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU8
CPU8: found redistributor 20200 region 0:0x000000008d280000
CPU8: using LPI pending table @0x00000011f6560000
CPU8: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU9
CPU9: found redistributor 20201 region 0:0x000000008d2b0000
CPU9: using LPI pending table @0x00000011f65a0000
CPU9: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU10
CPU10: found redistributor 20202 region 0:0x000000008d2e0000
CPU10: using LPI pending table @0x00000011f65d0000
CPU10: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU11
CPU11: found redistributor 20203 region 0:0x000000008d310000
CPU11: using LPI pending table @0x00000011f6600000
CPU11: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU12
CPU12: found redistributor 20300 region 0:0x000000008d340000
CPU12: using LPI pending table @0x00000011f6630000
CPU12: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU13
CPU13: found redistributor 20301 region 0:0x000000008d370000
CPU13: using LPI pending table @0x00000011f6670000
CPU13: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU14
CPU14: found redistributor 20302 region 0:0x000000008d3a0000
CPU14: using LPI pending table @0x00000011f66a0000
CPU14: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU15
CPU15: found redistributor 20303 region 0:0x000000008d3d0000
CPU15: using LPI pending table @0x00000011f66d0000
CPU15: Booted secondary processor [411fd071]
Brought up 16 CPUs
SMP: Total of 16 processors activated.
CPU features: detected feature: GIC system register CPU interface
CPU: All CPU(s) started at EL2
alternatives: patching kernel code
devtmpfs: initialized
SMBIOS 3.0.0 present.
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
cpuidle: using governor ladder
cpuidle: using governor menu
vdso: 2 pages (1 code @ ffffffc000999000, 1 data @ ffffffc000998000)
hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
DMA: preallocated 256 KiB pool for atomic allocations
ACPI: bus type PCI registered
Serial: AMBA PL011 UART driver
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
ACPI: Interpreter enabled
ACPI: Using GIC for interrupt routing
PCI: MMCONFIG for domain 0001 [bus 00-3f] at [mem 0x22000000000-0x22003ffffff] (base 0x22000000000)
PCI: MMCONFIG for domain 0002 [bus 40-7f] at [mem 0x24004000000-0x24007ffffff] (base 0x24000000000)
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: PCI Root Bridge [PCI1] (domain 0001 [bus 00-3f])
acpi HISI0080:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
acpi HISI0080:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
acpi HISI0080:00: PCI host bridge to bus 0001:00
pci_bus 0001:00: root bus resource [mem 0x22004000000-0x2200ffeffff window] (bus address [0xb0000000-0xbbfeffff])
pci_bus 0001:00: root bus resource [io 0x0000-0xffff window]
pci_bus 0001:00: root bus resource [bus 00-3f]
pci 0001:00:00.0: of_irq_parse_pci() failed with rc=-22
pci 0001:00:00.0: of_irq_parse_pci() failed with rc=-22
pci 0001:00:00.0: BAR 8: assigned [mem 0x22004000000-0x220041fffff]
pci 0001:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0001:01:00.0: BAR 6: assigned [mem 0x22004000000-0x220040fffff pref]
pci 0001:01:00.0: BAR 1: assigned [mem 0x22004100000-0x2200410ffff 64bit]
pci 0001:01:00.0: BAR 0: assigned [io 0x1000-0x10ff]
pci 0001:00:00.0: PCI bridge to [bus 01]
pci 0001:00:00.0: bridge window [io 0x1000-0x1fff]
pci 0001:00:00.0: bridge window [mem 0x22004000000-0x220041fffff]
ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 40-7f])
acpi HISI0080:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
acpi HISI0080:01: _OSC failed (AE_NOT_FOUND); disabling ASPM
acpi HISI0080:01: PCI host bridge to bus 0002:40
pci_bus 0002:40: root bus resource [mem 0x24008000000-0x2400ffeffff window] (bus address [0xc0000000-0xc7feffff])
pci_bus 0002:40: root bus resource [io 0x10000-0x1ffff window] (bus address [0x0000-0xffff])
pci_bus 0002:40: root bus resource [bus 40-7f]
pci 0002:40:00.0: of_irq_parse_pci() failed with rc=-22
pci 0002:40:00.0: Primary bus is hard wired to 0
pci 0002:40:00.0: bridge configuration invalid ([bus 01-01]), reconfiguring
pci 0002:40:00.0: of_irq_parse_pci() failed with rc=-22
pci 0002:40:00.0: of_irq_parse_pci() failed with rc=-22
pci 0002:40:00.0: BAR 8: assigned [mem 0x24008000000-0x240087fffff]
pci 0002:40:00.0: BAR 9: assigned [mem 0x24008800000-0x240091fffff 64bit pref]
pci 0002:40:00.0: BAR 7: assigned [io 0x10000-0x10fff]
pci 0002:41:00.0: BAR 0: assigned [mem 0x24008800000-0x24008bfffff 64bit pref]
pci 0002:41:00.0: BAR 6: assigned [mem 0x24008000000-0x240083fffff pref]
pci 0002:41:00.1: BAR 0: assigned [mem 0x24008c00000-0x24008ffffff 64bit pref]
pci 0002:41:00.1: BAR 6: assigned [mem 0x24008400000-0x240087fffff pref]
pci 0002:41:00.0: BAR 4: assigned [mem 0x24009000000-0x24009003fff 64bit pref]
pci 0002:41:00.1: BAR 4: assigned [mem 0x24009004000-0x24009007fff 64bit pref]
pci 0002:41:00.0: BAR 2: assigned [io 0x10000-0x1001f]
pci 0002:41:00.1: BAR 2: assigned [io 0x10020-0x1003f]
pci 0002:40:00.0: PCI bridge to [bus 41]
pci 0002:40:00.0: bridge window [io 0x10000-0x10fff]
pci 0002:40:00.0: bridge window [mem 0x24008000000-0x240087fffff]
pci 0002:40:00.0: bridge window [mem 0x24008800000-0x240091fffff 64bit pref]
vgaarb: loaded
SCSI subsystem initialized
ACPI: bus type USB registered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
clocksource: Switched to clocksource arch_sys_counter
pnp: PnP ACPI init
pnp: PnP ACPI: found 0 devices
NET: Registered protocol family 2
TCP established hash table entries: 65536 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
UDP hash table entries: 4096 (order: 5, 131072 bytes)
UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Unpacking initramfs...
Freeing initrd memory: 27492K (ffffffc01e520000 - ffffffc01fff9000)
kvm [1]: error: no compatible GIC node found
kvm [1]: error initializing Hyp mode: -19
ACPI: IORT: can't find node related to (null) device
futex hash table entries: 4096 (order: 7, 524288 bytes)
audit: initializing netlink subsys (disabled)
audit: type=2000 audit(1.720:1): initialized
HugeTLB registered 2 MB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.6.0
VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
fuse init (API version 7.23)
9p: Installing v9fs 9p2000 file system support
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler noop registered
io scheduler cfq registered (default)
pcieport 0001:00:00.0: can't derive routing for PCI INT A
pcieport 0001:00:00.0: PCI INT A: no GSI
pcieport 0002:40:00.0: can't derive routing for PCI INT A
pcieport 0002:40:00.0: PCI INT A: no GSI
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
console [ttyS0] disabled
APMC0D08:00: ttyS0 at MMIO 0x80300000 (irq = 5, base_baud = 12500000) is a 16550A
console [ttyS0] enabled
console [ttyS0] enabled
bootconsole [uart0] disabled
bootconsole [uart0] disabled
msm_serial: driver initialized
Failed to find cpu0 device node
Unable to detect cache hierarchy from DT for CPU 0
loop: module loaded
hisi_sas: driver version v1.0
scsi host0: hisi_sas
scsi host1: hisi_sas
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
libphy: Hisilicon MII Bus: probed
hisi_sas_v1_hw HISI0161:01: phyup: phy7 link_rate=10
scsi 1:0:0:0: Direct-Access SEAGATE ST9500620SS AS02 PQ: 0 ANSI: 5
sd 1:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 1:0:0:0: [sda] Attached SCSI disk
hns-nic HISI00C1:00: No valid mac, use random mac da:3a:ad:09:a3:14
netif_napi_add() called with weight 256 on device eth%d
hns-nic HISI00C1:01: No valid mac, use random mac ea:58:90:0b:08:bc
hns-nic HISI00C1:02: No valid mac, use random mac 2a:ef:14:d5:0f:41
hns-nic HISI00C1:03: No valid mac, use random mac 7a:77:63:4e:57:89
ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 4.2.1-k
ixgbe: Copyright (c) 1999-2015 Intel Corporation.
pcieport 0002:40:00.0: can't derive routing for PCI INT A
ixgbe 0002:41:00.0: PCI INT A: no GSI
ixgbe 0002:41:00.0: enabling device (0000 -> 0002)
ixgbe 0002:41:00.0: Multiqueue Enabled: Rx Queue count = 16, Tx Queue count = 16
ixgbe 0002:41:00.0: PCI Express bandwidth of 32GT/s available
ixgbe 0002:41:00.0: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%)
ixgbe 0002:41:00.0: MAC: 2, PHY: 17, SFP+: 5, PBA No: FFFFFF-0FF
ixgbe 0002:41:00.0: 68:a8:28:2e:c9:10
ixgbe 0002:41:00.0: Intel(R) 10 Gigabit Network Connection
pcieport 0002:40:00.0: can't derive routing for PCI INT B
ixgbe 0002:41:00.1: PCI INT B: no GSI
ixgbe 0002:41:00.1: enabling device (0000 -> 0002)
ixgbe 0002:41:00.1: Multiqueue Enabled: Rx Queue count = 16, Tx Queue count = 16
ixgbe 0002:41:00.1: PCI Express bandwidth of 32GT/s available
ixgbe 0002:41:00.1: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%)
ixgbe 0002:41:00.1: MAC: 2, PHY: 1, PBA No: FFFFFF-0FF
ixgbe 0002:41:00.1: 68:a8:28:2e:c9:11
ixgbe 0002:41:00.1: Intel(R) 10 Gigabit Network Connection
sky2: driver version 1.30
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-platform: EHCI generic platform driver
ehci-platform PNP0D20:00: EHCI Host Controller
ehci-platform PNP0D20:00: new USB bus registered, assigned bus number 1
ehci-platform PNP0D20:00: irq 6, io mem 0xa1000000
ehci-platform PNP0D20:00: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-pci: OHCI PCI platform driver
ohci-platform: OHCI generic platform driver
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
Synopsys Designware Multimedia Card Interface Driver
sdhci-pltfm: SDHCI platform and OF driver helper
ledtrig-cpu: registered to indicate activity on CPUs
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
NET: Registered protocol family 17
9pnet: Installing 9P2000 support
Key type dns_resolver registered
registered taskstats version 1
rtc-efi rtc-efi: setting system clock to 2100-01-01 00:02:52 UTC (4102444972)
ttyS0 - failed to request DMA
Freeing unused kernel memory: 572K (ffffffc0008f0000 - ffffffc00097f000)
Freeing alternatives memory: 60K (ffffffc00097f000 - ffffffc00098e000)
root@(none)$ ifconfig eth4 192.168.20.188
ixgbe 0002:41:00.0: registered PHC device on eth4
root@(none)$ ixgbe 0002:41:00.0 eth4: detected SFP+: 5
ixgbe 0002:41:00.0 eth4: NIC Link is Up 10 Gbps, Flow Control: RX/TX
root@(none)$ ping 192.168.20.4
PING 192.168.20.4 (192.168.20.4): 56 data bytes
64 bytes from 192.168.20.4: seq=21 ttl=128 time=0.368 ms
64 bytes from 192.168.20.4: seq=22 ttl=128 time=0.257 ms
64 bytes from 192.168.20.4: seq=23 ttl=128 time=0.316 ms
64 bytes from 192.168.20.4: seq=24 ttl=128 time=0.355 ms
64 bytes from 192.168.20.4: seq=25 ttl=128 time=0.257 ms
64 bytes from 192.168.20.4: seq=26 ttl=128 time=0.305 ms
64 bytes from 192.168.20.4: seq=27 ttl=128 time=0.290 ms
64 bytes from 192.168.20.4: seq=28 ttl=128 time=0.227 ms
64 bytes from 192.168.20.4: seq=29 ttl=128 time=3.865 ms
64 bytes from 192.168.20.4: seq=30 ttl=128 time=0.297 ms
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-29 6:43 ` liudongdong (C)
0 siblings, 0 replies; 184+ messages in thread
From: liudongdong (C) @ 2016-01-29 6:43 UTC (permalink / raw)
To: linux-arm-kernel
? 2016/1/13 21:20, Tomasz Nowicki ??:
>>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 at 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
Based on the patchset and add the Hip05 ACPI specific quirks.
Tested on the HiSilicon ARM64 D02 board.
I made a test based on Intel 82599 networking card,it can work ok.
this is the bootup log which contains PCIe host and Intel 82599 networking card part.
Tested-by: Dongdong Liu <liudongdong3@huawei.com>
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from command line
EFI stub: Exiting boot services and installing virtual address map...
GMAC ExitBootServicesEvent
SMMU ExitBootServicesEvent
Booting Linux on physical CPU 0x20000
Initializing cgroup subsys cpu
Linux version 4.4.0-rc2+ (l00290354 at linux-ioko) (gcc version 4.9.3 20150211 (prerelease) (20150316) ) #194 SMP PREEMPT Thu Jan 28 09:51:15 CST 2016
Boot CPU: AArch64 Processor [411fd071]
earlycon: Early serial console at MMIO32 0x80300000 (options '')
bootconsole [uart0] enabled
efi: Getting EFI parameters from FDT:
EFI v2.50 by ARM Versatile Express EFI Jan 13 2016 20:43:10
efi: SMBIOS=0x7aae0000 SMBIOS 3.0=0x7aac0000 ACPI=0x7ab20000 ACPI 2.0=0x7ab20014
cma: Reserved 16 MiB at 0x000000007e800000
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x000000007AB20014 000024 (v02 HISI )
ACPI: XSDT 0x000000007AB100E8 00006C (v01 HISI HISI-D02 20140727 01000013)
ACPI: FACP 0x000000007AA80000 00010C (v05 HISI HISI-D02 20140727 HISI 00000099)
ACPI: Override [DSDT-HISI-D02], this is unsafe: tainting kernel
Disabling lock debugging due to kernel taint
ACPI: DSDT 0x000000007AA10000 Logical table override, new table: 0xFFFFFFC0009CB8B8
ACPI: DSDT 0xFFFFFFC0009CB8B8 0015B5 (v01 HISI HISI-D02 20140727 INTL 20150619)
ACPI: DBG2 0x000000007AAA0000 00005A (v00 HISI HISI-D02 20140727 HISI 00000099)
ACPI: GTDT 0x000000007AA70000 000060 (v02 HISI HISI-D02 20140727 HISI 00000099)
ACPI: APIC 0x000000007AA60000 000564 (v01 HISI HISI-D02 20140727 HISI 00000099)
ACPI: MCFG 0x000000007AA50000 00004C (v01 HISI HISI-D02 20140727 HISI 00000099)
ACPI: SLIT 0x000000007AA40000 0001BC (v01 HISI HISI-D02 20140727 HISI 00000099)
ACPI: SPCR 0x000000007AA30000 000050 (v02 HISI HISI-D02 20140727 HISI 00000099)
ACPI: SRAT 0x000000007AA20000 0001B0 (v03 HISI HISI-D02 20140727 HISI 00000099)
ACPI: IORT 0x000000007AA00000 0001FC (v00 INTEL TEMPLATE 00000000 INTL 20150619)
psci: probing for conduit method from ACPI.
NOTICE: [psci_smc_handler]:[349L] PSCI_VERSION CALL
NOTICE: [psci_version]:[101L] PSCI_MAJOR_VER: 10000: PSCI_MINOR_VER: 0
0008;<54
psci: PSCIv1.0 detected in firmware.
psci: Using standard PSCI v0.2 function IDs
0008;<54
psci: MIGRATE_INFO_TYPE not supported.
0008;<54
0008;<54
PERCPU: Embedded 15 pages/cpu @ffffffd1ffedb000 s24576 r8192 d28672 u61440
Detected PIPT I-cache on CPU0
CPU features: enabling workaround for ARM erratum 832075
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2063376
Kernel command line: dtb=hip05-d02.dtb console=ttyS0,115200 earlycon=uart8250,mmio32,0x80300000 initrd=filesystem.cpio.gz acpi=force
log_buf_len individual max cpu contribution: 4096 bytes
log_buf_len total cpu_extra contributions: 61440 bytes
log_buf_len min size: 16384 bytes
log_buf_len: 131072 bytes
early log buf free: 12732(77%)
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
software IO TLB [mem 0x76a00000-0x7aa00000] (64MB) mapped at [ffffffc076a00000-ffffffc07a9fffff]
Memory: 8052312K/8384512K available (6074K kernel code, 519K rwdata, 2556K rodata, 572K init, 212K bss, 315816K reserved, 16384K cma-reserved)
Virtual kernel memory layout:
vmalloc : 0xffffff8000000000 - 0xffffffbdbfff0000 ( 246 GB)
vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 GB maximum)
0xffffffbdc0000000 - 0xffffffbe08000000 ( 1152 MB actual)
fixed : 0xffffffbffa7fd000 - 0xffffffbffac00000 ( 4108 KB)
PCI I/O : 0xffffffbffae00000 - 0xffffffbffbe00000 ( 16 MB)
modules : 0xffffffbffc000000 - 0xffffffc000000000 ( 64 MB)
memory : 0xffffffc000000000 - 0xffffffd200000000 ( 73728 MB)
.init : 0xffffffc0008f0000 - 0xffffffc00097f000 ( 572 KB)
.text : 0xffffffc000080000 - 0xffffffc0008efa34 ( 8639 KB)
.data : 0xffffffc000994000 - 0xffffffc000a15c00 ( 519 KB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=1
Preemptible hierarchical RCU implementation.
Build-time adjustment of leaf fanout to 64.
RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=16.
RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=16
NR_IRQS:64 nr_irqs:64 0
GIC: Using split EOI/Deactivate mode
ITS at 0x8c000000
ITS: allocated 65536 Devices @11f6c80000 (psz 4K, shr 1)
ITS: allocated 512 Virtual CPUs @11f6c0d000 (psz 4K, shr 1)
ITS: allocated 512 Interrupt Collections @11f6c0e000 (psz 4K, shr 1)
ITS at 0xc6000000
ITS: allocated 65536 Devices @11f6d00000 (psz 4K, shr 1)
ITS: allocated 512 Virtual CPUs @11f6c0f000 (psz 4K, shr 1)
ITS: allocated 512 Interrupt Collections @11f6c30000 (psz 4K, shr 1)
ITS at 0xa3000000
ITS: allocated 65536 Devices @11f6d80000 (psz 4K, shr 1)
ITS: allocated 512 Virtual CPUs @11f6c33000 (psz 4K, shr 1)
ITS: allocated 512 Interrupt Collections @11f6c34000 (psz 4K, shr 1)
ITS at 0xb7000000
ITS: allocated 65536 Devices @11f6e00000 (psz 4K, shr 1)
ITS: allocated 512 Virtual CPUs @11f6c35000 (psz 4K, shr 1)
ITS: allocated 512 Interrupt Collections @11f6c36000 (psz 4K, shr 1)
GIC: using LPI property table @0x00000011f6c60000
ITS: Allocated 1792 chunks for LPIs
CPU0: found redistributor 20000 region 0:0x000000008d100000
CPU0: using LPI pending table @0x00000011f6c70000
Architected cp15 timer(s) running at 50.00MHz (phys).
clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xb8812736b, max_idle_ns: 440795202655 ns
sched_clock: 56 bits@50MHz, resolution 20ns, wraps every 4398046511100ns
Console: colour dummy device 80x25
Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=200000)
pid_max: default: 32768 minimum: 301
ACPI: Core revision 20150930
ACPI: 1 ACPI AML tables successfully acquired and loaded
Security Framework initialized
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes)
Initializing cgroup subsys memory
Initializing cgroup subsys hugetlb
Remapping and enabling EFI services.
EFI remap 0x000000007aab0000 => 0000000040000000
EFI remap 0x000000007aaf0000 => 0000000040040000
EFI remap 0x000000007ab00000 => 0000000040050000
EFI remap 0x000000007ab30000 => 0000000040060000
EFI remap 0x000000007ab70000 => 00000000400a0000
EFI remap 0x000000007aba0000 => 00000000400c0000
EFI remap 0x000000007fb90000 => 00000000400d0000
EFI remap 0x000000007fbb0000 => 00000000400e0000
EFI remap 0x0000000080300000 => 0000000040110000
EFI remap 0x00000000a00f0000 => 0000000040120000
ASID allocator initialised with 65536 entries
PCI/MSI: ITS at 0x8c000000 domain created
PCI/MSI: ITS at 0xc6000000 domain created
PCI/MSI: ITS at 0xa3000000 domain created
PCI/MSI: ITS at 0xb7000000 domain created
Platform MSI: irqchip at 000000008c000000 domain created
Platform MSI: irqchip at 00000000c6000000 domain created
Platform MSI: irqchip at 00000000a3000000 domain created
Platform MSI: irqchip at 00000000b7000000 domain created
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20001 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x1
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x1
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c080
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d190
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20002 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x1
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x1
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c100
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d3a0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20003 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x1
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x1
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c180
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d5b0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20100 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x1
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x3
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c200
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d7c0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20101 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x3
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x3
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c280
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d9d0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20102 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x3
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x3
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c300
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3dbe0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20103 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x3
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x3
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c380
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3ddf0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20200 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x3
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x7
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c400
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e000
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20201 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x7
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x7
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c480
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e210
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20202 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x7
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x7
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c500
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e420
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20203 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x7
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x7
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c580
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e630
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20300 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x7
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0xf
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c600
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e840
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20301 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0xf
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0xf
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c680
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3ea50
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20302 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0xf
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0xf
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c700
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3ec60
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20303 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0xf
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0xf
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c780
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3ee70
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
Detected PIPT I-cache on CPU1
CPU1: found redistributor 20001 region 0:0x000000008d130000
CPU1: using LPI pending table @0x00000011f6400000
CPU1: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU2
CPU2: found redistributor 20002 region 0:0x000000008d160000
CPU2: using LPI pending table @0x00000011f6430000
CPU2: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU3
CPU3: found redistributor 20003 region 0:0x000000008d190000
CPU3: using LPI pending table @0x00000011f6460000
CPU3: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU4
CPU4: found redistributor 20100 region 0:0x000000008d1c0000
CPU4: using LPI pending table @0x00000011f64a0000
CPU4: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU5
CPU5: found redistributor 20101 region 0:0x000000008d1f0000
CPU5: using LPI pending table @0x00000011f64d0000
CPU5: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU6
CPU6: found redistributor 20102 region 0:0x000000008d220000
CPU6: using LPI pending table @0x00000011f6500000
CPU6: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU7
CPU7: found redistributor 20103 region 0:0x000000008d250000
CPU7: using LPI pending table @0x00000011f6540000
CPU7: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU8
CPU8: found redistributor 20200 region 0:0x000000008d280000
CPU8: using LPI pending table @0x00000011f6560000
CPU8: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU9
CPU9: found redistributor 20201 region 0:0x000000008d2b0000
CPU9: using LPI pending table @0x00000011f65a0000
CPU9: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU10
CPU10: found redistributor 20202 region 0:0x000000008d2e0000
CPU10: using LPI pending table @0x00000011f65d0000
CPU10: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU11
CPU11: found redistributor 20203 region 0:0x000000008d310000
CPU11: using LPI pending table @0x00000011f6600000
CPU11: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU12
CPU12: found redistributor 20300 region 0:0x000000008d340000
CPU12: using LPI pending table @0x00000011f6630000
CPU12: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU13
CPU13: found redistributor 20301 region 0:0x000000008d370000
CPU13: using LPI pending table @0x00000011f6670000
CPU13: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU14
CPU14: found redistributor 20302 region 0:0x000000008d3a0000
CPU14: using LPI pending table @0x00000011f66a0000
CPU14: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU15
CPU15: found redistributor 20303 region 0:0x000000008d3d0000
CPU15: using LPI pending table @0x00000011f66d0000
CPU15: Booted secondary processor [411fd071]
Brought up 16 CPUs
SMP: Total of 16 processors activated.
CPU features: detected feature: GIC system register CPU interface
CPU: All CPU(s) started at EL2
alternatives: patching kernel code
devtmpfs: initialized
SMBIOS 3.0.0 present.
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
cpuidle: using governor ladder
cpuidle: using governor menu
vdso: 2 pages (1 code @ ffffffc000999000, 1 data @ ffffffc000998000)
hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
DMA: preallocated 256 KiB pool for atomic allocations
ACPI: bus type PCI registered
Serial: AMBA PL011 UART driver
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
ACPI: Interpreter enabled
ACPI: Using GIC for interrupt routing
PCI: MMCONFIG for domain 0001 [bus 00-3f] at [mem 0x22000000000-0x22003ffffff] (base 0x22000000000)
PCI: MMCONFIG for domain 0002 [bus 40-7f] at [mem 0x24004000000-0x24007ffffff] (base 0x24000000000)
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: PCI Root Bridge [PCI1] (domain 0001 [bus 00-3f])
acpi HISI0080:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
acpi HISI0080:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
acpi HISI0080:00: PCI host bridge to bus 0001:00
pci_bus 0001:00: root bus resource [mem 0x22004000000-0x2200ffeffff window] (bus address [0xb0000000-0xbbfeffff])
pci_bus 0001:00: root bus resource [io 0x0000-0xffff window]
pci_bus 0001:00: root bus resource [bus 00-3f]
pci 0001:00:00.0: of_irq_parse_pci() failed with rc=-22
pci 0001:00:00.0: of_irq_parse_pci() failed with rc=-22
pci 0001:00:00.0: BAR 8: assigned [mem 0x22004000000-0x220041fffff]
pci 0001:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0001:01:00.0: BAR 6: assigned [mem 0x22004000000-0x220040fffff pref]
pci 0001:01:00.0: BAR 1: assigned [mem 0x22004100000-0x2200410ffff 64bit]
pci 0001:01:00.0: BAR 0: assigned [io 0x1000-0x10ff]
pci 0001:00:00.0: PCI bridge to [bus 01]
pci 0001:00:00.0: bridge window [io 0x1000-0x1fff]
pci 0001:00:00.0: bridge window [mem 0x22004000000-0x220041fffff]
ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 40-7f])
acpi HISI0080:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
acpi HISI0080:01: _OSC failed (AE_NOT_FOUND); disabling ASPM
acpi HISI0080:01: PCI host bridge to bus 0002:40
pci_bus 0002:40: root bus resource [mem 0x24008000000-0x2400ffeffff window] (bus address [0xc0000000-0xc7feffff])
pci_bus 0002:40: root bus resource [io 0x10000-0x1ffff window] (bus address [0x0000-0xffff])
pci_bus 0002:40: root bus resource [bus 40-7f]
pci 0002:40:00.0: of_irq_parse_pci() failed with rc=-22
pci 0002:40:00.0: Primary bus is hard wired to 0
pci 0002:40:00.0: bridge configuration invalid ([bus 01-01]), reconfiguring
pci 0002:40:00.0: of_irq_parse_pci() failed with rc=-22
pci 0002:40:00.0: of_irq_parse_pci() failed with rc=-22
pci 0002:40:00.0: BAR 8: assigned [mem 0x24008000000-0x240087fffff]
pci 0002:40:00.0: BAR 9: assigned [mem 0x24008800000-0x240091fffff 64bit pref]
pci 0002:40:00.0: BAR 7: assigned [io 0x10000-0x10fff]
pci 0002:41:00.0: BAR 0: assigned [mem 0x24008800000-0x24008bfffff 64bit pref]
pci 0002:41:00.0: BAR 6: assigned [mem 0x24008000000-0x240083fffff pref]
pci 0002:41:00.1: BAR 0: assigned [mem 0x24008c00000-0x24008ffffff 64bit pref]
pci 0002:41:00.1: BAR 6: assigned [mem 0x24008400000-0x240087fffff pref]
pci 0002:41:00.0: BAR 4: assigned [mem 0x24009000000-0x24009003fff 64bit pref]
pci 0002:41:00.1: BAR 4: assigned [mem 0x24009004000-0x24009007fff 64bit pref]
pci 0002:41:00.0: BAR 2: assigned [io 0x10000-0x1001f]
pci 0002:41:00.1: BAR 2: assigned [io 0x10020-0x1003f]
pci 0002:40:00.0: PCI bridge to [bus 41]
pci 0002:40:00.0: bridge window [io 0x10000-0x10fff]
pci 0002:40:00.0: bridge window [mem 0x24008000000-0x240087fffff]
pci 0002:40:00.0: bridge window [mem 0x24008800000-0x240091fffff 64bit pref]
vgaarb: loaded
SCSI subsystem initialized
ACPI: bus type USB registered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
clocksource: Switched to clocksource arch_sys_counter
pnp: PnP ACPI init
pnp: PnP ACPI: found 0 devices
NET: Registered protocol family 2
TCP established hash table entries: 65536 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
UDP hash table entries: 4096 (order: 5, 131072 bytes)
UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Unpacking initramfs...
Freeing initrd memory: 27492K (ffffffc01e520000 - ffffffc01fff9000)
kvm [1]: error: no compatible GIC node found
kvm [1]: error initializing Hyp mode: -19
ACPI: IORT: can't find node related to (null) device
futex hash table entries: 4096 (order: 7, 524288 bytes)
audit: initializing netlink subsys (disabled)
audit: type=2000 audit(1.720:1): initialized
HugeTLB registered 2 MB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.6.0
VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
fuse init (API version 7.23)
9p: Installing v9fs 9p2000 file system support
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler noop registered
io scheduler cfq registered (default)
pcieport 0001:00:00.0: can't derive routing for PCI INT A
pcieport 0001:00:00.0: PCI INT A: no GSI
pcieport 0002:40:00.0: can't derive routing for PCI INT A
pcieport 0002:40:00.0: PCI INT A: no GSI
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
console [ttyS0] disabled
APMC0D08:00: ttyS0 at MMIO 0x80300000 (irq = 5, base_baud = 12500000) is a 16550A
console [ttyS0] enabled
console [ttyS0] enabled
bootconsole [uart0] disabled
bootconsole [uart0] disabled
msm_serial: driver initialized
Failed to find cpu0 device node
Unable to detect cache hierarchy from DT for CPU 0
loop: module loaded
hisi_sas: driver version v1.0
scsi host0: hisi_sas
scsi host1: hisi_sas
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
libphy: Hisilicon MII Bus: probed
hisi_sas_v1_hw HISI0161:01: phyup: phy7 link_rate=10
scsi 1:0:0:0: Direct-Access SEAGATE ST9500620SS AS02 PQ: 0 ANSI: 5
sd 1:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 1:0:0:0: [sda] Attached SCSI disk
hns-nic HISI00C1:00: No valid mac, use random mac da:3a:ad:09:a3:14
netif_napi_add() called with weight 256 on device eth%d
hns-nic HISI00C1:01: No valid mac, use random mac ea:58:90:0b:08:bc
hns-nic HISI00C1:02: No valid mac, use random mac 2a:ef:14:d5:0f:41
hns-nic HISI00C1:03: No valid mac, use random mac 7a:77:63:4e:57:89
ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 4.2.1-k
ixgbe: Copyright (c) 1999-2015 Intel Corporation.
pcieport 0002:40:00.0: can't derive routing for PCI INT A
ixgbe 0002:41:00.0: PCI INT A: no GSI
ixgbe 0002:41:00.0: enabling device (0000 -> 0002)
ixgbe 0002:41:00.0: Multiqueue Enabled: Rx Queue count = 16, Tx Queue count = 16
ixgbe 0002:41:00.0: PCI Express bandwidth of 32GT/s available
ixgbe 0002:41:00.0: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%)
ixgbe 0002:41:00.0: MAC: 2, PHY: 17, SFP+: 5, PBA No: FFFFFF-0FF
ixgbe 0002:41:00.0: 68:a8:28:2e:c9:10
ixgbe 0002:41:00.0: Intel(R) 10 Gigabit Network Connection
pcieport 0002:40:00.0: can't derive routing for PCI INT B
ixgbe 0002:41:00.1: PCI INT B: no GSI
ixgbe 0002:41:00.1: enabling device (0000 -> 0002)
ixgbe 0002:41:00.1: Multiqueue Enabled: Rx Queue count = 16, Tx Queue count = 16
ixgbe 0002:41:00.1: PCI Express bandwidth of 32GT/s available
ixgbe 0002:41:00.1: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%)
ixgbe 0002:41:00.1: MAC: 2, PHY: 1, PBA No: FFFFFF-0FF
ixgbe 0002:41:00.1: 68:a8:28:2e:c9:11
ixgbe 0002:41:00.1: Intel(R) 10 Gigabit Network Connection
sky2: driver version 1.30
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-platform: EHCI generic platform driver
ehci-platform PNP0D20:00: EHCI Host Controller
ehci-platform PNP0D20:00: new USB bus registered, assigned bus number 1
ehci-platform PNP0D20:00: irq 6, io mem 0xa1000000
ehci-platform PNP0D20:00: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-pci: OHCI PCI platform driver
ohci-platform: OHCI generic platform driver
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
Synopsys Designware Multimedia Card Interface Driver
sdhci-pltfm: SDHCI platform and OF driver helper
ledtrig-cpu: registered to indicate activity on CPUs
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
NET: Registered protocol family 17
9pnet: Installing 9P2000 support
Key type dns_resolver registered
registered taskstats version 1
rtc-efi rtc-efi: setting system clock to 2100-01-01 00:02:52 UTC (4102444972)
ttyS0 - failed to request DMA
Freeing unused kernel memory: 572K (ffffffc0008f0000 - ffffffc00097f000)
Freeing alternatives memory: 60K (ffffffc00097f000 - ffffffc00098e000)
root@(none)$ ifconfig eth4 192.168.20.188
ixgbe 0002:41:00.0: registered PHC device on eth4
root@(none)$ ixgbe 0002:41:00.0 eth4: detected SFP+: 5
ixgbe 0002:41:00.0 eth4: NIC Link is Up 10 Gbps, Flow Control: RX/TX
root@(none)$ ping 192.168.20.4
PING 192.168.20.4 (192.168.20.4): 56 data bytes
64 bytes from 192.168.20.4: seq=21 ttl=128 time=0.368 ms
64 bytes from 192.168.20.4: seq=22 ttl=128 time=0.257 ms
64 bytes from 192.168.20.4: seq=23 ttl=128 time=0.316 ms
64 bytes from 192.168.20.4: seq=24 ttl=128 time=0.355 ms
64 bytes from 192.168.20.4: seq=25 ttl=128 time=0.257 ms
64 bytes from 192.168.20.4: seq=26 ttl=128 time=0.305 ms
64 bytes from 192.168.20.4: seq=27 ttl=128 time=0.290 ms
64 bytes from 192.168.20.4: seq=28 ttl=128 time=0.227 ms
64 bytes from 192.168.20.4: seq=29 ttl=128 time=3.865 ms
64 bytes from 192.168.20.4: seq=30 ttl=128 time=0.297 ms
^ permalink raw reply [flat|nested] 184+ messages in thread* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-01-29 6:43 ` liudongdong (C)
0 siblings, 0 replies; 184+ messages in thread
From: liudongdong (C) @ 2016-01-29 6:43 UTC (permalink / raw)
To: Tomasz Nowicki, bhelgaas, arnd, will.deacon, catalin.marinas,
rjw, hanjun.guo, Lorenzo.Pieralisi, okaya, jiang.liu,
Stefano.Stabellini
Cc: robert.richter, mw, Liviu.Dudau, ddaney, tglx, wangyijing,
Suravee.Suthikulpanit, msalter, linux-pci, linux-arm-kernel,
linux-acpi, linux-kernel, linaro-acpi, jchandra, jcm,
liudongdong3
在 2016/1/13 21:20, Tomasz Nowicki 写道:
>>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
Based on the patchset and add the Hip05 ACPI specific quirks.
Tested on the HiSilicon ARM64 D02 board.
I made a test based on Intel 82599 networking card,it can work ok.
this is the bootup log which contains PCIe host and Intel 82599 networking card part.
Tested-by: Dongdong Liu <liudongdong3@huawei.com>
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from command line
EFI stub: Exiting boot services and installing virtual address map...
GMAC ExitBootServicesEvent
SMMU ExitBootServicesEvent
Booting Linux on physical CPU 0x20000
Initializing cgroup subsys cpu
Linux version 4.4.0-rc2+ (l00290354@linux-ioko) (gcc version 4.9.3 20150211 (prerelease) (20150316) ) #194 SMP PREEMPT Thu Jan 28 09:51:15 CST 2016
Boot CPU: AArch64 Processor [411fd071]
earlycon: Early serial console at MMIO32 0x80300000 (options '')
bootconsole [uart0] enabled
efi: Getting EFI parameters from FDT:
EFI v2.50 by ARM Versatile Express EFI Jan 13 2016 20:43:10
efi: SMBIOS=0x7aae0000 SMBIOS 3.0=0x7aac0000 ACPI=0x7ab20000 ACPI 2.0=0x7ab20014
cma: Reserved 16 MiB at 0x000000007e800000
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x000000007AB20014 000024 (v02 HISI )
ACPI: XSDT 0x000000007AB100E8 00006C (v01 HISI HISI-D02 20140727 01000013)
ACPI: FACP 0x000000007AA80000 00010C (v05 HISI HISI-D02 20140727 HISI 00000099)
ACPI: Override [DSDT-HISI-D02], this is unsafe: tainting kernel
Disabling lock debugging due to kernel taint
ACPI: DSDT 0x000000007AA10000 Logical table override, new table: 0xFFFFFFC0009CB8B8
ACPI: DSDT 0xFFFFFFC0009CB8B8 0015B5 (v01 HISI HISI-D02 20140727 INTL 20150619)
ACPI: DBG2 0x000000007AAA0000 00005A (v00 HISI HISI-D02 20140727 HISI 00000099)
ACPI: GTDT 0x000000007AA70000 000060 (v02 HISI HISI-D02 20140727 HISI 00000099)
ACPI: APIC 0x000000007AA60000 000564 (v01 HISI HISI-D02 20140727 HISI 00000099)
ACPI: MCFG 0x000000007AA50000 00004C (v01 HISI HISI-D02 20140727 HISI 00000099)
ACPI: SLIT 0x000000007AA40000 0001BC (v01 HISI HISI-D02 20140727 HISI 00000099)
ACPI: SPCR 0x000000007AA30000 000050 (v02 HISI HISI-D02 20140727 HISI 00000099)
ACPI: SRAT 0x000000007AA20000 0001B0 (v03 HISI HISI-D02 20140727 HISI 00000099)
ACPI: IORT 0x000000007AA00000 0001FC (v00 INTEL TEMPLATE 00000000 INTL 20150619)
psci: probing for conduit method from ACPI.
NOTICE: [psci_smc_handler]:[349L] PSCI_VERSION CALL
NOTICE: [psci_version]:[101L] PSCI_MAJOR_VER: 10000: PSCI_MINOR_VER: 0
0008;<54
psci: PSCIv1.0 detected in firmware.
psci: Using standard PSCI v0.2 function IDs
0008;<54
psci: MIGRATE_INFO_TYPE not supported.
0008;<54
0008;<54
PERCPU: Embedded 15 pages/cpu @ffffffd1ffedb000 s24576 r8192 d28672 u61440
Detected PIPT I-cache on CPU0
CPU features: enabling workaround for ARM erratum 832075
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2063376
Kernel command line: dtb=hip05-d02.dtb console=ttyS0,115200 earlycon=uart8250,mmio32,0x80300000 initrd=filesystem.cpio.gz acpi=force
log_buf_len individual max cpu contribution: 4096 bytes
log_buf_len total cpu_extra contributions: 61440 bytes
log_buf_len min size: 16384 bytes
log_buf_len: 131072 bytes
early log buf free: 12732(77%)
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
software IO TLB [mem 0x76a00000-0x7aa00000] (64MB) mapped at [ffffffc076a00000-ffffffc07a9fffff]
Memory: 8052312K/8384512K available (6074K kernel code, 519K rwdata, 2556K rodata, 572K init, 212K bss, 315816K reserved, 16384K cma-reserved)
Virtual kernel memory layout:
vmalloc : 0xffffff8000000000 - 0xffffffbdbfff0000 ( 246 GB)
vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000 ( 8 GB maximum)
0xffffffbdc0000000 - 0xffffffbe08000000 ( 1152 MB actual)
fixed : 0xffffffbffa7fd000 - 0xffffffbffac00000 ( 4108 KB)
PCI I/O : 0xffffffbffae00000 - 0xffffffbffbe00000 ( 16 MB)
modules : 0xffffffbffc000000 - 0xffffffc000000000 ( 64 MB)
memory : 0xffffffc000000000 - 0xffffffd200000000 ( 73728 MB)
.init : 0xffffffc0008f0000 - 0xffffffc00097f000 ( 572 KB)
.text : 0xffffffc000080000 - 0xffffffc0008efa34 ( 8639 KB)
.data : 0xffffffc000994000 - 0xffffffc000a15c00 ( 519 KB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=1
Preemptible hierarchical RCU implementation.
Build-time adjustment of leaf fanout to 64.
RCU restricting CPUs from NR_CPUS=64 to nr_cpu_ids=16.
RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=16
NR_IRQS:64 nr_irqs:64 0
GIC: Using split EOI/Deactivate mode
ITS@0x8c000000
ITS: allocated 65536 Devices @11f6c80000 (psz 4K, shr 1)
ITS: allocated 512 Virtual CPUs @11f6c0d000 (psz 4K, shr 1)
ITS: allocated 512 Interrupt Collections @11f6c0e000 (psz 4K, shr 1)
ITS@0xc6000000
ITS: allocated 65536 Devices @11f6d00000 (psz 4K, shr 1)
ITS: allocated 512 Virtual CPUs @11f6c0f000 (psz 4K, shr 1)
ITS: allocated 512 Interrupt Collections @11f6c30000 (psz 4K, shr 1)
ITS@0xa3000000
ITS: allocated 65536 Devices @11f6d80000 (psz 4K, shr 1)
ITS: allocated 512 Virtual CPUs @11f6c33000 (psz 4K, shr 1)
ITS: allocated 512 Interrupt Collections @11f6c34000 (psz 4K, shr 1)
ITS@0xb7000000
ITS: allocated 65536 Devices @11f6e00000 (psz 4K, shr 1)
ITS: allocated 512 Virtual CPUs @11f6c35000 (psz 4K, shr 1)
ITS: allocated 512 Interrupt Collections @11f6c36000 (psz 4K, shr 1)
GIC: using LPI property table @0x00000011f6c60000
ITS: Allocated 1792 chunks for LPIs
CPU0: found redistributor 20000 region 0:0x000000008d100000
CPU0: using LPI pending table @0x00000011f6c70000
Architected cp15 timer(s) running at 50.00MHz (phys).
clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0xb8812736b, max_idle_ns: 440795202655 ns
sched_clock: 56 bits at 50MHz, resolution 20ns, wraps every 4398046511100ns
Console: colour dummy device 80x25
Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=200000)
pid_max: default: 32768 minimum: 301
ACPI: Core revision 20150930
ACPI: 1 ACPI AML tables successfully acquired and loaded
Security Framework initialized
Mount-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes)
Initializing cgroup subsys memory
Initializing cgroup subsys hugetlb
Remapping and enabling EFI services.
EFI remap 0x000000007aab0000 => 0000000040000000
EFI remap 0x000000007aaf0000 => 0000000040040000
EFI remap 0x000000007ab00000 => 0000000040050000
EFI remap 0x000000007ab30000 => 0000000040060000
EFI remap 0x000000007ab70000 => 00000000400a0000
EFI remap 0x000000007aba0000 => 00000000400c0000
EFI remap 0x000000007fb90000 => 00000000400d0000
EFI remap 0x000000007fbb0000 => 00000000400e0000
EFI remap 0x0000000080300000 => 0000000040110000
EFI remap 0x00000000a00f0000 => 0000000040120000
ASID allocator initialised with 65536 entries
PCI/MSI: ITS@0x8c000000 domain created
PCI/MSI: ITS@0xc6000000 domain created
PCI/MSI: ITS@0xa3000000 domain created
PCI/MSI: ITS@0xb7000000 domain created
Platform MSI: irqchip@000000008c000000 domain created
Platform MSI: irqchip@00000000c6000000 domain created
Platform MSI: irqchip@00000000a3000000 domain created
Platform MSI: irqchip@00000000b7000000 domain created
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20001 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x1
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x1
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c080
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d190
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20002 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x1
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x1
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c100
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d3a0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20003 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x1
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x1
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c180
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d5b0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20100 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x1
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x3
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c200
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d7c0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20101 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x3
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x3
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c280
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3d9d0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20102 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x3
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x3
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c300
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3dbe0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20103 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x3
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x3
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c380
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3ddf0
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20200 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x3
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x7
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c400
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e000
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20201 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x7
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x7
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c480
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e210
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20202 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x7
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x7
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c500
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e420
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20203 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x7
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0x7
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c580
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e630
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20300 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0x7
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0xf
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c600
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3e840
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20301 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0xf
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0xf
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c680
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3ea50
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20302 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0xf
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0xf
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c700
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3ec60
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
NOTICE: [psci_smc_handler]:[410L] PSCI_CPU_ON_AARCH64 CALL
NOTICE: [psci_smc_handler]:[411L] x1=0x20303 x2=0x827d0 x3=0x0
NOTICE: [scpi_set_css_power_state]:[89L] domain_cluster=0xf
NOTICE: [scpi_set_css_power_state]:[97L] domain_cluster=0xf
0008;<AB54
NOTICE: [psci_afflvl_power_on_finish]:[508L]
NOTICE: [cm_prepare_el3_exit]:[266L] read_tpidr_el3 = 7fc3c780
NOTICE: [cm_prepare_el3_exit]:[321L] ctx add = 7fc3ee70
NOTICE: [psci_afflvl_power_on_finish]:[566L]
000827=0
Detected PIPT I-cache on CPU1
CPU1: found redistributor 20001 region 0:0x000000008d130000
CPU1: using LPI pending table @0x00000011f6400000
CPU1: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU2
CPU2: found redistributor 20002 region 0:0x000000008d160000
CPU2: using LPI pending table @0x00000011f6430000
CPU2: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU3
CPU3: found redistributor 20003 region 0:0x000000008d190000
CPU3: using LPI pending table @0x00000011f6460000
CPU3: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU4
CPU4: found redistributor 20100 region 0:0x000000008d1c0000
CPU4: using LPI pending table @0x00000011f64a0000
CPU4: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU5
CPU5: found redistributor 20101 region 0:0x000000008d1f0000
CPU5: using LPI pending table @0x00000011f64d0000
CPU5: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU6
CPU6: found redistributor 20102 region 0:0x000000008d220000
CPU6: using LPI pending table @0x00000011f6500000
CPU6: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU7
CPU7: found redistributor 20103 region 0:0x000000008d250000
CPU7: using LPI pending table @0x00000011f6540000
CPU7: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU8
CPU8: found redistributor 20200 region 0:0x000000008d280000
CPU8: using LPI pending table @0x00000011f6560000
CPU8: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU9
CPU9: found redistributor 20201 region 0:0x000000008d2b0000
CPU9: using LPI pending table @0x00000011f65a0000
CPU9: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU10
CPU10: found redistributor 20202 region 0:0x000000008d2e0000
CPU10: using LPI pending table @0x00000011f65d0000
CPU10: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU11
CPU11: found redistributor 20203 region 0:0x000000008d310000
CPU11: using LPI pending table @0x00000011f6600000
CPU11: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU12
CPU12: found redistributor 20300 region 0:0x000000008d340000
CPU12: using LPI pending table @0x00000011f6630000
CPU12: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU13
CPU13: found redistributor 20301 region 0:0x000000008d370000
CPU13: using LPI pending table @0x00000011f6670000
CPU13: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU14
CPU14: found redistributor 20302 region 0:0x000000008d3a0000
CPU14: using LPI pending table @0x00000011f66a0000
CPU14: Booted secondary processor [411fd071]
Detected PIPT I-cache on CPU15
CPU15: found redistributor 20303 region 0:0x000000008d3d0000
CPU15: using LPI pending table @0x00000011f66d0000
CPU15: Booted secondary processor [411fd071]
Brought up 16 CPUs
SMP: Total of 16 processors activated.
CPU features: detected feature: GIC system register CPU interface
CPU: All CPU(s) started at EL2
alternatives: patching kernel code
devtmpfs: initialized
SMBIOS 3.0.0 present.
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
cpuidle: using governor ladder
cpuidle: using governor menu
vdso: 2 pages (1 code @ ffffffc000999000, 1 data @ ffffffc000998000)
hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
DMA: preallocated 256 KiB pool for atomic allocations
ACPI: bus type PCI registered
Serial: AMBA PL011 UART driver
ACPI: Added _OSI(Module Device)
ACPI: Added _OSI(Processor Device)
ACPI: Added _OSI(3.0 _SCP Extensions)
ACPI: Added _OSI(Processor Aggregator Device)
ACPI: Interpreter enabled
ACPI: Using GIC for interrupt routing
PCI: MMCONFIG for domain 0001 [bus 00-3f] at [mem 0x22000000000-0x22003ffffff] (base 0x22000000000)
PCI: MMCONFIG for domain 0002 [bus 40-7f] at [mem 0x24004000000-0x24007ffffff] (base 0x24000000000)
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: IORT: can't find node related to (null) device
ACPI: PCI Root Bridge [PCI1] (domain 0001 [bus 00-3f])
acpi HISI0080:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
acpi HISI0080:00: _OSC failed (AE_NOT_FOUND); disabling ASPM
acpi HISI0080:00: PCI host bridge to bus 0001:00
pci_bus 0001:00: root bus resource [mem 0x22004000000-0x2200ffeffff window] (bus address [0xb0000000-0xbbfeffff])
pci_bus 0001:00: root bus resource [io 0x0000-0xffff window]
pci_bus 0001:00: root bus resource [bus 00-3f]
pci 0001:00:00.0: of_irq_parse_pci() failed with rc=-22
pci 0001:00:00.0: of_irq_parse_pci() failed with rc=-22
pci 0001:00:00.0: BAR 8: assigned [mem 0x22004000000-0x220041fffff]
pci 0001:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
pci 0001:01:00.0: BAR 6: assigned [mem 0x22004000000-0x220040fffff pref]
pci 0001:01:00.0: BAR 1: assigned [mem 0x22004100000-0x2200410ffff 64bit]
pci 0001:01:00.0: BAR 0: assigned [io 0x1000-0x10ff]
pci 0001:00:00.0: PCI bridge to [bus 01]
pci 0001:00:00.0: bridge window [io 0x1000-0x1fff]
pci 0001:00:00.0: bridge window [mem 0x22004000000-0x220041fffff]
ACPI: PCI Root Bridge [PCI2] (domain 0002 [bus 40-7f])
acpi HISI0080:01: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
acpi HISI0080:01: _OSC failed (AE_NOT_FOUND); disabling ASPM
acpi HISI0080:01: PCI host bridge to bus 0002:40
pci_bus 0002:40: root bus resource [mem 0x24008000000-0x2400ffeffff window] (bus address [0xc0000000-0xc7feffff])
pci_bus 0002:40: root bus resource [io 0x10000-0x1ffff window] (bus address [0x0000-0xffff])
pci_bus 0002:40: root bus resource [bus 40-7f]
pci 0002:40:00.0: of_irq_parse_pci() failed with rc=-22
pci 0002:40:00.0: Primary bus is hard wired to 0
pci 0002:40:00.0: bridge configuration invalid ([bus 01-01]), reconfiguring
pci 0002:40:00.0: of_irq_parse_pci() failed with rc=-22
pci 0002:40:00.0: of_irq_parse_pci() failed with rc=-22
pci 0002:40:00.0: BAR 8: assigned [mem 0x24008000000-0x240087fffff]
pci 0002:40:00.0: BAR 9: assigned [mem 0x24008800000-0x240091fffff 64bit pref]
pci 0002:40:00.0: BAR 7: assigned [io 0x10000-0x10fff]
pci 0002:41:00.0: BAR 0: assigned [mem 0x24008800000-0x24008bfffff 64bit pref]
pci 0002:41:00.0: BAR 6: assigned [mem 0x24008000000-0x240083fffff pref]
pci 0002:41:00.1: BAR 0: assigned [mem 0x24008c00000-0x24008ffffff 64bit pref]
pci 0002:41:00.1: BAR 6: assigned [mem 0x24008400000-0x240087fffff pref]
pci 0002:41:00.0: BAR 4: assigned [mem 0x24009000000-0x24009003fff 64bit pref]
pci 0002:41:00.1: BAR 4: assigned [mem 0x24009004000-0x24009007fff 64bit pref]
pci 0002:41:00.0: BAR 2: assigned [io 0x10000-0x1001f]
pci 0002:41:00.1: BAR 2: assigned [io 0x10020-0x1003f]
pci 0002:40:00.0: PCI bridge to [bus 41]
pci 0002:40:00.0: bridge window [io 0x10000-0x10fff]
pci 0002:40:00.0: bridge window [mem 0x24008000000-0x240087fffff]
pci 0002:40:00.0: bridge window [mem 0x24008800000-0x240091fffff 64bit pref]
vgaarb: loaded
SCSI subsystem initialized
ACPI: bus type USB registered
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
pps_core: LinuxPPS API ver. 1 registered
pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
PTP clock support registered
clocksource: Switched to clocksource arch_sys_counter
pnp: PnP ACPI init
pnp: PnP ACPI: found 0 devices
NET: Registered protocol family 2
TCP established hash table entries: 65536 (order: 7, 524288 bytes)
TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
TCP: Hash tables configured (established 65536 bind 65536)
UDP hash table entries: 4096 (order: 5, 131072 bytes)
UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Unpacking initramfs...
Freeing initrd memory: 27492K (ffffffc01e520000 - ffffffc01fff9000)
kvm [1]: error: no compatible GIC node found
kvm [1]: error initializing Hyp mode: -19
ACPI: IORT: can't find node related to (null) device
futex hash table entries: 4096 (order: 7, 524288 bytes)
audit: initializing netlink subsys (disabled)
audit: type=2000 audit(1.720:1): initialized
HugeTLB registered 2 MB page size, pre-allocated 0 pages
VFS: Disk quotas dquot_6.6.0
VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
NFS: Registering the id_resolver key type
Key type id_resolver registered
Key type id_legacy registered
fuse init (API version 7.23)
9p: Installing v9fs 9p2000 file system support
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler noop registered
io scheduler cfq registered (default)
pcieport 0001:00:00.0: can't derive routing for PCI INT A
pcieport 0001:00:00.0: PCI INT A: no GSI
pcieport 0002:40:00.0: can't derive routing for PCI INT A
pcieport 0002:40:00.0: PCI INT A: no GSI
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
console [ttyS0] disabled
APMC0D08:00: ttyS0 at MMIO 0x80300000 (irq = 5, base_baud = 12500000) is a 16550A
console [ttyS0] enabled
console [ttyS0] enabled
bootconsole [uart0] disabled
bootconsole [uart0] disabled
msm_serial: driver initialized
Failed to find cpu0 device node
Unable to detect cache hierarchy from DT for CPU 0
loop: module loaded
hisi_sas: driver version v1.0
scsi host0: hisi_sas
scsi host1: hisi_sas
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
libphy: Hisilicon MII Bus: probed
hisi_sas_v1_hw HISI0161:01: phyup: phy7 link_rate=10
scsi 1:0:0:0: Direct-Access SEAGATE ST9500620SS AS02 PQ: 0 ANSI: 5
sd 1:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA
sd 1:0:0:0: [sda] Attached SCSI disk
hns-nic HISI00C1:00: No valid mac, use random mac da:3a:ad:09:a3:14
netif_napi_add() called with weight 256 on device eth%d
hns-nic HISI00C1:01: No valid mac, use random mac ea:58:90:0b:08:bc
hns-nic HISI00C1:02: No valid mac, use random mac 2a:ef:14:d5:0f:41
hns-nic HISI00C1:03: No valid mac, use random mac 7a:77:63:4e:57:89
ixgbe: Intel(R) 10 Gigabit PCI Express Network Driver - version 4.2.1-k
ixgbe: Copyright (c) 1999-2015 Intel Corporation.
pcieport 0002:40:00.0: can't derive routing for PCI INT A
ixgbe 0002:41:00.0: PCI INT A: no GSI
ixgbe 0002:41:00.0: enabling device (0000 -> 0002)
ixgbe 0002:41:00.0: Multiqueue Enabled: Rx Queue count = 16, Tx Queue count = 16
ixgbe 0002:41:00.0: PCI Express bandwidth of 32GT/s available
ixgbe 0002:41:00.0: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%)
ixgbe 0002:41:00.0: MAC: 2, PHY: 17, SFP+: 5, PBA No: FFFFFF-0FF
ixgbe 0002:41:00.0: 68:a8:28:2e:c9:10
ixgbe 0002:41:00.0: Intel(R) 10 Gigabit Network Connection
pcieport 0002:40:00.0: can't derive routing for PCI INT B
ixgbe 0002:41:00.1: PCI INT B: no GSI
ixgbe 0002:41:00.1: enabling device (0000 -> 0002)
ixgbe 0002:41:00.1: Multiqueue Enabled: Rx Queue count = 16, Tx Queue count = 16
ixgbe 0002:41:00.1: PCI Express bandwidth of 32GT/s available
ixgbe 0002:41:00.1: (Speed:5.0GT/s, Width: x8, Encoding Loss:20%)
ixgbe 0002:41:00.1: MAC: 2, PHY: 1, PBA No: FFFFFF-0FF
ixgbe 0002:41:00.1: 68:a8:28:2e:c9:11
ixgbe 0002:41:00.1: Intel(R) 10 Gigabit Network Connection
sky2: driver version 1.30
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
ehci-pci: EHCI PCI platform driver
ehci-platform: EHCI generic platform driver
ehci-platform PNP0D20:00: EHCI Host Controller
ehci-platform PNP0D20:00: new USB bus registered, assigned bus number 1
ehci-platform PNP0D20:00: irq 6, io mem 0xa1000000
ehci-platform PNP0D20:00: USB 2.0 started, EHCI 1.00
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ohci-pci: OHCI PCI platform driver
ohci-platform: OHCI generic platform driver
usbcore: registered new interface driver usb-storage
mousedev: PS/2 mouse device common for all mice
rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
Synopsys Designware Multimedia Card Interface Driver
sdhci-pltfm: SDHCI platform and OF driver helper
ledtrig-cpu: registered to indicate activity on CPUs
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
NET: Registered protocol family 17
9pnet: Installing 9P2000 support
Key type dns_resolver registered
registered taskstats version 1
rtc-efi rtc-efi: setting system clock to 2100-01-01 00:02:52 UTC (4102444972)
ttyS0 - failed to request DMA
Freeing unused kernel memory: 572K (ffffffc0008f0000 - ffffffc00097f000)
Freeing alternatives memory: 60K (ffffffc00097f000 - ffffffc00098e000)
root@(none)$ ifconfig eth4 192.168.20.188
ixgbe 0002:41:00.0: registered PHC device on eth4
root@(none)$ ixgbe 0002:41:00.0 eth4: detected SFP+: 5
ixgbe 0002:41:00.0 eth4: NIC Link is Up 10 Gbps, Flow Control: RX/TX
root@(none)$ ping 192.168.20.4
PING 192.168.20.4 (192.168.20.4): 56 data bytes
64 bytes from 192.168.20.4: seq=21 ttl=128 time=0.368 ms
64 bytes from 192.168.20.4: seq=22 ttl=128 time=0.257 ms
64 bytes from 192.168.20.4: seq=23 ttl=128 time=0.316 ms
64 bytes from 192.168.20.4: seq=24 ttl=128 time=0.355 ms
64 bytes from 192.168.20.4: seq=25 ttl=128 time=0.257 ms
64 bytes from 192.168.20.4: seq=26 ttl=128 time=0.305 ms
64 bytes from 192.168.20.4: seq=27 ttl=128 time=0.290 ms
64 bytes from 192.168.20.4: seq=28 ttl=128 time=0.227 ms
64 bytes from 192.168.20.4: seq=29 ttl=128 time=3.865 ms
64 bytes from 192.168.20.4: seq=30 ttl=128 time=0.297 ms
^ permalink raw reply [flat|nested] 184+ messages in thread
* Re: [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
2016-01-13 13:20 ` Tomasz Nowicki
@ 2016-02-01 19:58 ` Duc Dang
-1 siblings, 0 replies; 184+ messages in thread
From: Duc Dang @ 2016-02-01 19:58 UTC (permalink / raw)
To: Tomasz Nowicki
Cc: Bjorn Helgaas, Arnd Bergmann, Will Deacon, Catalin Marinas, rjw,
Hanjun Guo, Lorenzo Pieralisi, okaya, Jiang Liu,
Stefano.Stabellini, robert.richter, mw, Liviu Dudau, ddaney,
Thomas Gleixner, Yijing Wang, Suravee Suthikulpanit, msalter,
linux-pci, linux-arm, linux-acpi, Linux Kernel Mailing List,
linaro-acpi, Jayachandran C, Jon Masters
On Wed, Jan 13, 2016 at 5:20 AM, Tomasz Nowicki <tn@semihalf.com> 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.
Hi Tomasz,
I tested your tree with APM X-Gene v1 and X-Gene v2 platforms and PCIe
came up fine on both platforms (with X-Gene ECAM fixup patch that I
will post separately). Thanks for your work and please feel free to
add my Tested-by.
Regards,
Duc Dang.
>
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 184+ messages in thread* [PATCH V3 00/21] MMCONFIG refactoring and support for ARM64 PCI hostbridge init based on ACPI
@ 2016-02-01 19:58 ` Duc Dang
0 siblings, 0 replies; 184+ messages in thread
From: Duc Dang @ 2016-02-01 19:58 UTC (permalink / raw)
To: linux-arm-kernel
On Wed, Jan 13, 2016 at 5:20 AM, Tomasz Nowicki <tn@semihalf.com> 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 at 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.
Hi Tomasz,
I tested your tree with APM X-Gene v1 and X-Gene v2 platforms and PCIe
came up fine on both platforms (with X-Gene ECAM fixup patch that I
will post separately). Thanks for your work and please feel free to
add my Tested-by.
Regards,
Duc Dang.
>
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 184+ messages in thread