- Linaro-acpi - lists.linaro.org

[RFC] Discussions about _DSD and device properties

by Al Stone

I thought I would pass on some of the discussion that's going on around the use and definition of _DSD device properties. There seems to be some basic agreement that (a) we should send things to a common forum for review and documentation, and that (b) the forum needs to be easily visible and usable by Linux folks, MS people, and firmware developers, and that (c) there is a dsd(a)acpica.org mailing list set up for that, but has not been used at all (nor has the ASWG process, for that matter). Darren Hart of Intel has proposed some of these, and has volunteered to try to get this going. And, I agree with him on where we need to go with all of this. So, I would encourage people to start submitting things to the dsd(a)acpica.org mailing list. But, that begs the question of *what* to submit. I haven't been very vocal about this just because I was fiddling around with the ideas but I think they're solid enough to get moving. Please see the git tree at https://github.com/ahs3/dsd. This may or may not be the right long term place to host it, but the README describes the idea -- I've written a tool that uses simple YAML to describe device properties. The tool can verify that all the right things are documented, and allows one to build a data base -- of plain human-readable ASCII YAML -- that anyone can visit, peruse, or offer updates to. The YAML is probably not complete; however, the key thing is that this is completely open source, under a very permissive license, and easily seen or used by developers of any OS or any bit of firmware -- the neutral location and open license means equal use and access for Microsoft, Linux, and the firmware writers. Patches are of course welcome -- to the tool, or even the data base of device property descriptions. So, if one sends the type of YAML expected to dsd(a)acpica.org, I can easily pull it in, verify it, and push it back out to github, assuming it's reasonably correct and usable. If we can agree that all discussions about the acceptability of any particular device property occurs on dsd(a)acpica.org, we can get this process moving and documented, and change the discussion to be about specific device properties instead. I'm attaching the README from https://github.com/ahs3/dsd for those that are as lazy as I am about following links :)..... README ------ dsd -- a command line tool for _DSD device property registrations ----------------------------------------------------------------- A simple 'make' will produce a command line tool to help in the collection, registration and maintenance of entries describing the device properties allowed via the _DSD method in ACPI [0] -- and in Device Tree (DT). The issue is that there is a desire to share device properties not only across devices (e.g., is more than one "mac-address" really needed?), but between the users of ACPI via _DSD, and possibly the users of Device Tree (DT), where the key-value model is used extensively. While DT documentation seems to be reasonably well cared for (at least in the Linux kernel documentation) and there is a process for maintaining the device property definitions, the same is not true of ACPI. In fact, device properties as used by _DSD are maintained completely outside of the specification, and there is no history of maintaining -- or registering -- them as there is for DT, since this is all relatively new to ACPI. However, regardless of its quality, keeping documentatation in the Linux kernel does present some problems. For one, firmware developers are not likely to look at the Linux source for information on the device properties they might want to use or need to define. The OS is not really where their focus lies. For two, sharing device properties with the Windows OS becomes very difficult; asking Microsoft engineers to go use the Linux source code as reference material puts them in an untenable position. What this tool -- dsd -- is attempting to do is provide a standard, neutral location and format for the definition of these properties, so that anyone that needs to can easily get to them, register new ones, or share existing properties. Each device property is described in YAML (examples below, with details in the file called YAML). At present, a directory contains the YAML, with one file per device property, one file per device using those properties, and acts as a very crude "data base" for all of the entries. The dsd command provides several functions for dealing with this "data base" of device properties: -- initialize the data base -- verify the YAML is correct -- add the device property to the data base in a consistent format -- remove a device property from the data base -- list all known device property names -- output the info from a given device property -- output a basic text description of the property for use in Linux documentation (or elsewhere) Additional functions can be added (all the source is provided), and should this project work out, more will be -- for example, summaries of all of the properties for a given device, or analysis indicating whether or not a property is needed and by what devices, or perhaps even more clever things. Building the tool ----------------- The dsd command requires that libyaml for C be installed [1]. Then, just do: % make There is no install target at present. Run the command: % ./dsd help to show what options are available. YAML ---- The dsd command uses basic YAML formatting (so, spaces for indentation, then indentation for indicating structure) and currently recognizes the following keywords: property: <name> owner: <string> type: integer | hexadecimal-integer | hexadecimal-address-package | string | <type> <value-list> description: <free text> example: <free text> For example: property: phy-mode owner: Al Stone <ahs3(a)redhat.com> type: string values: - token: na description: none available - token: mii description: media independent interface (MII) - token: gmii description: gigabit MII - token: sgmii description: serial gigabit MII - token: tbi description: ten bit interface - token: revmii description: reverse MII - token: rmii description: reduced MII - token: rgmii description: reduced gigabit MII (RGMII) - token: rgmii-id description: RGMII with internal delay - token: rgmii-rxid description: RGMII with receive delay only - token: rgmii-txid description: RGMII with transmit delay only - token: rtbi description: reduced ten bit interface - token: smii description: serial MII - token: xgmii description: 10 gigabit MII - token: moca description: multimedia over coax - token: qsgmii description: quad serial gigabit MII description: | Defines the PHY mode to be used for this device. example: | Package (2) { "phy-mode", "xgmii" } Please use '---' to separate device property definitions if several are included in a single file of text (dsd will separate them into unique entries in the "data base"). References ---------- [0] For a description of _DSD, see: http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide… For the device properties UUID of _DSD, see: http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UU… [1] On Debian: apt-get install libyaml-dev On Fedora: dnf install libyaml-devel -- ciao, al ----------------------------------- Al Stone Software Engineer Linaro Enterprise Group al.stone(a)linaro.org -----------------------------------

