Linaro-acpi

linaro-acpi@lists.linaro.org

820 discussions

[PATCH v4 00/13] Enable ACPI on ARM64 in Kconfig

by Hanjun Guo

This patch set is the first part of ARM64 ACPI core patches to running ACPI on ARM64, it just handle some compile errors when ACPI is introduced to ARM64 platform and enable ACPI on ARM64 in Kconfig. Following core patch sets for ACPI based SMP/GIC/Arch Timer initialization to enable ACPI on ARM64 are under interally review and will send out when ACPI 5.1 is released. patch 1~3 are cleanups for ACPI core; patch 4~13 are arch dependent code for ARM64 ACPI; This patch set is based on linux-next branch of Rafael's linux-pm tree, and PCI patches for ARM64 from Liviu: Support for creating generic host_bridge from device tree https://lkml.org/lkml/2014/3/14/279 Add support for PCI in AArch64 http://comments.gmane.org/gmane.linux.ports.arm.kernel/309392 Changes since v3: - Introduce three new patches - acpi: arm64 does not have a BIOS add config for BIOS table scan - ACPI: Don't use acpi_lapic in ACPI core code - ARM64 / ACPI: if we chose to boot from acpi then disable FDT - Rebase on the latest linux-next branch of Rafael's tree, and introduce asm/acenv.h for ARM64; - Introduce ARCH_HAS_ACPI_PDC to move all the _PDC related code to a single place and make x86 and ia64 select ARCH_HAS_ACPI_PDC; - Fix some checpatch warning; - Fix broken Signed-off-by chain; - Remove duplicate interface macros for ACPICA pointed out by Mark Rutland and Zheng Lv; - Redefine ACPI_FLUSH_CPU_CACHE(); - Stub out some PCI functions suggested by Arnd and already merged into 3.16 Comments still need to be addressed: - Empty PCI implementation in arch/arm64 which suggested by Arnd; - suspend and sleep on ARM64 platform pointed out by Lorenzo; Changes since v2: - Make ACPI depend on PCI on ARM64 - rework all the patches and seperate some of the patches into fine-grained, and add some comments and changelog to make it easier for review. Al Stone (3): ARM64 / ACPI: Introduce arm-core.c and its related head file ARM64 / ACPI: Introduce early_param for "acpi" ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Graeme Gregory (6): acpi: arm64 does not have a BIOS add config for BIOS table scan. ACPI: Don't use acpi_lapic in ACPI core code ARM64 : Add dummy asm/cpu.h ARM64 / ACPI: Introduce lowlevel suspend function ARM64 / ACPI: if we chose to boot from acpi then disable FDT ARM64 / ACPI: Enable ARM64 in Kconfig Hanjun Guo (4): ACPI / processor: Introduce ARCH_HAS_ACPI_PDC ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology ARM64 / ACPI: Introduce PCI functions for ACPI on ARM64 ACPI: Make EC debugfs depend on X86 || IA64 in Kconfig Documentation/kernel-parameters.txt | 3 +- arch/arm64/Kconfig | 3 + arch/arm64/include/asm/acenv.h | 18 +++ arch/arm64/include/asm/acpi.h | 61 +++++++++++ arch/arm64/include/asm/cpu.h | 11 ++ arch/arm64/include/asm/pci.h | 6 + arch/arm64/include/asm/topology.h | 2 + arch/arm64/kernel/pci.c | 28 +++++ arch/arm64/kernel/setup.c | 7 +- arch/arm64/kernel/topology.c | 14 +++ arch/ia64/Kconfig | 2 + arch/ia64/include/asm/acpi.h | 5 + arch/x86/Kconfig | 2 + arch/x86/include/asm/acpi.h | 5 + drivers/acpi/Kconfig | 19 +++- drivers/acpi/Makefile | 3 + drivers/acpi/acpi_processor.c | 2 +- drivers/acpi/internal.h | 5 + drivers/acpi/osl.c | 4 +- drivers/acpi/plat/Makefile | 1 + drivers/acpi/plat/arm-core.c | 138 +++++++++++++++++++++++ drivers/acpi/processor_core.c | 198 --------------------------------- drivers/acpi/processor_pdc.c | 206 +++++++++++++++++++++++++++++++++++ 23 files changed, 539 insertions(+), 204 deletions(-) create mode 100644 arch/arm64/include/asm/acenv.h create mode 100644 arch/arm64/include/asm/acpi.h create mode 100644 arch/arm64/include/asm/cpu.h create mode 100644 drivers/acpi/plat/Makefile create mode 100644 drivers/acpi/plat/arm-core.c create mode 100644 drivers/acpi/processor_pdc.c -- 1.7.9.5

12 years

