Linaro-acpi December 2014

linaro-acpi@lists.linaro.org

31 participants
23 discussions

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

by Tomasz Nowicki

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

7 years

[RFC PATCH 0/7] hw/arm/virt: Dynamic ACPI v5.1 table generation

by Alexander Spyridakis

Currently, the virt machine model generates Device Tree information dynamically based on the existing devices in the system. This patch series extends the same concept but for ACPI information instead. A total of seven tables have been implemented in this patch series, which is the minimum for a basic ARM support. The set of generated tables are: - RSDP - XSDT - MADT - GTDT - FADT - FACS - DSDT The tables are created in standalone buffers, taking into account the needed information passed from the virt machine model. When the generation is finalized, the individual buffers are compacted to a single ACPI binary blob, where it is injected on the guest memory space in a fixed location. The guest kernel can find the ACPI tables by providing to it the physical address of the ACPI blob (e.g. acpi_rsdp=0x47000000 boot argument). This series has been tested on the Foundation Model 0.8 build 5206 and the Juno development board. For kernel and driver support it is based on the "Introduce ACPI for ARM64 based on ACPI 5.1" and "Drivers for Juno to boot from ACPI" patch series from Hanjun Guo. Alexander Spyridakis (7): hw/i386: Move ACPI header definitions in an arch-independent location hw/arm/virt-acpi: Basic skeleton for dynamic generation of ACPI tables hw/arm/virt-acpi: Generate RSDP and XSDT, add helper functions hw/arm/virt-acpi: Generate FACS and FADT, update ACPI headers hw/arm/virt-acpi: GIC and Arch Timer definitions in MADT and GTDT hw/arm/virt-acpi: Generation of DSDT including virt devices hw/arm/virt: Enable dynamic generation of ACPI v5.1 tables hw/arm/Makefile.objs | 2 +- hw/arm/boot.c | 26 +++ hw/arm/virt-acpi.c | 555 ++++++++++++++++++++++++++++++++++++++++++++ hw/arm/virt.c | 54 ++++- hw/i386/acpi-build.c | 2 +- hw/i386/acpi-defs.h | 368 ----------------------------- include/hw/acpi/acpi-defs.h | 535 ++++++++++++++++++++++++++++++++++++++++++ include/hw/arm/arm.h | 2 + include/hw/arm/virt-acpi.h | 73 ++++++ tests/bios-tables-test.c | 2 +- 10 files changed, 1244 insertions(+), 375 deletions(-) create mode 100644 hw/arm/virt-acpi.c delete mode 100644 hw/i386/acpi-defs.h create mode 100644 include/hw/acpi/acpi-defs.h create mode 100644 include/hw/arm/virt-acpi.h -- 1.9.1

9 years, 1 month

[PATCH 0/6] PCI: MMCONFIG clean up

by Tomasz Nowicki

MMCFG ACPI table has no arch dependencies so it can be used across all architectures. Currently MMCONFIG related code resides in arch/x86 directories. This patch set is goint to isolate non-architecure specific code and make it accessible from drivers/pci/ directory. Tomasz Nowicki (6): x86, acpi, pci: Reorder logic of pci_mmconfig_insert() function x86, acpi, pci: Move arch-agnostic MMCFG code out of arch/x86/ directory x86, acpi, pci: Move PCI config space accessors. x86, acpi, pci: mmconfig_{32,64}.c code refactoring - remove code duplication. x86, acpi, pci: mmconfig_64.c becomes default implementation for arch agnostic low-level direct PCI config space accessors via MMCONFIG. pci, acpi: Share ACPI PCI config space accessors. arch/x86/include/asm/pci.h | 42 +++++ arch/x86/include/asm/pci_x86.h | 72 -------- arch/x86/pci/Makefile | 5 +- arch/x86/pci/acpi.c | 1 + arch/x86/pci/init.c | 1 + arch/x86/pci/mmconfig-shared.c | 242 ++++--------------------- arch/x86/pci/mmconfig_32.c | 11 +- arch/x86/pci/mmconfig_64.c | 153 ---------------- drivers/acpi/Makefile | 1 + drivers/acpi/bus.c | 1 + drivers/acpi/mmconfig.c | 396 +++++++++++++++++++++++++++++++++++++++++ include/linux/mmconfig.h | 62 +++++++ include/linux/pci.h | 8 - 13 files changed, 541 insertions(+), 454 deletions(-) delete mode 100644 arch/x86/pci/mmconfig_64.c create mode 100644 drivers/acpi/mmconfig.c create mode 100644 include/linux/mmconfig.h -- 1.9.1

