Linaro-acpi

linaro-acpi@lists.linaro.org

820 discussions

[PATCH] ARM64 / ACPI: Introduce early_param "acpi=" to enable/disable ACPI

by Ard Biesheuvel

Per the request of Hanjun, and due to my involvement in the discussion regarding adding /chosen node properties to the EFI stub<->kernel interface, here is a patch that implements the policy that we discussed, i.e., to enable ACPI explicitly if acpi=force is set, and to enable it implicitly if the device tree has no nodes at depth 1 other than the /chosen node (in which case the device tree is considered to be empty). We did not discuss the acpi=off case, but this patch changes its handling from 'enable ACPI implicitly if the EFI stub generated the DTB' (which is what Hanjun implemented) to 'ACPI is disabled period' (which is arguably more appropriate) This patch replaces the following two patches ARM64 / ACPI: Introduce early_param for "acpi" and pass acpi=force to enable ACPI dt / chosen: Add linux,uefi-stub-generated-dtb property -------------->8------------------ This implements the following policy to decide whether ACPI should be used to boot the system: - acpi=off: ACPI will not be used to boot the system, even if there is no alternative available (e.g., device tree is empty) - acpi=force: only ACPI will be used to boot the system; if that fails, there will be no fallback to alternative methods (such as device tree) - otherwise, ACPI will be used as a fallback if the device tree turns out to lack a platform description; the heuristic to decide this is whether /chosen is the only node present at depth 1 CC: Catalin Marinas <catalin.marinas(a)arm.com> CC: Will Deacon <will.deacon(a)arm.com> CC: Rafael J. Wysocki <rjw(a)rjwysocki.net> Signed-off-by: Al Stone <al.stone(a)linaro.org> Signed-off-by: Graeme Gregory <graeme.gregory(a)linaro.org> Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> --- Documentation/kernel-parameters.txt | 3 ++- arch/arm64/kernel/acpi.c | 54 +++++++++++++++++++++++++++++++++---- 2 files changed, 51 insertions(+), 6 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 176d4fe4f076..d6a952ec4433 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -165,7 +165,7 @@ multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 2^20, and 2^30 bytes respectively. Such letter suffixes can also be entirely omitted. - acpi= [HW,ACPI,X86] + acpi= [HW,ACPI,X86,ARM64] Advanced Configuration and Power Interface Format: { force | off | strict | noirq | rsdt } force -- enable ACPI if default was off @@ -175,6 +175,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. strictly ACPI specification compliant. rsdt -- prefer RSDT over (default) XSDT copy_dsdt -- copy DSDT to memory + For ARM64, ONLY "acpi=off" or "acpi=force" are available See also Documentation/power/runtime_pm.txt, pci=noacpi diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index 7f67c011261b..732ad0d075f5 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -20,15 +20,49 @@ #include <linux/irq.h> #include <linux/irqdomain.h> #include <linux/memblock.h> +#include <linux/of_fdt.h> #include <linux/smp.h> -int acpi_noirq; /* skip ACPI IRQ initialization */ -int acpi_disabled; +int acpi_noirq = 1; /* skip ACPI IRQ initialization */ +int acpi_disabled = 1; EXPORT_SYMBOL(acpi_disabled); -int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */ +int acpi_pci_disabled = 1; /* skip ACPI PCI scan and IRQ initialization */ EXPORT_SYMBOL(acpi_pci_disabled); +static bool __initdata param_acpi_off; +static bool __initdata param_acpi_force; + +static int __init parse_acpi(char *arg) +{ + if (!arg) + return -EINVAL; + + /* "acpi=off" disables both ACPI table parsing and interpreter */ + if (strcmp(arg, "off") == 0) + param_acpi_off = true; + else if (strcmp(arg, "force") == 0) /* force ACPI to be enabled */ + param_acpi_force = true; + else + return -EINVAL; /* Core will print when we return error */ + + return 0; +} +early_param("acpi", parse_acpi); + +static int __init dt_scan_depth1_nodes(unsigned long node, + const char *uname, int depth, + void *data) +{ + /* + * Return 1 as soon as we encounter a node at depth 1 that is + * not the /chosen node. + */ + if (depth == 1 && (strcmp(uname, "chosen") != 0)) + return 1; + return 0; +} + /* * __acpi_map_table() will be called before page_init(), so early_ioremap() * or early_memremap() should be called here to for ACPI table mapping. @@ -59,10 +93,20 @@ void __init __acpi_unmap_table(char *map, unsigned long size) */ void __init acpi_boot_table_init(void) { - /* If acpi_disabled, bail out */ - if (acpi_disabled) + /* + * Enable ACPI instead of device tree unless + * - ACPI has been disabled explicitly (acpi=off), or + * - the device tree is not empty (it has more than just a /chosen node) + * and ACPI has not been force enabled (acpi=force) + */ + if (param_acpi_off || + (!param_acpi_force && of_scan_flat_dt(dt_scan_depth1_nodes, NULL))) return; + acpi_disabled = 0; + acpi_pci_disabled = 0; + acpi_noirq = 0; + /* Initialize the ACPI boot-time table parser. */ if (acpi_table_init()) disable_acpi(); -- 1.8.3.2