10 years, 8 months

1
0
0 0

leg-kernel tag leg-20150821.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-20150821.0 This is based on mainline kernel v4.2-rc7 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: http://git.linaro.org/leg/acpi/leg-kernel.git/commit/f54108bb7b07c9ce7100d4… Topic Branches :- http://git.linaro.org/leg/acpi/acpi.git - acpi-topic-arm64-apei - acpi-topic-juno-fvp - acpi-topic-nodevmem - acpi-topic-sbsa-watchdog - acpi-topic-seattle - acpi-topic-spcr - acpi-topic-bad-madt - topic-gic-self-probe http://git.linaro.org/people/graeme.gregory/linux.git - topic-capsule http://git.linaro.org/people/leif.lindholm/linux.git - arm64-pcihost-generic Mainline Based -------------- Repository: http://git.linaro.org/leg/acpi/acpi.git Branch: leg-kernel Tag: leg-mainline-20150820.0

10 years, 8 months

1
0
0 0

[PATCH] acpi, apei, arm64: APEI initial support for aarch64.

by fu.wei＠linaro.org

From: Tomasz Nowicki <tomasz.nowicki(a)linaro.org> This commit provides APEI arch-specific bits for aarch64 Changelog: Fu Wei: Move arch_apei_flush_tlb_one() to arch/arm64/include/asm/apci.h. Delete arch/arm64/kernel/apei.c. Add "#ifdef CONFIG_ACPI_APEI" for "acpi_disable_cmcff". Signed-off-by: Tomasz Nowicki <tomasz.nowicki(a)linaro.org> Signed-off-by: Fu Wei <fu.wei(a)linaro.org> --- arch/arm64/Kconfig | 1 + arch/arm64/include/asm/acpi.h | 11 +++++++++++ arch/arm64/kernel/acpi.c | 4 ++++ 3 files changed, 16 insertions(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 318175f..6144c9d 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -3,6 +3,7 @@ config ARM64 select ACPI_CCA_REQUIRED if ACPI select ACPI_GENERIC_GSI if ACPI select ACPI_REDUCED_HARDWARE_ONLY if ACPI + select HAVE_ACPI_APEI if ACPI select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE select ARCH_HAS_ELF_RANDOMIZE select ARCH_HAS_GCOV_PROFILE_ALL diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index a17b623..ced6e25 100644 --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -22,6 +22,7 @@ #ifdef CONFIG_ACPI_APEI #include <linux/efi.h> #include <asm/pgtable.h> +#include <asm/tlbflush.h> #endif /* Macros for consistency checks of the GICC subtable of MADT */ @@ -52,6 +53,9 @@ typedef u64 phys_cpuid_t; extern int acpi_disabled; extern int acpi_noirq; extern int acpi_pci_disabled; +#ifdef CONFIG_ACPI_APEI +extern int acpi_disable_cmcff; +#endif static inline void disable_acpi(void) { @@ -89,6 +93,13 @@ static inline bool acpi_has_cpu_in_madt(void) static inline void arch_fix_phys_package_id(int num, u32 slot) { } void __init acpi_init_cpus(void); +#ifdef CONFIG_ACPI_APEI +static inline void arch_apei_flush_tlb_one(unsigned long addr) +{ + flush_tlb_kernel_range(addr, addr + PAGE_SIZE); +} +#endif + #else static inline void acpi_init_cpus(void) { } #endif /* CONFIG_ACPI */ diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index 19de753..bd1be9a 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -36,6 +36,10 @@ EXPORT_SYMBOL(acpi_disabled); int acpi_pci_disabled = 1; /* skip ACPI PCI scan and IRQ initialization */ EXPORT_SYMBOL(acpi_pci_disabled); +#ifdef CONFIG_ACPI_APEI +int acpi_disable_cmcff; +#endif + static bool param_acpi_off __initdata; static bool param_acpi_force __initdata; -- 1.9.1

10 years, 8 months

4
7
0 0

Mustang branch boot issue

by Itaru Kitayama

Hi, I have been trying to boot the Mustang branch with acpi=force, but it stalls during the process I need to powercycle every time I enter that state. Checking setup_arch(), acpi_boot_table_init() seems to be ok, but it can not continue booting if disable_acpi() is not called before the block below: if (acpi_disabled) { unflatten_device_tree(); psci_dt_init(); } else { psci_acpi_init(); } Instead, calling disable_acpi() right after the block above ends up stalling. psci_acpi_init() does nothing on Mustang as it does not support the interface. Has anyone has an idea as to what's blocking the acpi=force boot process? Itaru

10 years, 8 months

2
1
0 0

[PATCH 0/5] ACPI: 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, for example). 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 that is currently ignored), 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 also been cross-compiled for x86 and ia64 with no known failures. 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/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.c | 6 -- include/linux/acpi.h | 4 - 7 files changed, 241 insertions(+), 67 deletions(-) -- 2.4.3

