Linaro-acpi January 2014

linaro-acpi@lists.linaro.org

24 participants
28 discussions

[PATCH 0/4 v2] Add tool to enable APEI tables test, other minor changes.

by Tomasz Nowicki

Patch set implement as follows: 1. Minor changes around existing tools - reorganize building process, - move common code to separate direction, - no functionality changes. 2. Add BFAPEI (Blob For APEI) tool which can create blobs for APEI testing. - see commit log for more details Changes for v2: - compilation regardless of whether APEI is used or not, - correct file name in comment headers, - move ACPI structures, defines, etc. to acpi.h headers, - suppress compiler warnings. Tomasz Nowicki (4): map, cab: Reorganize building process and tree hierarchy. bfapei: Add tool that can create blobs for APEI table testing. bfapei: Move generic ACPI structures to separated file, remove duplicated defines. Suppress compiler warnings, file comment headers cleanup. Makefile | 28 +- platforms/Makefile | 9 +- tools/bfapei/Makefile | 11 + tools/bfapei/bfapei.c | 271 +++++++++++++++++++ tools/bfapei/bfapei.h | 49 ++++ tools/cab/Makefile | 12 +- tools/cab/cab.c | 535 +------------------------------------- tools/cab/cab.h | 149 ----------- tools/common/Makefile | 4 + tools/common/build_aml.c | 455 ++++++++++++++++++++++++++++++++ tools/common/check_aml.c | 512 ++++++++++++++++++++++++++++++++++++ tools/common/include/acpi.h | 204 +++++++++++++++ tools/common/include/build_aml.h | 74 ++++++ tools/common/include/check_aml.h | 92 +++++++ tools/mab/Makefile | 13 +- tools/mab/mab.c | 437 +------------------------------ tools/mab/mab.h | 77 ------ 17 files changed, 1734 insertions(+), 1198 deletions(-) create mode 100644 tools/bfapei/Makefile create mode 100644 tools/bfapei/bfapei.c create mode 100644 tools/bfapei/bfapei.h create mode 100644 tools/common/Makefile create mode 100644 tools/common/build_aml.c create mode 100644 tools/common/check_aml.c create mode 100644 tools/common/include/acpi.h create mode 100644 tools/common/include/build_aml.h create mode 100644 tools/common/include/check_aml.h -- 1.7.9.5

7 years, 9 months

