Linaro-acpi January 2015

linaro-acpi@lists.linaro.org

42 participants
26 discussions

[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, 4 months

[RFC v2] ACPI on arm64 TODO List, 11 Jan 2015

by Al Stone

Update for 11 Jan 2015: Back in September 2014, a meeting was held at Linaro Connect where we discussed what issues remained before the arm64 ACPI core patches could be merged into the kernel, creating the TODO list below. I should have published this list sooner; I got focused on trying to resolve some of the issues instead. We have made some progress on all of these items. But, I want to make sure we haven't missed something. Since this list was compiled by only the people in the room at Connect, it is probable we have. I, for one, do not yet claim omniscience. So, I want to ask the ARM and ACPI communities: -- Is this list correct? -- Is this list complete? Below is what we currently know about; very brief notes on status are included. The TL;DR versions of the TODO list and the current status can be found at: https://wiki.linaro.org/LEG/Engineering/Kernel/ACPI/CoreUpstreamNotes and I'll do my best to kept that up to date. Thanks. Any and all feedback is greatly appreciated. Changes since 14 Dec 2014: -- v6 of ACPI core patches posted -- Good progress in _OSI investigation, started preparing RFC for the mailing lists -- Precise definition of kernel behavior when defaulting to DT and/or using acpi=force being discussed again -- FWTS now runs and results posted after each merge of leg-kernel (includes ACPI) with Linus' tree (i.e., each -rc). -- ACPI on arm64 kernel document updated, under extensive discussion on the lists; starting coordination with SBBR content. -- Firmware Summit: planned for 26 Mar 2015, San Jose, CA, at the ARM office; mailing list (with archives) now up and running; updated agenda being prepared -- Merged items "Demonstrate the ACPI core patches work", and "Platform support patches need review" because of their similarity. -- Further discussions have occurred regarding "Why ACPI?"; Grant has a blog post explaining this better, and we will add that to kernel document -- Further discussion on the usage of _DSD has occurred, but much more is needed TODO List for ACPI on arm64: ============================ 1. Define how Aarch64 OS identifies itself to firmware * Problem: * _OSI method is demonstrably unreliable. On x86, Linux claims to be Windows. * Proposal to use _OSC method as replacement is complicated and creates an explosion of combinations * Solution: * Draft and propose OS identification rules to ABST and ASWG for inclusion in ACPI spec. * Draft and propose recommended practice for current ACPI 5.1 spec platforms. * Status: Good progress in _OSI investigation, started preparing RFC for the mailing lists; general agreement to deprecate _OSI completely 2. Linux must choose DT booting by default when offered both ACPI and DT on arm64 * Status: DONE, but being revisited for possible algorithmic change 3. Linux UEFI/ACPI testing tools must be made available * Problem: * Hardware/Firmware vendors do not have tools to test Linux compatibility. * Common problems go undetected if not tested for. * Solution: * Port FWTS tool and LuvOS distribution to AArch64 * Make LuvOS images readily available * Require hardware vendors to actively test against old and new kernels. * Status: * LuvOS and FWTS ported to arm64; patches in mainline; additional test cases being written. * CI loop set up to run FWTS on Foundation model for each -rc merge of Linus' tree into leg-kernel. * AMD Seattle results pending updated kernel patches. * LuvOS details at https://wiki.linaro.org/LEG/Engineering/luvOS 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: kernel text updated and under heavy discussion, AMD has made their guidance document available, and starting to coordinate content with SBBR; firmware summit date and location seems firm, agenda being updated. 5. Platform support patches need verification and review * Problem: the core Aarch64 patches have been reviewed and are in good shape, but there is not yet a good example of server platform support patches that use them. * Solution: post *good* patches for multiple ACPI platforms, demonstrating that both the core patches work, and that the use of the ACPI core makes sense. * Status: * ACPI core works on at least the Foundation model, Juno, APM Mustang, and AMD Seattle * FWTS results for the Foundation model have been posted * First version for AMD Seattle has been posted to the public linaro-acpi mailing list for initial review, refined versions to be posted to broader lists after a few iterations for basic cleanup 6. How does the kernel handle_DSD usage? * Problem: * _DSD defines key-value properties in the DT style. How do we ensure _DSD bindings are well defined? * How do we ensure DT and _DSD bindings remain consistent with each other? * Solution: public documentation for all bindings, and a process for defining them * Status: proposal 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. Discussion continues. 7. Why is ACPI required? * Problem: * arm64 maintainers still haven't been convinced that ACPI is necessary. * Why do hardware and OS vendors say ACPI is required? * Solution: discussions between those who want ACPI and arm64 maintainers * Status: Grant has provided a blog post at http://www.secretlab.ca/archives/151. Al will roll that content into the kernel documentation, also. -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3(a)redhat.com -----------------------------------

9 years, 4 months

Re: [Linaro-acpi] [PATCH] ARM64 / ACPI : Probe _PXM during pci acpi scan

by Hanjun Guo

On 2015年01月08日 17:26, Ashok Kumar wrote: > On Thu, Jan 08, 2015 at 04:00:37PM +0800, Hanjun Guo wrote: >> On 2015???01???07??? 21:32, Ashok Kumar wrote: >>> Also provided pcibus_to_node and cpumask_of_pcibus >>> based on x86. >>> >>> Signed-off-by: Ashok Kumar <ashoks(a)broadcom.com> >>> --- >>> Hanjun, >>> This patch is based on your acpi numa patchset and leg-kernel. >>> Tested it on qemu using generic pci host controller. >>> could you add this to your set of patches if it is fine? >>> Thanks! >> >> sure, I will. thanks for your patch! >> >> I already fixed the call trace of early_ioremap memory >> leak, will send another version. > Hanjun, > > Thanks! > > I just noticed the call to numa_add_memblk in acpi_numa_memory_affinity_init should use ma->length > as the second param. The syntax of numa_add_memblk is numa_add_memblk(u32 nid, u64 base, u64 size). > > diff --git a/arch/arm64/kernel/acpi_numa.c b/arch/arm64/kernel/acpi_numa.c > index 44de133..b5fc732 100644 > --- a/arch/arm64/kernel/acpi_numa.c > +++ b/arch/arm64/kernel/acpi_numa.c > @@ -147,7 +147,7 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma) > goto out_err_bad_srat; > } > > - if (numa_add_memblk(node, start, end) < 0) > + if (numa_add_memblk(node, start, ma->length) < 0) Good catch! I didn't notice Ganapat updated the numa_add_memblk() API for ARM64. > goto out_err_bad_srat; > > node_set(node, numa_nodes_parsed); > > Ganapat, > Is it possible to change the info prints of numa_add_memblk_to like below > > diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c > index 7bead6a..f293182 100644 > --- a/arch/arm64/mm/numa.c > +++ b/arch/arm64/mm/numa.c > @@ -194,7 +194,7 @@ static int __init numa_add_memblk_to(int nid, u64 start, u64 end, > } > > pr_info("NUMA: Adding memblock %d [0x%llx - 0x%llx] on node %d\n", > - mi->nr_blks, start, end, nid); > + mi->nr_blks, start, end - 1, nid); I think this is reasonable, 0x60000000 is belong to another block I think. Thanks Hanjun