10 years, 9 months

5
11
0 0

[PATCH v4 00/10] ACPI GIC Self-probing, GICv2m and GICv3 support

by Hanjun Guo

When ACPI core patches were merged into mainline, there were two TODOs for ACPI based GIC init, one is the Self-probing for GIC, the other one is to support stacked irq domain, also the feature of GICv2m and GICv3 is missing in that patch set. For ACPI Self-probing for GIC, thanks to the GIC version which is introduced in ACPI 6.0, we can match the GIC version and GIC driver, based on that, we introduce the self-probe infrastructure similar as IRQCHIP_DECLARE(), please see patch 1~3. The stacked domain thing is more complicated, Marc introduced a patchset to slove this problem (great thanks!) - Making the generic ACPI GSI layer irqdomain aware, which is avaiable at: git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git irq/gsi-irq-domain-v2 so we reworked the GICv2m and GICv3 support on top of it, and combined them as a single patch set for review. Note: this patchset has no ITS support for GICv3/4, it will be implmented in the IORT patchset, which had a draft version but needs to rework it on top of Marc's Per-device MSI domain & platform MSI patchset. Tested on GICv2 based FVP base model and AMD Seattle platform, both wired interrupt and MSI (with some PCI patches) work fine. Patches are on top of Marc's branch irq/gsi-irq-domain-v2, and available at: git://git.linaro.org/leg/acpi/acpi.git gsi-irqdomain Comments are warmly welcomed. >From v3: - Rework GICv3 patches on top of Marc's tree - Add gicV2m support Hanjun Guo (5): 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 / GICv3: remove the useless comparision of device node in xlate irqchip / GICv3 / ACPI: Add GICR support via GICC structures Suravee Suthikulpanit (3): ACPI: GIC: Add ACPI helper functions to query irq-domain tokens for for GIC MSI and ITS PCI: ACPI: Bind GIC MSI frame to PCI host bridge irqchip / gicv2m: Introducing gicv2m_acpi_init() 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/irq.h | 13 -- arch/arm64/kernel/acpi.c | 25 -- drivers/acpi/Makefile | 1 + drivers/acpi/acpi_gic.c | 234 +++++++++++++++++++ drivers/irqchip/Kconfig | 3 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-gic-acpi.c | 175 ++++++++++++++ drivers/irqchip/irq-gic-v2m.c | 111 +++++++-- drivers/irqchip/irq-gic-v3.c | 438 +++++++++++++++++++++++++++++++---- drivers/irqchip/irq-gic.c | 6 +- drivers/pci/pci-acpi.c | 18 ++ drivers/pci/probe.c | 3 + include/acpi/acpi_gic.h | 23 ++ include/asm-generic/vmlinux.lds.h | 13 ++ include/linux/acpi.h | 17 ++ include/linux/acpi_irq.h | 4 +- include/linux/irqchip.h | 13 ++ include/linux/irqchip/arm-gic-acpi.h | 10 +- include/linux/irqchip/arm-gic.h | 7 + include/linux/mod_devicetable.h | 8 + include/linux/pci-acpi.h | 4 + 22 files changed, 1009 insertions(+), 119 deletions(-) create mode 100644 drivers/acpi/acpi_gic.c create mode 100644 drivers/irqchip/irq-gic-acpi.c create mode 100644 include/acpi/acpi_gic.h -- 1.9.1

10 years, 9 months

7
43
0 0