[RFC v2 0/3] ACPI Platform Communication Channel driver

by Ashwin Chaugule

Hello, This patchset adds initial support for the PCC (Platform Communication Channel) interface as described in the current ACPI 5.0a 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 (Platform Communication Channel) 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. While the PCC clients will come as following patches whenever they're ready, I wanted to get feedback on this common driver and hope that it could be merged upstream. This should hopefully help various folks that are working on drivers that rely on the PCC interface. Cheers, Ashwin === Testing Methodology === The PCC test driver in [2/2] is a simple driver that was used to demonstrate how PCC clients would use the PCC driver. The PCC driver was tested by sending multiple PCC READS and PCC WRITES across a shared memory region on an MSM ARMv7 platform. This memory is shared between an apps processor and a power controller processor. So, one end of the PCC channel is the PCC test driver running on the apps processor and the other end is a debugger script (running on a JTAG debugger) thats attached to the power processor. The debugger script is busy looping on the doorbell address waiting for a bit to flip. This bit indicates a synchronous communication from the apps processor. The doorbell is rung when the OS sends a PCC READ or PCC WRITE command. The PCC communication channel is simply a few fake 32 bit registers that are incremented by the OS and the debugger script. The OS increments the registers and then sends the PCC WRITE command. On a PCC READ, the script increments these registers and then OS reads them back. The values are always incremented by 1 by either end, so we know what value to expect for each PCC READ/WRITE. === Changelog === Changes since V1: - Integration with Mailbox framework - https://lkml.org/lkml/2014/5/15/49 Ashwin Chaugule (3): Mailbox: Add support for ACPI ACPI: Add support for Platform Communication Channel PCC test driver drivers/acpi/Makefile | 2 +- drivers/acpi/pcc-test.c | 208 ++++++++++++++++++++++++++++++++++ drivers/acpi/pcc.c | 225 +++++++++++++++++++++++++++++++++++++ drivers/mailbox/Kconfig | 11 ++ drivers/mailbox/mailbox.c | 155 ++++++++++++++++--------- include/linux/mailbox_client.h | 3 + include/linux/mailbox_controller.h | 6 + 7 files changed, 557 insertions(+), 53 deletions(-) create mode 100644 drivers/acpi/pcc-test.c create mode 100644 drivers/acpi/pcc.c -- 1.8.3.2

12 years

[PATCH v3 0/5] APEI: Make APEI architecture independent.

by Tomasz Nowicki

APEI is currently implemented so that it depends on x86 hardware. The primary dependency is that GHES uses the x86 NMI for hardware error notification and MCE for memory error handling. These patches remove that dependency. Other APEI features such as error reporting via external IRQ, error serialization, or error injection, do not require changes to use them on non-x86 architectures. The following patch set eliminates the APEI Kconfig x86 dependency by making these changes: - treat NMI notification as GHES feature - ARCH_HAS_ACPI_APEI_NMI - reorganize GHES notification type init/deinitialization so that we can decide in run time whether NMI is supported or not - identify architectural boxes and abstract it accordingly (NMI and MCE) - rework ioremap for both IRQ and NMI context NMI code is kept in ghes.c file since NMI and IRQ context are tightly coupled. Note, these patches introduce no functional changes for x86. The NMI notification feature is hard selected for x86. Architectures that want to use this feature should also provide NMI code infrastructure. V1->V2 - address Borislav's comment - abstract arch-specific calls instead of wrapping into the #ifdef V2->V3 - address Robert's comment - disable ACPI_APEI_NMI selection so that it is hard selected by arch Kconfig - rename ACPI_APEI_NMI to ARCH_HAS_ACPI_APEI_NMI Tomasz Nowicki (5): apei, mce: Factor out APEI architecture specific MCE calls. acpi, apei, ghes: Introduce ARCH_HAS_ACPI_APEI_NMI to make NMI error notification a GHES feature. acpi, apei, ghes: Introduce more generic mechanism to init/deinit GHES error notifications. apei, ghes, nmi: Factor out NMI arch-specific calls. acpi, apei, ghes: Factor out ioremap virtual memory for IRQ and NMI context. arch/x86/Kconfig | 1 + arch/x86/kernel/acpi/Makefile | 1 + arch/x86/kernel/acpi/apei.c | 87 ++++++++++++ drivers/acpi/apei/Kconfig | 8 +- drivers/acpi/apei/apei-base.c | 32 +++++ drivers/acpi/apei/ghes.c | 301 +++++++++++++++++++++++++---------------- drivers/acpi/apei/hest.c | 29 +--- include/acpi/apei.h | 11 ++ 8 files changed, 327 insertions(+), 143 deletions(-) create mode 100644 arch/x86/kernel/acpi/apei.c -- 1.7.9.5