9 years, 4 months

[PATCH] ARM64 / ACPI : Probe _PXM during pci acpi scan

by Ashok Kumar

Also provided pcibus_to_node and cpumask_of_pcibus based on x86. Signed-off-by: Ashok Kumar <ashoks(a)broadcom.com> --- Hanjun, This patch is based on your acpi numa patchset and leg-kernel. Tested it on qemu using generic pci host controller. could you add this to your set of patches if it is fine? Thanks! arch/arm64/include/asm/numa.h | 4 +--- arch/arm64/include/asm/pci.h | 20 ++++++++++++++++++++ arch/arm64/pci/pci.c | 5 ++++- 3 files changed, 25 insertions(+), 4 deletions(-) diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h index 3ed6edb..18716ec 100644 --- a/arch/arm64/include/asm/numa.h +++ b/arch/arm64/include/asm/numa.h @@ -12,9 +12,7 @@ /* currently, arm64 implements flat NUMA topology */ #define parent_node(node) (node) -/* dummy definitions for pci functions */ -#define pcibus_to_node(node) 0 -#define cpumask_of_pcibus(bus) 0 +#define pcibus_to_node(bus) __pcibus_to_node(bus) struct node_cpu_hwid { u32 node_id; /* logical node containing this CPU */ diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h index faad64c..522ba7c 100644 --- a/arch/arm64/include/asm/pci.h +++ b/arch/arm64/include/asm/pci.h @@ -88,6 +88,26 @@ struct acpi_mcfg_fixup { acpi_mcfg_fixup_t hook; }; +#ifdef CONFIG_NUMA +/* Returns the node based on pci bus */ +static inline int __pcibus_to_node(const struct pci_bus *bus) +{ + const struct pci_sysdata *sd = bus->sysdata; + + return sd->node; +} + +static inline const struct cpumask * +cpumask_of_pcibus(const struct pci_bus *bus) +{ + int node; + + node = __pcibus_to_node(bus); + return (node == -1) ? cpu_online_mask : + cpumask_of_node(node); +} +#endif + /* Designate a routine to fix up buggy MCFG */ #define DECLARE_ACPI_MCFG_FIXUP(oem_id, table_id, hook) \ static const struct acpi_mcfg_fixup __acpi_fixup_##hook __used \ diff --git a/arch/arm64/pci/pci.c b/arch/arm64/pci/pci.c index a1f8b08..a38753e 100644 --- a/arch/arm64/pci/pci.c +++ b/arch/arm64/pci/pci.c @@ -324,7 +324,10 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root) return NULL; } - node = NUMA_NO_NODE; + node = acpi_get_node(device->handle); + + if (node != NUMA_NO_NODE && !node_online(node)) + node = NUMA_NO_NODE; info = kzalloc_node(sizeof(*info), GFP_KERNEL, node); if (!info) { -- 1.9.1

9 years, 4 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, 4 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, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-acpi January 2015