9 years, 2 months

[PATCH v5 00/18] Introduce ACPI for ARM64 based on ACPI 5.1

by Hanjun Guo

ACPI 5.1 has some major changes for ARM platform and the following tables which are essential for ARM platforms: 1) MADT table updates for GIC v2/v3. 2) FADT updates for PSCI 3) GTDT for arch timer This patch set is the ARM64 ACPI core patches covered MADT, FADT and GTDT, platform board specific drivers are not covered by this patch set. We first introduce acpi.c and its related head file which are needed by ACPI core, and then get RSDP to extract all the ACPI boot-time tables. When all the boot-time tables (FADT, MADT, GTDT) are ready, then parse them to init the sytem when booted. Specifically, a) we use FADT to init PSCI and use PSCI to boot SMP; b) Use MADT for GIC init and SMP init; c) GTDT for arch timer init. This patch set is based on 3.17-rc4 and was tested by Graeme on Juno and FVP base model boot with ACPI only OK, if you want to test them, you can pull from acpi-5.1-v5 branch in leg/acpi repo: git://git.linaro.org/leg/acpi/acpi.git Updates since v4: - ACPI uasge doc for ARM64 was updated a lot by Al - Collect some ACKs from Grant, Olof, Mark - address some comments from Olof and Catalin since last version Updates since v3: - Compile out sleep.c on ARM64 when ACPI enabled - refactor the GIC init code to address the comments from Marc and Arnd - refactor the SMP init code to fix some logic problem when PSCI is not present, also address some of Grant and Lorenzo's comments - reorder the patch series and move ACPI table changes to the front of patch set - rebase on top of 3.17-rc4 Updates since v2: - Refactor the code to make SMP/PSCI init with less sperated init path by Tomasz - make ACPI depend on EXPERT - Address lots of comments from Catalin, Sudeep, Geoff - Add Juno device ACPI driver patches for review Updates since v1: - Set ACPI default off on ARM64 suggested by Olof; - Rebase the patch set on top of linux-next branch/linux-pm tree which includes the ACPICA for full ACPI 5.1 support. - Update the document as suggested; - Adress lots of comments from Mark, Sudeep, Randy, Naresh, Olof, Geoff and more... Al Stone (3): ARM64 / ACPI: Get RSDP and ACPI boot-time tables ARM64 / ACPI: Introduce early_param for "acpi" and pass acpi=force to enable ACPI ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64 Ashwin Chaugule (1): ACPI / table: Add new function to get table entries Graeme Gregory (4): ARM64 / ACPI: Introduce sleep-arm.c ARM64 / ACPI: If we chose to boot from acpi then disable FDT ARM64 / ACPI: Enable ARM64 in Kconfig Documentation: ACPI for ARM64 Hanjun Guo (8): ARM64: Move the init of cpu_logical_map(0) before unflatten_device_tree() ARM64 / ACPI: Make PCI optional for ACPI on ARM64 ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init ACPI / table: Print GIC information when MADT is parsed ARM64 / ACPI: Parse MADT for SMP initialization ACPI / processor: Make it possible to get CPU hardware ID via GICC ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi ARM64 / ACPI: Parse GTDT to initialize arch timer Tomasz Nowicki (2): ACPI / table: Count matched and successfully parsed entries without specifying max entries ARM64 / ACPI: Add GICv2 specific ACPI boot support Documentation/arm64/arm-acpi.txt | 323 ++++++++++++++++++++++++++++++ Documentation/kernel-parameters.txt | 3 +- arch/arm64/Kconfig | 3 + arch/arm64/include/asm/acenv.h | 18 ++ arch/arm64/include/asm/acpi.h | 99 ++++++++++ arch/arm64/include/asm/cpu_ops.h | 1 + arch/arm64/include/asm/pci.h | 11 ++ arch/arm64/include/asm/psci.h | 3 +- arch/arm64/include/asm/smp.h | 5 +- arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/acpi.c | 356 ++++++++++++++++++++++++++++++++++ arch/arm64/kernel/cpu_ops.c | 4 +- arch/arm64/kernel/psci.c | 78 +++++--- arch/arm64/kernel/setup.c | 25 ++- arch/arm64/kernel/smp.c | 2 +- arch/arm64/kernel/time.c | 7 + drivers/acpi/Kconfig | 6 +- drivers/acpi/Makefile | 6 +- drivers/acpi/bus.c | 3 + drivers/acpi/internal.h | 5 + drivers/acpi/processor_core.c | 37 ++++ drivers/acpi/sleep-arm.c | 28 +++ drivers/acpi/tables.c | 115 +++++++++-- drivers/clocksource/arm_arch_timer.c | 117 +++++++++-- drivers/irqchip/irq-gic.c | 106 ++++++++++ drivers/irqchip/irqchip.c | 3 + include/linux/acpi.h | 5 + include/linux/clocksource.h | 6 + include/linux/irqchip/arm-gic-acpi.h | 31 +++ include/linux/pci.h | 37 +++- 30 files changed, 1353 insertions(+), 91 deletions(-) create mode 100644 Documentation/arm64/arm-acpi.txt create mode 100644 arch/arm64/include/asm/acenv.h create mode 100644 arch/arm64/include/asm/acpi.h create mode 100644 arch/arm64/include/asm/pci.h create mode 100644 arch/arm64/kernel/acpi.c create mode 100644 drivers/acpi/sleep-arm.c create mode 100644 include/linux/irqchip/arm-gic-acpi.h -- 1.7.9.5