[PATCH V11 0/5] 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. V11: 1. Changed how we deal with superimposed memory region attributes as provided in UEFI memory map, on arm64. V10: 1. Fixed compilation issue on x86. V9: 1. Rebased to arm64-upstream-14543 of arm64/master. 2. Match strict MM type in arch_apei_get_mem_attribute(). V8: 1. For x86, always return PAGE_KERNEL for arch_apei_get_mem_attribute(). The rational is explained in comment. 2. Rebased to arm64-upstream-14201 of arm64/master, next-20150724 of linux-next/master. V7: 1. Added PROT_DEVICE_nGnRnE and PROT_NORMAL_WT to support all possible UEFI memory types for arm64. 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 (5): efi: x86: rearrange efi_mem_attributes() x86: acpi: implement arch_apei_get_mem_attributes() arm64: mm: add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT arm64: apei: implement arch_apei_get_mem_attributes() acpi, apei: use appropriate pgprot_t to map GHES memory arch/arm64/include/asm/acpi.h | 30 ++++++++++++++++++++++++++++++ arch/arm64/include/asm/memory.h | 1 + arch/arm64/include/asm/pgtable.h | 2 ++ arch/arm64/mm/proc.S | 4 +++- arch/x86/include/asm/acpi.h | 24 ++++++++++++++++++++++++ arch/x86/platform/efi/efi.c | 18 ------------------ drivers/acpi/apei/ghes.c | 6 ++++-- drivers/firmware/efi/efi.c | 31 +++++++++++++++++++++++++++++++ 8 files changed, 95 insertions(+), 21 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

10 years, 9 months

3
7
0 0

Boot issue with the mustang topic branch

by Itaru Kitayama

Hi Al, The current HEAD of acpi topic branch boot process stops right after: EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services and installing virtual address map... XhcClearBiosOwnership: called to clear BIOS ownership XhcClearBiosOwnership: called to clear BIOS ownership L3c Cache: 8MB I've been testing the topic branch on one of the Mustangs in the Linaro Server lab. The firmware version is: version 1.1.0-rh-0.15 built at 14:20:32 on Mar 13 2015. Can I have your .config you are using for ACPI testing? Itaru

10 years, 9 months

1
0
0 0

Tenemos los mejores títulos para ver en xtop

by paula

Tenemos los mejores títulos para ver en xtop Encontranos con la palabra xtop en todos los buscadores Estrenos y preestrenos: 8 APELLIDOS VASCOS AGUA ANTMAN (EL HOMBRE HORMIGA) CENIZAS DEL PASADO CERCANA OBSESION (THE BOY NEXT DOOR) CHAPPIE CIUDADES DE PAPEL (PAPER TOWNS) CON DERECHO A ROCE DE CABALLOS Y DE HOMBRES DONDE SE ESCONDE EL DIABLO (WHERE THE DEVIL HIDES) DOS DIAS UNA NOCHE (DEUX JOURS UNE NUIT) DOS LOCAS EN FUGA (HOT PURSUIT) DRAGON BALL Z RESURRECTION F (LA RESURRECCION DE FREEZER) EL AÑO MAS VIOLENTO (A MOST VIOLENT YEAR) EL GRAN PEQUEÑO (LITTLE BOY) EL GRAN SECUESTRO DE MR HEINEKEN EL GURU DE LAS BODAS (THE WEDDING RINGER) EL NUEVO EXOTICO HOTEL MARIGOLD EL PAYASO DEL MAL (CLOWN) EL SECRETO DE ADALINE EL SEPTIMO ENANITO (THE 7TH DWARF) EL ULTIMO NARUTO LA PELICULA (THE LAST NARUTO THE MOVIE) ELIMINADO (UNFRIENDED) ESCRIBIENDO DE AMOR INTENSAMENTE JESSABELLE JURASSIC WORLD (JURASSIC PARK IV) LA CASA DEL DEMONIO (DEMONIC) LA DAMA DE ORO (WOMAN IN GOLD) LA MECANICA DEL CORAZON (JACK ET LA MECANIQUE DU COEUR) LA NOCHE DEL DEMONIO 3 (INSIDIOUS) LA OVEJA SHAUN LA PELICULA LOS 33 DE SAN JOSE (33) LUGARES OSCUROS (DARK PLACES) MAD MAX 4 FURIA EN LA CARRETERA MAGIC MIKE XXL MAN ON WIRE (EL ALAMBRISTA) MIENTRAS SEAMOS JOVENES (WHILE WERE YOUNG) MIL VECES BUENAS NOCHES (A THOU SAND TIMES GOODNIGHT) MINIONS MISION IMPOSIBLE 5 NACION SECRETA NOTAS PERFECTAS 2 (PITCH PERFECT 2) PIXELES POLTERGEIST (JUEGOS DIABOLICOS) PUERTAS ADENTRO (MUSARAÑAS) RAPIDOS Y FURIOSOS 7 RESUCITADOS SHOWROOM SPY UNA ESPIA DESPISTADA TE SIGUE (IT FOLLOWS) TED 2 TERAPIA DE BROADWAY (SHES FUNNY THAT WAY) TERMINATOR 5 GENESIS TERREMOTO LA FALLA DE SAN ANDRES TOMORROWLAND EL MUNDO DEL MAÑANA TRASH (LADRONES DE ESPERANZA) TRUENO Y LA CASA MAGICA UN CASTILLO EN ITALIA (UN CHATEAU EN ITALIE) UN NUEVO DESPERTAR (THE HUMBLING) UNA NOCHE PARA SOBREVIVIR (RUN ALL NIGHT) VOLEY series DE TV : A TOUCH OF CLOTH ANTMAN (EL HOMBRE HORMIGA) COMBATE DARK MATTER DEVIOUS MAIDS DOWNTON ABBEY DR HOUSE DRAGON BALL SUPE FEAR THE WALKING DEAD GAME OF THRONES GYM TONY HEROES HUMANS INFIELES (MISTRESSES) JONATHAN STRANGE AND MR NORRELL LOS CABALLEROS DEL ZODIACO ALMA DORADA MAJOR CRIMES ORANGE IS THE NEW BLACK OUTLANDER PATITO FEO STITCHERS TEEN WOLF THE BLACKLIST THE BRINK THE FOSTERS THE MESSENGERS WAYWARD PINES ZUMBA SCULPT

