- Linaro-acpi - lists.linaro.org

[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

10 years, 7 months

8
43
0 0

[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 -----------------------------------

10 years, 7 months

1
0
0 0

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

10 years, 7 months

2
1
0 0

[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

10 years, 7 months

3
4
0 0

[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

10 years, 7 months

2
5
0 0

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 --

10 years, 7 months

4
5
0 0

[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

10 years, 7 months

4
12
0 0

[PATCH 00/38] Seattle Topic Branch

by al.stone＠linaro.org

From: Al Stone <ahs3(a)redhat.com> This patch set is in the acpi-topic-seattle branch of acpi.git. The basic idea is that these patches are an example of how to implement ACPI for the AMD Seattle platform. Many of them have been borrowed from the Fedora arm64 kernel tree which is at: git://git.fedorahosted.org/git/kernel-arm64.git Additional patches come from Linaro and LKMLA. With the exception of the PCI patches, or others mentioned below, the intent is that the original authors of these patches will submit them upstream. As always, they rely on the ACPI core patches already being in place. Patches 0001-006 are some cleanup and nice-to-have patches that let ACPI, UEFI and the Seattle platform work better together. Patch 0007 is Graeme's SBSA console patch, which ultimately needs to be replaced with a proper pl011 console driver (still being worked on by ARM, I believe). Patch 0008 introduces ACPI support for the Seattle's AHCI code. Patch 0009 fixes a compilation error in the PNP code. Patch 0010 introduces some skeleton PCI functions to be replaced later. Patch 0011 adds support for the secondary CPU parking protocol. Patches 0011 and 0012 add general support for the AMD XGBE 10Gbe network interface. Patches 0014-0025 are from the device properties previously posted on the ACPI mailing list; these may need updates if the final versions put into the Linux tree differ. NB: 0017-0025 are not strictly required for Seattle, but have been included so that the entire patch set posted on LKMLA is included. Patch 0026 adds ACPI support to the AMD XGBE 10Gbe interface. Yes, just one patch. Patch 0027 adds code to make it easy to set up DMA coherency on a device using ACPI. Patch 0028 may or may not be useful for upstream; it corrects a problem with DMA operations when ACPI and PCI are being used but there may be better ways to handle it. Patch 0029 removes at DT dependency in the arch timer that can cause a hang when using ACPI. Patches 0030-0034 do basic PCI setup based on the contents of the MCFG table in ACPI (for PCIe); these are also a first generation and definitely need refinement and refactoring -- in some cases, there is code duplicated from x86 or ia64, for example. Patches 0035-0037 fix compiler warnings that annoyed me. Patch 0038 allows one to skip adding a console= parameter on the command line. These patches were tested on an AMD Seattle platform, using the 71C version of their firmware (future versions will have needed fixes for PCI windows and some other odds and ends). The kernel command line was: BOOT_IMAGE=/Image.acpi.git root=UUID=d5f87d27-cd7d-4ac5-9e16-dfa850ae32ad \ ro console=ttySBSA0,115200 earlycon=sbsauart,0xe1010000 vconsole.keymap=us \ crashkernel=auto vconsole.font=latarcyrheb-sun16 acpi=force \ acpi_force_table_verification uefi_debug The console, SATA, and NIC all work as expected. PCIe works (PCI will need a new DSDT) with a SATA card I had laying around. It is known to work with a couple of other PCIe devices, but that's all I tried. Things to do: -- Get PCI re-done; there are way too many x86-isms in the code, and some serious refactoring and cleanup is needed; the ia64 seems to have taken some good steps in this direction. -- MSI(-X) support: a DT version has been posted, and some ACPI work is under way. -- KVM support: ACPI support patches are available, but were not included here since I have not had time to test them. -- Subject the code to the full FWTS; this is pending available LAVA machines and some patches to FWTS, but the CI loop is set up. -- Plus whatever ACPI spec changes or additions arise.... Tested-by: Al Stone <al.stone(a)linaro.org> Aaron Lu (2): input: gpio_keys_polled - Add support for GPIO descriptors input: gpio_keys_polled - Make use of device property API Al Stone (5): Fix arm64 compilation error in PNP code arm64/pci/acpi: initial support for ACPI probing of PCI drivers/base: correct function prototype to remove compiler warning drivers/of: fix new device property function that could return a bad value AMD / XGBE : remove duplicate function definition 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 Mark Salter (11): arm64: use EFI as last resort for reboot and poweroff acpi: fix acpi_os_ioremap for arm64 arm64: add parking protocol support acpi: add utility to test for device dma coherency arm64: [NOT FOR UPSTREAM] fix dma_ops for ACPI and PCI devices clocksource: arm_arch_timer: fix system hang 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 iommu/arm-smmu: fix NULL dereference with ACPI PCI devices arm64: avoid need for console= to enable serial console Mika Westerberg (7): ACPI: Add support for device specific properties ACPI: Allow drivers to match using Device Tree compatible property misc: at25: Make use of device property API gpio / ACPI: Add support for _DSD device properties gpio: sch: Consolidate core and resume banks leds: leds-gpio: Add support for GPIO descriptors gpio: Support for unified device properties interface Rafael J. Wysocki (3): Driver core: Unified device properties interface for platform firmware Driver core: Unified interface for firmware node properties leds: leds-gpio: Make use of device property API Russell King (2): ARM: Blacklist GCC 4.8.0 to GCC 4.8.2 - PR58854 ARM: fix some printk formats Suravee Suthikulpanit (1): ata: ahci_platform: Add ACPI support for AMD Seattle SATA controller Tom Lendacky (3): drivers: net: AMD Seattle XGBE 10GbE support for A0 silicon drivers: net: AMD Seattle XGBE PHY support for A0 silicon amd-xgbe: AMD 10GbE driver APCI support for A0 Will Deacon (1): zap_pte_range: update addr when forcing flush after TLB batching faiure Documentation/acpi/gpio-properties.txt | 52 ++ arch/arm/kernel/asm-offsets.c | 12 +- arch/arm/mm/init.c | 8 +- arch/arm64/Kconfig | 6 + arch/arm64/Makefile | 1 + arch/arm64/include/asm/acpi.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 | 107 ++++ 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/Kconfig | 2 +- drivers/ata/ahci_platform.c | 13 + drivers/base/Makefile | 2 +- drivers/base/dma-coherent.c | 6 +- drivers/base/property.c | 625 +++++++++++++++++++++++ drivers/clocksource/arm_arch_timer.c | 11 +- drivers/gpio/devres.c | 36 ++ drivers/gpio/gpio-sch.c | 293 +++++------ drivers/gpio/gpiolib-acpi.c | 78 ++- drivers/gpio/gpiolib.c | 86 +++- drivers/gpio/gpiolib.h | 7 +- drivers/input/keyboard/gpio_keys_polled.c | 112 ++--- drivers/iommu/arm-smmu.c | 8 +- drivers/irqchip/irq-gic-v3.c | 10 + drivers/irqchip/irq-gic.c | 10 + drivers/leds/leds-gpio.c | 186 +++---- drivers/misc/eeprom/at25.c | 34 +- drivers/net/ethernet/amd/Kconfig | 2 +- drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 16 +- drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 3 + drivers/net/ethernet/amd/xgbe/xgbe-main.c | 289 ++++++++--- drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 20 +- drivers/net/ethernet/amd/xgbe/xgbe-ptp.c | 4 +- drivers/net/ethernet/amd/xgbe/xgbe.h | 13 + drivers/net/phy/Kconfig | 2 +- drivers/net/phy/amd-xgbe-phy.c | 791 ++++++++++++++++-------------- drivers/of/base.c | 103 +++- drivers/pnp/resource.c | 2 + drivers/tty/Kconfig | 6 + drivers/tty/Makefile | 1 + drivers/tty/sbsauart.c | 355 ++++++++++++++ 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/gpio/consumer.h | 8 + include/linux/gpio_keys.h | 3 + include/linux/irqchip/arm-gic.h | 2 + include/linux/leds.h | 1 + include/linux/of.h | 44 ++ include/linux/property.h | 107 ++++ mm/memory.c | 1 + 68 files changed, 4611 insertions(+), 923 deletions(-) create mode 100644 Documentation/acpi/gpio-properties.txt 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

10 years, 7 months

11
80
0 0

Re: [Linaro-acpi] [RFC PATCH 1/2] ACPI / scan: Add support for ACPI _CLS device matching

by Suravee Suthikulanit

On 12/19/2014 12:47 PM, Suravee Suthikulanit wrote: > On 12/19/2014 8:56 AM, Hanjun Guo wrote: >> Hi Suravee, >> >> On 2014年12月18日 07:16, Suravee Suthikulpanit wrote: >>> From: Suravee Suthikulpanit <Suravee.Suthikulpanit(a)amd.com> >>> >>> Device drivers typically use ACPI _HIDs/_CIDs listed in struct >>> device_driver >>> acpi_match_table to match devices. However, for generic drivers, we do >>> not want to list _HID for all supported devices, and some device classes >>> do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS, >>> which specifies PCI-defined class code (i.e. base-class, subclass and >>> programming interface). >>> >>> This patch adds support for matching ACPI devices using the _CLS method. >>> >>> Signed-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit(a)amd.com> >>> --- >>> drivers/acpi/scan.c | 73 >>> +++++++++++++++++++++++++++++++++++++++++ >>> include/acpi/acnames.h | 1 + >>> include/linux/acpi.h | 12 ++++++- >>> include/linux/device.h | 1 + >>> include/linux/mod_devicetable.h | 6 ++++ >>> 5 files changed, 92 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c >>> index d670158..6406648 100644 >>> --- a/drivers/acpi/scan.c >>> +++ b/drivers/acpi/scan.c >>> @@ -864,6 +864,79 @@ int acpi_match_device_ids(struct acpi_device >>> *device, >>> } >>> EXPORT_SYMBOL(acpi_match_device_ids); >>> >>> +/** >>> + * acpi_match_device_cls - Match a struct device against a ACPI _CLS >>> method >>> + * @dev_cls: A pointer to struct acpi_device_cls object to match >>> against. >>> + * @dev: The ACPI device structure to match. >>> + * >>> + * Check if @dev has a valid ACPI and _CLS handle. If there is a >>> + * struct acpi_device_cls object for that handle, use that object to >>> match >>> + * against the given struct acpi_device_cls object. >>> + * >>> + * Return 0 on success or error code on failure. >>> + */ >>> +int acpi_match_device_cls(const struct acpi_device_cls *dev_cls, >>> + const struct device *dev) >>> +{ >>> + int ret = -EINVAL; >>> + acpi_status status; >>> + struct acpi_device *adev; >>> + union acpi_object *pkg; >>> + struct acpi_device_cls cls; >>> + struct acpi_buffer buffer = { ACPI_ALLOCATE_BUFFER, NULL }; >>> + struct acpi_buffer format = { sizeof("NNN"), "NNN" }; >>> + struct acpi_buffer state = { 0, NULL }; >>> + acpi_handle handle = ACPI_HANDLE(dev); >> >> ... >> >>> + acpi_handle cls_handle; >>> + >>> + if (!handle || acpi_bus_get_device(handle, &adev)) >> >> if handle is not NULL, adev will not NULL too :) >> because you get the handle from adev, ACPI_HANDLE() is defined as: >> acpi_device_handle(ACPI_COMPANION(dev)), and adev = ACPI_COMPANION(dev); >> >> you may use adev = ACPI_COMPANION(dev) to simplify the code. >> Thanks for the pointer. >>> + return ret; >>> + >>> + if (!adev->status.present || !dev_cls) >>> + return ret; >>> + >>> + status = acpi_get_handle(adev->handle, METHOD_NAME__CLS, >>> &cls_handle); >> >> do we need this function called here? _CLS is the method under ACPI >> device object in DSDT/SSDT, and you will get adev->handle == cls_handle >> if I'm not wrong :) You are right. It is not needed, and we can just evaluate right from the handle. >>> + if (ACPI_FAILURE(status)) >>> + return ret; >>> + >>> + status = acpi_evaluate_object(cls_handle, "_CLS", NULL, &buffer); >>> + if (ACPI_FAILURE(status)) { >>> + ACPI_EXCEPTION((AE_INFO, status, "Failed to Evaluat _CLS")); >>> + return ret; >>> + } >> >> I think you can evaluate _CLS directly with handle here. >> >> Thanks >> Hanjun > Yep. I will send out the new patch in a bit. Thanks, Suravee

10 years, 8 months

1
0
0 0

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

by Suravee Suthikulpanit

From: Suravee Suthikulpanit <Suravee.Suthikulpanit(a)amd.com> 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 Suravee Suthikulpanit (2): ACPI / scan: Add support for ACPI _CLS device matching ata: ahci_platform: Add ACPI _CLS matching drivers/acpi/scan.c | 73 +++++++++++++++++++++++++++++++++++++++++ drivers/ata/Kconfig | 2 +- drivers/ata/ahci_platform.c | 10 ++++++ include/acpi/acnames.h | 1 + include/linux/acpi.h | 12 ++++++- include/linux/device.h | 1 + include/linux/mod_devicetable.h | 6 ++++ 7 files changed, 103 insertions(+), 2 deletions(-) -- 1.9.3

10 years, 8 months

5
6
0 0

leg-kernel tag leg-20141215.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-201401215.0 This is based on mainline kernel v3.18 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: https://git.linaro.org/leg/acpi/leg-kernel.git/commit/d37eefeb160cc9cc1db99… Notes :- 1) This release merges Seattle support from Redhat/AMD! https://git.linaro.org/leg/acpi/acpi.git/shortlog/refs/heads/acpi-topic-sea… 2) This release merges the Mustang support from Redhat/APM https://git.linaro.org/leg/acpi/acpi.git/shortlog/refs/heads/acpi-topic-mus… 3) This release disables STRICT_DEVMEM in distribution.conf, this is needed to work on FWTS for the short term and should not be considered a production change.

10 years, 8 months

4
3
0 0

[PATCH] Mailbox: Complete wait event only if Tx was successful

by Ashwin Chaugule

If a wait_for_completion_timeout() call returns due to a timeout, the mbox code can still call complete() after returning from the wait. This can cause subsequent transmissions on a channel to fail, since the wait_for_completion_timeout() sees the completion variable is !=0, caused by the erroneous complete() call, and immediately returns without waiting for the time as expected by the client. Fix this by calling complete() only if the TX was successful. Signed-off-by: Ashwin Chaugule <ashwin.chaugule(a)linaro.org> --- drivers/mailbox/mailbox.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c index 17e9e4a..4acaddb 100644 --- a/drivers/mailbox/mailbox.c +++ b/drivers/mailbox/mailbox.c @@ -101,7 +101,7 @@ static void tx_tick(struct mbox_chan *chan, int r) if (mssg && chan->cl->tx_done) chan->cl->tx_done(chan->cl, mssg, r); - if (chan->cl->tx_block) + if ((!r) && chan->cl->tx_block) complete(&chan->tx_complete); } -- 1.9.1

10 years, 8 months

3
6
0 0

[PATCH 0/5] ACPI based NUMA support for ARM64

by Hanjun Guo

With ACPI arm64 core paches and NUMA patch from Ganapatrao, I prepared those ACPI based NUMA support for ARM64. updates since RFC version: - Address some comments from Arnd - I tested those patches on simulation platform and find the mappings of CPU to NUMA node and memory to NUMA node are correct; - fix some compile issues with CONFIG_ACPI_NUMA disabled; - fix logical problem for the mappings of CPU to node ID There is still a warning about not released a early remapped memory, I'm working on it now. Ganapatrao Kulkarni (1): arm64:numa: adding numa support for arm64 platforms Hanjun Guo (4): ACPI / NUMA: Use pr_fmt() instead of printk ACPI / NUMA: Remove redundant ACPI_DEBUG_OUTPUT and replace ACPI_DEBUG_PRINT() with pr_debug() ARM64 / ACPI: NUMA support based on SRAT and SLIT ACPI / NUMA: Enable ACPI based NUMA on ARM64 arch/arm64/Kconfig | 33 ++ arch/arm64/include/asm/acpi.h | 7 +- arch/arm64/include/asm/mmzone.h | 32 ++ arch/arm64/include/asm/numa.h | 46 +++ arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/acpi_numa.c | 176 +++++++++++ arch/arm64/kernel/setup.c | 11 + arch/arm64/kernel/smp.c | 2 + arch/arm64/mm/Makefile | 1 + arch/arm64/mm/init.c | 34 +- arch/arm64/mm/numa.c | 674 ++++++++++++++++++++++++++++++++++++++++ drivers/acpi/Kconfig | 2 +- drivers/acpi/numa.c | 108 ++++--- drivers/acpi/processor_core.c | 5 + include/acpi/processor.h | 1 + include/linux/acpi.h | 15 + 16 files changed, 1097 insertions(+), 51 deletions(-) create mode 100644 arch/arm64/include/asm/mmzone.h create mode 100644 arch/arm64/include/asm/numa.h create mode 100644 arch/arm64/kernel/acpi_numa.c create mode 100644 arch/arm64/mm/numa.c -- 1.9.1

10 years, 8 months

2
6
0 0

[PATCH] grub_git : fix ${S} references to ${B}

by Graeme Gregory

grub does an out of tree build so ${S} points to the wrong place for binaries. Signed-off-by: Graeme Gregory <graeme.gregory(a)linaro.org> --- meta-luv/recipes-bsp/grub/grub_git.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta-luv/recipes-bsp/grub/grub_git.bb b/meta-luv/recipes-bsp/grub/grub_git.bb index 8d42537..ea85a48 100644 --- a/meta-luv/recipes-bsp/grub/grub_git.bb +++ b/meta-luv/recipes-bsp/grub/grub_git.bb @@ -52,14 +52,14 @@ do_configure_prepend() { do_install_append () { install -d ${D}${sysconfdir}/grub.d #install -m 0755 ${WORKDIR}/40_custom ${D}${sysconfdir}/grub.d/40_custom - install -m 0755 ${S}/${GRUB_IMAGE} ${D}${bindir} + install -m 0755 ${B}/${GRUB_IMAGE} ${D}${bindir} } do_deploy() { install -d ${DEPLOYDIR} - install -m 0755 ${S}/${GRUB_IMAGE} ${DEPLOYDIR} + install -m 0755 ${B}/${GRUB_IMAGE} ${DEPLOYDIR} } addtask deploy after do_install before do_build -- 1.9.1

10 years, 8 months

2
1
0 0

luvOS build and boot on ARM64

by Naresh Bhat

Hi, The luvOS distribution is booting on arm64 FVP base model. The log goes here https://pastebin.linaro.org/view/dc319415 certainly it is required to update the FWTS with arm64 patches. The git repo - http://git.linaro.org/people/naresh.bhat/luvOS/luv-yocto.git The wiki page is Under construction...:) If you want to try it on your machine. You can just copy and paste the below commands on your machine after installing the OE/Yocto dependency packages on your host machine distribution. $ git clone ssh://git@git.linaro.org/people/naresh.bhat/luvOS/luv-yocto.git $ cd luv-yocto $ . ./oe-init-build-env $ vim conf/local.conf and change the following lines in your local.conf file BB_NUMBER_THREADS ?= "16" ... ...... MACHINE ??= "genericarmv8" .... ......... DISTRO ?= "luv" save and quit local.conf file $ vim conf/bblayers.conf Add the following line to BBLAYERS variable <project-path>/luv-yocto/meta-luv e.g. BBLAYERS ?= " \ /home/nareshbhat/Projects/OE/arm64/luv-yocto/meta \ /home/nareshbhat/Projects/OE/arm64/luv-yocto/meta-yocto \ /home/nareshbhat/Projects/OE/arm64/luv-yocto/meta-yocto-bsp \ /home/nareshbhat/Projects/OE/arm64/luv-yocto/meta-luv \ " Save and quit the bblayers.conf file Now, you can start building the project $ bitbake luv-live-image which generates HDD image, ISO image. You can also generate the core-image-efi image which gives a rootfs from command $ bitbake core-image-efi Let me know if you have any issues. -Cheers Naresh

10 years, 8 months

1
0
0 0

leg-kernel tag leg-20141208.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-201401208.0 This is based on mainline kernel v3.18 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: https://git.linaro.org/leg/acpi/leg-kernel.git/commit/b93910fe23afce806af98… Notes :- 1) This release merges Seattle support from Redhat/AMD! https://git.linaro.org/leg/acpi/acpi.git/shortlog/refs/heads/acpi-topic-sea… 2) This release merges the Mustang support from Redhat/APM https://git.linaro.org/leg/acpi/acpi.git/shortlog/refs/heads/acpi-topic-mus… 3) This release disables STRICT_DEVMEM in distribution.conf, this is needed to work on FWTS for the short term and should not be considered a production change.

10 years, 8 months

2
1
0 0

[RFC PATCH 0/5] ACPI based NUMA support for ARM64

by Hanjun Guo

this is the RFC version of ACPI based NUMA support for ARM64, it is based on 3.18-rc4 and v5 of ARM64 ACPI core patches, it also based on DT based NUMA patch from Ganapatrao [1]. Have not tested yet, will do that after posted this patch for RFC, any comment are welcomed. [1] http://www.spinics.net/lists/arm-kernel/msg380197.html Ganapatrao Kulkarni (1): arm64:numa: adding numa support for arm64 platforms. Hanjun Guo (4): ACPI / NUMA: Use pr_fmt() instead of printk ACPI / NUMA: Remove redundant ACPI_DEBUG_OUTPUT ARM64 / ACPI: NUMA support based on SRAT and SLIT ACPI / NUMA: Enable ACPI based NUMA on ARM64 arch/arm64/Kconfig | 33 ++ arch/arm64/include/asm/acpi.h | 3 + arch/arm64/include/asm/mmzone.h | 32 ++ arch/arm64/include/asm/numa.h | 46 +++ arch/arm64/kernel/Makefile | 1 + arch/arm64/kernel/acpi_numa.c | 176 +++++++++++ arch/arm64/kernel/setup.c | 10 + arch/arm64/kernel/smp.c | 2 + arch/arm64/mm/Makefile | 1 + arch/arm64/mm/init.c | 34 +- arch/arm64/mm/numa.c | 675 ++++++++++++++++++++++++++++++++++++++++ drivers/acpi/Kconfig | 2 +- drivers/acpi/numa.c | 64 ++-- drivers/acpi/processor_core.c | 5 + include/acpi/processor.h | 1 + include/linux/acpi.h | 15 + 16 files changed, 1074 insertions(+), 26 deletions(-) create mode 100644 arch/arm64/include/asm/mmzone.h create mode 100644 arch/arm64/include/asm/numa.h create mode 100644 arch/arm64/kernel/acpi_numa.c create mode 100644 arch/arm64/mm/numa.c -- 1.9.1

10 years, 8 months

3
10
0 0

leg-kernel tag leg-20141203.0 released

by Graeme Gregory

The leg-kernel release has been made and tagged as leg-201401203.0 This is based on mainline kernel v3.18-rc7 Repository : http://git.linaro.org/leg/acpi/leg-kernel.git Direct Link: https://git.linaro.org/leg/acpi/leg-kernel.git/commit/2c2fa2a7b17e0d4623c47… Notes :- 1) This release merges Seattle support from Redhat/AMD! https://git.linaro.org/leg/acpi/acpi.git/shortlog/refs/heads/acpi-topic-sea… 2) This release merges the Mustang support from Redhat/APM https://git.linaro.org/leg/acpi/acpi.git/shortlog/refs/heads/acpi-topic-mus… 3) This release disables STRICT_DEVMEM in distribution.conf, this is needed to work on FWTS for the short term and should not be considered a production change.

10 years, 8 months

1
0
0 0

[PATCH 1/2] luv-live-image : correct the aarch64 cmdline

by Graeme Gregory

Signed-off-by: Graeme Gregory <graeme.gregory(a)linaro.org> --- meta-luv/recipes-core/images/luv-live-image.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta-luv/recipes-core/images/luv-live-image.bb b/meta-luv/recipes-core/images/luv-live-image.bb index 90cbc22..75d9897 100644 --- a/meta-luv/recipes-core/images/luv-live-image.bb +++ b/meta-luv/recipes-core/images/luv-live-image.bb @@ -11,7 +11,7 @@ INITRD_IMAGE = "core-image-efi-initramfs" INITRD = "${DEPLOY_DIR_IMAGE}/${INITRD_IMAGE}-${MACHINE}.cpio.gz" MACHINE_FEATURES += "efi" APPEND = "crashkernel=256M console=ttyS0,115200 console=ttyPCH0,115200" -APPEND_aarch64 = "crashkernel=256M console=ttyAMA0,38400n8 uefi_debug earlycon=pl011,0x1c090000" +APPEND_aarch64 = "crashkernel=256M console=ttySBSA0 uefi_debug earlycon=sbsauart,0x1c090000 acpi=force" SPLASH_IMAGE = "blue-luv.jpg" -- 1.9.1

10 years, 8 months

2
3
0 0

[PATCH 1/2] ACPI / table: Add new function to get table entries

by Hanjun Guo

From: Ashwin Chaugule <ashwin.chaugule(a)linaro.org> The acpi_table_parse() function has a callback that passes a pointer to a table_header. Add a new function which takes this pointer and parses its entries. This eliminates the need to re-traverse all the tables for each call. e.g. as in acpi_table_parse_madt() which is normally called after acpi_table_parse(). Acked-by: Grant Likely <grant.likely(a)linaro.org> Signed-off-by: Ashwin Chaugule <ashwin.chaugule(a)linaro.org> Signed-off-by: Tomasz Nowicki <tomasz.nowicki(a)linaro.org> Signed-off-by: Hanjun Guo <hanjun.guo(a)linaro.org> --- drivers/acpi/tables.c | 63 +++++++++++++++++++++++++++++++++++---------------- include/linux/acpi.h | 4 ++++ 2 files changed, 48 insertions(+), 19 deletions(-) diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c index 6d5a6cd..f1debe9 100644 --- a/drivers/acpi/tables.c +++ b/drivers/acpi/tables.c @@ -190,30 +190,24 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header) } } - int __init -acpi_table_parse_entries(char *id, - unsigned long table_size, - int entry_id, - acpi_tbl_entry_handler handler, - unsigned int max_entries) +acpi_parse_entries(char *id, unsigned long table_size, + acpi_tbl_entry_handler handler, + struct acpi_table_header *table_header, + int entry_id, unsigned int max_entries) { - struct acpi_table_header *table_header = NULL; struct acpi_subtable_header *entry; - unsigned int count = 0; + int count = 0; unsigned long table_end; - acpi_size tbl_size; if (acpi_disabled) return -ENODEV; - if (!handler) + if (!id || !handler) return -EINVAL; - if (strncmp(id, ACPI_SIG_MADT, 4) == 0) - acpi_get_table_with_size(id, acpi_apic_instance, &table_header, &tbl_size); - else - acpi_get_table_with_size(id, 0, &table_header, &tbl_size); + if (!table_size) + return -EINVAL; if (!table_header) { pr_warn("%4.4s not present\n", id); @@ -232,7 +226,7 @@ acpi_table_parse_entries(char *id, if (entry->type == entry_id && (!max_entries || count++ < max_entries)) if (handler(entry, table_end)) - goto err; + return -EINVAL; /* * If entry->length is 0, break from this loop to avoid @@ -240,22 +234,53 @@ acpi_table_parse_entries(char *id, */ if (entry->length == 0) { pr_err("[%4.4s:0x%02x] Invalid zero length\n", id, entry_id); - goto err; + return -EINVAL; } entry = (struct acpi_subtable_header *) ((unsigned long)entry + entry->length); } + if (max_entries && count > max_entries) { pr_warn("[%4.4s:0x%02x] ignored %i entries of %i found\n", id, entry_id, count - max_entries, count); } - early_acpi_os_unmap_memory((char *)table_header, tbl_size); return count; -err: +} + +int __init +acpi_table_parse_entries(char *id, + unsigned long table_size, + int entry_id, + acpi_tbl_entry_handler handler, + unsigned int max_entries) +{ + struct acpi_table_header *table_header = NULL; + acpi_size tbl_size; + int count; + u32 instance = 0; + + if (acpi_disabled) + return -ENODEV; + + if (!id || !handler) + return -EINVAL; + + if (!strncmp(id, ACPI_SIG_MADT, 4)) + instance = acpi_apic_instance; + + acpi_get_table_with_size(id, instance, &table_header, &tbl_size); + if (!table_header) { + pr_warn("%4.4s not present\n", id); + return -ENODEV; + } + + count = acpi_parse_entries(id, table_size, handler, table_header, + entry_id, max_entries); + early_acpi_os_unmap_memory((char *)table_header, tbl_size); - return -EINVAL; + return count; } int __init diff --git a/include/linux/acpi.h b/include/linux/acpi.h index e09f7f4..d7a5fcf 100644 --- a/include/linux/acpi.h +++ b/include/linux/acpi.h @@ -124,6 +124,10 @@ int acpi_numa_init (void); int acpi_table_init (void); int acpi_table_parse(char *id, acpi_tbl_table_handler handler); +int __init acpi_parse_entries(char *id, unsigned long table_size, + acpi_tbl_entry_handler handler, + struct acpi_table_header *table_header, + int entry_id, unsigned int max_entries); int __init acpi_table_parse_entries(char *id, unsigned long table_size, int entry_id, acpi_tbl_entry_handler handler, -- 1.9.1

10 years, 8 months

2
5
0 0

[PATCH v11 0/1] PCC: Platform Communication Channel

by Ashwin Chaugule

Changes since V10: - Replace array with dynamic allocation. - Rename index to subspace_id to avoid confusion. - Use latency instead of min turnaround time. Changes since V9: - Default to PCC subspace headers as defined in ACPI v5.1 Changes since V8: - Removed unncessary header files. - Added kerneldoc comments. - Added intro about PCC in pcc.c Changes since V7: - Added timeout to tx method in case the remote dies. - Restructured usage of acpi_status. Had inverted logic previously. Changes since V6: - Cosmetic changes based on Lv's suggestions Changes since V5: - Optimize loop that matches channel request. - Use platform_create_bundle. - Replace ioread/writes. - Remove redundant code and headers. - Restructure common mailbox macros. - Reformat PCC cmd parsing. Changes since V4: - Folded PCC Mailbox helpers into pcc.c Changes since V3: - Added PCC helper functions to work around "struct device" limitations. - PCC driver changes to work with PCC specific Mailbox helpers. Changes since V2: - Rebased on top of git://git.linaro.org/landing-teams/working/fujitsu/integration.git branch mailbox-for-3.17 - Added PCC API to mailbox framework as per Arnd's suggestion to allow usage without ACPI. Changes since V1: - Integration with Mailbox framework - https://lkml.org/lkml/2014/5/15/49 This patchset adds support for the PCC (Platform Communication Channel) interface as described in the current ACPI 5.0 spec. See Section 14 of the ACPI spec - http://acpi.info/DOWNLOADS/ACPI_5_Errata%20A.pdf for more details on how PCC works. In brief PCC is a generic means for PCC clients, to talk to the firmware. The PCC register space is typically memory mapped IO and uses a doorbell mechanism to communicate synchronously from the OS to the firmware. The PCC driver is completely agnostic to the protocol implemented by the PCC clients. It only implements the enumeration of PCC channels and the low level transport mechanism and leaves the rest to the PCC clients. The PCC is meant to be useable in the future by clients such as CPPC (Collaborative Processor Performance Control), RAS (Reliability, Availability and Serviceability) and MPST (Memory Power State Tables) and possibly others. Ashwin Chaugule (1): Mailbox: Add support for Platform Communication Channel drivers/mailbox/Kconfig | 12 ++ drivers/mailbox/Makefile | 2 + drivers/mailbox/mailbox.c | 4 +- drivers/mailbox/mailbox.h | 16 ++ drivers/mailbox/pcc.c | 403 ++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 434 insertions(+), 3 deletions(-) create mode 100644 drivers/mailbox/mailbox.h create mode 100644 drivers/mailbox/pcc.c -- 1.9.1

10 years, 8 months

3
4
0 0

[PATCHv2 0/3] updates to linaro-image-lamp for better ACPI testing

by Graeme Gregory

Hi, Just a small series to enable better testing of ACPI in LAVA without having to fetch and built test suites with git. Changes since v1 :- Missed a hunk from aapits patch that prevents test results being overwritten on test end. Thanks Graeme

10 years, 8 months

3
6
0 0

[PATCH v2 0/3] cleanups for converting apic_id to phys_id to make it arch agnostic

by Hanjun Guo

Some cleanups to convert apic_id to phys_id to accommodate ACPI 5.0+. updates since v1: - rebase on top of linux-next git repo to slove the conflicts with IOAPIC hotplug patch - modify patch 2 to update the comments and print message using arch independent words instead of APIC Hanjun Guo (3): ACPI / processor: Update the comments in processor.h ACPI / processor: Convert apic_id to phys_id to make it arch agnostic ACPI / processor: Rename acpi_(un)map_lsapic() to acpi_(un)map_cpu() arch/ia64/kernel/acpi.c | 9 ++++--- arch/x86/kernel/acpi/boot.c | 9 ++++--- drivers/acpi/acpi_processor.c | 25 ++++++++++--------- drivers/acpi/processor_core.c | 56 +++++++++++++++++++++---------------------- include/acpi/processor.h | 12 ++++++---- include/linux/acpi.h | 4 ++-- 6 files changed, 59 insertions(+), 56 deletions(-) -- 1.9.1

10 years, 8 months

1
4
0 0

leg-kernel test suits

by G Gregory

Hi, So over the last couple of days I have been looking into the test suites we currently have available in the leg-kernel CI/test cycle and come to the following conclusions. 1) aapits - tests the core of the acpica code, does not test anything in the kernel or the BIOS. Is unmaintained by acpica folks and Tomasz patches have sat idle on bug tracker for 3/4 of a year. This test suite does not test anything we are interested in I propose we drop it from CI. 2) acpica-tools - tests the iasl compiler, is run on every tools packaging for rpm/deb. I suggest the tools CI/packaging cycles are a better location for these tests and we drop them from CI 3) acpi-smoke-test - This is the basic test that we booted from ACPI, I think this is useful to keep as a quick getout of testing if it fails. 4) FWTS - current target of our testing for BIOS testing. This we keep. So I am suggesting we only have tests that exercise the kernel or BIOS in some manner. We are still lacking in tests that exercise the kernel but I have no idea what these tests should be at current time. Thanks Graeme

10 years, 8 months

4
3
0 0

[PATCH] openembedded/aapits.yaml : updates to use aapits packages in image

by Graeme Gregory

Signed-off-by: Graeme Gregory <graeme.gregory(a)linaro.org> --- openembedded/aapits.yaml | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-) diff --git a/openembedded/aapits.yaml b/openembedded/aapits.yaml index ba0b822..6a25bfd 100644 --- a/openembedded/aapits.yaml +++ b/openembedded/aapits.yaml @@ -13,15 +13,7 @@ metadata: run: steps: - - 'git clone git://git.linaro.org/leg/acpica/acpica.git' - - 'cd acpica' - - 'git branch linaro origin/linaro' - - 'git checkout linaro' - - 'make iasl' - - 'cd tests/aapits' - - 'make all' - - 'cd bin' - - './aapitsrun' - - 'cat ../tmp/raw.out' + - 'aapitsrun aapits' + - 'cat aapits/raw.out' parse: pattern: "[ a-zA-Z]+ (?P<test_case_id>[a-zA-Z0-9]+):\\s(?P<result>PASS|FAIL|SKIP)" -- 2.1.1

10 years, 8 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Linaro-acpi