9 years, 3 months

[RFC] ACPI on arm64 TODO List

by Al Stone

Back in September 2014, a meeting was held at Linaro Connect where we discussed what issues remained before the arm64 ACPI core patches could be merged into the kernel, creating the TODO list below. I should have published this list sooner; I got focused on trying to resolve some of the issues instead. We have made some progress on all of these items. But, I want to make sure we haven't missed something. Since this list was compiled by only the people in the room at Connect, it is probable we have. I, for one, do not yet claim omniscience. So, I want to ask the ARM and ACPI communities: -- Is this list correct? -- Is this list complete? Below is what we currently know about; very brief notes on status are included. The TL;DR versions of the TODO list and the current status can be found at: https://wiki.linaro.org/LEG/Engineering/Kernel/ACPI/CoreUpstreamNotes and I'll do my best to kept that up to date. Thanks. Any and all feedback is greatly appreciated. TODO List for ACPI on arm64: ============================ 1. Define how Aarch64 OS identifies itself to firmware. * Problem: * _OSI method is demonstrably unreliable. On x86 Linux claims to be Windows * Proposal to use _OSC method as replacement is complicated and creates an explosion of combinations * Solution: * Draft and propose OS identification rules to ABST and ASWG for inclusion in ACPI spec. * Draft and propose recommended practice for current ACPI 5.1 spec platforms. * Status: Little progress, still under investigation 2. Linux must choose DT booting by default when offered both ACPI and DT on arm64 * DONE 3. Linux UEFI/ACPI testing tools must be made available * Problem: * Hardware/Firmware vendors do not have tools to test Linux compatibility. * Common problems go undetected if not tested for. * Solution: * Port FWTS tool and LuvOS distribution to AArch64 * Make LuvOS images readily available * Require hardware vendors to actively test against old and new kernels. * Status: LuvOS and FWTS ported to arm64 and running; patches being mainlined; additional test cases being written. 4. Set clear expectations for those providing ACPI for use with Linux * Problem: * Hardware/Firmware vendors can and will create ACPI tables that cannot be used by Linux without some guidance * Kernel developers cannot determine whether the kernel or firmware is broken without knowing what the firmware should do * Solution: document the expectations, and iterate as needed. Enforce when we must. * Status: initial kernel text available; AMD has offered to make their guidance document generic; firmware summit planned for deeper discussions. 5. Demonstrate the ACPI core patches work * Problem: how can we be sure the patches work? * Solution: verify the patches on arm64 server platforms * Status: * ACPI core works on at least the Foundation model, Juno, APM Mustang, and AMD Seattle * FWTS results will be published as soon as possible 6. How does the kernel handle_DSD usage? * Problem: * _DSD defines key-value properties in the DT style. How do we ensure _DSD bindings are well defined? * How do we ensure DT and _DSD bindings remain consistent with each other? * Solution: public documentation for all bindings, and a process for defining them * Status: proposal to require patch authors to point at public binding documentation; kernel Documentation/devicetree/bindings remains the default if no other location exists; UEFI forum has set up a binding repository. 7. Why is ACPI required? * Problem: * arm64 maintainers still haven't been convinced that ACPI is necessary. * Why do hardware and OS vendors say ACPI is required? * Status: Al & Grant collecting statements from OEMs to be posted publicly early in the new year; firmware summit for broader discussion planned. 8. Platform support patches need review * Problem: the core Aarch64 patches have been reviewed and are in good shape, but there is not yet a good example of server platform support patches that use them. * Solution: Post *good* patches for multiple ACPI platforms * Status: first version for AMD Seattle has been posted to the public linaro-acpi mailing list for initial review (thanks, Arnd), refined versions to be posted to broader lists after a few iterations for basic cleanup -- ciao, al ----------------------------------- Al Stone Software Engineer Linaro Enterprise Group al.stone(a)linaro.org -----------------------------------