9 years, 7 months

leg-kernel tag leg-20150216.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-20150216.0 This is based on mainline kernel v3.19 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: https://git.linaro.org/leg/acpi/leg-kernel.git/commit/2eaf1f1ee1d722cacf15f… Notes :- 1) This release only supports Juno/FVP until updated topics for Seattle and Mustang are available. 2) This release incorporates the SBSA UART support for pl011 driver from Andre Przywara. This means that your console will become ttyAMA0 (console=ttyAMA0) on Juno/FVP. It also means to run FVP model you need these options :- -C bp.pl011_uart0.untimed_fifos=0 -C bp.pl011_uart0.revision="r1p5"

9 years, 7 months

Re: [Linaro-acpi] [PATCH v8 00/21] Introduce ACPI for ARM64 based on ACPI 5.1

by Jonathan (Zhixiong) Zhang

On 02/02/2015 05:45 AM, Hanjun Guo wrote: > From: Al Stone <al.stone at linaro.org> > > Two more documentation files are also being added: > (1) A verbatim copy of the "Why ACPI on ARM?" blog posting by Grant Likely, > which is also summarized in arm-acpi.txt, and > > (2) A section by section review of the ACPI spec (acpi_object_usage.txt) > to note recommendations and prohibitions on the use of the numerous > ACPI tables and objects. This sets out the current expectations of > the firmware by Linux very explicitly (or as explicitly as I can, for > now). > [snip....] > +ERST Section 18.5 (signature == "ERST") > + == Error Record Serialization Table == > + Must be supplied if RAS support is provided by the platform. It > + is recommended this table be supplied. The above text related to ERST table could lead to misunderstanding. Following is what the ACPI spec (section 18.5) says: "The error record serialization feature is used to save and retrieve hardware error information to and from a persistent store. OSPM interacts with the platform through a platform interface. On UEFI-based platforms, the UEFI runtime variable services can be used to carry out error record persistence operations. On non-UEFI based platforms, the ACPI solution described below is used." When RAS support is provided by the platform, ERST table may not be supplied when it is UEFI-based and when UEFI run time service provides the ability to save and retrieve hardware error information to and from a persistent store (UEFI spec section 7.2.3). Therefore, following text might be more accurate: " On a platform supports RAS, this table must be supplied if it is not UEFI-based; if it is UEFI-based, this table may be supplied, consult your firmware vendor if you are not sure. When this table is not present, UEFI run time service will be utilized to save and retrieve hardware error information to and from a persistent store." ==== Jonathan (Zhixiong) Zhang Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

9 years, 7 months

[V3 PATCH 0/2] Introduce ACPI support for ahci_platform driver

by Suravee Suthikulpanit