10 years, 9 months

1
0
0 0

[PATCH V10 0/5] 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. V10: 1. Fixed compilation issue on x86. V9: 1. Rebased to arm64-upstream-14543 of arm64/master. 2. Match strict MM type in arch_apei_get_mem_attribute(). V8: 1. For x86, always return PAGE_KERNEL for arch_apei_get_mem_attribute(). The rational is explained in comment. 2. Rebased to arm64-upstream-14201 of arm64/master, next-20150724 of linux-next/master. V7: 1. Added PROT_DEVICE_nGnRnE and PROT_NORMAL_WT to support all possible UEFI memory types for arm64. 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 (5): efi: x86: rearrange efi_mem_attributes() x86: acpi: implement arch_apei_get_mem_attributes() arm64: mm: add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT arm64: apei: implement arch_apei_get_mem_attributes() acpi, apei: use appropriate pgprot_t to map GHES memory arch/arm64/include/asm/acpi.h | 27 +++++++++++++++++++++++++++ arch/arm64/include/asm/memory.h | 1 + arch/arm64/include/asm/pgtable.h | 2 ++ arch/arm64/mm/proc.S | 4 +++- arch/x86/include/asm/acpi.h | 24 ++++++++++++++++++++++++ arch/x86/platform/efi/efi.c | 18 ------------------ drivers/acpi/apei/ghes.c | 6 ++++-- drivers/firmware/efi/efi.c | 31 +++++++++++++++++++++++++++++++ 8 files changed, 92 insertions(+), 21 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

10 years, 9 months

4
14
0 0

[PATCH V9 0/5] 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. V9: 1. Rebased to arm64-upstream-14543 of arm64/master. 2. Match strict MM type in arch_apei_get_mem_attribute(). V8: 1. For x86, always return PAGE_KERNEL for arch_apei_get_mem_attribute(). The rational is explained in comment. 2. Rebased to arm64-upstream-14201 of arm64/master, next-20150724 of linux-next/master. V7: 1. Added PROT_DEVICE_nGnRnE and PROT_NORMAL_WT to support all possible UEFI memory types for arm64. 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 (5): efi: x86: rearrange efi_mem_attributes() x86: acpi: implement arch_apei_get_mem_attributes() arm64: mm: add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT arm64: apei: implement arch_apei_get_mem_attributes() acpi, apei: use appropriate pgprot_t to map GHES memory arch/arm64/include/asm/acpi.h | 26 ++++++++++++++++++++++++++ arch/arm64/include/asm/memory.h | 1 + arch/arm64/include/asm/pgtable.h | 2 ++ arch/arm64/mm/proc.S | 4 +++- arch/x86/kernel/acpi/apei.c | 19 +++++++++++++++++++ arch/x86/platform/efi/efi.c | 18 ------------------ drivers/acpi/apei/ghes.c | 6 ++++-- drivers/firmware/efi/efi.c | 31 +++++++++++++++++++++++++++++++ include/acpi/apei.h | 1 + 9 files changed, 87 insertions(+), 21 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

10 years, 9 months

5
16
0 0

Tenemos los mejores títulos para ver en xtop

by paula