9 years, 3 months

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

by Suravee Suthikulpanit

This patch series introduce ACPI support for non-PCI AHCI platform driver. Existing ACPI support for AHCI assumes the device controller is a PCI device. Also, since there is no ACPI _HID/_CID for generic AHCI controller, the driver could not use them for matching devices. Therefore, this patch introduces a mechanism for drivers to match devices using ACPI _CLS method. This patch series is rebased from: http://git.linaro.org/leg/acpi/acpi.git acpi-5.1-v6 This topic was discussed earlier here (as part of introducing support for AMD Seattle SATA controller): http://marc.info/?l=linux-arm-kernel&m=141083492521584&w=2 Changes from RFC (https://lkml.org/lkml/2014/12/17/446) * Remove #ifdef and make non-ACPI version of the acpi_match_device_cls as inline. (per Arnd) * Simplify logic to retrieve and evaluate _CLS handle. (per Hanjun) Suravee Suthikulpanit (2): ACPI / scan: Add support for ACPI _CLS device matching ata: ahci_platform: Add ACPI _CLS matching drivers/acpi/scan.c | 63 +++++++++++++++++++++++++++++++++++++++++ drivers/ata/Kconfig | 2 +- drivers/ata/ahci_platform.c | 3 ++ include/acpi/acnames.h | 1 + include/linux/acpi.h | 12 +++++++- include/linux/device.h | 1 + include/linux/mod_devicetable.h | 6 ++++ 7 files changed, 86 insertions(+), 2 deletions(-) -- 1.9.3

9 years, 3 months

[PATCH 00/28] Rough draft topic branch for Mustang

by al.stone＠linaro.org

