Linaro-acpi July 2015

linaro-acpi@lists.linaro.org

27 participants
36 discussions

by Itaru Kitayama

Hi Graeme, This is just to let you know that the current Mustang topic branch is able to boot the machine available in Austin the server lab. Attached is the config I used, last time I tried to build the branch I wasn't setting ACPI to y. This time some of ACPI related messages in demsg. Itaru

8 years, 9 months

[RFCv1 PATCH 0/7] Introducing ACPI support for GICv2m

by Suravee Suthikulpanit

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

8 years, 9 months

[PATCH v6 5/8] Watchdog: introduce ARM SBSA watchdog driver

by fu.wei＠linaro.org

From: Fu Wei <fu.wei(a)linaro.org> This driver bases on linux kernel watchdog framework, and use "pretimeout" in the framework. It supports getting timeout and pretimeout from parameter and FDT at the driver init stage. In first timeout, the interrupt routine run panic to save system context. Signed-off-by: Fu Wei <fu.wei(a)linaro.org> --- drivers/watchdog/Kconfig | 14 ++ drivers/watchdog/Makefile | 1 + drivers/watchdog/sbsa_gwdt.c | 455 +++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 470 insertions(+) create mode 100644 drivers/watchdog/sbsa_gwdt.c diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index e5e7c55..e059850 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -152,6 +152,20 @@ config ARM_SP805_WATCHDOG ARM Primecell SP805 Watchdog timer. This will reboot your system when the timeout is reached. +config ARM_SBSA_WATCHDOG + tristate "ARM SBSA Generic Watchdog" + depends on ARM64 + depends on ARM_ARCH_TIMER + select WATCHDOG_CORE + help + ARM SBSA Generic Watchdog. This watchdog has two Watchdog timeouts. + The first timeout will trigger a panic; the second timeout will + trigger a system reset. + More details: ARM DEN0029B - Server Base System Architecture (SBSA) + + To compile this driver as module, choose M here: The module + will be called sbsa_gwdt. + config AT91RM9200_WATCHDOG tristate "AT91RM9200 watchdog" depends on SOC_AT91RM9200 && MFD_SYSCON diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index 5c19294..471f1b7c 100644 --- a/drivers/watchdog/Makefile +++ b/drivers/watchdog/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o # ARM Architecture obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o +obj-$(CONFIG_ARM_SBSA_WATCHDOG) += sbsa_gwdt.o obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c new file mode 100644 index 0000000..2de5899 --- /dev/null +++ b/drivers/watchdog/sbsa_gwdt.c @@ -0,0 +1,455 @@ +/* + * SBSA(Server Base System Architecture) Generic Watchdog driver + * + * Copyright (c) 2015, Linaro Ltd. + * Author: Fu Wei <fu.wei(a)linaro.org> + * Suravee Suthikulpanit <Suravee.Suthikulpanit(a)amd.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License 2 as published + * by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * The SBSA Generic watchdog driver is compatible with the pretimeout + * concept of Linux kernel. + * The timeout and pretimeout are determined by WCV or WOR. + * The first watch period is set by writing WCV directly, that can + * support more than 10s timeout at the maximum system counter + * frequency (400MHz). + * When WS0 is triggered, the second watch period (pretimeout) is + * determined by one of these registers: + * (1)WOR: 32bit register, this gives a maximum watch period of + * around 10s at the maximum system counter frequency. It's loaded + * automatically by hardware. + * (2)WCV: If the pretimeout value is greater then "max_wor_timeout", + * it will be loaded in WS0 interrupt routine. If system is in + * ws0_mode (reboot by kexec/kdump in panic with watchdog enabled + * and WS0 == true), the ping operation will only reload WCV. + * More details about the hardware specification of this device: + * ARM DEN0029B - Server Base System Architecture (SBSA) + * + * Kernel/API: P------------------| pretimeout + * |----------------------------------------T timeout + * SBSA GWDT: P---WOR (or WCV)---WS1 pretimeout + * |-------WCV----------WS0~~~(ws0_mode)~~~~T timeout + */ + +#include <linux/io.h> +#include <linux/interrupt.h> +#include <linux/module.h> +#include <linux/moduleparam.h> +#include <linux/of.h> +#include <linux/of_device.h> +#include <linux/platform_device.h> +#include <linux/uaccess.h> +#include <linux/watchdog.h> +#include <asm/arch_timer.h> + +/* SBSA Generic Watchdog register definitions */ +/* refresh frame */ +#define SBSA_GWDT_WRR 0x000 + +/* control frame */ +#define SBSA_GWDT_WCS 0x000 +#define SBSA_GWDT_WOR 0x008 +#define SBSA_GWDT_WCV_LO 0x010 +#define SBSA_GWDT_WCV_HI 0x014 + +/* refresh/control frame */ +#define SBSA_GWDT_W_IIDR 0xfcc +#define SBSA_GWDT_IDR 0xfd0 + +/* Watchdog Control and Status Register */ +#define SBSA_GWDT_WCS_EN BIT(0) +#define SBSA_GWDT_WCS_WS0 BIT(1) +#define SBSA_GWDT_WCS_WS1 BIT(2) + +/** + * struct sbsa_gwdt - Internal representation of the SBSA GWDT + * @wdd: kernel watchdog_device structure + * @clk: store the System Counter clock frequency, in Hz. + * @ws0_mode: indicate the system boot in the second stage timeout. + * @max_wor_timeout: the maximum timeout value for WOR (in seconds). + * @refresh_base: Virtual address of the watchdog refresh frame + * @control_base: Virtual address of the watchdog control frame + */ +struct sbsa_gwdt { + struct watchdog_device wdd; + u32 clk; + bool ws0_mode; + int max_wor_timeout; + void __iomem *refresh_base; + void __iomem *control_base; +}; + +#define to_sbsa_gwdt(e) container_of(e, struct sbsa_gwdt, wdd) + +#define DEFAULT_TIMEOUT 30 /* seconds, the 1st + 2nd watch periods*/ +#define DEFAULT_PRETIMEOUT 10 /* seconds, the 2nd watch period*/ + +static unsigned int timeout; +module_param(timeout, uint, 0); +MODULE_PARM_DESC(timeout, + "Watchdog timeout in seconds. (>=0, default=" + __MODULE_STRING(DEFAULT_TIMEOUT) ")"); + +static unsigned int pretimeout; +module_param(pretimeout, uint, 0); +MODULE_PARM_DESC(pretimeout, + "Watchdog pretimeout in seconds. (>=0, default=" + __MODULE_STRING(DEFAULT_PRETIMEOUT) ")"); + +static bool nowayout = WATCHDOG_NOWAYOUT; +module_param(nowayout, bool, S_IRUGO); +MODULE_PARM_DESC(nowayout, + "Watchdog cannot be stopped once started (default=" + __MODULE_STRING(WATCHDOG_NOWAYOUT) ")"); + +/* + * help functions for accessing 64bit WCV register + */ +static u64 sbsa_gwdt_get_wcv(struct watchdog_device *wdd) +{ + u32 wcv_lo, wcv_hi; + struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd); + + do { + wcv_hi = readl_relaxed(gwdt->control_base + SBSA_GWDT_WCV_HI); + wcv_lo = readl_relaxed(gwdt->control_base + SBSA_GWDT_WCV_LO); + } while (wcv_hi != readl_relaxed(gwdt->control_base + + SBSA_GWDT_WCV_HI)); + + return (((u64)wcv_hi << 32) | wcv_lo); +} + +static void sbsa_gwdt_set_wcv(struct watchdog_device *wdd, unsigned int t) +{ + struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd); + u64 wcv; + + wcv = arch_counter_get_cntvct() + (u64)t * gwdt->clk; + + writel_relaxed(upper_32_bits(wcv), + gwdt->control_base + SBSA_GWDT_WCV_HI); + writel_relaxed(lower_32_bits(wcv), + gwdt->control_base + SBSA_GWDT_WCV_LO); +} + +/* + * inline functions for reloading 64bit WCV register + */ +static inline void reload_pretimeout_to_wcv(struct watchdog_device *wdd) +{ + sbsa_gwdt_set_wcv(wdd, wdd->pretimeout); +} + +static inline void reload_first_stage_to_wcv(struct watchdog_device *wdd) +{ + sbsa_gwdt_set_wcv(wdd, wdd->timeout - wdd->pretimeout); +} + +/* + * watchdog operation functions + */ +static int sbsa_gwdt_set_timeout(struct watchdog_device *wdd, + unsigned int timeout) +{ + wdd->timeout = timeout; + + return 0; +} + +static int sbsa_gwdt_set_pretimeout(struct watchdog_device *wdd, + unsigned int pretimeout) +{ + struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd); + u32 wor; + + wdd->pretimeout = pretimeout; + + /* If ws0_mode == true, we won't touch WOR */ + if (!gwdt->ws0_mode) { + if (!pretimeout) + /* + * If pretimeout is 0, it gives driver a timeslot (1s) + * to update WCV after an explicit refresh + * (sbsa_gwdt_start) + */ + wor = gwdt->clk; + else + if (pretimeout > gwdt->max_wor_timeout) + wor = U32_MAX; + else + wor = pretimeout * gwdt->clk; + + /* wtite WOR, that will cause an explicit watchdog refresh */ + writel_relaxed(wor, gwdt->control_base + SBSA_GWDT_WOR); + } + + return 0; +} + +static unsigned int sbsa_gwdt_get_timeleft(struct watchdog_device *wdd) +{ + struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd); + u64 timeleft = sbsa_gwdt_get_wcv(wdd) - arch_counter_get_cntvct(); + + do_div(timeleft, gwdt->clk); + + return timeleft; +} + +static int sbsa_gwdt_keepalive(struct watchdog_device *wdd) +{ + struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd); + + if (gwdt->ws0_mode) + reload_pretimeout_to_wcv(wdd); + else + reload_first_stage_to_wcv(wdd); + + return 0; +} + +static int sbsa_gwdt_start(struct watchdog_device *wdd) +{ + struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd); + + /* If ws0_mode == true, the watchdog is enabled */ + if (!gwdt->ws0_mode) + /* writing WCS will cause an explicit watchdog refresh */ + writel_relaxed(SBSA_GWDT_WCS_EN, + gwdt->control_base + SBSA_GWDT_WCS); + + return sbsa_gwdt_keepalive(wdd); +} + +static int sbsa_gwdt_stop(struct watchdog_device *wdd) +{ + struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd); + + writel_relaxed(0, gwdt->control_base + SBSA_GWDT_WCS); + /* + * Writing WCS has caused an explicit watchdog refresh. + * Both watchdog signals are deasserted, so clean ws0_mode flag. + */ + gwdt->ws0_mode = false; + + return 0; +} + +static irqreturn_t sbsa_gwdt_interrupt(int irq, void *dev_id) +{ + struct sbsa_gwdt *gwdt = (struct sbsa_gwdt *)dev_id; + struct watchdog_device *wdd = &gwdt->wdd; + + /* We don't use pretimeout, trigger WS1 now */ + if (!wdd->pretimeout) + sbsa_gwdt_set_wcv(wdd, 0); + + /* + * The pretimeout is valid, go panic + * If pretimeout is greater then "max_wor_timeout", + * reload the right value to WCV, then panic + */ + if (wdd->pretimeout > gwdt->max_wor_timeout) + reload_pretimeout_to_wcv(wdd); + panic("SBSA Watchdog pre-timeout"); + + return IRQ_HANDLED; +} + +static struct watchdog_info sbsa_gwdt_info = { + .identity = "SBSA Generic Watchdog", + .options = WDIOF_SETTIMEOUT | + WDIOF_KEEPALIVEPING | + WDIOF_MAGICCLOSE | + WDIOF_PRETIMEOUT | + WDIOF_CARDRESET, +}; + +static struct watchdog_ops sbsa_gwdt_ops = { + .owner = THIS_MODULE, + .start = sbsa_gwdt_start, + .stop = sbsa_gwdt_stop, + .ping = sbsa_gwdt_keepalive, + .set_timeout = sbsa_gwdt_set_timeout, + .set_pretimeout = sbsa_gwdt_set_pretimeout, + .get_timeleft = sbsa_gwdt_get_timeleft, +}; + +static int sbsa_gwdt_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct watchdog_device *wdd; + struct sbsa_gwdt *gwdt; + struct resource *res; + u64 max_wcv_timeout = U64_MAX; + void *rf_base, *cf_base; + int ret, irq; + u32 status; + + gwdt = devm_kzalloc(dev, sizeof(*gwdt), GFP_KERNEL); + if (!gwdt) + return -ENOMEM; + platform_set_drvdata(pdev, gwdt); + + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "refresh"); + rf_base = devm_ioremap_resource(dev, res); + if (IS_ERR(rf_base)) + return PTR_ERR(rf_base); + + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "control"); + cf_base = devm_ioremap_resource(dev, res); + if (IS_ERR(cf_base)) + return PTR_ERR(cf_base); + + irq = platform_get_irq_byname(pdev, "ws0"); + if (irq < 0) { + dev_err(dev, "unable to get ws0 interrupt.\n"); + return irq; + } + + /* + * Get the frequency of system counter from the cp15 interface of ARM + * Generic timer. We don't need to check it, because if it returns "0", + * system would panic in very early stage. + */ + gwdt->clk = arch_timer_get_cntfrq(); + gwdt->refresh_base = rf_base; + gwdt->control_base = cf_base; + gwdt->max_wor_timeout = U32_MAX / gwdt->clk; + gwdt->ws0_mode = false; + + wdd = &gwdt->wdd; + wdd->parent = dev; + wdd->info = &sbsa_gwdt_info; + wdd->ops = &sbsa_gwdt_ops; + watchdog_set_drvdata(wdd, gwdt); + watchdog_set_nowayout(wdd, nowayout); + + wdd->min_pretimeout = 0; + wdd->min_timeout = 1; + do_div(max_wcv_timeout, gwdt->clk); + wdd->max_pretimeout = max_wcv_timeout; + wdd->max_timeout = max_wcv_timeout * 2; + + wdd->pretimeout = DEFAULT_PRETIMEOUT; + wdd->timeout = DEFAULT_TIMEOUT; + watchdog_init_timeouts(wdd, pretimeout, timeout, dev); + + status = readl_relaxed(gwdt->control_base + SBSA_GWDT_WCS); + if (status & SBSA_GWDT_WCS_WS1) { + dev_warn(dev, "System reset by WDT(WCV: %llx)\n", + sbsa_gwdt_get_wcv(wdd)); + wdd->bootstatus |= WDIOF_CARDRESET; + } else if (status == (SBSA_GWDT_WCS_WS0 | SBSA_GWDT_WCS_EN)) { + gwdt->ws0_mode = true; + } + + ret = devm_request_irq(dev, irq, sbsa_gwdt_interrupt, 0, + pdev->name, gwdt); + if (ret) { + dev_err(dev, "unable to request IRQ %d\n", irq); + return ret; + } + + ret = watchdog_register_device(wdd); + if (ret) + return ret; + + /* If ws0_mode == true, the line won't update WOR */ + sbsa_gwdt_set_pretimeout(wdd, wdd->pretimeout); + + /* + * If watchdog is already enabled, do a ping operation + * to keep system running + */ + if (status & SBSA_GWDT_WCS_EN) + sbsa_gwdt_keepalive(wdd); + + dev_info(dev, "Initialized with %ds timeout, %ds pretimeout @ %u Hz%s\n", + wdd->timeout, wdd->pretimeout, gwdt->clk, + status & SBSA_GWDT_WCS_EN ? + gwdt->ws0_mode ? " [second stage]" : " [enabled]" : + ""); + + return 0; +} + +static void sbsa_gwdt_shutdown(struct platform_device *pdev) +{ + struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev); + + sbsa_gwdt_stop(&gwdt->wdd); +} + +static int sbsa_gwdt_remove(struct platform_device *pdev) +{ + struct sbsa_gwdt *gwdt = platform_get_drvdata(pdev); + + watchdog_unregister_device(&gwdt->wdd); + + return 0; +} + +/* Disable watchdog if it is active during suspend */ +static int __maybe_unused sbsa_gwdt_suspend(struct device *dev) +{ + struct sbsa_gwdt *gwdt = dev_get_drvdata(dev); + + if (watchdog_active(&gwdt->wdd)) + sbsa_gwdt_stop(&gwdt->wdd); + + return 0; +} + +/* Enable watchdog and configure it if necessary */ +static int __maybe_unused sbsa_gwdt_resume(struct device *dev) +{ + struct sbsa_gwdt *gwdt = dev_get_drvdata(dev); + + if (watchdog_active(&gwdt->wdd)) + sbsa_gwdt_start(&gwdt->wdd); + + return 0; +} + +static const struct dev_pm_ops sbsa_gwdt_pm_ops = { + SET_SYSTEM_SLEEP_PM_OPS(sbsa_gwdt_suspend, sbsa_gwdt_resume) +}; + +static const struct of_device_id sbsa_gwdt_of_match[] = { + { .compatible = "arm,sbsa-gwdt", }, + {}, +}; +MODULE_DEVICE_TABLE(of, sbsa_gwdt_of_match); + +static const struct platform_device_id sbsa_gwdt_pdev_match[] = { + { .name = "sbsa-gwdt", }, + {}, +}; +MODULE_DEVICE_TABLE(platform, sbsa_gwdt_pdev_match); + +static struct platform_driver sbsa_gwdt_driver = { + .driver = { + .name = "sbsa-gwdt", + .pm = &sbsa_gwdt_pm_ops, + .of_match_table = sbsa_gwdt_of_match, + }, + .probe = sbsa_gwdt_probe, + .remove = sbsa_gwdt_remove, + .shutdown = sbsa_gwdt_shutdown, + .id_table = sbsa_gwdt_pdev_match, +}; + +module_platform_driver(sbsa_gwdt_driver); + +MODULE_DESCRIPTION("SBSA Generic Watchdog Driver"); +MODULE_AUTHOR("Fu Wei <fu.wei(a)linaro.org>"); +MODULE_AUTHOR("Suravee Suthikulpanit <Suravee.Suthikulpanit(a)amd.com>"); +MODULE_LICENSE("GPL v2"); -- 1.9.1

8 years, 9 months

[PATCH 0/2] process vendor proprietary CPER error section

by Jonathan (Zhixiong) Zhang

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

8 years, 9 months

[PATCH V6 0/4] map GHES memory region according to EFI memory map

by Jonathan (Zhixiong) Zhang

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

8 years, 9 months

Re: [Linaro-acpi] [PATCH V3 4/4] acpi, apei: use EFI memmap to map GHES memory

by Zhang, Jonathan Zhixiong

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

8 years, 9 months

[PATCH V5 0/4] map GHES memory region according to EFI memory map

by Jonathan (Zhixiong) Zhang

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

8 years, 9 months

[PATCH v3 0/8] Add self-probe infrastructure and stacked irqdomain support for ACPI based GICv2/3 init

by Hanjun Guo

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

8 years, 9 months

[RFC PATCH 0/7] ACPI IORT (connections of PCI, devices, ITS and SMMU)

by Hanjun Guo

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

8 years, 9 months

[RFC PATCH 0/5] Provide better MADT subtable sanity checks

by Al Stone

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

8 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-acpi July 2015