Tenemos los mejores títulos para ver en xtop Encontranos con la palabra xtop en todos los buscadores Estrenos y preestrenos: 8 APELLIDOS VASCOS AGUA ANTMAN (EL HOMBRE HORMIGA) CENIZAS DEL PASADO CERCANA OBSESION (THE BOY NEXT DOOR) CHAPPIE CIUDADES DE PAPEL (PAPER TOWNS) CON DERECHO A ROCE DE CABALLOS Y DE HOMBRES DONDE SE ESCONDE EL DIABLO (WHERE THE DEVIL HIDES) DOS DIAS UNA NOCHE (DEUX JOURS UNE NUIT) DOS LOCAS EN FUGA (HOT PURSUIT) DRAGON BALL Z RESURRECTION F (LA RESURRECCION DE FREEZER) EL AÑO MAS VIOLENTO (A MOST VIOLENT YEAR) EL GRAN PEQUEÑO (LITTLE BOY) EL GRAN SECUESTRO DE MR HEINEKEN EL GURU DE LAS BODAS (THE WEDDING RINGER) EL NUEVO EXOTICO HOTEL MARIGOLD EL PAYASO DEL MAL (CLOWN) EL SECRETO DE ADALINE EL SEPTIMO ENANITO (THE 7TH DWARF) EL ULTIMO NARUTO LA PELICULA (THE LAST NARUTO THE MOVIE) ELIMINADO (UNFRIENDED) ESCRIBIENDO DE AMOR INTENSAMENTE JESSABELLE JURASSIC WORLD (JURASSIC PARK IV) LA CASA DEL DEMONIO (DEMONIC) LA DAMA DE ORO (WOMAN IN GOLD) LA MECANICA DEL CORAZON (JACK ET LA MECANIQUE DU COEUR) LA NOCHE DEL DEMONIO 3 (INSIDIOUS) LA OVEJA SHAUN LA PELICULA LOS 33 DE SAN JOSE (33) LUGARES OSCUROS (DARK PLACES) MAD MAX 4 FURIA EN LA CARRETERA MAGIC MIKE XXL MAN ON WIRE (EL ALAMBRISTA) MIENTRAS SEAMOS JOVENES (WHILE WERE YOUNG) MIL VECES BUENAS NOCHES (A THOU SAND TIMES GOODNIGHT) MINIONS MISION IMPOSIBLE 5 NACION SECRETA NOTAS PERFECTAS 2 (PITCH PERFECT 2) PIXELES POLTERGEIST (JUEGOS DIABOLICOS) PUERTAS ADENTRO (MUSARAÑAS) RAPIDOS Y FURIOSOS 7 RESUCITADOS SHOWROOM SPY UNA ESPIA DESPISTADA TE SIGUE (IT FOLLOWS) TED 2 TERAPIA DE BROADWAY (SHES FUNNY THAT WAY) TERMINATOR 5 GENESIS TERREMOTO LA FALLA DE SAN ANDRES TOMORROWLAND EL MUNDO DEL MAÑANA TRASH (LADRONES DE ESPERANZA) TRUENO Y LA CASA MAGICA UN CASTILLO EN ITALIA (UN CHATEAU EN ITALIE) UN NUEVO DESPERTAR (THE HUMBLING) UNA NOCHE PARA SOBREVIVIR (RUN ALL NIGHT) VOLEY series DE TV : A TOUCH OF CLOTH ANTMAN (EL HOMBRE HORMIGA) COMBATE DARK MATTER DEVIOUS MAIDS DOWNTON ABBEY DR HOUSE DRAGON BALL SUPE FEAR THE WALKING DEAD GAME OF THRONES GYM TONY HEROES HUMANS INFIELES (MISTRESSES) JONATHAN STRANGE AND MR NORRELL LOS CABALLEROS DEL ZODIACO ALMA DORADA MAJOR CRIMES ORANGE IS THE NEW BLACK OUTLANDER PATITO FEO STITCHERS TEEN WOLF THE BLACKLIST THE BRINK THE FOSTERS THE MESSENGERS WAYWARD PINES ZUMBA SCULPT

10 years, 9 months

1
0
0 0

[PATCH v7 0/8] CPUFreq driver using CPPC methods

by Ashwin Chaugule