[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

10 years, 7 months

[RFC PATCH 0/5] Introducing the Grand Unified Firmware Interface

by al.stone＠linaro.org

From: Al Stone <al.stone(a)linaro.org> These patches are purely experimental; they just barely compile and they do not run just yet. The reason for posting them is really just to stir some discussion and see if this is a truly crazy idea or if it has some potential for easing the ACPI transition. These patches introduce GUFI: the Grand Unified Firmware Interface. Okay, yes, it is a silly name. I didn't spend a lot of time on it. What I'm most interested in is the idea and whether it is worth pursuing further, and whether or not there are better ways to do this if it does make sense. The idea is very simple: introduce a shim layer that looks like a merge of some sort between ACPI and FDT functionality in the kernel. In that shim layer, make it possible for a driver to make a single call to a function, and with that call, retrieve configuration information stored in either ACPI tables or a DT. Further, allow the kernel to specify which has priority -- i.e., search through ACPI tables, and then through FDT if data is not found, or vice versa -- or which is exclusive, either ACPI or FDT only. Why would I do this? As a kernel developer, this allows me to make changes in the direction of either FDT or ACPI as quickly or as slowly as I want to. Most of my config can be in FDT and I can then piecemeal convert to ACPI as I figure out ASL and/or any driver changes that may be needed. Secondly, if I do this well, the changes to convert from FDT to ACPI *should* be very small; from ACPI to FDT may be much more difficult but over time that can likely be improved as well. Third, in the really, really long term, maybe someone comes up with yet another hardware configuration description format that is so cool it provides sharks with laser beams on their heads and *everyone* wants to convert to it. With this layer in place, perhaps we can smooth even that transition by abstracting out the config info that's needed and the API to retrieve it. So, what do you think? Al Stone (5): ACPI: GUFI: add kernel config options for GUFI ACPI: GUFI: add build commands for drivers/gufi ACPI: GUFI: add in early prototype code for some GUFI functions ACPI: GUFI: add in simple test driver placeholders ACPI: GUFI: start modifying the vexpress-sysreg driver to use the GUFI arch/arm64/Kconfig | 6 - drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/acpi/acpi_platform.c | 1 + drivers/gufi/Kconfig | 54 ++++++++ drivers/gufi/Makefile | 11 ++ drivers/gufi/gufi.c | 309 ++++++++++++++++++++++++++++++++++++++++++ drivers/gufi/gufi_acpi_test.c | 84 ++++++++++++ drivers/gufi/gufi_of_test.c | 83 ++++++++++++ drivers/mfd/vexpress-sysreg.c | 14 +- include/linux/gufi.h | 83 ++++++++++++ 11 files changed, 636 insertions(+), 12 deletions(-) create mode 100644 drivers/gufi/Kconfig create mode 100644 drivers/gufi/Makefile create mode 100644 drivers/gufi/gufi.c create mode 100644 drivers/gufi/gufi_acpi_test.c create mode 100644 drivers/gufi/gufi_of_test.c create mode 100644 include/linux/gufi.h -- 1.8.3.1

10 years, 9 months

[linaro-acpi PATCH v2 0/4] acpi-asl: DBG2 table template support

by naresh.bhat＠linaro.org

From: Naresh Bhat <naresh.bhat(a)linaro.org> The DBG2 table support in iASL compiler will be available in the next release of acpica https://github.com/acpica/acpica/commit/278cbb119f090d3aad0480381126c1ae8e5… the following set of patches support the DBG2 table template in acpi-asl tool. Naresh Bhat (4): ACPI / ASL: Add DBG2 table template DBG2: Update platforms manifest DBG2: Update xsdt entries across platforms DBG2: Support DBG2 table compilation platforms/exynos5250-arndale.acpi/dbg2.asl | 106 ++++++++++++++++++++ .../exynos5250-arndale.manifest | 1 + platforms/exynos5250-arndale.acpi/xsdt.asl | 1 + platforms/foundation-v8.acpi/dbg2.asl | 106 ++++++++++++++++++++ .../foundation-v8.acpi/foundation-v8.manifest | 1 + platforms/foundation-v8.acpi/xsdt.asl | 1 + platforms/rtsm_ve-aemv8a.acpi/dbg2.asl | 106 ++++++++++++++++++++ .../rtsm_ve-aemv8a.acpi/rtsm_ve-aemv8a.manifest | 1 + platforms/rtsm_ve-aemv8a.acpi/xsdt.asl | 1 + tools/common/build_aml.c | 1 + tools/common/check_aml.c | 1 + tools/common/include/check_aml.h | 1 + 12 files changed, 327 insertions(+) create mode 100644 platforms/exynos5250-arndale.acpi/dbg2.asl create mode 100644 platforms/foundation-v8.acpi/dbg2.asl create mode 100644 platforms/rtsm_ve-aemv8a.acpi/dbg2.asl -- 1.7.9.5

10 years, 9 months

Re: [Linaro-acpi] draft of blog post - UEFI and ACPI

by Grant Likely

My blog post on ACPI and UEFI has now gone public. Here's the link: http://www.secretlab.ca/archives/27 Jennifer, you can go ahead and publish on the Linaro blog also. g.

10 years, 11 months

[PATCH 00/20] Make ACPI core running on ARM64

by Hanjun Guo

This patch set trys to make ACPI core running on ARM64. 1. Why ACPI is needed ? ACPI provides standard interfaces for power managment, themal control, device enumeration and configuration and etc. So ACPI can make OS and hardware decoupling and make people upgrade software or hardware more easily. ACPI is more than that. It can provide standard error report interface called ACPI Platform Error Interface (APEI) for RAS features, and provide standard interface for dynamic system device reconfigurations such as CPU/memory/computer node hot-add and hot-remove, this is especially useful for servers. 2. Does ACPI run propably on ARM64 ? ACPI spec 5.0 introduces hardware reduced mode, GICC/GICD, GTDT for arch timer and etc for Socs. This makes it possible to run ACPI on ARM/ARM64. Some company already did that (UEFI+ACPI) on ARM platforms. ACPI spec for ARM/ARM64 is still need to be improved and people are working on that, but for now, we can run ACPI propably except for some new features such as PSCI and GICv3. 3. What we did in this patch set patch 1-8(Hanjun Guo) will make ACPI core running on ARM64 and make the compilation is ok on ARM64. patch 9-12 will enumeration cpus presented by MADT table. since PSCI is not available for ACPI 5.0, we use spin-table method for SMP initialization. patch 13-16 will initialize GIC in the system. ACPI only support one GIC and only report information about GICC and GICD, so there will some limitations for GICv3 and GICH for GICv2 for virtualization. patch 17-19 and patch from Amit will finish the arch timer initialization. We get informatiom from GTDT (Generic Timer Description Table) to initialize arch timer and introduce a macro CLOCKSOURCE_ACPI_DECLARE to do the same job as CLOCKSOURCE_OF_DECLARE to make it scalable for other timers. All the ACPI tables are available with BSD license at: git://git.linaro.org/arm/acpi/acpi-asl.git Changs since last RFC version: 1) Introduce some PCI functions when PCI is enabled 2) Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled 3) Remove ACPI based CPU hotplug code 4) Use spin-table method for SMP initialization 5) Add macro CLOCKSOURCE_ACPI_DECLARE for ACPI timer init 6) Address lots of comments and suggestions in last RFC version 7) Remove RFC tag and make all the patches seperated as two parts, one is "ACPI: Some patches to prepare for running ACPI on !x86 and !ia64", and another is this one. 8) Rebased on 3.13-rc8. Amit Daniel Kachhap (1): clocksource / acpi: Add macro CLOCKSOURCE_ACPI_DECLARE Hanjun Guo (19): ARM64 / ACPI: Make PCI optional for ACPI on ARM64 ARM64 : Add dummy asm/cpu.h ARM64 / ACPI: Introduce the skeleton of _PDC related for ARM64 ARM64 / ACPI: Introduce arm_core.c and its related head file ARM64 / ACPI: Introduce lowlevel suspend function ARM64 / ACPI: Introduce some PCI functions when PCI is enabled ARM64 / ACPI: Enable ARM64 in Kconfig ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 ARM64 / ACPI: Implement core functions for parsing MADT table ARM64 / ACPI: Enumerate possible/present CPU set and map logical cpu id to APIC id ARM64 / ACPI: Get the enable method for SMP initialization ARM64 / ACPI: Use Parked Address in GIC structure for spin table SMP initialisation ARM64 / ACPI: Define ACPI_IRQ_MODEL_GIC needed for arm Irqchip / gic: Set as default domain so we can access from ACPI ACPI / ARM64: Update acpi_register_gsi to register with the core IRQ subsystem ACPI / GIC: Initialize GIC using the information in MADT clocksource / arch_timer: Use ACPI GTDT table to initialize arch timer clocksource / ACPI: Introduce clocksource_acpi_init() using CLOCKSOURCE_ACPI_DECLARE ARM64 / clocksource: Use clocksource_acpi_init() arch/arm64/Kconfig | 3 + arch/arm64/Makefile | 1 + arch/arm64/include/asm/acpi.h | 112 +++++++ arch/arm64/include/asm/cpu.h | 25 ++ arch/arm64/include/asm/cpu_ops.h | 1 + arch/arm64/include/asm/pci.h | 20 ++ arch/arm64/include/asm/processor.h | 2 + arch/arm64/include/asm/smp.h | 2 +- arch/arm64/kernel/cpu_ops.c | 2 +- arch/arm64/kernel/irq.c | 6 + arch/arm64/kernel/process.c | 3 + arch/arm64/kernel/setup.c | 6 + arch/arm64/kernel/smp.c | 42 ++- arch/arm64/kernel/smp_spin_table.c | 12 +- arch/arm64/kernel/time.c | 6 + arch/arm64/pci/Makefile | 1 + arch/arm64/pci/pci.c | 33 ++ drivers/acpi/Kconfig | 11 +- drivers/acpi/Makefile | 4 +- drivers/acpi/bus.c | 3 + drivers/acpi/internal.h | 7 + drivers/acpi/osl.c | 3 +- drivers/acpi/plat/Makefile | 1 + drivers/acpi/plat/arm-core.c | 599 ++++++++++++++++++++++++++++++++++ drivers/acpi/tables.c | 21 ++ drivers/clocksource/Makefile | 1 + drivers/clocksource/arm_arch_timer.c | 101 +++++- drivers/clocksource/clksrc-acpi.c | 36 ++ drivers/irqchip/irq-gic.c | 7 + include/asm-generic/vmlinux.lds.h | 10 + include/linux/acpi.h | 7 + include/linux/clocksource.h | 15 + include/linux/pci.h | 33 +- 33 files changed, 1099 insertions(+), 37 deletions(-) create mode 100644 arch/arm64/include/asm/acpi.h create mode 100644 arch/arm64/include/asm/cpu.h create mode 100644 arch/arm64/include/asm/pci.h create mode 100644 arch/arm64/pci/Makefile create mode 100644 arch/arm64/pci/pci.c create mode 100644 drivers/acpi/plat/Makefile create mode 100644 drivers/acpi/plat/arm-core.c create mode 100644 drivers/clocksource/clksrc-acpi.c -- 1.7.9.5

10 years, 11 months

[PATCH 1/2] ACPI / ACPICA: refactor acpi_evaluate_object() to reduce nesting if

by Hanjun Guo

acpi_evaluate_object() has nesting if judgement to make code a little bit complicated, refactor it to make things simple. Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org> --- drivers/acpi/acpica/nsxfeval.c | 104 +++++++++++++++++++--------------------- 1 file changed, 50 insertions(+), 54 deletions(-) diff --git a/drivers/acpi/acpica/nsxfeval.c b/drivers/acpi/acpica/nsxfeval.c index 1f0c28b..a1b0b88 100644 --- a/drivers/acpi/acpica/nsxfeval.c +++ b/drivers/acpi/acpica/nsxfeval.c @@ -370,68 +370,64 @@ acpi_evaluate_object(acpi_handle handle, * If we are expecting a return value, and all went well above, * copy the return value to an external object. */ - if (return_buffer) { - if (!info->return_object) { - return_buffer->length = 0; - } else { - if (ACPI_GET_DESCRIPTOR_TYPE(info->return_object) == - ACPI_DESC_TYPE_NAMED) { - /* - * If we received a NS Node as a return object, this means that - * the object we are evaluating has nothing interesting to - * return (such as a mutex, etc.) We return an error because - * these types are essentially unsupported by this interface. - * We don't check up front because this makes it easier to add - * support for various types at a later date if necessary. - */ - status = AE_TYPE; - info->return_object = NULL; /* No need to delete a NS Node */ - return_buffer->length = 0; - } + if (!return_buffer) + goto out; - if (ACPI_SUCCESS(status)) { + if (!info->return_object) { + return_buffer->length = 0; + goto out; + } - /* Dereference Index and ref_of references */ + if (ACPI_GET_DESCRIPTOR_TYPE(info->return_object) == + ACPI_DESC_TYPE_NAMED) { + /* + * If we received a NS Node as a return object, this means that + * the object we are evaluating has nothing interesting to + * return (such as a mutex, etc.) We return an error because + * these types are essentially unsupported by this interface. + * We don't check up front because this makes it easier to add + * support for various types at a later date if necessary. + */ + status = AE_TYPE; + info->return_object = NULL; /* No need to delete a NS Node */ + return_buffer->length = 0; + } - acpi_ns_resolve_references(info); + if (ACPI_FAILURE(status)) + goto out; - /* Get the size of the returned object */ + /* Dereference Index and ref_of references */ - status = - acpi_ut_get_object_size(info->return_object, - &buffer_space_needed); - if (ACPI_SUCCESS(status)) { - - /* Validate/Allocate/Clear caller buffer */ - - status = - acpi_ut_initialize_buffer - (return_buffer, - buffer_space_needed); - if (ACPI_FAILURE(status)) { - /* - * Caller's buffer is too small or a new one can't - * be allocated - */ - ACPI_DEBUG_PRINT((ACPI_DB_INFO, - "Needed buffer size %X, %s\n", - (u32) - buffer_space_needed, - acpi_format_exception - (status))); - } else { - /* We have enough space for the object, build it */ - - status = - acpi_ut_copy_iobject_to_eobject - (info->return_object, - return_buffer); - } - } - } + acpi_ns_resolve_references(info); + + /* Get the size of the returned object */ + + status = acpi_ut_get_object_size(info->return_object, + &buffer_space_needed); + if (ACPI_SUCCESS(status)) { + + /* Validate/Allocate/Clear caller buffer */ + + status = acpi_ut_initialize_buffer(return_buffer, + buffer_space_needed); + if (ACPI_FAILURE(status)) { + /* + * Caller's buffer is too small or a new one can't + * be allocated + */ + ACPI_DEBUG_PRINT((ACPI_DB_INFO, + "Needed buffer size %X, %s\n", + (u32)buffer_space_needed, + acpi_format_exception(status))); + } else { + /* We have enough space for the object, build it */ + + status = acpi_ut_copy_iobject_to_eobject( + info->return_object, return_buffer); } } +out: if (info->return_object) { /* * Delete the internal return object. NOTE: Interpreter must be -- 1.7.9.5

10 years, 11 months

[PATCH] Platform / wmi: Fix potential memory leak in parse_wdg()

by Hanjun Guo

we forgot to call wmi_free_devices() and free out.pointer when alloc mamory failed. Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org> --- drivers/platform/x86/wmi.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c index 43d1329..e1338b5 100644 --- a/drivers/platform/x86/wmi.c +++ b/drivers/platform/x86/wmi.c @@ -797,8 +797,11 @@ static int parse_wdg(acpi_handle handle) wmi_dump_wdg(&gblock[i]); wblock = kzalloc(sizeof(struct wmi_block), GFP_KERNEL); - if (!wblock) - return -ENOMEM; + if (!wblock) { + wmi_free_devices(); + retval = -ENOMEM; + goto out_free_pointer; + } wblock->handle = handle; wblock->gblock = gblock[i]; -- 1.7.9.5

10 years, 11 months

Updating UEFI to latest ACPI tables

by Graeme Gregory

Hi Guys, This patch updates the hardcoded tables in UEFI to the latest version produced by the ACPI team. This is the version that allows the FVP model to boot completely from ACPI. Can this please go into 2014.01 release? Graeme

10 years, 11 months

[PATCH] watchdog: Add sp805_wdt depends on ARM64

by naresh.bhat＠linaro.org

From: Naresh Bhat <naresh.bhat(a)linaro.org> Add sp805_wdt depends on ARM64. Signed-off-by: Naresh Bhat <naresh.bhat(a)linaro.org> --- drivers/watchdog/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 5be6e91..2385124 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -109,7 +109,7 @@ config WM8350_WATCHDOG config ARM_SP805_WATCHDOG tristate "ARM SP805 Watchdog" - depends on ARM && ARM_AMBA + depends on (ARM || ARM64) && ARM_AMBA select WATCHDOG_CORE help ARM Primecell SP805 Watchdog timer. This will reboot your system when -- 1.7.9.5

10 years, 11 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-acpi January 2014