ACPI core patches for ARM64 are now upstreamed in 4.1. Also PCI support
patches for ARM64 ACPI are in progress, I am sending out this RFC to
introduce ACPI support for GICv2m. This would allow MSI to work when
booting ACPI.
This patch series modify existing IRQ domain and ACPI GSI code
to better support ACPI on ARM64.
Summary:
* Patch 1,2 introduce the new irq_domain_ops.init_alloc_info().
* Patch 3,4 modify the existing irq_domain_ops.match() to support ACPI.
* Patch 5,6 introduce IRQ domain for ARM64 ACPI.
* Patch 7 introduces ACPI support for GICv2m.
Due to a large number of prerequisite patches, I have put together a branch
on GitHub for review and testing:
https://github.com/ssuthiku/linux.git acpi-pci-msi-rfc1
This branch has been tested on AMD Seattle Platform. Any feedback and
comments are appreciated.
Thank you in advance,
Suravee
Suravee Suthikulpanit (7):
irqdomain: Introduce irq_domain_ops.init_alloc_info
gic: Add gic_init_irq_alloc_info()
irqdomain: Introduce irqdomain matching by reference
Adopting the new irq_domain_ops.match() function prototype
acpi: gsi: Adding irqdomain for ACPI
acpi: gsi: Adding ARM64-specific acpi_register_gsi()
gicv2m: Introducing ACPI support for GICv2m
arch/arm64/kernel/acpi.c | 62 ++++++++-
arch/powerpc/platforms/512x/mpc5121_ads_cpld.c | 4 +-
arch/powerpc/platforms/cell/interrupt.c | 4 +-
arch/powerpc/platforms/powermac/pic.c | 4 +-
arch/powerpc/platforms/ps3/interrupt.c | 4 +-
arch/powerpc/sysdev/ehv_pic.c | 4 +-
arch/powerpc/sysdev/i8259.c | 4 +-
arch/powerpc/sysdev/ipic.c | 4 +-
arch/powerpc/sysdev/mpic.c | 4 +-
arch/powerpc/sysdev/qe_lib/qe_ic.c | 4 +-
arch/powerpc/sysdev/xics/xics-common.c | 4 +-
drivers/acpi/gsi.c | 23 +++-
drivers/irqchip/irq-gic-v2m.c | 172 ++++++++++++++++++++-----
drivers/irqchip/irq-gic.c | 98 ++++++++++++--
drivers/pci/pci-acpi.c | 52 ++++++++
drivers/pci/probe.c | 2 +
include/linux/acpi.h | 4 +
include/linux/irqchip/arm-gic-acpi.h | 5 +-
include/linux/irqchip/arm-gic.h | 11 ++
include/linux/irqdomain.h | 17 ++-
include/linux/pci-acpi.h | 2 +
kernel/irq/irqdomain.c | 41 ++++--
22 files changed, 453 insertions(+), 76 deletions(-)
--
2.1.0
From: "Jonathan (Zhixiong) Zhang" <zjzhang(a)codeaurora.org>
UEFI spec allows for non-standard (eg. vendor proprietary) error
section in CPER (COmmon Platform Error Record), as defined in section
N2.3 of UEFI version 2.5.
If section Type field of Generic Error Data Entry matches with one
of the GUID as defined in include/linux/cper.h, print out the raw data
in dmesg buffer, and also add a tracepoint for reporting such error.
Jonathan (Zhixiong) Zhang (2):
efi: parse vendor proprietary CPER section
ras: acpi/apei: trace event for vendor proprietary CPER section
drivers/firmware/efi/cper.c | 61 +++++++++++++++++++++++++++++++++++++++++++--
include/linux/cper.h | 4 +++
drivers/acpi/apei/ghes.c | 29 +++++++++++++++++++++++++++--
drivers/ras/ras.c | 1 +
include/ras/ras_event.h | 30 ++++++++++++++++++++++++++++++
5 files changed, 121 insertions(+), 4 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
From: "Jonathan (Zhixiong) Zhang" <zjzhang(a)codeaurora.org>
On a platform with APEI (ACPI Platform Error Interface) enabled, firmware
updates a memory region with hardware error record using nocache
attribute. When OS reads the region, since it maps the region with
cacahed attribute even though EFI memory map defines this region as
uncached, OS gets stale data and errorneously reports there is no new
HW error.
When ghes driver maps the memory region, it uses the cache attribute
according to EFI memory map, if EFI memory map feature is enabled
at runtime.
Since both arch/x86 and arch/ia64 implemented architecture agnostic EFI
memory map attribue lookup function efi_memattributes(), the code is
moved from arch/x86 into EFI subsystem and is declared as __weak; archs
other than ia64 should not override the default implementation.
V6:
1. Implemented arch_apei_get_mem_attributes() for arm64 as inline
function.
2. Rebased to efi-next-14364 of efi/next, pm+acpi-4.2-rc3 of
linux-pm/master, arm64-upstream-13521 of arm64/master,
next-20150720 of linux-next/master.
V5:
1. Rebased to next-20150713 of linux-next/master, efi-next-14359 of
efi/next, pm+acpi-4.2-rc2 of linux-pm/master,
arm64-fixes-1215 of arm64/master.
2. Added comment for efi_mem_attributes(), explained why it is marked
as __weak at the function definition site.
V4:
1. Introduced arch_apei_get_mem_attributes() to allow arch specific
implementation of getting pgprot_t appropriate for a physical
address.
2. Implemented arch_apei_get_mem_attributes() for x86 and for arm64.
V3:
1. Rebased to v4.1-rc7.
2. Moved efi_mem_attributes() from arch/x86 to drivers/firmware/efi
and declared it as __weak.
3. Introduced ARCH_APEI_PAGE_KERNEL_UC to allow arch specific page
protection type for UC.
4. Removed efi_ioremap(). It can not be used for GHES memory region
mapping purpose since ioremap can not be used in atomic context.
V2:
1. Rebased to v4.1-rc5.
2. Split removal of efi_mem_attributes() and creation of efi_ioremap()
into two patches.
Jonathan (Zhixiong) Zhang (4):
efi: x86: rearrange efi_mem_attributes()
x86: acpi: implement arch_apei_get_mem_attributes()
arm64: apei: implement arch_apei_get_mem_attributes()
acpi, apei: use appropriate pgprot_t to map GHES memory
arch/arm64/include/asm/acpi.h | 15 +++++++++++++++
arch/x86/kernel/acpi/apei.c | 10 ++++++++++
arch/x86/platform/efi/efi.c | 18 ------------------
drivers/acpi/apei/ghes.c | 6 ++++--
drivers/firmware/efi/efi.c | 31 +++++++++++++++++++++++++++++++
include/acpi/apei.h | 1 +
6 files changed, 61 insertions(+), 20 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
Hi Matt/Borislav, thanks for the discussion. I am sorry that somehow
I did not see this message in my inbox. I found it by surprise through
an internet search.
> On Mon, 22 Jun, at 06:11:31AM, Matt Fleming wrote:
>>
>> Right, but see my previous comment about x86 discarding a bunch of
>> attributes for memory regions because the kernel "knows better".
>>
>> And in most places, yes, the kernel really does know better. But this
>> APEI case is special because irrespective of what the kernel says we
>> want to be compatible with the firmware's memory map.
>>
>> And we don't have an API for that.
>
> Maybe what we want is a new PAGE_* protection that is compatible with
> any firmware mappings? That'd be nice because we wouldn't have to
> introduce a whole new API for this GHES case and ioremap_* could do
> whatever it wanted under the hood.
>
> Thougts?
>
Agree. That being said, I do not know if this GHES case is the only
user case that will benefit from such framework. If it is, then it may
be controversial to introduce a framework for only one use case.
To me, there are two ways that will help GHES case:
a. Define ioremap_page_range_[no]cache() functions for archs, similar
like the case for ioremap_[no]cache.
b. Define a set of PAGE_* protection types (in particular
PAGE_KERNEL_NOCACHE). Right now it seems like only a few protection
types (such as PAGE_KERNEL) are defined across the archs.
--
Jonathan (Zhixiong) Zhang
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
From: "Jonathan (Zhixiong) Zhang" <zjzhang(a)codeaurora.org>
On a platform with APEI (ACPI Platform Error Interface) enabled, firmware
updates a memory region with hardware error record using nocache
attribute. When OS reads the region, since it maps the region with
cacahed attribute even though EFI memory map defines this region as
uncached, OS gets stale data and errorneously reports there is no new
HW error.
When ghes driver maps the memory region, it uses the cache attribute
according to EFI memory map, if EFI memory map feature is enabled
at runtime.
Since both arch/x86 and arch/ia64 implemented architecture agnostic EFI
memory map attribue lookup function efi_memattributes(), the code is
moved from arch/x86 into EFI subsystem and is declared as __weak; archs
other than ia64 should not override the default implementation.
V5:
1. Rebased to next-20150713 of linux-next/master, efi-next-14359 of
efi/next, pm+acpi-4.2-rc2 of linux-pm/master,
arm64-fixes-1215 of arm64/master.
2. Added comment for efi_mem_attributes(), explained why it is marked
as __weak at the function definition site.
V4:
1. Introduced arch_apei_get_mem_attributes() to allow arch specific
implementation of getting pgprot_t appropriate for a physical
address.
2. Implemented arch_apei_get_mem_attributes() for x86 and for arm64.
V3:
1. Rebased to v4.1-rc7.
2. Moved efi_mem_attributes() from arch/x86 to drivers/firmware/efi
and declared it as __weak.
3. Introduced ARCH_APEI_PAGE_KERNEL_UC to allow arch specific page
protection type for UC.
4. Removed efi_ioremap(). It can not be used for GHES memory region
mapping purpose since ioremap can not be used in atomic context.
V2:
1. Rebased to v4.1-rc5.
2. Split removal of efi_mem_attributes() and creation of efi_ioremap()
into two patches.
Jonathan (Zhixiong) Zhang (4):
efi: x86: rearrange efi_mem_attributes()
x86: acpi: implement arch_apei_get_mem_attributes()
arm64: apei: implement arch_apei_get_mem_attributes()
acpi, apei: use appropriate pgprot_t to map GHES memory
arch/arm64/kernel/apei.c | 11 +++++++++++
arch/x86/kernel/acpi/apei.c | 10 ++++++++++
arch/x86/platform/efi/efi.c | 18 ------------------
drivers/acpi/apei/ghes.c | 6 ++++--
drivers/firmware/efi/efi.c | 31 +++++++++++++++++++++++++++++++
include/acpi/apei.h | 1 +
6 files changed, 57 insertions(+), 20 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
This patch set introduce self-probe infrastructure to init IRQ
controllers and stacked irqdomain support for ACPI based GICv2/3
init.
This patch set add its support for GIC verion which is introduced
in ACPI 6.0, based on that, we introduce the self-probe infrastructure,
the self-probe infrastructure for ACPI GIC init is similar as
IRQCHIP_DECLARE() and based on the GIC version support in ACPI
MADT table. we match the GIC version and GIC driver and load
it.
After the self-probe infrastructure is ready, I cleanuped the GICv2
code to use the framework.
Patch 4 implement the stacked irqdomain support for GICv2 based on
the model of mapping interrupt and device in ACPI.
Patch 5~8 are ACPI based GICv3 init.
Any comments are warmly welcomed.
v2->v3:
- Introduced a mechanism to match the GSI with its irqdomain instead of
referring to the acpi_irq_domain in previous version
- Add finding GICR base address in GICC structures in GICv3 code.
- Address the comments from Lorenzo and Marc
- Rebased on top of 4.2-rc1, since ACPICA patches were pushed to
4.2 by Rafael, I removed ACPICA patches in previous version.
v1->v2:
- Remove the gicv2/v3 related driver code in drivers/irqchip/irq-gic-acpi.c
which I was trying to consolidate them in one file, then arm-gic.h and
arm-gic-v3.h will be used separately within parent driver only
- Drop the gsi_mutex patch
- Use the GIC version to match the GIC driver, then no need to test
for the version in each driver
- Move acpi_irq_init() to drivers/irqchip/irq-gic-acpi.c instead of
in drivers/acpi/irq.c. maybe we need to rename acpi_irq_init() as
acpi_gic_init() but I keep that name to accommodate of_irq_init(),
any objections please let me know.
update from RFC version:
- Consolidate all the GIC init code into drivers/irqchip/irq-gic-acpi.c
Hanjun Guo (6):
irqchip / GIC: Add GIC version support in ACPI MADT
ACPI / irqchip: Add self-probe infrastructure to initialize IRQ
controller
irqchip / GIC / ACPI: Use IRQCHIP_ACPI_DECLARE to simplify GICv2 init
code
irqchip / gic: Add stacked irqdomain support for ACPI based GICv2 init
irqchip / GICv3: Add stacked irqdomain support for ACPI based init
irqchip / gicv3 / ACPI: Add GICR support via GICC structures
Tomasz Nowicki (2):
irqchip / GICv3: Refactor gic_of_init() for GICv3 driver
irqchip / GICv3: Add ACPI support for GICv3+ initialization
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/acpi.h | 1 -
arch/arm64/include/asm/irq.h | 13 --
arch/arm64/kernel/acpi.c | 25 --
drivers/acpi/gsi.c | 78 +++++--
drivers/irqchip/Kconfig | 3 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-gic-acpi.c | 171 ++++++++++++++
drivers/irqchip/irq-gic-v3.c | 427 ++++++++++++++++++++++++++++++-----
drivers/irqchip/irq-gic.c | 40 ++--
include/asm-generic/vmlinux.lds.h | 13 ++
include/linux/acpi.h | 21 ++
include/linux/acpi_irq.h | 4 +-
include/linux/irqchip.h | 13 ++
include/linux/irqchip/arm-gic-acpi.h | 10 +-
include/linux/mod_devicetable.h | 8 +
16 files changed, 695 insertions(+), 134 deletions(-)
create mode 100644 drivers/irqchip/irq-gic-acpi.c
--
1.9.1
IORT, IO remapping tables, which is a table to describe the connections
of PCI root complex, devices, ITS (msi controller) and SMMU, for example,
it presents the topology of which device under which SMMU and(or) ITS.
This patch set first do some cleanup for the ITS dirver, then init the ITS
with the information presented by MADT ITS entries, then follows the IORT spec,
implementing:
- PCI root complex using ITS as msi controller, mapping its domain (segemnt)
number with the MSI controller;
- init the SMMU and use the mapping of PCI and no-PCI device to SMMU to
connect them
- No-PCI devices using MSI (connect to ITS) is not covered by this patch
set.
please refer to the ARM documentation:
http://infocenter.arm.com/help/topic/com.arm.doc.den0049a/DEN0049A_IO_Remap…
This patch set is based on Tomasz Nowicki's work, but I rework some of
the patches significantly, more work is needed for this patch set
and I'm still not satisfy with the some of implementation, anyway, I
will continue working on that, and at the same time, sending them out
for review to see if there are some major problems.
you can get them form
git://git.linaro.org/leg/acpi/acpi.git devel
Comments and test are warmly welcomed.
Hanjun Guo (5):
irqchip / GICv3: remove gic root node in ITS
irqchip / GICv3 / ITS: mark its_init() as __init
irqchip/GICv3/ITS: refator ITS dt init code to prepare for ACPI
irqchip: gicv3: its: probe ITS in ACPI way
ARM64, ACPI, PCI, MSI: I/O Remapping Table (IORT) initial support.
Tomasz Nowicki (2):
arm, smmu: Use more generic structure for SMMU master list.
ARM64, ACPI, IORT: Bind SMMU driver via IORT table
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/iort.c | 536 +++++++++++++++++++++++++++++++++++++++
drivers/acpi/pci_root.c | 2 +
drivers/iommu/arm-smmu.c | 290 ++++++++++++++++-----
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-gic-v3-its.c | 188 ++++++++++----
include/linux/iort.h | 63 +++++
8 files changed, 966 insertions(+), 118 deletions(-)
create mode 100644 drivers/acpi/iort.c
create mode 100644 include/linux/iort.h
--
1.9.1
Currently, the BAD_MADT_ENTRY macro is used to do a very simple sanity
check on the various subtables that are defined for the MADT. The check
compares the size of the subtable data structure as defined by ACPICA to
the length entry in the subtable. If they are not the same, the assumption
is that the subtable is incorrect.
Over time, the ACPI spec has allowed for MADT subtables where this can
never be true (the local SAPIC subtable). Or, more recently, the spec
has accumulated some minor flaws where there are three possible sizes for
a subtable, all of which are valid, but only for specific versions of the
spec (the GICC subtable). In both cases, BAD_MADT_ENTRY reports these
subtables as bad when they are not. In order to retain some sanity check
on the MADT subtables, we now have to special case these subtables. Of
necessity, these special cases have ended up in arch-dependent code (arm64)
or an arch has simply decided to forgo the check (ia64).
This patch set replaces the BAD_MADT_ENTRY macro with a function called
bad_madt_entry(). This function uses a data set of details about the
subtables to provide more sanity checking than before:
-- is the subtable legal for the version given in the FADT?
-- is the subtable legal for the revision of the MADT in use?
-- is the subtable of the proper length (including checking
on the one variable length subtable), given the FADT version
and the MADT revision?
Further, this patch set adds in the call to bad_madt_entry() from the
acpi_table_parse_madt() function, allowing it to be used consistently
by all architectures, for all subtables, and removing the need for each
of the subtable traversal callback functions to use BAD_MADT_ENTRY.
In theory, as the ACPI specification changes, we would only have to add
additional information to the data set describing the MADT subtables in
order to continue providing sanity checks, even when new subtables are
added.
These patches have been tested on an APM Mustang (arm64) and are known to
work there. They have NOT been tested anywhere else yet.
Al Stone (5):
ACPI: add in a bad_madt_entry() function to eventually replace the
macro
ACPI / ARM64: remove usage of BAD_MADT_ENTRY/BAD_MADT_GICC_ENTRY
ACPI / IA64: remove usage of BAD_MADT_ENTRY
ACPI / X86: remove usage of BAD_MADT_ENTRY
ACPI: remove definition of BAD_MADT_ENTRY macro
arch/arm64/include/asm/acpi.h | 8 --
arch/arm64/kernel/perf_event.c | 3 -
arch/arm64/kernel/smp.c | 2 -
arch/ia64/kernel/acpi.c | 20 ----
arch/x86/kernel/acpi/boot.c | 27 -----
drivers/acpi/tables.c | 241 +++++++++++++++++++++++++++++++++++++++++
drivers/irqchip/irq-gic-v2m.c | 2 -
drivers/irqchip/irq-gic.c | 6 -
include/linux/acpi.h | 4 -
9 files changed, 241 insertions(+), 72 deletions(-)
--
2.4.3