12 years

leg-kernel tag leg-20140614.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-20140614.0 This is based on mainline kernel v3.15 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: https://git.linaro.org/leg/acpi/leg-kernel.git/commit/380fd57c0626a74594446… Notes :-

12 years

[PATCH v2 0/5] APEI: Make APEI architecture independent.

by Tomasz Nowicki

APEI is currently implemented so that it depends on x86 hardware. The primary dependency is that GHES uses the x86 NMI for hardware error notification and MCE for memory error handling. These patches remove that dependency. Other APEI features such as error reporting via external IRQ, error serialization, or error injection, do not require changes to use them on non-x86 architectures. The following patch set eliminates the APEI Kconfig x86 dependency by making these changes: - treat NMI notification as GHES feature - CONFIG_ACPI_APEI_NMI - reorganize GHES notification type init/deinitialization so that we can decide in run time whether NMI is supported or not - identify architectural boxes and abstract it accordingly (NMI and MCE) - rework ioremap for both IRQ and NMI context NMI code is kept in ghes.c file since NMI and IRQ context are tightly coupled. Note, these patches introduce no functional changes for x86. The NMI notification feature is selected for x86 by default. Architectures that want to use this feature should also provide NMI code infrastructure. V1->V2 - address Borislav comment - abstract arch-specific calls instead of wrapping into the #ifdef Tomasz Nowicki (5): apei, mce: Factor out APEI architecture specific MCE calls. acpi, apei, ghes: Introduce ACPI_APEI_NMI to make NMI error notification a GHES feature. acpi, apei, ghes: Introduce more generic mechanism to init/deinit GHES error notifications. apei, ghes, nmi: Factor out NMI arch-specific calls. acpi, apei, ghes: Factor out ioremap virtual memory for IRQ and NMI context. arch/x86/kernel/acpi/Makefile | 1 + arch/x86/kernel/acpi/apei.c | 87 ++++++++++++ drivers/acpi/apei/Kconfig | 10 +- drivers/acpi/apei/apei-base.c | 32 +++++ drivers/acpi/apei/ghes.c | 301 +++++++++++++++++++++++++---------------- drivers/acpi/apei/hest.c | 26 +--- include/acpi/apei.h | 11 ++ 7 files changed, 328 insertions(+), 140 deletions(-) create mode 100644 arch/x86/kernel/acpi/apei.c -- 1.7.9.5

12 years

[RFC PATCH 0/3] ACPI: Add vexpress-sysreg

by naresh.bhat＠linaro.org

From: Naresh Bhat <naresh.bhat(a)linaro.org> Add vexpress sysreg probe support, platform ID and remove dts binding. Logs on the v8 model are as below root@genericarmv8:/sys# find . -name LINA0009* ./bus/acpi/devices/LINA0009:00 ./bus/platform/devices/LINA0009:00 ./bus/platform/drivers/vexpress-sysreg/LINA0009:00 ./devices/platform/LINA0009:00 ./devices/LNXSYSTM:00/device:00/ACPI0004:01/ACPI0004:02/LINA0009:00 root@genericarmv8:/sys# Naresh Bhat (3): v2m_sysreg: Add ACPI probing for SYSREG ACPI: Add vexpress sysreg platform ID arm64: dts: remove the vexpress-sysreg binding arch/arm64/boot/dts/foundation-v8-acpi.dts | 6 +++--- drivers/acpi/acpi_platform.c | 3 ++- drivers/mfd/vexpress-sysreg.c | 9 +++++++++ 3 files changed, 14 insertions(+), 4 deletions(-) -- 1.7.9.5

12 years

[PATCH] acpi: arm64 does not have a BIOS add config for BIOS table scan.

by Graeme Gregory