From: Al Stone <ahs3(a)redhat.com> The following patches are pretty much the same core as used for the Seattle topic branch. There are a few additional APM X-Gene specific patches. These are not final by any stretch of the imagination. As with the Seattle patches, there is much work to be done for PCI (especially since the Mustang hardware is a very special case), and it is a known the the network card does not yet work properly. So why commit these patches? Simply put, to record the current progress and make visible the current work on Mustang. This kernel does boot and run, and PCI does seem to work. As noted, the NIC is not yet correct but this is being investigated and may be firmware related, not kernel. Al Stone (3): Fix arm64 compilation error in PNP code clocksource: arm_arch_timer: fix system hang arm64/pci/acpi: initial support for ACPI probing of PCI Graeme Gregory (2): acpi: add arm to the platforms that use ioremap tty: SBSA compatible UART Hanjun Guo (1): ARM64 / ACPI: Introduce some PCI functions when PCI is enabled Kyle McMartin (1): arm64: don't set READ_IMPLIES_EXEC for EM_AARCH64 ELF objects Mark Salter (17): ahci_xgene: add errata workaround for ATA_CMD_SMART arm64: use EFI as last resort for reboot and poweroff acpi: fix acpi_os_ioremap for arm64 arm64: add parking protocol support sata/xgene: support acpi probing xgene: add support for ACPI-probed serial port Revert "ahci_xgene: Skip the PHY and clock initialization if already configured by the firmware." arm64: add sev to parking protocol arm64: avoid need for console= to enable serial console xgene acpi network - first cut acpi: add utility to test for device dma coherency arm64: [NOT FOR UPSTREAM] fix dma_ops for ACPI and PCI devices arm64/pci: replace weak raw pci ops with settable ops arm64/acpi/pci: add support for parsing MCFG table arm64/acpi/pci: provide hook for MCFG fixups PCI: xgene: Provide fixup for ACPI MCFG support iommu/arm-smmu: fix NULL dereference with ACPI PCI devices Mika Westerberg (2): ACPI: Add support for device specific properties ACPI: Allow drivers to match using Device Tree compatible property Rafael J. Wysocki (2): Driver core: Unified device properties interface for platform firmware Driver core: Unified interface for firmware node properties arch/arm64/Kconfig | 6 + arch/arm64/Makefile | 1 + arch/arm64/include/asm/acpi.h | 3 + arch/arm64/include/asm/elf.h | 3 +- arch/arm64/include/asm/pci.h | 57 +++ arch/arm64/include/asm/smp.h | 5 + arch/arm64/kernel/Makefile | 3 +- arch/arm64/kernel/acpi.c | 54 +- arch/arm64/kernel/cpu_ops.c | 4 + arch/arm64/kernel/efi.c | 11 + arch/arm64/kernel/pci.c | 108 ++-- arch/arm64/kernel/process.c | 6 + arch/arm64/kernel/setup.c | 22 + arch/arm64/kernel/smp_parking_protocol.c | 110 ++++ arch/arm64/mm/dma-mapping.c | 103 ++++ arch/arm64/pci/Makefile | 2 + arch/arm64/pci/mmconfig.c | 431 ++++++++++++++++ arch/arm64/pci/pci.c | 375 ++++++++++++++ drivers/acpi/Makefile | 1 + drivers/acpi/internal.h | 6 + drivers/acpi/osl.c | 6 +- drivers/acpi/property.c | 567 ++++++++++++++++++++ drivers/acpi/scan.c | 120 ++++- drivers/acpi/utils.c | 26 + drivers/ata/ahci_xgene.c | 30 +- drivers/base/Makefile | 2 +- drivers/base/property.c | 625 +++++++++++++++++++++++ drivers/clocksource/arm_arch_timer.c | 9 +- drivers/iommu/arm-smmu.c | 8 +- drivers/irqchip/irq-gic-v3.c | 10 + drivers/irqchip/irq-gic.c | 10 + drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 77 ++- drivers/net/ethernet/apm/xgene/xgene_enet_main.c | 68 ++- drivers/net/ethernet/apm/xgene/xgene_enet_main.h | 1 + drivers/of/base.c | 102 +++- drivers/pci/host/pci-xgene.c | 144 ++++++ drivers/pnp/resource.c | 2 + drivers/tty/Kconfig | 6 + drivers/tty/Makefile | 1 + drivers/tty/sbsauart.c | 355 +++++++++++++ drivers/tty/serial/8250/8250_dw.c | 9 + include/acpi/acpi_bus.h | 27 + include/acpi/acpi_io.h | 6 + include/asm-generic/vmlinux.lds.h | 7 + include/linux/acpi.h | 106 +++- include/linux/irqchip/arm-gic.h | 2 + include/linux/of.h | 44 ++ include/linux/property.h | 107 ++++ 48 files changed, 3670 insertions(+), 118 deletions(-) create mode 100644 arch/arm64/kernel/smp_parking_protocol.c create mode 100644 arch/arm64/pci/Makefile create mode 100644 arch/arm64/pci/mmconfig.c create mode 100644 arch/arm64/pci/pci.c create mode 100644 drivers/acpi/property.c create mode 100644 drivers/base/property.c create mode 100644 drivers/tty/sbsauart.c create mode 100644 include/linux/property.h -- 1.9.3