This patch series introduce ACPI support for non-PCI AHCI platform driver. Existing ACPI support for AHCI assumes the device controller is a PCI device. Also, since there is no ACPI _HID/_CID for generic AHCI controller, the driver could not use them for matching devices. Therefore, this patch introduces a mechanism for drivers to match devices using ACPI _CLS method. This patch series is rebased from and tested with: http://git.linaro.org/leg/acpi/acpi.git acpi-5.1-v8 This topic was discussed earlier here (as part of introducing support for AMD Seattle SATA controller): http://marc.info/?l=linux-arm-kernel&m=141083492521584&w=2 Changes from V2 (https://lkml.org/lkml/2015/1/5/662) * Update with review comment from Rafael in patch 1/2 * Rebased and tested with acpi-5.1-v8 Changes from V1 (https://lkml.org/lkml/2014/12/19/345) * Rebased to 3.19.0-rc2 * Change from acpi_cls in device_driver to acpi_match_cls (Hanjun comment) * Change the matching logic in acpi_driver_match_device() due to the new special PRP0001 _HID. * Simplify the return type of acpi_match_device_cls() to boolean. Changes from RFC (https://lkml.org/lkml/2014/12/17/446) * Remove #ifdef and make non-ACPI version of the acpi_match_device_cls as inline. (per Arnd) * Simplify logic to retrieve and evaluate _CLS handle. (per Hanjun) Suravee Suthikulpanit (2): ACPI / scan: Add support for ACPI _CLS device matching ata: ahci_platform: Add ACPI _CLS matching drivers/acpi/scan.c | 75 +++++++++++++++++++++++++++++++++++++++-- drivers/ata/Kconfig | 2 +- drivers/ata/ahci_platform.c | 3 ++ include/acpi/acnames.h | 1 + include/linux/acpi.h | 10 ++++++ include/linux/device.h | 1 + include/linux/mod_devicetable.h | 6 ++++ 7 files changed, 94 insertions(+), 4 deletions(-) -- 2.1.0

9 years, 7 months

[V2 PATCH 0/2] Introduce ACPI support for ahci_platform driver

by Suravee Suthikulpanit

This patch series introduce ACPI support for non-PCI AHCI platform driver. Existing ACPI support for AHCI assumes the device controller is a PCI device. Also, since there is no ACPI _HID/_CID for generic AHCI controller, the driver could not use them for matching devices. Therefore, this patch introduces a mechanism for drivers to match devices using ACPI _CLS method. This patch series is rebased from and tested with: http://git.linaro.org/leg/acpi/acpi.git acpi-5.1-v7 This topic was discussed earlier here (as part of introducing support for AMD Seattle SATA controller): http://marc.info/?l=linux-arm-kernel&m=141083492521584&w=2 NOTE: * PATCH 2/2 has already been Acked-by Tejun Heo in V1. I only made a minor renaming of the acpi_cls to acpi_match_cls for clarity in V2. It probably should be routed together with the PATCH 1/2 (once acked) since it defines the new member in the struct. Changes V1 (https://lkml.org/lkml/2014/12/19/345) * Rebased to 3.19.0-rc2 * Change from acpi_cls in device_driver to acpi_match_cls (Hanjun comment) * Change the matching logic in acpi_driver_match_device() due to the new special PRP0001 _HID. * Simplify the return type of acpi_match_device_cls() to boolean. Changes from RFC (https://lkml.org/lkml/2014/12/17/446) * Remove #ifdef and make non-ACPI version of the acpi_match_device_cls as inline. (per Arnd) * Simplify logic to retrieve and evaluate _CLS handle. (per Hanjun) Suravee Suthikulpanit (2): ACPI / scan: Add support for ACPI _CLS device matching ata: ahci_platform: Add ACPI _CLS matching drivers/acpi/scan.c | 79 +++++++++++++++++++++++++++++++++++++++-- drivers/ata/Kconfig | 2 +- drivers/ata/ahci_platform.c | 3 ++ include/acpi/acnames.h | 1 + include/linux/acpi.h | 10 ++++++ include/linux/device.h | 1 + include/linux/mod_devicetable.h | 6 ++++ 7 files changed, 98 insertions(+), 4 deletions(-) -- 1.9.3

9 years, 7 months

[PATCH] ACPI / table: remove duplicate NULL check for the handler of acpi_table_parse()

by Hanjun Guo