CPPC: ==== CPPC (Collaborative Processor Performance Control) is a new way to control CPU performance using an abstract continous scale as against a discretized P-state scale which is tied to CPU frequency only. It is defined in the ACPI 5.0+ spec. In brief, the basic operation involves: - OS makes a CPU performance request. (Can provide min and max tolerable bounds) - Platform (such as BMC) is free to optimize request within requested bounds depending on power/thermal budgets etc. - Platform conveys its decision back to OS The communication between OS and platform occurs through another medium called (PCC) Platform communication Channel. This is a generic mailbox like mechanism which includes doorbell semantics to indicate register updates. See drivers/mailbox/pcc.c This patchset introduces a CPPC based CPUFreq driver that works with existing governors such as ondemand. The CPPC table parsing and the CPPC communication semantics are abstracted into separate files to allow future CPPC based drivers to implement their own governors if required. Initial patchsets included an adaptation of the PID governor from intel_pstate.c. However recent experiments led to extensive modifications of the algorithm to calculate CPU busyness. Until it is verified that these changes are worthwhile, the existing governors should provide for a good enough starting point for ARM64 servers. Finer details about the PCC and CPPC spec are available in the latest ACPI 5.1 specification.[2] Testing: ======= This was tested on an SBSA compatible ARMv8 server with CPPCv2 firmware running on a remote processor. I verified that each CPUs performance limits were detected and that new performance requests were made by the on-demand governor proportional to the load on each CPU. I also verified that using the acpi_processor driver correctly maps the physical CPU ids to logical CPU ids, which helps in picking up the proper _CPC details from a processor object, in the case where CPU physical ids may not be contiguous. Changes since V6: - Separated PSS and CST from ACPI processor driver in two patches. - Made new Kconfig symbols auto selectable from Arch Kconfigs. Changes since V5: - Checkpatch cleanups. - Change pss_init to pss_perf_init. Rec by Srinivas Pandruvada. - Explicit comment explaining why postcore_initcall to pcc mailbox. - Fold acpi_processor_syscore_init/exit into CONFIG_ACPI_CST. - Added patch with dummy functions used by ACPI_HOTPLUG_CPU. Changes since V4: - Misc cleanups. Addressed feedback from Rafael. - Made acpi_processor.c independent of C-states, P-states and others. - Per CPU scanning for _CPC is now made from acpi_processor.c - Added new Kconfig options for legacy C states and P states to enable future support for newer alternatives as defined in the ACPI spec 6.0. Changes since V3: - Split CPPC backend methods into separate files. - Add frontend driver which plugs into existing CPUfreq governors. - Simplify PCC driver by moving communication space mapping and read/write into client drivers. Changes since V2: - Select driver if !X86, since intel_pstate will use HWP extensions instead. - Added more comments. - Added Freq domain awareness and PSD parsing. Changes since V1: - Create a new driver based on Dirks suggestion. - Fold in CPPC backend hooks into main driver. Changes since V0: [1] - Split intel_pstate.c into a generic PID governor and platform specific backend. - Add CPPC accessors as PID backend. [1] - http://lwn.net/Articles/608715/ [2] - http://www.uefi.org/sites/default/files/resources/ACPI_5_1release.pdf [3] - https://patches.linaro.org/40705/ Ashwin Chaugule (8): PCC: Initialize PCC Mailbox earlier at boot ACPI: Split out ACPI PSS from ACPI Processor driver ACPI: Decouple ACPI idle and ACPI processor drivers ACPI: Introduce CPU performance controls using CPPC CPPC: Add a CPUFreq driver for use with CPPC ACPI: Add weak routines for ACPI CPU Hotplug CPPC: Probe for CPPC tables for each ACPI Processor object PCC: Enable PCC only when needed arch/arm64/Kconfig | 1 + arch/x86/Kconfig | 1 + drivers/acpi/Kconfig | 41 +- drivers/acpi/Makefile | 8 +- drivers/acpi/acpi_processor.c | 18 + drivers/acpi/cppc_acpi.c | 812 ++++++++++++++++++++++++++++++++++++++++ drivers/acpi/processor_driver.c | 90 +++-- drivers/cpufreq/Kconfig | 2 +- drivers/cpufreq/Kconfig.arm | 16 + drivers/cpufreq/Kconfig.x86 | 2 + drivers/cpufreq/Makefile | 2 + drivers/cpufreq/cppc_cpufreq.c | 197 ++++++++++ drivers/mailbox/Kconfig | 2 +- drivers/mailbox/pcc.c | 8 +- include/acpi/cppc_acpi.h | 137 +++++++ include/acpi/processor.h | 129 +++++-- 16 files changed, 1392 insertions(+), 74 deletions(-) create mode 100644 drivers/acpi/cppc_acpi.c create mode 100644 drivers/cpufreq/cppc_cpufreq.c create mode 100644 include/acpi/cppc_acpi.h -- 1.9.1

10 years, 9 months

4
45
0 0

leg-kernel tag leg-20150804.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-20150804.0 This is based on mainline kernel v4.2-rc5 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: http://git.linaro.org/leg/acpi/leg-kernel.git/commit/8ceb073a662c26983126e5… Notes :- 1) SPCR updated with patch from Leif Lindholm to match devices using _CRS not _ADR which not all devices have (it is not mandated in ACPI, SPCR or SBSA/SBBR specs).

10 years, 9 months

1
0
0 0

[PATCH] arm64: acpi: identify SPCR device by _CRS instead of _ADR

by Leif Lindholm