9 years, 3 months

[PATCH 1/3] Revert "gcc-4.8: Redefine dynamic linker for aarch64"

by Graeme Gregory

This reverts commit d1977a6b7f7555fea4f328efbb0be6c590472030. Conflicts: meta/recipes-devtools/gcc/gcc-4.8.inc --- meta/recipes-devtools/gcc/gcc-4.8.inc | 1 - .../gcc/gcc-4.8/redefine-dynamic-linker-for-aarch64.patch | 11 ----------- 2 files changed, 12 deletions(-) delete mode 100644 meta/recipes-devtools/gcc/gcc-4.8/redefine-dynamic-linker-for-aarch64.patch diff --git a/meta/recipes-devtools/gcc/gcc-4.8.inc b/meta/recipes-devtools/gcc/gcc-4.8.inc index 1e0c6d4..69a7449 100644 --- a/meta/recipes-devtools/gcc/gcc-4.8.inc +++ b/meta/recipes-devtools/gcc/gcc-4.8.inc @@ -77,7 +77,6 @@ SRC_URI = "${GNU_MIRROR}/gcc/gcc-${PV}/gcc-${PV}.tar.bz2 \ file://0045-gcc-4.8-PR57717-PowerPC-E500v2.patch \ file://0046-libatomic-deptracking.patch \ file://0047-repomembug.patch \ - file://redefine-dynamic-linker-for-aarch64.patch \ file://use-lib-for-aarch64.patch \ " SRC_URI[md5sum] = "3b2386c114cd74185aa3754b58a79304" diff --git a/meta/recipes-devtools/gcc/gcc-4.8/redefine-dynamic-linker-for-aarch64.patch b/meta/recipes-devtools/gcc/gcc-4.8/redefine-dynamic-linker-for-aarch64.patch deleted file mode 100644 index 3b49f63..0000000 --- a/meta/recipes-devtools/gcc/gcc-4.8/redefine-dynamic-linker-for-aarch64.patch +++ /dev/null @@ -1,11 +0,0 @@ ---- a/gcc/config/aarch64/aarch64-linux.h -+++ b/gcc/config/aarch64/aarch64-linux.h -@@ -21,7 +21,7 @@ - #ifndef GCC_AARCH64_LINUX_H - #define GCC_AARCH64_LINUX_H - --#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64.so.1" -+#define GLIBC_DYNAMIC_LINKER "/lib64/ld-linux-aarch64%{mbig-endian:_be}.so.1" - - #define LINUX_TARGET_LINK_SPEC "%{h*} \ - %{static:-Bstatic} \ -- 1.9.1

9 years, 3 months

Re: [Linaro-acpi] [PATCH v5 18/18] Documentation: ACPI for ARM64

by ashwinc＠codeaurora.org