With the addition of ARM64 that does not have a traditional BIOS to scan add a config option which is selected on x86 and ia64 to do the traditional BIOS scanning for tables. Signed-off-by: Graeme Gregory <graeme.gregory(a)linaro.org> --- arch/ia64/Kconfig | 1 + arch/x86/Kconfig | 1 + drivers/acpi/Kconfig | 3 +++ drivers/acpi/osl.c | 4 +++- 4 files changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig index 12c3afe..42a210f6 100644 --- a/arch/ia64/Kconfig +++ b/arch/ia64/Kconfig @@ -46,6 +46,7 @@ config IA64 select MODULES_USE_ELF_RELA select ARCH_USE_CMPXCHG_LOCKREF select HAVE_ARCH_AUDITSYSCALL + select ACPI_SCAN_BIOS_NOT_EFI default y help The Itanium Processor Family is Intel's 64-bit successor to diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 25d2c6f..d89c6060 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -130,6 +130,7 @@ config X86 select HAVE_CC_STACKPROTECTOR select GENERIC_CPU_AUTOPROBE select HAVE_ARCH_AUDITSYSCALL + select ACPI_SCAN_BIOS_NOT_EFI config INSTRUCTION_DECODER def_bool y diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index d726e17..1550ea8 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -40,6 +40,9 @@ menuconfig ACPI <http://www.acpi.info> <http://www.uefi.org/acpi/specs> +config ACPI_SCAN_BIOS_NOT_EFI + bool + if ACPI config ACPI_SLEEP diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index 147bc1b..54f8247 100644 --- a/drivers/acpi/osl.c +++ b/drivers/acpi/osl.c @@ -258,12 +258,14 @@ acpi_physical_address __init acpi_os_get_root_pointer(void) "System description tables not found\n"); return 0; } - } else { + } else if (IS_ENABLED(CONFIG_ACPI_SCAN_BIOS_NOT_EFI)) { acpi_physical_address pa = 0; acpi_find_root_pointer(&pa); return pa; } + + return 0; } /* Must be called with 'acpi_ioremap_lock' or RCU read lock held. */ -- 2.0.0

12 years, 1 month

leg-kernel tag leg-20140603.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-20140603.0 This is based on mainline kernel v3.15-rc8 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: http://git.linaro.org/leg/acpi/leg-kernel.git/commit/379f632a429b7d9768efd0… Notes :- This release contains the PCC driver written by Ashwin Chaugule for testing.

12 years, 1 month

[RFC 0/2] Experimental support for PCC and CPPC

by Ashwin Chaugule

This series contains experimental patchwork for PCC and CPPC as defined in the current ACPI5.0a spec. The PCC patch was tested on an ARMv7 platform and on a hacked up PCC emulator. The CPPC part is only compile tested. Both are very much a WIP. Any feedback and help with testing would be highly appreciated! Ashwin Chaugule (2): ACPI: Add support for Platform Communication Channel CPPC: Initial support for Collaborative Processor Performance Control arch/arm64/Kconfig | 2 + drivers/acpi/Kconfig | 10 ++ drivers/acpi/Makefile | 2 +- drivers/acpi/pcc.c | 209 +++++++++++++++++++++++++++++ drivers/cpufreq/Kconfig | 11 +- drivers/cpufreq/Makefile | 1 + drivers/cpufreq/cppc-cpufreq.c | 298 +++++++++++++++++++++++++++++++++++++++++ 7 files changed, 531 insertions(+), 2 deletions(-) create mode 100644 drivers/acpi/pcc.c create mode 100644 drivers/cpufreq/cppc-cpufreq.c -- 1.8.3.2

12 years, 1 month

[RFC 0/2] ACPI Platform Communication Channel driver

by Ashwin Chaugule

Hello, This patchset adds initial support for the PCC (Platform Communication Channel) interface as described in the current ACPI 5.0a 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 (Platform Communication Channel) 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. While the PCC clients will come as following patches whenever they're ready, I wanted to get feedback on this common driver and hope that it could be merged upstream. This should hopefully help various folks that are working on drivers that rely on the PCC interface. Cheers, Ashwin === Testing Methodology === The PCC test driver in [2/2] is a simple driver that was used to demonstrate how PCC clients would use the PCC driver. The PCC driver was tested by sending multiple PCC READS and PCC WRITES across a shared memory region on an MSM ARMv7 platform. This memory is shared between an apps processor and a power controller processor. So, one end of the PCC channel is the PCC test driver running on the apps processor and the other end is a debugger script (running on a JTAG debugger) thats attached to the power processor. The debugger script is busy looping on the doorbell address waiting for a bit to flip. This bit indicates a synchronous communication from the apps processor. The doorbell is rung when the OS sends a PCC READ or PCC WRITE command. The PCC communication channel is simply a few fake 32 bit registers that are incremented by the OS and the debugger script. The OS increments the registers and then sends the PCC WRITE command. On a PCC READ, the script increments these registers and then OS reads them back. The values are always incremented by 1 by either end, so we know what value to expect for each PCC READ/WRITE. Ashwin Chaugule (2): ACPI: Add support for Platform Communication Channel PCC Test driver drivers/acpi/Kconfig | 10 +++ drivers/acpi/Makefile | 2 +- drivers/acpi/pcc-test.c | 172 +++++++++++++++++++++++++++++++++++++++++++ drivers/acpi/pcc.c | 192 ++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 375 insertions(+), 1 deletion(-) create mode 100644 drivers/acpi/pcc-test.c create mode 100644 drivers/acpi/pcc.c -- 1.8.3.2

12 years, 1 month

← Newer
1
...
43
44
45
46
47
48
49
...
82
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-acpi