this is the RFC version of ACPI based NUMA support for ARM64,
it is based on 3.18-rc4 and v5 of ARM64 ACPI core patches, it also
based on DT based NUMA patch from Ganapatrao [1].
Have not tested yet, will do that after posted this patch
for RFC, any comment are welcomed.
[1] http://www.spinics.net/lists/arm-kernel/msg380197.html
Ganapatrao Kulkarni (1):
arm64:numa: adding numa support for arm64 platforms.
Hanjun Guo (4):
ACPI / NUMA: Use pr_fmt() instead of printk
ACPI / NUMA: Remove redundant ACPI_DEBUG_OUTPUT
ARM64 / ACPI: NUMA support based on SRAT and SLIT
ACPI / NUMA: Enable ACPI based NUMA on ARM64
arch/arm64/Kconfig | 33 ++
arch/arm64/include/asm/acpi.h | 3 +
arch/arm64/include/asm/mmzone.h | 32 ++
arch/arm64/include/asm/numa.h | 46 +++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/acpi_numa.c | 176 +++++++++++
arch/arm64/kernel/setup.c | 10 +
arch/arm64/kernel/smp.c | 2 +
arch/arm64/mm/Makefile | 1 +
arch/arm64/mm/init.c | 34 +-
arch/arm64/mm/numa.c | 675 ++++++++++++++++++++++++++++++++++++++++
drivers/acpi/Kconfig | 2 +-
drivers/acpi/numa.c | 64 ++--
drivers/acpi/processor_core.c | 5 +
include/acpi/processor.h | 1 +
include/linux/acpi.h | 15 +
16 files changed, 1074 insertions(+), 26 deletions(-)
create mode 100644 arch/arm64/include/asm/mmzone.h
create mode 100644 arch/arm64/include/asm/numa.h
create mode 100644 arch/arm64/kernel/acpi_numa.c
create mode 100644 arch/arm64/mm/numa.c
--
1.9.1
Changes since V10:
- Replace array with dynamic allocation.
- Rename index to subspace_id to avoid confusion.
- Use latency instead of min turnaround time.
Changes since V9:
- Default to PCC subspace headers as defined in ACPI v5.1
Changes since V8:
- Removed unncessary header files.
- Added kerneldoc comments.
- Added intro about PCC in pcc.c
Changes since V7:
- Added timeout to tx method in case the remote dies.
- Restructured usage of acpi_status. Had inverted logic previously.
Changes since V6:
- Cosmetic changes based on Lv's suggestions
Changes since V5:
- Optimize loop that matches channel request.
- Use platform_create_bundle.
- Replace ioread/writes.
- Remove redundant code and headers.
- Restructure common mailbox macros.
- Reformat PCC cmd parsing.
Changes since V4:
- Folded PCC Mailbox helpers into pcc.c
Changes since V3:
- Added PCC helper functions to work around "struct device" limitations.
- PCC driver changes to work with PCC specific Mailbox helpers.
Changes since V2:
- Rebased on top of git://git.linaro.org/landing-teams/working/fujitsu/integration.git
branch mailbox-for-3.17
- Added PCC API to mailbox framework as per Arnd's suggestion to allow usage without ACPI.
Changes since V1:
- Integration with Mailbox framework - https://lkml.org/lkml/2014/5/15/49
This patchset adds support for the PCC (Platform Communication Channel)
interface as described in the current ACPI 5.0 spec. See Section 14 of the
ACPI spec - http://acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf for more details
on how PCC works.
In brief PCC is a generic means for PCC clients, to talk to the firmware. The
PCC register space is typically memory mapped IO and uses a doorbell mechanism
to communicate synchronously from the OS to the firmware. The PCC driver is
completely agnostic to the protocol implemented by the PCC clients. It only
implements the enumeration of PCC channels and the low level transport mechanism
and leaves the rest to the PCC clients.
The PCC is meant to be useable in the future by clients such as CPPC
(Collaborative Processor Performance Control), RAS (Reliability,
Availability and Serviceability) and MPST (Memory Power State Tables) and possibly others.
Ashwin Chaugule (1):
Mailbox: Add support for Platform Communication Channel
drivers/mailbox/Kconfig | 12 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/mailbox.c | 4 +-
drivers/mailbox/mailbox.h | 16 ++
drivers/mailbox/pcc.c | 403 ++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 434 insertions(+), 3 deletions(-)
create mode 100644 drivers/mailbox/mailbox.h
create mode 100644 drivers/mailbox/pcc.c
--
1.9.1
Hi,
Just a small series to enable better testing of ACPI in LAVA without having
to fetch and built test suites with git.
Changes since v1 :-
Missed a hunk from aapits patch that prevents test results being overwritten
on test end.
Thanks
Graeme
Some cleanups to convert apic_id to phys_id to accommodate
ACPI 5.0+.
updates since v1:
- rebase on top of linux-next git repo to slove the conflicts
with IOAPIC hotplug patch
- modify patch 2 to update the comments and print message using
arch independent words instead of APIC
Hanjun Guo (3):
ACPI / processor: Update the comments in processor.h
ACPI / processor: Convert apic_id to phys_id to make it arch agnostic
ACPI / processor: Rename acpi_(un)map_lsapic() to acpi_(un)map_cpu()
arch/ia64/kernel/acpi.c | 9 ++++---
arch/x86/kernel/acpi/boot.c | 9 ++++---
drivers/acpi/acpi_processor.c | 25 ++++++++++---------
drivers/acpi/processor_core.c | 56 +++++++++++++++++++++----------------------
include/acpi/processor.h | 12 ++++++----
include/linux/acpi.h | 4 ++--
6 files changed, 59 insertions(+), 56 deletions(-)
--
1.9.1
Hi,
So over the last couple of days I have been looking into the test
suites we currently have available in the leg-kernel CI/test cycle and
come to the following conclusions.
1) aapits - tests the core of the acpica code, does not test anything
in the kernel or the BIOS. Is unmaintained by acpica folks and Tomasz
patches have sat idle on bug tracker for 3/4 of a year. This test
suite does not test anything we are interested in I propose we drop it
from CI.
2) acpica-tools - tests the iasl compiler, is run on every tools
packaging for rpm/deb. I suggest the tools CI/packaging cycles are a
better location for these tests and we drop them from CI
3) acpi-smoke-test - This is the basic test that we booted from ACPI,
I think this is useful to keep as a quick getout of testing if it
fails.
4) FWTS - current target of our testing for BIOS testing. This we keep.
So I am suggesting we only have tests that exercise the kernel or BIOS
in some manner. We are still lacking in tests that exercise the kernel
but I have no idea what these tests should be at current time.
Thanks
Graeme