The first version of SPCR handling code identified the correct device by comparing the address in SPCR with _ADR objects, through walking the namespace. Instead, use the required _CRS object for this matching, making the functionality more portable. Signed-off-by: Leif Lindholm <leif.lindholm(a)linaro.org> --- By my interpretation of the spec, the use of _ADR for this purpose is incorrect. Regardless, this patch makes automatic SPCR console identification work on Juno and FVP. arch/arm64/kernel/acpi.c | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index c5c6e49..64129b8 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -313,31 +313,37 @@ static int __init acpi_parse_spcr(struct acpi_table_header *table) static acpi_status acpi_spcr_device_scan(acpi_handle handle, u32 level, void *context, void **retv) { - unsigned long long adr; + unsigned long long adr = 0; struct acpi_buffer name_buffer = { ACPI_ALLOCATE_BUFFER, NULL }; acpi_status status = AE_OK; struct acpi_device *adev; + struct list_head resource_list; + struct resource_entry *rentry; status = acpi_get_name(handle, ACPI_FULL_PATHNAME, &name_buffer); if (ACPI_FAILURE(status)) return status; + adev = acpi_bus_get_acpi_device(handle); + if (!adev) { + pr_err("Err locating SPCR device from ACPI handle\n"); + return AE_OK; /* skip this one */ + } + /* - * does thie APCI entry have an associated Address? + * Read device address from _CRS. */ - status = acpi_evaluate_integer(handle, "_ADR", NULL, &adr); - if (ACPI_FAILURE(status)) - return AE_OK; /* not device we are interested in... */ - - if (adr == spcr_serial_addr) { - - adev = acpi_bus_get_acpi_device(handle); + INIT_LIST_HEAD(&resource_list); + if (acpi_dev_get_resources(adev, &resource_list, NULL, NULL) <= 0) + return AE_OK; - if (!adev) { - pr_err("Err locating SPCR device from ACPI handle\n"); - return AE_OK; /* skip this one */ - } + list_for_each_entry(rentry, &resource_list, node) { + if (resource_type(rentry->res) == IORESOURCE_MEM) + adr = rentry->res->start; + } + acpi_dev_free_resource_list(&resource_list); + if (adr == spcr_serial_addr) { acpi_spcr_serial_device = adev; pr_info("SPCR serial console: %s (0x%llx)\n", -- 2.1.4

10 years, 9 months

2
2
0 0

leg-kernel tag leg-20150731.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-20150731.0 This is based on mainline kernel v4.2-rc4 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: http://git.linaro.org/leg/acpi/leg-kernel.git/commit/8ceceb6b2d134c11d9884f… Notes :- 1) Fixes a problem with SPCR support

10 years, 9 months

1
0
0 0

leg-kernel tag leg-20150730.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-20150730.0 This is based on mainline kernel v4.2-rc4 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: http://git.linaro.org/leg/acpi/leg-kernel.git/commit/3d2e8b224ff7ab03ed88cf… Notes :- 1)

10 years, 9 months

1
0
0 0

[PATCH V7 0/5] 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. V7: 1. Added PROT_DEVICE_nGnRnE and PROT_NORMAL_WT to support all possible UEFI memory types for arm64. 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 (5): efi: x86: rearrange efi_mem_attributes() x86: acpi: implement arch_apei_get_mem_attributes() arm64: mm: add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT arm64: apei: implement arch_apei_get_mem_attributes() acpi, apei: use appropriate pgprot_t to map GHES memory arch/arm64/include/asm/acpi.h | 26 ++++++++++++++++++++++++++ arch/arm64/include/asm/memory.h | 1 + arch/arm64/include/asm/pgtable.h | 2 ++ arch/arm64/mm/proc.S | 6 ++++-- 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 + 9 files changed, 79 insertions(+), 22 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

10 years, 9 months

6
21
0 0

[PATCH V8 0/5] 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. V8: 1. For x86, always return PAGE_KERNEL for arch_apei_get_mem_attribute(). The rational is explained in comment. 2. Rebased to arm64-upstream-14201 of arm64/master, next-20150724 of linux-next/master. V7: 1. Added PROT_DEVICE_nGnRnE and PROT_NORMAL_WT to support all possible UEFI memory types for arm64. 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 (5): efi: x86: rearrange efi_mem_attributes() x86: acpi: implement arch_apei_get_mem_attributes() arm64: mm: add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT arm64: apei: implement arch_apei_get_mem_attributes() acpi, apei: use appropriate pgprot_t to map GHES memory arch/arm64/include/asm/acpi.h | 26 ++++++++++++++++++++++++++ arch/arm64/include/asm/memory.h | 1 + arch/arm64/include/asm/pgtable.h | 2 ++ arch/arm64/mm/proc.S | 4 +++- arch/x86/kernel/acpi/apei.c | 19 +++++++++++++++++++ arch/x86/platform/efi/efi.c | 18 ------------------ drivers/acpi/apei/ghes.c | 6 ++++-- drivers/firmware/efi/efi.c | 31 +++++++++++++++++++++++++++++++ include/acpi/apei.h | 1 + 9 files changed, 87 insertions(+), 21 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

10 years, 9 months

3
9
0 0

acpi-topic-mustang

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

10 years, 9 months

1
0
0 0

[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

10 years, 9 months

5
20
0 0

[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

10 years, 9 months

2
4
0 0

[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

10 years, 9 months

3
5
0 0

[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

10 years, 9 months

4
10
0 0

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

10 years, 9 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-acpi