In acpi_table_parse(), pointer of the table to pass to handler() is checked before handler() called, so remove all the duplicate NULL check in the handler function. CC: Tony Luck <tony.luck(a)intel.com> CC: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org> --- arch/ia64/kernel/acpi.c | 6 ------ arch/x86/kernel/acpi/boot.c | 16 ++-------------- drivers/acpi/numa.c | 12 ++---------- 3 files changed, 4 insertions(+), 30 deletions(-) diff --git a/arch/ia64/kernel/acpi.c b/arch/ia64/kernel/acpi.c index e795cb8..2c44989 100644 --- a/arch/ia64/kernel/acpi.c +++ b/arch/ia64/kernel/acpi.c @@ -380,9 +380,6 @@ static void __init acpi_madt_oem_check(char *oem_id, char *oem_table_id) static int __init acpi_parse_madt(struct acpi_table_header *table) { - if (!table) - return -EINVAL; - acpi_madt = (struct acpi_table_madt *)table; acpi_madt_rev = acpi_madt->header.revision; @@ -645,9 +642,6 @@ static int __init acpi_parse_fadt(struct acpi_table_header *table) struct acpi_table_header *fadt_header; struct acpi_table_fadt *fadt; - if (!table) - return -EINVAL; - fadt_header = (struct acpi_table_header *)table; if (fadt_header->revision != 3) return -ENODEV; /* Only deal with ACPI 2.0 FADT */ diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c index b9e30da..14d3652 100644 --- a/arch/x86/kernel/acpi/boot.c +++ b/arch/x86/kernel/acpi/boot.c @@ -843,13 +843,7 @@ int acpi_ioapic_registered(acpi_handle handle, u32 gsi_base) static int __init acpi_parse_sbf(struct acpi_table_header *table) { - struct acpi_table_boot *sb; - - sb = (struct acpi_table_boot *)table; - if (!sb) { - printk(KERN_WARNING PREFIX "Unable to map SBF\n"); - return -ENODEV; - } + struct acpi_table_boot *sb = (struct acpi_table_boot *)table; sbf_port = sb->cmos_index; /* Save CMOS port */ @@ -863,13 +857,7 @@ static struct resource *hpet_res __initdata; static int __init acpi_parse_hpet(struct acpi_table_header *table) { - struct acpi_table_hpet *hpet_tbl; - - hpet_tbl = (struct acpi_table_hpet *)table; - if (!hpet_tbl) { - printk(KERN_WARNING PREFIX "Unable to map HPET\n"); - return -ENODEV; - } + struct acpi_table_hpet *hpet_tbl = (struct acpi_table_hpet *)table; if (hpet_tbl->address.space_id != ACPI_SPACE_MEM) { printk(KERN_WARNING PREFIX "HPET timers must be located in " diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c index 24b5476..1333cbdc 100644 --- a/drivers/acpi/numa.c +++ b/drivers/acpi/numa.c @@ -177,12 +177,7 @@ static int __init slit_valid(struct acpi_table_slit *slit) static int __init acpi_parse_slit(struct acpi_table_header *table) { - struct acpi_table_slit *slit; - - if (!table) - return -EINVAL; - - slit = (struct acpi_table_slit *)table; + struct acpi_table_slit *slit = (struct acpi_table_slit *)table; if (!slit_valid(slit)) { printk(KERN_INFO "ACPI: SLIT table looks invalid. Not used.\n"); @@ -260,11 +255,8 @@ acpi_parse_memory_affinity(struct acpi_subtable_header * header, static int __init acpi_parse_srat(struct acpi_table_header *table) { - struct acpi_table_srat *srat; - if (!table) - return -EINVAL; + struct acpi_table_srat *srat = (struct acpi_table_srat *)table; - srat = (struct acpi_table_srat *)table; acpi_srat_revision = srat->header.revision; /* Real work done in acpi_table_parse_srat below. */ -- 1.9.1

9 years, 8 months

[PATCH] acpi: move sleep_arm to architecure specific directory

by Graeme Gregory

There is no reason this file cannot be an arm64 specific stub holder so move the file and change the Kconfig to match. Signed-off-by: Graeme Gregory <graeme.gregory(a)linaro.org> --- arch/arm64/kernel/Makefile | 2 +- arch/arm64/kernel/acpi_sleep.c | 28 ++++++++++++++++++++++++++++ drivers/acpi/Makefile | 4 +--- drivers/acpi/sleep_arm.c | 28 ---------------------------- 4 files changed, 30 insertions(+), 32 deletions(-) create mode 100644 arch/arm64/kernel/acpi_sleep.c delete mode 100644 drivers/acpi/sleep_arm.c diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile index 8bdc6bd..f2c488b 100644 --- a/arch/arm64/kernel/Makefile +++ b/arch/arm64/kernel/Makefile @@ -34,7 +34,7 @@ arm64-obj-$(CONFIG_KGDB) += kgdb.o arm64-obj-$(CONFIG_EFI) += efi.o efi-stub.o efi-entry.o arm64-obj-$(CONFIG_PCI) += pci.o arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o -arm64-obj-$(CONFIG_ACPI) += acpi.o +arm64-obj-$(CONFIG_ACPI) += acpi.o acpi_sleep.o obj-y += $(arm64-obj-y) vdso/ obj-m += $(arm64-obj-m) diff --git a/arch/arm64/kernel/acpi_sleep.c b/arch/arm64/kernel/acpi_sleep.c new file mode 100644 index 0000000..54578ef --- /dev/null +++ b/arch/arm64/kernel/acpi_sleep.c @@ -0,0 +1,28 @@ +/* + * ARM64 Specific Sleep Functionality + * + * Copyright (C) 2013-2014, Linaro Ltd. + * Author: Graeme Gregory <graeme.gregory(a)linaro.org> + * + * 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> + +/* + * Currently the ACPI 5.1 standard does not define S states in a + * manner which is usable for ARM64. These two stubs are sufficient + * that system initialises and device PM works. + */ +u32 acpi_target_system_state(void) +{ + return ACPI_STATE_S0; +} +EXPORT_SYMBOL_GPL(acpi_target_system_state); + +int __init acpi_sleep_init(void) +{ + return -ENOSYS; +} diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile index bcec54e..753785d 100644 --- a/drivers/acpi/Makefile +++ b/drivers/acpi/Makefile @@ -23,9 +23,7 @@ acpi-y += nvs.o # Power management related files acpi-y += wakeup.o -ifeq ($(ARCH), arm64) -acpi-y += sleep_arm.o -else # X86, IA64 +ifneq (,$(findstring $(ARCH),x86 ia64)) acpi-y += sleep.o endif acpi-y += device_pm.o diff --git a/drivers/acpi/sleep_arm.c b/drivers/acpi/sleep_arm.c deleted file mode 100644 index 54578ef..0000000 --- a/drivers/acpi/sleep_arm.c +++ /dev/null @@ -1,28 +0,0 @@ -/* - * ARM64 Specific Sleep Functionality - * - * Copyright (C) 2013-2014, Linaro Ltd. - * Author: Graeme Gregory <graeme.gregory(a)linaro.org> - * - * 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> - -/* - * Currently the ACPI 5.1 standard does not define S states in a - * manner which is usable for ARM64. These two stubs are sufficient - * that system initialises and device PM works. - */ -u32 acpi_target_system_state(void) -{ - return ACPI_STATE_S0; -} -EXPORT_SYMBOL_GPL(acpi_target_system_state); - -int __init acpi_sleep_init(void) -{ - return -ENOSYS; -} -- 2.1.4

9 years, 8 months

[PATCH v2 0/5] Start deprecating _OSI on new architectures

by al.stone＠linaro.org

From: Al Stone <al.stone(a)linaro.org> The use of the ACPI _OSI method in Linux has a long and sordid history. Instead of perpetuating past complications on new architectures, the consensus amongst those writing the ACPI specification and those using it seems to be to ultimately deprecate the use of _OSI. A change request has been submitted (but not yet decided upon) to modify the ACPI specification accordingly. In the meantime, these patches rearrange the implementation of _OSI so that it can be deprecated, or ultimately removed completely, on at least arm64 platforms. This is done by separating out the _OSI implementation and moving it into a new file. For x86 and ia64, there is no change in functionality. But, this allows us to provide a separate implementation of _OSI for arm64 that generates a warning that it has been deprecated, and always returns false; i.e., that the capability being queried for, whether OS name or functionality, is not supported. This is the first four of the patches. The final patch changes the default value for the _OS_ method for arm64 only. Since there is no need to pretend to be older versions of Windows, or any other OS at all, the _OS_ method will return "Linux" on arm64. One can still use the acpi_os_name kernel parameter if there is a need to use some other value. The first three patches do not depend on arm64 support for ACPI and could be used independently. The last two patches make much more sense when used in conjunction with Hanjun's patches for ACPI 5.1 on arm64 [0]. These have been through some simple testing on two different x86 laptops, and all seems well (Lenovo t440s and t430s ThinkPads). The arm64 code has been tested on an AMD Seattle system. Unfortunately, for ia64, all I could do was cross-compile the code; I have no access to hardware to test on. NB: the first two patches do not pass checkpatch.pl; since this is existing code being moved, I have not repaired the reported errors for now, but will do so once the disposition of these patches have been resolved. Changes in v2: -- significant simplification based on Rafael's comments -- ACPI spec change request has now been submitted [0] https://lkml.org/lkml/2015/2/2/261 Al Stone (4): ACPI: move acpi_os_handler() so it can be made arch-dependent later ACPI: move _OSI support functions to allow arch-dependent implementation ACPI: add arch-specific compilation for _OSI and the blacklist ACPI: arm64: use the arch-specific ACPI _OSI method and ACPI blacklist Hanjun Guo (1): ACPI: arm64: use "Linux" as ACPI_OS_NAME for _OS on arm64 arch/arm64/Kconfig | 7 ++ drivers/acpi/Kconfig | 22 ++++ drivers/acpi/Makefile | 17 +++ drivers/acpi/blacklist-arm.c | 20 ++++ drivers/acpi/blacklist.c | 9 ++ drivers/acpi/osi-arm.c | 25 ++++ drivers/acpi/osi.c | 255 ++++++++++++++++++++++++++++++++++++++++ drivers/acpi/osl.c | 217 ---------------------------------- include/acpi/acconfig.h | 2 + include/acpi/platform/aclinux.h | 4 + include/linux/acpi.h | 4 +- 11 files changed, 362 insertions(+), 220 deletions(-) create mode 100644 drivers/acpi/blacklist-arm.c create mode 100644 drivers/acpi/osi-arm.c create mode 100644 drivers/acpi/osi.c -- 2.1.0

9 years, 8 months

[RFC v3] ACPI on arm64 TODO List, 4 Feb 2015

by Al Stone

Update for 4 Feb 2015: Back in September 2014, a meeting was held at Linaro Connect where we discussed what issues remained before the arm64 ACPI core patches could be merged into the kernel, creating the TODO list below. I should have published this list sooner; I got focused on trying to resolve some of the issues instead. We have made some progress on all of these items. But, I want to make sure we haven't missed something. Since this list was compiled by only the people in the room at Connect, it is probable we have. I, for one, do not yet claim omniscience. So, I want to ask the ARM and ACPI communities: -- Is this list correct? -- Is this list complete? Below is what we currently know about; very brief notes on status are included. The TL;DR versions of the TODO list and the current status can be found at: https://wiki.linaro.org/LEG/Engineering/Kernel/ACPI/CoreUpstreamNotes and I'll do my best to kept that up to date. Thanks. Any and all feedback is greatly appreciated. Changes since 11 Jan 2015: -- v7 of ACPI core patches posted; lots of discussion around GICs, documentation, and how to handle acpi=force -- Merging requested, discussed, NAK'd until further changes and sign-offs and ACKs from subsystem maintainers -- v8 of ACPI core patches posted, updated per v7 discussions; significant changes to GIC handling and documentation, much larger collection of sign-offs of all kinds; _OSC and _DSD review processes suggested; handling of acpi=force codified -- v1 of _OSI patches posted; v2 posted today; _OSC addressed in ACPI core v8 patches -- Additional FWTS runs, CI loop integration -- luvOS v1 patches posted and reviewed; working on updating GRUB and FWTS; CI loop built and running -- _DSD process suggested in ACPI core v8 patches -- Grant's summary of the ACPI rationale now part of the documentation Changes since 14 Dec 2014: -- v6 of ACPI core patches posted -- Good progress in _OSI investigation, started preparing RFC for the mailing lists -- Precise definition of kernel behavior when defaulting to DT and/or using acpi=force being discussed again -- FWTS now runs and results posted after each merge of leg-kernel (includes ACPI) with Linus' tree (i.e., each -rc). -- ACPI on arm64 kernel document updated, under extensive discussion on the lists; starting coordination with SBBR content. -- Firmware Summit: planned for 26 Mar 2015, San Jose, CA, at the ARM office; mailing list (with archives) now up and running; updated agenda being prepared -- Merged items "Demonstrate the ACPI core patches work", and "Platform support patches need review" because of their similarity. -- Further discussions have occurred regarding "Why ACPI?" and the usage of _DSD, more still needed TODO List for ACPI on arm64: ============================ 1. Define how Aarch64 OS identifies itself to firmware * Problem: * _OSI method is demonstrably unreliable. On x86, Linux claims to be Windows. * Proposal to use _OSC method as replacement is complicated and creates an explosion of combinations * Solution: * Draft and propose OS identification rules to ABST and ASWG for inclusion in ACPI spec. * Draft and propose recommended practice for current ACPI 5.1 spec platforms. * Status: general agreement to deprecate _OSI completely, replace _OS_, and v2 of patches to do so posted (https://lkml.org/lkml/2015/2/3/877); _OSC process suggested in ACPI on arm64 documentation 2. Linux must choose DT booting by default when offered both ACPI and DT on arm64 * Status: DONE, again, after incorporating discussion into v8 of core patches 3. Linux UEFI/ACPI testing tools must be made available * Problem: * Hardware/Firmware vendors do not have tools to test Linux compatibility. * Common problems go undetected if not tested for. * Solution: * Port FWTS tool and LuvOS distribution to AArch64 * Make LuvOS images readily available * Require hardware vendors to actively test against old and new kernels. * Status: * LuvOS and FWTS ported to arm64; patches in mainline; additional test cases being written. * CI loop set up to run FWTS on Foundation model for each -rc merge of Linus' tree into leg-kernel. * AMD Seattle results pending updated kernel patches. * LuvOS details at https://wiki.linaro.org/LEG/Engineering/luvOS * v1 patches out and reviewed * CI loop up and running * Working on update of GRUB2 and FWTS 4. Set clear expectations for those providing ACPI for use with Linux * Problem: * Hardware/Firmware vendors can and will create ACPI tables that cannot be used by Linux without some guidance * Kernel developers cannot determine whether the kernel or firmware is broken without knowing what the firmware should do * Solution: document the expectations, and iterate as needed. Enforce when we must. * Status: significant rewrite and additions to kernel documentation; starting to coordinate content with SBBR; firmware summit date and location firm, agenda updated, kernel docs shared for discussion. 5. Platform support patches need verification and review * Problem: the core Aarch64 patches have been reviewed and are in good shape, but there is not yet a good example of server platform support patches that use them. * Solution: post *good* patches for multiple ACPI platforms, demonstrating that both the core patches work, and that the use of the ACPI core makes sense. * Status: * Lots of changes to subsystem patches (GIC, PCI, ...) all over the place * ACPI core works on at least the Foundation model, Juno, APM Mustang, and AMD Seattle * FWTS results for the Foundation model have been posted * First version for AMD Seattle has been posted to the public linaro-acpi mailing list for initial review, refined versions to be posted to broader lists after a few iterations for basic cleanup 6. How does the kernel handle_DSD usage? * Problem: * _DSD defines key-value properties in the DT style. How do we ensure _DSD bindings are well defined? * How do we ensure DT and _DSD bindings remain consistent with each other? * Solution: public documentation for all bindings, and a process for defining them * Status: proposal documented in ACPI core patches to require patch authors to submit bindings with drivers, then register with UEFI Forum; kernel Documentation/devicetree/bindings remains the default if no other location exists. 7. Why is ACPI required? * Problem: * arm64 maintainers still haven't been convinced that ACPI is necessary. * Why do hardware and OS vendors say ACPI is required? * Solution: discussions between those who want ACPI and arm64 maintainers * Status: DONE, and documentation added to proposed kernel docs; firmware summit for broader discussion still planned. -- ciao, al ----------------------------------- Al Stone Software Engineer Linaro Enterprise Group al.stone(a)linaro.org -----------------------------------

9 years, 8 months

leg-kernel tag leg-20150203.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-20150203.0 This is based on mainline kernel v3.19-rc7 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: https://git.linaro.org/leg/acpi/leg-kernel.git/commit/2cb1e1db278a9856d98de… Notes :- 1) This release only supports Juno/FVP until updated topics for Seattle and Mustang are available. 2) This release incorporates the SBSA UART support for pl011 driver from Andre Przywara. This means that your console will become ttyAMA0 (console=ttyAMA0) on Juno/FVP. It also means to run FVP model you need these options :- -C bp.pl011_uart0.untimed_fifos=0 -C bp.pl011_uart0.revision="r1p5"

9 years, 8 months

← Newer
1
...
33
34
35
36
37
38
39
...
82
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-acpi