Hi Hanjun, Overall the document looks good to us. Some minor clarifications below. > ---------- Forwarded message ---------- > From: Graeme Gregory <graeme.gregory(a)linaro.org> > > Add documentation for the guidelines of how to use ACPI > on ARM64. > > Signed-off-by: Graeme Gregory <graeme.gregory(a)linaro.org> > Signed-off-by: Al Stone <al.stone(a)linaro.org> > Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org> > --- > Documentation/arm64/arm-acpi.txt | 323 > ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 323 insertions(+) > create mode 100644 Documentation/arm64/arm-acpi.txt > [..] > +Relationship with Device Tree > +----------------------------- [..] > +When booting using ACPI tables, the /chosen node in DT will still be > parsed > +to extract the kernel command line and initrd path. No other section of > the > +DT will be used. Is this still true? > +Programmable Power Control Resources > +------------------------------------ > +Programmable power control resources include such resources as > voltage/current > +providers (regulators) and clock sources. > + > +The kernel assumes that power control of these resources is represented > with > +Power Resource Objects (ACPI section 7.1). The ACPI core will then > handle > +correctly enabling and disabling resources as they are needed. In order > to > +get that to work, ACPI assumes each device has defined D-states and that > these > +can be controlled through the optional ACPI methods _PS0, _PS1, _PS2, and > _PS3; > +in ACPI, _PS0 is the method to invoke to turn a device full on, and _PS3 > is for > +turning a device full off. > + > +The kernel ACPI code will also assume that the _PS? methods follow the > normal > +ACPI rules for such methods: > + > + -- If either _PS0 or _PS3 is implemented, then the other method must > also > + be implemented. > + > + -- If a device requires usage or setup of a power resource when on, > the ASL > + should organize that it is allocated/enabled using the _PS0 method. > + > + -- Resources allocated or enabled in the _PS0 method should be > disabled > + or de-allocated in the _PS3 method. > + > + -- Firmware will leave the resources in a reasonable state before > handing > + over control to the kernel. > + We found this section could be improved a bit by explicitly calling out the options for handling device PM. Platform vendor has two choices. Resources can be managed in _PSx routine which gets called on entry to Dx. Or they can be declared separately as power resources with their own _ON and _OFF methods. They are then tied back to D-states for a particular device via _PRx which specifies which power resources a device needs to be on while in Dx. Kernel then tracks number of devices using a power resource and calls _ON/_OFF as needed. > +Such code in _PS? methods will of course be very platform specific. But, > +this allows the driver to abstract out the interface for operating the > device > +and avoid having to read special non-standard values from ACPI tables. > Further, > +abstracting the use of these resources allows the hardware to change over > time > +without requiring updates to the driver. > + I think its been mentioned in the past and you planned to add it here: we should explicitly state that with ACPI, the kernel clock/vreg framework are not expected to be used at all. > + > +Clocks > +------ > +ACPI makes the assumption that clocks are initialized by the firmware -- > +UEFI, in this case -- to some working value before control is handed over > +to the kernel. This has implications for devices such as UARTs, or SoC > +driven LCD displays, for example. > + > +When the kernel boots, the clock is assumed to be set to reasonable > +working value. If for some reason the frequency needs to change -- e.g., > +throttling for power management -- the device driver should expect that > +process to be abstracted out into some ACPI method that can be invoked Exception to this is CPU clocks where CPPC provides a much richer interface than just blindly invoking some method. > +(please see the ACPI specification for further recommendations on > standard > +methods to be expected). If is not, there is no direct way for ACPI to > +control the clocks. > + > + [..] > +ASWG > +---- > +The following areas are not yet fully defined for ARM in the 5.1 version > +of the ACPI specification and are expected to be worked through in the > +UEFI ACPI Specification Working Group (ASWG): > + > + -- ACPI based CPU topology > + -- ACPI based Power management Should clarify this to idle management rather than generic power management. > + -- CPU idle control based on PSCI > + -- CPU performance control (CPPC) There is no ongoing work on CPPC. Additional enhancements may be explored in the future, but spec is viable as is. Regards, Ashwin -- Qualcomm Innovation Center, Inc The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project --

9 years, 3 months

[PATCH v3 0/2] CPPC as a PID backend

by Ashwin Chaugule

This patchset introduces CPPC(Collaborative Processor Performance Control) as a backend to the PID governor. The PID governor from intel_pstate.c maps cleanly onto some CPPC interfaces. e.g. The CPU performance requests are made on a continuous scale as against discrete pstate levels. The CPU performance feedback over an interval is gauged using platform specific counters which are also described by CPPC. Although CPPC describes several other registers to provide more hints to the platform, Linux as of today does not have the infrastructure to make use of those registers. Some of the CPPC specific information could be made available from the scheduler as part of the CPUfreq and Scheduler intergration work. Until then PID can be used as the front end for CPPC. This implementation was tested using a Thinkpad X240 Laptop which enumerates CPPC and PCC tables in its ACPI firmware. This patchset builds on top of the PCC driver which is being reviewed separately[3]. 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. 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. The PCC driver is being discussed in a separate patchset [3] and is not included here, since CPPC is only one client of PCC. Finer details about the PCC and CPPC spec are available in the latest ACPI 5.1 specification.[2] [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 (2): CPPC as a PID controller backend ACPI PID: Add frequency domain awareness. drivers/cpufreq/Kconfig | 12 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/acpi_pid.c | 1230 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 1243 insertions(+) create mode 100644 drivers/cpufreq/acpi_pid.c -- 1.9.1

9 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-acpi December 2014