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

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

[Hanjun Guo]

ACPI 5.1 was released [1] and it fixed some major gaps to run ACPI
on ARM, this patch just follow the ACPI 5.1 spec and prepare the
code to run ACPI on ARM64.

ACPI 5.1 has some major changes for the following tables and
method which are essential for ARM platforms:

1) MADT table updates.
New fields were introduced to cover MPIDR and virtualization in
GICC, and introduce GICR and GIC MSI frame structure to cover
GICv3 and GICv2m (this patch set only cover GICv2).

2) FADT updates for PSCI
New fields were introduced to cover PSCI and ACPI can use psci
to boot SMP and other PSCI related functions.

3) GTDT
GTDT was updated to support arch timer, memory-mapped tiemr,
SBSA watchdog timer, in this patch, only arch timer tested on
Juno board, so only arch timer init is available.

4) _DSD
_DSD (Device Specific Data) will provide some key values which
presented by FDT before, it makes possible that some devices can
be emumerated in ACPI way, please refer to the document provided
in this patch set for detail.

This patch set is the ARM64 ACPI core patches covered MADT, FADT
and GTDT, _DSD is not covered in 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 the former ACPICA patches I sent, and I
already compiled it OK with:
a) each patch applied on ARM64 with CONFIG_ACPI=y;
b) CONFIG_ACPI=n on ARM64;
c) CONFIG_ACPI=y on x86.

Also this patch set was tested by Graeme on ARM64 Juno platform, it
boot successfully with ACPI only (no device tree).

[1]
You can download ACPI 5.1 from http://www.uefi.org/specifications

Al Stone (3):
  ARM64 / ACPI: Get RSDP and ACPI boot-time tables
  ARM64 / ACPI: Introduce early_param for "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 lowlevel suspend function
  ARM64 / ACPI: If we chose to boot from acpi then disable FDT
  ARM64 / ACPI: Enable ARM64 in Kconfig
  Documentation: ACPI for ARM64

Hanjun Guo (10):
  ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology
  ARM64 / ACPI: Make PCI optional for ACPI on ARM64
  ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init
  ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get
    cpu_possible/present_map
  ACPI / table: Print GIC information when MADT is parsed
  ARM64 / ACPI: Move the initialization of cpu_logical_map(0) before
    acpi_boot_init()
  ARM64 / ACPI: Get the enable method for SMP initialization in ACPI
    way
  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 (1):
  ARM64 / ACPI: Add GICv2 specific ACPI boot support

 Documentation/arm64/arm-acpi.txt     |  240 ++++++++++++++++++++
 Documentation/kernel-parameters.txt  |    3 +-
 arch/arm64/Kconfig                   |    3 +
 arch/arm64/include/asm/acenv.h       |   18 ++
 arch/arm64/include/asm/acpi.h        |   90 ++++++++
 arch/arm64/include/asm/cpu.h         |   11 +
 arch/arm64/include/asm/cpu_ops.h     |    9 +-
 arch/arm64/include/asm/pci.h         |   11 +
 arch/arm64/include/asm/smp.h         |    2 +-
 arch/arm64/include/asm/topology.h    |    2 +
 arch/arm64/kernel/Makefile           |    1 +
 arch/arm64/kernel/acpi.c             |  403 ++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/cpu_ops.c          |   52 ++++-
 arch/arm64/kernel/irq.c              |    5 +
 arch/arm64/kernel/psci.c             |   95 +++++---
 arch/arm64/kernel/setup.c            |   11 +-
 arch/arm64/kernel/smp.c              |   39 +++-
 arch/arm64/kernel/time.c             |    7 +
 arch/arm64/kernel/topology.c         |   14 ++
 drivers/acpi/Kconfig                 |    6 +-
 drivers/acpi/Makefile                |    2 +-
 drivers/acpi/bus.c                   |    3 +
 drivers/acpi/internal.h              |    5 +
 drivers/acpi/processor_core.c        |   36 +++
 drivers/acpi/tables.c                |  109 +++++++--
 drivers/clocksource/arm_arch_timer.c |  117 ++++++++--
 drivers/irqchip/irq-gic.c            |  114 ++++++++++
 include/linux/acpi.h                 |    5 +
 include/linux/clocksource.h          |    6 +
 include/linux/irqchip/arm-gic-acpi.h |   36 +++
 include/linux/pci.h                  |   37 +++-
 31 files changed, 1397 insertions(+), 95 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/cpu.h
 create mode 100644 arch/arm64/include/asm/pci.h
 create mode 100644 arch/arm64/kernel/acpi.c
 create mode 100644 include/linux/irqchip/arm-gic-acpi.h

-- 
1.7.9.5

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

[Hanjun Guo]

ACPI 5.1 was released [1] and it fixed some major gaps to run ACPI
on ARM, this patch just follow the ACPI 5.1 spec and prepare the
code to run ACPI on ARM64.

ACPI 5.1 has some major changes for the following tables and
method which are essential for ARM platforms:

1) MADT table updates.
New fields were introduced to cover MPIDR and virtualization in
GICC, and introduce GICR and GIC MSI frame structure to cover
GICv3 and GICv2m (this patch set only cover GICv2).

2) FADT updates for PSCI
New fields were introduced to cover PSCI and ACPI can use psci
to boot SMP and other PSCI related functions.

3) GTDT
GTDT was updated to support arch timer, memory-mapped tiemr,
SBSA watchdog timer, in this patch, only arch timer tested on
Juno board, so only arch timer init is available.

4) _DSD
_DSD (Device Specific Data) will provide some key values which
presented by FDT before, it makes possible that some devices can
be emumerated in ACPI way, please refer to the document provided
in this patch set for detail.

This patch set is the ARM64 ACPI core patches covered MADT, FADT
and GTDT, _DSD is not covered in 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 the former ACPICA patches I sent, and I
already compiled it OK with:
a) each patch applied on ARM64 with CONFIG_ACPI=y;
b) CONFIG_ACPI=n on ARM64;
c) CONFIG_ACPI=y on x86.

Also this patch set was tested by Graeme on ARM64 Juno platform, it
boot successfully with ACPI only (no device tree).

[1]
You can download ACPI 5.1 from http://www.uefi.org/specifications

Al Stone (3):
  ARM64 / ACPI: Get RSDP and ACPI boot-time tables
  ARM64 / ACPI: Introduce early_param for "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 lowlevel suspend function
  ARM64 / ACPI: If we chose to boot from acpi then disable FDT
  ARM64 / ACPI: Enable ARM64 in Kconfig
  Documentation: ACPI for ARM64

Hanjun Guo (10):
  ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology
  ARM64 / ACPI: Make PCI optional for ACPI on ARM64
  ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init
  ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get
    cpu_possible/present_map
  ACPI / table: Print GIC information when MADT is parsed
  ARM64 / ACPI: Move the initialization of cpu_logical_map(0) before
    acpi_boot_init()
  ARM64 / ACPI: Get the enable method for SMP initialization in ACPI
    way
  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 (1):
  ARM64 / ACPI: Add GICv2 specific ACPI boot support

 Documentation/arm64/arm-acpi.txt     |  240 ++++++++++++++++++++
 Documentation/kernel-parameters.txt  |    3 +-
 arch/arm64/Kconfig                   |    3 +
 arch/arm64/include/asm/acenv.h       |   18 ++
 arch/arm64/include/asm/acpi.h        |   90 ++++++++
 arch/arm64/include/asm/cpu.h         |   11 +
 arch/arm64/include/asm/cpu_ops.h     |    9 +-
 arch/arm64/include/asm/pci.h         |   11 +
 arch/arm64/include/asm/smp.h         |    2 +-
 arch/arm64/include/asm/topology.h    |    2 +
 arch/arm64/kernel/Makefile           |    1 +
 arch/arm64/kernel/acpi.c             |  403 ++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/cpu_ops.c          |   52 ++++-
 arch/arm64/kernel/irq.c              |    5 +
 arch/arm64/kernel/psci.c             |   95 +++++---
 arch/arm64/kernel/setup.c            |   11 +-
 arch/arm64/kernel/smp.c              |   39 +++-
 arch/arm64/kernel/time.c             |    7 +
 arch/arm64/kernel/topology.c         |   14 ++
 drivers/acpi/Kconfig                 |    6 +-
 drivers/acpi/Makefile                |    2 +-
 drivers/acpi/bus.c                   |    3 +
 drivers/acpi/internal.h              |    5 +
 drivers/acpi/processor_core.c        |   36 +++
 drivers/acpi/tables.c                |  109 +++++++--
 drivers/clocksource/arm_arch_timer.c |  117 ++++++++--
 drivers/irqchip/irq-gic.c            |  114 ++++++++++
 include/linux/acpi.h                 |    5 +
 include/linux/clocksource.h          |    6 +
 include/linux/irqchip/arm-gic-acpi.h |   36 +++
 include/linux/pci.h                  |   37 +++-
 31 files changed, 1397 insertions(+), 95 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/cpu.h
 create mode 100644 arch/arm64/include/asm/pci.h
 create mode 100644 arch/arm64/kernel/acpi.c
 create mode 100644 include/linux/irqchip/arm-gic-acpi.h

-- 
1.7.9.5

[PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Hanjun Guo]

From: Al Stone <al.stone@linaro.org>

As we want to get ACPI tables to parse and then use the information
for system initialization, we should get the RSDP (Root System
Description Pointer) first, it then locates Extended Root Description
Table (XSDT) which contains all the 64-bit physical address that
pointer to other boot-time tables.

Introduce acpi.c and its related head file in this patch to provide
fundamental needs of extern variables and functions for ACPI core,
and then get boot-time tables as needed.
  - asm/cpu.h need for ACPI core and will be updated in the future to
    add definitions for arch_(un)register_cpu which are required for
    ACPI based physical CPU hotplug;
  - asm/acenv.h for arch specific ACPICA environments and
    implementation;
  - asm/acpi.h for arch specific variables and functions needed by
    ACPI driver core;
  - acpi.c for ARM64 related ACPI implementation for ACPI driver
    core;

acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
it will be called in setup_arch() before paging_init(), so we should
use eary_memremap() mechanism here to get the RSDP and all the table
pointers.

Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/acenv.h |   18 ++++++++++
 arch/arm64/include/asm/acpi.h  |   41 ++++++++++++++++++++++
 arch/arm64/include/asm/cpu.h   |   11 ++++++
 arch/arm64/kernel/Makefile     |    1 +
 arch/arm64/kernel/acpi.c       |   76 ++++++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/setup.c      |    4 +++
 6 files changed, 151 insertions(+)
 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/cpu.h
 create mode 100644 arch/arm64/kernel/acpi.c

diff --git a/arch/arm64/include/asm/acenv.h b/arch/arm64/include/asm/acenv.h
new file mode 100644
index 0000000..3899ee6
--- /dev/null
+++ b/arch/arm64/include/asm/acenv.h
@@ -0,0 +1,18 @@
+/*
+ * ARM64 specific ACPICA environments and implementation
+ *
+ * Copyright (C) 2014, Linaro Ltd.
+ *   Author: Hanjun Guo <hanjun.guo@linaro.org>
+ *   Author: Graeme Gregory <graeme.gregory@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _ASM_ACENV_H
+#define _ASM_ACENV_H
+
+#define ACPI_FLUSH_CPU_CACHE() WARN_ONCE(1, "Not currently supported on ARM64")
+
+#endif /* _ASM_ACENV_H */
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
new file mode 100644
index 0000000..e8581ea
--- /dev/null
+++ b/arch/arm64/include/asm/acpi.h
@@ -0,0 +1,41 @@
+/*
+ *  Copyright (C) 2013-2014, Linaro Ltd.
+ *	Author: Al Stone <al.stone@linaro.org>
+ *	Author: Graeme Gregory <graeme.gregory@linaro.org>
+ *	Author: Hanjun Guo <hanjun.guo@linaro.org>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation;
+ */
+
+#ifndef _ASM_ACPI_H
+#define _ASM_ACPI_H
+
+/* Basic configuration for ACPI */
+#ifdef	CONFIG_ACPI
+extern int acpi_disabled;
+extern int acpi_noirq;
+extern int acpi_pci_disabled;
+extern int acpi_strict;
+
+static inline void disable_acpi(void)
+{
+	acpi_disabled = 1;
+	acpi_pci_disabled = 1;
+	acpi_noirq = 1;
+}
+
+/*
+ * MADT must provide at least one GICC structure
+ * for GIC initialization, so CPU will be
+ * always available in MADT on ARM64
+ */
+static inline bool acpi_has_cpu_in_madt(void)
+{
+	return 1;
+}
+
+#endif /* CONFIG_ACPI */
+
+#endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
new file mode 100644
index 0000000..cee7d3f
--- /dev/null
+++ b/arch/arm64/include/asm/cpu.h
@@ -0,0 +1,11 @@
+/*
+ *  Copyright (C) 2013-2014 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ASM_CPU_H
+#define __ASM_CPU_H
+
+#endif
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index cdaedad..b568c26 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND)	+= sleep.o suspend.o
 arm64-obj-$(CONFIG_JUMP_LABEL)		+= jump_label.o
 arm64-obj-$(CONFIG_KGDB)		+= kgdb.o
 arm64-obj-$(CONFIG_EFI)			+= efi.o efi-stub.o efi-entry.o
+arm64-obj-$(CONFIG_ACPI)		+= acpi.o
 
 obj-y					+= $(arm64-obj-y) vdso/
 obj-m					+= $(arm64-obj-m)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
new file mode 100644
index 0000000..c62fce6
--- /dev/null
+++ b/arch/arm64/kernel/acpi.c
@@ -0,0 +1,76 @@
+/*
+ *  ARM64 Specific Low-Level ACPI Boot Support
+ *
+ *  Copyright (C) 2013-2014, Linaro Ltd.
+ *	Author: Al Stone <al.stone@linaro.org>
+ *	Author: Graeme Gregory <graeme.gregory@linaro.org>
+ *	Author: Hanjun Guo <hanjun.guo@linaro.org>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/acpi.h>
+#include <linux/cpumask.h>
+#include <linux/memblock.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/bootmem.h>
+#include <linux/smp.h>
+
+/*
+ * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
+ * variable is still required by the ACPI core
+ */
+u32 acpi_rsdt_forced;
+
+int acpi_noirq;			/* skip ACPI IRQ initialization */
+int acpi_strict;
+int acpi_disabled;
+EXPORT_SYMBOL(acpi_disabled);
+
+int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
+EXPORT_SYMBOL(acpi_pci_disabled);
+
+/*
+ * __acpi_map_table() will be called before page_init(), so early_ioremap()
+ * or early_memremap() should be called here to for ACPI table mapping.
+ */
+char *__init __acpi_map_table(unsigned long phys, unsigned long size)
+{
+	if (!phys || !size)
+		return NULL;
+
+	return early_memremap(phys, size);
+}
+
+void __init __acpi_unmap_table(char *map, unsigned long size)
+{
+	if (!map || !size)
+		return;
+
+	early_iounmap(map, size);
+}
+
+/*
+ * acpi_boot_table_init() called from setup_arch(), always.
+ *	1. find RSDP and get its address, and then find XSDT
+ *	2. extract all tables and checksums them all
+ *
+ * We can parse ACPI boot-time tables such as FADT, MADT after
+ * this function is called.
+ */
+void __init acpi_boot_table_init(void)
+{
+	/* If acpi_disabled, bail out */
+	if (acpi_disabled)
+		return;
+
+	/* Initialize the ACPI boot-time table parser. */
+	if (acpi_table_init()) {
+		disable_acpi();
+		return;
+	}
+}
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 46d1125..9dedb0b 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -43,6 +43,7 @@
 #include <linux/of_fdt.h>
 #include <linux/of_platform.h>
 #include <linux/efi.h>
+#include <linux/acpi.h>
 
 #include <asm/fixmap.h>
 #include <asm/cputype.h>
@@ -385,6 +386,9 @@ void __init setup_arch(char **cmdline_p)
 	efi_init();
 	arm64_memblock_init();
 
+	/* Parse the ACPI tables for possible boot-time configuration */
+	acpi_boot_table_init();
+
 	paging_init();
 	request_standard_resources();
 
-- 
1.7.9.5

[PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Hanjun Guo]

From: Al Stone <al.stone@linaro.org>

As we want to get ACPI tables to parse and then use the information
for system initialization, we should get the RSDP (Root System
Description Pointer) first, it then locates Extended Root Description
Table (XSDT) which contains all the 64-bit physical address that
pointer to other boot-time tables.

Introduce acpi.c and its related head file in this patch to provide
fundamental needs of extern variables and functions for ACPI core,
and then get boot-time tables as needed.
  - asm/cpu.h need for ACPI core and will be updated in the future to
    add definitions for arch_(un)register_cpu which are required for
    ACPI based physical CPU hotplug;
  - asm/acenv.h for arch specific ACPICA environments and
    implementation;
  - asm/acpi.h for arch specific variables and functions needed by
    ACPI driver core;
  - acpi.c for ARM64 related ACPI implementation for ACPI driver
    core;

acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
it will be called in setup_arch() before paging_init(), so we should
use eary_memremap() mechanism here to get the RSDP and all the table
pointers.

Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/acenv.h |   18 ++++++++++
 arch/arm64/include/asm/acpi.h  |   41 ++++++++++++++++++++++
 arch/arm64/include/asm/cpu.h   |   11 ++++++
 arch/arm64/kernel/Makefile     |    1 +
 arch/arm64/kernel/acpi.c       |   76 ++++++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/setup.c      |    4 +++
 6 files changed, 151 insertions(+)
 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/cpu.h
 create mode 100644 arch/arm64/kernel/acpi.c

diff --git a/arch/arm64/include/asm/acenv.h b/arch/arm64/include/asm/acenv.h
new file mode 100644
index 0000000..3899ee6
--- /dev/null
+++ b/arch/arm64/include/asm/acenv.h
@@ -0,0 +1,18 @@
+/*
+ * ARM64 specific ACPICA environments and implementation
+ *
+ * Copyright (C) 2014, Linaro Ltd.
+ *   Author: Hanjun Guo <hanjun.guo@linaro.org>
+ *   Author: Graeme Gregory <graeme.gregory@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _ASM_ACENV_H
+#define _ASM_ACENV_H
+
+#define ACPI_FLUSH_CPU_CACHE() WARN_ONCE(1, "Not currently supported on ARM64")
+
+#endif /* _ASM_ACENV_H */
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
new file mode 100644
index 0000000..e8581ea
--- /dev/null
+++ b/arch/arm64/include/asm/acpi.h
@@ -0,0 +1,41 @@
+/*
+ *  Copyright (C) 2013-2014, Linaro Ltd.
+ *	Author: Al Stone <al.stone@linaro.org>
+ *	Author: Graeme Gregory <graeme.gregory@linaro.org>
+ *	Author: Hanjun Guo <hanjun.guo@linaro.org>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation;
+ */
+
+#ifndef _ASM_ACPI_H
+#define _ASM_ACPI_H
+
+/* Basic configuration for ACPI */
+#ifdef	CONFIG_ACPI
+extern int acpi_disabled;
+extern int acpi_noirq;
+extern int acpi_pci_disabled;
+extern int acpi_strict;
+
+static inline void disable_acpi(void)
+{
+	acpi_disabled = 1;
+	acpi_pci_disabled = 1;
+	acpi_noirq = 1;
+}
+
+/*
+ * MADT must provide at least one GICC structure
+ * for GIC initialization, so CPU will be
+ * always available in MADT on ARM64
+ */
+static inline bool acpi_has_cpu_in_madt(void)
+{
+	return 1;
+}
+
+#endif /* CONFIG_ACPI */
+
+#endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
new file mode 100644
index 0000000..cee7d3f
--- /dev/null
+++ b/arch/arm64/include/asm/cpu.h
@@ -0,0 +1,11 @@
+/*
+ *  Copyright (C) 2013-2014 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ASM_CPU_H
+#define __ASM_CPU_H
+
+#endif
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index cdaedad..b568c26 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND)	+= sleep.o suspend.o
 arm64-obj-$(CONFIG_JUMP_LABEL)		+= jump_label.o
 arm64-obj-$(CONFIG_KGDB)		+= kgdb.o
 arm64-obj-$(CONFIG_EFI)			+= efi.o efi-stub.o efi-entry.o
+arm64-obj-$(CONFIG_ACPI)		+= acpi.o
 
 obj-y					+= $(arm64-obj-y) vdso/
 obj-m					+= $(arm64-obj-m)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
new file mode 100644
index 0000000..c62fce6
--- /dev/null
+++ b/arch/arm64/kernel/acpi.c
@@ -0,0 +1,76 @@
+/*
+ *  ARM64 Specific Low-Level ACPI Boot Support
+ *
+ *  Copyright (C) 2013-2014, Linaro Ltd.
+ *	Author: Al Stone <al.stone@linaro.org>
+ *	Author: Graeme Gregory <graeme.gregory@linaro.org>
+ *	Author: Hanjun Guo <hanjun.guo@linaro.org>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ */
+
+#include <linux/init.h>
+#include <linux/acpi.h>
+#include <linux/cpumask.h>
+#include <linux/memblock.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/bootmem.h>
+#include <linux/smp.h>
+
+/*
+ * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
+ * variable is still required by the ACPI core
+ */
+u32 acpi_rsdt_forced;
+
+int acpi_noirq;			/* skip ACPI IRQ initialization */
+int acpi_strict;
+int acpi_disabled;
+EXPORT_SYMBOL(acpi_disabled);
+
+int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
+EXPORT_SYMBOL(acpi_pci_disabled);
+
+/*
+ * __acpi_map_table() will be called before page_init(), so early_ioremap()
+ * or early_memremap() should be called here to for ACPI table mapping.
+ */
+char *__init __acpi_map_table(unsigned long phys, unsigned long size)
+{
+	if (!phys || !size)
+		return NULL;
+
+	return early_memremap(phys, size);
+}
+
+void __init __acpi_unmap_table(char *map, unsigned long size)
+{
+	if (!map || !size)
+		return;
+
+	early_iounmap(map, size);
+}
+
+/*
+ * acpi_boot_table_init() called from setup_arch(), always.
+ *	1. find RSDP and get its address, and then find XSDT
+ *	2. extract all tables and checksums them all
+ *
+ * We can parse ACPI boot-time tables such as FADT, MADT after
+ * this function is called.
+ */
+void __init acpi_boot_table_init(void)
+{
+	/* If acpi_disabled, bail out */
+	if (acpi_disabled)
+		return;
+
+	/* Initialize the ACPI boot-time table parser. */
+	if (acpi_table_init()) {
+		disable_acpi();
+		return;
+	}
+}
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 46d1125..9dedb0b 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -43,6 +43,7 @@
 #include <linux/of_fdt.h>
 #include <linux/of_platform.h>
 #include <linux/efi.h>
+#include <linux/acpi.h>
 
 #include <asm/fixmap.h>
 #include <asm/cputype.h>
@@ -385,6 +386,9 @@ void __init setup_arch(char **cmdline_p)
 	efi_init();
 	arm64_memblock_init();
 
+	/* Parse the ACPI tables for possible boot-time configuration */
+	acpi_boot_table_init();
+
 	paging_init();
 	request_standard_resources();
 
-- 
1.7.9.5

[PATCH 02/19] ARM64 / ACPI: Introduce early_param for "acpi"

[Hanjun Guo]

From: Al Stone <al.stone@linaro.org>

Introduce two early parameters for "acpi", one is the parameter
to disable ACPI on ARM64 and another one is acpi=strict to disable
out-of-spec workarounds.

Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 Documentation/kernel-parameters.txt |    3 ++-
 arch/arm64/kernel/acpi.c            |   21 +++++++++++++++++++++
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index b7fa2f5..d130bd5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -165,7 +165,7 @@ multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 2^20, and 2^30
 bytes respectively. Such letter suffixes can also be entirely omitted.
 
 
-	acpi=		[HW,ACPI,X86]
+	acpi=		[HW,ACPI,X86,ARM]
 			Advanced Configuration and Power Interface
 			Format: { force | off | strict | noirq | rsdt }
 			force -- enable ACPI if default was off
@@ -175,6 +175,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 				strictly ACPI specification compliant.
 			rsdt -- prefer RSDT over (default) XSDT
 			copy_dsdt -- copy DSDT to memory
+			For ARM64, ONLY "off" and "strict" are available.
 
 			See also Documentation/power/runtime_pm.txt, pci=noacpi
 
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index c62fce6..ac78e4e 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -74,3 +74,24 @@ void __init acpi_boot_table_init(void)
 		return;
 	}
 }
+
+static int __init parse_acpi(char *arg)
+{
+	if (!arg)
+		return -EINVAL;
+
+	/* "acpi=off" disables both ACPI table parsing and interpreter */
+	if (strcmp(arg, "off") == 0) {
+		disable_acpi();
+	}
+	/* acpi=strict disables out-of-spec workarounds */
+	else if (strcmp(arg, "strict") == 0) {
+		acpi_strict = 1;
+	} else {
+		/* Core will printk when we return error */
+		return -EINVAL;
+	}
+
+	return 0;
+}
+early_param("acpi", parse_acpi);
-- 
1.7.9.5

[PATCH 02/19] ARM64 / ACPI: Introduce early_param for "acpi"

[Hanjun Guo]

From: Al Stone <al.stone@linaro.org>

Introduce two early parameters for "acpi", one is the parameter
to disable ACPI on ARM64 and another one is acpi=strict to disable
out-of-spec workarounds.

Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 Documentation/kernel-parameters.txt |    3 ++-
 arch/arm64/kernel/acpi.c            |   21 +++++++++++++++++++++
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index b7fa2f5..d130bd5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -165,7 +165,7 @@ multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 2^20, and 2^30
 bytes respectively. Such letter suffixes can also be entirely omitted.
 
 
-	acpi=		[HW,ACPI,X86]
+	acpi=		[HW,ACPI,X86,ARM]
 			Advanced Configuration and Power Interface
 			Format: { force | off | strict | noirq | rsdt }
 			force -- enable ACPI if default was off
@@ -175,6 +175,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 				strictly ACPI specification compliant.
 			rsdt -- prefer RSDT over (default) XSDT
 			copy_dsdt -- copy DSDT to memory
+			For ARM64, ONLY "off" and "strict" are available.
 
 			See also Documentation/power/runtime_pm.txt, pci=noacpi
 
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index c62fce6..ac78e4e 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -74,3 +74,24 @@ void __init acpi_boot_table_init(void)
 		return;
 	}
 }
+
+static int __init parse_acpi(char *arg)
+{
+	if (!arg)
+		return -EINVAL;
+
+	/* "acpi=off" disables both ACPI table parsing and interpreter */
+	if (strcmp(arg, "off") == 0) {
+		disable_acpi();
+	}
+	/* acpi=strict disables out-of-spec workarounds */
+	else if (strcmp(arg, "strict") == 0) {
+		acpi_strict = 1;
+	} else {
+		/* Core will printk when we return error */
+		return -EINVAL;
+	}
+
+	return 0;
+}
+early_param("acpi", parse_acpi);
-- 
1.7.9.5

[PATCH 03/19] ARM64 / ACPI: Introduce lowlevel suspend function

[Hanjun Guo]

From: Graeme Gregory <graeme.gregory@linaro.org>

acpi_wakeup_address is used on x86 as the address bios jumps into
when machine wakes up from suspend. As arm64 does not have such a
bios this mechanism will be provided by other means. But the define
is still required inside the acpi core.

Introduce a null stub for acpi_suspend_lowlevel as this is also
required by core. This will be filled in when standards are
defined for arm64 ACPI global power states.

Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/acpi.h |   12 ++++++++++++
 arch/arm64/kernel/acpi.c      |    7 +++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index e8581ea..44b617f 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -36,6 +36,18 @@ static inline bool acpi_has_cpu_in_madt(void)
 	return 1;
 }
 
+/* Low-level suspend routine.
+ *
+ * ACPI S-states for ARM64 have to be defined
+ * and approved before doing anything else, maybe
+ * we need update the ACPI spec, here we
+ * just introduce function and macro needed by
+ * ACPI core as IA64 did, and revisit them when
+ * the spec is ready.
+ */
+extern int (*acpi_suspend_lowlevel)(void);
+#define acpi_wakeup_address 0
+
 #endif /* CONFIG_ACPI */
 
 #endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index ac78e4e..f5a10b5 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -95,3 +95,10 @@ static int __init parse_acpi(char *arg)
 	return 0;
 }
 early_param("acpi", parse_acpi);
+
+/*
+ * acpi_suspend_lowlevel() - save kernel state and suspend.
+ *
+ * TBD when ARM/ARM64 starts to support suspend...
+ */
+int (*acpi_suspend_lowlevel)(void);
-- 
1.7.9.5

[PATCH 03/19] ARM64 / ACPI: Introduce lowlevel suspend function

[Hanjun Guo]

From: Graeme Gregory <graeme.gregory@linaro.org>

acpi_wakeup_address is used on x86 as the address bios jumps into
when machine wakes up from suspend. As arm64 does not have such a
bios this mechanism will be provided by other means. But the define
is still required inside the acpi core.

Introduce a null stub for acpi_suspend_lowlevel as this is also
required by core. This will be filled in when standards are
defined for arm64 ACPI global power states.

Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/acpi.h |   12 ++++++++++++
 arch/arm64/kernel/acpi.c      |    7 +++++++
 2 files changed, 19 insertions(+)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index e8581ea..44b617f 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -36,6 +36,18 @@ static inline bool acpi_has_cpu_in_madt(void)
 	return 1;
 }
 
+/* Low-level suspend routine.
+ *
+ * ACPI S-states for ARM64 have to be defined
+ * and approved before doing anything else, maybe
+ * we need update the ACPI spec, here we
+ * just introduce function and macro needed by
+ * ACPI core as IA64 did, and revisit them when
+ * the spec is ready.
+ */
+extern int (*acpi_suspend_lowlevel)(void);
+#define acpi_wakeup_address 0
+
 #endif /* CONFIG_ACPI */
 
 #endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index ac78e4e..f5a10b5 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -95,3 +95,10 @@ static int __init parse_acpi(char *arg)
 	return 0;
 }
 early_param("acpi", parse_acpi);
+
+/*
+ * acpi_suspend_lowlevel() - save kernel state and suspend.
+ *
+ * TBD when ARM/ARM64 starts to support suspend...
+ */
+int (*acpi_suspend_lowlevel)(void);
-- 
1.7.9.5

[PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Hanjun Guo]

arch_fix_phys_package_id() will be called in ACPI core to use
the slot number provided by ACPI to update the physical package
id, then we can get the right value in the "physical id" field
of /proc/cpuinfo.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/topology.h |    2 ++
 arch/arm64/kernel/topology.c      |   14 ++++++++++++++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index 7ebcd31..2b216d4 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -23,11 +23,13 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
 void init_cpu_topology(void);
 void store_cpu_topology(unsigned int cpuid);
 const struct cpumask *cpu_coregroup_mask(int cpu);
+void arch_fix_phys_package_id(int num, u32 slot);
 
 #else
 
 static inline void init_cpu_topology(void) { }
 static inline void store_cpu_topology(unsigned int cpuid) { }
+static inline void arch_fix_phys_package_id(int num, u32 slot) { }
 
 #endif
 
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 43514f9..c547885 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -281,3 +281,17 @@ void __init init_cpu_topology(void)
 	if (parse_dt_topology())
 		reset_cpu_topology();
 }
+
+/*
+ * Use the CPU slot number provided by ACPI to update the physical
+ * package id when cpuid_topo->cluster_id is not available, then we
+ * can get the right value in the "physical id" field of /proc/cpuinfo.
+ */
+void arch_fix_phys_package_id(int num, u32 slot)
+{
+	struct cpu_topology *cpuid_topo = &cpu_topology[num];
+
+	if (cpuid_topo->cluster_id == -1)
+		cpuid_topo->cluster_id = slot;
+}
+EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
-- 
1.7.9.5

[PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Hanjun Guo]

arch_fix_phys_package_id() will be called in ACPI core to use
the slot number provided by ACPI to update the physical package
id, then we can get the right value in the "physical id" field
of /proc/cpuinfo.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/topology.h |    2 ++
 arch/arm64/kernel/topology.c      |   14 ++++++++++++++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index 7ebcd31..2b216d4 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -23,11 +23,13 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
 void init_cpu_topology(void);
 void store_cpu_topology(unsigned int cpuid);
 const struct cpumask *cpu_coregroup_mask(int cpu);
+void arch_fix_phys_package_id(int num, u32 slot);
 
 #else
 
 static inline void init_cpu_topology(void) { }
 static inline void store_cpu_topology(unsigned int cpuid) { }
+static inline void arch_fix_phys_package_id(int num, u32 slot) { }
 
 #endif
 
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 43514f9..c547885 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -281,3 +281,17 @@ void __init init_cpu_topology(void)
 	if (parse_dt_topology())
 		reset_cpu_topology();
 }
+
+/*
+ * Use the CPU slot number provided by ACPI to update the physical
+ * package id when cpuid_topo->cluster_id is not available, then we
+ * can get the right value in the "physical id" field of /proc/cpuinfo.
+ */
+void arch_fix_phys_package_id(int num, u32 slot)
+{
+	struct cpu_topology *cpuid_topo = &cpu_topology[num];
+
+	if (cpuid_topo->cluster_id == -1)
+		cpuid_topo->cluster_id = slot;
+}
+EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
-- 
1.7.9.5

[PATCH 05/19] ARM64 / ACPI: Make PCI optional for ACPI on ARM64

[Hanjun Guo]

As PCI for ARM64 is not ready, so introduce some stub functions
to make PCI optional for ACPI, and make ACPI core run without
CONFIG_PCI on ARM64.

Since ACPI on X86 and IA64 depends on PCI and this patch only makes
PCI optinal for ARM64, it will not break anything on X86 and IA64.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/pci.h |   11 +++++++++++
 drivers/acpi/Makefile        |    2 +-
 drivers/acpi/internal.h      |    5 +++++
 include/linux/pci.h          |   37 +++++++++++++++++++++++++++----------
 4 files changed, 44 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm64/include/asm/pci.h

diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
new file mode 100644
index 0000000..250cd24
--- /dev/null
+++ b/arch/arm64/include/asm/pci.h
@@ -0,0 +1,11 @@
+#ifndef __ASM_PCI_H
+#define __ASM_PCI_H
+#ifdef __KERNEL__
+
+/*
+ * PCI address space differs from physical memory address space
+ */
+#define PCI_DMA_BUS_IS_PHYS	(0)
+
+#endif  /* __KERNEL__ */
+#endif  /* __ASM_PCI_H */
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 505d4d7..8e9bbe6 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -39,7 +39,7 @@ acpi-y				+= processor_core.o
 acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
 acpi-y				+= ec.o
 acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
-acpi-y				+= pci_root.o pci_link.o pci_irq.o
+acpi-$(CONFIG_PCI)		+= pci_root.o pci_link.o pci_irq.o
 acpi-y				+= acpi_lpss.o
 acpi-y				+= acpi_platform.o
 acpi-y				+= acpi_pnp.o
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 4c5cf77..e1e6487 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -26,8 +26,13 @@
 acpi_status acpi_os_initialize1(void);
 int init_acpi_device_notify(void);
 int acpi_scan_init(void);
+#ifdef CONFIG_PCI
 void acpi_pci_root_init(void);
 void acpi_pci_link_init(void);
+#else
+static inline void acpi_pci_root_init(void) {}
+static inline void acpi_pci_link_init(void) {}
+#endif
 void acpi_processor_init(void);
 void acpi_platform_init(void);
 void acpi_pnp_init(void);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 466bcd1..27d7354 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -558,15 +558,6 @@ struct pci_ops {
 	int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val);
 };
 
-/*
- * ACPI needs to be able to access PCI config space before we've done a
- * PCI bus scan and created pci_bus structures.
- */
-int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
-		 int reg, int len, u32 *val);
-int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
-		  int reg, int len, u32 val);
-
 struct pci_bus_region {
 	dma_addr_t start;
 	dma_addr_t end;
@@ -1293,6 +1284,16 @@ typedef int (*arch_set_vga_state_t)(struct pci_dev *pdev, bool decode,
 		      unsigned int command_bits, u32 flags);
 void pci_register_set_vga_state(arch_set_vga_state_t func);
 
+/*
+ * ACPI needs to be able to access PCI config space before we've done a
+ * PCI bus scan and created pci_bus structures.
+ */
+int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
+		 int reg, int len, u32 *val);
+int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
+		  int reg, int len, u32 val);
+void pcibios_penalize_isa_irq(int irq, int active);
+
 #else /* CONFIG_PCI is not enabled */
 
 /*
@@ -1394,6 +1395,23 @@ static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
 						unsigned int devfn)
 { return NULL; }
 
+static inline struct pci_bus *pci_find_bus(int domain, int busnr)
+{ return NULL; }
+
+static inline int pci_bus_write_config_byte(struct pci_bus *bus,
+				unsigned int devfn, int where, u8 val)
+{ return -ENODEV; }
+
+static inline int raw_pci_read(unsigned int domain, unsigned int bus,
+			unsigned int devfn, int reg, int len, u32 *val)
+{ return -EINVAL; }
+
+static inline int raw_pci_write(unsigned int domain, unsigned int bus,
+			unsigned int devfn, int reg, int len, u32 val)
+{ return -EINVAL; }
+
+static inline void pcibios_penalize_isa_irq(int irq, int active) { }
+
 static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
 static inline struct pci_dev *pci_dev_get(struct pci_dev *dev) { return NULL; }
 
@@ -1597,7 +1615,6 @@ int pcibios_set_pcie_reset_state(struct pci_dev *dev,
 				 enum pcie_reset_state state);
 int pcibios_add_device(struct pci_dev *dev);
 void pcibios_release_device(struct pci_dev *dev);
-void pcibios_penalize_isa_irq(int irq, int active);
 
 #ifdef CONFIG_HIBERNATE_CALLBACKS
 extern struct dev_pm_ops pcibios_pm_ops;
-- 
1.7.9.5

[PATCH 05/19] ARM64 / ACPI: Make PCI optional for ACPI on ARM64

[Hanjun Guo]

As PCI for ARM64 is not ready, so introduce some stub functions
to make PCI optional for ACPI, and make ACPI core run without
CONFIG_PCI on ARM64.

Since ACPI on X86 and IA64 depends on PCI and this patch only makes
PCI optinal for ARM64, it will not break anything on X86 and IA64.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/pci.h |   11 +++++++++++
 drivers/acpi/Makefile        |    2 +-
 drivers/acpi/internal.h      |    5 +++++
 include/linux/pci.h          |   37 +++++++++++++++++++++++++++----------
 4 files changed, 44 insertions(+), 11 deletions(-)
 create mode 100644 arch/arm64/include/asm/pci.h

diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
new file mode 100644
index 0000000..250cd24
--- /dev/null
+++ b/arch/arm64/include/asm/pci.h
@@ -0,0 +1,11 @@
+#ifndef __ASM_PCI_H
+#define __ASM_PCI_H
+#ifdef __KERNEL__
+
+/*
+ * PCI address space differs from physical memory address space
+ */
+#define PCI_DMA_BUS_IS_PHYS	(0)
+
+#endif  /* __KERNEL__ */
+#endif  /* __ASM_PCI_H */
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 505d4d7..8e9bbe6 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -39,7 +39,7 @@ acpi-y				+= processor_core.o
 acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
 acpi-y				+= ec.o
 acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
-acpi-y				+= pci_root.o pci_link.o pci_irq.o
+acpi-$(CONFIG_PCI)		+= pci_root.o pci_link.o pci_irq.o
 acpi-y				+= acpi_lpss.o
 acpi-y				+= acpi_platform.o
 acpi-y				+= acpi_pnp.o
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 4c5cf77..e1e6487 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -26,8 +26,13 @@
 acpi_status acpi_os_initialize1(void);
 int init_acpi_device_notify(void);
 int acpi_scan_init(void);
+#ifdef CONFIG_PCI
 void acpi_pci_root_init(void);
 void acpi_pci_link_init(void);
+#else
+static inline void acpi_pci_root_init(void) {}
+static inline void acpi_pci_link_init(void) {}
+#endif
 void acpi_processor_init(void);
 void acpi_platform_init(void);
 void acpi_pnp_init(void);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 466bcd1..27d7354 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -558,15 +558,6 @@ struct pci_ops {
 	int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val);
 };
 
-/*
- * ACPI needs to be able to access PCI config space before we've done a
- * PCI bus scan and created pci_bus structures.
- */
-int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
-		 int reg, int len, u32 *val);
-int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
-		  int reg, int len, u32 val);
-
 struct pci_bus_region {
 	dma_addr_t start;
 	dma_addr_t end;
@@ -1293,6 +1284,16 @@ typedef int (*arch_set_vga_state_t)(struct pci_dev *pdev, bool decode,
 		      unsigned int command_bits, u32 flags);
 void pci_register_set_vga_state(arch_set_vga_state_t func);
 
+/*
+ * ACPI needs to be able to access PCI config space before we've done a
+ * PCI bus scan and created pci_bus structures.
+ */
+int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
+		 int reg, int len, u32 *val);
+int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
+		  int reg, int len, u32 val);
+void pcibios_penalize_isa_irq(int irq, int active);
+
 #else /* CONFIG_PCI is not enabled */
 
 /*
@@ -1394,6 +1395,23 @@ static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
 						unsigned int devfn)
 { return NULL; }
 
+static inline struct pci_bus *pci_find_bus(int domain, int busnr)
+{ return NULL; }
+
+static inline int pci_bus_write_config_byte(struct pci_bus *bus,
+				unsigned int devfn, int where, u8 val)
+{ return -ENODEV; }
+
+static inline int raw_pci_read(unsigned int domain, unsigned int bus,
+			unsigned int devfn, int reg, int len, u32 *val)
+{ return -EINVAL; }
+
+static inline int raw_pci_write(unsigned int domain, unsigned int bus,
+			unsigned int devfn, int reg, int len, u32 val)
+{ return -EINVAL; }
+
+static inline void pcibios_penalize_isa_irq(int irq, int active) { }
+
 static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
 static inline struct pci_dev *pci_dev_get(struct pci_dev *dev) { return NULL; }
 
@@ -1597,7 +1615,6 @@ int pcibios_set_pcie_reset_state(struct pci_dev *dev,
 				 enum pcie_reset_state state);
 int pcibios_add_device(struct pci_dev *dev);
 void pcibios_release_device(struct pci_dev *dev);
-void pcibios_penalize_isa_irq(int irq, int active);
 
 #ifdef CONFIG_HIBERNATE_CALLBACKS
 extern struct dev_pm_ops pcibios_pm_ops;
-- 
1.7.9.5

[PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Hanjun Guo]

There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
the former signals to the OS that the hardware is PSCI compliant.
The latter selects the appropriate conduit for PSCI calls by
toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
(SMC).

FADT table contains such information, parse FADT to get the flags
for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
function IDs, which means that only PSCI 0.2+ is supported in ACPI.

At the same time, only ACPI 5.1 or higher verison supports PSCI,
and FADT Major.Minor version was introduced in ACPI 5.1, so we
will check the version and only parse FADT table with version >= 5.1.

If firmware provides ACPI tables with ACPI version less than 5.1,
OS will be messed up with those information and have no way to
bring up secondery CPUs, so disable ACPI if we get an FADT table
with version less that 5.1.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
---
 arch/arm64/include/asm/acpi.h |    2 +
 arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
 arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
 arch/arm64/kernel/setup.c     |    2 +
 4 files changed, 121 insertions(+), 28 deletions(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 44b617f..67dac90 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -18,6 +18,8 @@ extern int acpi_disabled;
 extern int acpi_noirq;
 extern int acpi_pci_disabled;
 extern int acpi_strict;
+extern int acpi_psci_present;
+extern int acpi_psci_use_hvc;
 
 static inline void disable_acpi(void)
 {
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index f5a10b5..374926f 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -11,6 +11,8 @@
  *  published by the Free Software Foundation.
  */
 
+#define pr_fmt(fmt) "ACPI: " fmt
+
 #include <linux/init.h>
 #include <linux/acpi.h>
 #include <linux/cpumask.h>
@@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
 int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
 EXPORT_SYMBOL(acpi_pci_disabled);
 
+/* 1 to indicate PSCI is implemented */
+int acpi_psci_present;
+
+/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
+int acpi_psci_use_hvc;
+
 /*
  * __acpi_map_table() will be called before page_init(), so early_ioremap()
  * or early_memremap() should be called here to for ACPI table mapping.
@@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
 	early_iounmap(map, size);
 }
 
+static int __init acpi_parse_fadt(struct acpi_table_header *table)
+{
+	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
+
+	/*
+	 * Revision in table header is the FADT Major version,
+	 * and there is a minor version of FADT which was introduced
+	 * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
+	 * to get arm boot flags, or we will disable ACPI.
+	 */
+	if (table->revision < 5 || fadt->minor_version < 1) {
+		pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
+			table->revision, fadt->minor_version);
+		acpi_psci_present = 0;
+		disable_acpi();
+		return -EINVAL;
+	}
+
+	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
+		acpi_psci_present = 1;
+
+	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
+		acpi_psci_use_hvc = 1;
+
+	return 0;
+}
+
 /*
  * acpi_boot_table_init() called from setup_arch(), always.
  *	1. find RSDP and get its address, and then find XSDT
@@ -75,6 +110,21 @@ void __init acpi_boot_table_init(void)
 	}
 }
 
+int __init acpi_boot_init(void)
+{
+	int err = 0;
+
+	/* If acpi_disabled, bail out */
+	if (acpi_disabled)
+		return -ENODEV;
+
+	err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
+	if (err)
+		pr_err("Can't find FADT\n");
+
+	return err;
+}
+
 static int __init parse_acpi(char *arg)
 {
 	if (!arg)
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index 9e9798f..adb25f3 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -15,6 +15,7 @@
 
 #define pr_fmt(fmt) "psci: " fmt
 
+#include <linux/acpi.h>
 #include <linux/init.h>
 #include <linux/of.h>
 #include <linux/smp.h>
@@ -231,6 +232,33 @@ static void psci_sys_poweroff(void)
 	invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
 }
 
+static void psci_0_2_set_functions(void)
+{
+	pr_info("Using standard PSCI v0.2 function IDs\n");
+	psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
+	psci_ops.cpu_suspend = psci_cpu_suspend;
+
+	psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
+	psci_ops.cpu_off = psci_cpu_off;
+
+	psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
+	psci_ops.cpu_on = psci_cpu_on;
+
+	psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
+	psci_ops.migrate = psci_migrate;
+
+	psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
+	psci_ops.affinity_info = psci_affinity_info;
+
+	psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
+		PSCI_0_2_FN_MIGRATE_INFO_TYPE;
+	psci_ops.migrate_info_type = psci_migrate_info_type;
+
+	arm_pm_restart = psci_sys_reset;
+
+	pm_power_off = psci_sys_poweroff;
+}
+
 /*
  * PSCI Function IDs for v0.2+ are well defined so use
  * standard values.
@@ -264,29 +292,7 @@ static int psci_0_2_init(struct device_node *np)
 		}
 	}
 
-	pr_info("Using standard PSCI v0.2 function IDs\n");
-	psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
-	psci_ops.cpu_suspend = psci_cpu_suspend;
-
-	psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
-	psci_ops.cpu_off = psci_cpu_off;
-
-	psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
-	psci_ops.cpu_on = psci_cpu_on;
-
-	psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
-	psci_ops.migrate = psci_migrate;
-
-	psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
-	psci_ops.affinity_info = psci_affinity_info;
-
-	psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
-		PSCI_0_2_FN_MIGRATE_INFO_TYPE;
-	psci_ops.migrate_info_type = psci_migrate_info_type;
-
-	arm_pm_restart = psci_sys_reset;
-
-	pm_power_off = psci_sys_poweroff;
+	psci_0_2_set_functions();
 
 out_put_node:
 	of_node_put(np);
@@ -333,6 +339,33 @@ out_put_node:
 	return err;
 }
 
+#ifdef CONFIG_ACPI
+static int get_set_conduit_method_acpi(void)
+{
+	if (acpi_psci_use_hvc)
+		invoke_psci_fn = __invoke_psci_fn_hvc;
+	else
+		invoke_psci_fn = __invoke_psci_fn_smc;
+
+	return 0;
+}
+
+/* We use PSCI 0.2+ when ACPI is deployed */
+static int psci_0_2_init_acpi(void)
+{
+	get_set_conduit_method_acpi();
+
+	psci_0_2_set_functions();
+
+	return 0;
+}
+#else
+static inline int psci_0_2_init_acpi(void)
+{
+	return -ENODEV;
+}
+#endif
+
 static const struct of_device_id psci_of_match[] __initconst = {
 	{ .compatible = "arm,psci",	.data = psci_0_1_init},
 	{ .compatible = "arm,psci-0.2",	.data = psci_0_2_init},
@@ -345,13 +378,19 @@ int __init psci_init(void)
 	const struct of_device_id *matched_np;
 	psci_initcall_t init_fn;
 
-	np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
+	if (acpi_disabled) {
+		np = of_find_matching_node_and_match(NULL,
+				psci_of_match, &matched_np);
 
-	if (!np)
-		return -ENODEV;
+		if (!np)
+			return -ENODEV;
+
+		init_fn = (psci_initcall_t)matched_np->data;
+
+		return init_fn(np);
+	}
 
-	init_fn = (psci_initcall_t)matched_np->data;
-	return init_fn(np);
+	return psci_0_2_init_acpi();
 }
 
 #ifdef CONFIG_SMP
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 9dedb0b..e00d40c 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -394,6 +394,8 @@ void __init setup_arch(char **cmdline_p)
 
 	efi_idmap_init();
 
+	acpi_boot_init();
+
 	unflatten_device_tree();
 
 	psci_init();
-- 
1.7.9.5

[PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Hanjun Guo]

There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
the former signals to the OS that the hardware is PSCI compliant.
The latter selects the appropriate conduit for PSCI calls by
toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
(SMC).

FADT table contains such information, parse FADT to get the flags
for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
function IDs, which means that only PSCI 0.2+ is supported in ACPI.

At the same time, only ACPI 5.1 or higher verison supports PSCI,
and FADT Major.Minor version was introduced in ACPI 5.1, so we
will check the version and only parse FADT table with version >= 5.1.

If firmware provides ACPI tables with ACPI version less than 5.1,
OS will be messed up with those information and have no way to
bring up secondery CPUs, so disable ACPI if we get an FADT table
with version less that 5.1.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
---
 arch/arm64/include/asm/acpi.h |    2 +
 arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
 arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
 arch/arm64/kernel/setup.c     |    2 +
 4 files changed, 121 insertions(+), 28 deletions(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 44b617f..67dac90 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -18,6 +18,8 @@ extern int acpi_disabled;
 extern int acpi_noirq;
 extern int acpi_pci_disabled;
 extern int acpi_strict;
+extern int acpi_psci_present;
+extern int acpi_psci_use_hvc;
 
 static inline void disable_acpi(void)
 {
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index f5a10b5..374926f 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -11,6 +11,8 @@
  *  published by the Free Software Foundation.
  */
 
+#define pr_fmt(fmt) "ACPI: " fmt
+
 #include <linux/init.h>
 #include <linux/acpi.h>
 #include <linux/cpumask.h>
@@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
 int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
 EXPORT_SYMBOL(acpi_pci_disabled);
 
+/* 1 to indicate PSCI is implemented */
+int acpi_psci_present;
+
+/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
+int acpi_psci_use_hvc;
+
 /*
  * __acpi_map_table() will be called before page_init(), so early_ioremap()
  * or early_memremap() should be called here to for ACPI table mapping.
@@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
 	early_iounmap(map, size);
 }
 
+static int __init acpi_parse_fadt(struct acpi_table_header *table)
+{
+	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
+
+	/*
+	 * Revision in table header is the FADT Major version,
+	 * and there is a minor version of FADT which was introduced
+	 * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
+	 * to get arm boot flags, or we will disable ACPI.
+	 */
+	if (table->revision < 5 || fadt->minor_version < 1) {
+		pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
+			table->revision, fadt->minor_version);
+		acpi_psci_present = 0;
+		disable_acpi();
+		return -EINVAL;
+	}
+
+	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
+		acpi_psci_present = 1;
+
+	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
+		acpi_psci_use_hvc = 1;
+
+	return 0;
+}
+
 /*
  * acpi_boot_table_init() called from setup_arch(), always.
  *	1. find RSDP and get its address, and then find XSDT
@@ -75,6 +110,21 @@ void __init acpi_boot_table_init(void)
 	}
 }
 
+int __init acpi_boot_init(void)
+{
+	int err = 0;
+
+	/* If acpi_disabled, bail out */
+	if (acpi_disabled)
+		return -ENODEV;
+
+	err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
+	if (err)
+		pr_err("Can't find FADT\n");
+
+	return err;
+}
+
 static int __init parse_acpi(char *arg)
 {
 	if (!arg)
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index 9e9798f..adb25f3 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -15,6 +15,7 @@
 
 #define pr_fmt(fmt) "psci: " fmt
 
+#include <linux/acpi.h>
 #include <linux/init.h>
 #include <linux/of.h>
 #include <linux/smp.h>
@@ -231,6 +232,33 @@ static void psci_sys_poweroff(void)
 	invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
 }
 
+static void psci_0_2_set_functions(void)
+{
+	pr_info("Using standard PSCI v0.2 function IDs\n");
+	psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
+	psci_ops.cpu_suspend = psci_cpu_suspend;
+
+	psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
+	psci_ops.cpu_off = psci_cpu_off;
+
+	psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
+	psci_ops.cpu_on = psci_cpu_on;
+
+	psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
+	psci_ops.migrate = psci_migrate;
+
+	psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
+	psci_ops.affinity_info = psci_affinity_info;
+
+	psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
+		PSCI_0_2_FN_MIGRATE_INFO_TYPE;
+	psci_ops.migrate_info_type = psci_migrate_info_type;
+
+	arm_pm_restart = psci_sys_reset;
+
+	pm_power_off = psci_sys_poweroff;
+}
+
 /*
  * PSCI Function IDs for v0.2+ are well defined so use
  * standard values.
@@ -264,29 +292,7 @@ static int psci_0_2_init(struct device_node *np)
 		}
 	}
 
-	pr_info("Using standard PSCI v0.2 function IDs\n");
-	psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
-	psci_ops.cpu_suspend = psci_cpu_suspend;
-
-	psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
-	psci_ops.cpu_off = psci_cpu_off;
-
-	psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
-	psci_ops.cpu_on = psci_cpu_on;
-
-	psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
-	psci_ops.migrate = psci_migrate;
-
-	psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
-	psci_ops.affinity_info = psci_affinity_info;
-
-	psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
-		PSCI_0_2_FN_MIGRATE_INFO_TYPE;
-	psci_ops.migrate_info_type = psci_migrate_info_type;
-
-	arm_pm_restart = psci_sys_reset;
-
-	pm_power_off = psci_sys_poweroff;
+	psci_0_2_set_functions();
 
 out_put_node:
 	of_node_put(np);
@@ -333,6 +339,33 @@ out_put_node:
 	return err;
 }
 
+#ifdef CONFIG_ACPI
+static int get_set_conduit_method_acpi(void)
+{
+	if (acpi_psci_use_hvc)
+		invoke_psci_fn = __invoke_psci_fn_hvc;
+	else
+		invoke_psci_fn = __invoke_psci_fn_smc;
+
+	return 0;
+}
+
+/* We use PSCI 0.2+ when ACPI is deployed */
+static int psci_0_2_init_acpi(void)
+{
+	get_set_conduit_method_acpi();
+
+	psci_0_2_set_functions();
+
+	return 0;
+}
+#else
+static inline int psci_0_2_init_acpi(void)
+{
+	return -ENODEV;
+}
+#endif
+
 static const struct of_device_id psci_of_match[] __initconst = {
 	{ .compatible = "arm,psci",	.data = psci_0_1_init},
 	{ .compatible = "arm,psci-0.2",	.data = psci_0_2_init},
@@ -345,13 +378,19 @@ int __init psci_init(void)
 	const struct of_device_id *matched_np;
 	psci_initcall_t init_fn;
 
-	np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
+	if (acpi_disabled) {
+		np = of_find_matching_node_and_match(NULL,
+				psci_of_match, &matched_np);
 
-	if (!np)
-		return -ENODEV;
+		if (!np)
+			return -ENODEV;
+
+		init_fn = (psci_initcall_t)matched_np->data;
+
+		return init_fn(np);
+	}
 
-	init_fn = (psci_initcall_t)matched_np->data;
-	return init_fn(np);
+	return psci_0_2_init_acpi();
 }
 
 #ifdef CONFIG_SMP
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 9dedb0b..e00d40c 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -394,6 +394,8 @@ void __init setup_arch(char **cmdline_p)
 
 	efi_idmap_init();
 
+	acpi_boot_init();
+
 	unflatten_device_tree();
 
 	psci_init();
-- 
1.7.9.5

[PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Hanjun Guo]

MADT contains the information for MPIDR which is essential for
SMP initialization, parse the GIC cpu interface structures to
get the MPIDR value and map it to cpu_logical_map(), and add
enabled cpu with valid MPIDR into cpu_possible_map and
cpu_present_map.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
---
 arch/arm64/include/asm/acpi.h |    2 +
 arch/arm64/kernel/acpi.c      |  127 +++++++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/smp.c       |   10 +++-
 3 files changed, 138 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 67dac90..5ce85f8 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -50,6 +50,8 @@ static inline bool acpi_has_cpu_in_madt(void)
 extern int (*acpi_suspend_lowlevel)(void);
 #define acpi_wakeup_address 0
 
+#define MAX_GIC_CPU_INTERFACE 65535
+
 #endif /* CONFIG_ACPI */
 
 #endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 374926f..801e268 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -22,6 +22,9 @@
 #include <linux/bootmem.h>
 #include <linux/smp.h>
 
+#include <asm/smp_plat.h>
+#include <asm/cputype.h>
+
 /*
  * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
  * variable is still required by the ACPI core
@@ -42,6 +45,9 @@ int acpi_psci_present;
 /* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
 int acpi_psci_use_hvc;
 
+/* Processors (GICC) with enabled flag in MADT */
+static int enabled_cpus;
+
 /*
  * __acpi_map_table() will be called before page_init(), so early_ioremap()
  * or early_memremap() should be called here to for ACPI table mapping.
@@ -62,6 +68,122 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
 	early_iounmap(map, size);
 }
 
+/**
+ * acpi_register_gic_cpu_interface - register a gic cpu interface and
+ * generates a logic cpu number
+ * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
+ * @enabled: this cpu is enabled or not
+ *
+ * Returns the logic cpu number which maps to the gic cpu interface
+ */
+static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)
+{
+	int cpu;
+
+	if (mpidr == INVALID_HWID) {
+		pr_info("Skip invalid cpu hardware ID\n");
+		return -EINVAL;
+	}
+
+	total_cpus++;
+	if (!enabled)
+		return -EINVAL;
+
+	if (enabled_cpus >=  NR_CPUS) {
+		pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
+			NR_CPUS, total_cpus, mpidr);
+		return -EINVAL;
+	}
+
+	/* If it is the first CPU, no need to check duplicate MPIDRs */
+	if (!enabled_cpus)
+		goto skip_mpidr_check;
+
+	/*
+	 * Duplicate MPIDRs are a recipe for disaster. Scan
+	 * all initialized entries and check for
+	 * duplicates. If any is found just ignore the CPU.
+	 */
+	for_each_present_cpu(cpu) {
+		if (cpu_logical_map(cpu) == mpidr) {
+			pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
+			       mpidr);
+			return -EINVAL;
+		}
+	}
+
+skip_mpidr_check:
+	enabled_cpus++;
+
+	/* allocate a logic cpu id for the new comer */
+	if (cpu_logical_map(0) == mpidr) {
+		/*
+		 * boot_cpu_init() already hold bit 0 in cpu_present_mask
+		 * for BSP, no need to allocte again.
+		 */
+		cpu = 0;
+	} else {
+		cpu = cpumask_next_zero(-1, cpu_present_mask);
+	}
+
+	/* map the logic cpu id to cpu MPIDR */
+	cpu_logical_map(cpu) = mpidr;
+
+	set_cpu_possible(cpu, true);
+	set_cpu_present(cpu, true);
+
+	return cpu;
+}
+
+static int __init
+acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
+				const unsigned long end)
+{
+	struct acpi_madt_generic_interrupt *processor;
+
+	processor = (struct acpi_madt_generic_interrupt *)header;
+
+	if (BAD_MADT_ENTRY(processor, end))
+		return -EINVAL;
+
+	acpi_table_print_madt_entry(header);
+
+	acpi_register_gic_cpu_interface(processor->mpidr,
+		processor->flags & ACPI_MADT_ENABLED);
+
+	return 0;
+}
+
+/*
+ * Parse GIC cpu interface related entries in MADT
+ * returns 0 on success, < 0 on error
+ */
+static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
+{
+	int count;
+
+	/*
+	 * do a partial walk of MADT to determine how many CPUs
+	 * we have including disabled CPUs, and get information
+	 * we need for SMP init
+	 */
+	count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+			acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
+
+	if (!count) {
+		pr_err("No GIC CPU interface entries present\n");
+		return -ENODEV;
+	} else if (count < 0) {
+		pr_err("Error parsing GIC CPU interface entry\n");
+		return count;
+	}
+
+	/* Make boot-up look pretty */
+	pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
+
+	return 0;
+}
+
 static int __init acpi_parse_fadt(struct acpi_table_header *table)
 {
 	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
@@ -122,6 +244,11 @@ int __init acpi_boot_init(void)
 	if (err)
 		pr_err("Can't find FADT\n");
 
+	/* Get the boot CPU's MPIDR before MADT parsing */
+	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
+
+	err = acpi_parse_madt_gic_cpu_interface_entries();
+
 	return err;
 }
 
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 40f38f4..8f1d37c 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -36,6 +36,7 @@
 #include <linux/completion.h>
 #include <linux/of.h>
 #include <linux/irq_work.h>
+#include <linux/acpi.h>
 
 #include <asm/atomic.h>
 #include <asm/cacheflush.h>
@@ -458,7 +459,14 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 		if (err)
 			continue;
 
-		set_cpu_present(cpu, true);
+		/*
+		 * In ACPI mode, cpu_present_map was initialised when
+		 * MADT table was parsed which before this function
+		 * is called.
+		 */
+		if (acpi_disabled)
+			set_cpu_present(cpu, true);
+
 		max_cpus--;
 	}
 }
-- 
1.7.9.5

[PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Hanjun Guo]

MADT contains the information for MPIDR which is essential for
SMP initialization, parse the GIC cpu interface structures to
get the MPIDR value and map it to cpu_logical_map(), and add
enabled cpu with valid MPIDR into cpu_possible_map and
cpu_present_map.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
---
 arch/arm64/include/asm/acpi.h |    2 +
 arch/arm64/kernel/acpi.c      |  127 +++++++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/smp.c       |   10 +++-
 3 files changed, 138 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 67dac90..5ce85f8 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -50,6 +50,8 @@ static inline bool acpi_has_cpu_in_madt(void)
 extern int (*acpi_suspend_lowlevel)(void);
 #define acpi_wakeup_address 0
 
+#define MAX_GIC_CPU_INTERFACE 65535
+
 #endif /* CONFIG_ACPI */
 
 #endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 374926f..801e268 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -22,6 +22,9 @@
 #include <linux/bootmem.h>
 #include <linux/smp.h>
 
+#include <asm/smp_plat.h>
+#include <asm/cputype.h>
+
 /*
  * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
  * variable is still required by the ACPI core
@@ -42,6 +45,9 @@ int acpi_psci_present;
 /* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
 int acpi_psci_use_hvc;
 
+/* Processors (GICC) with enabled flag in MADT */
+static int enabled_cpus;
+
 /*
  * __acpi_map_table() will be called before page_init(), so early_ioremap()
  * or early_memremap() should be called here to for ACPI table mapping.
@@ -62,6 +68,122 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
 	early_iounmap(map, size);
 }
 
+/**
+ * acpi_register_gic_cpu_interface - register a gic cpu interface and
+ * generates a logic cpu number
+ * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
+ * @enabled: this cpu is enabled or not
+ *
+ * Returns the logic cpu number which maps to the gic cpu interface
+ */
+static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)
+{
+	int cpu;
+
+	if (mpidr == INVALID_HWID) {
+		pr_info("Skip invalid cpu hardware ID\n");
+		return -EINVAL;
+	}
+
+	total_cpus++;
+	if (!enabled)
+		return -EINVAL;
+
+	if (enabled_cpus >=  NR_CPUS) {
+		pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
+			NR_CPUS, total_cpus, mpidr);
+		return -EINVAL;
+	}
+
+	/* If it is the first CPU, no need to check duplicate MPIDRs */
+	if (!enabled_cpus)
+		goto skip_mpidr_check;
+
+	/*
+	 * Duplicate MPIDRs are a recipe for disaster. Scan
+	 * all initialized entries and check for
+	 * duplicates. If any is found just ignore the CPU.
+	 */
+	for_each_present_cpu(cpu) {
+		if (cpu_logical_map(cpu) == mpidr) {
+			pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
+			       mpidr);
+			return -EINVAL;
+		}
+	}
+
+skip_mpidr_check:
+	enabled_cpus++;
+
+	/* allocate a logic cpu id for the new comer */
+	if (cpu_logical_map(0) == mpidr) {
+		/*
+		 * boot_cpu_init() already hold bit 0 in cpu_present_mask
+		 * for BSP, no need to allocte again.
+		 */
+		cpu = 0;
+	} else {
+		cpu = cpumask_next_zero(-1, cpu_present_mask);
+	}
+
+	/* map the logic cpu id to cpu MPIDR */
+	cpu_logical_map(cpu) = mpidr;
+
+	set_cpu_possible(cpu, true);
+	set_cpu_present(cpu, true);
+
+	return cpu;
+}
+
+static int __init
+acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
+				const unsigned long end)
+{
+	struct acpi_madt_generic_interrupt *processor;
+
+	processor = (struct acpi_madt_generic_interrupt *)header;
+
+	if (BAD_MADT_ENTRY(processor, end))
+		return -EINVAL;
+
+	acpi_table_print_madt_entry(header);
+
+	acpi_register_gic_cpu_interface(processor->mpidr,
+		processor->flags & ACPI_MADT_ENABLED);
+
+	return 0;
+}
+
+/*
+ * Parse GIC cpu interface related entries in MADT
+ * returns 0 on success, < 0 on error
+ */
+static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
+{
+	int count;
+
+	/*
+	 * do a partial walk of MADT to determine how many CPUs
+	 * we have including disabled CPUs, and get information
+	 * we need for SMP init
+	 */
+	count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+			acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
+
+	if (!count) {
+		pr_err("No GIC CPU interface entries present\n");
+		return -ENODEV;
+	} else if (count < 0) {
+		pr_err("Error parsing GIC CPU interface entry\n");
+		return count;
+	}
+
+	/* Make boot-up look pretty */
+	pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
+
+	return 0;
+}
+
 static int __init acpi_parse_fadt(struct acpi_table_header *table)
 {
 	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
@@ -122,6 +244,11 @@ int __init acpi_boot_init(void)
 	if (err)
 		pr_err("Can't find FADT\n");
 
+	/* Get the boot CPU's MPIDR before MADT parsing */
+	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
+
+	err = acpi_parse_madt_gic_cpu_interface_entries();
+
 	return err;
 }
 
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 40f38f4..8f1d37c 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -36,6 +36,7 @@
 #include <linux/completion.h>
 #include <linux/of.h>
 #include <linux/irq_work.h>
+#include <linux/acpi.h>
 
 #include <asm/atomic.h>
 #include <asm/cacheflush.h>
@@ -458,7 +459,14 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
 		if (err)
 			continue;
 
-		set_cpu_present(cpu, true);
+		/*
+		 * In ACPI mode, cpu_present_map was initialised when
+		 * MADT table was parsed which before this function
+		 * is called.
+		 */
+		if (acpi_disabled)
+			set_cpu_present(cpu, true);
+
 		max_cpus--;
 	}
 }
-- 
1.7.9.5

[PATCH 08/19] ACPI / table: Print GIC information when MADT is parsed

[Hanjun Guo]

When MADT is parsed, print GIC information to make the boot
log look pretty.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
---
 drivers/acpi/tables.c |   39 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 6d5a6cd..8bb8159 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -183,6 +183,44 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header)
 		}
 		break;
 
+	case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
+		{
+			struct acpi_madt_generic_interrupt *p =
+				(struct acpi_madt_generic_interrupt *)header;
+			pr_info("GICC (acpi_id[0x%04x] cpu_address[0x%08llx] MPDIR[0x%llx] %s)\n",
+				p->uid, p->base_address, p->mpidr,
+				(p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled");
+
+		}
+		break;
+
+	case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
+		{
+			struct acpi_madt_generic_distributor *p =
+				(struct acpi_madt_generic_distributor *)header;
+			pr_info("GIC Distributor (id[0x%04x] address[0x%08llx] gsi_base[%d])\n",
+				p->gic_id, p->base_address, p->global_irq_base);
+		}
+		break;
+
+	case ACPI_MADT_TYPE_GIC_MSI_FRAME:
+		{
+			struct acpi_madt_gic_msi_frame *p =
+				(struct acpi_madt_gic_msi_frame *)header;
+			pr_info("GIC MSI Frame (address[0x%08llx] msi_fame_id[%d])\n",
+				p->base_address, p->gic_msi_frame_id);
+		}
+		break;
+
+	case ACPI_MADT_TYPE_GIC_REDISTRIBUTOR:
+		{
+			struct acpi_madt_gic_redistributor *p =
+				(struct acpi_madt_gic_redistributor *)header;
+			pr_info("GIC Redistributor (address[0x%08llx] region_size[0x%x])\n",
+				p->base_address, p->region_size);
+		}
+		break;
+
 	default:
 		pr_warn("Found unsupported MADT entry (type = 0x%x)\n",
 			header->type);
@@ -190,7 +228,6 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header)
 	}
 }
 
-
 int __init
 acpi_table_parse_entries(char *id,
 			     unsigned long table_size,
-- 
1.7.9.5

[PATCH 08/19] ACPI / table: Print GIC information when MADT is parsed

[Hanjun Guo]

When MADT is parsed, print GIC information to make the boot
log look pretty.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
---
 drivers/acpi/tables.c |   39 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 6d5a6cd..8bb8159 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -183,6 +183,44 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header)
 		}
 		break;
 
+	case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
+		{
+			struct acpi_madt_generic_interrupt *p =
+				(struct acpi_madt_generic_interrupt *)header;
+			pr_info("GICC (acpi_id[0x%04x] cpu_address[0x%08llx] MPDIR[0x%llx] %s)\n",
+				p->uid, p->base_address, p->mpidr,
+				(p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled");
+
+		}
+		break;
+
+	case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
+		{
+			struct acpi_madt_generic_distributor *p =
+				(struct acpi_madt_generic_distributor *)header;
+			pr_info("GIC Distributor (id[0x%04x] address[0x%08llx] gsi_base[%d])\n",
+				p->gic_id, p->base_address, p->global_irq_base);
+		}
+		break;
+
+	case ACPI_MADT_TYPE_GIC_MSI_FRAME:
+		{
+			struct acpi_madt_gic_msi_frame *p =
+				(struct acpi_madt_gic_msi_frame *)header;
+			pr_info("GIC MSI Frame (address[0x%08llx] msi_fame_id[%d])\n",
+				p->base_address, p->gic_msi_frame_id);
+		}
+		break;
+
+	case ACPI_MADT_TYPE_GIC_REDISTRIBUTOR:
+		{
+			struct acpi_madt_gic_redistributor *p =
+				(struct acpi_madt_gic_redistributor *)header;
+			pr_info("GIC Redistributor (address[0x%08llx] region_size[0x%x])\n",
+				p->base_address, p->region_size);
+		}
+		break;
+
 	default:
 		pr_warn("Found unsupported MADT entry (type = 0x%x)\n",
 			header->type);
@@ -190,7 +228,6 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header)
 	}
 }
 
-
 int __init
 acpi_table_parse_entries(char *id,
 			     unsigned long table_size,
-- 
1.7.9.5

[PATCH 09/19] ARM64 / ACPI: Move the initialization of cpu_logical_map(0) before acpi_boot_init()

[Hanjun Guo]

Move the initialization of cpu_logical_map(0) before acpi_boot_init()
to remove the duplicated initialization of cpu_logical_map(0).

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/kernel/acpi.c  |    3 ---
 arch/arm64/kernel/setup.c |    3 ++-
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 801e268..ff0f6a0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -244,9 +244,6 @@ int __init acpi_boot_init(void)
 	if (err)
 		pr_err("Can't find FADT\n");
 
-	/* Get the boot CPU's MPIDR before MADT parsing */
-	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
-
 	err = acpi_parse_madt_gic_cpu_interface_entries();
 
 	return err;
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index e00d40c..17ab98e 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -394,13 +394,14 @@ void __init setup_arch(char **cmdline_p)
 
 	efi_idmap_init();
 
+	/* Get the boot CPU's MPIDR before cpu logical map is built */
+	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
 	acpi_boot_init();
 
 	unflatten_device_tree();
 
 	psci_init();
 
-	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
 	cpu_read_bootcpu_ops();
 #ifdef CONFIG_SMP
 	smp_init_cpus();
-- 
1.7.9.5

[PATCH 09/19] ARM64 / ACPI: Move the initialization of cpu_logical_map(0) before acpi_boot_init()

[Hanjun Guo]

Move the initialization of cpu_logical_map(0) before acpi_boot_init()
to remove the duplicated initialization of cpu_logical_map(0).

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/kernel/acpi.c  |    3 ---
 arch/arm64/kernel/setup.c |    3 ++-
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 801e268..ff0f6a0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -244,9 +244,6 @@ int __init acpi_boot_init(void)
 	if (err)
 		pr_err("Can't find FADT\n");
 
-	/* Get the boot CPU's MPIDR before MADT parsing */
-	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
-
 	err = acpi_parse_madt_gic_cpu_interface_entries();
 
 	return err;
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index e00d40c..17ab98e 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -394,13 +394,14 @@ void __init setup_arch(char **cmdline_p)
 
 	efi_idmap_init();
 
+	/* Get the boot CPU's MPIDR before cpu logical map is built */
+	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
 	acpi_boot_init();
 
 	unflatten_device_tree();
 
 	psci_init();
 
-	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
 	cpu_read_bootcpu_ops();
 #ifdef CONFIG_SMP
 	smp_init_cpus();
-- 
1.7.9.5

[PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

ACPI 5.1 only has two explicit methods to boot up SMP,
PSCI and Parking protocol, but the Parking protocol is
only suitable for ARMv7 now, so make PSCI as the only way
for the SMP boot protocol before some updates for the
ACPI spec or the Parking protocol spec.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
---
 arch/arm64/include/asm/acpi.h    |   21 +++++++++++++++
 arch/arm64/include/asm/cpu_ops.h |    9 ++++++-
 arch/arm64/include/asm/smp.h     |    2 +-
 arch/arm64/kernel/acpi.c         |    9 +++++++
 arch/arm64/kernel/cpu_ops.c      |   52 ++++++++++++++++++++++++++++++++++----
 arch/arm64/kernel/smp.c          |   29 +++++++++++++++++++--
 6 files changed, 113 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 5ce85f8..6240327 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -14,6 +14,27 @@
 
 /* Basic configuration for ACPI */
 #ifdef	CONFIG_ACPI
+/*
+ * ACPI 5.1 only has two explicit methods to
+ * boot up SMP, PSCI and Parking protocol,
+ * but the Parking protocol is only defined
+ * for ARMv7 now, so make PSCI as the only
+ * way for the SMP boot protocol before some
+ * updates for the ACPI spec or the Parking
+ * protocol spec.
+ *
+ * This enum is intend to make the boot method
+ * scalable when above updates are happended,
+ * which NOT means to support all of them.
+ */
+enum acpi_smp_boot_protocol {
+	ACPI_SMP_BOOT_PSCI,
+	ACPI_SMP_BOOT_PARKING_PROTOCOL,
+	ACPI_SMP_BOOT_PROTOCOL_MAX
+};
+
+enum acpi_smp_boot_protocol smp_boot_protocol(void);
+
 extern int acpi_disabled;
 extern int acpi_noirq;
 extern int acpi_pci_disabled;
diff --git a/arch/arm64/include/asm/cpu_ops.h b/arch/arm64/include/asm/cpu_ops.h
index d7b4b38..2a7c6fd 100644
--- a/arch/arm64/include/asm/cpu_ops.h
+++ b/arch/arm64/include/asm/cpu_ops.h
@@ -61,7 +61,14 @@ struct cpu_operations {
 };
 
 extern const struct cpu_operations *cpu_ops[NR_CPUS];
-extern int __init cpu_read_ops(struct device_node *dn, int cpu);
+extern int __init cpu_of_read_ops(struct device_node *dn, int cpu);
+
+#ifdef CONFIG_ACPI
+extern int __init cpu_acpi_read_ops(int cpu);
+#else
+static inline int __init cpu_acpi_read_ops(int cpu) { return -ENODEV; }
+#endif
+
 extern void __init cpu_read_bootcpu_ops(void);
 
 #endif /* ifndef __ASM_CPU_OPS_H */
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index a498f2c..a5cea56 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -39,7 +39,7 @@ extern void show_ipi_list(struct seq_file *p, int prec);
 extern void handle_IPI(int ipinr, struct pt_regs *regs);
 
 /*
- * Setup the set of possible CPUs (via set_cpu_possible)
+ * Platform specific SMP operations
  */
 extern void smp_init_cpus(void);
 
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index ff0f6a0..2af6662 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
 	return 0;
 }
 
+/* Protocol to bring up secondary CPUs */
+enum acpi_smp_boot_protocol smp_boot_protocol(void)
+{
+	if (acpi_psci_present)
+		return ACPI_SMP_BOOT_PSCI;
+	else
+		return ACPI_SMP_BOOT_PARKING_PROTOCOL;
+}
+
 static int __init acpi_parse_fadt(struct acpi_table_header *table)
 {
 	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
index d62d12f..4d9b3cf 100644
--- a/arch/arm64/kernel/cpu_ops.c
+++ b/arch/arm64/kernel/cpu_ops.c
@@ -16,11 +16,13 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
-#include <asm/cpu_ops.h>
-#include <asm/smp_plat.h>
 #include <linux/errno.h>
 #include <linux/of.h>
 #include <linux/string.h>
+#include <linux/acpi.h>
+
+#include <asm/cpu_ops.h>
+#include <asm/smp_plat.h>
 
 extern const struct cpu_operations smp_spin_table_ops;
 extern const struct cpu_operations cpu_psci_ops;
@@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
 /*
  * Read a cpu's enable method from the device tree and record it in cpu_ops.
  */
-int __init cpu_read_ops(struct device_node *dn, int cpu)
+int __init cpu_of_read_ops(struct device_node *dn, int cpu)
 {
 	const char *enable_method = of_get_property(dn, "enable-method", NULL);
 	if (!enable_method) {
@@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
 	return 0;
 }
 
+#ifdef CONFIG_ACPI
+/*
+ * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
+ */
+int __init cpu_acpi_read_ops(int cpu)
+{
+	/*
+	 * For ACPI 5.1, only two kind of methods are provided,
+	 * Parking protocol and PSCI, but Parking protocol is
+	 * used on ARMv7 only, so make PSCI as the only method
+	 * for SMP initialization before the ACPI spec or Parking
+	 * protocol spec is updated.
+	 */
+	switch (smp_boot_protocol()) {
+	case ACPI_SMP_BOOT_PSCI:
+		cpu_ops[cpu] = cpu_get_ops("psci");
+		break;
+	case ACPI_SMP_BOOT_PARKING_PROTOCOL:
+	default:
+		cpu_ops[cpu] = NULL;
+		break;
+	}
+
+	if (!cpu_ops[cpu]) {
+		pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
+			cpu);
+		return -EOPNOTSUPP;
+	}
+
+	return 0;
+}
+#endif
+
 void __init cpu_read_bootcpu_ops(void)
 {
-	struct device_node *dn = of_get_cpu_node(0, NULL);
+	struct device_node *dn;
+
+	if (!acpi_disabled) {
+		cpu_acpi_read_ops(0);
+		return;
+	}
+
+	dn = of_get_cpu_node(0, NULL);
 	if (!dn) {
 		pr_err("Failed to find device node for boot cpu\n");
 		return;
 	}
-	cpu_read_ops(dn, 0);
+	cpu_of_read_ops(dn, 0);
 }
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 8f1d37c..cb71662 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -315,7 +315,7 @@ static void (*smp_cross_call)(const struct cpumask *, unsigned int);
  * cpu logical map array containing MPIDR values related to logical
  * cpus. Assumes that cpu_logical_map(0) has already been initialized.
  */
-void __init smp_init_cpus(void)
+static void __init of_smp_init_cpus(void)
 {
 	struct device_node *dn = NULL;
 	unsigned int i, cpu = 1;
@@ -387,7 +387,7 @@ void __init smp_init_cpus(void)
 		if (cpu >= NR_CPUS)
 			goto next;
 
-		if (cpu_read_ops(dn, cpu) != 0)
+		if (cpu_of_read_ops(dn, cpu) != 0)
 			goto next;
 
 		if (cpu_ops[cpu]->cpu_init(dn, cpu))
@@ -418,6 +418,31 @@ next:
 			set_cpu_possible(i, true);
 }
 
+/*
+ * In ACPI mode, the cpu possible map was enumerated before SMP
+ * initialization when MADT table was parsed, so we can get the
+ * possible map here to initialize CPUs.
+ */
+static void __init acpi_smp_init_cpus(void)
+{
+	int cpu;
+
+	for_each_possible_cpu(cpu) {
+		if (cpu_acpi_read_ops(cpu) != 0)
+			continue;
+
+		cpu_ops[cpu]->cpu_init(NULL, cpu);
+	}
+}
+
+void __init smp_init_cpus(void)
+{
+	if (acpi_disabled)
+		of_smp_init_cpus();
+	else
+		acpi_smp_init_cpus();
+}
+
 void __init smp_prepare_cpus(unsigned int max_cpus)
 {
 	int err;
-- 
1.7.9.5

[PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

ACPI 5.1 only has two explicit methods to boot up SMP,
PSCI and Parking protocol, but the Parking protocol is
only suitable for ARMv7 now, so make PSCI as the only way
for the SMP boot protocol before some updates for the
ACPI spec or the Parking protocol spec.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
---
 arch/arm64/include/asm/acpi.h    |   21 +++++++++++++++
 arch/arm64/include/asm/cpu_ops.h |    9 ++++++-
 arch/arm64/include/asm/smp.h     |    2 +-
 arch/arm64/kernel/acpi.c         |    9 +++++++
 arch/arm64/kernel/cpu_ops.c      |   52 ++++++++++++++++++++++++++++++++++----
 arch/arm64/kernel/smp.c          |   29 +++++++++++++++++++--
 6 files changed, 113 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 5ce85f8..6240327 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -14,6 +14,27 @@
 
 /* Basic configuration for ACPI */
 #ifdef	CONFIG_ACPI
+/*
+ * ACPI 5.1 only has two explicit methods to
+ * boot up SMP, PSCI and Parking protocol,
+ * but the Parking protocol is only defined
+ * for ARMv7 now, so make PSCI as the only
+ * way for the SMP boot protocol before some
+ * updates for the ACPI spec or the Parking
+ * protocol spec.
+ *
+ * This enum is intend to make the boot method
+ * scalable when above updates are happended,
+ * which NOT means to support all of them.
+ */
+enum acpi_smp_boot_protocol {
+	ACPI_SMP_BOOT_PSCI,
+	ACPI_SMP_BOOT_PARKING_PROTOCOL,
+	ACPI_SMP_BOOT_PROTOCOL_MAX
+};
+
+enum acpi_smp_boot_protocol smp_boot_protocol(void);
+
 extern int acpi_disabled;
 extern int acpi_noirq;
 extern int acpi_pci_disabled;
diff --git a/arch/arm64/include/asm/cpu_ops.h b/arch/arm64/include/asm/cpu_ops.h
index d7b4b38..2a7c6fd 100644
--- a/arch/arm64/include/asm/cpu_ops.h
+++ b/arch/arm64/include/asm/cpu_ops.h
@@ -61,7 +61,14 @@ struct cpu_operations {
 };
 
 extern const struct cpu_operations *cpu_ops[NR_CPUS];
-extern int __init cpu_read_ops(struct device_node *dn, int cpu);
+extern int __init cpu_of_read_ops(struct device_node *dn, int cpu);
+
+#ifdef CONFIG_ACPI
+extern int __init cpu_acpi_read_ops(int cpu);
+#else
+static inline int __init cpu_acpi_read_ops(int cpu) { return -ENODEV; }
+#endif
+
 extern void __init cpu_read_bootcpu_ops(void);
 
 #endif /* ifndef __ASM_CPU_OPS_H */
diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
index a498f2c..a5cea56 100644
--- a/arch/arm64/include/asm/smp.h
+++ b/arch/arm64/include/asm/smp.h
@@ -39,7 +39,7 @@ extern void show_ipi_list(struct seq_file *p, int prec);
 extern void handle_IPI(int ipinr, struct pt_regs *regs);
 
 /*
- * Setup the set of possible CPUs (via set_cpu_possible)
+ * Platform specific SMP operations
  */
 extern void smp_init_cpus(void);
 
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index ff0f6a0..2af6662 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
 	return 0;
 }
 
+/* Protocol to bring up secondary CPUs */
+enum acpi_smp_boot_protocol smp_boot_protocol(void)
+{
+	if (acpi_psci_present)
+		return ACPI_SMP_BOOT_PSCI;
+	else
+		return ACPI_SMP_BOOT_PARKING_PROTOCOL;
+}
+
 static int __init acpi_parse_fadt(struct acpi_table_header *table)
 {
 	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
index d62d12f..4d9b3cf 100644
--- a/arch/arm64/kernel/cpu_ops.c
+++ b/arch/arm64/kernel/cpu_ops.c
@@ -16,11 +16,13 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
-#include <asm/cpu_ops.h>
-#include <asm/smp_plat.h>
 #include <linux/errno.h>
 #include <linux/of.h>
 #include <linux/string.h>
+#include <linux/acpi.h>
+
+#include <asm/cpu_ops.h>
+#include <asm/smp_plat.h>
 
 extern const struct cpu_operations smp_spin_table_ops;
 extern const struct cpu_operations cpu_psci_ops;
@@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
 /*
  * Read a cpu's enable method from the device tree and record it in cpu_ops.
  */
-int __init cpu_read_ops(struct device_node *dn, int cpu)
+int __init cpu_of_read_ops(struct device_node *dn, int cpu)
 {
 	const char *enable_method = of_get_property(dn, "enable-method", NULL);
 	if (!enable_method) {
@@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
 	return 0;
 }
 
+#ifdef CONFIG_ACPI
+/*
+ * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
+ */
+int __init cpu_acpi_read_ops(int cpu)
+{
+	/*
+	 * For ACPI 5.1, only two kind of methods are provided,
+	 * Parking protocol and PSCI, but Parking protocol is
+	 * used on ARMv7 only, so make PSCI as the only method
+	 * for SMP initialization before the ACPI spec or Parking
+	 * protocol spec is updated.
+	 */
+	switch (smp_boot_protocol()) {
+	case ACPI_SMP_BOOT_PSCI:
+		cpu_ops[cpu] = cpu_get_ops("psci");
+		break;
+	case ACPI_SMP_BOOT_PARKING_PROTOCOL:
+	default:
+		cpu_ops[cpu] = NULL;
+		break;
+	}
+
+	if (!cpu_ops[cpu]) {
+		pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
+			cpu);
+		return -EOPNOTSUPP;
+	}
+
+	return 0;
+}
+#endif
+
 void __init cpu_read_bootcpu_ops(void)
 {
-	struct device_node *dn = of_get_cpu_node(0, NULL);
+	struct device_node *dn;
+
+	if (!acpi_disabled) {
+		cpu_acpi_read_ops(0);
+		return;
+	}
+
+	dn = of_get_cpu_node(0, NULL);
 	if (!dn) {
 		pr_err("Failed to find device node for boot cpu\n");
 		return;
 	}
-	cpu_read_ops(dn, 0);
+	cpu_of_read_ops(dn, 0);
 }
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 8f1d37c..cb71662 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -315,7 +315,7 @@ static void (*smp_cross_call)(const struct cpumask *, unsigned int);
  * cpu logical map array containing MPIDR values related to logical
  * cpus. Assumes that cpu_logical_map(0) has already been initialized.
  */
-void __init smp_init_cpus(void)
+static void __init of_smp_init_cpus(void)
 {
 	struct device_node *dn = NULL;
 	unsigned int i, cpu = 1;
@@ -387,7 +387,7 @@ void __init smp_init_cpus(void)
 		if (cpu >= NR_CPUS)
 			goto next;
 
-		if (cpu_read_ops(dn, cpu) != 0)
+		if (cpu_of_read_ops(dn, cpu) != 0)
 			goto next;
 
 		if (cpu_ops[cpu]->cpu_init(dn, cpu))
@@ -418,6 +418,31 @@ next:
 			set_cpu_possible(i, true);
 }
 
+/*
+ * In ACPI mode, the cpu possible map was enumerated before SMP
+ * initialization when MADT table was parsed, so we can get the
+ * possible map here to initialize CPUs.
+ */
+static void __init acpi_smp_init_cpus(void)
+{
+	int cpu;
+
+	for_each_possible_cpu(cpu) {
+		if (cpu_acpi_read_ops(cpu) != 0)
+			continue;
+
+		cpu_ops[cpu]->cpu_init(NULL, cpu);
+	}
+}
+
+void __init smp_init_cpus(void)
+{
+	if (acpi_disabled)
+		of_smp_init_cpus();
+	else
+		acpi_smp_init_cpus();
+}
+
 void __init smp_prepare_cpus(unsigned int max_cpus)
 {
 	int err;
-- 
1.7.9.5

[PATCH 11/19] ACPI / processor: Make it possible to get CPU hardware ID via GICC

[Hanjun Guo]

Introduce a new function map_gicc_mpidr() to allow MPIDRs to be obtained
from the GICC Structure introduced by ACPI 5.1.

MPIDR is the CPU hardware ID as local APIC ID on x86 platform, so we use
MPIDR not the GIC CPU interface ID to identify CPUs.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/acpi.h |   14 ++++++++++++++
 arch/arm64/kernel/acpi.c      |   21 ++++++++++++++++++++-
 drivers/acpi/processor_core.c |   36 ++++++++++++++++++++++++++++++++++++
 3 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 6240327..f40e137 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -12,6 +12,8 @@
 #ifndef _ASM_ACPI_H
 #define _ASM_ACPI_H
 
+#include <asm/smp_plat.h>
+
 /* Basic configuration for ACPI */
 #ifdef	CONFIG_ACPI
 /*
@@ -49,6 +51,18 @@ static inline void disable_acpi(void)
 	acpi_noirq = 1;
 }
 
+u32 pack_mpidr_into_32_bits(u64 mpidr);
+
+/*
+ * The ACPI processor driver for ACPI core code needs this macro
+ * to find out this cpu was already mapped (mapping from CPU hardware
+ * ID to CPU logical ID) or not.
+ *
+ * cpu_logical_map(cpu) is the mapping of MPIDR and the logical cpu,
+ * and MPIDR is the cpu hardware ID we needed.
+ */
+#define cpu_physical_id(cpu) pack_mpidr_into_32_bits(cpu_logical_map(cpu))
+
 /*
  * MADT must provide at least one GICC structure
  * for GIC initialization, so CPU will be
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 2af6662..ef06e91 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -22,7 +22,6 @@
 #include <linux/bootmem.h>
 #include <linux/smp.h>
 
-#include <asm/smp_plat.h>
 #include <asm/cputype.h>
 
 /*
@@ -279,6 +278,26 @@ static int __init parse_acpi(char *arg)
 }
 early_param("acpi", parse_acpi);
 
+/* MPIDR value provided in GICC structure is 64 bits, but
+ * the acpi processor driver use the 32 bits cpu hardware
+ * ID (apic_id on intel platform) everywhere, it is pretty
+ * hard to modify the acpi processor driver to accept the
+ * 64 bits MPIDR value, at the same time, only 32 bits of
+ * the MPIDR is used in the 64 bits MPIDR, just pack the
+ * Affx fields into a single 32 bit identifier to accommodate
+ * the acpi processor drivers.
+ */
+u32 pack_mpidr_into_32_bits(u64 mpidr)
+{
+	/*
+	 * Bits [0:7] Aff0;
+	 * Bits [8:15] Aff1;
+	 * Bits [16:23] Aff2;
+	 * Bits [32:39] Aff3;
+	 */
+	return (u32) ((mpidr & 0xff00000000) >> 8) | mpidr;
+}
+
 /*
  * acpi_suspend_lowlevel() - save kernel state and suspend.
  *
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 00f48d1..fa3d0ed 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -64,6 +64,37 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
 	return 0;
 }
 
+/*
+ * On ARM platform, MPIDR value is the hardware ID as apic ID
+ * on Intel platforms
+ */
+static int map_gicc_mpidr(struct acpi_subtable_header *entry,
+		int device_declaration, u32 acpi_id, int *mpidr)
+{
+	struct acpi_madt_generic_interrupt *gicc =
+	    container_of(entry, struct acpi_madt_generic_interrupt, header);
+
+	if (!(gicc->flags & ACPI_MADT_ENABLED))
+		return -ENODEV;
+
+	/* In the GIC interrupt model, logical processors are
+	 * required to have a Processor Device object in the DSDT,
+	 * so we should check device_declaration here
+	 */
+	if (device_declaration && (gicc->uid == acpi_id)) {
+		/*
+		 * Only bits [0:7] Aff0, bits [8:15] Aff1, bits [16:23] Aff2
+		 * and bits [32:39] Aff3 are meaningful, so pack the Affx
+		 * fields into a single 32 bit identifier to accommodate the
+		 * acpi processor drivers.
+		 */
+		*mpidr = ((gicc->mpidr & 0xff00000000) >> 8) | gicc->mpidr;
+		return 0;
+	}
+
+	return -EINVAL;
+}
+
 static int map_madt_entry(int type, u32 acpi_id)
 {
 	unsigned long madt_end, entry;
@@ -99,6 +130,9 @@ static int map_madt_entry(int type, u32 acpi_id)
 		} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
 			if (!map_lsapic_id(header, type, acpi_id, &apic_id))
 				break;
+		} else if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
+			if (!map_gicc_mpidr(header, type, acpi_id, &apic_id))
+				break;
 		}
 		entry += header->length;
 	}
@@ -129,6 +163,8 @@ static int map_mat_entry(acpi_handle handle, int type, u32 acpi_id)
 		map_lapic_id(header, acpi_id, &apic_id);
 	} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
 		map_lsapic_id(header, type, acpi_id, &apic_id);
+	} else if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
+		map_gicc_mpidr(header, type, acpi_id, &apic_id);
 	}
 
 exit:
-- 
1.7.9.5

[PATCH 11/19] ACPI / processor: Make it possible to get CPU hardware ID via GICC

[Hanjun Guo]

Introduce a new function map_gicc_mpidr() to allow MPIDRs to be obtained
from the GICC Structure introduced by ACPI 5.1.

MPIDR is the CPU hardware ID as local APIC ID on x86 platform, so we use
MPIDR not the GIC CPU interface ID to identify CPUs.

Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/acpi.h |   14 ++++++++++++++
 arch/arm64/kernel/acpi.c      |   21 ++++++++++++++++++++-
 drivers/acpi/processor_core.c |   36 ++++++++++++++++++++++++++++++++++++
 3 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 6240327..f40e137 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -12,6 +12,8 @@
 #ifndef _ASM_ACPI_H
 #define _ASM_ACPI_H
 
+#include <asm/smp_plat.h>
+
 /* Basic configuration for ACPI */
 #ifdef	CONFIG_ACPI
 /*
@@ -49,6 +51,18 @@ static inline void disable_acpi(void)
 	acpi_noirq = 1;
 }
 
+u32 pack_mpidr_into_32_bits(u64 mpidr);
+
+/*
+ * The ACPI processor driver for ACPI core code needs this macro
+ * to find out this cpu was already mapped (mapping from CPU hardware
+ * ID to CPU logical ID) or not.
+ *
+ * cpu_logical_map(cpu) is the mapping of MPIDR and the logical cpu,
+ * and MPIDR is the cpu hardware ID we needed.
+ */
+#define cpu_physical_id(cpu) pack_mpidr_into_32_bits(cpu_logical_map(cpu))
+
 /*
  * MADT must provide at least one GICC structure
  * for GIC initialization, so CPU will be
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 2af6662..ef06e91 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -22,7 +22,6 @@
 #include <linux/bootmem.h>
 #include <linux/smp.h>
 
-#include <asm/smp_plat.h>
 #include <asm/cputype.h>
 
 /*
@@ -279,6 +278,26 @@ static int __init parse_acpi(char *arg)
 }
 early_param("acpi", parse_acpi);
 
+/* MPIDR value provided in GICC structure is 64 bits, but
+ * the acpi processor driver use the 32 bits cpu hardware
+ * ID (apic_id on intel platform) everywhere, it is pretty
+ * hard to modify the acpi processor driver to accept the
+ * 64 bits MPIDR value, at the same time, only 32 bits of
+ * the MPIDR is used in the 64 bits MPIDR, just pack the
+ * Affx fields into a single 32 bit identifier to accommodate
+ * the acpi processor drivers.
+ */
+u32 pack_mpidr_into_32_bits(u64 mpidr)
+{
+	/*
+	 * Bits [0:7] Aff0;
+	 * Bits [8:15] Aff1;
+	 * Bits [16:23] Aff2;
+	 * Bits [32:39] Aff3;
+	 */
+	return (u32) ((mpidr & 0xff00000000) >> 8) | mpidr;
+}
+
 /*
  * acpi_suspend_lowlevel() - save kernel state and suspend.
  *
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index 00f48d1..fa3d0ed 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -64,6 +64,37 @@ static int map_lsapic_id(struct acpi_subtable_header *entry,
 	return 0;
 }
 
+/*
+ * On ARM platform, MPIDR value is the hardware ID as apic ID
+ * on Intel platforms
+ */
+static int map_gicc_mpidr(struct acpi_subtable_header *entry,
+		int device_declaration, u32 acpi_id, int *mpidr)
+{
+	struct acpi_madt_generic_interrupt *gicc =
+	    container_of(entry, struct acpi_madt_generic_interrupt, header);
+
+	if (!(gicc->flags & ACPI_MADT_ENABLED))
+		return -ENODEV;
+
+	/* In the GIC interrupt model, logical processors are
+	 * required to have a Processor Device object in the DSDT,
+	 * so we should check device_declaration here
+	 */
+	if (device_declaration && (gicc->uid == acpi_id)) {
+		/*
+		 * Only bits [0:7] Aff0, bits [8:15] Aff1, bits [16:23] Aff2
+		 * and bits [32:39] Aff3 are meaningful, so pack the Affx
+		 * fields into a single 32 bit identifier to accommodate the
+		 * acpi processor drivers.
+		 */
+		*mpidr = ((gicc->mpidr & 0xff00000000) >> 8) | gicc->mpidr;
+		return 0;
+	}
+
+	return -EINVAL;
+}
+
 static int map_madt_entry(int type, u32 acpi_id)
 {
 	unsigned long madt_end, entry;
@@ -99,6 +130,9 @@ static int map_madt_entry(int type, u32 acpi_id)
 		} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
 			if (!map_lsapic_id(header, type, acpi_id, &apic_id))
 				break;
+		} else if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
+			if (!map_gicc_mpidr(header, type, acpi_id, &apic_id))
+				break;
 		}
 		entry += header->length;
 	}
@@ -129,6 +163,8 @@ static int map_mat_entry(acpi_handle handle, int type, u32 acpi_id)
 		map_lapic_id(header, acpi_id, &apic_id);
 	} else if (header->type == ACPI_MADT_TYPE_LOCAL_SAPIC) {
 		map_lsapic_id(header, type, acpi_id, &apic_id);
+	} else if (header->type == ACPI_MADT_TYPE_GENERIC_INTERRUPT) {
+		map_gicc_mpidr(header, type, acpi_id, &apic_id);
 	}
 
 exit:
-- 
1.7.9.5

[PATCH 12/19] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi

[Hanjun Guo]

Introduce ACPI_IRQ_MODEL_GIC which is needed for ARM64 as GIC is
used, and then register device's gsi with the core IRQ subsystem.

acpi_register_gsi() is similar to DT based irq_of_parse_and_map(),
since gsi is unique in the system, so use hwirq number directly
for the mapping.

Originally-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/kernel/acpi.c |   73 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/acpi/bus.c       |    3 ++
 include/linux/acpi.h     |    1 +
 3 files changed, 77 insertions(+)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index ef06e91..3a078dc 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -48,6 +48,12 @@ int acpi_psci_use_hvc;
 static int enabled_cpus;
 
 /*
+ * Since we're on ARM, the default interrupt routing model
+ * clearly has to be GIC.
+ */
+enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_GIC;
+
+/*
  * __acpi_map_table() will be called before page_init(), so early_ioremap()
  * or early_memremap() should be called here to for ACPI table mapping.
  */
@@ -183,6 +189,73 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
 	return 0;
 }
 
+int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
+{
+	*irq = irq_find_mapping(NULL, gsi);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
+
+/*
+ * success: return IRQ number (>0)
+ * failure: return =< 0
+ */
+int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
+{
+	unsigned int irq;
+	unsigned int irq_type;
+
+	/*
+	 * ACPI have no bindings to indicate SPI or PPI, so we
+	 * use different mappings from DT in ACPI.
+	 *
+	 * For FDT
+	 * PPI interrupt: in the range [0, 15];
+	 * SPI interrupt: in the range [0, 987];
+	 *
+	 * For ACPI, GSI should be unique so using
+	 * the hwirq directly for the mapping:
+	 * PPI interrupt: in the range [16, 31];
+	 * SPI interrupt: in the range [32, 1019];
+	 */
+
+	if (trigger == ACPI_EDGE_SENSITIVE &&
+				polarity == ACPI_ACTIVE_LOW)
+		irq_type = IRQ_TYPE_EDGE_FALLING;
+	else if (trigger == ACPI_EDGE_SENSITIVE &&
+				polarity == ACPI_ACTIVE_HIGH)
+		irq_type = IRQ_TYPE_EDGE_RISING;
+	else if (trigger == ACPI_LEVEL_SENSITIVE &&
+				polarity == ACPI_ACTIVE_LOW)
+		irq_type = IRQ_TYPE_LEVEL_LOW;
+	else if (trigger == ACPI_LEVEL_SENSITIVE &&
+				polarity == ACPI_ACTIVE_HIGH)
+		irq_type = IRQ_TYPE_LEVEL_HIGH;
+	else
+		irq_type = IRQ_TYPE_NONE;
+
+	/*
+	 * Since only one GIC is supported in ACPI 5.0, we can
+	 * create mapping refer to the default domain
+	 */
+	irq = irq_create_mapping(NULL, gsi);
+	if (!irq)
+		return irq;
+
+	/* Set irq type if specified and different than the current one */
+	if (irq_type != IRQ_TYPE_NONE &&
+		irq_type != irq_get_trigger_type(irq))
+		irq_set_irq_type(irq, irq_type);
+	return irq;
+}
+EXPORT_SYMBOL_GPL(acpi_register_gsi);
+
+void acpi_unregister_gsi(u32 gsi)
+{
+}
+EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
+
 /* Protocol to bring up secondary CPUs */
 enum acpi_smp_boot_protocol smp_boot_protocol(void)
 {
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index c5bc8cf..301529c 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -458,6 +458,9 @@ static int __init acpi_bus_init_irq(void)
 	case ACPI_IRQ_MODEL_IOSAPIC:
 		message = "IOSAPIC";
 		break;
+	case ACPI_IRQ_MODEL_GIC:
+		message = "GIC";
+		break;
 	case ACPI_IRQ_MODEL_PLATFORM:
 		message = "platform specific model";
 		break;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 358c01b..ad6c30f 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -71,6 +71,7 @@ enum acpi_irq_model_id {
 	ACPI_IRQ_MODEL_IOAPIC,
 	ACPI_IRQ_MODEL_IOSAPIC,
 	ACPI_IRQ_MODEL_PLATFORM,
+	ACPI_IRQ_MODEL_GIC,
 	ACPI_IRQ_MODEL_COUNT
 };
 
-- 
1.7.9.5

[PATCH 12/19] ARM64 / ACPI: Introduce ACPI_IRQ_MODEL_GIC and register device's gsi

[Hanjun Guo]

Introduce ACPI_IRQ_MODEL_GIC which is needed for ARM64 as GIC is
used, and then register device's gsi with the core IRQ subsystem.

acpi_register_gsi() is similar to DT based irq_of_parse_and_map(),
since gsi is unique in the system, so use hwirq number directly
for the mapping.

Originally-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/kernel/acpi.c |   73 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/acpi/bus.c       |    3 ++
 include/linux/acpi.h     |    1 +
 3 files changed, 77 insertions(+)

diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index ef06e91..3a078dc 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -48,6 +48,12 @@ int acpi_psci_use_hvc;
 static int enabled_cpus;
 
 /*
+ * Since we're on ARM, the default interrupt routing model
+ * clearly has to be GIC.
+ */
+enum acpi_irq_model_id acpi_irq_model = ACPI_IRQ_MODEL_GIC;
+
+/*
  * __acpi_map_table() will be called before page_init(), so early_ioremap()
  * or early_memremap() should be called here to for ACPI table mapping.
  */
@@ -183,6 +189,73 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
 	return 0;
 }
 
+int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
+{
+	*irq = irq_find_mapping(NULL, gsi);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
+
+/*
+ * success: return IRQ number (>0)
+ * failure: return =< 0
+ */
+int acpi_register_gsi(struct device *dev, u32 gsi, int trigger, int polarity)
+{
+	unsigned int irq;
+	unsigned int irq_type;
+
+	/*
+	 * ACPI have no bindings to indicate SPI or PPI, so we
+	 * use different mappings from DT in ACPI.
+	 *
+	 * For FDT
+	 * PPI interrupt: in the range [0, 15];
+	 * SPI interrupt: in the range [0, 987];
+	 *
+	 * For ACPI, GSI should be unique so using
+	 * the hwirq directly for the mapping:
+	 * PPI interrupt: in the range [16, 31];
+	 * SPI interrupt: in the range [32, 1019];
+	 */
+
+	if (trigger == ACPI_EDGE_SENSITIVE &&
+				polarity == ACPI_ACTIVE_LOW)
+		irq_type = IRQ_TYPE_EDGE_FALLING;
+	else if (trigger == ACPI_EDGE_SENSITIVE &&
+				polarity == ACPI_ACTIVE_HIGH)
+		irq_type = IRQ_TYPE_EDGE_RISING;
+	else if (trigger == ACPI_LEVEL_SENSITIVE &&
+				polarity == ACPI_ACTIVE_LOW)
+		irq_type = IRQ_TYPE_LEVEL_LOW;
+	else if (trigger == ACPI_LEVEL_SENSITIVE &&
+				polarity == ACPI_ACTIVE_HIGH)
+		irq_type = IRQ_TYPE_LEVEL_HIGH;
+	else
+		irq_type = IRQ_TYPE_NONE;
+
+	/*
+	 * Since only one GIC is supported in ACPI 5.0, we can
+	 * create mapping refer to the default domain
+	 */
+	irq = irq_create_mapping(NULL, gsi);
+	if (!irq)
+		return irq;
+
+	/* Set irq type if specified and different than the current one */
+	if (irq_type != IRQ_TYPE_NONE &&
+		irq_type != irq_get_trigger_type(irq))
+		irq_set_irq_type(irq, irq_type);
+	return irq;
+}
+EXPORT_SYMBOL_GPL(acpi_register_gsi);
+
+void acpi_unregister_gsi(u32 gsi)
+{
+}
+EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
+
 /* Protocol to bring up secondary CPUs */
 enum acpi_smp_boot_protocol smp_boot_protocol(void)
 {
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index c5bc8cf..301529c 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -458,6 +458,9 @@ static int __init acpi_bus_init_irq(void)
 	case ACPI_IRQ_MODEL_IOSAPIC:
 		message = "IOSAPIC";
 		break;
+	case ACPI_IRQ_MODEL_GIC:
+		message = "GIC";
+		break;
 	case ACPI_IRQ_MODEL_PLATFORM:
 		message = "platform specific model";
 		break;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 358c01b..ad6c30f 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -71,6 +71,7 @@ enum acpi_irq_model_id {
 	ACPI_IRQ_MODEL_IOAPIC,
 	ACPI_IRQ_MODEL_IOSAPIC,
 	ACPI_IRQ_MODEL_PLATFORM,
+	ACPI_IRQ_MODEL_GIC,
 	ACPI_IRQ_MODEL_COUNT
 };
 
-- 
1.7.9.5

[PATCH 13/19] ACPI / table: Add new function to get table entries

[Hanjun Guo]

From: Ashwin Chaugule <ashwin.chaugule@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().

Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 drivers/acpi/tables.c |   70 +++++++++++++++++++++++++++++++++++--------------
 include/linux/acpi.h  |    4 +++
 2 files changed, 54 insertions(+), 20 deletions(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 8bb8159..e6455c9 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -229,17 +229,14 @@ 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(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;
@@ -247,13 +244,11 @@ acpi_table_parse_entries(char *id,
 	if (!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);
+		pr_warn("Table header not present\n");
 		return -ENODEV;
 	}
 
@@ -268,31 +263,66 @@ acpi_table_parse_entries(char *id,
 	       table_end) {
 		if (entry->type == entry_id
 		    && (!max_entries || count++ < max_entries))
-			if (handler(entry, table_end))
+			if (handler(entry, table_end)) {
+				count = -EINVAL;
 				goto err;
+		}
 
 		/*
 		 * If entry->length is 0, break from this loop to avoid
 		 * infinite loop.
 		 */
 		if (entry->length == 0) {
-			pr_err("[%4.4s:0x%02x] Invalid zero length\n", id, entry_id);
+			pr_err("[0x%02x] Invalid zero length\n", entry_id);
+			count = -EINVAL;
 			goto err;
 		}
 
 		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);
+		pr_warn("[0x%02x] ignored %i entries of %i found\n",
+			entry_id, count - max_entries, count);
 	}
 
-	early_acpi_os_unmap_memory((char *)table_header, tbl_size);
-	return count;
 err:
+	return count;
+}
+
+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;
+
+	if (acpi_disabled)
+		return -ENODEV;
+
+	if (!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_header) {
+		pr_warn("%4.4s not present\n", id);
+		return -ENODEV;
+	}
+
+	count = acpi_parse_entries(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 ad6c30f..95540e7 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(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.7.9.5

[PATCH 13/19] ACPI / table: Add new function to get table entries

[Hanjun Guo]

From: Ashwin Chaugule <ashwin.chaugule@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().

Signed-off-by: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 drivers/acpi/tables.c |   70 +++++++++++++++++++++++++++++++++++--------------
 include/linux/acpi.h  |    4 +++
 2 files changed, 54 insertions(+), 20 deletions(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 8bb8159..e6455c9 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -229,17 +229,14 @@ 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(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;
@@ -247,13 +244,11 @@ acpi_table_parse_entries(char *id,
 	if (!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);
+		pr_warn("Table header not present\n");
 		return -ENODEV;
 	}
 
@@ -268,31 +263,66 @@ acpi_table_parse_entries(char *id,
 	       table_end) {
 		if (entry->type == entry_id
 		    && (!max_entries || count++ < max_entries))
-			if (handler(entry, table_end))
+			if (handler(entry, table_end)) {
+				count = -EINVAL;
 				goto err;
+		}
 
 		/*
 		 * If entry->length is 0, break from this loop to avoid
 		 * infinite loop.
 		 */
 		if (entry->length == 0) {
-			pr_err("[%4.4s:0x%02x] Invalid zero length\n", id, entry_id);
+			pr_err("[0x%02x] Invalid zero length\n", entry_id);
+			count = -EINVAL;
 			goto err;
 		}
 
 		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);
+		pr_warn("[0x%02x] ignored %i entries of %i found\n",
+			entry_id, count - max_entries, count);
 	}
 
-	early_acpi_os_unmap_memory((char *)table_header, tbl_size);
-	return count;
 err:
+	return count;
+}
+
+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;
+
+	if (acpi_disabled)
+		return -ENODEV;
+
+	if (!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_header) {
+		pr_warn("%4.4s not present\n", id);
+		return -ENODEV;
+	}
+
+	count = acpi_parse_entries(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 ad6c30f..95540e7 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(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.7.9.5

[PATCH 14/19] ARM64 / ACPI: Add GICv2 specific ACPI boot support

[Hanjun Guo]

From: Tomasz Nowicki <tomasz.nowicki@linaro.org>

ACPI kernel uses MADT table for proper GIC initialization. It needs to
parse GIC related subtables, collect CPU interface and distributor
addresses and call driver initialization function (which is hardware
abstraction agnostic). In a similar way, FDT initialize GICv1/2.

NOTE: This commit allow to initialize GICv1/2 only.

Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/acpi.h        |    2 -
 arch/arm64/kernel/acpi.c             |   26 +++++++-
 arch/arm64/kernel/irq.c              |    5 ++
 drivers/irqchip/irq-gic.c            |  114 ++++++++++++++++++++++++++++++++++
 include/linux/irqchip/arm-gic-acpi.h |   36 +++++++++++
 5 files changed, 180 insertions(+), 3 deletions(-)
 create mode 100644 include/linux/irqchip/arm-gic-acpi.h

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index f40e137..60497a6 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -85,8 +85,6 @@ static inline bool acpi_has_cpu_in_madt(void)
 extern int (*acpi_suspend_lowlevel)(void);
 #define acpi_wakeup_address 0
 
-#define MAX_GIC_CPU_INTERFACE 65535
-
 #endif /* CONFIG_ACPI */
 
 #endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 3a078dc..1f28f1e 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -21,6 +21,7 @@
 #include <linux/irqdomain.h>
 #include <linux/bootmem.h>
 #include <linux/smp.h>
+#include <linux/irqchip/arm-gic-acpi.h>
 
 #include <asm/cputype.h>
 
@@ -173,7 +174,8 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
 	 * we need for SMP init
 	 */
 	count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
-			acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
+				      acpi_parse_gic_cpu_interface,
+				      ACPI_GIC_MAX_CPU_INTERFACE);
 
 	if (!count) {
 		pr_err("No GIC CPU interface entries present\n");
@@ -330,6 +332,28 @@ int __init acpi_boot_init(void)
 	return err;
 }
 
+void __init acpi_gic_init(void)
+{
+	struct acpi_table_header *table;
+	acpi_status status;
+	acpi_size tbl_size;
+	int err;
+
+	status = acpi_get_table_with_size(ACPI_SIG_MADT, 0, &table, &tbl_size);
+	if (ACPI_FAILURE(status)) {
+		const char *msg = acpi_format_exception(status);
+
+		pr_err("Failed to get MADT table, %s\n", msg);
+		return;
+	}
+
+	err = gic_v2_acpi_init(table);
+	if (err)
+		pr_err("Failed to initialize GIC IRQ controller");
+
+	early_acpi_os_unmap_memory((char *)table, tbl_size);
+}
+
 static int __init parse_acpi(char *arg)
 {
 	if (!arg)
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 0f08dfd..c074d60 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -28,6 +28,7 @@
 #include <linux/irqchip.h>
 #include <linux/seq_file.h>
 #include <linux/ratelimit.h>
+#include <linux/irqchip/arm-gic-acpi.h>
 
 unsigned long irq_err_count;
 
@@ -78,6 +79,10 @@ void __init set_handle_irq(void (*handle_irq)(struct pt_regs *))
 void __init init_IRQ(void)
 {
 	irqchip_init();
+
+	if (!handle_arch_irq)
+		acpi_gic_init();
+
 	if (!handle_arch_irq)
 		panic("No interrupt controller found.");
 }
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 7c131cf..25860f0 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -35,12 +35,14 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <linux/acpi.h>
 #include <linux/irqdomain.h>
 #include <linux/interrupt.h>
 #include <linux/percpu.h>
 #include <linux/slab.h>
 #include <linux/irqchip/chained_irq.h>
 #include <linux/irqchip/arm-gic.h>
+#include <linux/irqchip/arm-gic-acpi.h>
 
 #include <asm/cputype.h>
 #include <asm/irq.h>
@@ -1082,3 +1084,115 @@ IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init);
 IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
 
 #endif
+
+#ifdef CONFIG_ACPI
+static u64 dist_phy_base, cpu_phy_base = ULONG_MAX;
+
+static int __init
+gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
+			const unsigned long end)
+{
+	struct acpi_madt_generic_interrupt *processor;
+	u64 gic_cpu_base;
+
+	processor = (struct acpi_madt_generic_interrupt *)header;
+
+	if (BAD_MADT_ENTRY(processor, end))
+		return -EINVAL;
+
+	gic_cpu_base = processor->base_address;
+	if (!gic_cpu_base)
+		return -EFAULT;
+
+	/*
+	 * There is no support for non-banked GICv1/2 register in ACPI spec.
+	 * All CPU interface addresses have to be the same.
+	 */
+	if (cpu_phy_base != ULONG_MAX && gic_cpu_base != cpu_phy_base)
+		return -EFAULT;
+
+	cpu_phy_base = gic_cpu_base;
+	return 0;
+}
+
+static int __init
+gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
+				const unsigned long end)
+{
+	struct acpi_madt_generic_distributor *dist;
+
+	dist = (struct acpi_madt_generic_distributor *)header;
+
+	if (BAD_MADT_ENTRY(dist, end))
+		return -EINVAL;
+
+	dist_phy_base = dist->base_address;
+	if (!dist_phy_base)
+		return -EFAULT;
+
+	return 0;
+}
+
+int __init
+gic_v2_acpi_init(struct acpi_table_header *table)
+{
+	void __iomem *cpu_base, *dist_base;
+	int count;
+
+	/* Collect CPU base addresses */
+	count = acpi_parse_entries(sizeof(struct acpi_table_madt),
+				   gic_acpi_parse_madt_cpu, table,
+				   ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+				   ACPI_GIC_MAX_CPU_INTERFACE);
+	if (count < 0) {
+		pr_err("Error during GICC entries parsing\n");
+		return -EFAULT;
+	} else if (!count) {
+		/* No GICC entries provided, use address from MADT header */
+		struct acpi_table_madt *madt = (struct acpi_table_madt *)table;
+
+		if (!madt->address)
+			return -EFAULT;
+
+		cpu_phy_base = (u64)madt->address;
+	}
+
+	/*
+	 * Find distributor base address. We expect one distributor entry since
+	 * ACPI 5.1 spec neither support multi-GIC instances nor GIC cascade.
+	 */
+	count = acpi_parse_entries(sizeof(struct acpi_table_madt),
+				   gic_acpi_parse_madt_distributor, table,
+				   ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
+				   ACPI_GIC_MAX_DISTRIBUTOR);
+	if (count <= 0) {
+		pr_err("Error during GICD entries parsing\n");
+		return -EFAULT;
+	} else if (count > 1) {
+		pr_err("More than one GICD entry detected\n");
+		return -EINVAL;
+	}
+
+	cpu_base = ioremap(cpu_phy_base, ACPI_GIC_CPU_IF_MEM_SIZE);
+	if (!cpu_base) {
+		pr_err("Unable to map GICC registers\n");
+		return -ENOMEM;
+	}
+
+	dist_base = ioremap(dist_phy_base, ACPI_GIC_DIST_MEM_SIZE);
+	if (!dist_base) {
+		pr_err("Unable to map GICD registers\n");
+		iounmap(cpu_base);
+		return -ENOMEM;
+	}
+
+	/*
+	 * Initialize zero GIC instance (no multi-GIC support). Also, set GIC
+	 * as default IRQ domain to allow for GSI registration and GSI to IRQ
+	 * number translation (see acpi_register_gsi() and acpi_gsi_to_irq()).
+	 */
+	gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
+	irq_set_default_host(gic_data[0].domain);
+	return 0;
+}
+#endif
diff --git a/include/linux/irqchip/arm-gic-acpi.h b/include/linux/irqchip/arm-gic-acpi.h
new file mode 100644
index 0000000..ffcfeb2
--- /dev/null
+++ b/include/linux/irqchip/arm-gic-acpi.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright (C) 2014, Linaro Ltd.
+ *	Author: Tomasz Nowicki <tomasz.nowicki@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef ARM_GIC_ACPI_H_
+#define ARM_GIC_ACPI_H_
+
+#include <linux/acpi.h>
+
+#ifdef CONFIG_ACPI
+#define ACPI_GIC_MAX_CPU_INTERFACE	65535
+#define ACPI_GIC_MAX_DISTRIBUTOR	1
+
+/*
+ * Hard code here, we can not get memory size from MADT (but FDT does),
+ * Actually no need to do that, because this size can be inferred
+ * from GIC spec.
+ */
+#define ACPI_GIC_DIST_MEM_SIZE		(SZ_64K)
+#define ACPI_GIC_CPU_IF_MEM_SIZE	(SZ_8K)
+
+void acpi_gic_init(void);
+int gic_v2_acpi_init(struct acpi_table_header *table);
+#else
+static inline void acpi_gic_init(void)
+{
+
+}
+#endif
+
+#endif /* ARM_GIC_ACPI_H_ */
-- 
1.7.9.5

[PATCH 14/19] ARM64 / ACPI: Add GICv2 specific ACPI boot support

[Hanjun Guo]

From: Tomasz Nowicki <tomasz.nowicki@linaro.org>

ACPI kernel uses MADT table for proper GIC initialization. It needs to
parse GIC related subtables, collect CPU interface and distributor
addresses and call driver initialization function (which is hardware
abstraction agnostic). In a similar way, FDT initialize GICv1/2.

NOTE: This commit allow to initialize GICv1/2 only.

Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/include/asm/acpi.h        |    2 -
 arch/arm64/kernel/acpi.c             |   26 +++++++-
 arch/arm64/kernel/irq.c              |    5 ++
 drivers/irqchip/irq-gic.c            |  114 ++++++++++++++++++++++++++++++++++
 include/linux/irqchip/arm-gic-acpi.h |   36 +++++++++++
 5 files changed, 180 insertions(+), 3 deletions(-)
 create mode 100644 include/linux/irqchip/arm-gic-acpi.h

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index f40e137..60497a6 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -85,8 +85,6 @@ static inline bool acpi_has_cpu_in_madt(void)
 extern int (*acpi_suspend_lowlevel)(void);
 #define acpi_wakeup_address 0
 
-#define MAX_GIC_CPU_INTERFACE 65535
-
 #endif /* CONFIG_ACPI */
 
 #endif /*_ASM_ACPI_H*/
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 3a078dc..1f28f1e 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -21,6 +21,7 @@
 #include <linux/irqdomain.h>
 #include <linux/bootmem.h>
 #include <linux/smp.h>
+#include <linux/irqchip/arm-gic-acpi.h>
 
 #include <asm/cputype.h>
 
@@ -173,7 +174,8 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
 	 * we need for SMP init
 	 */
 	count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
-			acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
+				      acpi_parse_gic_cpu_interface,
+				      ACPI_GIC_MAX_CPU_INTERFACE);
 
 	if (!count) {
 		pr_err("No GIC CPU interface entries present\n");
@@ -330,6 +332,28 @@ int __init acpi_boot_init(void)
 	return err;
 }
 
+void __init acpi_gic_init(void)
+{
+	struct acpi_table_header *table;
+	acpi_status status;
+	acpi_size tbl_size;
+	int err;
+
+	status = acpi_get_table_with_size(ACPI_SIG_MADT, 0, &table, &tbl_size);
+	if (ACPI_FAILURE(status)) {
+		const char *msg = acpi_format_exception(status);
+
+		pr_err("Failed to get MADT table, %s\n", msg);
+		return;
+	}
+
+	err = gic_v2_acpi_init(table);
+	if (err)
+		pr_err("Failed to initialize GIC IRQ controller");
+
+	early_acpi_os_unmap_memory((char *)table, tbl_size);
+}
+
 static int __init parse_acpi(char *arg)
 {
 	if (!arg)
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 0f08dfd..c074d60 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -28,6 +28,7 @@
 #include <linux/irqchip.h>
 #include <linux/seq_file.h>
 #include <linux/ratelimit.h>
+#include <linux/irqchip/arm-gic-acpi.h>
 
 unsigned long irq_err_count;
 
@@ -78,6 +79,10 @@ void __init set_handle_irq(void (*handle_irq)(struct pt_regs *))
 void __init init_IRQ(void)
 {
 	irqchip_init();
+
+	if (!handle_arch_irq)
+		acpi_gic_init();
+
 	if (!handle_arch_irq)
 		panic("No interrupt controller found.");
 }
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 7c131cf..25860f0 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -35,12 +35,14 @@
 #include <linux/of.h>
 #include <linux/of_address.h>
 #include <linux/of_irq.h>
+#include <linux/acpi.h>
 #include <linux/irqdomain.h>
 #include <linux/interrupt.h>
 #include <linux/percpu.h>
 #include <linux/slab.h>
 #include <linux/irqchip/chained_irq.h>
 #include <linux/irqchip/arm-gic.h>
+#include <linux/irqchip/arm-gic-acpi.h>
 
 #include <asm/cputype.h>
 #include <asm/irq.h>
@@ -1082,3 +1084,115 @@ IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init);
 IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
 
 #endif
+
+#ifdef CONFIG_ACPI
+static u64 dist_phy_base, cpu_phy_base = ULONG_MAX;
+
+static int __init
+gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
+			const unsigned long end)
+{
+	struct acpi_madt_generic_interrupt *processor;
+	u64 gic_cpu_base;
+
+	processor = (struct acpi_madt_generic_interrupt *)header;
+
+	if (BAD_MADT_ENTRY(processor, end))
+		return -EINVAL;
+
+	gic_cpu_base = processor->base_address;
+	if (!gic_cpu_base)
+		return -EFAULT;
+
+	/*
+	 * There is no support for non-banked GICv1/2 register in ACPI spec.
+	 * All CPU interface addresses have to be the same.
+	 */
+	if (cpu_phy_base != ULONG_MAX && gic_cpu_base != cpu_phy_base)
+		return -EFAULT;
+
+	cpu_phy_base = gic_cpu_base;
+	return 0;
+}
+
+static int __init
+gic_acpi_parse_madt_distributor(struct acpi_subtable_header *header,
+				const unsigned long end)
+{
+	struct acpi_madt_generic_distributor *dist;
+
+	dist = (struct acpi_madt_generic_distributor *)header;
+
+	if (BAD_MADT_ENTRY(dist, end))
+		return -EINVAL;
+
+	dist_phy_base = dist->base_address;
+	if (!dist_phy_base)
+		return -EFAULT;
+
+	return 0;
+}
+
+int __init
+gic_v2_acpi_init(struct acpi_table_header *table)
+{
+	void __iomem *cpu_base, *dist_base;
+	int count;
+
+	/* Collect CPU base addresses */
+	count = acpi_parse_entries(sizeof(struct acpi_table_madt),
+				   gic_acpi_parse_madt_cpu, table,
+				   ACPI_MADT_TYPE_GENERIC_INTERRUPT,
+				   ACPI_GIC_MAX_CPU_INTERFACE);
+	if (count < 0) {
+		pr_err("Error during GICC entries parsing\n");
+		return -EFAULT;
+	} else if (!count) {
+		/* No GICC entries provided, use address from MADT header */
+		struct acpi_table_madt *madt = (struct acpi_table_madt *)table;
+
+		if (!madt->address)
+			return -EFAULT;
+
+		cpu_phy_base = (u64)madt->address;
+	}
+
+	/*
+	 * Find distributor base address. We expect one distributor entry since
+	 * ACPI 5.1 spec neither support multi-GIC instances nor GIC cascade.
+	 */
+	count = acpi_parse_entries(sizeof(struct acpi_table_madt),
+				   gic_acpi_parse_madt_distributor, table,
+				   ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR,
+				   ACPI_GIC_MAX_DISTRIBUTOR);
+	if (count <= 0) {
+		pr_err("Error during GICD entries parsing\n");
+		return -EFAULT;
+	} else if (count > 1) {
+		pr_err("More than one GICD entry detected\n");
+		return -EINVAL;
+	}
+
+	cpu_base = ioremap(cpu_phy_base, ACPI_GIC_CPU_IF_MEM_SIZE);
+	if (!cpu_base) {
+		pr_err("Unable to map GICC registers\n");
+		return -ENOMEM;
+	}
+
+	dist_base = ioremap(dist_phy_base, ACPI_GIC_DIST_MEM_SIZE);
+	if (!dist_base) {
+		pr_err("Unable to map GICD registers\n");
+		iounmap(cpu_base);
+		return -ENOMEM;
+	}
+
+	/*
+	 * Initialize zero GIC instance (no multi-GIC support). Also, set GIC
+	 * as default IRQ domain to allow for GSI registration and GSI to IRQ
+	 * number translation (see acpi_register_gsi() and acpi_gsi_to_irq()).
+	 */
+	gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
+	irq_set_default_host(gic_data[0].domain);
+	return 0;
+}
+#endif
diff --git a/include/linux/irqchip/arm-gic-acpi.h b/include/linux/irqchip/arm-gic-acpi.h
new file mode 100644
index 0000000..ffcfeb2
--- /dev/null
+++ b/include/linux/irqchip/arm-gic-acpi.h
@@ -0,0 +1,36 @@
+/*
+ * Copyright (C) 2014, Linaro Ltd.
+ *	Author: Tomasz Nowicki <tomasz.nowicki@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef ARM_GIC_ACPI_H_
+#define ARM_GIC_ACPI_H_
+
+#include <linux/acpi.h>
+
+#ifdef CONFIG_ACPI
+#define ACPI_GIC_MAX_CPU_INTERFACE	65535
+#define ACPI_GIC_MAX_DISTRIBUTOR	1
+
+/*
+ * Hard code here, we can not get memory size from MADT (but FDT does),
+ * Actually no need to do that, because this size can be inferred
+ * from GIC spec.
+ */
+#define ACPI_GIC_DIST_MEM_SIZE		(SZ_64K)
+#define ACPI_GIC_CPU_IF_MEM_SIZE	(SZ_8K)
+
+void acpi_gic_init(void);
+int gic_v2_acpi_init(struct acpi_table_header *table);
+#else
+static inline void acpi_gic_init(void)
+{
+
+}
+#endif
+
+#endif /* ARM_GIC_ACPI_H_ */
-- 
1.7.9.5

[PATCH 15/19] ARM64 / ACPI: Parse GTDT to initialize arch timer

[Hanjun Guo]

Using the information presented by GTDT to initialize the arch
timer (not memory-mapped).

Originally-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/kernel/time.c             |    7 ++
 drivers/clocksource/arm_arch_timer.c |  117 ++++++++++++++++++++++++++++------
 include/linux/clocksource.h          |    6 ++
 3 files changed, 111 insertions(+), 19 deletions(-)

diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index 1a7125c..42f9195 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -35,6 +35,7 @@
 #include <linux/delay.h>
 #include <linux/clocksource.h>
 #include <linux/clk-provider.h>
+#include <linux/acpi.h>
 
 #include <clocksource/arm_arch_timer.h>
 
@@ -72,6 +73,12 @@ void __init time_init(void)
 
 	tick_setup_hrtimer_broadcast();
 
+	/*
+	 * Since ACPI or FDT will only one be available in the system,
+	 * we can use acpi_generic_timer_init() here safely
+	 */
+	acpi_generic_timer_init();
+
 	arch_timer_rate = arch_timer_get_rate();
 	if (!arch_timer_rate)
 		panic("Unable to initialise architected timer.\n");
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 5163ec1..397783f 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -21,6 +21,7 @@
 #include <linux/io.h>
 #include <linux/slab.h>
 #include <linux/sched_clock.h>
+#include <linux/acpi.h>
 
 #include <asm/arch_timer.h>
 #include <asm/virt.h>
@@ -338,8 +339,12 @@ arch_timer_detect_rate(void __iomem *cntbase, struct device_node *np)
 	if (arch_timer_rate)
 		return;
 
-	/* Try to determine the frequency from the device tree or CNTFRQ */
-	if (of_property_read_u32(np, "clock-frequency", &arch_timer_rate)) {
+	/*
+	 * Try to determine the frequency from the device tree or CNTFRQ,
+	 * if ACPI is enabled, get the frequency from CNTFRQ ONLY.
+	 */
+	if (!acpi_disabled ||
+	    of_property_read_u32(np, "clock-frequency", &arch_timer_rate)) {
 		if (cntbase)
 			arch_timer_rate = readl_relaxed(cntbase + CNTFRQ);
 		else
@@ -635,20 +640,8 @@ static void __init arch_timer_common_init(void)
 	arch_timer_arch_init();
 }
 
-static void __init arch_timer_init(struct device_node *np)
+static void __init arch_timer_init(void)
 {
-	int i;
-
-	if (arch_timers_present & ARCH_CP15_TIMER) {
-		pr_warn("arch_timer: multiple nodes in dt, skipping\n");
-		return;
-	}
-
-	arch_timers_present |= ARCH_CP15_TIMER;
-	for (i = PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++)
-		arch_timer_ppi[i] = irq_of_parse_and_map(np, i);
-	arch_timer_detect_rate(NULL, np);
-
 	/*
 	 * If HYP mode is available, we know that the physical timer
 	 * has been configured to be accessible from PL1. Use it, so
@@ -667,13 +660,31 @@ static void __init arch_timer_init(struct device_node *np)
 		}
 	}
 
-	arch_timer_c3stop = !of_property_read_bool(np, "always-on");
-
 	arch_timer_register();
 	arch_timer_common_init();
 }
-CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_init);
-CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_init);
+
+static void __init arch_timer_of_init(struct device_node *np)
+{
+	int i;
+
+	if (arch_timers_present & ARCH_CP15_TIMER) {
+		pr_warn("arch_timer: multiple nodes in dt, skipping\n");
+		return;
+	}
+
+	arch_timers_present |= ARCH_CP15_TIMER;
+	for (i = PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++)
+		arch_timer_ppi[i] = irq_of_parse_and_map(np, i);
+
+	arch_timer_detect_rate(NULL, np);
+
+	arch_timer_c3stop = !of_property_read_bool(np, "always-on");
+
+	arch_timer_init();
+}
+CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_of_init);
+CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_of_init);
 
 static void __init arch_timer_mem_init(struct device_node *np)
 {
@@ -740,3 +751,71 @@ static void __init arch_timer_mem_init(struct device_node *np)
 }
 CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
 		       arch_timer_mem_init);
+
+#ifdef CONFIG_ACPI
+static int __init
+map_generic_timer_interrupt(u32 interrupt, u32 flags)
+{
+	int trigger, polarity;
+
+	if (!interrupt)
+		return 0;
+
+	trigger = (flags & ACPI_GTDT_INTERRUPT_MODE) ? ACPI_EDGE_SENSITIVE
+			: ACPI_LEVEL_SENSITIVE;
+
+	polarity = (flags & ACPI_GTDT_INTERRUPT_POLARITY) ? ACPI_ACTIVE_LOW
+			: ACPI_ACTIVE_HIGH;
+
+	return acpi_register_gsi(NULL, interrupt, trigger, polarity);
+}
+
+/* Initialize per-processor generic timer */
+static int __init arch_timer_acpi_init(struct acpi_table_header *table)
+{
+	struct acpi_table_gtdt *gtdt;
+
+	if (arch_timers_present & ARCH_CP15_TIMER) {
+		pr_warn("arch_timer: already initialized, skipping\n");
+		return -EINVAL;
+	}
+
+	gtdt = container_of(table, struct acpi_table_gtdt, header);
+
+	arch_timers_present |= ARCH_CP15_TIMER;
+
+	arch_timer_ppi[PHYS_SECURE_PPI] =
+		map_generic_timer_interrupt(gtdt->secure_el1_interrupt,
+		gtdt->secure_el1_flags);
+
+	arch_timer_ppi[PHYS_NONSECURE_PPI] =
+		map_generic_timer_interrupt(gtdt->non_secure_el1_interrupt,
+		gtdt->non_secure_el1_flags);
+
+	arch_timer_ppi[VIRT_PPI] =
+		map_generic_timer_interrupt(gtdt->virtual_timer_interrupt,
+		gtdt->virtual_timer_flags);
+
+	arch_timer_ppi[HYP_PPI] =
+		map_generic_timer_interrupt(gtdt->non_secure_el2_interrupt,
+		gtdt->non_secure_el2_flags);
+
+	/* Get the frequency from CNTFRQ */
+	arch_timer_detect_rate(NULL, NULL);
+
+	/* Always-on capability */
+	arch_timer_c3stop = !(gtdt->non_secure_el1_flags & ACPI_GTDT_ALWAYS_ON);
+
+	arch_timer_init();
+	return 0;
+}
+
+/* Initialize all the generic timers presented in GTDT */
+void __init acpi_generic_timer_init(void)
+{
+	if (acpi_disabled)
+		return;
+
+	acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init);
+}
+#endif
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index a16b497..544e298 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -348,4 +348,10 @@ extern void clocksource_of_init(void);
 static inline void clocksource_of_init(void) {}
 #endif
 
+#ifdef CONFIG_ACPI
+void acpi_generic_timer_init(void);
+#else
+static inline void acpi_generic_timer_init(void) {}
+#endif
+
 #endif /* _LINUX_CLOCKSOURCE_H */
-- 
1.7.9.5

[PATCH 15/19] ARM64 / ACPI: Parse GTDT to initialize arch timer

[Hanjun Guo]

Using the information presented by GTDT to initialize the arch
timer (not memory-mapped).

Originally-by: Amit Daniel Kachhap <amit.daniel@samsung.com>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/kernel/time.c             |    7 ++
 drivers/clocksource/arm_arch_timer.c |  117 ++++++++++++++++++++++++++++------
 include/linux/clocksource.h          |    6 ++
 3 files changed, 111 insertions(+), 19 deletions(-)

diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
index 1a7125c..42f9195 100644
--- a/arch/arm64/kernel/time.c
+++ b/arch/arm64/kernel/time.c
@@ -35,6 +35,7 @@
 #include <linux/delay.h>
 #include <linux/clocksource.h>
 #include <linux/clk-provider.h>
+#include <linux/acpi.h>
 
 #include <clocksource/arm_arch_timer.h>
 
@@ -72,6 +73,12 @@ void __init time_init(void)
 
 	tick_setup_hrtimer_broadcast();
 
+	/*
+	 * Since ACPI or FDT will only one be available in the system,
+	 * we can use acpi_generic_timer_init() here safely
+	 */
+	acpi_generic_timer_init();
+
 	arch_timer_rate = arch_timer_get_rate();
 	if (!arch_timer_rate)
 		panic("Unable to initialise architected timer.\n");
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index 5163ec1..397783f 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -21,6 +21,7 @@
 #include <linux/io.h>
 #include <linux/slab.h>
 #include <linux/sched_clock.h>
+#include <linux/acpi.h>
 
 #include <asm/arch_timer.h>
 #include <asm/virt.h>
@@ -338,8 +339,12 @@ arch_timer_detect_rate(void __iomem *cntbase, struct device_node *np)
 	if (arch_timer_rate)
 		return;
 
-	/* Try to determine the frequency from the device tree or CNTFRQ */
-	if (of_property_read_u32(np, "clock-frequency", &arch_timer_rate)) {
+	/*
+	 * Try to determine the frequency from the device tree or CNTFRQ,
+	 * if ACPI is enabled, get the frequency from CNTFRQ ONLY.
+	 */
+	if (!acpi_disabled ||
+	    of_property_read_u32(np, "clock-frequency", &arch_timer_rate)) {
 		if (cntbase)
 			arch_timer_rate = readl_relaxed(cntbase + CNTFRQ);
 		else
@@ -635,20 +640,8 @@ static void __init arch_timer_common_init(void)
 	arch_timer_arch_init();
 }
 
-static void __init arch_timer_init(struct device_node *np)
+static void __init arch_timer_init(void)
 {
-	int i;
-
-	if (arch_timers_present & ARCH_CP15_TIMER) {
-		pr_warn("arch_timer: multiple nodes in dt, skipping\n");
-		return;
-	}
-
-	arch_timers_present |= ARCH_CP15_TIMER;
-	for (i = PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++)
-		arch_timer_ppi[i] = irq_of_parse_and_map(np, i);
-	arch_timer_detect_rate(NULL, np);
-
 	/*
 	 * If HYP mode is available, we know that the physical timer
 	 * has been configured to be accessible from PL1. Use it, so
@@ -667,13 +660,31 @@ static void __init arch_timer_init(struct device_node *np)
 		}
 	}
 
-	arch_timer_c3stop = !of_property_read_bool(np, "always-on");
-
 	arch_timer_register();
 	arch_timer_common_init();
 }
-CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_init);
-CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_init);
+
+static void __init arch_timer_of_init(struct device_node *np)
+{
+	int i;
+
+	if (arch_timers_present & ARCH_CP15_TIMER) {
+		pr_warn("arch_timer: multiple nodes in dt, skipping\n");
+		return;
+	}
+
+	arch_timers_present |= ARCH_CP15_TIMER;
+	for (i = PHYS_SECURE_PPI; i < MAX_TIMER_PPI; i++)
+		arch_timer_ppi[i] = irq_of_parse_and_map(np, i);
+
+	arch_timer_detect_rate(NULL, np);
+
+	arch_timer_c3stop = !of_property_read_bool(np, "always-on");
+
+	arch_timer_init();
+}
+CLOCKSOURCE_OF_DECLARE(armv7_arch_timer, "arm,armv7-timer", arch_timer_of_init);
+CLOCKSOURCE_OF_DECLARE(armv8_arch_timer, "arm,armv8-timer", arch_timer_of_init);
 
 static void __init arch_timer_mem_init(struct device_node *np)
 {
@@ -740,3 +751,71 @@ static void __init arch_timer_mem_init(struct device_node *np)
 }
 CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
 		       arch_timer_mem_init);
+
+#ifdef CONFIG_ACPI
+static int __init
+map_generic_timer_interrupt(u32 interrupt, u32 flags)
+{
+	int trigger, polarity;
+
+	if (!interrupt)
+		return 0;
+
+	trigger = (flags & ACPI_GTDT_INTERRUPT_MODE) ? ACPI_EDGE_SENSITIVE
+			: ACPI_LEVEL_SENSITIVE;
+
+	polarity = (flags & ACPI_GTDT_INTERRUPT_POLARITY) ? ACPI_ACTIVE_LOW
+			: ACPI_ACTIVE_HIGH;
+
+	return acpi_register_gsi(NULL, interrupt, trigger, polarity);
+}
+
+/* Initialize per-processor generic timer */
+static int __init arch_timer_acpi_init(struct acpi_table_header *table)
+{
+	struct acpi_table_gtdt *gtdt;
+
+	if (arch_timers_present & ARCH_CP15_TIMER) {
+		pr_warn("arch_timer: already initialized, skipping\n");
+		return -EINVAL;
+	}
+
+	gtdt = container_of(table, struct acpi_table_gtdt, header);
+
+	arch_timers_present |= ARCH_CP15_TIMER;
+
+	arch_timer_ppi[PHYS_SECURE_PPI] =
+		map_generic_timer_interrupt(gtdt->secure_el1_interrupt,
+		gtdt->secure_el1_flags);
+
+	arch_timer_ppi[PHYS_NONSECURE_PPI] =
+		map_generic_timer_interrupt(gtdt->non_secure_el1_interrupt,
+		gtdt->non_secure_el1_flags);
+
+	arch_timer_ppi[VIRT_PPI] =
+		map_generic_timer_interrupt(gtdt->virtual_timer_interrupt,
+		gtdt->virtual_timer_flags);
+
+	arch_timer_ppi[HYP_PPI] =
+		map_generic_timer_interrupt(gtdt->non_secure_el2_interrupt,
+		gtdt->non_secure_el2_flags);
+
+	/* Get the frequency from CNTFRQ */
+	arch_timer_detect_rate(NULL, NULL);
+
+	/* Always-on capability */
+	arch_timer_c3stop = !(gtdt->non_secure_el1_flags & ACPI_GTDT_ALWAYS_ON);
+
+	arch_timer_init();
+	return 0;
+}
+
+/* Initialize all the generic timers presented in GTDT */
+void __init acpi_generic_timer_init(void)
+{
+	if (acpi_disabled)
+		return;
+
+	acpi_table_parse(ACPI_SIG_GTDT, arch_timer_acpi_init);
+}
+#endif
diff --git a/include/linux/clocksource.h b/include/linux/clocksource.h
index a16b497..544e298 100644
--- a/include/linux/clocksource.h
+++ b/include/linux/clocksource.h
@@ -348,4 +348,10 @@ extern void clocksource_of_init(void);
 static inline void clocksource_of_init(void) {}
 #endif
 
+#ifdef CONFIG_ACPI
+void acpi_generic_timer_init(void);
+#else
+static inline void acpi_generic_timer_init(void) {}
+#endif
+
 #endif /* _LINUX_CLOCKSOURCE_H */
-- 
1.7.9.5

[PATCH 16/19] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64

[Hanjun Guo]

From: Al Stone <al.stone@linaro.org>

ACPI reduced hardware mode is disabled by default, but ARM64
can only run properly in ACPI hardware reduced mode, so select
ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64.

Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 839f48c..95835bc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1,5 +1,6 @@
 config ARM64
 	def_bool y
+	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_OPP
 	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
-- 
1.7.9.5

[PATCH 16/19] ARM64 / ACPI: Select ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64

[Hanjun Guo]

From: Al Stone <al.stone@linaro.org>

ACPI reduced hardware mode is disabled by default, but ARM64
can only run properly in ACPI hardware reduced mode, so select
ACPI_REDUCED_HARDWARE_ONLY if ACPI is enabled on ARM64.

Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/Kconfig |    1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 839f48c..95835bc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1,5 +1,6 @@
 config ARM64
 	def_bool y
+	select ACPI_REDUCED_HARDWARE_ONLY if ACPI
 	select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
 	select ARCH_HAS_OPP
 	select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
-- 
1.7.9.5

[PATCH 17/19] ARM64 / ACPI: If we chose to boot from acpi then disable FDT

[Hanjun Guo]

From: Graeme Gregory <graeme.gregory@linaro.org>

If the early boot methods of acpi are happy that we have valid ACPI
tables and acpi=off has not been passed. Then do not unflat devicetree
effectively disabling further hardware probing from DT.

Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/kernel/setup.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 17ab98e..4ace77c 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -397,8 +397,8 @@ void __init setup_arch(char **cmdline_p)
 	/* Get the boot CPU's MPIDR before cpu logical map is built */
 	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
 	acpi_boot_init();
-
-	unflatten_device_tree();
+	if (acpi_disabled)
+		unflatten_device_tree();
 
 	psci_init();
 
-- 
1.7.9.5

[PATCH 17/19] ARM64 / ACPI: If we chose to boot from acpi then disable FDT

[Hanjun Guo]

From: Graeme Gregory <graeme.gregory@linaro.org>

If the early boot methods of acpi are happy that we have valid ACPI
tables and acpi=off has not been passed. Then do not unflat devicetree
effectively disabling further hardware probing from DT.

Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/kernel/setup.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 17ab98e..4ace77c 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -397,8 +397,8 @@ void __init setup_arch(char **cmdline_p)
 	/* Get the boot CPU's MPIDR before cpu logical map is built */
 	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
 	acpi_boot_init();
-
-	unflatten_device_tree();
+	if (acpi_disabled)
+		unflatten_device_tree();
 
 	psci_init();
 
-- 
1.7.9.5

[PATCH 18/19] ARM64 / ACPI: Enable ARM64 in Kconfig

[Hanjun Guo]

From: Graeme Gregory <graeme.gregory@linaro.org>

Add Kconfigs to build ACPI on ARM64, and make ACPI available on ARM64.

acpi_idle driver is x86/IA64 dependent now, so make CONFIG_ACPI_PROCESSOR
depend on X86 || IA64, and implement it on ARM64 in the future.

Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/Kconfig   |    2 ++
 drivers/acpi/Kconfig |    6 +++---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 95835bc..1e0ca19 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -362,6 +362,8 @@ source "drivers/Kconfig"
 
 source "drivers/firmware/Kconfig"
 
+source "drivers/acpi/Kconfig"
+
 source "fs/Kconfig"
 
 source "arch/arm64/kvm/Kconfig"
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 3f5f745..f6b6791 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -5,8 +5,7 @@
 menuconfig ACPI
 	bool "ACPI (Advanced Configuration and Power Interface) Support"
 	depends on !IA64_HP_SIM
-	depends on IA64 || X86
-	depends on PCI
+	depends on ((IA64 || X86) && PCI) || ARM64
 	select PNP
 	default y
 	help
@@ -163,6 +162,7 @@ config ACPI_PROCESSOR
 	tristate "Processor"
 	select THERMAL
 	select CPU_IDLE
+	depends on X86 || IA64
 	default y
 	help
 	  This driver installs ACPI as the idle handler for Linux and uses
@@ -263,7 +263,7 @@ config ACPI_DEBUG
 
 config ACPI_PCI_SLOT
 	bool "PCI slot detection driver"
-	depends on SYSFS
+	depends on SYSFS && PCI
 	default n
 	help
 	  This driver creates entries in /sys/bus/pci/slots/ for all PCI
-- 
1.7.9.5

[PATCH 18/19] ARM64 / ACPI: Enable ARM64 in Kconfig

[Hanjun Guo]

From: Graeme Gregory <graeme.gregory@linaro.org>

Add Kconfigs to build ACPI on ARM64, and make ACPI available on ARM64.

acpi_idle driver is x86/IA64 dependent now, so make CONFIG_ACPI_PROCESSOR
depend on X86 || IA64, and implement it on ARM64 in the future.

Reviewed-by: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Al Stone <al.stone@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 arch/arm64/Kconfig   |    2 ++
 drivers/acpi/Kconfig |    6 +++---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 95835bc..1e0ca19 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -362,6 +362,8 @@ source "drivers/Kconfig"
 
 source "drivers/firmware/Kconfig"
 
+source "drivers/acpi/Kconfig"
+
 source "fs/Kconfig"
 
 source "arch/arm64/kvm/Kconfig"
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 3f5f745..f6b6791 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -5,8 +5,7 @@
 menuconfig ACPI
 	bool "ACPI (Advanced Configuration and Power Interface) Support"
 	depends on !IA64_HP_SIM
-	depends on IA64 || X86
-	depends on PCI
+	depends on ((IA64 || X86) && PCI) || ARM64
 	select PNP
 	default y
 	help
@@ -163,6 +162,7 @@ config ACPI_PROCESSOR
 	tristate "Processor"
 	select THERMAL
 	select CPU_IDLE
+	depends on X86 || IA64
 	default y
 	help
 	  This driver installs ACPI as the idle handler for Linux and uses
@@ -263,7 +263,7 @@ config ACPI_DEBUG
 
 config ACPI_PCI_SLOT
 	bool "PCI slot detection driver"
-	depends on SYSFS
+	depends on SYSFS && PCI
 	default n
 	help
 	  This driver creates entries in /sys/bus/pci/slots/ for all PCI
-- 
1.7.9.5

[PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

From: Graeme Gregory <graeme.gregory@linaro.org>

Add documentation for the guidelines of how to use ACPI
on ARM64.

Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 240 insertions(+)
 create mode 100644 Documentation/arm64/arm-acpi.txt

diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
new file mode 100644
index 0000000..12cd550
--- /dev/null
+++ b/Documentation/arm64/arm-acpi.txt
@@ -0,0 +1,240 @@
+ACPI on ARMv8 Servers
+---------------------
+
+ACPI will be used for ARMv8 general purpose servers designed to follow
+the SBSA specification (currently available to people with an ARM login at
+http://silver.arm.com)
+
+The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
+which is available at <http://www.uefi.org/acpi/specs>.
+
+If the machine does not meet these requirements then it is likely that Device
+Tree (DT) is more suitable for the hardware.
+
+Relationship with Device Tree
+-----------------------------
+
+ACPI support in drivers and subsystems for ARMv8 should never be mutually
+exclusive with DT support at compile time.
+
+At boot time the kernel will only use one description method depending on
+parameters passed from the bootloader.
+
+Regardless of whether DT or ACPI is used, the kernel must always be capable
+of booting with either scheme.
+
+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.
+
+Booting using ACPI tables
+-------------------------
+
+Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
+is via the UEFI system configuration table.
+
+The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
+RSDP table (the table with the ACPI signature "RSD PTR ").
+
+The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
+
+Processing of ACPI tables may be disabled by passing acpi=off on the kernel
+command line.
+
+DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
+only allow for 32bit addresses.
+
+DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
+64-bit alternatives MUST be used.
+
+The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
+and GTDT. If PCI is used the MCFG table MUST also be present.
+
+ACPI Detection
+--------------
+
+Drivers should determine their probe() type by checking for ACPI_HANDLE,
+or .of_node, or other information in the device structure. This is
+detailed further in the "Driver Recomendations" section.
+
+If the presence of ACPI needs to be detected at runtime, then check the value
+of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
+
+Device Enumeration
+------------------
+
+Device descriptions in ACPI should use standard recognised ACPI interfaces.
+These are far simpler than the information provided via Device Tree. Drivers
+should take into account this simplicity and work with sensible defaults.
+
+On no account should a Device Tree attempt to be replicated in ASL using such
+constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
+data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
+_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
+
+Common _DSD bindings should be submitted to ASWG to be included in the
+document :-
+
+http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
+
+TODO: Clarification and examples from Juno implementation.
+
+Programmable Power Control Resources
+------------------------------------
+
+Programmable power control resources include such resources as voltage/current
+providers (regulators) and clock sources.
+
+For power control of these resources they should be represented with Power
+Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
+enabling/disabling of resources as they are needed.
+
+There exists in the ACPI 5.1 specification no standard binding for these objects
+to enable programmable levels or rates so this should be avoid if possible and
+the resources set to appropriate level by the firmware. If this is not possible
+then any manipulation should be abstracted in ASL.
+
+Each device in ACPI has D-states and these can be controlled through
+the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
+
+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 organise that it is allocated/enabled using the _PS0 method.
+
+Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
+in the _PS3 method.
+
+Such code in _PS? methods will of course be very platform specific but
+should allow the driver to operate the device without special non standard
+values being read from ASL. Further, abstracting the use of these resources
+allows hardware revisions without requiring updates to the kernel.
+
+TODO: Clarification and examples from Juno implementation.
+
+Clocks
+------
+
+Like clocks that are part of the power resources there is no standard way
+to represent a clock tree in ACPI 5.1 in a similar manner to how it is
+described in DT.
+
+Devices affected by this include things like UARTs, SoC driven LCD displays,
+etc.
+
+The firmware for example UEFI should initialise these clocks to fixed working
+values before the kernel is executed. If a driver requires to know rates of
+clocks set by firmware then they can be passed to kernel using _DSD.
+
+example :-
+
+Device (CLK0) {
+	...
+
+	Name (_DSD, Package() {
+		ToUUID("XXXXX"),
+		Package() {
+			Package(2) {"#clock-cells", 0},
+			Package(2) {"clock-frequency", "10000"}
+		}
+	})
+
+	...
+}
+
+Device (USR1) {
+	...
+
+	Name (_DSD, Package() {
+		ToUUID("XXXXX"),
+		Package() {
+			Package(2) {"clocks", Package() {1, ^CLK0}}},
+		}
+	})
+
+	...
+}
+			
+Driver Recommendations
+----------------------
+
+DO NOT remove any FDT handling when adding ACPI support for a driver, different
+systems may use the same device.
+
+DO try and keep complex sections of ACPI and DT functionality seperate. This
+may mean a patch to break out some complex DT to another function before
+the patch to add ACPI. This may happen in other functions but is most likely
+in probe function. This gives a clearer flow of data for reviewing driver
+source.
+
+probe() :-
+
+TODO: replace this with a specific real example from Juno?
+
+static int device_probe_dt(struct platform_device *pdev)
+{
+	/* DT specific functionality */
+	...
+}
+
+static int device_probe_acpi(struct platform_device *pdev)
+{
+	/* ACPI specific functionality */
+	...
+}
+
+static int device_probe(stuct platform_device *pdev)
+{
+	...
+	acpi_handle handle = ACPI_HANDLE(&pdev->dev);
+	struct device_node node = pdev->dev.of_node;
+	...
+
+	if (node)
+		ret = device_probe_dt(pdev);
+	else if (handle)
+		ret = device_probe_acpi(pdev);
+	else
+		/* other initialisation */
+		...
+	/* Continue with any generic probe operations */
+	...
+}
+
+DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
+the different names the driver is probed for, both from DT and from ACPI.
+
+module device tables :-
+
+static struct of_device_id virtio_mmio_match[] = {
+        { .compatible = "virtio,mmio", },
+        {},
+};
+MODULE_DEVICE_TABLE(of, virtio_mmio_match);
+
+static const struct acpi_device_id virtio_mmio_acpi_match[] = {
+        { "LNRO0005", },
+        { }
+};
+MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
+
+TODO: Add any other helpful rules that develop from Juno ACPI work.
+
+ASWG
+----
+
+The following areas are not yet well defined for ARM in the current ACPI
+specification and are expected to be worked through in the UEFI ACPI
+Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
+Participation in this group is open to all UEFI members.
+
+	- ACPI based CPU topology
+	- ACPI based Power management
+	- CPU idle control based on PSCI
+	- CPU performance control (CPPC)
+
+No code shall be accepted into the kernel unless it complies with the released
+standards from UEFI ASWG. If there are features missing from ACPI to make it
+function on a platform ECRs should be submitted to ASWG and go through the
+approval process.
-- 
1.7.9.5

[PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

From: Graeme Gregory <graeme.gregory@linaro.org>

Add documentation for the guidelines of how to use ACPI
on ARM64.

Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
 Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 240 insertions(+)
 create mode 100644 Documentation/arm64/arm-acpi.txt

diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
new file mode 100644
index 0000000..12cd550
--- /dev/null
+++ b/Documentation/arm64/arm-acpi.txt
@@ -0,0 +1,240 @@
+ACPI on ARMv8 Servers
+---------------------
+
+ACPI will be used for ARMv8 general purpose servers designed to follow
+the SBSA specification (currently available to people with an ARM login at
+http://silver.arm.com)
+
+The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
+which is available at <http://www.uefi.org/acpi/specs>.
+
+If the machine does not meet these requirements then it is likely that Device
+Tree (DT) is more suitable for the hardware.
+
+Relationship with Device Tree
+-----------------------------
+
+ACPI support in drivers and subsystems for ARMv8 should never be mutually
+exclusive with DT support at compile time.
+
+At boot time the kernel will only use one description method depending on
+parameters passed from the bootloader.
+
+Regardless of whether DT or ACPI is used, the kernel must always be capable
+of booting with either scheme.
+
+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.
+
+Booting using ACPI tables
+-------------------------
+
+Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
+is via the UEFI system configuration table.
+
+The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
+RSDP table (the table with the ACPI signature "RSD PTR ").
+
+The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
+
+Processing of ACPI tables may be disabled by passing acpi=off on the kernel
+command line.
+
+DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
+only allow for 32bit addresses.
+
+DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
+64-bit alternatives MUST be used.
+
+The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
+and GTDT. If PCI is used the MCFG table MUST also be present.
+
+ACPI Detection
+--------------
+
+Drivers should determine their probe() type by checking for ACPI_HANDLE,
+or .of_node, or other information in the device structure. This is
+detailed further in the "Driver Recomendations" section.
+
+If the presence of ACPI needs to be detected at runtime, then check the value
+of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
+
+Device Enumeration
+------------------
+
+Device descriptions in ACPI should use standard recognised ACPI interfaces.
+These are far simpler than the information provided via Device Tree. Drivers
+should take into account this simplicity and work with sensible defaults.
+
+On no account should a Device Tree attempt to be replicated in ASL using such
+constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
+data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
+_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
+
+Common _DSD bindings should be submitted to ASWG to be included in the
+document :-
+
+http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
+
+TODO: Clarification and examples from Juno implementation.
+
+Programmable Power Control Resources
+------------------------------------
+
+Programmable power control resources include such resources as voltage/current
+providers (regulators) and clock sources.
+
+For power control of these resources they should be represented with Power
+Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
+enabling/disabling of resources as they are needed.
+
+There exists in the ACPI 5.1 specification no standard binding for these objects
+to enable programmable levels or rates so this should be avoid if possible and
+the resources set to appropriate level by the firmware. If this is not possible
+then any manipulation should be abstracted in ASL.
+
+Each device in ACPI has D-states and these can be controlled through
+the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
+
+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 organise that it is allocated/enabled using the _PS0 method.
+
+Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
+in the _PS3 method.
+
+Such code in _PS? methods will of course be very platform specific but
+should allow the driver to operate the device without special non standard
+values being read from ASL. Further, abstracting the use of these resources
+allows hardware revisions without requiring updates to the kernel.
+
+TODO: Clarification and examples from Juno implementation.
+
+Clocks
+------
+
+Like clocks that are part of the power resources there is no standard way
+to represent a clock tree in ACPI 5.1 in a similar manner to how it is
+described in DT.
+
+Devices affected by this include things like UARTs, SoC driven LCD displays,
+etc.
+
+The firmware for example UEFI should initialise these clocks to fixed working
+values before the kernel is executed. If a driver requires to know rates of
+clocks set by firmware then they can be passed to kernel using _DSD.
+
+example :-
+
+Device (CLK0) {
+	...
+
+	Name (_DSD, Package() {
+		ToUUID("XXXXX"),
+		Package() {
+			Package(2) {"#clock-cells", 0},
+			Package(2) {"clock-frequency", "10000"}
+		}
+	})
+
+	...
+}
+
+Device (USR1) {
+	...
+
+	Name (_DSD, Package() {
+		ToUUID("XXXXX"),
+		Package() {
+			Package(2) {"clocks", Package() {1, ^CLK0}}},
+		}
+	})
+
+	...
+}
+			
+Driver Recommendations
+----------------------
+
+DO NOT remove any FDT handling when adding ACPI support for a driver, different
+systems may use the same device.
+
+DO try and keep complex sections of ACPI and DT functionality seperate. This
+may mean a patch to break out some complex DT to another function before
+the patch to add ACPI. This may happen in other functions but is most likely
+in probe function. This gives a clearer flow of data for reviewing driver
+source.
+
+probe() :-
+
+TODO: replace this with a specific real example from Juno?
+
+static int device_probe_dt(struct platform_device *pdev)
+{
+	/* DT specific functionality */
+	...
+}
+
+static int device_probe_acpi(struct platform_device *pdev)
+{
+	/* ACPI specific functionality */
+	...
+}
+
+static int device_probe(stuct platform_device *pdev)
+{
+	...
+	acpi_handle handle = ACPI_HANDLE(&pdev->dev);
+	struct device_node node = pdev->dev.of_node;
+	...
+
+	if (node)
+		ret = device_probe_dt(pdev);
+	else if (handle)
+		ret = device_probe_acpi(pdev);
+	else
+		/* other initialisation */
+		...
+	/* Continue with any generic probe operations */
+	...
+}
+
+DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
+the different names the driver is probed for, both from DT and from ACPI.
+
+module device tables :-
+
+static struct of_device_id virtio_mmio_match[] = {
+        { .compatible = "virtio,mmio", },
+        {},
+};
+MODULE_DEVICE_TABLE(of, virtio_mmio_match);
+
+static const struct acpi_device_id virtio_mmio_acpi_match[] = {
+        { "LNRO0005", },
+        { }
+};
+MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
+
+TODO: Add any other helpful rules that develop from Juno ACPI work.
+
+ASWG
+----
+
+The following areas are not yet well defined for ARM in the current ACPI
+specification and are expected to be worked through in the UEFI ACPI
+Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
+Participation in this group is open to all UEFI members.
+
+	- ACPI based CPU topology
+	- ACPI based Power management
+	- CPU idle control based on PSCI
+	- CPU performance control (CPPC)
+
+No code shall be accepted into the kernel unless it complies with the released
+standards from UEFI ASWG. If there are features missing from ACPI to make it
+function on a platform ECRs should be submitted to ASWG and go through the
+approval process.
-- 
1.7.9.5

Re: [PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 836 bytes --]

On Thu, Jul 24, 2014 at 09:00:10PM +0800, Hanjun Guo wrote:

> +/*
> + * Use the CPU slot number provided by ACPI to update the physical
> + * package id when cpuid_topo->cluster_id is not available, then we
> + * can get the right value in the "physical id" field of /proc/cpuinfo.
> + */
> +void arch_fix_phys_package_id(int num, u32 slot)
> +{
> +	struct cpu_topology *cpuid_topo = &cpu_topology[num];
> +
> +	if (cpuid_topo->cluster_id == -1)
> +		cpuid_topo->cluster_id = slot;
> +}
> +EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);

As I said on the previous version of this patch are you sure this runs
at a point between the cluster ID getting initialized to -1 and the slot
being initialized (bear in mind that we now use MPIDR information if
availabe).  I don't understand why we don't just unconditionally use the
value given.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Mark Brown]

On Thu, Jul 24, 2014 at 09:00:10PM +0800, Hanjun Guo wrote:

> +/*
> + * Use the CPU slot number provided by ACPI to update the physical
> + * package id when cpuid_topo->cluster_id is not available, then we
> + * can get the right value in the "physical id" field of /proc/cpuinfo.
> + */
> +void arch_fix_phys_package_id(int num, u32 slot)
> +{
> +	struct cpu_topology *cpuid_topo = &cpu_topology[num];
> +
> +	if (cpuid_topo->cluster_id == -1)
> +		cpuid_topo->cluster_id = slot;
> +}
> +EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);

As I said on the previous version of this patch are you sure this runs
at a point between the cluster ID getting initialized to -1 and the slot
being initialized (bear in mind that we now use MPIDR information if
availabe).  I don't understand why we don't just unconditionally use the
value given.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140724/ea69f852/attachment.sig>

Re: [PATCH 09/19] ARM64 / ACPI: Move the initialization of cpu_logical_map(0) before acpi_boot_init()

[Mark Rutland]

On Thu, Jul 24, 2014 at 02:00:15PM +0100, Hanjun Guo wrote:
> Move the initialization of cpu_logical_map(0) before acpi_boot_init()
> to remove the duplicated initialization of cpu_logical_map(0).

It always make sense to initialise CPU0's logical map entry from the
hardware values, so you could do this earlier in the series, before you
introduce any ACPI code. Then you don't have the churn in acpi.c

> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  arch/arm64/kernel/acpi.c  |    3 ---
>  arch/arm64/kernel/setup.c |    3 ++-
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 801e268..ff0f6a0 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -244,9 +244,6 @@ int __init acpi_boot_init(void)
>  	if (err)
>  		pr_err("Can't find FADT\n");
>  
> -	/* Get the boot CPU's MPIDR before MADT parsing */
> -	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> -
>  	err = acpi_parse_madt_gic_cpu_interface_entries();
>  
>  	return err;
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index e00d40c..17ab98e 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -394,13 +394,14 @@ void __init setup_arch(char **cmdline_p)
>  
>  	efi_idmap_init();
>  
> +	/* Get the boot CPU's MPIDR before cpu logical map is built */

That comment's a bit useless; I think it can just be dropped.

All you need to do is move the initialisation of cpu_logical_map(0)
before unflatten_device_tree(). When you introduce acpi_boot_init(),
place it after the initialisation.

Thanks,
Mark.

> +	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>  	acpi_boot_init();
>  
>  	unflatten_device_tree();
>  
>  	psci_init();
>  
> -	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>  	cpu_read_bootcpu_ops();
>  #ifdef CONFIG_SMP
>  	smp_init_cpus();
> -- 
> 1.7.9.5
> 
> 

[PATCH 09/19] ARM64 / ACPI: Move the initialization of cpu_logical_map(0) before acpi_boot_init()

[Mark Rutland]

On Thu, Jul 24, 2014 at 02:00:15PM +0100, Hanjun Guo wrote:
> Move the initialization of cpu_logical_map(0) before acpi_boot_init()
> to remove the duplicated initialization of cpu_logical_map(0).

It always make sense to initialise CPU0's logical map entry from the
hardware values, so you could do this earlier in the series, before you
introduce any ACPI code. Then you don't have the churn in acpi.c

> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  arch/arm64/kernel/acpi.c  |    3 ---
>  arch/arm64/kernel/setup.c |    3 ++-
>  2 files changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 801e268..ff0f6a0 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -244,9 +244,6 @@ int __init acpi_boot_init(void)
>  	if (err)
>  		pr_err("Can't find FADT\n");
>  
> -	/* Get the boot CPU's MPIDR before MADT parsing */
> -	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> -
>  	err = acpi_parse_madt_gic_cpu_interface_entries();
>  
>  	return err;
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index e00d40c..17ab98e 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -394,13 +394,14 @@ void __init setup_arch(char **cmdline_p)
>  
>  	efi_idmap_init();
>  
> +	/* Get the boot CPU's MPIDR before cpu logical map is built */

That comment's a bit useless; I think it can just be dropped.

All you need to do is move the initialisation of cpu_logical_map(0)
before unflatten_device_tree(). When you introduce acpi_boot_init(),
place it after the initialisation.

Thanks,
Mark.

> +	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>  	acpi_boot_init();
>  
>  	unflatten_device_tree();
>  
>  	psci_init();
>  
> -	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>  	cpu_read_bootcpu_ops();
>  #ifdef CONFIG_SMP
>  	smp_init_cpus();
> -- 
> 1.7.9.5
> 
> 

Re: [PATCH 03/19] ARM64 / ACPI: Introduce lowlevel suspend function

[Mark Rutland]

On Thu, Jul 24, 2014 at 02:00:09PM +0100, Hanjun Guo wrote:
> From: Graeme Gregory <graeme.gregory@linaro.org>
> 
> acpi_wakeup_address is used on x86 as the address bios jumps into
> when machine wakes up from suspend. As arm64 does not have such a
> bios this mechanism will be provided by other means. But the define
> is still required inside the acpi core.
> 
> Introduce a null stub for acpi_suspend_lowlevel as this is also
> required by core. This will be filled in when standards are
> defined for arm64 ACPI global power states.
> 
> Reviewed-by: Grant Likely <grant.likely@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h |   12 ++++++++++++
>  arch/arm64/kernel/acpi.c      |    7 +++++++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index e8581ea..44b617f 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -36,6 +36,18 @@ static inline bool acpi_has_cpu_in_madt(void)
>  	return 1;
>  }
>  
> +/* Low-level suspend routine.
> + *
> + * ACPI S-states for ARM64 have to be defined
> + * and approved before doing anything else, maybe
> + * we need update the ACPI spec, here we
> + * just introduce function and macro needed by
> + * ACPI core as IA64 did, and revisit them when
> + * the spec is ready.
> + */
> +extern int (*acpi_suspend_lowlevel)(void);
> +#define acpi_wakeup_address 0
> +
>  #endif /* CONFIG_ACPI */
>  
>  #endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index ac78e4e..f5a10b5 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -95,3 +95,10 @@ static int __init parse_acpi(char *arg)
>  	return 0;
>  }
>  early_param("acpi", parse_acpi);
> +
> +/*
> + * acpi_suspend_lowlevel() - save kernel state and suspend.
> + *
> + * TBD when ARM/ARM64 starts to support suspend...
> + */
> +int (*acpi_suspend_lowlevel)(void);

Shouldn't this should be intialised to NULL explicitly?

Thanks,
Mark.

[PATCH 03/19] ARM64 / ACPI: Introduce lowlevel suspend function

[Mark Rutland]

On Thu, Jul 24, 2014 at 02:00:09PM +0100, Hanjun Guo wrote:
> From: Graeme Gregory <graeme.gregory@linaro.org>
> 
> acpi_wakeup_address is used on x86 as the address bios jumps into
> when machine wakes up from suspend. As arm64 does not have such a
> bios this mechanism will be provided by other means. But the define
> is still required inside the acpi core.
> 
> Introduce a null stub for acpi_suspend_lowlevel as this is also
> required by core. This will be filled in when standards are
> defined for arm64 ACPI global power states.
> 
> Reviewed-by: Grant Likely <grant.likely@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h |   12 ++++++++++++
>  arch/arm64/kernel/acpi.c      |    7 +++++++
>  2 files changed, 19 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index e8581ea..44b617f 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -36,6 +36,18 @@ static inline bool acpi_has_cpu_in_madt(void)
>  	return 1;
>  }
>  
> +/* Low-level suspend routine.
> + *
> + * ACPI S-states for ARM64 have to be defined
> + * and approved before doing anything else, maybe
> + * we need update the ACPI spec, here we
> + * just introduce function and macro needed by
> + * ACPI core as IA64 did, and revisit them when
> + * the spec is ready.
> + */
> +extern int (*acpi_suspend_lowlevel)(void);
> +#define acpi_wakeup_address 0
> +
>  #endif /* CONFIG_ACPI */
>  
>  #endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index ac78e4e..f5a10b5 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -95,3 +95,10 @@ static int __init parse_acpi(char *arg)
>  	return 0;
>  }
>  early_param("acpi", parse_acpi);
> +
> +/*
> + * acpi_suspend_lowlevel() - save kernel state and suspend.
> + *
> + * TBD when ARM/ARM64 starts to support suspend...
> + */
> +int (*acpi_suspend_lowlevel)(void);

Shouldn't this should be intialised to NULL explicitly?

Thanks,
Mark.

Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Mark Rutland]

On Thu, Jul 24, 2014 at 02:00:16PM +0100, Hanjun Guo wrote:
> ACPI 5.1 only has two explicit methods to boot up SMP,
> PSCI and Parking protocol, but the Parking protocol is
> only suitable for ARMv7 now, so make PSCI as the only way
> for the SMP boot protocol before some updates for the
> ACPI spec or the Parking protocol spec.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h    |   21 +++++++++++++++
>  arch/arm64/include/asm/cpu_ops.h |    9 ++++++-
>  arch/arm64/include/asm/smp.h     |    2 +-
>  arch/arm64/kernel/acpi.c         |    9 +++++++
>  arch/arm64/kernel/cpu_ops.c      |   52 ++++++++++++++++++++++++++++++++++----
>  arch/arm64/kernel/smp.c          |   29 +++++++++++++++++++--
>  6 files changed, 113 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 5ce85f8..6240327 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -14,6 +14,27 @@
> 
>  /* Basic configuration for ACPI */
>  #ifdef CONFIG_ACPI
> +/*
> + * ACPI 5.1 only has two explicit methods to
> + * boot up SMP, PSCI and Parking protocol,
> + * but the Parking protocol is only defined
> + * for ARMv7 now, so make PSCI as the only
> + * way for the SMP boot protocol before some
> + * updates for the ACPI spec or the Parking
> + * protocol spec.
> + *
> + * This enum is intend to make the boot method
> + * scalable when above updates are happended,
> + * which NOT means to support all of them.
> + */
> +enum acpi_smp_boot_protocol {
> +       ACPI_SMP_BOOT_PSCI,
> +       ACPI_SMP_BOOT_PARKING_PROTOCOL,
> +       ACPI_SMP_BOOT_PROTOCOL_MAX
> +};
> +
> +enum acpi_smp_boot_protocol smp_boot_protocol(void);
> +
>  extern int acpi_disabled;
>  extern int acpi_noirq;
>  extern int acpi_pci_disabled;
> diff --git a/arch/arm64/include/asm/cpu_ops.h b/arch/arm64/include/asm/cpu_ops.h
> index d7b4b38..2a7c6fd 100644
> --- a/arch/arm64/include/asm/cpu_ops.h
> +++ b/arch/arm64/include/asm/cpu_ops.h
> @@ -61,7 +61,14 @@ struct cpu_operations {
>  };
> 
>  extern const struct cpu_operations *cpu_ops[NR_CPUS];
> -extern int __init cpu_read_ops(struct device_node *dn, int cpu);
> +extern int __init cpu_of_read_ops(struct device_node *dn, int cpu);
> +
> +#ifdef CONFIG_ACPI
> +extern int __init cpu_acpi_read_ops(int cpu);
> +#else
> +static inline int __init cpu_acpi_read_ops(int cpu) { return -ENODEV; }
> +#endif
> +
>  extern void __init cpu_read_bootcpu_ops(void);
> 
>  #endif /* ifndef __ASM_CPU_OPS_H */
> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> index a498f2c..a5cea56 100644
> --- a/arch/arm64/include/asm/smp.h
> +++ b/arch/arm64/include/asm/smp.h
> @@ -39,7 +39,7 @@ extern void show_ipi_list(struct seq_file *p, int prec);
>  extern void handle_IPI(int ipinr, struct pt_regs *regs);
> 
>  /*
> - * Setup the set of possible CPUs (via set_cpu_possible)
> + * Platform specific SMP operations
>   */
>  extern void smp_init_cpus(void);

While the originial comment is out of date, the new form is plain wrong.

Something like "Discover the set of possible CPUs and determine their
SMP operations" would be a better description of what's going on here.

> 
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index ff0f6a0..2af6662 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
>         return 0;
>  }
> 
> +/* Protocol to bring up secondary CPUs */
> +enum acpi_smp_boot_protocol smp_boot_protocol(void)
> +{
> +       if (acpi_psci_present)
> +               return ACPI_SMP_BOOT_PSCI;
> +       else
> +               return ACPI_SMP_BOOT_PARKING_PROTOCOL;
> +}
> +
>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
>  {
>         struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
> index d62d12f..4d9b3cf 100644
> --- a/arch/arm64/kernel/cpu_ops.c
> +++ b/arch/arm64/kernel/cpu_ops.c
> @@ -16,11 +16,13 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
> 
> -#include <asm/cpu_ops.h>
> -#include <asm/smp_plat.h>
>  #include <linux/errno.h>
>  #include <linux/of.h>
>  #include <linux/string.h>
> +#include <linux/acpi.h>
> +
> +#include <asm/cpu_ops.h>
> +#include <asm/smp_plat.h>

Was the header move just for consistency with other files, or is there
some ordering requirement here?

> 
>  extern const struct cpu_operations smp_spin_table_ops;
>  extern const struct cpu_operations cpu_psci_ops;
> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
>  /*
>   * Read a cpu's enable method from the device tree and record it in cpu_ops.
>   */
> -int __init cpu_read_ops(struct device_node *dn, int cpu)
> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
>  {
>         const char *enable_method = of_get_property(dn, "enable-method", NULL);
>         if (!enable_method) {
> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
>         return 0;
>  }
> 
> +#ifdef CONFIG_ACPI
> +/*
> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
> + */
> +int __init cpu_acpi_read_ops(int cpu)
> +{
> +       /*
> +        * For ACPI 5.1, only two kind of methods are provided,
> +        * Parking protocol and PSCI, but Parking protocol is
> +        * used on ARMv7 only, so make PSCI as the only method
> +        * for SMP initialization before the ACPI spec or Parking
> +        * protocol spec is updated.
> +        */

That comment is a little misleading. The parking protocol is _specified_
for ARMv7 only.

> +       switch (smp_boot_protocol()) {
> +       case ACPI_SMP_BOOT_PSCI:
> +               cpu_ops[cpu] = cpu_get_ops("psci");
> +               break;
> +       case ACPI_SMP_BOOT_PARKING_PROTOCOL:
> +       default:
> +               cpu_ops[cpu] = NULL;
> +               break;
> +       }
> +
> +       if (!cpu_ops[cpu]) {
> +               pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
> +                       cpu);
> +               return -EOPNOTSUPP;
> +       }

That's going to require changes as things get updated, and
"enable-method" is a term from DT rather than ACPI.

How about:

	"CPU%d: boot protocol unsupported or unknown\n".

Cheers,
Mark.

[PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Mark Rutland]

On Thu, Jul 24, 2014 at 02:00:16PM +0100, Hanjun Guo wrote:
> ACPI 5.1 only has two explicit methods to boot up SMP,
> PSCI and Parking protocol, but the Parking protocol is
> only suitable for ARMv7 now, so make PSCI as the only way
> for the SMP boot protocol before some updates for the
> ACPI spec or the Parking protocol spec.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h    |   21 +++++++++++++++
>  arch/arm64/include/asm/cpu_ops.h |    9 ++++++-
>  arch/arm64/include/asm/smp.h     |    2 +-
>  arch/arm64/kernel/acpi.c         |    9 +++++++
>  arch/arm64/kernel/cpu_ops.c      |   52 ++++++++++++++++++++++++++++++++++----
>  arch/arm64/kernel/smp.c          |   29 +++++++++++++++++++--
>  6 files changed, 113 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 5ce85f8..6240327 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -14,6 +14,27 @@
> 
>  /* Basic configuration for ACPI */
>  #ifdef CONFIG_ACPI
> +/*
> + * ACPI 5.1 only has two explicit methods to
> + * boot up SMP, PSCI and Parking protocol,
> + * but the Parking protocol is only defined
> + * for ARMv7 now, so make PSCI as the only
> + * way for the SMP boot protocol before some
> + * updates for the ACPI spec or the Parking
> + * protocol spec.
> + *
> + * This enum is intend to make the boot method
> + * scalable when above updates are happended,
> + * which NOT means to support all of them.
> + */
> +enum acpi_smp_boot_protocol {
> +       ACPI_SMP_BOOT_PSCI,
> +       ACPI_SMP_BOOT_PARKING_PROTOCOL,
> +       ACPI_SMP_BOOT_PROTOCOL_MAX
> +};
> +
> +enum acpi_smp_boot_protocol smp_boot_protocol(void);
> +
>  extern int acpi_disabled;
>  extern int acpi_noirq;
>  extern int acpi_pci_disabled;
> diff --git a/arch/arm64/include/asm/cpu_ops.h b/arch/arm64/include/asm/cpu_ops.h
> index d7b4b38..2a7c6fd 100644
> --- a/arch/arm64/include/asm/cpu_ops.h
> +++ b/arch/arm64/include/asm/cpu_ops.h
> @@ -61,7 +61,14 @@ struct cpu_operations {
>  };
> 
>  extern const struct cpu_operations *cpu_ops[NR_CPUS];
> -extern int __init cpu_read_ops(struct device_node *dn, int cpu);
> +extern int __init cpu_of_read_ops(struct device_node *dn, int cpu);
> +
> +#ifdef CONFIG_ACPI
> +extern int __init cpu_acpi_read_ops(int cpu);
> +#else
> +static inline int __init cpu_acpi_read_ops(int cpu) { return -ENODEV; }
> +#endif
> +
>  extern void __init cpu_read_bootcpu_ops(void);
> 
>  #endif /* ifndef __ASM_CPU_OPS_H */
> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> index a498f2c..a5cea56 100644
> --- a/arch/arm64/include/asm/smp.h
> +++ b/arch/arm64/include/asm/smp.h
> @@ -39,7 +39,7 @@ extern void show_ipi_list(struct seq_file *p, int prec);
>  extern void handle_IPI(int ipinr, struct pt_regs *regs);
> 
>  /*
> - * Setup the set of possible CPUs (via set_cpu_possible)
> + * Platform specific SMP operations
>   */
>  extern void smp_init_cpus(void);

While the originial comment is out of date, the new form is plain wrong.

Something like "Discover the set of possible CPUs and determine their
SMP operations" would be a better description of what's going on here.

> 
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index ff0f6a0..2af6662 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
>         return 0;
>  }
> 
> +/* Protocol to bring up secondary CPUs */
> +enum acpi_smp_boot_protocol smp_boot_protocol(void)
> +{
> +       if (acpi_psci_present)
> +               return ACPI_SMP_BOOT_PSCI;
> +       else
> +               return ACPI_SMP_BOOT_PARKING_PROTOCOL;
> +}
> +
>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
>  {
>         struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
> index d62d12f..4d9b3cf 100644
> --- a/arch/arm64/kernel/cpu_ops.c
> +++ b/arch/arm64/kernel/cpu_ops.c
> @@ -16,11 +16,13 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
> 
> -#include <asm/cpu_ops.h>
> -#include <asm/smp_plat.h>
>  #include <linux/errno.h>
>  #include <linux/of.h>
>  #include <linux/string.h>
> +#include <linux/acpi.h>
> +
> +#include <asm/cpu_ops.h>
> +#include <asm/smp_plat.h>

Was the header move just for consistency with other files, or is there
some ordering requirement here?

> 
>  extern const struct cpu_operations smp_spin_table_ops;
>  extern const struct cpu_operations cpu_psci_ops;
> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
>  /*
>   * Read a cpu's enable method from the device tree and record it in cpu_ops.
>   */
> -int __init cpu_read_ops(struct device_node *dn, int cpu)
> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
>  {
>         const char *enable_method = of_get_property(dn, "enable-method", NULL);
>         if (!enable_method) {
> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
>         return 0;
>  }
> 
> +#ifdef CONFIG_ACPI
> +/*
> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
> + */
> +int __init cpu_acpi_read_ops(int cpu)
> +{
> +       /*
> +        * For ACPI 5.1, only two kind of methods are provided,
> +        * Parking protocol and PSCI, but Parking protocol is
> +        * used on ARMv7 only, so make PSCI as the only method
> +        * for SMP initialization before the ACPI spec or Parking
> +        * protocol spec is updated.
> +        */

That comment is a little misleading. The parking protocol is _specified_
for ARMv7 only.

> +       switch (smp_boot_protocol()) {
> +       case ACPI_SMP_BOOT_PSCI:
> +               cpu_ops[cpu] = cpu_get_ops("psci");
> +               break;
> +       case ACPI_SMP_BOOT_PARKING_PROTOCOL:
> +       default:
> +               cpu_ops[cpu] = NULL;
> +               break;
> +       }
> +
> +       if (!cpu_ops[cpu]) {
> +               pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
> +                       cpu);
> +               return -EOPNOTSUPP;
> +       }

That's going to require changes as things get updated, and
"enable-method" is a term from DT rather than ACPI.

How about:

	"CPU%d: boot protocol unsupported or unknown\n".

Cheers,
Mark.

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Randy Dunlap]

On 07/24/2014 06:00 AM, Hanjun Guo wrote:
> From: Graeme Gregory <graeme.gregory@linaro.org>
> 
> Add documentation for the guidelines of how to use ACPI
> on ARM64.
> 
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 240 insertions(+)
>  create mode 100644 Documentation/arm64/arm-acpi.txt
> 
> diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> new file mode 100644
> index 0000000..12cd550
> --- /dev/null
> +++ b/Documentation/arm64/arm-acpi.txt
> @@ -0,0 +1,240 @@
> +ACPI on ARMv8 Servers
> +---------------------
> +
> +ACPI will be used for ARMv8 general purpose servers designed to follow
> +the SBSA specification (currently available to people with an ARM login at
> +http://silver.arm.com)

                    .com).

> +
> +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> +which is available at <http://www.uefi.org/acpi/specs>.
> +
> +If the machine does not meet these requirements then it is likely that Device
> +Tree (DT) is more suitable for the hardware.
> +
> +Relationship with Device Tree
> +-----------------------------
> +
> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> +exclusive with DT support at compile time.
> +
> +At boot time the kernel will only use one description method depending on
> +parameters passed from the bootloader.
> +
> +Regardless of whether DT or ACPI is used, the kernel must always be capable
> +of booting with either scheme.
> +
> +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.
> +
> +Booting using ACPI tables
> +-------------------------
> +
> +Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
> +is via the UEFI system configuration table.
> +
> +The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
> +RSDP table (the table with the ACPI signature "RSD PTR ").
> +
> +The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
> +
> +Processing of ACPI tables may be disabled by passing acpi=off on the kernel
> +command line.
> +
> +DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They

             XSDT;

> +only allow for 32bit addresses.

                  32-bit

> +
> +DO NOT use the 32-bit address fields in the FADT, they are deprecated, the

                                               FADT; they are deprecated. The

> +64-bit alternatives MUST be used.
> +
> +The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
> +and GTDT. If PCI is used the MCFG table MUST also be present.
> +
> +ACPI Detection
> +--------------
> +
> +Drivers should determine their probe() type by checking for ACPI_HANDLE,
> +or .of_node, or other information in the device structure. This is
> +detailed further in the "Driver Recomendations" section.

                                   Recommendations

> +
> +If the presence of ACPI needs to be detected at runtime, then check the value
> +of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.

                     If CONFIG_ACPI is not set, acpi_disabled will always be 1.

> +
> +Device Enumeration
> +------------------
> +
> +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> +These are far simpler than the information provided via Device Tree. Drivers
> +should take into account this simplicity and work with sensible defaults.
> +
> +On no account should a Device Tree attempt to be replicated in ASL using such
> +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
> +
> +Common _DSD bindings should be submitted to ASWG to be included in the
> +document :-
> +
> +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
> +
> +TODO: Clarification and examples from Juno implementation.
> +
> +Programmable Power Control Resources
> +------------------------------------
> +
> +Programmable power control resources include such resources as voltage/current
> +providers (regulators) and clock sources.
> +
> +For power control of these resources they should be represented with Power
> +Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
> +enabling/disabling of resources as they are needed.
> +
> +There exists in the ACPI 5.1 specification no standard binding for these objects
> +to enable programmable levels or rates so this should be avoid if possible and

                                                            avoided

> +the resources set to appropriate level by the firmware. If this is not possible

                                    levels

> +then any manipulation should be abstracted in ASL.
> +
> +Each device in ACPI has D-states and these can be controlled through
> +the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
> +
> +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 organise that it is allocated/enabled using the _PS0 method.
> +
> +Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
> +in the _PS3 method.
> +
> +Such code in _PS? methods will of course be very platform specific but
> +should allow the driver to operate the device without special non standard

                                                                 non-standard

> +values being read from ASL. Further, abstracting the use of these resources
> +allows hardware revisions without requiring updates to the kernel.
> +
> +TODO: Clarification and examples from Juno implementation.
> +
> +Clocks
> +------
> +
> +Like clocks that are part of the power resources there is no standard way
> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
> +described in DT.
> +
> +Devices affected by this include things like UARTs, SoC driven LCD displays,
> +etc.
> +
> +The firmware for example UEFI should initialise these clocks to fixed working

                (for example, UEFI)

> +values before the kernel is executed. If a driver requires to know rates of
> +clocks set by firmware then they can be passed to kernel using _DSD.
> +
> +example :-
> +
> +Device (CLK0) {
> +	...
> +
> +	Name (_DSD, Package() {
> +		ToUUID("XXXXX"),
> +		Package() {
> +			Package(2) {"#clock-cells", 0},
> +			Package(2) {"clock-frequency", "10000"}
> +		}
> +	})
> +
> +	...
> +}
> +
> +Device (USR1) {
> +	...
> +
> +	Name (_DSD, Package() {
> +		ToUUID("XXXXX"),
> +		Package() {
> +			Package(2) {"clocks", Package() {1, ^CLK0}}},
> +		}
> +	})
> +
> +	...
> +}
> +			
> +Driver Recommendations
> +----------------------
> +
> +DO NOT remove any FDT handling when adding ACPI support for a driver, different

                                                                 driver. Different

> +systems may use the same device.
> +
> +DO try and keep complex sections of ACPI and DT functionality seperate. This

                                                                 separate.

> +may mean a patch to break out some complex DT to another function before
> +the patch to add ACPI. This may happen in other functions but is most likely
> +in probe function. This gives a clearer flow of data for reviewing driver
> +source.
> +
> +probe() :-
> +
> +TODO: replace this with a specific real example from Juno?
> +
> +static int device_probe_dt(struct platform_device *pdev)
> +{
> +	/* DT specific functionality */
> +	...
> +}
> +
> +static int device_probe_acpi(struct platform_device *pdev)
> +{
> +	/* ACPI specific functionality */
> +	...
> +}
> +
> +static int device_probe(stuct platform_device *pdev)
> +{
> +	...
> +	acpi_handle handle = ACPI_HANDLE(&pdev->dev);
> +	struct device_node node = pdev->dev.of_node;
> +	...
> +
> +	if (node)
> +		ret = device_probe_dt(pdev);
> +	else if (handle)
> +		ret = device_probe_acpi(pdev);
> +	else
> +		/* other initialisation */
> +		...
> +	/* Continue with any generic probe operations */
> +	...
> +}
> +
> +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
> +the different names the driver is probed for, both from DT and from ACPI.
> +
> +module device tables :-
> +
> +static struct of_device_id virtio_mmio_match[] = {
> +        { .compatible = "virtio,mmio", },
> +        {},
> +};
> +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
> +
> +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
> +        { "LNRO0005", },
> +        { }
> +};
> +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
> +
> +TODO: Add any other helpful rules that develop from Juno ACPI work.
> +
> +ASWG
> +----
> +
> +The following areas are not yet well defined for ARM in the current ACPI
> +specification and are expected to be worked through in the UEFI ACPI
> +Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
> +Participation in this group is open to all UEFI members.
> +
> +	- ACPI based CPU topology
> +	- ACPI based Power management
> +	- CPU idle control based on PSCI
> +	- CPU performance control (CPPC)
> +
> +No code shall be accepted into the kernel unless it complies with the released
> +standards from UEFI ASWG. If there are features missing from ACPI to make it
> +function on a platform ECRs should be submitted to ASWG and go through the

            on a platform, ECRs

> +approval process.
> 


-- 
~Randy

[PATCH 19/19] Documentation: ACPI for ARM64

[Randy Dunlap]

On 07/24/2014 06:00 AM, Hanjun Guo wrote:
> From: Graeme Gregory <graeme.gregory@linaro.org>
> 
> Add documentation for the guidelines of how to use ACPI
> on ARM64.
> 
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 240 insertions(+)
>  create mode 100644 Documentation/arm64/arm-acpi.txt
> 
> diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> new file mode 100644
> index 0000000..12cd550
> --- /dev/null
> +++ b/Documentation/arm64/arm-acpi.txt
> @@ -0,0 +1,240 @@
> +ACPI on ARMv8 Servers
> +---------------------
> +
> +ACPI will be used for ARMv8 general purpose servers designed to follow
> +the SBSA specification (currently available to people with an ARM login at
> +http://silver.arm.com)

                    .com).

> +
> +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> +which is available at <http://www.uefi.org/acpi/specs>.
> +
> +If the machine does not meet these requirements then it is likely that Device
> +Tree (DT) is more suitable for the hardware.
> +
> +Relationship with Device Tree
> +-----------------------------
> +
> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> +exclusive with DT support at compile time.
> +
> +At boot time the kernel will only use one description method depending on
> +parameters passed from the bootloader.
> +
> +Regardless of whether DT or ACPI is used, the kernel must always be capable
> +of booting with either scheme.
> +
> +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.
> +
> +Booting using ACPI tables
> +-------------------------
> +
> +Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
> +is via the UEFI system configuration table.
> +
> +The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
> +RSDP table (the table with the ACPI signature "RSD PTR ").
> +
> +The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
> +
> +Processing of ACPI tables may be disabled by passing acpi=off on the kernel
> +command line.
> +
> +DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They

             XSDT;

> +only allow for 32bit addresses.

                  32-bit

> +
> +DO NOT use the 32-bit address fields in the FADT, they are deprecated, the

                                               FADT; they are deprecated. The

> +64-bit alternatives MUST be used.
> +
> +The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
> +and GTDT. If PCI is used the MCFG table MUST also be present.
> +
> +ACPI Detection
> +--------------
> +
> +Drivers should determine their probe() type by checking for ACPI_HANDLE,
> +or .of_node, or other information in the device structure. This is
> +detailed further in the "Driver Recomendations" section.

                                   Recommendations

> +
> +If the presence of ACPI needs to be detected at runtime, then check the value
> +of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.

                     If CONFIG_ACPI is not set, acpi_disabled will always be 1.

> +
> +Device Enumeration
> +------------------
> +
> +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> +These are far simpler than the information provided via Device Tree. Drivers
> +should take into account this simplicity and work with sensible defaults.
> +
> +On no account should a Device Tree attempt to be replicated in ASL using such
> +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
> +
> +Common _DSD bindings should be submitted to ASWG to be included in the
> +document :-
> +
> +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
> +
> +TODO: Clarification and examples from Juno implementation.
> +
> +Programmable Power Control Resources
> +------------------------------------
> +
> +Programmable power control resources include such resources as voltage/current
> +providers (regulators) and clock sources.
> +
> +For power control of these resources they should be represented with Power
> +Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
> +enabling/disabling of resources as they are needed.
> +
> +There exists in the ACPI 5.1 specification no standard binding for these objects
> +to enable programmable levels or rates so this should be avoid if possible and

                                                            avoided

> +the resources set to appropriate level by the firmware. If this is not possible

                                    levels

> +then any manipulation should be abstracted in ASL.
> +
> +Each device in ACPI has D-states and these can be controlled through
> +the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
> +
> +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 organise that it is allocated/enabled using the _PS0 method.
> +
> +Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
> +in the _PS3 method.
> +
> +Such code in _PS? methods will of course be very platform specific but
> +should allow the driver to operate the device without special non standard

                                                                 non-standard

> +values being read from ASL. Further, abstracting the use of these resources
> +allows hardware revisions without requiring updates to the kernel.
> +
> +TODO: Clarification and examples from Juno implementation.
> +
> +Clocks
> +------
> +
> +Like clocks that are part of the power resources there is no standard way
> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
> +described in DT.
> +
> +Devices affected by this include things like UARTs, SoC driven LCD displays,
> +etc.
> +
> +The firmware for example UEFI should initialise these clocks to fixed working

                (for example, UEFI)

> +values before the kernel is executed. If a driver requires to know rates of
> +clocks set by firmware then they can be passed to kernel using _DSD.
> +
> +example :-
> +
> +Device (CLK0) {
> +	...
> +
> +	Name (_DSD, Package() {
> +		ToUUID("XXXXX"),
> +		Package() {
> +			Package(2) {"#clock-cells", 0},
> +			Package(2) {"clock-frequency", "10000"}
> +		}
> +	})
> +
> +	...
> +}
> +
> +Device (USR1) {
> +	...
> +
> +	Name (_DSD, Package() {
> +		ToUUID("XXXXX"),
> +		Package() {
> +			Package(2) {"clocks", Package() {1, ^CLK0}}},
> +		}
> +	})
> +
> +	...
> +}
> +			
> +Driver Recommendations
> +----------------------
> +
> +DO NOT remove any FDT handling when adding ACPI support for a driver, different

                                                                 driver. Different

> +systems may use the same device.
> +
> +DO try and keep complex sections of ACPI and DT functionality seperate. This

                                                                 separate.

> +may mean a patch to break out some complex DT to another function before
> +the patch to add ACPI. This may happen in other functions but is most likely
> +in probe function. This gives a clearer flow of data for reviewing driver
> +source.
> +
> +probe() :-
> +
> +TODO: replace this with a specific real example from Juno?
> +
> +static int device_probe_dt(struct platform_device *pdev)
> +{
> +	/* DT specific functionality */
> +	...
> +}
> +
> +static int device_probe_acpi(struct platform_device *pdev)
> +{
> +	/* ACPI specific functionality */
> +	...
> +}
> +
> +static int device_probe(stuct platform_device *pdev)
> +{
> +	...
> +	acpi_handle handle = ACPI_HANDLE(&pdev->dev);
> +	struct device_node node = pdev->dev.of_node;
> +	...
> +
> +	if (node)
> +		ret = device_probe_dt(pdev);
> +	else if (handle)
> +		ret = device_probe_acpi(pdev);
> +	else
> +		/* other initialisation */
> +		...
> +	/* Continue with any generic probe operations */
> +	...
> +}
> +
> +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
> +the different names the driver is probed for, both from DT and from ACPI.
> +
> +module device tables :-
> +
> +static struct of_device_id virtio_mmio_match[] = {
> +        { .compatible = "virtio,mmio", },
> +        {},
> +};
> +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
> +
> +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
> +        { "LNRO0005", },
> +        { }
> +};
> +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
> +
> +TODO: Add any other helpful rules that develop from Juno ACPI work.
> +
> +ASWG
> +----
> +
> +The following areas are not yet well defined for ARM in the current ACPI
> +specification and are expected to be worked through in the UEFI ACPI
> +Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
> +Participation in this group is open to all UEFI members.
> +
> +	- ACPI based CPU topology
> +	- ACPI based Power management
> +	- CPU idle control based on PSCI
> +	- CPU performance control (CPPC)
> +
> +No code shall be accepted into the kernel unless it complies with the released
> +standards from UEFI ASWG. If there are features missing from ACPI to make it
> +function on a platform ECRs should be submitted to ASWG and go through the

            on a platform, ECRs

> +approval process.
> 


-- 
~Randy

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Randy Dunlap]

On 07/24/2014 02:16 PM, Naresh Bhat wrote:
> 
> On 24 July 2014 18:30, Hanjun Guo <hanjun.guo@linaro.org <mailto:hanjun.guo@linaro.org>> wrote:
> 
>     From: Graeme Gregory <graeme.gregory@linaro.org <mailto:graeme.gregory@linaro.org>>
> 
>     Add documentation for the guidelines of how to use ACPI
>     on ARM64.
> 
>     Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org <mailto:graeme.gregory@linaro.org>>
>     Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org <mailto:hanjun.guo@linaro.org>>
>     ---
>      Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>      1 file changed, 240 insertions(+)
>      create mode 100644 Documentation/arm64/arm-acpi.txt
> 
>     diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
>     new file mode 100644
>     index 0000000..12cd550
>     --- /dev/null
>     +++ b/Documentation/arm64/arm-acpi.txt
>     @@ -0,0 +1,240 @@
>     +ACPI on ARMv8 Servers
>     +---------------------
>     +
>     +ACPI will be used for ARMv8 general purpose servers designed to follow
>     +the SBSA specification (currently available to people with an ARM login at
>     +http://silver.arm.com)
>     +
>     +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
>     +which is available at <http://www.uefi.org/acpi/specs>.
>     +
>     +If the machine does not meet these requirements then it is likely that Device
>     +Tree (DT) is more suitable for the hardware.
>     +
>     +Relationship with Device Tree
>     +-----------------------------
>     +
>     +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>     +exclusive with DT support at compile time.
>     +
>     +At boot time the kernel will only use one description method depending on
>     +parameters passed from the bootloader.
>     +
>     +Regardless of whether DT or ACPI is used, the kernel must always be capable
>     +of booting with either scheme.
>     +
>     +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.
>     +
>     +Booting using ACPI tables
>     +-------------------------
>     +
>     +Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
>     +is via the UEFI system configuration table.
>     +
>     +The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
>     +RSDP table (the table with the ACPI signature "RSD PTR ").
>     +
>     +The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
>     +
>     +Processing of ACPI tables may be disabled by passing acpi=off on the kernel
>     +command line.
>     +
>     +DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
>     +only allow for 32bit addresses.
>     +
>     +DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
>     +64-bit alternatives MUST be used.
>     +
>     +The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
>     +and GTDT. If PCI is used the MCFG table MUST also be present.
>     +
>     +ACPI Detection
>     +--------------
>     +
>     +Drivers should determine their probe() type by checking for ACPI_HANDLE,
>     +or .of_node, or other information in the device structure. This is
>     +detailed further in the "Driver Recomendations" section.
>     +
>     +If the presence of ACPI needs to be detected at runtime, then check the value
>     +of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
>     +
>     +Device Enumeration
>     +------------------
>     +
>     +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> 
> 
> recognized

Yeah, I saw all of these also, but we accept British or American spelling of these words.

>  
> 
>     +These are far simpler than the information provided via Device Tree. Drivers
>     +should take into account this simplicity and work with sensible defaults.
>     +
>     +On no account should a Device Tree attempt to be replicated in ASL using such
>     +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
>     +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
>     +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
>     +
>     +Common _DSD bindings should be submitted to ASWG to be included in the
>     +document :-
>     +
>     +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
>     +
>     +TODO: Clarification and examples from Juno implementation.
>     +
>     +Programmable Power Control Resources
>     +------------------------------------
>     +
>     +Programmable power control resources include such resources as voltage/current
>     +providers (regulators) and clock sources.
>     +
>     +For power control of these resources they should be represented with Power
>     +Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
>     +enabling/disabling of resources as they are needed.
>     +
>     +There exists in the ACPI 5.1 specification no standard binding for these objects
>     +to enable programmable levels or rates so this should be avoid if possible and
>     +the resources set to appropriate level by the firmware. If this is not possible
>     +then any manipulation should be abstracted in ASL.
>     +
>     +Each device in ACPI has D-states and these can be controlled through
>     +the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
>     +
>     +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 organise that it is allocated/enabled using the _PS0 method.
> 
>  
> organize
> 
>     +
>     +Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
>     +in the _PS3 method.
>     +
>     +Such code in _PS? methods will of course be very platform specific but
>     +should allow the driver to operate the device without special non standard
>     +values being read from ASL. Further, abstracting the use of these resources
>     +allows hardware revisions without requiring updates to the kernel.
>     +
>     +TODO: Clarification and examples from Juno implementation.
>     +
>     +Clocks
>     +------
>     +
>     +Like clocks that are part of the power resources there is no standard way
>     +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
>     +described in DT.
>     +
>     +Devices affected by this include things like UARTs, SoC driven LCD displays,
>     +etc.
>     +
>     +The firmware for example UEFI should initialise these clocks to fixed working
> 
> 
> initialize
>  
> 
>     +values before the kernel is executed. If a driver requires to know rates of
>     +clocks set by firmware then they can be passed to kernel using _DSD.
>     +
>     +example :-
>     +
>     +Device (CLK0) {
>     +       ...
>     +
>     +       Name (_DSD, Package() {
>     +               ToUUID("XXXXX"),
>     +               Package() {
>     +                       Package(2) {"#clock-cells", 0},
>     +                       Package(2) {"clock-frequency", "10000"}
>     +               }
>     +       })
>     +
>     +       ...
>     +}
>     +
>     +Device (USR1) {
>     +       ...
>     +
>     +       Name (_DSD, Package() {
>     +               ToUUID("XXXXX"),
>     +               Package() {
>     +                       Package(2) {"clocks", Package() {1, ^CLK0}}},
>     +               }
>     +       })
>     +
>     +       ...
>     +}
>     +
>     +Driver Recommendations
>     +----------------------
>     +
>     +DO NOT remove any FDT handling when adding ACPI support for a driver, different
>     +systems may use the same device.
>     +
>     +DO try and keep complex sections of ACPI and DT functionality seperate. This
> 
> 
> separate
>  
> 
>     +may mean a patch to break out some complex DT to another function before
>     +the patch to add ACPI. This may happen in other functions but is most likely
>     +in probe function. This gives a clearer flow of data for reviewing driver
>     +source.
>     +
>     +probe() :-
>     +
>     +TODO: replace this with a specific real example from Juno?
>     +
>     +static int device_probe_dt(struct platform_device *pdev)
>     +{
>     +       /* DT specific functionality */
>     +       ...
>     +}
>     +
>     +static int device_probe_acpi(struct platform_device *pdev)
>     +{
>     +       /* ACPI specific functionality */
>     +       ...
>     +}
>     +
>     +static int device_probe(stuct platform_device *pdev)
>     +{
>     +       ...
>     +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
>     +       struct device_node node = pdev->dev.of_node;
>     +       ...
>     +
>     +       if (node)
>     +               ret = device_probe_dt(pdev);
>     +       else if (handle)
>     +               ret = device_probe_acpi(pdev);
>     +       else
>     +               /* other initialisation */
> 
> 
> initialization
>  
> 
>     +               ...
>     +       /* Continue with any generic probe operations */
>     +       ...
>     +}
>     +
>     +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
>     +the different names the driver is probed for, both from DT and from ACPI.
>     +
>     +module device tables :-
>     +
>     +static struct of_device_id virtio_mmio_match[] = {
>     +        { .compatible = "virtio,mmio", },
>     +        {},
>     +};
>     +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
>     +
>     +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
>     +        { "LNRO0005", },
>     +        { }
>     +};
>     +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
>     +
>     +TODO: Add any other helpful rules that develop from Juno ACPI work.
>     +
>     +ASWG
>     +----
>     +
>     +The following areas are not yet well defined for ARM in the current ACPI
>     +specification and are expected to be worked through in the UEFI ACPI
>     +Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
>     +Participation in this group is open to all UEFI members.
>     +
>     +       - ACPI based CPU topology
>     +       - ACPI based Power management
>     +       - CPU idle control based on PSCI
>     +       - CPU performance control (CPPC)
>     +
>     +No code shall be accepted into the kernel unless it complies with the released
>     +standards from UEFI ASWG. If there are features missing from ACPI to make it
>     +function on a platform ECRs should be submitted to ASWG and go through the
>     +approval process.
>     --
>     1.7.9.5
> 
> 


-- 
~Randy

[PATCH 19/19] Documentation: ACPI for ARM64

[Randy Dunlap]

On 07/24/2014 02:16 PM, Naresh Bhat wrote:
> 
> On 24 July 2014 18:30, Hanjun Guo <hanjun.guo at linaro.org <mailto:hanjun.guo@linaro.org>> wrote:
> 
>     From: Graeme Gregory <graeme.gregory at linaro.org <mailto:graeme.gregory@linaro.org>>
> 
>     Add documentation for the guidelines of how to use ACPI
>     on ARM64.
> 
>     Signed-off-by: Graeme Gregory <graeme.gregory at linaro.org <mailto:graeme.gregory@linaro.org>>
>     Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org <mailto:hanjun.guo@linaro.org>>
>     ---
>      Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>      1 file changed, 240 insertions(+)
>      create mode 100644 Documentation/arm64/arm-acpi.txt
> 
>     diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
>     new file mode 100644
>     index 0000000..12cd550
>     --- /dev/null
>     +++ b/Documentation/arm64/arm-acpi.txt
>     @@ -0,0 +1,240 @@
>     +ACPI on ARMv8 Servers
>     +---------------------
>     +
>     +ACPI will be used for ARMv8 general purpose servers designed to follow
>     +the SBSA specification (currently available to people with an ARM login at
>     +http://silver.arm.com)
>     +
>     +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
>     +which is available at <http://www.uefi.org/acpi/specs>.
>     +
>     +If the machine does not meet these requirements then it is likely that Device
>     +Tree (DT) is more suitable for the hardware.
>     +
>     +Relationship with Device Tree
>     +-----------------------------
>     +
>     +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>     +exclusive with DT support at compile time.
>     +
>     +At boot time the kernel will only use one description method depending on
>     +parameters passed from the bootloader.
>     +
>     +Regardless of whether DT or ACPI is used, the kernel must always be capable
>     +of booting with either scheme.
>     +
>     +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.
>     +
>     +Booting using ACPI tables
>     +-------------------------
>     +
>     +Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
>     +is via the UEFI system configuration table.
>     +
>     +The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
>     +RSDP table (the table with the ACPI signature "RSD PTR ").
>     +
>     +The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
>     +
>     +Processing of ACPI tables may be disabled by passing acpi=off on the kernel
>     +command line.
>     +
>     +DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
>     +only allow for 32bit addresses.
>     +
>     +DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
>     +64-bit alternatives MUST be used.
>     +
>     +The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
>     +and GTDT. If PCI is used the MCFG table MUST also be present.
>     +
>     +ACPI Detection
>     +--------------
>     +
>     +Drivers should determine their probe() type by checking for ACPI_HANDLE,
>     +or .of_node, or other information in the device structure. This is
>     +detailed further in the "Driver Recomendations" section.
>     +
>     +If the presence of ACPI needs to be detected at runtime, then check the value
>     +of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
>     +
>     +Device Enumeration
>     +------------------
>     +
>     +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> 
> 
> recognized

Yeah, I saw all of these also, but we accept British or American spelling of these words.

>  
> 
>     +These are far simpler than the information provided via Device Tree. Drivers
>     +should take into account this simplicity and work with sensible defaults.
>     +
>     +On no account should a Device Tree attempt to be replicated in ASL using such
>     +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
>     +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
>     +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
>     +
>     +Common _DSD bindings should be submitted to ASWG to be included in the
>     +document :-
>     +
>     +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
>     +
>     +TODO: Clarification and examples from Juno implementation.
>     +
>     +Programmable Power Control Resources
>     +------------------------------------
>     +
>     +Programmable power control resources include such resources as voltage/current
>     +providers (regulators) and clock sources.
>     +
>     +For power control of these resources they should be represented with Power
>     +Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
>     +enabling/disabling of resources as they are needed.
>     +
>     +There exists in the ACPI 5.1 specification no standard binding for these objects
>     +to enable programmable levels or rates so this should be avoid if possible and
>     +the resources set to appropriate level by the firmware. If this is not possible
>     +then any manipulation should be abstracted in ASL.
>     +
>     +Each device in ACPI has D-states and these can be controlled through
>     +the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
>     +
>     +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 organise that it is allocated/enabled using the _PS0 method.
> 
>  
> organize
> 
>     +
>     +Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
>     +in the _PS3 method.
>     +
>     +Such code in _PS? methods will of course be very platform specific but
>     +should allow the driver to operate the device without special non standard
>     +values being read from ASL. Further, abstracting the use of these resources
>     +allows hardware revisions without requiring updates to the kernel.
>     +
>     +TODO: Clarification and examples from Juno implementation.
>     +
>     +Clocks
>     +------
>     +
>     +Like clocks that are part of the power resources there is no standard way
>     +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
>     +described in DT.
>     +
>     +Devices affected by this include things like UARTs, SoC driven LCD displays,
>     +etc.
>     +
>     +The firmware for example UEFI should initialise these clocks to fixed working
> 
> 
> initialize
>  
> 
>     +values before the kernel is executed. If a driver requires to know rates of
>     +clocks set by firmware then they can be passed to kernel using _DSD.
>     +
>     +example :-
>     +
>     +Device (CLK0) {
>     +       ...
>     +
>     +       Name (_DSD, Package() {
>     +               ToUUID("XXXXX"),
>     +               Package() {
>     +                       Package(2) {"#clock-cells", 0},
>     +                       Package(2) {"clock-frequency", "10000"}
>     +               }
>     +       })
>     +
>     +       ...
>     +}
>     +
>     +Device (USR1) {
>     +       ...
>     +
>     +       Name (_DSD, Package() {
>     +               ToUUID("XXXXX"),
>     +               Package() {
>     +                       Package(2) {"clocks", Package() {1, ^CLK0}}},
>     +               }
>     +       })
>     +
>     +       ...
>     +}
>     +
>     +Driver Recommendations
>     +----------------------
>     +
>     +DO NOT remove any FDT handling when adding ACPI support for a driver, different
>     +systems may use the same device.
>     +
>     +DO try and keep complex sections of ACPI and DT functionality seperate. This
> 
> 
> separate
>  
> 
>     +may mean a patch to break out some complex DT to another function before
>     +the patch to add ACPI. This may happen in other functions but is most likely
>     +in probe function. This gives a clearer flow of data for reviewing driver
>     +source.
>     +
>     +probe() :-
>     +
>     +TODO: replace this with a specific real example from Juno?
>     +
>     +static int device_probe_dt(struct platform_device *pdev)
>     +{
>     +       /* DT specific functionality */
>     +       ...
>     +}
>     +
>     +static int device_probe_acpi(struct platform_device *pdev)
>     +{
>     +       /* ACPI specific functionality */
>     +       ...
>     +}
>     +
>     +static int device_probe(stuct platform_device *pdev)
>     +{
>     +       ...
>     +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
>     +       struct device_node node = pdev->dev.of_node;
>     +       ...
>     +
>     +       if (node)
>     +               ret = device_probe_dt(pdev);
>     +       else if (handle)
>     +               ret = device_probe_acpi(pdev);
>     +       else
>     +               /* other initialisation */
> 
> 
> initialization
>  
> 
>     +               ...
>     +       /* Continue with any generic probe operations */
>     +       ...
>     +}
>     +
>     +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
>     +the different names the driver is probed for, both from DT and from ACPI.
>     +
>     +module device tables :-
>     +
>     +static struct of_device_id virtio_mmio_match[] = {
>     +        { .compatible = "virtio,mmio", },
>     +        {},
>     +};
>     +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
>     +
>     +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
>     +        { "LNRO0005", },
>     +        { }
>     +};
>     +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
>     +
>     +TODO: Add any other helpful rules that develop from Juno ACPI work.
>     +
>     +ASWG
>     +----
>     +
>     +The following areas are not yet well defined for ARM in the current ACPI
>     +specification and are expected to be worked through in the UEFI ACPI
>     +Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
>     +Participation in this group is open to all UEFI members.
>     +
>     +       - ACPI based CPU topology
>     +       - ACPI based Power management
>     +       - CPU idle control based on PSCI
>     +       - CPU performance control (CPPC)
>     +
>     +No code shall be accepted into the kernel unless it complies with the released
>     +standards from UEFI ASWG. If there are features missing from ACPI to make it
>     +function on a platform ECRs should be submitted to ASWG and go through the
>     +approval process.
>     --
>     1.7.9.5
> 
> 


-- 
~Randy

Re: [PATCH 05/19] ARM64 / ACPI: Make PCI optional for ACPI on ARM64

[Naresh Bhat]

On 24 July 2014 18:30, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>
> As PCI for ARM64 is not ready, so introduce some stub functions
> to make PCI optional for ACPI, and make ACPI core run without
> CONFIG_PCI on ARM64.
>
> Since ACPI on X86 and IA64 depends on PCI and this patch only makes
> PCI optinal for ARM64, it will not break anything on X86 and IA64.


optional

>
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  arch/arm64/include/asm/pci.h |   11 +++++++++++
>  drivers/acpi/Makefile        |    2 +-
>  drivers/acpi/internal.h      |    5 +++++
>  include/linux/pci.h          |   37 +++++++++++++++++++++++++++----------
>  4 files changed, 44 insertions(+), 11 deletions(-)
>  create mode 100644 arch/arm64/include/asm/pci.h
>
> diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> new file mode 100644
> index 0000000..250cd24
> --- /dev/null
> +++ b/arch/arm64/include/asm/pci.h
> @@ -0,0 +1,11 @@
> +#ifndef __ASM_PCI_H
> +#define __ASM_PCI_H
> +#ifdef __KERNEL__
> +
> +/*
> + * PCI address space differs from physical memory address space
> + */
> +#define PCI_DMA_BUS_IS_PHYS    (0)
> +
> +#endif  /* __KERNEL__ */
> +#endif  /* __ASM_PCI_H */
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 505d4d7..8e9bbe6 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -39,7 +39,7 @@ acpi-y                                += processor_core.o
>  acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
>  acpi-y                         += ec.o
>  acpi-$(CONFIG_ACPI_DOCK)       += dock.o
> -acpi-y                         += pci_root.o pci_link.o pci_irq.o
> +acpi-$(CONFIG_PCI)             += pci_root.o pci_link.o pci_irq.o
>  acpi-y                         += acpi_lpss.o
>  acpi-y                         += acpi_platform.o
>  acpi-y                         += acpi_pnp.o
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 4c5cf77..e1e6487 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -26,8 +26,13 @@
>  acpi_status acpi_os_initialize1(void);
>  int init_acpi_device_notify(void);
>  int acpi_scan_init(void);
> +#ifdef CONFIG_PCI
>  void acpi_pci_root_init(void);
>  void acpi_pci_link_init(void);
> +#else
> +static inline void acpi_pci_root_init(void) {}
> +static inline void acpi_pci_link_init(void) {}
> +#endif
>  void acpi_processor_init(void);
>  void acpi_platform_init(void);
>  void acpi_pnp_init(void);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 466bcd1..27d7354 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -558,15 +558,6 @@ struct pci_ops {
>         int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val);
>  };
>
> -/*
> - * ACPI needs to be able to access PCI config space before we've done a
> - * PCI bus scan and created pci_bus structures.
> - */
> -int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
> -                int reg, int len, u32 *val);
> -int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
> -                 int reg, int len, u32 val);
> -
>  struct pci_bus_region {
>         dma_addr_t start;
>         dma_addr_t end;
> @@ -1293,6 +1284,16 @@ typedef int (*arch_set_vga_state_t)(struct pci_dev *pdev, bool decode,
>                       unsigned int command_bits, u32 flags);
>  void pci_register_set_vga_state(arch_set_vga_state_t func);
>
> +/*
> + * ACPI needs to be able to access PCI config space before we've done a
> + * PCI bus scan and created pci_bus structures.
> + */
> +int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
> +                int reg, int len, u32 *val);
> +int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
> +                 int reg, int len, u32 val);
> +void pcibios_penalize_isa_irq(int irq, int active);
> +
>  #else /* CONFIG_PCI is not enabled */
>
>  /*
> @@ -1394,6 +1395,23 @@ static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
>                                                 unsigned int devfn)
>  { return NULL; }
>
> +static inline struct pci_bus *pci_find_bus(int domain, int busnr)
> +{ return NULL; }
> +
> +static inline int pci_bus_write_config_byte(struct pci_bus *bus,
> +                               unsigned int devfn, int where, u8 val)
> +{ return -ENODEV; }
> +
> +static inline int raw_pci_read(unsigned int domain, unsigned int bus,
> +                       unsigned int devfn, int reg, int len, u32 *val)
> +{ return -EINVAL; }
> +
> +static inline int raw_pci_write(unsigned int domain, unsigned int bus,
> +                       unsigned int devfn, int reg, int len, u32 val)
> +{ return -EINVAL; }
> +
> +static inline void pcibios_penalize_isa_irq(int irq, int active) { }
> +
>  static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
>  static inline struct pci_dev *pci_dev_get(struct pci_dev *dev) { return NULL; }
>
> @@ -1597,7 +1615,6 @@ int pcibios_set_pcie_reset_state(struct pci_dev *dev,
>                                  enum pcie_reset_state state);
>  int pcibios_add_device(struct pci_dev *dev);
>  void pcibios_release_device(struct pci_dev *dev);
> -void pcibios_penalize_isa_irq(int irq, int active);
>
>  #ifdef CONFIG_HIBERNATE_CALLBACKS
>  extern struct dev_pm_ops pcibios_pm_ops;
> --
> 1.7.9.5
>

Re: [PATCH 05/19] ARM64 / ACPI: Make PCI optional for ACPI on ARM64

[Naresh Bhat]

On 24 July 2014 18:30, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>
> As PCI for ARM64 is not ready, so introduce some stub functions
> to make PCI optional for ACPI, and make ACPI core run without
> CONFIG_PCI on ARM64.
>
> Since ACPI on X86 and IA64 depends on PCI and this patch only makes
> PCI optinal for ARM64, it will not break anything on X86 and IA64.


optional

>
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  arch/arm64/include/asm/pci.h |   11 +++++++++++
>  drivers/acpi/Makefile        |    2 +-
>  drivers/acpi/internal.h      |    5 +++++
>  include/linux/pci.h          |   37 +++++++++++++++++++++++++++----------
>  4 files changed, 44 insertions(+), 11 deletions(-)
>  create mode 100644 arch/arm64/include/asm/pci.h
>
> diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> new file mode 100644
> index 0000000..250cd24
> --- /dev/null
> +++ b/arch/arm64/include/asm/pci.h
> @@ -0,0 +1,11 @@
> +#ifndef __ASM_PCI_H
> +#define __ASM_PCI_H
> +#ifdef __KERNEL__
> +
> +/*
> + * PCI address space differs from physical memory address space
> + */
> +#define PCI_DMA_BUS_IS_PHYS    (0)
> +
> +#endif  /* __KERNEL__ */
> +#endif  /* __ASM_PCI_H */
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 505d4d7..8e9bbe6 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -39,7 +39,7 @@ acpi-y                                += processor_core.o
>  acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
>  acpi-y                         += ec.o
>  acpi-$(CONFIG_ACPI_DOCK)       += dock.o
> -acpi-y                         += pci_root.o pci_link.o pci_irq.o
> +acpi-$(CONFIG_PCI)             += pci_root.o pci_link.o pci_irq.o
>  acpi-y                         += acpi_lpss.o
>  acpi-y                         += acpi_platform.o
>  acpi-y                         += acpi_pnp.o
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 4c5cf77..e1e6487 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -26,8 +26,13 @@
>  acpi_status acpi_os_initialize1(void);
>  int init_acpi_device_notify(void);
>  int acpi_scan_init(void);
> +#ifdef CONFIG_PCI
>  void acpi_pci_root_init(void);
>  void acpi_pci_link_init(void);
> +#else
> +static inline void acpi_pci_root_init(void) {}
> +static inline void acpi_pci_link_init(void) {}
> +#endif
>  void acpi_processor_init(void);
>  void acpi_platform_init(void);
>  void acpi_pnp_init(void);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 466bcd1..27d7354 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -558,15 +558,6 @@ struct pci_ops {
>         int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val);
>  };
>
> -/*
> - * ACPI needs to be able to access PCI config space before we've done a
> - * PCI bus scan and created pci_bus structures.
> - */
> -int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
> -                int reg, int len, u32 *val);
> -int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
> -                 int reg, int len, u32 val);
> -
>  struct pci_bus_region {
>         dma_addr_t start;
>         dma_addr_t end;
> @@ -1293,6 +1284,16 @@ typedef int (*arch_set_vga_state_t)(struct pci_dev *pdev, bool decode,
>                       unsigned int command_bits, u32 flags);
>  void pci_register_set_vga_state(arch_set_vga_state_t func);
>
> +/*
> + * ACPI needs to be able to access PCI config space before we've done a
> + * PCI bus scan and created pci_bus structures.
> + */
> +int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
> +                int reg, int len, u32 *val);
> +int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
> +                 int reg, int len, u32 val);
> +void pcibios_penalize_isa_irq(int irq, int active);
> +
>  #else /* CONFIG_PCI is not enabled */
>
>  /*
> @@ -1394,6 +1395,23 @@ static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
>                                                 unsigned int devfn)
>  { return NULL; }
>
> +static inline struct pci_bus *pci_find_bus(int domain, int busnr)
> +{ return NULL; }
> +
> +static inline int pci_bus_write_config_byte(struct pci_bus *bus,
> +                               unsigned int devfn, int where, u8 val)
> +{ return -ENODEV; }
> +
> +static inline int raw_pci_read(unsigned int domain, unsigned int bus,
> +                       unsigned int devfn, int reg, int len, u32 *val)
> +{ return -EINVAL; }
> +
> +static inline int raw_pci_write(unsigned int domain, unsigned int bus,
> +                       unsigned int devfn, int reg, int len, u32 val)
> +{ return -EINVAL; }
> +
> +static inline void pcibios_penalize_isa_irq(int irq, int active) { }
> +
>  static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
>  static inline struct pci_dev *pci_dev_get(struct pci_dev *dev) { return NULL; }
>
> @@ -1597,7 +1615,6 @@ int pcibios_set_pcie_reset_state(struct pci_dev *dev,
>                                  enum pcie_reset_state state);
>  int pcibios_add_device(struct pci_dev *dev);
>  void pcibios_release_device(struct pci_dev *dev);
> -void pcibios_penalize_isa_irq(int irq, int active);
>
>  #ifdef CONFIG_HIBERNATE_CALLBACKS
>  extern struct dev_pm_ops pcibios_pm_ops;
> --
> 1.7.9.5
>

[PATCH 05/19] ARM64 / ACPI: Make PCI optional for ACPI on ARM64

[Naresh Bhat]

On 24 July 2014 18:30, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>
> As PCI for ARM64 is not ready, so introduce some stub functions
> to make PCI optional for ACPI, and make ACPI core run without
> CONFIG_PCI on ARM64.
>
> Since ACPI on X86 and IA64 depends on PCI and this patch only makes
> PCI optinal for ARM64, it will not break anything on X86 and IA64.


optional

>
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  arch/arm64/include/asm/pci.h |   11 +++++++++++
>  drivers/acpi/Makefile        |    2 +-
>  drivers/acpi/internal.h      |    5 +++++
>  include/linux/pci.h          |   37 +++++++++++++++++++++++++++----------
>  4 files changed, 44 insertions(+), 11 deletions(-)
>  create mode 100644 arch/arm64/include/asm/pci.h
>
> diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> new file mode 100644
> index 0000000..250cd24
> --- /dev/null
> +++ b/arch/arm64/include/asm/pci.h
> @@ -0,0 +1,11 @@
> +#ifndef __ASM_PCI_H
> +#define __ASM_PCI_H
> +#ifdef __KERNEL__
> +
> +/*
> + * PCI address space differs from physical memory address space
> + */
> +#define PCI_DMA_BUS_IS_PHYS    (0)
> +
> +#endif  /* __KERNEL__ */
> +#endif  /* __ASM_PCI_H */
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 505d4d7..8e9bbe6 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -39,7 +39,7 @@ acpi-y                                += processor_core.o
>  acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
>  acpi-y                         += ec.o
>  acpi-$(CONFIG_ACPI_DOCK)       += dock.o
> -acpi-y                         += pci_root.o pci_link.o pci_irq.o
> +acpi-$(CONFIG_PCI)             += pci_root.o pci_link.o pci_irq.o
>  acpi-y                         += acpi_lpss.o
>  acpi-y                         += acpi_platform.o
>  acpi-y                         += acpi_pnp.o
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 4c5cf77..e1e6487 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -26,8 +26,13 @@
>  acpi_status acpi_os_initialize1(void);
>  int init_acpi_device_notify(void);
>  int acpi_scan_init(void);
> +#ifdef CONFIG_PCI
>  void acpi_pci_root_init(void);
>  void acpi_pci_link_init(void);
> +#else
> +static inline void acpi_pci_root_init(void) {}
> +static inline void acpi_pci_link_init(void) {}
> +#endif
>  void acpi_processor_init(void);
>  void acpi_platform_init(void);
>  void acpi_pnp_init(void);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 466bcd1..27d7354 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -558,15 +558,6 @@ struct pci_ops {
>         int (*write)(struct pci_bus *bus, unsigned int devfn, int where, int size, u32 val);
>  };
>
> -/*
> - * ACPI needs to be able to access PCI config space before we've done a
> - * PCI bus scan and created pci_bus structures.
> - */
> -int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
> -                int reg, int len, u32 *val);
> -int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
> -                 int reg, int len, u32 val);
> -
>  struct pci_bus_region {
>         dma_addr_t start;
>         dma_addr_t end;
> @@ -1293,6 +1284,16 @@ typedef int (*arch_set_vga_state_t)(struct pci_dev *pdev, bool decode,
>                       unsigned int command_bits, u32 flags);
>  void pci_register_set_vga_state(arch_set_vga_state_t func);
>
> +/*
> + * ACPI needs to be able to access PCI config space before we've done a
> + * PCI bus scan and created pci_bus structures.
> + */
> +int raw_pci_read(unsigned int domain, unsigned int bus, unsigned int devfn,
> +                int reg, int len, u32 *val);
> +int raw_pci_write(unsigned int domain, unsigned int bus, unsigned int devfn,
> +                 int reg, int len, u32 val);
> +void pcibios_penalize_isa_irq(int irq, int active);
> +
>  #else /* CONFIG_PCI is not enabled */
>
>  /*
> @@ -1394,6 +1395,23 @@ static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
>                                                 unsigned int devfn)
>  { return NULL; }
>
> +static inline struct pci_bus *pci_find_bus(int domain, int busnr)
> +{ return NULL; }
> +
> +static inline int pci_bus_write_config_byte(struct pci_bus *bus,
> +                               unsigned int devfn, int where, u8 val)
> +{ return -ENODEV; }
> +
> +static inline int raw_pci_read(unsigned int domain, unsigned int bus,
> +                       unsigned int devfn, int reg, int len, u32 *val)
> +{ return -EINVAL; }
> +
> +static inline int raw_pci_write(unsigned int domain, unsigned int bus,
> +                       unsigned int devfn, int reg, int len, u32 val)
> +{ return -EINVAL; }
> +
> +static inline void pcibios_penalize_isa_irq(int irq, int active) { }
> +
>  static inline int pci_domain_nr(struct pci_bus *bus) { return 0; }
>  static inline struct pci_dev *pci_dev_get(struct pci_dev *dev) { return NULL; }
>
> @@ -1597,7 +1615,6 @@ int pcibios_set_pcie_reset_state(struct pci_dev *dev,
>                                  enum pcie_reset_state state);
>  int pcibios_add_device(struct pci_dev *dev);
>  void pcibios_release_device(struct pci_dev *dev);
> -void pcibios_penalize_isa_irq(int irq, int active);
>
>  #ifdef CONFIG_HIBERNATE_CALLBACKS
>  extern struct dev_pm_ops pcibios_pm_ops;
> --
> 1.7.9.5
>

Re: [PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Naresh Bhat]

On 24 July 2014 18:30, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> MADT contains the information for MPIDR which is essential for
> SMP initialization, parse the GIC cpu interface structures to
> get the MPIDR value and map it to cpu_logical_map(), and add
> enabled cpu with valid MPIDR into cpu_possible_map and
> cpu_present_map.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h |    2 +
>  arch/arm64/kernel/acpi.c      |  127 +++++++++++++++++++++++++++++++++++++++++
>  arch/arm64/kernel/smp.c       |   10 +++-
>  3 files changed, 138 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 67dac90..5ce85f8 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -50,6 +50,8 @@ static inline bool acpi_has_cpu_in_madt(void)
>  extern int (*acpi_suspend_lowlevel)(void);
>  #define acpi_wakeup_address 0
>
> +#define MAX_GIC_CPU_INTERFACE 65535
> +
>  #endif /* CONFIG_ACPI */
>
>  #endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 374926f..801e268 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -22,6 +22,9 @@
>  #include <linux/bootmem.h>
>  #include <linux/smp.h>
>
> +#include <asm/smp_plat.h>
> +#include <asm/cputype.h>
> +
>  /*
>   * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>   * variable is still required by the ACPI core
> @@ -42,6 +45,9 @@ int acpi_psci_present;
>  /* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>  int acpi_psci_use_hvc;
>
> +/* Processors (GICC) with enabled flag in MADT */
> +static int enabled_cpus;
> +
>  /*
>   * __acpi_map_table() will be called before page_init(), so early_ioremap()
>   * or early_memremap() should be called here to for ACPI table mapping.
> @@ -62,6 +68,122 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>         early_iounmap(map, size);
>  }
>
> +/**
> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
> + * generates a logic cpu number

logic - logical

> + * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
> + * @enabled: this cpu is enabled or not
> + *
> + * Returns the logic cpu number which maps to the gic cpu interface

logic - logical

> + */
> +static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)
> +{
> +       int cpu;
> +
> +       if (mpidr == INVALID_HWID) {
> +               pr_info("Skip invalid cpu hardware ID\n");
> +               return -EINVAL;
> +       }
> +
> +       total_cpus++;
> +       if (!enabled)
> +               return -EINVAL;
> +
> +       if (enabled_cpus >=  NR_CPUS) {
> +               pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
> +                       NR_CPUS, total_cpus, mpidr);
> +               return -EINVAL;
> +       }
> +
> +       /* If it is the first CPU, no need to check duplicate MPIDRs */
> +       if (!enabled_cpus)
> +               goto skip_mpidr_check;
> +
> +       /*
> +        * Duplicate MPIDRs are a recipe for disaster. Scan
> +        * all initialized entries and check for
> +        * duplicates. If any is found just ignore the CPU.
> +        */
> +       for_each_present_cpu(cpu) {
> +               if (cpu_logical_map(cpu) == mpidr) {
> +                       pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
> +                              mpidr);
> +                       return -EINVAL;
> +               }
> +       }
> +
> +skip_mpidr_check:
> +       enabled_cpus++;
> +
> +       /* allocate a logic cpu id for the new comer */

logic - logical

> +       if (cpu_logical_map(0) == mpidr) {
> +               /*
> +                * boot_cpu_init() already hold bit 0 in cpu_present_mask
> +                * for BSP, no need to allocte again.

allocte - allocate

> +                */
> +               cpu = 0;
> +       } else {
> +               cpu = cpumask_next_zero(-1, cpu_present_mask);
> +       }
> +
> +       /* map the logic cpu id to cpu MPIDR */

logic - logical

> +       cpu_logical_map(cpu) = mpidr;
> +
> +       set_cpu_possible(cpu, true);
> +       set_cpu_present(cpu, true);
> +
> +       return cpu;
> +}
> +
> +static int __init
> +acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
> +                               const unsigned long end)
> +{
> +       struct acpi_madt_generic_interrupt *processor;
> +
> +       processor = (struct acpi_madt_generic_interrupt *)header;
> +
> +       if (BAD_MADT_ENTRY(processor, end))
> +               return -EINVAL;
> +
> +       acpi_table_print_madt_entry(header);
> +
> +       acpi_register_gic_cpu_interface(processor->mpidr,
> +               processor->flags & ACPI_MADT_ENABLED);
> +
> +       return 0;
> +}
> +
> +/*
> + * Parse GIC cpu interface related entries in MADT
> + * returns 0 on success, < 0 on error
> + */
> +static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
> +{
> +       int count;
> +
> +       /*
> +        * do a partial walk of MADT to determine how many CPUs
> +        * we have including disabled CPUs, and get information
> +        * we need for SMP init
> +        */
> +       count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
> +                       acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
> +
> +       if (!count) {
> +               pr_err("No GIC CPU interface entries present\n");
> +               return -ENODEV;
> +       } else if (count < 0) {
> +               pr_err("Error parsing GIC CPU interface entry\n");
> +               return count;
> +       }
> +
> +       /* Make boot-up look pretty */
> +       pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
> +
> +       return 0;
> +}
> +
>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
>  {
>         struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> @@ -122,6 +244,11 @@ int __init acpi_boot_init(void)
>         if (err)
>                 pr_err("Can't find FADT\n");
>
> +       /* Get the boot CPU's MPIDR before MADT parsing */
> +       cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> +
> +       err = acpi_parse_madt_gic_cpu_interface_entries();
> +
>         return err;
>  }
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 40f38f4..8f1d37c 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -36,6 +36,7 @@
>  #include <linux/completion.h>
>  #include <linux/of.h>
>  #include <linux/irq_work.h>
> +#include <linux/acpi.h>
>
>  #include <asm/atomic.h>
>  #include <asm/cacheflush.h>
> @@ -458,7 +459,14 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>                 if (err)
>                         continue;
>
> -               set_cpu_present(cpu, true);
> +               /*
> +                * In ACPI mode, cpu_present_map was initialised when
> +                * MADT table was parsed which before this function
> +                * is called.
> +                */
> +               if (acpi_disabled)
> +                       set_cpu_present(cpu, true);
> +
>                 max_cpus--;
>         }
>  }
> --
> 1.7.9.5
>

Re: [PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Naresh Bhat]

On 24 July 2014 18:30, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> MADT contains the information for MPIDR which is essential for
> SMP initialization, parse the GIC cpu interface structures to
> get the MPIDR value and map it to cpu_logical_map(), and add
> enabled cpu with valid MPIDR into cpu_possible_map and
> cpu_present_map.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h |    2 +
>  arch/arm64/kernel/acpi.c      |  127 +++++++++++++++++++++++++++++++++++++++++
>  arch/arm64/kernel/smp.c       |   10 +++-
>  3 files changed, 138 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 67dac90..5ce85f8 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -50,6 +50,8 @@ static inline bool acpi_has_cpu_in_madt(void)
>  extern int (*acpi_suspend_lowlevel)(void);
>  #define acpi_wakeup_address 0
>
> +#define MAX_GIC_CPU_INTERFACE 65535
> +
>  #endif /* CONFIG_ACPI */
>
>  #endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 374926f..801e268 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -22,6 +22,9 @@
>  #include <linux/bootmem.h>
>  #include <linux/smp.h>
>
> +#include <asm/smp_plat.h>
> +#include <asm/cputype.h>
> +
>  /*
>   * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>   * variable is still required by the ACPI core
> @@ -42,6 +45,9 @@ int acpi_psci_present;
>  /* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>  int acpi_psci_use_hvc;
>
> +/* Processors (GICC) with enabled flag in MADT */
> +static int enabled_cpus;
> +
>  /*
>   * __acpi_map_table() will be called before page_init(), so early_ioremap()
>   * or early_memremap() should be called here to for ACPI table mapping.
> @@ -62,6 +68,122 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>         early_iounmap(map, size);
>  }
>
> +/**
> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
> + * generates a logic cpu number

logic - logical

> + * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
> + * @enabled: this cpu is enabled or not
> + *
> + * Returns the logic cpu number which maps to the gic cpu interface

logic - logical

> + */
> +static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)
> +{
> +       int cpu;
> +
> +       if (mpidr == INVALID_HWID) {
> +               pr_info("Skip invalid cpu hardware ID\n");
> +               return -EINVAL;
> +       }
> +
> +       total_cpus++;
> +       if (!enabled)
> +               return -EINVAL;
> +
> +       if (enabled_cpus >=  NR_CPUS) {
> +               pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
> +                       NR_CPUS, total_cpus, mpidr);
> +               return -EINVAL;
> +       }
> +
> +       /* If it is the first CPU, no need to check duplicate MPIDRs */
> +       if (!enabled_cpus)
> +               goto skip_mpidr_check;
> +
> +       /*
> +        * Duplicate MPIDRs are a recipe for disaster. Scan
> +        * all initialized entries and check for
> +        * duplicates. If any is found just ignore the CPU.
> +        */
> +       for_each_present_cpu(cpu) {
> +               if (cpu_logical_map(cpu) == mpidr) {
> +                       pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
> +                              mpidr);
> +                       return -EINVAL;
> +               }
> +       }
> +
> +skip_mpidr_check:
> +       enabled_cpus++;
> +
> +       /* allocate a logic cpu id for the new comer */

logic - logical

> +       if (cpu_logical_map(0) == mpidr) {
> +               /*
> +                * boot_cpu_init() already hold bit 0 in cpu_present_mask
> +                * for BSP, no need to allocte again.

allocte - allocate

> +                */
> +               cpu = 0;
> +       } else {
> +               cpu = cpumask_next_zero(-1, cpu_present_mask);
> +       }
> +
> +       /* map the logic cpu id to cpu MPIDR */

logic - logical

> +       cpu_logical_map(cpu) = mpidr;
> +
> +       set_cpu_possible(cpu, true);
> +       set_cpu_present(cpu, true);
> +
> +       return cpu;
> +}
> +
> +static int __init
> +acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
> +                               const unsigned long end)
> +{
> +       struct acpi_madt_generic_interrupt *processor;
> +
> +       processor = (struct acpi_madt_generic_interrupt *)header;
> +
> +       if (BAD_MADT_ENTRY(processor, end))
> +               return -EINVAL;
> +
> +       acpi_table_print_madt_entry(header);
> +
> +       acpi_register_gic_cpu_interface(processor->mpidr,
> +               processor->flags & ACPI_MADT_ENABLED);
> +
> +       return 0;
> +}
> +
> +/*
> + * Parse GIC cpu interface related entries in MADT
> + * returns 0 on success, < 0 on error
> + */
> +static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
> +{
> +       int count;
> +
> +       /*
> +        * do a partial walk of MADT to determine how many CPUs
> +        * we have including disabled CPUs, and get information
> +        * we need for SMP init
> +        */
> +       count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
> +                       acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
> +
> +       if (!count) {
> +               pr_err("No GIC CPU interface entries present\n");
> +               return -ENODEV;
> +       } else if (count < 0) {
> +               pr_err("Error parsing GIC CPU interface entry\n");
> +               return count;
> +       }
> +
> +       /* Make boot-up look pretty */
> +       pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
> +
> +       return 0;
> +}
> +
>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
>  {
>         struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> @@ -122,6 +244,11 @@ int __init acpi_boot_init(void)
>         if (err)
>                 pr_err("Can't find FADT\n");
>
> +       /* Get the boot CPU's MPIDR before MADT parsing */
> +       cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> +
> +       err = acpi_parse_madt_gic_cpu_interface_entries();
> +
>         return err;
>  }
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 40f38f4..8f1d37c 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -36,6 +36,7 @@
>  #include <linux/completion.h>
>  #include <linux/of.h>
>  #include <linux/irq_work.h>
> +#include <linux/acpi.h>
>
>  #include <asm/atomic.h>
>  #include <asm/cacheflush.h>
> @@ -458,7 +459,14 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>                 if (err)
>                         continue;
>
> -               set_cpu_present(cpu, true);
> +               /*
> +                * In ACPI mode, cpu_present_map was initialised when
> +                * MADT table was parsed which before this function
> +                * is called.
> +                */
> +               if (acpi_disabled)
> +                       set_cpu_present(cpu, true);
> +
>                 max_cpus--;
>         }
>  }
> --
> 1.7.9.5
>

[PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Naresh Bhat]

On 24 July 2014 18:30, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> MADT contains the information for MPIDR which is essential for
> SMP initialization, parse the GIC cpu interface structures to
> get the MPIDR value and map it to cpu_logical_map(), and add
> enabled cpu with valid MPIDR into cpu_possible_map and
> cpu_present_map.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h |    2 +
>  arch/arm64/kernel/acpi.c      |  127 +++++++++++++++++++++++++++++++++++++++++
>  arch/arm64/kernel/smp.c       |   10 +++-
>  3 files changed, 138 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 67dac90..5ce85f8 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -50,6 +50,8 @@ static inline bool acpi_has_cpu_in_madt(void)
>  extern int (*acpi_suspend_lowlevel)(void);
>  #define acpi_wakeup_address 0
>
> +#define MAX_GIC_CPU_INTERFACE 65535
> +
>  #endif /* CONFIG_ACPI */
>
>  #endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 374926f..801e268 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -22,6 +22,9 @@
>  #include <linux/bootmem.h>
>  #include <linux/smp.h>
>
> +#include <asm/smp_plat.h>
> +#include <asm/cputype.h>
> +
>  /*
>   * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>   * variable is still required by the ACPI core
> @@ -42,6 +45,9 @@ int acpi_psci_present;
>  /* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>  int acpi_psci_use_hvc;
>
> +/* Processors (GICC) with enabled flag in MADT */
> +static int enabled_cpus;
> +
>  /*
>   * __acpi_map_table() will be called before page_init(), so early_ioremap()
>   * or early_memremap() should be called here to for ACPI table mapping.
> @@ -62,6 +68,122 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>         early_iounmap(map, size);
>  }
>
> +/**
> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
> + * generates a logic cpu number

logic - logical

> + * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
> + * @enabled: this cpu is enabled or not
> + *
> + * Returns the logic cpu number which maps to the gic cpu interface

logic - logical

> + */
> +static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)
> +{
> +       int cpu;
> +
> +       if (mpidr == INVALID_HWID) {
> +               pr_info("Skip invalid cpu hardware ID\n");
> +               return -EINVAL;
> +       }
> +
> +       total_cpus++;
> +       if (!enabled)
> +               return -EINVAL;
> +
> +       if (enabled_cpus >=  NR_CPUS) {
> +               pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
> +                       NR_CPUS, total_cpus, mpidr);
> +               return -EINVAL;
> +       }
> +
> +       /* If it is the first CPU, no need to check duplicate MPIDRs */
> +       if (!enabled_cpus)
> +               goto skip_mpidr_check;
> +
> +       /*
> +        * Duplicate MPIDRs are a recipe for disaster. Scan
> +        * all initialized entries and check for
> +        * duplicates. If any is found just ignore the CPU.
> +        */
> +       for_each_present_cpu(cpu) {
> +               if (cpu_logical_map(cpu) == mpidr) {
> +                       pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
> +                              mpidr);
> +                       return -EINVAL;
> +               }
> +       }
> +
> +skip_mpidr_check:
> +       enabled_cpus++;
> +
> +       /* allocate a logic cpu id for the new comer */

logic - logical

> +       if (cpu_logical_map(0) == mpidr) {
> +               /*
> +                * boot_cpu_init() already hold bit 0 in cpu_present_mask
> +                * for BSP, no need to allocte again.

allocte - allocate

> +                */
> +               cpu = 0;
> +       } else {
> +               cpu = cpumask_next_zero(-1, cpu_present_mask);
> +       }
> +
> +       /* map the logic cpu id to cpu MPIDR */

logic - logical

> +       cpu_logical_map(cpu) = mpidr;
> +
> +       set_cpu_possible(cpu, true);
> +       set_cpu_present(cpu, true);
> +
> +       return cpu;
> +}
> +
> +static int __init
> +acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
> +                               const unsigned long end)
> +{
> +       struct acpi_madt_generic_interrupt *processor;
> +
> +       processor = (struct acpi_madt_generic_interrupt *)header;
> +
> +       if (BAD_MADT_ENTRY(processor, end))
> +               return -EINVAL;
> +
> +       acpi_table_print_madt_entry(header);
> +
> +       acpi_register_gic_cpu_interface(processor->mpidr,
> +               processor->flags & ACPI_MADT_ENABLED);
> +
> +       return 0;
> +}
> +
> +/*
> + * Parse GIC cpu interface related entries in MADT
> + * returns 0 on success, < 0 on error
> + */
> +static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
> +{
> +       int count;
> +
> +       /*
> +        * do a partial walk of MADT to determine how many CPUs
> +        * we have including disabled CPUs, and get information
> +        * we need for SMP init
> +        */
> +       count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
> +                       acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
> +
> +       if (!count) {
> +               pr_err("No GIC CPU interface entries present\n");
> +               return -ENODEV;
> +       } else if (count < 0) {
> +               pr_err("Error parsing GIC CPU interface entry\n");
> +               return count;
> +       }
> +
> +       /* Make boot-up look pretty */
> +       pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
> +
> +       return 0;
> +}
> +
>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
>  {
>         struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> @@ -122,6 +244,11 @@ int __init acpi_boot_init(void)
>         if (err)
>                 pr_err("Can't find FADT\n");
>
> +       /* Get the boot CPU's MPIDR before MADT parsing */
> +       cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> +
> +       err = acpi_parse_madt_gic_cpu_interface_entries();
> +
>         return err;
>  }
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 40f38f4..8f1d37c 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -36,6 +36,7 @@
>  #include <linux/completion.h>
>  #include <linux/of.h>
>  #include <linux/irq_work.h>
> +#include <linux/acpi.h>
>
>  #include <asm/atomic.h>
>  #include <asm/cacheflush.h>
> @@ -458,7 +459,14 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>                 if (err)
>                         continue;
>
> -               set_cpu_present(cpu, true);
> +               /*
> +                * In ACPI mode, cpu_present_map was initialised when
> +                * MADT table was parsed which before this function
> +                * is called.
> +                */
> +               if (acpi_disabled)
> +                       set_cpu_present(cpu, true);
> +
>                 max_cpus--;
>         }
>  }
> --
> 1.7.9.5
>

Re: [PATCH 00/19] Introduce ACPI for ARM64 based on ACPI 5.1

[Hanjun Guo]

Hi folks,

I included the linaro-acpi-private mail list wrongly when I was sending them
out, it will cause Delivery Status Notification (Failure) when you are not
in that mail list, sorry for the messed up, it was a little bit late for me
last night, and little bit dottiness for me too, I must be tired :(

please remove the linaro-acpi-private mail list when you replied, Thanks.

Best Regards
Hanjun

On 2014-7-24 21:00, Hanjun Guo wrote:
> ACPI 5.1 was released [1] and it fixed some major gaps to run ACPI
> on ARM, this patch just follow the ACPI 5.1 spec and prepare the
> code to run ACPI on ARM64.
> 
> ACPI 5.1 has some major changes for the following tables and
> method which are essential for ARM platforms:
> 
> 1) MADT table updates.
> New fields were introduced to cover MPIDR and virtualization in
> GICC, and introduce GICR and GIC MSI frame structure to cover
> GICv3 and GICv2m (this patch set only cover GICv2).
> 
> 2) FADT updates for PSCI
> New fields were introduced to cover PSCI and ACPI can use psci
> to boot SMP and other PSCI related functions.
> 
> 3) GTDT
> GTDT was updated to support arch timer, memory-mapped tiemr,
> SBSA watchdog timer, in this patch, only arch timer tested on
> Juno board, so only arch timer init is available.
> 
> 4) _DSD
> _DSD (Device Specific Data) will provide some key values which
> presented by FDT before, it makes possible that some devices can
> be emumerated in ACPI way, please refer to the document provided
> in this patch set for detail.
> 
> This patch set is the ARM64 ACPI core patches covered MADT, FADT
> and GTDT, _DSD is not covered in 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 the former ACPICA patches I sent, and I
> already compiled it OK with:
> a) each patch applied on ARM64 with CONFIG_ACPI=y;
> b) CONFIG_ACPI=n on ARM64;
> c) CONFIG_ACPI=y on x86.
> 
> Also this patch set was tested by Graeme on ARM64 Juno platform, it
> boot successfully with ACPI only (no device tree).
> 
> [1]
> You can download ACPI 5.1 from http://www.uefi.org/specifications
> 
> Al Stone (3):
>   ARM64 / ACPI: Get RSDP and ACPI boot-time tables
>   ARM64 / ACPI: Introduce early_param for "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 lowlevel suspend function
>   ARM64 / ACPI: If we chose to boot from acpi then disable FDT
>   ARM64 / ACPI: Enable ARM64 in Kconfig
>   Documentation: ACPI for ARM64
> 
> Hanjun Guo (10):
>   ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology
>   ARM64 / ACPI: Make PCI optional for ACPI on ARM64
>   ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init
>   ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get
>     cpu_possible/present_map
>   ACPI / table: Print GIC information when MADT is parsed
>   ARM64 / ACPI: Move the initialization of cpu_logical_map(0) before
>     acpi_boot_init()
>   ARM64 / ACPI: Get the enable method for SMP initialization in ACPI
>     way
>   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 (1):
>   ARM64 / ACPI: Add GICv2 specific ACPI boot support
> 
>  Documentation/arm64/arm-acpi.txt     |  240 ++++++++++++++++++++
>  Documentation/kernel-parameters.txt  |    3 +-
>  arch/arm64/Kconfig                   |    3 +
>  arch/arm64/include/asm/acenv.h       |   18 ++
>  arch/arm64/include/asm/acpi.h        |   90 ++++++++
>  arch/arm64/include/asm/cpu.h         |   11 +
>  arch/arm64/include/asm/cpu_ops.h     |    9 +-
>  arch/arm64/include/asm/pci.h         |   11 +
>  arch/arm64/include/asm/smp.h         |    2 +-
>  arch/arm64/include/asm/topology.h    |    2 +
>  arch/arm64/kernel/Makefile           |    1 +
>  arch/arm64/kernel/acpi.c             |  403 ++++++++++++++++++++++++++++++++++
>  arch/arm64/kernel/cpu_ops.c          |   52 ++++-
>  arch/arm64/kernel/irq.c              |    5 +
>  arch/arm64/kernel/psci.c             |   95 +++++---
>  arch/arm64/kernel/setup.c            |   11 +-
>  arch/arm64/kernel/smp.c              |   39 +++-
>  arch/arm64/kernel/time.c             |    7 +
>  arch/arm64/kernel/topology.c         |   14 ++
>  drivers/acpi/Kconfig                 |    6 +-
>  drivers/acpi/Makefile                |    2 +-
>  drivers/acpi/bus.c                   |    3 +
>  drivers/acpi/internal.h              |    5 +
>  drivers/acpi/processor_core.c        |   36 +++
>  drivers/acpi/tables.c                |  109 +++++++--
>  drivers/clocksource/arm_arch_timer.c |  117 ++++++++--
>  drivers/irqchip/irq-gic.c            |  114 ++++++++++
>  include/linux/acpi.h                 |    5 +
>  include/linux/clocksource.h          |    6 +
>  include/linux/irqchip/arm-gic-acpi.h |   36 +++
>  include/linux/pci.h                  |   37 +++-
>  31 files changed, 1397 insertions(+), 95 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/cpu.h
>  create mode 100644 arch/arm64/include/asm/pci.h
>  create mode 100644 arch/arm64/kernel/acpi.c
>  create mode 100644 include/linux/irqchip/arm-gic-acpi.h
> 

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

[Hanjun Guo]

Hi folks,

I included the linaro-acpi-private mail list wrongly when I was sending them
out, it will cause Delivery Status Notification (Failure) when you are not
in that mail list, sorry for the messed up, it was a little bit late for me
last night, and little bit dottiness for me too, I must be tired :(

please remove the linaro-acpi-private mail list when you replied, Thanks.

Best Regards
Hanjun

On 2014-7-24 21:00, Hanjun Guo wrote:
> ACPI 5.1 was released [1] and it fixed some major gaps to run ACPI
> on ARM, this patch just follow the ACPI 5.1 spec and prepare the
> code to run ACPI on ARM64.
> 
> ACPI 5.1 has some major changes for the following tables and
> method which are essential for ARM platforms:
> 
> 1) MADT table updates.
> New fields were introduced to cover MPIDR and virtualization in
> GICC, and introduce GICR and GIC MSI frame structure to cover
> GICv3 and GICv2m (this patch set only cover GICv2).
> 
> 2) FADT updates for PSCI
> New fields were introduced to cover PSCI and ACPI can use psci
> to boot SMP and other PSCI related functions.
> 
> 3) GTDT
> GTDT was updated to support arch timer, memory-mapped tiemr,
> SBSA watchdog timer, in this patch, only arch timer tested on
> Juno board, so only arch timer init is available.
> 
> 4) _DSD
> _DSD (Device Specific Data) will provide some key values which
> presented by FDT before, it makes possible that some devices can
> be emumerated in ACPI way, please refer to the document provided
> in this patch set for detail.
> 
> This patch set is the ARM64 ACPI core patches covered MADT, FADT
> and GTDT, _DSD is not covered in 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 the former ACPICA patches I sent, and I
> already compiled it OK with:
> a) each patch applied on ARM64 with CONFIG_ACPI=y;
> b) CONFIG_ACPI=n on ARM64;
> c) CONFIG_ACPI=y on x86.
> 
> Also this patch set was tested by Graeme on ARM64 Juno platform, it
> boot successfully with ACPI only (no device tree).
> 
> [1]
> You can download ACPI 5.1 from http://www.uefi.org/specifications
> 
> Al Stone (3):
>   ARM64 / ACPI: Get RSDP and ACPI boot-time tables
>   ARM64 / ACPI: Introduce early_param for "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 lowlevel suspend function
>   ARM64 / ACPI: If we chose to boot from acpi then disable FDT
>   ARM64 / ACPI: Enable ARM64 in Kconfig
>   Documentation: ACPI for ARM64
> 
> Hanjun Guo (10):
>   ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology
>   ARM64 / ACPI: Make PCI optional for ACPI on ARM64
>   ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init
>   ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get
>     cpu_possible/present_map
>   ACPI / table: Print GIC information when MADT is parsed
>   ARM64 / ACPI: Move the initialization of cpu_logical_map(0) before
>     acpi_boot_init()
>   ARM64 / ACPI: Get the enable method for SMP initialization in ACPI
>     way
>   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 (1):
>   ARM64 / ACPI: Add GICv2 specific ACPI boot support
> 
>  Documentation/arm64/arm-acpi.txt     |  240 ++++++++++++++++++++
>  Documentation/kernel-parameters.txt  |    3 +-
>  arch/arm64/Kconfig                   |    3 +
>  arch/arm64/include/asm/acenv.h       |   18 ++
>  arch/arm64/include/asm/acpi.h        |   90 ++++++++
>  arch/arm64/include/asm/cpu.h         |   11 +
>  arch/arm64/include/asm/cpu_ops.h     |    9 +-
>  arch/arm64/include/asm/pci.h         |   11 +
>  arch/arm64/include/asm/smp.h         |    2 +-
>  arch/arm64/include/asm/topology.h    |    2 +
>  arch/arm64/kernel/Makefile           |    1 +
>  arch/arm64/kernel/acpi.c             |  403 ++++++++++++++++++++++++++++++++++
>  arch/arm64/kernel/cpu_ops.c          |   52 ++++-
>  arch/arm64/kernel/irq.c              |    5 +
>  arch/arm64/kernel/psci.c             |   95 +++++---
>  arch/arm64/kernel/setup.c            |   11 +-
>  arch/arm64/kernel/smp.c              |   39 +++-
>  arch/arm64/kernel/time.c             |    7 +
>  arch/arm64/kernel/topology.c         |   14 ++
>  drivers/acpi/Kconfig                 |    6 +-
>  drivers/acpi/Makefile                |    2 +-
>  drivers/acpi/bus.c                   |    3 +
>  drivers/acpi/internal.h              |    5 +
>  drivers/acpi/processor_core.c        |   36 +++
>  drivers/acpi/tables.c                |  109 +++++++--
>  drivers/clocksource/arm_arch_timer.c |  117 ++++++++--
>  drivers/irqchip/irq-gic.c            |  114 ++++++++++
>  include/linux/acpi.h                 |    5 +
>  include/linux/clocksource.h          |    6 +
>  include/linux/irqchip/arm-gic-acpi.h |   36 +++
>  include/linux/pci.h                  |   37 +++-
>  31 files changed, 1397 insertions(+), 95 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/cpu.h
>  create mode 100644 arch/arm64/include/asm/pci.h
>  create mode 100644 arch/arm64/kernel/acpi.c
>  create mode 100644 include/linux/irqchip/arm-gic-acpi.h
> 

Re: [PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Hanjun Guo]

On 2014-7-24 22:43, Mark Brown wrote:
> On Thu, Jul 24, 2014 at 09:00:10PM +0800, Hanjun Guo wrote:
> 
>> +/*
>> + * Use the CPU slot number provided by ACPI to update the physical
>> + * package id when cpuid_topo->cluster_id is not available, then we
>> + * can get the right value in the "physical id" field of /proc/cpuinfo.
>> + */
>> +void arch_fix_phys_package_id(int num, u32 slot)
>> +{
>> +	struct cpu_topology *cpuid_topo = &cpu_topology[num];
>> +
>> +	if (cpuid_topo->cluster_id == -1)
>> +		cpuid_topo->cluster_id = slot;
>> +}
>> +EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
> 
> As I said on the previous version of this patch are you sure this runs
> at a point between the cluster ID getting initialized to -1 and the slot
> being initialized (bear in mind that we now use MPIDR information if
> availabe).  I don't understand why we don't just unconditionally use the
> value given.

Ah, sorry, it should be unconditionally used as you said, and I remember
the comments in last version, but the patch shows not, must be something
wrong, will update it in next version.

Thanks
Hanjun

[PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Hanjun Guo]

On 2014-7-24 22:43, Mark Brown wrote:
> On Thu, Jul 24, 2014 at 09:00:10PM +0800, Hanjun Guo wrote:
> 
>> +/*
>> + * Use the CPU slot number provided by ACPI to update the physical
>> + * package id when cpuid_topo->cluster_id is not available, then we
>> + * can get the right value in the "physical id" field of /proc/cpuinfo.
>> + */
>> +void arch_fix_phys_package_id(int num, u32 slot)
>> +{
>> +	struct cpu_topology *cpuid_topo = &cpu_topology[num];
>> +
>> +	if (cpuid_topo->cluster_id == -1)
>> +		cpuid_topo->cluster_id = slot;
>> +}
>> +EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
> 
> As I said on the previous version of this patch are you sure this runs
> at a point between the cluster ID getting initialized to -1 and the slot
> being initialized (bear in mind that we now use MPIDR information if
> availabe).  I don't understand why we don't just unconditionally use the
> value given.

Ah, sorry, it should be unconditionally used as you said, and I remember
the comments in last version, but the patch shows not, must be something
wrong, will update it in next version.

Thanks
Hanjun

Re: [PATCH 09/19] ARM64 / ACPI: Move the initialization of cpu_logical_map(0) before acpi_boot_init()

[Hanjun Guo]

On 2014-7-24 23:21, Mark Rutland wrote:
> On Thu, Jul 24, 2014 at 02:00:15PM +0100, Hanjun Guo wrote:
>> Move the initialization of cpu_logical_map(0) before acpi_boot_init()
>> to remove the duplicated initialization of cpu_logical_map(0).
> 
> It always make sense to initialise CPU0's logical map entry from the
> hardware values, so you could do this earlier in the series, before you
> introduce any ACPI code. Then you don't have the churn in acpi.c

ok, I will prepare a separate patch to do this before ACPI code, does it
make sense to you?

> 
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>  arch/arm64/kernel/acpi.c  |    3 ---
>>  arch/arm64/kernel/setup.c |    3 ++-
>>  2 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index 801e268..ff0f6a0 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -244,9 +244,6 @@ int __init acpi_boot_init(void)
>>  	if (err)
>>  		pr_err("Can't find FADT\n");
>>  
>> -	/* Get the boot CPU's MPIDR before MADT parsing */
>> -	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>> -
>>  	err = acpi_parse_madt_gic_cpu_interface_entries();
>>  
>>  	return err;
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index e00d40c..17ab98e 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -394,13 +394,14 @@ void __init setup_arch(char **cmdline_p)
>>  
>>  	efi_idmap_init();
>>  
>> +	/* Get the boot CPU's MPIDR before cpu logical map is built */
> 
> That comment's a bit useless; I think it can just be dropped.
> 
> All you need to do is move the initialisation of cpu_logical_map(0)
> before unflatten_device_tree(). When you introduce acpi_boot_init(),
> place it after the initialisation.

ok, I agree with you, will update it.

Thanks
Hanjun

Re: [PATCH 09/19] ARM64 / ACPI: Move the initialization of cpu_logical_map(0) before acpi_boot_init()

[Hanjun Guo]

On 2014-7-24 23:21, Mark Rutland wrote:
> On Thu, Jul 24, 2014 at 02:00:15PM +0100, Hanjun Guo wrote:
>> Move the initialization of cpu_logical_map(0) before acpi_boot_init()
>> to remove the duplicated initialization of cpu_logical_map(0).
> 
> It always make sense to initialise CPU0's logical map entry from the
> hardware values, so you could do this earlier in the series, before you
> introduce any ACPI code. Then you don't have the churn in acpi.c

ok, I will prepare a separate patch to do this before ACPI code, does it
make sense to you?

> 
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>  arch/arm64/kernel/acpi.c  |    3 ---
>>  arch/arm64/kernel/setup.c |    3 ++-
>>  2 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index 801e268..ff0f6a0 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -244,9 +244,6 @@ int __init acpi_boot_init(void)
>>  	if (err)
>>  		pr_err("Can't find FADT\n");
>>  
>> -	/* Get the boot CPU's MPIDR before MADT parsing */
>> -	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>> -
>>  	err = acpi_parse_madt_gic_cpu_interface_entries();
>>  
>>  	return err;
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index e00d40c..17ab98e 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -394,13 +394,14 @@ void __init setup_arch(char **cmdline_p)
>>  
>>  	efi_idmap_init();
>>  
>> +	/* Get the boot CPU's MPIDR before cpu logical map is built */
> 
> That comment's a bit useless; I think it can just be dropped.
> 
> All you need to do is move the initialisation of cpu_logical_map(0)
> before unflatten_device_tree(). When you introduce acpi_boot_init(),
> place it after the initialisation.

ok, I agree with you, will update it.

Thanks
Hanjun

[PATCH 09/19] ARM64 / ACPI: Move the initialization of cpu_logical_map(0) before acpi_boot_init()

[Hanjun Guo]

On 2014-7-24 23:21, Mark Rutland wrote:
> On Thu, Jul 24, 2014 at 02:00:15PM +0100, Hanjun Guo wrote:
>> Move the initialization of cpu_logical_map(0) before acpi_boot_init()
>> to remove the duplicated initialization of cpu_logical_map(0).
> 
> It always make sense to initialise CPU0's logical map entry from the
> hardware values, so you could do this earlier in the series, before you
> introduce any ACPI code. Then you don't have the churn in acpi.c

ok, I will prepare a separate patch to do this before ACPI code, does it
make sense to you?

> 
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>  arch/arm64/kernel/acpi.c  |    3 ---
>>  arch/arm64/kernel/setup.c |    3 ++-
>>  2 files changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index 801e268..ff0f6a0 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -244,9 +244,6 @@ int __init acpi_boot_init(void)
>>  	if (err)
>>  		pr_err("Can't find FADT\n");
>>  
>> -	/* Get the boot CPU's MPIDR before MADT parsing */
>> -	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>> -
>>  	err = acpi_parse_madt_gic_cpu_interface_entries();
>>  
>>  	return err;
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index e00d40c..17ab98e 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -394,13 +394,14 @@ void __init setup_arch(char **cmdline_p)
>>  
>>  	efi_idmap_init();
>>  
>> +	/* Get the boot CPU's MPIDR before cpu logical map is built */
> 
> That comment's a bit useless; I think it can just be dropped.
> 
> All you need to do is move the initialisation of cpu_logical_map(0)
> before unflatten_device_tree(). When you introduce acpi_boot_init(),
> place it after the initialisation.

ok, I agree with you, will update it.

Thanks
Hanjun

Re: [PATCH 03/19] ARM64 / ACPI: Introduce lowlevel suspend function

[Hanjun Guo]

On 2014-7-24 23:34, Mark Rutland wrote:
[...]
>>  early_param("acpi", parse_acpi);
>> +
>> +/*
>> + * acpi_suspend_lowlevel() - save kernel state and suspend.
>> + *
>> + * TBD when ARM/ARM64 starts to support suspend...
>> + */
>> +int (*acpi_suspend_lowlevel)(void);
> 
> Shouldn't this should be intialised to NULL explicitly?

Yes, as ARM64 does not support suspend, initialize it
to NULL will be fine, will update in next version.

Thanks
Hanjun

[PATCH 03/19] ARM64 / ACPI: Introduce lowlevel suspend function

[Hanjun Guo]

On 2014-7-24 23:34, Mark Rutland wrote:
[...]
>>  early_param("acpi", parse_acpi);
>> +
>> +/*
>> + * acpi_suspend_lowlevel() - save kernel state and suspend.
>> + *
>> + * TBD when ARM/ARM64 starts to support suspend...
>> + */
>> +int (*acpi_suspend_lowlevel)(void);
> 
> Shouldn't this should be intialised to NULL explicitly?

Yes, as ARM64 does not support suspend, initialize it
to NULL will be fine, will update in next version.

Thanks
Hanjun

Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

On 2014-7-24 23:47, Mark Rutland wrote:
> On Thu, Jul 24, 2014 at 02:00:16PM +0100, Hanjun Guo wrote:
>> ACPI 5.1 only has two explicit methods to boot up SMP,
>> PSCI and Parking protocol, but the Parking protocol is
>> only suitable for ARMv7 now, so make PSCI as the only way
>> for the SMP boot protocol before some updates for the
>> ACPI spec or the Parking protocol spec.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> ---
>>  arch/arm64/include/asm/acpi.h    |   21 +++++++++++++++
>>  arch/arm64/include/asm/cpu_ops.h |    9 ++++++-
>>  arch/arm64/include/asm/smp.h     |    2 +-
>>  arch/arm64/kernel/acpi.c         |    9 +++++++
>>  arch/arm64/kernel/cpu_ops.c      |   52 ++++++++++++++++++++++++++++++++++----
>>  arch/arm64/kernel/smp.c          |   29 +++++++++++++++++++--
>>  6 files changed, 113 insertions(+), 9 deletions(-)
[...]
>>  /*
>> - * Setup the set of possible CPUs (via set_cpu_possible)
>> + * Platform specific SMP operations
>>   */
>>  extern void smp_init_cpus(void);
> 
> While the originial comment is out of date, the new form is plain wrong.
> 
> Something like "Discover the set of possible CPUs and determine their
> SMP operations" would be a better description of what's going on here.

Agreed.

> 
>>
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index ff0f6a0..2af6662 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
>>         return 0;
>>  }
>>
>> +/* Protocol to bring up secondary CPUs */
>> +enum acpi_smp_boot_protocol smp_boot_protocol(void)
>> +{
>> +       if (acpi_psci_present)
>> +               return ACPI_SMP_BOOT_PSCI;
>> +       else
>> +               return ACPI_SMP_BOOT_PARKING_PROTOCOL;
>> +}
>> +
>>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
>>  {
>>         struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
>> index d62d12f..4d9b3cf 100644
>> --- a/arch/arm64/kernel/cpu_ops.c
>> +++ b/arch/arm64/kernel/cpu_ops.c
>> @@ -16,11 +16,13 @@
>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>   */
>>
>> -#include <asm/cpu_ops.h>
>> -#include <asm/smp_plat.h>
>>  #include <linux/errno.h>
>>  #include <linux/of.h>
>>  #include <linux/string.h>
>> +#include <linux/acpi.h>
>> +
>> +#include <asm/cpu_ops.h>
>> +#include <asm/smp_plat.h>
> 
> Was the header move just for consistency with other files, or is there
> some ordering requirement here?

Ordering requirement, it will meet compile error for "return -ENODEV;"
in the head file which I introduced, I know I can include the right
head file in asm/cpu_ops.h, but I think move the asm/xx.h after the
include of linux/xx.h would be fine.

> 
>>
>>  extern const struct cpu_operations smp_spin_table_ops;
>>  extern const struct cpu_operations cpu_psci_ops;
>> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
>>  /*
>>   * Read a cpu's enable method from the device tree and record it in cpu_ops.
>>   */
>> -int __init cpu_read_ops(struct device_node *dn, int cpu)
>> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
>>  {
>>         const char *enable_method = of_get_property(dn, "enable-method", NULL);
>>         if (!enable_method) {
>> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
>>         return 0;
>>  }
>>
>> +#ifdef CONFIG_ACPI
>> +/*
>> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
>> + */
>> +int __init cpu_acpi_read_ops(int cpu)
>> +{
>> +       /*
>> +        * For ACPI 5.1, only two kind of methods are provided,
>> +        * Parking protocol and PSCI, but Parking protocol is
>> +        * used on ARMv7 only, so make PSCI as the only method
>> +        * for SMP initialization before the ACPI spec or Parking
>> +        * protocol spec is updated.
>> +        */
> 
> That comment is a little misleading. The parking protocol is _specified_
> for ARMv7 only.

Agreed. But I'm just wondering if the Parking protocol is modified and
then support ARMv8, how to describe it in the comments?

> 
>> +       switch (smp_boot_protocol()) {
>> +       case ACPI_SMP_BOOT_PSCI:
>> +               cpu_ops[cpu] = cpu_get_ops("psci");
>> +               break;
>> +       case ACPI_SMP_BOOT_PARKING_PROTOCOL:
>> +       default:
>> +               cpu_ops[cpu] = NULL;
>> +               break;
>> +       }
>> +
>> +       if (!cpu_ops[cpu]) {
>> +               pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
>> +                       cpu);
>> +               return -EOPNOTSUPP;
>> +       }
> 
> That's going to require changes as things get updated, and
> "enable-method" is a term from DT rather than ACPI.
> 
> How about:
> 
> 	"CPU%d: boot protocol unsupported or unknown\n".

Pretty fine to me :)

Thanks
Hanjun

[PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

On 2014-7-24 23:47, Mark Rutland wrote:
> On Thu, Jul 24, 2014 at 02:00:16PM +0100, Hanjun Guo wrote:
>> ACPI 5.1 only has two explicit methods to boot up SMP,
>> PSCI and Parking protocol, but the Parking protocol is
>> only suitable for ARMv7 now, so make PSCI as the only way
>> for the SMP boot protocol before some updates for the
>> ACPI spec or the Parking protocol spec.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> ---
>>  arch/arm64/include/asm/acpi.h    |   21 +++++++++++++++
>>  arch/arm64/include/asm/cpu_ops.h |    9 ++++++-
>>  arch/arm64/include/asm/smp.h     |    2 +-
>>  arch/arm64/kernel/acpi.c         |    9 +++++++
>>  arch/arm64/kernel/cpu_ops.c      |   52 ++++++++++++++++++++++++++++++++++----
>>  arch/arm64/kernel/smp.c          |   29 +++++++++++++++++++--
>>  6 files changed, 113 insertions(+), 9 deletions(-)
[...]
>>  /*
>> - * Setup the set of possible CPUs (via set_cpu_possible)
>> + * Platform specific SMP operations
>>   */
>>  extern void smp_init_cpus(void);
> 
> While the originial comment is out of date, the new form is plain wrong.
> 
> Something like "Discover the set of possible CPUs and determine their
> SMP operations" would be a better description of what's going on here.

Agreed.

> 
>>
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index ff0f6a0..2af6662 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
>>         return 0;
>>  }
>>
>> +/* Protocol to bring up secondary CPUs */
>> +enum acpi_smp_boot_protocol smp_boot_protocol(void)
>> +{
>> +       if (acpi_psci_present)
>> +               return ACPI_SMP_BOOT_PSCI;
>> +       else
>> +               return ACPI_SMP_BOOT_PARKING_PROTOCOL;
>> +}
>> +
>>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
>>  {
>>         struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
>> index d62d12f..4d9b3cf 100644
>> --- a/arch/arm64/kernel/cpu_ops.c
>> +++ b/arch/arm64/kernel/cpu_ops.c
>> @@ -16,11 +16,13 @@
>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>   */
>>
>> -#include <asm/cpu_ops.h>
>> -#include <asm/smp_plat.h>
>>  #include <linux/errno.h>
>>  #include <linux/of.h>
>>  #include <linux/string.h>
>> +#include <linux/acpi.h>
>> +
>> +#include <asm/cpu_ops.h>
>> +#include <asm/smp_plat.h>
> 
> Was the header move just for consistency with other files, or is there
> some ordering requirement here?

Ordering requirement, it will meet compile error for "return -ENODEV;"
in the head file which I introduced, I know I can include the right
head file in asm/cpu_ops.h, but I think move the asm/xx.h after the
include of linux/xx.h would be fine.

> 
>>
>>  extern const struct cpu_operations smp_spin_table_ops;
>>  extern const struct cpu_operations cpu_psci_ops;
>> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
>>  /*
>>   * Read a cpu's enable method from the device tree and record it in cpu_ops.
>>   */
>> -int __init cpu_read_ops(struct device_node *dn, int cpu)
>> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
>>  {
>>         const char *enable_method = of_get_property(dn, "enable-method", NULL);
>>         if (!enable_method) {
>> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
>>         return 0;
>>  }
>>
>> +#ifdef CONFIG_ACPI
>> +/*
>> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
>> + */
>> +int __init cpu_acpi_read_ops(int cpu)
>> +{
>> +       /*
>> +        * For ACPI 5.1, only two kind of methods are provided,
>> +        * Parking protocol and PSCI, but Parking protocol is
>> +        * used on ARMv7 only, so make PSCI as the only method
>> +        * for SMP initialization before the ACPI spec or Parking
>> +        * protocol spec is updated.
>> +        */
> 
> That comment is a little misleading. The parking protocol is _specified_
> for ARMv7 only.

Agreed. But I'm just wondering if the Parking protocol is modified and
then support ARMv8, how to describe it in the comments?

> 
>> +       switch (smp_boot_protocol()) {
>> +       case ACPI_SMP_BOOT_PSCI:
>> +               cpu_ops[cpu] = cpu_get_ops("psci");
>> +               break;
>> +       case ACPI_SMP_BOOT_PARKING_PROTOCOL:
>> +       default:
>> +               cpu_ops[cpu] = NULL;
>> +               break;
>> +       }
>> +
>> +       if (!cpu_ops[cpu]) {
>> +               pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
>> +                       cpu);
>> +               return -EOPNOTSUPP;
>> +       }
> 
> That's going to require changes as things get updated, and
> "enable-method" is a term from DT rather than ACPI.
> 
> How about:
> 
> 	"CPU%d: boot protocol unsupported or unknown\n".

Pretty fine to me :)

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

Hi Randy,

Thank you for your careful review comments, I will update it in next version :)

Best Regards
Hanjun

On 2014-7-25 4:42, Randy Dunlap wrote:
> On 07/24/2014 06:00 AM, Hanjun Guo wrote:
>> From: Graeme Gregory <graeme.gregory@linaro.org>
>>
>> Add documentation for the guidelines of how to use ACPI
>> on ARM64.
>>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 240 insertions(+)
>>  create mode 100644 Documentation/arm64/arm-acpi.txt
>>
>> diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
>> new file mode 100644
>> index 0000000..12cd550
>> --- /dev/null
>> +++ b/Documentation/arm64/arm-acpi.txt
>> @@ -0,0 +1,240 @@
>> +ACPI on ARMv8 Servers
>> +---------------------
>> +
>> +ACPI will be used for ARMv8 general purpose servers designed to follow
>> +the SBSA specification (currently available to people with an ARM login at
>> +http://silver.arm.com)
> 
>                     .com).
> 
>> +
>> +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
>> +which is available at <http://www.uefi.org/acpi/specs>.
>> +
>> +If the machine does not meet these requirements then it is likely that Device
>> +Tree (DT) is more suitable for the hardware.
>> +
>> +Relationship with Device Tree
>> +-----------------------------
>> +
>> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>> +exclusive with DT support at compile time.
>> +
>> +At boot time the kernel will only use one description method depending on
>> +parameters passed from the bootloader.
>> +
>> +Regardless of whether DT or ACPI is used, the kernel must always be capable
>> +of booting with either scheme.
>> +
>> +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.
>> +
>> +Booting using ACPI tables
>> +-------------------------
>> +
>> +Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
>> +is via the UEFI system configuration table.
>> +
>> +The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
>> +RSDP table (the table with the ACPI signature "RSD PTR ").
>> +
>> +The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
>> +
>> +Processing of ACPI tables may be disabled by passing acpi=off on the kernel
>> +command line.
>> +
>> +DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
> 
>              XSDT;
> 
>> +only allow for 32bit addresses.
> 
>                   32-bit
> 
>> +
>> +DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
> 
>                                                FADT; they are deprecated. The
> 
>> +64-bit alternatives MUST be used.
>> +
>> +The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
>> +and GTDT. If PCI is used the MCFG table MUST also be present.
>> +
>> +ACPI Detection
>> +--------------
>> +
>> +Drivers should determine their probe() type by checking for ACPI_HANDLE,
>> +or .of_node, or other information in the device structure. This is
>> +detailed further in the "Driver Recomendations" section.
> 
>                                    Recommendations
> 
>> +
>> +If the presence of ACPI needs to be detected at runtime, then check the value
>> +of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
> 
>                      If CONFIG_ACPI is not set, acpi_disabled will always be 1.
> 
>> +
>> +Device Enumeration
>> +------------------
>> +
>> +Device descriptions in ACPI should use standard recognised ACPI interfaces.
>> +These are far simpler than the information provided via Device Tree. Drivers
>> +should take into account this simplicity and work with sensible defaults.
>> +
>> +On no account should a Device Tree attempt to be replicated in ASL using such
>> +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
>> +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
>> +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
>> +
>> +Common _DSD bindings should be submitted to ASWG to be included in the
>> +document :-
>> +
>> +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
>> +
>> +TODO: Clarification and examples from Juno implementation.
>> +
>> +Programmable Power Control Resources
>> +------------------------------------
>> +
>> +Programmable power control resources include such resources as voltage/current
>> +providers (regulators) and clock sources.
>> +
>> +For power control of these resources they should be represented with Power
>> +Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
>> +enabling/disabling of resources as they are needed.
>> +
>> +There exists in the ACPI 5.1 specification no standard binding for these objects
>> +to enable programmable levels or rates so this should be avoid if possible and
> 
>                                                             avoided
> 
>> +the resources set to appropriate level by the firmware. If this is not possible
> 
>                                     levels
> 
>> +then any manipulation should be abstracted in ASL.
>> +
>> +Each device in ACPI has D-states and these can be controlled through
>> +the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
>> +
>> +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 organise that it is allocated/enabled using the _PS0 method.
>> +
>> +Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
>> +in the _PS3 method.
>> +
>> +Such code in _PS? methods will of course be very platform specific but
>> +should allow the driver to operate the device without special non standard
> 
>                                                                  non-standard
> 
>> +values being read from ASL. Further, abstracting the use of these resources
>> +allows hardware revisions without requiring updates to the kernel.
>> +
>> +TODO: Clarification and examples from Juno implementation.
>> +
>> +Clocks
>> +------
>> +
>> +Like clocks that are part of the power resources there is no standard way
>> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
>> +described in DT.
>> +
>> +Devices affected by this include things like UARTs, SoC driven LCD displays,
>> +etc.
>> +
>> +The firmware for example UEFI should initialise these clocks to fixed working
> 
>                 (for example, UEFI)
> 
>> +values before the kernel is executed. If a driver requires to know rates of
>> +clocks set by firmware then they can be passed to kernel using _DSD.
>> +
>> +example :-
>> +
>> +Device (CLK0) {
>> +	...
>> +
>> +	Name (_DSD, Package() {
>> +		ToUUID("XXXXX"),
>> +		Package() {
>> +			Package(2) {"#clock-cells", 0},
>> +			Package(2) {"clock-frequency", "10000"}
>> +		}
>> +	})
>> +
>> +	...
>> +}
>> +
>> +Device (USR1) {
>> +	...
>> +
>> +	Name (_DSD, Package() {
>> +		ToUUID("XXXXX"),
>> +		Package() {
>> +			Package(2) {"clocks", Package() {1, ^CLK0}}},
>> +		}
>> +	})
>> +
>> +	...
>> +}
>> +			
>> +Driver Recommendations
>> +----------------------
>> +
>> +DO NOT remove any FDT handling when adding ACPI support for a driver, different
> 
>                                                                  driver. Different
> 
>> +systems may use the same device.
>> +
>> +DO try and keep complex sections of ACPI and DT functionality seperate. This
> 
>                                                                  separate.
> 
>> +may mean a patch to break out some complex DT to another function before
>> +the patch to add ACPI. This may happen in other functions but is most likely
>> +in probe function. This gives a clearer flow of data for reviewing driver
>> +source.
>> +
>> +probe() :-
>> +
>> +TODO: replace this with a specific real example from Juno?
>> +
>> +static int device_probe_dt(struct platform_device *pdev)
>> +{
>> +	/* DT specific functionality */
>> +	...
>> +}
>> +
>> +static int device_probe_acpi(struct platform_device *pdev)
>> +{
>> +	/* ACPI specific functionality */
>> +	...
>> +}
>> +
>> +static int device_probe(stuct platform_device *pdev)
>> +{
>> +	...
>> +	acpi_handle handle = ACPI_HANDLE(&pdev->dev);
>> +	struct device_node node = pdev->dev.of_node;
>> +	...
>> +
>> +	if (node)
>> +		ret = device_probe_dt(pdev);
>> +	else if (handle)
>> +		ret = device_probe_acpi(pdev);
>> +	else
>> +		/* other initialisation */
>> +		...
>> +	/* Continue with any generic probe operations */
>> +	...
>> +}
>> +
>> +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
>> +the different names the driver is probed for, both from DT and from ACPI.
>> +
>> +module device tables :-
>> +
>> +static struct of_device_id virtio_mmio_match[] = {
>> +        { .compatible = "virtio,mmio", },
>> +        {},
>> +};
>> +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
>> +
>> +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
>> +        { "LNRO0005", },
>> +        { }
>> +};
>> +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
>> +
>> +TODO: Add any other helpful rules that develop from Juno ACPI work.
>> +
>> +ASWG
>> +----
>> +
>> +The following areas are not yet well defined for ARM in the current ACPI
>> +specification and are expected to be worked through in the UEFI ACPI
>> +Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
>> +Participation in this group is open to all UEFI members.
>> +
>> +	- ACPI based CPU topology
>> +	- ACPI based Power management
>> +	- CPU idle control based on PSCI
>> +	- CPU performance control (CPPC)
>> +
>> +No code shall be accepted into the kernel unless it complies with the released
>> +standards from UEFI ASWG. If there are features missing from ACPI to make it
>> +function on a platform ECRs should be submitted to ASWG and go through the
> 
>             on a platform, ECRs
> 
>> +approval process.
>>
> 
> 

[PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

Hi Randy,

Thank you for your careful review comments, I will update it in next version :)

Best Regards
Hanjun

On 2014-7-25 4:42, Randy Dunlap wrote:
> On 07/24/2014 06:00 AM, Hanjun Guo wrote:
>> From: Graeme Gregory <graeme.gregory@linaro.org>
>>
>> Add documentation for the guidelines of how to use ACPI
>> on ARM64.
>>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 240 insertions(+)
>>  create mode 100644 Documentation/arm64/arm-acpi.txt
>>
>> diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
>> new file mode 100644
>> index 0000000..12cd550
>> --- /dev/null
>> +++ b/Documentation/arm64/arm-acpi.txt
>> @@ -0,0 +1,240 @@
>> +ACPI on ARMv8 Servers
>> +---------------------
>> +
>> +ACPI will be used for ARMv8 general purpose servers designed to follow
>> +the SBSA specification (currently available to people with an ARM login at
>> +http://silver.arm.com)
> 
>                     .com).
> 
>> +
>> +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
>> +which is available at <http://www.uefi.org/acpi/specs>.
>> +
>> +If the machine does not meet these requirements then it is likely that Device
>> +Tree (DT) is more suitable for the hardware.
>> +
>> +Relationship with Device Tree
>> +-----------------------------
>> +
>> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>> +exclusive with DT support at compile time.
>> +
>> +At boot time the kernel will only use one description method depending on
>> +parameters passed from the bootloader.
>> +
>> +Regardless of whether DT or ACPI is used, the kernel must always be capable
>> +of booting with either scheme.
>> +
>> +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.
>> +
>> +Booting using ACPI tables
>> +-------------------------
>> +
>> +Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
>> +is via the UEFI system configuration table.
>> +
>> +The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
>> +RSDP table (the table with the ACPI signature "RSD PTR ").
>> +
>> +The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
>> +
>> +Processing of ACPI tables may be disabled by passing acpi=off on the kernel
>> +command line.
>> +
>> +DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
> 
>              XSDT;
> 
>> +only allow for 32bit addresses.
> 
>                   32-bit
> 
>> +
>> +DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
> 
>                                                FADT; they are deprecated. The
> 
>> +64-bit alternatives MUST be used.
>> +
>> +The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
>> +and GTDT. If PCI is used the MCFG table MUST also be present.
>> +
>> +ACPI Detection
>> +--------------
>> +
>> +Drivers should determine their probe() type by checking for ACPI_HANDLE,
>> +or .of_node, or other information in the device structure. This is
>> +detailed further in the "Driver Recomendations" section.
> 
>                                    Recommendations
> 
>> +
>> +If the presence of ACPI needs to be detected at runtime, then check the value
>> +of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
> 
>                      If CONFIG_ACPI is not set, acpi_disabled will always be 1.
> 
>> +
>> +Device Enumeration
>> +------------------
>> +
>> +Device descriptions in ACPI should use standard recognised ACPI interfaces.
>> +These are far simpler than the information provided via Device Tree. Drivers
>> +should take into account this simplicity and work with sensible defaults.
>> +
>> +On no account should a Device Tree attempt to be replicated in ASL using such
>> +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
>> +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
>> +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
>> +
>> +Common _DSD bindings should be submitted to ASWG to be included in the
>> +document :-
>> +
>> +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
>> +
>> +TODO: Clarification and examples from Juno implementation.
>> +
>> +Programmable Power Control Resources
>> +------------------------------------
>> +
>> +Programmable power control resources include such resources as voltage/current
>> +providers (regulators) and clock sources.
>> +
>> +For power control of these resources they should be represented with Power
>> +Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
>> +enabling/disabling of resources as they are needed.
>> +
>> +There exists in the ACPI 5.1 specification no standard binding for these objects
>> +to enable programmable levels or rates so this should be avoid if possible and
> 
>                                                             avoided
> 
>> +the resources set to appropriate level by the firmware. If this is not possible
> 
>                                     levels
> 
>> +then any manipulation should be abstracted in ASL.
>> +
>> +Each device in ACPI has D-states and these can be controlled through
>> +the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
>> +
>> +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 organise that it is allocated/enabled using the _PS0 method.
>> +
>> +Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
>> +in the _PS3 method.
>> +
>> +Such code in _PS? methods will of course be very platform specific but
>> +should allow the driver to operate the device without special non standard
> 
>                                                                  non-standard
> 
>> +values being read from ASL. Further, abstracting the use of these resources
>> +allows hardware revisions without requiring updates to the kernel.
>> +
>> +TODO: Clarification and examples from Juno implementation.
>> +
>> +Clocks
>> +------
>> +
>> +Like clocks that are part of the power resources there is no standard way
>> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
>> +described in DT.
>> +
>> +Devices affected by this include things like UARTs, SoC driven LCD displays,
>> +etc.
>> +
>> +The firmware for example UEFI should initialise these clocks to fixed working
> 
>                 (for example, UEFI)
> 
>> +values before the kernel is executed. If a driver requires to know rates of
>> +clocks set by firmware then they can be passed to kernel using _DSD.
>> +
>> +example :-
>> +
>> +Device (CLK0) {
>> +	...
>> +
>> +	Name (_DSD, Package() {
>> +		ToUUID("XXXXX"),
>> +		Package() {
>> +			Package(2) {"#clock-cells", 0},
>> +			Package(2) {"clock-frequency", "10000"}
>> +		}
>> +	})
>> +
>> +	...
>> +}
>> +
>> +Device (USR1) {
>> +	...
>> +
>> +	Name (_DSD, Package() {
>> +		ToUUID("XXXXX"),
>> +		Package() {
>> +			Package(2) {"clocks", Package() {1, ^CLK0}}},
>> +		}
>> +	})
>> +
>> +	...
>> +}
>> +			
>> +Driver Recommendations
>> +----------------------
>> +
>> +DO NOT remove any FDT handling when adding ACPI support for a driver, different
> 
>                                                                  driver. Different
> 
>> +systems may use the same device.
>> +
>> +DO try and keep complex sections of ACPI and DT functionality seperate. This
> 
>                                                                  separate.
> 
>> +may mean a patch to break out some complex DT to another function before
>> +the patch to add ACPI. This may happen in other functions but is most likely
>> +in probe function. This gives a clearer flow of data for reviewing driver
>> +source.
>> +
>> +probe() :-
>> +
>> +TODO: replace this with a specific real example from Juno?
>> +
>> +static int device_probe_dt(struct platform_device *pdev)
>> +{
>> +	/* DT specific functionality */
>> +	...
>> +}
>> +
>> +static int device_probe_acpi(struct platform_device *pdev)
>> +{
>> +	/* ACPI specific functionality */
>> +	...
>> +}
>> +
>> +static int device_probe(stuct platform_device *pdev)
>> +{
>> +	...
>> +	acpi_handle handle = ACPI_HANDLE(&pdev->dev);
>> +	struct device_node node = pdev->dev.of_node;
>> +	...
>> +
>> +	if (node)
>> +		ret = device_probe_dt(pdev);
>> +	else if (handle)
>> +		ret = device_probe_acpi(pdev);
>> +	else
>> +		/* other initialisation */
>> +		...
>> +	/* Continue with any generic probe operations */
>> +	...
>> +}
>> +
>> +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
>> +the different names the driver is probed for, both from DT and from ACPI.
>> +
>> +module device tables :-
>> +
>> +static struct of_device_id virtio_mmio_match[] = {
>> +        { .compatible = "virtio,mmio", },
>> +        {},
>> +};
>> +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
>> +
>> +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
>> +        { "LNRO0005", },
>> +        { }
>> +};
>> +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
>> +
>> +TODO: Add any other helpful rules that develop from Juno ACPI work.
>> +
>> +ASWG
>> +----
>> +
>> +The following areas are not yet well defined for ARM in the current ACPI
>> +specification and are expected to be worked through in the UEFI ACPI
>> +Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
>> +Participation in this group is open to all UEFI members.
>> +
>> +	- ACPI based CPU topology
>> +	- ACPI based Power management
>> +	- CPU idle control based on PSCI
>> +	- CPU performance control (CPPC)
>> +
>> +No code shall be accepted into the kernel unless it complies with the released
>> +standards from UEFI ASWG. If there are features missing from ACPI to make it
>> +function on a platform ECRs should be submitted to ASWG and go through the
> 
>             on a platform, ECRs
> 
>> +approval process.
>>
> 
> 

Re: [PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Hanjun Guo]

Hi Naresh,

On 2014-7-25 7:06, Naresh Bhat wrote:
> On 24 July 2014 18:30, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> MADT contains the information for MPIDR which is essential for
>> SMP initialization, parse the GIC cpu interface structures to
>> get the MPIDR value and map it to cpu_logical_map(), and add
>> enabled cpu with valid MPIDR into cpu_possible_map and
>> cpu_present_map.
[...]
>> +/**
>> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
>> + * generates a logic cpu number
> 
> logic - logical

Thanks for all the typos you got, will fix them.

Best Regards
Hanjun

Re: [PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Hanjun Guo]

Hi Naresh,

On 2014-7-25 7:06, Naresh Bhat wrote:
> On 24 July 2014 18:30, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> MADT contains the information for MPIDR which is essential for
>> SMP initialization, parse the GIC cpu interface structures to
>> get the MPIDR value and map it to cpu_logical_map(), and add
>> enabled cpu with valid MPIDR into cpu_possible_map and
>> cpu_present_map.
[...]
>> +/**
>> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
>> + * generates a logic cpu number
> 
> logic - logical

Thanks for all the typos you got, will fix them.

Best Regards
Hanjun

[PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Hanjun Guo]

Hi Naresh,

On 2014-7-25 7:06, Naresh Bhat wrote:
> On 24 July 2014 18:30, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> MADT contains the information for MPIDR which is essential for
>> SMP initialization, parse the GIC cpu interface structures to
>> get the MPIDR value and map it to cpu_logical_map(), and add
>> enabled cpu with valid MPIDR into cpu_possible_map and
>> cpu_present_map.
[...]
>> +/**
>> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
>> + * generates a logic cpu number
> 
> logic - logical

Thanks for all the typos you got, will fix them.

Best Regards
Hanjun

Re: [PATCH 09/19] ARM64 / ACPI: Move the initialization of cpu_logical_map(0) before acpi_boot_init()

[Mark Rutland]

On Fri, Jul 25, 2014 at 11:39:08AM +0100, Hanjun Guo wrote:
> On 2014-7-24 23:21, Mark Rutland wrote:
> > On Thu, Jul 24, 2014 at 02:00:15PM +0100, Hanjun Guo wrote:
> >> Move the initialization of cpu_logical_map(0) before acpi_boot_init()
> >> to remove the duplicated initialization of cpu_logical_map(0).
> > 
> > It always make sense to initialise CPU0's logical map entry from the
> > hardware values, so you could do this earlier in the series, before you
> > introduce any ACPI code. Then you don't have the churn in acpi.c
> 
> ok, I will prepare a separate patch to do this before ACPI code, does it
> make sense to you?

Yes. Just put that at the start of the series.

Thanks,
Mark.

Re: [PATCH 09/19] ARM64 / ACPI: Move the initialization of cpu_logical_map(0) before acpi_boot_init()

[Mark Rutland]

On Fri, Jul 25, 2014 at 11:39:08AM +0100, Hanjun Guo wrote:
> On 2014-7-24 23:21, Mark Rutland wrote:
> > On Thu, Jul 24, 2014 at 02:00:15PM +0100, Hanjun Guo wrote:
> >> Move the initialization of cpu_logical_map(0) before acpi_boot_init()
> >> to remove the duplicated initialization of cpu_logical_map(0).
> > 
> > It always make sense to initialise CPU0's logical map entry from the
> > hardware values, so you could do this earlier in the series, before you
> > introduce any ACPI code. Then you don't have the churn in acpi.c
> 
> ok, I will prepare a separate patch to do this before ACPI code, does it
> make sense to you?

Yes. Just put that at the start of the series.

Thanks,
Mark.

[PATCH 09/19] ARM64 / ACPI: Move the initialization of cpu_logical_map(0) before acpi_boot_init()

[Mark Rutland]

On Fri, Jul 25, 2014 at 11:39:08AM +0100, Hanjun Guo wrote:
> On 2014-7-24 23:21, Mark Rutland wrote:
> > On Thu, Jul 24, 2014 at 02:00:15PM +0100, Hanjun Guo wrote:
> >> Move the initialization of cpu_logical_map(0) before acpi_boot_init()
> >> to remove the duplicated initialization of cpu_logical_map(0).
> > 
> > It always make sense to initialise CPU0's logical map entry from the
> > hardware values, so you could do this earlier in the series, before you
> > introduce any ACPI code. Then you don't have the churn in acpi.c
> 
> ok, I will prepare a separate patch to do this before ACPI code, does it
> make sense to you?

Yes. Just put that at the start of the series.

Thanks,
Mark.

Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Mark Rutland]

On Fri, Jul 25, 2014 at 11:51:37AM +0100, Hanjun Guo wrote:
> On 2014-7-24 23:47, Mark Rutland wrote:
> > On Thu, Jul 24, 2014 at 02:00:16PM +0100, Hanjun Guo wrote:
> >> ACPI 5.1 only has two explicit methods to boot up SMP,
> >> PSCI and Parking protocol, but the Parking protocol is
> >> only suitable for ARMv7 now, so make PSCI as the only way
> >> for the SMP boot protocol before some updates for the
> >> ACPI spec or the Parking protocol spec.
> >>
> >> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> >> ---
> >>  arch/arm64/include/asm/acpi.h    |   21 +++++++++++++++
> >>  arch/arm64/include/asm/cpu_ops.h |    9 ++++++-
> >>  arch/arm64/include/asm/smp.h     |    2 +-
> >>  arch/arm64/kernel/acpi.c         |    9 +++++++
> >>  arch/arm64/kernel/cpu_ops.c      |   52 ++++++++++++++++++++++++++++++++++----
> >>  arch/arm64/kernel/smp.c          |   29 +++++++++++++++++++--
> >>  6 files changed, 113 insertions(+), 9 deletions(-)
> [...]
> >>  /*
> >> - * Setup the set of possible CPUs (via set_cpu_possible)
> >> + * Platform specific SMP operations
> >>   */
> >>  extern void smp_init_cpus(void);
> > 
> > While the originial comment is out of date, the new form is plain wrong.
> > 
> > Something like "Discover the set of possible CPUs and determine their
> > SMP operations" would be a better description of what's going on here.
> 
> Agreed.

Ok.

> > 
> >>
> >> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> >> index ff0f6a0..2af6662 100644
> >> --- a/arch/arm64/kernel/acpi.c
> >> +++ b/arch/arm64/kernel/acpi.c
> >> @@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
> >>         return 0;
> >>  }
> >>
> >> +/* Protocol to bring up secondary CPUs */
> >> +enum acpi_smp_boot_protocol smp_boot_protocol(void)
> >> +{
> >> +       if (acpi_psci_present)
> >> +               return ACPI_SMP_BOOT_PSCI;
> >> +       else
> >> +               return ACPI_SMP_BOOT_PARKING_PROTOCOL;
> >> +}
> >> +
> >>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
> >>  {
> >>         struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> >> diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
> >> index d62d12f..4d9b3cf 100644
> >> --- a/arch/arm64/kernel/cpu_ops.c
> >> +++ b/arch/arm64/kernel/cpu_ops.c
> >> @@ -16,11 +16,13 @@
> >>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >>   */
> >>
> >> -#include <asm/cpu_ops.h>
> >> -#include <asm/smp_plat.h>
> >>  #include <linux/errno.h>
> >>  #include <linux/of.h>
> >>  #include <linux/string.h>
> >> +#include <linux/acpi.h>
> >> +
> >> +#include <asm/cpu_ops.h>
> >> +#include <asm/smp_plat.h>
> > 
> > Was the header move just for consistency with other files, or is there
> > some ordering requirement here?
> 
> Ordering requirement, it will meet compile error for "return -ENODEV;"
> in the head file which I introduced, I know I can include the right
> head file in asm/cpu_ops.h, but I think move the asm/xx.h after the
> include of linux/xx.h would be fine.

If a file uses something defined in a header, it should include that
header. So if you need ENODEV in cpu_ops.h, make cpu_ops.h include
<linux/errno.h>. It is not fine to deliberately rely on implicit
includes.

Moving the headers around is a separate issue. I have no problem with
doing that for consistency with other files.

> 
> > 
> >>
> >>  extern const struct cpu_operations smp_spin_table_ops;
> >>  extern const struct cpu_operations cpu_psci_ops;
> >> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
> >>  /*
> >>   * Read a cpu's enable method from the device tree and record it in cpu_ops.
> >>   */
> >> -int __init cpu_read_ops(struct device_node *dn, int cpu)
> >> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
> >>  {
> >>         const char *enable_method = of_get_property(dn, "enable-method", NULL);
> >>         if (!enable_method) {
> >> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
> >>         return 0;
> >>  }
> >>
> >> +#ifdef CONFIG_ACPI
> >> +/*
> >> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
> >> + */
> >> +int __init cpu_acpi_read_ops(int cpu)
> >> +{
> >> +       /*
> >> +        * For ACPI 5.1, only two kind of methods are provided,
> >> +        * Parking protocol and PSCI, but Parking protocol is
> >> +        * used on ARMv7 only, so make PSCI as the only method
> >> +        * for SMP initialization before the ACPI spec or Parking
> >> +        * protocol spec is updated.
> >> +        */
> > 
> > That comment is a little misleading. The parking protocol is _specified_
> > for ARMv7 only.
> 
> Agreed. But I'm just wondering if the Parking protocol is modified and
> then support ARMv8, how to describe it in the comments?

We update the comments if and when that happens.

> > 
> >> +       switch (smp_boot_protocol()) {
> >> +       case ACPI_SMP_BOOT_PSCI:
> >> +               cpu_ops[cpu] = cpu_get_ops("psci");
> >> +               break;
> >> +       case ACPI_SMP_BOOT_PARKING_PROTOCOL:
> >> +       default:
> >> +               cpu_ops[cpu] = NULL;
> >> +               break;
> >> +       }
> >> +
> >> +       if (!cpu_ops[cpu]) {
> >> +               pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
> >> +                       cpu);
> >> +               return -EOPNOTSUPP;
> >> +       }
> > 
> > That's going to require changes as things get updated, and
> > "enable-method" is a term from DT rather than ACPI.
> > 
> > How about:
> > 
> > 	"CPU%d: boot protocol unsupported or unknown\n".
> 
> Pretty fine to me :)

Ok.

Cheers,
Mark.

[PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Mark Rutland]

On Fri, Jul 25, 2014 at 11:51:37AM +0100, Hanjun Guo wrote:
> On 2014-7-24 23:47, Mark Rutland wrote:
> > On Thu, Jul 24, 2014 at 02:00:16PM +0100, Hanjun Guo wrote:
> >> ACPI 5.1 only has two explicit methods to boot up SMP,
> >> PSCI and Parking protocol, but the Parking protocol is
> >> only suitable for ARMv7 now, so make PSCI as the only way
> >> for the SMP boot protocol before some updates for the
> >> ACPI spec or the Parking protocol spec.
> >>
> >> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> >> ---
> >>  arch/arm64/include/asm/acpi.h    |   21 +++++++++++++++
> >>  arch/arm64/include/asm/cpu_ops.h |    9 ++++++-
> >>  arch/arm64/include/asm/smp.h     |    2 +-
> >>  arch/arm64/kernel/acpi.c         |    9 +++++++
> >>  arch/arm64/kernel/cpu_ops.c      |   52 ++++++++++++++++++++++++++++++++++----
> >>  arch/arm64/kernel/smp.c          |   29 +++++++++++++++++++--
> >>  6 files changed, 113 insertions(+), 9 deletions(-)
> [...]
> >>  /*
> >> - * Setup the set of possible CPUs (via set_cpu_possible)
> >> + * Platform specific SMP operations
> >>   */
> >>  extern void smp_init_cpus(void);
> > 
> > While the originial comment is out of date, the new form is plain wrong.
> > 
> > Something like "Discover the set of possible CPUs and determine their
> > SMP operations" would be a better description of what's going on here.
> 
> Agreed.

Ok.

> > 
> >>
> >> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> >> index ff0f6a0..2af6662 100644
> >> --- a/arch/arm64/kernel/acpi.c
> >> +++ b/arch/arm64/kernel/acpi.c
> >> @@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
> >>         return 0;
> >>  }
> >>
> >> +/* Protocol to bring up secondary CPUs */
> >> +enum acpi_smp_boot_protocol smp_boot_protocol(void)
> >> +{
> >> +       if (acpi_psci_present)
> >> +               return ACPI_SMP_BOOT_PSCI;
> >> +       else
> >> +               return ACPI_SMP_BOOT_PARKING_PROTOCOL;
> >> +}
> >> +
> >>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
> >>  {
> >>         struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> >> diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
> >> index d62d12f..4d9b3cf 100644
> >> --- a/arch/arm64/kernel/cpu_ops.c
> >> +++ b/arch/arm64/kernel/cpu_ops.c
> >> @@ -16,11 +16,13 @@
> >>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >>   */
> >>
> >> -#include <asm/cpu_ops.h>
> >> -#include <asm/smp_plat.h>
> >>  #include <linux/errno.h>
> >>  #include <linux/of.h>
> >>  #include <linux/string.h>
> >> +#include <linux/acpi.h>
> >> +
> >> +#include <asm/cpu_ops.h>
> >> +#include <asm/smp_plat.h>
> > 
> > Was the header move just for consistency with other files, or is there
> > some ordering requirement here?
> 
> Ordering requirement, it will meet compile error for "return -ENODEV;"
> in the head file which I introduced, I know I can include the right
> head file in asm/cpu_ops.h, but I think move the asm/xx.h after the
> include of linux/xx.h would be fine.

If a file uses something defined in a header, it should include that
header. So if you need ENODEV in cpu_ops.h, make cpu_ops.h include
<linux/errno.h>. It is not fine to deliberately rely on implicit
includes.

Moving the headers around is a separate issue. I have no problem with
doing that for consistency with other files.

> 
> > 
> >>
> >>  extern const struct cpu_operations smp_spin_table_ops;
> >>  extern const struct cpu_operations cpu_psci_ops;
> >> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
> >>  /*
> >>   * Read a cpu's enable method from the device tree and record it in cpu_ops.
> >>   */
> >> -int __init cpu_read_ops(struct device_node *dn, int cpu)
> >> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
> >>  {
> >>         const char *enable_method = of_get_property(dn, "enable-method", NULL);
> >>         if (!enable_method) {
> >> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
> >>         return 0;
> >>  }
> >>
> >> +#ifdef CONFIG_ACPI
> >> +/*
> >> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
> >> + */
> >> +int __init cpu_acpi_read_ops(int cpu)
> >> +{
> >> +       /*
> >> +        * For ACPI 5.1, only two kind of methods are provided,
> >> +        * Parking protocol and PSCI, but Parking protocol is
> >> +        * used on ARMv7 only, so make PSCI as the only method
> >> +        * for SMP initialization before the ACPI spec or Parking
> >> +        * protocol spec is updated.
> >> +        */
> > 
> > That comment is a little misleading. The parking protocol is _specified_
> > for ARMv7 only.
> 
> Agreed. But I'm just wondering if the Parking protocol is modified and
> then support ARMv8, how to describe it in the comments?

We update the comments if and when that happens.

> > 
> >> +       switch (smp_boot_protocol()) {
> >> +       case ACPI_SMP_BOOT_PSCI:
> >> +               cpu_ops[cpu] = cpu_get_ops("psci");
> >> +               break;
> >> +       case ACPI_SMP_BOOT_PARKING_PROTOCOL:
> >> +       default:
> >> +               cpu_ops[cpu] = NULL;
> >> +               break;
> >> +       }
> >> +
> >> +       if (!cpu_ops[cpu]) {
> >> +               pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
> >> +                       cpu);
> >> +               return -EOPNOTSUPP;
> >> +       }
> > 
> > That's going to require changes as things get updated, and
> > "enable-method" is a term from DT rather than ACPI.
> > 
> > How about:
> > 
> > 	"CPU%d: boot protocol unsupported or unknown\n".
> 
> Pretty fine to me :)

Ok.

Cheers,
Mark.

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> From: Graeme Gregory <graeme.gregory@linaro.org>
>
> Add documentation for the guidelines of how to use ACPI
> on ARM64.

As the most vocal participant against ACPI being adopted, I would have
appreciated a cc on this patch set -- it's not like you were going for
a minimal set of cc recipients already. It makes it seem like you're
trying to sneak it past me for comments. Not cool. I know that's
probably not your intent, but still.

Some comments below. Overall the doc looks pretty good, but the
details about _DSD and clocks are somewhat worrisome.

> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 240 insertions(+)
>  create mode 100644 Documentation/arm64/arm-acpi.txt
>
> diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> new file mode 100644
> index 0000000..12cd550
> --- /dev/null
> +++ b/Documentation/arm64/arm-acpi.txt
> @@ -0,0 +1,240 @@
> +ACPI on ARMv8 Servers
> +---------------------
> +
> +ACPI will be used for ARMv8 general purpose servers designed to follow

"ACPI might be used"    or     "can be used"

> +the SBSA specification (currently available to people with an ARM login at
> +http://silver.arm.com)
> +
> +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> +which is available at <http://www.uefi.org/acpi/specs>.

The implemented version where? The kernel implements that version?
Worth clarifying.

> +If the machine does not meet these requirements then it is likely that Device
> +Tree (DT) is more suitable for the hardware.

This is should be a very clear statement that is currently vague
w.r.t. which requirements are met or not, especially based on the
sentence above.

> +Relationship with Device Tree
> +-----------------------------
> +
> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> +exclusive with DT support at compile time.
> +
> +At boot time the kernel will only use one description method depending on
> +parameters passed from the bootloader.

Possibly overriden by kernel bootargs. And as debated for quite a
while earlier this year, acpi should still default to off -- if a DT
and ACPI are both passed in, DT should at this time be given priority.

(Where can I learn more about how the boot loaders currently handle
this? Do some of them pass in both DT and ACPI on some platforms, for
example?)


> +Regardless of whether DT or ACPI is used, the kernel must always be capable
> +of booting with either scheme.

It should always be possible to compile out ACPI. There will be plenty
of platforms that will not implement it, so disabling CONFIG_ACPI
needs to be possible.

> +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.
> +
> +Booting using ACPI tables
> +-------------------------
> +
> +Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
> +is via the UEFI system configuration table.
> +
> +The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
> +RSDP table (the table with the ACPI signature "RSD PTR ").
> +
> +The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
> +
> +Processing of ACPI tables may be disabled by passing acpi=off on the kernel
> +command line.
> +
> +DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
> +only allow for 32bit addresses.
> +
> +DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
> +64-bit alternatives MUST be used.
> +
> +The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
> +and GTDT. If PCI is used the MCFG table MUST also be present.
> +
> +ACPI Detection
> +--------------
> +
> +Drivers should determine their probe() type by checking for ACPI_HANDLE,
> +or .of_node, or other information in the device structure. This is
> +detailed further in the "Driver Recomendations" section.
> +
> +If the presence of ACPI needs to be detected at runtime, then check the value
> +of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.

Just to make sure, if acpi_disabled is 0, then there will be no acpi
handle associated with the device, right? I.e. there should be no need
to have every single driver check for whether ACPI is disabled, the
handle check should just fail instead.

> +Device Enumeration
> +------------------
> +
> +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> +These are far simpler than the information provided via Device Tree. Drivers
> +should take into account this simplicity and work with sensible defaults.
> +
> +On no account should a Device Tree attempt to be replicated in ASL using such
> +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.

I see these two sentences as contradictory, given that the _DSD doc
linked below contains examples that mirror over several properties,
such as "linux,default-trigger" and other LED-specific properties.
(section 2.4.2 in the below doc). "default-state" seems to come from
DT too?

Care to elaborate and explain what the intention here is? This could
worst case turn into quite a mess.

Given that ACPI can present completely different data based on what OS
is running, it's quite common to indeed have OS specific data in
there. How does that relate to this document and these practices?

> +Common _DSD bindings should be submitted to ASWG to be included in the
> +document :-
> +
> +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm

So, for these that are a mirror of the device tree bindings, there
needs to be a wording here around reviewing the DT binding first so we
don't get diverging bindings.

> +TODO: Clarification and examples from Juno implementation.
> +
> +Programmable Power Control Resources
> +------------------------------------
> +
> +Programmable power control resources include such resources as voltage/current
> +providers (regulators) and clock sources.
> +
> +For power control of these resources they should be represented with Power
> +Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
> +enabling/disabling of resources as they are needed.
> +
> +There exists in the ACPI 5.1 specification no standard binding for these objects
> +to enable programmable levels or rates so this should be avoid if possible and
> +the resources set to appropriate level by the firmware. If this is not possible
> +then any manipulation should be abstracted in ASL.
> +
> +Each device in ACPI has D-states and these can be controlled through
> +the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
> +
> +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 organise that it is allocated/enabled using the _PS0 method.
> +
> +Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
> +in the _PS3 method.
> +
> +Such code in _PS? methods will of course be very platform specific but
> +should allow the driver to operate the device without special non standard
> +values being read from ASL. Further, abstracting the use of these resources
> +allows hardware revisions without requiring updates to the kernel.
> +
> +TODO: Clarification and examples from Juno implementation.
> +
> +Clocks
> +------
> +
> +Like clocks that are part of the power resources there is no standard way
> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
> +described in DT.
> +
> +Devices affected by this include things like UARTs, SoC driven LCD displays,
> +etc.
> +
> +The firmware for example UEFI should initialise these clocks to fixed working

Odd wording.  Maube "The firmware (for example UEFI) should..."

> +values before the kernel is executed. If a driver requires to know rates of
> +clocks set by firmware then they can be passed to kernel using _DSD.
> +
> +example :-
> +
> +Device (CLK0) {
> +       ...
> +
> +       Name (_DSD, Package() {
> +               ToUUID("XXXXX"),
> +               Package() {
> +                       Package(2) {"#clock-cells", 0},

Clock-cells? What do they mean here? Is this specified in the ACPI
standards? I had to register to get access to it, and didn't feel like
doing that right now. I guess it's not _all_ that open a spec. :(

> +                       Package(2) {"clock-frequency", "10000"}
> +               }
> +       })
> +
> +       ...
> +}
> +
> +Device (USR1) {
> +       ...
> +
> +       Name (_DSD, Package() {
> +               ToUUID("XXXXX"),
> +               Package() {
> +                       Package(2) {"clocks", Package() {1, ^CLK0}}},

A clock is a device in the ACPI model? Why not just provide the rate
as data into the device here? You said you're not trying to model the
clock tree, so why reference an external node for it?

> +               }
> +       })
> +
> +       ...
> +}
> +
> +Driver Recommendations
> +----------------------
> +
> +DO NOT remove any FDT handling when adding ACPI support for a driver, different
> +systems may use the same device.
> +
> +DO try and keep complex sections of ACPI and DT functionality seperate. This
> +may mean a patch to break out some complex DT to another function before
> +the patch to add ACPI. This may happen in other functions but is most likely
> +in probe function. This gives a clearer flow of data for reviewing driver
> +source.
> +
> +probe() :-
> +
> +TODO: replace this with a specific real example from Juno?
> +
> +static int device_probe_dt(struct platform_device *pdev)
> +{
> +       /* DT specific functionality */
> +       ...
> +}
> +
> +static int device_probe_acpi(struct platform_device *pdev)
> +{
> +       /* ACPI specific functionality */
> +       ...
> +}
> +
> +static int device_probe(stuct platform_device *pdev)
> +{
> +       ...
> +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
> +       struct device_node node = pdev->dev.of_node;
> +       ...
> +
> +       if (node)
> +               ret = device_probe_dt(pdev);
> +       else if (handle)
> +               ret = device_probe_acpi(pdev);
> +       else
> +               /* other initialisation */
> +               ...
> +       /* Continue with any generic probe operations */
> +       ...
> +}

This looks good to me, and it's also my preferred way of ACPI-enabling
drivers. I guess we might discuss this at KS since it was a proposed
topic there, and others will object. :)

> +
> +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
> +the different names the driver is probed for, both from DT and from ACPI.
> +
> +module device tables :-
> +
> +static struct of_device_id virtio_mmio_match[] = {
> +        { .compatible = "virtio,mmio", },
> +        {},
> +};
> +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
> +
> +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
> +        { "LNRO0005", },
> +        { }

No comma here, but a comma on DT. Probably make them equivalent for
consistency (including space between the braces).

> +};
> +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
> +
> +TODO: Add any other helpful rules that develop from Juno ACPI work.

Looks like this should be fixed before the patch is merged, or this
TODO removed.

> +
> +ASWG
> +----
> +
> +The following areas are not yet well defined for ARM in the current ACPI
> +specification and are expected to be worked through in the UEFI ACPI
> +Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
> +Participation in this group is open to all UEFI members.
> +
> +       - ACPI based CPU topology
> +       - ACPI based Power management
> +       - CPU idle control based on PSCI
> +       - CPU performance control (CPPC)
> +
> +No code shall be accepted into the kernel unless it complies with the released
> +standards from UEFI ASWG. If there are features missing from ACPI to make it
> +function on a platform ECRs should be submitted to ASWG and go through the
> +approval process.

Thanks for listing the things that are not in place yet. Please keep
this doc up to date as new areas are discovered.


-Olof

[PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> From: Graeme Gregory <graeme.gregory@linaro.org>
>
> Add documentation for the guidelines of how to use ACPI
> on ARM64.

As the most vocal participant against ACPI being adopted, I would have
appreciated a cc on this patch set -- it's not like you were going for
a minimal set of cc recipients already. It makes it seem like you're
trying to sneak it past me for comments. Not cool. I know that's
probably not your intent, but still.

Some comments below. Overall the doc looks pretty good, but the
details about _DSD and clocks are somewhat worrisome.

> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 240 insertions(+)
>  create mode 100644 Documentation/arm64/arm-acpi.txt
>
> diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> new file mode 100644
> index 0000000..12cd550
> --- /dev/null
> +++ b/Documentation/arm64/arm-acpi.txt
> @@ -0,0 +1,240 @@
> +ACPI on ARMv8 Servers
> +---------------------
> +
> +ACPI will be used for ARMv8 general purpose servers designed to follow

"ACPI might be used"    or     "can be used"

> +the SBSA specification (currently available to people with an ARM login at
> +http://silver.arm.com)
> +
> +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> +which is available at <http://www.uefi.org/acpi/specs>.

The implemented version where? The kernel implements that version?
Worth clarifying.

> +If the machine does not meet these requirements then it is likely that Device
> +Tree (DT) is more suitable for the hardware.

This is should be a very clear statement that is currently vague
w.r.t. which requirements are met or not, especially based on the
sentence above.

> +Relationship with Device Tree
> +-----------------------------
> +
> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> +exclusive with DT support at compile time.
> +
> +At boot time the kernel will only use one description method depending on
> +parameters passed from the bootloader.

Possibly overriden by kernel bootargs. And as debated for quite a
while earlier this year, acpi should still default to off -- if a DT
and ACPI are both passed in, DT should at this time be given priority.

(Where can I learn more about how the boot loaders currently handle
this? Do some of them pass in both DT and ACPI on some platforms, for
example?)


> +Regardless of whether DT or ACPI is used, the kernel must always be capable
> +of booting with either scheme.

It should always be possible to compile out ACPI. There will be plenty
of platforms that will not implement it, so disabling CONFIG_ACPI
needs to be possible.

> +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.
> +
> +Booting using ACPI tables
> +-------------------------
> +
> +Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
> +is via the UEFI system configuration table.
> +
> +The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
> +RSDP table (the table with the ACPI signature "RSD PTR ").
> +
> +The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
> +
> +Processing of ACPI tables may be disabled by passing acpi=off on the kernel
> +command line.
> +
> +DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
> +only allow for 32bit addresses.
> +
> +DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
> +64-bit alternatives MUST be used.
> +
> +The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
> +and GTDT. If PCI is used the MCFG table MUST also be present.
> +
> +ACPI Detection
> +--------------
> +
> +Drivers should determine their probe() type by checking for ACPI_HANDLE,
> +or .of_node, or other information in the device structure. This is
> +detailed further in the "Driver Recomendations" section.
> +
> +If the presence of ACPI needs to be detected at runtime, then check the value
> +of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.

Just to make sure, if acpi_disabled is 0, then there will be no acpi
handle associated with the device, right? I.e. there should be no need
to have every single driver check for whether ACPI is disabled, the
handle check should just fail instead.

> +Device Enumeration
> +------------------
> +
> +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> +These are far simpler than the information provided via Device Tree. Drivers
> +should take into account this simplicity and work with sensible defaults.
> +
> +On no account should a Device Tree attempt to be replicated in ASL using such
> +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.

I see these two sentences as contradictory, given that the _DSD doc
linked below contains examples that mirror over several properties,
such as "linux,default-trigger" and other LED-specific properties.
(section 2.4.2 in the below doc). "default-state" seems to come from
DT too?

Care to elaborate and explain what the intention here is? This could
worst case turn into quite a mess.

Given that ACPI can present completely different data based on what OS
is running, it's quite common to indeed have OS specific data in
there. How does that relate to this document and these practices?

> +Common _DSD bindings should be submitted to ASWG to be included in the
> +document :-
> +
> +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm

So, for these that are a mirror of the device tree bindings, there
needs to be a wording here around reviewing the DT binding first so we
don't get diverging bindings.

> +TODO: Clarification and examples from Juno implementation.
> +
> +Programmable Power Control Resources
> +------------------------------------
> +
> +Programmable power control resources include such resources as voltage/current
> +providers (regulators) and clock sources.
> +
> +For power control of these resources they should be represented with Power
> +Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
> +enabling/disabling of resources as they are needed.
> +
> +There exists in the ACPI 5.1 specification no standard binding for these objects
> +to enable programmable levels or rates so this should be avoid if possible and
> +the resources set to appropriate level by the firmware. If this is not possible
> +then any manipulation should be abstracted in ASL.
> +
> +Each device in ACPI has D-states and these can be controlled through
> +the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
> +
> +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 organise that it is allocated/enabled using the _PS0 method.
> +
> +Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
> +in the _PS3 method.
> +
> +Such code in _PS? methods will of course be very platform specific but
> +should allow the driver to operate the device without special non standard
> +values being read from ASL. Further, abstracting the use of these resources
> +allows hardware revisions without requiring updates to the kernel.
> +
> +TODO: Clarification and examples from Juno implementation.
> +
> +Clocks
> +------
> +
> +Like clocks that are part of the power resources there is no standard way
> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
> +described in DT.
> +
> +Devices affected by this include things like UARTs, SoC driven LCD displays,
> +etc.
> +
> +The firmware for example UEFI should initialise these clocks to fixed working

Odd wording.  Maube "The firmware (for example UEFI) should..."

> +values before the kernel is executed. If a driver requires to know rates of
> +clocks set by firmware then they can be passed to kernel using _DSD.
> +
> +example :-
> +
> +Device (CLK0) {
> +       ...
> +
> +       Name (_DSD, Package() {
> +               ToUUID("XXXXX"),
> +               Package() {
> +                       Package(2) {"#clock-cells", 0},

Clock-cells? What do they mean here? Is this specified in the ACPI
standards? I had to register to get access to it, and didn't feel like
doing that right now. I guess it's not _all_ that open a spec. :(

> +                       Package(2) {"clock-frequency", "10000"}
> +               }
> +       })
> +
> +       ...
> +}
> +
> +Device (USR1) {
> +       ...
> +
> +       Name (_DSD, Package() {
> +               ToUUID("XXXXX"),
> +               Package() {
> +                       Package(2) {"clocks", Package() {1, ^CLK0}}},

A clock is a device in the ACPI model? Why not just provide the rate
as data into the device here? You said you're not trying to model the
clock tree, so why reference an external node for it?

> +               }
> +       })
> +
> +       ...
> +}
> +
> +Driver Recommendations
> +----------------------
> +
> +DO NOT remove any FDT handling when adding ACPI support for a driver, different
> +systems may use the same device.
> +
> +DO try and keep complex sections of ACPI and DT functionality seperate. This
> +may mean a patch to break out some complex DT to another function before
> +the patch to add ACPI. This may happen in other functions but is most likely
> +in probe function. This gives a clearer flow of data for reviewing driver
> +source.
> +
> +probe() :-
> +
> +TODO: replace this with a specific real example from Juno?
> +
> +static int device_probe_dt(struct platform_device *pdev)
> +{
> +       /* DT specific functionality */
> +       ...
> +}
> +
> +static int device_probe_acpi(struct platform_device *pdev)
> +{
> +       /* ACPI specific functionality */
> +       ...
> +}
> +
> +static int device_probe(stuct platform_device *pdev)
> +{
> +       ...
> +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
> +       struct device_node node = pdev->dev.of_node;
> +       ...
> +
> +       if (node)
> +               ret = device_probe_dt(pdev);
> +       else if (handle)
> +               ret = device_probe_acpi(pdev);
> +       else
> +               /* other initialisation */
> +               ...
> +       /* Continue with any generic probe operations */
> +       ...
> +}

This looks good to me, and it's also my preferred way of ACPI-enabling
drivers. I guess we might discuss this at KS since it was a proposed
topic there, and others will object. :)

> +
> +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
> +the different names the driver is probed for, both from DT and from ACPI.
> +
> +module device tables :-
> +
> +static struct of_device_id virtio_mmio_match[] = {
> +        { .compatible = "virtio,mmio", },
> +        {},
> +};
> +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
> +
> +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
> +        { "LNRO0005", },
> +        { }

No comma here, but a comma on DT. Probably make them equivalent for
consistency (including space between the braces).

> +};
> +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
> +
> +TODO: Add any other helpful rules that develop from Juno ACPI work.

Looks like this should be fixed before the patch is merged, or this
TODO removed.

> +
> +ASWG
> +----
> +
> +The following areas are not yet well defined for ARM in the current ACPI
> +specification and are expected to be worked through in the UEFI ACPI
> +Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
> +Participation in this group is open to all UEFI members.
> +
> +       - ACPI based CPU topology
> +       - ACPI based Power management
> +       - CPU idle control based on PSCI
> +       - CPU performance control (CPPC)
> +
> +No code shall be accepted into the kernel unless it complies with the released
> +standards from UEFI ASWG. If there are features missing from ACPI to make it
> +function on a platform ECRs should be submitted to ASWG and go through the
> +approval process.

Thanks for listing the things that are not in place yet. Please keep
this doc up to date as new areas are discovered.


-Olof

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Graeme Gregory]

On 27/07/2014 03:34, Olof Johansson wrote:
> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> From: Graeme Gregory <graeme.gregory@linaro.org>
>>
>> Add documentation for the guidelines of how to use ACPI
>> on ARM64.
> As the most vocal participant against ACPI being adopted, I would have
> appreciated a cc on this patch set -- it's not like you were going for
> a minimal set of cc recipients already. It makes it seem like you're
> trying to sneak it past me for comments. Not cool. I know that's
> probably not your intent, but still.
>
> Some comments below. Overall the doc looks pretty good, but the
> details about _DSD and clocks are somewhat worrisome.
>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 240 insertions(+)
>>   create mode 100644 Documentation/arm64/arm-acpi.txt
>>
>> diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
>> new file mode 100644
>> index 0000000..12cd550
>> --- /dev/null
>> +++ b/Documentation/arm64/arm-acpi.txt
>> @@ -0,0 +1,240 @@
>> +ACPI on ARMv8 Servers
>> +---------------------
>> +
>> +ACPI will be used for ARMv8 general purpose servers designed to follow
> "ACPI might be used"    or     "can be used"
>
>> +the SBSA specification (currently available to people with an ARM login at
>> +http://silver.arm.com)
>> +
>> +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
>> +which is available at <http://www.uefi.org/acpi/specs>.
> The implemented version where? The kernel implements that version?
> Worth clarifying.
ok

the tables passed must be acpi 5.1+, the kernel must then obviously 
implement the 5.1 features, will clarify.
>> +If the machine does not meet these requirements then it is likely that Device
>> +Tree (DT) is more suitable for the hardware.
> This is should be a very clear statement that is currently vague
> w.r.t. which requirements are met or not, especially based on the
> sentence above.
The SBSA is the set of requirements, will clarify.

>> +Relationship with Device Tree
>> +-----------------------------
>> +
>> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>> +exclusive with DT support at compile time.
>> +
>> +At boot time the kernel will only use one description method depending on
>> +parameters passed from the bootloader.
> Possibly overriden by kernel bootargs. And as debated for quite a
> while earlier this year, acpi should still default to off -- if a DT
> and ACPI are both passed in, DT should at this time be given priority.
This does not work due to DT being misused as the kernel/bootloader 
communication layer as well. So a DT is always passed to the kernel. We 
cannot tell whether this is a useful DT without unpacking it and trying 
to boot platform from it.

There is an acpi=off parameter that can be passed to always disable acpi 
runtime.
> (Where can I learn more about how the boot loaders currently handle
> this? Do some of them pass in both DT and ACPI on some platforms, for
> example?)
Currently only one bootloader protocol is supported for ACPI and thats 
UEFI. As noted above due to abuse of DT in the /chosen/ node a DT is 
always passed to the kernel.

>> +Regardless of whether DT or ACPI is used, the kernel must always be capable
>> +of booting with either scheme.
> It should always be possible to compile out ACPI. There will be plenty
> of platforms that will not implement it, so disabling CONFIG_ACPI
> needs to be possible.
This will always be possible!
>> +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.
>> +
>> +Booting using ACPI tables
>> +-------------------------
>> +
>> +Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
>> +is via the UEFI system configuration table.
>> +
>> +The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
>> +RSDP table (the table with the ACPI signature "RSD PTR ").
>> +
>> +The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
>> +
>> +Processing of ACPI tables may be disabled by passing acpi=off on the kernel
>> +command line.
>> +
>> +DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
>> +only allow for 32bit addresses.
>> +
>> +DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
>> +64-bit alternatives MUST be used.
>> +
>> +The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
>> +and GTDT. If PCI is used the MCFG table MUST also be present.
>> +
>> +ACPI Detection
>> +--------------
>> +
>> +Drivers should determine their probe() type by checking for ACPI_HANDLE,
>> +or .of_node, or other information in the device structure. This is
>> +detailed further in the "Driver Recomendations" section.
>> +
>> +If the presence of ACPI needs to be detected at runtime, then check the value
>> +of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
> Just to make sure, if acpi_disabled is 0, then there will be no acpi
> handle associated with the device, right? I.e. there should be no need
> to have every single driver check for whether ACPI is disabled, the
> handle check should just fail instead.
I need to clarify this obviously, I meant for the second paragraph for 
that to be for code outside driver probing. Inside drivers they should 
only check for ACPI_HANDLE presence. But other bits of code espcially 
bits parsing tables for information in early boot should check for 
acpi_disabled before hunting for the tables etc.
>> +Device Enumeration
>> +------------------
>> +
>> +Device descriptions in ACPI should use standard recognised ACPI interfaces.
>> +These are far simpler than the information provided via Device Tree. Drivers
>> +should take into account this simplicity and work with sensible defaults.
>> +
>> +On no account should a Device Tree attempt to be replicated in ASL using such
>> +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
>> +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
>> +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
> I see these two sentences as contradictory, given that the _DSD doc
> linked below contains examples that mirror over several properties,
> such as "linux,default-trigger" and other LED-specific properties.
> (section 2.4.2 in the below doc). "default-state" seems to come from
> DT too?
>
> Care to elaborate and explain what the intention here is? This could
> worst case turn into quite a mess.
>
> Given that ACPI can present completely different data based on what OS
> is running, it's quite common to indeed have OS specific data in
> there. How does that relate to this document and these practices?
OS specific data has traditionally not worked out well for ACPI, I would 
like to "persuade" people not to use it on ARM.

The _DSD was quite late to the standards process and the supporting 
documentation is still catching up. We are working with ARM to bring 
these issues up and to define proper OS agnostic bindings for ARM.
>> +Common _DSD bindings should be submitted to ASWG to be included in the
>> +document :-
>> +
>> +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
> So, for these that are a mirror of the device tree bindings, there
> needs to be a wording here around reviewing the DT binding first so we
> don't get diverging bindings.
>
>> +TODO: Clarification and examples from Juno implementation.
>> +
>> +Programmable Power Control Resources
>> +------------------------------------
>> +
>> +Programmable power control resources include such resources as voltage/current
>> +providers (regulators) and clock sources.
>> +
>> +For power control of these resources they should be represented with Power
>> +Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
>> +enabling/disabling of resources as they are needed.
>> +
>> +There exists in the ACPI 5.1 specification no standard binding for these objects
>> +to enable programmable levels or rates so this should be avoid if possible and
>> +the resources set to appropriate level by the firmware. If this is not possible
>> +then any manipulation should be abstracted in ASL.
>> +
>> +Each device in ACPI has D-states and these can be controlled through
>> +the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
>> +
>> +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 organise that it is allocated/enabled using the _PS0 method.
>> +
>> +Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
>> +in the _PS3 method.
>> +
>> +Such code in _PS? methods will of course be very platform specific but
>> +should allow the driver to operate the device without special non standard
>> +values being read from ASL. Further, abstracting the use of these resources
>> +allows hardware revisions without requiring updates to the kernel.
>> +
>> +TODO: Clarification and examples from Juno implementation.
>> +
>> +Clocks
>> +------
>> +
>> +Like clocks that are part of the power resources there is no standard way
>> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
>> +described in DT.
>> +
>> +Devices affected by this include things like UARTs, SoC driven LCD displays,
>> +etc.
>> +
>> +The firmware for example UEFI should initialise these clocks to fixed working
> Odd wording.  Maube "The firmware (for example UEFI) should..."
agreed!
>> +values before the kernel is executed. If a driver requires to know rates of
>> +clocks set by firmware then they can be passed to kernel using _DSD.
>> +
>> +example :-
>> +
>> +Device (CLK0) {
>> +       ...
>> +
>> +       Name (_DSD, Package() {
>> +               ToUUID("XXXXX"),
>> +               Package() {
>> +                       Package(2) {"#clock-cells", 0},
> Clock-cells? What do they mean here? Is this specified in the ACPI
> standards? I had to register to get access to it, and didn't feel like
> doing that right now. I guess it's not _all_ that open a spec. :(
>
>> +                       Package(2) {"clock-frequency", "10000"}
>> +               }
>> +       })
>> +
>> +       ...
>> +}
>> +
>> +Device (USR1) {
>> +       ...
>> +
>> +       Name (_DSD, Package() {
>> +               ToUUID("XXXXX"),
>> +               Package() {
>> +                       Package(2) {"clocks", Package() {1, ^CLK0}}},
> A clock is a device in the ACPI model? Why not just provide the rate
> as data into the device here? You said you're not trying to model the
> clock tree, so why reference an external node for it?
This section is still a bit WIP due to the above noted issues with _DSD 
documentation catching up with the standards process. I will need to 
work with the clock maintainers to see if we can agree a proper set of 
bindings for this. #blah-cells always was my least favorite DT feature.

>> +               }
>> +       })
>> +
>> +       ...
>> +}
>> +
>> +Driver Recommendations
>> +----------------------
>> +
>> +DO NOT remove any FDT handling when adding ACPI support for a driver, different
>> +systems may use the same device.
>> +
>> +DO try and keep complex sections of ACPI and DT functionality seperate. This
>> +may mean a patch to break out some complex DT to another function before
>> +the patch to add ACPI. This may happen in other functions but is most likely
>> +in probe function. This gives a clearer flow of data for reviewing driver
>> +source.
>> +
>> +probe() :-
>> +
>> +TODO: replace this with a specific real example from Juno?
>> +
>> +static int device_probe_dt(struct platform_device *pdev)
>> +{
>> +       /* DT specific functionality */
>> +       ...
>> +}
>> +
>> +static int device_probe_acpi(struct platform_device *pdev)
>> +{
>> +       /* ACPI specific functionality */
>> +       ...
>> +}
>> +
>> +static int device_probe(stuct platform_device *pdev)
>> +{
>> +       ...
>> +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
>> +       struct device_node node = pdev->dev.of_node;
>> +       ...
>> +
>> +       if (node)
>> +               ret = device_probe_dt(pdev);
>> +       else if (handle)
>> +               ret = device_probe_acpi(pdev);
>> +       else
>> +               /* other initialisation */
>> +               ...
>> +       /* Continue with any generic probe operations */
>> +       ...
>> +}
> This looks good to me, and it's also my preferred way of ACPI-enabling
> drivers. I guess we might discuss this at KS since it was a proposed
> topic there, and others will object. :)
Hopefully someone can summarise the discussion at KS for me, I will not 
be there.
>> +
>> +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
>> +the different names the driver is probed for, both from DT and from ACPI.
>> +
>> +module device tables :-
>> +
>> +static struct of_device_id virtio_mmio_match[] = {
>> +        { .compatible = "virtio,mmio", },
>> +        {},
>> +};
>> +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
>> +
>> +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
>> +        { "LNRO0005", },
>> +        { }
> No comma here, but a comma on DT. Probably make them equivalent for
> consistency (including space between the braces).
ok
>> +};
>> +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
>> +
>> +TODO: Add any other helpful rules that develop from Juno ACPI work.
> Looks like this should be fixed before the patch is merged, or this
> TODO removed.
The plan is to fix these TODOs with actual data from Juno as that will 
be in the UEFI for Juno.
>> +
>> +ASWG
>> +----
>> +
>> +The following areas are not yet well defined for ARM in the current ACPI
>> +specification and are expected to be worked through in the UEFI ACPI
>> +Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
>> +Participation in this group is open to all UEFI members.
>> +
>> +       - ACPI based CPU topology
>> +       - ACPI based Power management
>> +       - CPU idle control based on PSCI
>> +       - CPU performance control (CPPC)
>> +
>> +No code shall be accepted into the kernel unless it complies with the released
>> +standards from UEFI ASWG. If there are features missing from ACPI to make it
>> +function on a platform ECRs should be submitted to ASWG and go through the
>> +approval process.
> Thanks for listing the things that are not in place yet. Please keep
> this doc up to date as new areas are discovered.
>
>
> -Olof
Thanks for the feedback, we shall work to incorporate it into the document.

Graeme

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Graeme Gregory]

On 27/07/2014 03:34, Olof Johansson wrote:
> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> From: Graeme Gregory <graeme.gregory@linaro.org>
>>
>> Add documentation for the guidelines of how to use ACPI
>> on ARM64.
> As the most vocal participant against ACPI being adopted, I would have
> appreciated a cc on this patch set -- it's not like you were going for
> a minimal set of cc recipients already. It makes it seem like you're
> trying to sneak it past me for comments. Not cool. I know that's
> probably not your intent, but still.
>
> Some comments below. Overall the doc looks pretty good, but the
> details about _DSD and clocks are somewhat worrisome.
>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 240 insertions(+)
>>   create mode 100644 Documentation/arm64/arm-acpi.txt
>>
>> diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
>> new file mode 100644
>> index 0000000..12cd550
>> --- /dev/null
>> +++ b/Documentation/arm64/arm-acpi.txt
>> @@ -0,0 +1,240 @@
>> +ACPI on ARMv8 Servers
>> +---------------------
>> +
>> +ACPI will be used for ARMv8 general purpose servers designed to follow
> "ACPI might be used"    or     "can be used"
>
>> +the SBSA specification (currently available to people with an ARM login at
>> +http://silver.arm.com)
>> +
>> +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
>> +which is available at <http://www.uefi.org/acpi/specs>.
> The implemented version where? The kernel implements that version?
> Worth clarifying.
ok

the tables passed must be acpi 5.1+, the kernel must then obviously 
implement the 5.1 features, will clarify.
>> +If the machine does not meet these requirements then it is likely that Device
>> +Tree (DT) is more suitable for the hardware.
> This is should be a very clear statement that is currently vague
> w.r.t. which requirements are met or not, especially based on the
> sentence above.
The SBSA is the set of requirements, will clarify.

>> +Relationship with Device Tree
>> +-----------------------------
>> +
>> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>> +exclusive with DT support at compile time.
>> +
>> +At boot time the kernel will only use one description method depending on
>> +parameters passed from the bootloader.
> Possibly overriden by kernel bootargs. And as debated for quite a
> while earlier this year, acpi should still default to off -- if a DT
> and ACPI are both passed in, DT should at this time be given priority.
This does not work due to DT being misused as the kernel/bootloader 
communication layer as well. So a DT is always passed to the kernel. We 
cannot tell whether this is a useful DT without unpacking it and trying 
to boot platform from it.

There is an acpi=off parameter that can be passed to always disable acpi 
runtime.
> (Where can I learn more about how the boot loaders currently handle
> this? Do some of them pass in both DT and ACPI on some platforms, for
> example?)
Currently only one bootloader protocol is supported for ACPI and thats 
UEFI. As noted above due to abuse of DT in the /chosen/ node a DT is 
always passed to the kernel.

>> +Regardless of whether DT or ACPI is used, the kernel must always be capable
>> +of booting with either scheme.
> It should always be possible to compile out ACPI. There will be plenty
> of platforms that will not implement it, so disabling CONFIG_ACPI
> needs to be possible.
This will always be possible!
>> +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.
>> +
>> +Booting using ACPI tables
>> +-------------------------
>> +
>> +Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
>> +is via the UEFI system configuration table.
>> +
>> +The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
>> +RSDP table (the table with the ACPI signature "RSD PTR ").
>> +
>> +The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
>> +
>> +Processing of ACPI tables may be disabled by passing acpi=off on the kernel
>> +command line.
>> +
>> +DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
>> +only allow for 32bit addresses.
>> +
>> +DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
>> +64-bit alternatives MUST be used.
>> +
>> +The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
>> +and GTDT. If PCI is used the MCFG table MUST also be present.
>> +
>> +ACPI Detection
>> +--------------
>> +
>> +Drivers should determine their probe() type by checking for ACPI_HANDLE,
>> +or .of_node, or other information in the device structure. This is
>> +detailed further in the "Driver Recomendations" section.
>> +
>> +If the presence of ACPI needs to be detected at runtime, then check the value
>> +of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
> Just to make sure, if acpi_disabled is 0, then there will be no acpi
> handle associated with the device, right? I.e. there should be no need
> to have every single driver check for whether ACPI is disabled, the
> handle check should just fail instead.
I need to clarify this obviously, I meant for the second paragraph for 
that to be for code outside driver probing. Inside drivers they should 
only check for ACPI_HANDLE presence. But other bits of code espcially 
bits parsing tables for information in early boot should check for 
acpi_disabled before hunting for the tables etc.
>> +Device Enumeration
>> +------------------
>> +
>> +Device descriptions in ACPI should use standard recognised ACPI interfaces.
>> +These are far simpler than the information provided via Device Tree. Drivers
>> +should take into account this simplicity and work with sensible defaults.
>> +
>> +On no account should a Device Tree attempt to be replicated in ASL using such
>> +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
>> +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
>> +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
> I see these two sentences as contradictory, given that the _DSD doc
> linked below contains examples that mirror over several properties,
> such as "linux,default-trigger" and other LED-specific properties.
> (section 2.4.2 in the below doc). "default-state" seems to come from
> DT too?
>
> Care to elaborate and explain what the intention here is? This could
> worst case turn into quite a mess.
>
> Given that ACPI can present completely different data based on what OS
> is running, it's quite common to indeed have OS specific data in
> there. How does that relate to this document and these practices?
OS specific data has traditionally not worked out well for ACPI, I would 
like to "persuade" people not to use it on ARM.

The _DSD was quite late to the standards process and the supporting 
documentation is still catching up. We are working with ARM to bring 
these issues up and to define proper OS agnostic bindings for ARM.
>> +Common _DSD bindings should be submitted to ASWG to be included in the
>> +document :-
>> +
>> +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
> So, for these that are a mirror of the device tree bindings, there
> needs to be a wording here around reviewing the DT binding first so we
> don't get diverging bindings.
>
>> +TODO: Clarification and examples from Juno implementation.
>> +
>> +Programmable Power Control Resources
>> +------------------------------------
>> +
>> +Programmable power control resources include such resources as voltage/current
>> +providers (regulators) and clock sources.
>> +
>> +For power control of these resources they should be represented with Power
>> +Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
>> +enabling/disabling of resources as they are needed.
>> +
>> +There exists in the ACPI 5.1 specification no standard binding for these objects
>> +to enable programmable levels or rates so this should be avoid if possible and
>> +the resources set to appropriate level by the firmware. If this is not possible
>> +then any manipulation should be abstracted in ASL.
>> +
>> +Each device in ACPI has D-states and these can be controlled through
>> +the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
>> +
>> +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 organise that it is allocated/enabled using the _PS0 method.
>> +
>> +Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
>> +in the _PS3 method.
>> +
>> +Such code in _PS? methods will of course be very platform specific but
>> +should allow the driver to operate the device without special non standard
>> +values being read from ASL. Further, abstracting the use of these resources
>> +allows hardware revisions without requiring updates to the kernel.
>> +
>> +TODO: Clarification and examples from Juno implementation.
>> +
>> +Clocks
>> +------
>> +
>> +Like clocks that are part of the power resources there is no standard way
>> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
>> +described in DT.
>> +
>> +Devices affected by this include things like UARTs, SoC driven LCD displays,
>> +etc.
>> +
>> +The firmware for example UEFI should initialise these clocks to fixed working
> Odd wording.  Maube "The firmware (for example UEFI) should..."
agreed!
>> +values before the kernel is executed. If a driver requires to know rates of
>> +clocks set by firmware then they can be passed to kernel using _DSD.
>> +
>> +example :-
>> +
>> +Device (CLK0) {
>> +       ...
>> +
>> +       Name (_DSD, Package() {
>> +               ToUUID("XXXXX"),
>> +               Package() {
>> +                       Package(2) {"#clock-cells", 0},
> Clock-cells? What do they mean here? Is this specified in the ACPI
> standards? I had to register to get access to it, and didn't feel like
> doing that right now. I guess it's not _all_ that open a spec. :(
>
>> +                       Package(2) {"clock-frequency", "10000"}
>> +               }
>> +       })
>> +
>> +       ...
>> +}
>> +
>> +Device (USR1) {
>> +       ...
>> +
>> +       Name (_DSD, Package() {
>> +               ToUUID("XXXXX"),
>> +               Package() {
>> +                       Package(2) {"clocks", Package() {1, ^CLK0}}},
> A clock is a device in the ACPI model? Why not just provide the rate
> as data into the device here? You said you're not trying to model the
> clock tree, so why reference an external node for it?
This section is still a bit WIP due to the above noted issues with _DSD 
documentation catching up with the standards process. I will need to 
work with the clock maintainers to see if we can agree a proper set of 
bindings for this. #blah-cells always was my least favorite DT feature.

>> +               }
>> +       })
>> +
>> +       ...
>> +}
>> +
>> +Driver Recommendations
>> +----------------------
>> +
>> +DO NOT remove any FDT handling when adding ACPI support for a driver, different
>> +systems may use the same device.
>> +
>> +DO try and keep complex sections of ACPI and DT functionality seperate. This
>> +may mean a patch to break out some complex DT to another function before
>> +the patch to add ACPI. This may happen in other functions but is most likely
>> +in probe function. This gives a clearer flow of data for reviewing driver
>> +source.
>> +
>> +probe() :-
>> +
>> +TODO: replace this with a specific real example from Juno?
>> +
>> +static int device_probe_dt(struct platform_device *pdev)
>> +{
>> +       /* DT specific functionality */
>> +       ...
>> +}
>> +
>> +static int device_probe_acpi(struct platform_device *pdev)
>> +{
>> +       /* ACPI specific functionality */
>> +       ...
>> +}
>> +
>> +static int device_probe(stuct platform_device *pdev)
>> +{
>> +       ...
>> +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
>> +       struct device_node node = pdev->dev.of_node;
>> +       ...
>> +
>> +       if (node)
>> +               ret = device_probe_dt(pdev);
>> +       else if (handle)
>> +               ret = device_probe_acpi(pdev);
>> +       else
>> +               /* other initialisation */
>> +               ...
>> +       /* Continue with any generic probe operations */
>> +       ...
>> +}
> This looks good to me, and it's also my preferred way of ACPI-enabling
> drivers. I guess we might discuss this at KS since it was a proposed
> topic there, and others will object. :)
Hopefully someone can summarise the discussion at KS for me, I will not 
be there.
>> +
>> +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
>> +the different names the driver is probed for, both from DT and from ACPI.
>> +
>> +module device tables :-
>> +
>> +static struct of_device_id virtio_mmio_match[] = {
>> +        { .compatible = "virtio,mmio", },
>> +        {},
>> +};
>> +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
>> +
>> +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
>> +        { "LNRO0005", },
>> +        { }
> No comma here, but a comma on DT. Probably make them equivalent for
> consistency (including space between the braces).
ok
>> +};
>> +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
>> +
>> +TODO: Add any other helpful rules that develop from Juno ACPI work.
> Looks like this should be fixed before the patch is merged, or this
> TODO removed.
The plan is to fix these TODOs with actual data from Juno as that will 
be in the UEFI for Juno.
>> +
>> +ASWG
>> +----
>> +
>> +The following areas are not yet well defined for ARM in the current ACPI
>> +specification and are expected to be worked through in the UEFI ACPI
>> +Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
>> +Participation in this group is open to all UEFI members.
>> +
>> +       - ACPI based CPU topology
>> +       - ACPI based Power management
>> +       - CPU idle control based on PSCI
>> +       - CPU performance control (CPPC)
>> +
>> +No code shall be accepted into the kernel unless it complies with the released
>> +standards from UEFI ASWG. If there are features missing from ACPI to make it
>> +function on a platform ECRs should be submitted to ASWG and go through the
>> +approval process.
> Thanks for listing the things that are not in place yet. Please keep
> this doc up to date as new areas are discovered.
>
>
> -Olof
Thanks for the feedback, we shall work to incorporate it into the document.

Graeme

[PATCH 19/19] Documentation: ACPI for ARM64

[Graeme Gregory]

On 27/07/2014 03:34, Olof Johansson wrote:
> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> From: Graeme Gregory <graeme.gregory@linaro.org>
>>
>> Add documentation for the guidelines of how to use ACPI
>> on ARM64.
> As the most vocal participant against ACPI being adopted, I would have
> appreciated a cc on this patch set -- it's not like you were going for
> a minimal set of cc recipients already. It makes it seem like you're
> trying to sneak it past me for comments. Not cool. I know that's
> probably not your intent, but still.
>
> Some comments below. Overall the doc looks pretty good, but the
> details about _DSD and clocks are somewhat worrisome.
>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 240 insertions(+)
>>   create mode 100644 Documentation/arm64/arm-acpi.txt
>>
>> diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
>> new file mode 100644
>> index 0000000..12cd550
>> --- /dev/null
>> +++ b/Documentation/arm64/arm-acpi.txt
>> @@ -0,0 +1,240 @@
>> +ACPI on ARMv8 Servers
>> +---------------------
>> +
>> +ACPI will be used for ARMv8 general purpose servers designed to follow
> "ACPI might be used"    or     "can be used"
>
>> +the SBSA specification (currently available to people with an ARM login at
>> +http://silver.arm.com)
>> +
>> +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
>> +which is available at <http://www.uefi.org/acpi/specs>.
> The implemented version where? The kernel implements that version?
> Worth clarifying.
ok

the tables passed must be acpi 5.1+, the kernel must then obviously 
implement the 5.1 features, will clarify.
>> +If the machine does not meet these requirements then it is likely that Device
>> +Tree (DT) is more suitable for the hardware.
> This is should be a very clear statement that is currently vague
> w.r.t. which requirements are met or not, especially based on the
> sentence above.
The SBSA is the set of requirements, will clarify.

>> +Relationship with Device Tree
>> +-----------------------------
>> +
>> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>> +exclusive with DT support at compile time.
>> +
>> +At boot time the kernel will only use one description method depending on
>> +parameters passed from the bootloader.
> Possibly overriden by kernel bootargs. And as debated for quite a
> while earlier this year, acpi should still default to off -- if a DT
> and ACPI are both passed in, DT should at this time be given priority.
This does not work due to DT being misused as the kernel/bootloader 
communication layer as well. So a DT is always passed to the kernel. We 
cannot tell whether this is a useful DT without unpacking it and trying 
to boot platform from it.

There is an acpi=off parameter that can be passed to always disable acpi 
runtime.
> (Where can I learn more about how the boot loaders currently handle
> this? Do some of them pass in both DT and ACPI on some platforms, for
> example?)
Currently only one bootloader protocol is supported for ACPI and thats 
UEFI. As noted above due to abuse of DT in the /chosen/ node a DT is 
always passed to the kernel.

>> +Regardless of whether DT or ACPI is used, the kernel must always be capable
>> +of booting with either scheme.
> It should always be possible to compile out ACPI. There will be plenty
> of platforms that will not implement it, so disabling CONFIG_ACPI
> needs to be possible.
This will always be possible!
>> +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.
>> +
>> +Booting using ACPI tables
>> +-------------------------
>> +
>> +Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
>> +is via the UEFI system configuration table.
>> +
>> +The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
>> +RSDP table (the table with the ACPI signature "RSD PTR ").
>> +
>> +The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
>> +
>> +Processing of ACPI tables may be disabled by passing acpi=off on the kernel
>> +command line.
>> +
>> +DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
>> +only allow for 32bit addresses.
>> +
>> +DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
>> +64-bit alternatives MUST be used.
>> +
>> +The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
>> +and GTDT. If PCI is used the MCFG table MUST also be present.
>> +
>> +ACPI Detection
>> +--------------
>> +
>> +Drivers should determine their probe() type by checking for ACPI_HANDLE,
>> +or .of_node, or other information in the device structure. This is
>> +detailed further in the "Driver Recomendations" section.
>> +
>> +If the presence of ACPI needs to be detected at runtime, then check the value
>> +of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
> Just to make sure, if acpi_disabled is 0, then there will be no acpi
> handle associated with the device, right? I.e. there should be no need
> to have every single driver check for whether ACPI is disabled, the
> handle check should just fail instead.
I need to clarify this obviously, I meant for the second paragraph for 
that to be for code outside driver probing. Inside drivers they should 
only check for ACPI_HANDLE presence. But other bits of code espcially 
bits parsing tables for information in early boot should check for 
acpi_disabled before hunting for the tables etc.
>> +Device Enumeration
>> +------------------
>> +
>> +Device descriptions in ACPI should use standard recognised ACPI interfaces.
>> +These are far simpler than the information provided via Device Tree. Drivers
>> +should take into account this simplicity and work with sensible defaults.
>> +
>> +On no account should a Device Tree attempt to be replicated in ASL using such
>> +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
>> +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
>> +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
> I see these two sentences as contradictory, given that the _DSD doc
> linked below contains examples that mirror over several properties,
> such as "linux,default-trigger" and other LED-specific properties.
> (section 2.4.2 in the below doc). "default-state" seems to come from
> DT too?
>
> Care to elaborate and explain what the intention here is? This could
> worst case turn into quite a mess.
>
> Given that ACPI can present completely different data based on what OS
> is running, it's quite common to indeed have OS specific data in
> there. How does that relate to this document and these practices?
OS specific data has traditionally not worked out well for ACPI, I would 
like to "persuade" people not to use it on ARM.

The _DSD was quite late to the standards process and the supporting 
documentation is still catching up. We are working with ARM to bring 
these issues up and to define proper OS agnostic bindings for ARM.
>> +Common _DSD bindings should be submitted to ASWG to be included in the
>> +document :-
>> +
>> +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
> So, for these that are a mirror of the device tree bindings, there
> needs to be a wording here around reviewing the DT binding first so we
> don't get diverging bindings.
>
>> +TODO: Clarification and examples from Juno implementation.
>> +
>> +Programmable Power Control Resources
>> +------------------------------------
>> +
>> +Programmable power control resources include such resources as voltage/current
>> +providers (regulators) and clock sources.
>> +
>> +For power control of these resources they should be represented with Power
>> +Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
>> +enabling/disabling of resources as they are needed.
>> +
>> +There exists in the ACPI 5.1 specification no standard binding for these objects
>> +to enable programmable levels or rates so this should be avoid if possible and
>> +the resources set to appropriate level by the firmware. If this is not possible
>> +then any manipulation should be abstracted in ASL.
>> +
>> +Each device in ACPI has D-states and these can be controlled through
>> +the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
>> +
>> +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 organise that it is allocated/enabled using the _PS0 method.
>> +
>> +Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
>> +in the _PS3 method.
>> +
>> +Such code in _PS? methods will of course be very platform specific but
>> +should allow the driver to operate the device without special non standard
>> +values being read from ASL. Further, abstracting the use of these resources
>> +allows hardware revisions without requiring updates to the kernel.
>> +
>> +TODO: Clarification and examples from Juno implementation.
>> +
>> +Clocks
>> +------
>> +
>> +Like clocks that are part of the power resources there is no standard way
>> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
>> +described in DT.
>> +
>> +Devices affected by this include things like UARTs, SoC driven LCD displays,
>> +etc.
>> +
>> +The firmware for example UEFI should initialise these clocks to fixed working
> Odd wording.  Maube "The firmware (for example UEFI) should..."
agreed!
>> +values before the kernel is executed. If a driver requires to know rates of
>> +clocks set by firmware then they can be passed to kernel using _DSD.
>> +
>> +example :-
>> +
>> +Device (CLK0) {
>> +       ...
>> +
>> +       Name (_DSD, Package() {
>> +               ToUUID("XXXXX"),
>> +               Package() {
>> +                       Package(2) {"#clock-cells", 0},
> Clock-cells? What do they mean here? Is this specified in the ACPI
> standards? I had to register to get access to it, and didn't feel like
> doing that right now. I guess it's not _all_ that open a spec. :(
>
>> +                       Package(2) {"clock-frequency", "10000"}
>> +               }
>> +       })
>> +
>> +       ...
>> +}
>> +
>> +Device (USR1) {
>> +       ...
>> +
>> +       Name (_DSD, Package() {
>> +               ToUUID("XXXXX"),
>> +               Package() {
>> +                       Package(2) {"clocks", Package() {1, ^CLK0}}},
> A clock is a device in the ACPI model? Why not just provide the rate
> as data into the device here? You said you're not trying to model the
> clock tree, so why reference an external node for it?
This section is still a bit WIP due to the above noted issues with _DSD 
documentation catching up with the standards process. I will need to 
work with the clock maintainers to see if we can agree a proper set of 
bindings for this. #blah-cells always was my least favorite DT feature.

>> +               }
>> +       })
>> +
>> +       ...
>> +}
>> +
>> +Driver Recommendations
>> +----------------------
>> +
>> +DO NOT remove any FDT handling when adding ACPI support for a driver, different
>> +systems may use the same device.
>> +
>> +DO try and keep complex sections of ACPI and DT functionality seperate. This
>> +may mean a patch to break out some complex DT to another function before
>> +the patch to add ACPI. This may happen in other functions but is most likely
>> +in probe function. This gives a clearer flow of data for reviewing driver
>> +source.
>> +
>> +probe() :-
>> +
>> +TODO: replace this with a specific real example from Juno?
>> +
>> +static int device_probe_dt(struct platform_device *pdev)
>> +{
>> +       /* DT specific functionality */
>> +       ...
>> +}
>> +
>> +static int device_probe_acpi(struct platform_device *pdev)
>> +{
>> +       /* ACPI specific functionality */
>> +       ...
>> +}
>> +
>> +static int device_probe(stuct platform_device *pdev)
>> +{
>> +       ...
>> +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
>> +       struct device_node node = pdev->dev.of_node;
>> +       ...
>> +
>> +       if (node)
>> +               ret = device_probe_dt(pdev);
>> +       else if (handle)
>> +               ret = device_probe_acpi(pdev);
>> +       else
>> +               /* other initialisation */
>> +               ...
>> +       /* Continue with any generic probe operations */
>> +       ...
>> +}
> This looks good to me, and it's also my preferred way of ACPI-enabling
> drivers. I guess we might discuss this at KS since it was a proposed
> topic there, and others will object. :)
Hopefully someone can summarise the discussion at KS for me, I will not 
be there.
>> +
>> +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
>> +the different names the driver is probed for, both from DT and from ACPI.
>> +
>> +module device tables :-
>> +
>> +static struct of_device_id virtio_mmio_match[] = {
>> +        { .compatible = "virtio,mmio", },
>> +        {},
>> +};
>> +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
>> +
>> +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
>> +        { "LNRO0005", },
>> +        { }
> No comma here, but a comma on DT. Probably make them equivalent for
> consistency (including space between the braces).
ok
>> +};
>> +MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
>> +
>> +TODO: Add any other helpful rules that develop from Juno ACPI work.
> Looks like this should be fixed before the patch is merged, or this
> TODO removed.
The plan is to fix these TODOs with actual data from Juno as that will 
be in the UEFI for Juno.
>> +
>> +ASWG
>> +----
>> +
>> +The following areas are not yet well defined for ARM in the current ACPI
>> +specification and are expected to be worked through in the UEFI ACPI
>> +Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
>> +Participation in this group is open to all UEFI members.
>> +
>> +       - ACPI based CPU topology
>> +       - ACPI based Power management
>> +       - CPU idle control based on PSCI
>> +       - CPU performance control (CPPC)
>> +
>> +No code shall be accepted into the kernel unless it complies with the released
>> +standards from UEFI ASWG. If there are features missing from ACPI to make it
>> +function on a platform ECRs should be submitted to ASWG and go through the
>> +approval process.
> Thanks for listing the things that are not in place yet. Please keep
> this doc up to date as new areas are discovered.
>
>
> -Olof
Thanks for the feedback, we shall work to incorporate it into the document.

Graeme

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > +Relationship with Device Tree
> > +-----------------------------
> > +
> > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > +exclusive with DT support at compile time.
> > +
> > +At boot time the kernel will only use one description method depending on
> > +parameters passed from the bootloader.
> 
> Possibly overriden by kernel bootargs. And as debated for quite a
> while earlier this year, acpi should still default to off -- if a DT
> and ACPI are both passed in, DT should at this time be given priority.

I think this would be harder to do with the way that ACPI is passed in
to the kernel. IIRC, you always have a minimal DT information based on
the ARM64 boot protocol, but in the case of ACPI, this contains pointers
to the ACPI tables, which are then used for populating the Linux platform
devices (unless acpi=disabled is set), while the other contents of the
DTB may be present but we skip the of_platform_populate state.

If this is correct, then replacing the firmware-generated dtb with a
user-provided on would implicitly remove the ACPI tables from visibility,
which is exactly what we want.

It's possible that I'm misremembering it though, and it should be
documented better.

> > +Regardless of whether DT or ACPI is used, the kernel must always be capable
> > +of booting with either scheme.
> 
> It should always be possible to compile out ACPI. There will be plenty
> of platforms that will not implement it, so disabling CONFIG_ACPI
> needs to be possible.

Right.

> > +Clocks
> > +------
> > +
> > +Like clocks that are part of the power resources there is no standard way
> > +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
> > +described in DT.
> > +
> > +Devices affected by this include things like UARTs, SoC driven LCD displays,
> > +etc.
> > +
> > +The firmware for example UEFI should initialise these clocks to fixed working
> > +values before the kernel is executed. If a driver requires to know rates of
> > +clocks set by firmware then they can be passed to kernel using _DSD.
> > +
> > +example :-
> > +
> > +Device (CLK0) {
> > +       ...
> > +
> > +       Name (_DSD, Package() {
> > +               ToUUID("XXXXX"),
> > +               Package() {
> > +                       Package(2) {"#clock-cells", 0},
> 
> Clock-cells? What do they mean here? Is this specified in the ACPI
> standards? I had to register to get access to it, and didn't feel like
> doing that right now. I guess it's not _all_ that open a spec. :(
...
> > +                       Package(2) {"clock-frequency", "10000"}
> > +               }
> > +       })
> > +
> > +       ...
> > +}
> > +
> > +Device (USR1) {
> > +       ...
> > +
> > +       Name (_DSD, Package() {
> > +               ToUUID("XXXXX"),
> > +               Package() {
> > +                       Package(2) {"clocks", Package() {1, ^CLK0}}},
> 
> A clock is a device in the ACPI model? Why not just provide the rate
> as data into the device here? You said you're not trying to model the
> clock tree, so why reference an external node for it?

Exactly. I think what is going on here is a conflict of interests between
Intel's embedded ACPI uses and the ARM64 server requirements. The above
closely resembles what we do in DT, and that makes perfect sense for
Intel's machines so they can reuse a lot of the infrastructure we put
in place for DT. I also suspect it will take a few more years before
this actually gets accepted into both an ACPI specification and the
common operating systems (no point doing it if only Linux is going to
adopt it).

For the servers, I don't see how it makes any sense at all, independent
of the architecture, and relying on a feature like this would only serve
to delay the adoption of ACPI (whether that is a good or bad thing
may be a matter of perspective).

Maybe Graeme or others can comment on where this is coming from. What kind
of driver would actually need to find out the clock rate of a device on
an arm64 server? The examples above list "UARTs, SoC driven LCD displays,
etc.". For all I know, the UART is required to be PL01x (without DMA)
compatible, which should be fully described in ACPI, and I don't see why
a server would come with an LCD.

	Arnd

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > +Relationship with Device Tree
> > +-----------------------------
> > +
> > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > +exclusive with DT support at compile time.
> > +
> > +At boot time the kernel will only use one description method depending on
> > +parameters passed from the bootloader.
> 
> Possibly overriden by kernel bootargs. And as debated for quite a
> while earlier this year, acpi should still default to off -- if a DT
> and ACPI are both passed in, DT should at this time be given priority.

I think this would be harder to do with the way that ACPI is passed in
to the kernel. IIRC, you always have a minimal DT information based on
the ARM64 boot protocol, but in the case of ACPI, this contains pointers
to the ACPI tables, which are then used for populating the Linux platform
devices (unless acpi=disabled is set), while the other contents of the
DTB may be present but we skip the of_platform_populate state.

If this is correct, then replacing the firmware-generated dtb with a
user-provided on would implicitly remove the ACPI tables from visibility,
which is exactly what we want.

It's possible that I'm misremembering it though, and it should be
documented better.

> > +Regardless of whether DT or ACPI is used, the kernel must always be capable
> > +of booting with either scheme.
> 
> It should always be possible to compile out ACPI. There will be plenty
> of platforms that will not implement it, so disabling CONFIG_ACPI
> needs to be possible.

Right.

> > +Clocks
> > +------
> > +
> > +Like clocks that are part of the power resources there is no standard way
> > +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
> > +described in DT.
> > +
> > +Devices affected by this include things like UARTs, SoC driven LCD displays,
> > +etc.
> > +
> > +The firmware for example UEFI should initialise these clocks to fixed working
> > +values before the kernel is executed. If a driver requires to know rates of
> > +clocks set by firmware then they can be passed to kernel using _DSD.
> > +
> > +example :-
> > +
> > +Device (CLK0) {
> > +       ...
> > +
> > +       Name (_DSD, Package() {
> > +               ToUUID("XXXXX"),
> > +               Package() {
> > +                       Package(2) {"#clock-cells", 0},
> 
> Clock-cells? What do they mean here? Is this specified in the ACPI
> standards? I had to register to get access to it, and didn't feel like
> doing that right now. I guess it's not _all_ that open a spec. :(
...
> > +                       Package(2) {"clock-frequency", "10000"}
> > +               }
> > +       })
> > +
> > +       ...
> > +}
> > +
> > +Device (USR1) {
> > +       ...
> > +
> > +       Name (_DSD, Package() {
> > +               ToUUID("XXXXX"),
> > +               Package() {
> > +                       Package(2) {"clocks", Package() {1, ^CLK0}}},
> 
> A clock is a device in the ACPI model? Why not just provide the rate
> as data into the device here? You said you're not trying to model the
> clock tree, so why reference an external node for it?

Exactly. I think what is going on here is a conflict of interests between
Intel's embedded ACPI uses and the ARM64 server requirements. The above
closely resembles what we do in DT, and that makes perfect sense for
Intel's machines so they can reuse a lot of the infrastructure we put
in place for DT. I also suspect it will take a few more years before
this actually gets accepted into both an ACPI specification and the
common operating systems (no point doing it if only Linux is going to
adopt it).

For the servers, I don't see how it makes any sense at all, independent
of the architecture, and relying on a feature like this would only serve
to delay the adoption of ACPI (whether that is a good or bad thing
may be a matter of perspective).

Maybe Graeme or others can comment on where this is coming from. What kind
of driver would actually need to find out the clock rate of a device on
an arm64 server? The examples above list "UARTs, SoC driven LCD displays,
etc.". For all I know, the UART is required to be PL01x (without DMA)
compatible, which should be fully described in ACPI, and I don't see why
a server would come with an LCD.

	Arnd

[PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > +Relationship with Device Tree
> > +-----------------------------
> > +
> > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > +exclusive with DT support at compile time.
> > +
> > +At boot time the kernel will only use one description method depending on
> > +parameters passed from the bootloader.
> 
> Possibly overriden by kernel bootargs. And as debated for quite a
> while earlier this year, acpi should still default to off -- if a DT
> and ACPI are both passed in, DT should at this time be given priority.

I think this would be harder to do with the way that ACPI is passed in
to the kernel. IIRC, you always have a minimal DT information based on
the ARM64 boot protocol, but in the case of ACPI, this contains pointers
to the ACPI tables, which are then used for populating the Linux platform
devices (unless acpi=disabled is set), while the other contents of the
DTB may be present but we skip the of_platform_populate state.

If this is correct, then replacing the firmware-generated dtb with a
user-provided on would implicitly remove the ACPI tables from visibility,
which is exactly what we want.

It's possible that I'm misremembering it though, and it should be
documented better.

> > +Regardless of whether DT or ACPI is used, the kernel must always be capable
> > +of booting with either scheme.
> 
> It should always be possible to compile out ACPI. There will be plenty
> of platforms that will not implement it, so disabling CONFIG_ACPI
> needs to be possible.

Right.

> > +Clocks
> > +------
> > +
> > +Like clocks that are part of the power resources there is no standard way
> > +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
> > +described in DT.
> > +
> > +Devices affected by this include things like UARTs, SoC driven LCD displays,
> > +etc.
> > +
> > +The firmware for example UEFI should initialise these clocks to fixed working
> > +values before the kernel is executed. If a driver requires to know rates of
> > +clocks set by firmware then they can be passed to kernel using _DSD.
> > +
> > +example :-
> > +
> > +Device (CLK0) {
> > +       ...
> > +
> > +       Name (_DSD, Package() {
> > +               ToUUID("XXXXX"),
> > +               Package() {
> > +                       Package(2) {"#clock-cells", 0},
> 
> Clock-cells? What do they mean here? Is this specified in the ACPI
> standards? I had to register to get access to it, and didn't feel like
> doing that right now. I guess it's not _all_ that open a spec. :(
...
> > +                       Package(2) {"clock-frequency", "10000"}
> > +               }
> > +       })
> > +
> > +       ...
> > +}
> > +
> > +Device (USR1) {
> > +       ...
> > +
> > +       Name (_DSD, Package() {
> > +               ToUUID("XXXXX"),
> > +               Package() {
> > +                       Package(2) {"clocks", Package() {1, ^CLK0}}},
> 
> A clock is a device in the ACPI model? Why not just provide the rate
> as data into the device here? You said you're not trying to model the
> clock tree, so why reference an external node for it?

Exactly. I think what is going on here is a conflict of interests between
Intel's embedded ACPI uses and the ARM64 server requirements. The above
closely resembles what we do in DT, and that makes perfect sense for
Intel's machines so they can reuse a lot of the infrastructure we put
in place for DT. I also suspect it will take a few more years before
this actually gets accepted into both an ACPI specification and the
common operating systems (no point doing it if only Linux is going to
adopt it).

For the servers, I don't see how it makes any sense at all, independent
of the architecture, and relying on a feature like this would only serve
to delay the adoption of ACPI (whether that is a good or bad thing
may be a matter of perspective).

Maybe Graeme or others can comment on where this is coming from. What kind
of driver would actually need to find out the clock rate of a device on
an arm64 server? The examples above list "UARTs, SoC driven LCD displays,
etc.". For all I know, the UART is required to be PL01x (without DMA)
compatible, which should be fully described in ACPI, and I don't see why
a server would come with an LCD.

	Arnd

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Graeme Gregory]

On 28/07/2014 10:07, Arnd Bergmann wrote:
> On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
>> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>>> +Relationship with Device Tree
>>> +-----------------------------
>>> +
>>> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>>> +exclusive with DT support at compile time.
>>> +
>>> +At boot time the kernel will only use one description method depending on
>>> +parameters passed from the bootloader.
>> Possibly overriden by kernel bootargs. And as debated for quite a
>> while earlier this year, acpi should still default to off -- if a DT
>> and ACPI are both passed in, DT should at this time be given priority.
> I think this would be harder to do with the way that ACPI is passed in
> to the kernel. IIRC, you always have a minimal DT information based on
> the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> to the ACPI tables, which are then used for populating the Linux platform
> devices (unless acpi=disabled is set), while the other contents of the
> DTB may be present but we skip the of_platform_populate state.
>
> If this is correct, then replacing the firmware-generated dtb with a
> user-provided on would implicitly remove the ACPI tables from visibility,
> which is exactly what we want.
>
> It's possible that I'm misremembering it though, and it should be
> documented better.
>
>>> +Regardless of whether DT or ACPI is used, the kernel must always be capable
>>> +of booting with either scheme.
>> It should always be possible to compile out ACPI. There will be plenty
>> of platforms that will not implement it, so disabling CONFIG_ACPI
>> needs to be possible.
> Right.
>
>>> +Clocks
>>> +------
>>> +
>>> +Like clocks that are part of the power resources there is no standard way
>>> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
>>> +described in DT.
>>> +
>>> +Devices affected by this include things like UARTs, SoC driven LCD displays,
>>> +etc.
>>> +
>>> +The firmware for example UEFI should initialise these clocks to fixed working
>>> +values before the kernel is executed. If a driver requires to know rates of
>>> +clocks set by firmware then they can be passed to kernel using _DSD.
>>> +
>>> +example :-
>>> +
>>> +Device (CLK0) {
>>> +       ...
>>> +
>>> +       Name (_DSD, Package() {
>>> +               ToUUID("XXXXX"),
>>> +               Package() {
>>> +                       Package(2) {"#clock-cells", 0},
>> Clock-cells? What do they mean here? Is this specified in the ACPI
>> standards? I had to register to get access to it, and didn't feel like
>> doing that right now. I guess it's not _all_ that open a spec. :(
> ...
>>> +                       Package(2) {"clock-frequency", "10000"}
>>> +               }
>>> +       })
>>> +
>>> +       ...
>>> +}
>>> +
>>> +Device (USR1) {
>>> +       ...
>>> +
>>> +       Name (_DSD, Package() {
>>> +               ToUUID("XXXXX"),
>>> +               Package() {
>>> +                       Package(2) {"clocks", Package() {1, ^CLK0}}},
>> A clock is a device in the ACPI model? Why not just provide the rate
>> as data into the device here? You said you're not trying to model the
>> clock tree, so why reference an external node for it?
> Exactly. I think what is going on here is a conflict of interests between
> Intel's embedded ACPI uses and the ARM64 server requirements. The above
> closely resembles what we do in DT, and that makes perfect sense for
> Intel's machines so they can reuse a lot of the infrastructure we put
> in place for DT. I also suspect it will take a few more years before
> this actually gets accepted into both an ACPI specification and the
> common operating systems (no point doing it if only Linux is going to
> adopt it).
>
> For the servers, I don't see how it makes any sense at all, independent
> of the architecture, and relying on a feature like this would only serve
> to delay the adoption of ACPI (whether that is a good or bad thing
> may be a matter of perspective).
>
> Maybe Graeme or others can comment on where this is coming from. What kind
> of driver would actually need to find out the clock rate of a device on
> an arm64 server? The examples above list "UARTs, SoC driven LCD displays,
> etc.". For all I know, the UART is required to be PL01x (without DMA)
> compatible, which should be fully described in ACPI, and I don't see why
> a server would come with an LCD.
>
>
The PL011 UART is the use-case I keep hitting, that IP block has a 
variable input clock on pretty much everything I have seen in the wild. 
I really hope that this use does not spread beyond a few essential 
devices like the UART. IMO all real hardware should be the other side of 
a PCIe bridge.

Graeme

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Graeme Gregory]

On 28/07/2014 10:07, Arnd Bergmann wrote:
> On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
>> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>>> +Relationship with Device Tree
>>> +-----------------------------
>>> +
>>> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>>> +exclusive with DT support at compile time.
>>> +
>>> +At boot time the kernel will only use one description method depending on
>>> +parameters passed from the bootloader.
>> Possibly overriden by kernel bootargs. And as debated for quite a
>> while earlier this year, acpi should still default to off -- if a DT
>> and ACPI are both passed in, DT should at this time be given priority.
> I think this would be harder to do with the way that ACPI is passed in
> to the kernel. IIRC, you always have a minimal DT information based on
> the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> to the ACPI tables, which are then used for populating the Linux platform
> devices (unless acpi=disabled is set), while the other contents of the
> DTB may be present but we skip the of_platform_populate state.
>
> If this is correct, then replacing the firmware-generated dtb with a
> user-provided on would implicitly remove the ACPI tables from visibility,
> which is exactly what we want.
>
> It's possible that I'm misremembering it though, and it should be
> documented better.
>
>>> +Regardless of whether DT or ACPI is used, the kernel must always be capable
>>> +of booting with either scheme.
>> It should always be possible to compile out ACPI. There will be plenty
>> of platforms that will not implement it, so disabling CONFIG_ACPI
>> needs to be possible.
> Right.
>
>>> +Clocks
>>> +------
>>> +
>>> +Like clocks that are part of the power resources there is no standard way
>>> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
>>> +described in DT.
>>> +
>>> +Devices affected by this include things like UARTs, SoC driven LCD displays,
>>> +etc.
>>> +
>>> +The firmware for example UEFI should initialise these clocks to fixed working
>>> +values before the kernel is executed. If a driver requires to know rates of
>>> +clocks set by firmware then they can be passed to kernel using _DSD.
>>> +
>>> +example :-
>>> +
>>> +Device (CLK0) {
>>> +       ...
>>> +
>>> +       Name (_DSD, Package() {
>>> +               ToUUID("XXXXX"),
>>> +               Package() {
>>> +                       Package(2) {"#clock-cells", 0},
>> Clock-cells? What do they mean here? Is this specified in the ACPI
>> standards? I had to register to get access to it, and didn't feel like
>> doing that right now. I guess it's not _all_ that open a spec. :(
> ...
>>> +                       Package(2) {"clock-frequency", "10000"}
>>> +               }
>>> +       })
>>> +
>>> +       ...
>>> +}
>>> +
>>> +Device (USR1) {
>>> +       ...
>>> +
>>> +       Name (_DSD, Package() {
>>> +               ToUUID("XXXXX"),
>>> +               Package() {
>>> +                       Package(2) {"clocks", Package() {1, ^CLK0}}},
>> A clock is a device in the ACPI model? Why not just provide the rate
>> as data into the device here? You said you're not trying to model the
>> clock tree, so why reference an external node for it?
> Exactly. I think what is going on here is a conflict of interests between
> Intel's embedded ACPI uses and the ARM64 server requirements. The above
> closely resembles what we do in DT, and that makes perfect sense for
> Intel's machines so they can reuse a lot of the infrastructure we put
> in place for DT. I also suspect it will take a few more years before
> this actually gets accepted into both an ACPI specification and the
> common operating systems (no point doing it if only Linux is going to
> adopt it).
>
> For the servers, I don't see how it makes any sense at all, independent
> of the architecture, and relying on a feature like this would only serve
> to delay the adoption of ACPI (whether that is a good or bad thing
> may be a matter of perspective).
>
> Maybe Graeme or others can comment on where this is coming from. What kind
> of driver would actually need to find out the clock rate of a device on
> an arm64 server? The examples above list "UARTs, SoC driven LCD displays,
> etc.". For all I know, the UART is required to be PL01x (without DMA)
> compatible, which should be fully described in ACPI, and I don't see why
> a server would come with an LCD.
>
>
The PL011 UART is the use-case I keep hitting, that IP block has a 
variable input clock on pretty much everything I have seen in the wild. 
I really hope that this use does not spread beyond a few essential 
devices like the UART. IMO all real hardware should be the other side of 
a PCIe bridge.

Graeme

[PATCH 19/19] Documentation: ACPI for ARM64

[Graeme Gregory]

On 28/07/2014 10:07, Arnd Bergmann wrote:
> On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
>> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>>> +Relationship with Device Tree
>>> +-----------------------------
>>> +
>>> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>>> +exclusive with DT support at compile time.
>>> +
>>> +At boot time the kernel will only use one description method depending on
>>> +parameters passed from the bootloader.
>> Possibly overriden by kernel bootargs. And as debated for quite a
>> while earlier this year, acpi should still default to off -- if a DT
>> and ACPI are both passed in, DT should at this time be given priority.
> I think this would be harder to do with the way that ACPI is passed in
> to the kernel. IIRC, you always have a minimal DT information based on
> the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> to the ACPI tables, which are then used for populating the Linux platform
> devices (unless acpi=disabled is set), while the other contents of the
> DTB may be present but we skip the of_platform_populate state.
>
> If this is correct, then replacing the firmware-generated dtb with a
> user-provided on would implicitly remove the ACPI tables from visibility,
> which is exactly what we want.
>
> It's possible that I'm misremembering it though, and it should be
> documented better.
>
>>> +Regardless of whether DT or ACPI is used, the kernel must always be capable
>>> +of booting with either scheme.
>> It should always be possible to compile out ACPI. There will be plenty
>> of platforms that will not implement it, so disabling CONFIG_ACPI
>> needs to be possible.
> Right.
>
>>> +Clocks
>>> +------
>>> +
>>> +Like clocks that are part of the power resources there is no standard way
>>> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
>>> +described in DT.
>>> +
>>> +Devices affected by this include things like UARTs, SoC driven LCD displays,
>>> +etc.
>>> +
>>> +The firmware for example UEFI should initialise these clocks to fixed working
>>> +values before the kernel is executed. If a driver requires to know rates of
>>> +clocks set by firmware then they can be passed to kernel using _DSD.
>>> +
>>> +example :-
>>> +
>>> +Device (CLK0) {
>>> +       ...
>>> +
>>> +       Name (_DSD, Package() {
>>> +               ToUUID("XXXXX"),
>>> +               Package() {
>>> +                       Package(2) {"#clock-cells", 0},
>> Clock-cells? What do they mean here? Is this specified in the ACPI
>> standards? I had to register to get access to it, and didn't feel like
>> doing that right now. I guess it's not _all_ that open a spec. :(
> ...
>>> +                       Package(2) {"clock-frequency", "10000"}
>>> +               }
>>> +       })
>>> +
>>> +       ...
>>> +}
>>> +
>>> +Device (USR1) {
>>> +       ...
>>> +
>>> +       Name (_DSD, Package() {
>>> +               ToUUID("XXXXX"),
>>> +               Package() {
>>> +                       Package(2) {"clocks", Package() {1, ^CLK0}}},
>> A clock is a device in the ACPI model? Why not just provide the rate
>> as data into the device here? You said you're not trying to model the
>> clock tree, so why reference an external node for it?
> Exactly. I think what is going on here is a conflict of interests between
> Intel's embedded ACPI uses and the ARM64 server requirements. The above
> closely resembles what we do in DT, and that makes perfect sense for
> Intel's machines so they can reuse a lot of the infrastructure we put
> in place for DT. I also suspect it will take a few more years before
> this actually gets accepted into both an ACPI specification and the
> common operating systems (no point doing it if only Linux is going to
> adopt it).
>
> For the servers, I don't see how it makes any sense at all, independent
> of the architecture, and relying on a feature like this would only serve
> to delay the adoption of ACPI (whether that is a good or bad thing
> may be a matter of perspective).
>
> Maybe Graeme or others can comment on where this is coming from. What kind
> of driver would actually need to find out the clock rate of a device on
> an arm64 server? The examples above list "UARTs, SoC driven LCD displays,
> etc.". For all I know, the UART is required to be PL01x (without DMA)
> compatible, which should be fully described in ACPI, and I don't see why
> a server would come with an LCD.
>
>
The PL011 UART is the use-case I keep hitting, that IP block has a 
variable input clock on pretty much everything I have seen in the wild. 
I really hope that this use does not spread beyond a few essential 
devices like the UART. IMO all real hardware should be the other side of 
a PCIe bridge.

Graeme

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

Hi Olof,

On Sun, Jul 27, 2014 at 03:34:48AM +0100, Olof Johansson wrote:
> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > From: Graeme Gregory <graeme.gregory@linaro.org>
> >
> > Add documentation for the guidelines of how to use ACPI
> > on ARM64.
>
> As the most vocal participant against ACPI being adopted, I would have
> appreciated a cc on this patch set -- it's not like you were going for
> a minimal set of cc recipients already. It makes it seem like you're
> trying to sneak it past me for comments. Not cool. I know that's
> probably not your intent, but still.
>
> Some comments below. Overall the doc looks pretty good, but the
> details about _DSD and clocks are somewhat worrisome.
>
> > Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> > Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> > ---
> >  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 240 insertions(+)
> >  create mode 100644 Documentation/arm64/arm-acpi.txt
> >
> > diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> > new file mode 100644
> > index 0000000..12cd550
> > --- /dev/null
> > +++ b/Documentation/arm64/arm-acpi.txt
> > @@ -0,0 +1,240 @@
> > +ACPI on ARMv8 Servers
> > +---------------------
> > +
> > +ACPI will be used for ARMv8 general purpose servers designed to follow
>
> "ACPI might be used"    or     "can be used"
>
> > +the SBSA specification (currently available to people with an ARM login at
> > +http://silver.arm.com)
> > +
> > +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> > +which is available at <http://www.uefi.org/acpi/specs>.
>
> The implemented version where? The kernel implements that version?
> Worth clarifying.
>
> > +If the machine does not meet these requirements then it is likely that Device
> > +Tree (DT) is more suitable for the hardware.
>
> This is should be a very clear statement that is currently vague
> w.r.t. which requirements are met or not, especially based on the
> sentence above.
>
> > +Relationship with Device Tree
> > +-----------------------------
> > +
> > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > +exclusive with DT support at compile time.
> > +
> > +At boot time the kernel will only use one description method depending on
> > +parameters passed from the bootloader.
>
> Possibly overriden by kernel bootargs. And as debated for quite a
> while earlier this year, acpi should still default to off -- if a DT
> and ACPI are both passed in, DT should at this time be given priority.

Why? I really don't see the logic in doing that.

Currently the kernel can only boot using DT, so DT will be used even if
ACPI is present. In the presence of ACPI support in the kernel, ACPI
would be used on said systems.

>From the discussions at the last Linaro Connect, this was seen as
important for virtual machines which want to provide ACPI services to
guests while still being able to boot DT-only kernels. I'll leave it to
Grant, Rob, and Christoffer to cover that.

> (Where can I learn more about how the boot loaders currently handle
> this? Do some of them pass in both DT and ACPI on some platforms, for
> example?)

All will pass in some form of DT. If booted through UEFI, the DT will be
augmented with data about the UEFI memory map (and if no DT is provided,
a /chosen only DT will eb created by the EFI stub).

A kernel with ACPI support will query EFI for ACPI tables, and if found
use them.

> > +Regardless of whether DT or ACPI is used, the kernel must always be capable
> > +of booting with either scheme.
>
> It should always be possible to compile out ACPI. There will be plenty
> of platforms that will not implement it, so disabling CONFIG_ACPI
> needs to be possible.

A better description would be that the two must never be mutually
exclusive. It must always be possible to have a kernel which supports
both, and code must never assume the absence of the other.

At run time, the kernel will decide to use one for system description
and use that.

[...]

> > +Device Enumeration
> > +------------------
> > +
> > +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> > +These are far simpler than the information provided via Device Tree. Drivers
> > +should take into account this simplicity and work with sensible defaults.
> > +
> > +On no account should a Device Tree attempt to be replicated in ASL using such
> > +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> > +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> > +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
>
> I see these two sentences as contradictory, given that the _DSD doc
> linked below contains examples that mirror over several properties,
> such as "linux,default-trigger" and other LED-specific properties.
> (section 2.4.2 in the below doc). "default-state" seems to come from
> DT too?

Urrgh. Those should never been placed in the ACPI spec. It's bad enough
in DT.

> Care to elaborate and explain what the intention here is? This could
> worst case turn into quite a mess.
>
> Given that ACPI can present completely different data based on what OS
> is running, it's quite common to indeed have OS specific data in
> there. How does that relate to this document and these practices?
>
> > +Common _DSD bindings should be submitted to ASWG to be included in the
> > +document :-
> > +
> > +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
>
> So, for these that are a mirror of the device tree bindings, there
> needs to be a wording here around reviewing the DT binding first so we
> don't get diverging bindings.

We shouldn't work on the assumption that the two should be identical.
ACPI already has standard mechanisms for describing certain linkages
that are divergent from DT.

This really needs higher-level thought, and I'd hoped that things
wouldn't blindly be copied one way or the other.

[...]

> > +values before the kernel is executed. If a driver requires to know rates of
> > +clocks set by firmware then they can be passed to kernel using _DSD.
> > +
> > +example :-
> > +
> > +Device (CLK0) {
> > +       ...
> > +
> > +       Name (_DSD, Package() {
> > +               ToUUID("XXXXX"),
> > +               Package() {
> > +                       Package(2) {"#clock-cells", 0},
>
> Clock-cells? What do they mean here? Is this specified in the ACPI
> standards? I had to register to get access to it, and didn't feel like
> doing that right now. I guess it's not _all_ that open a spec. :(

Yeah, this is complete nonsense.

If people are going to blindly copy elements from DT into ACPI without
actually understanding them, then ACPI is clearly no better than DT.

[...]

> > +static int device_probe(stuct platform_device *pdev)
> > +{
> > +       ...
> > +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
> > +       struct device_node node = pdev->dev.of_node;
> > +       ...
> > +
> > +       if (node)
> > +               ret = device_probe_dt(pdev);
> > +       else if (handle)
> > +               ret = device_probe_acpi(pdev);
> > +       else
> > +               /* other initialisation */
> > +               ...
> > +       /* Continue with any generic probe operations */
> > +       ...
> > +}
>
> This looks good to me, and it's also my preferred way of ACPI-enabling
> drivers. I guess we might discuss this at KS since it was a proposed
> topic there, and others will object. :)

This is almost precisely the form of probe I want to see (it would be
nicer IMO to have separate entry points for ACPI / DT / platform data
that can all call a common probe core, but this isn't too far off).

>
> > +
> > +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
> > +the different names the driver is probed for, both from DT and from ACPI.
> > +
> > +module device tables :-
> > +
> > +static struct of_device_id virtio_mmio_match[] = {
> > +        { .compatible = "virtio,mmio", },
> > +        {},
> > +};
> > +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
> > +
> > +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
> > +        { "LNRO0005", },
> > +        { }
>
> No comma here, but a comma on DT. Probably make them equivalent for
> consistency (including space between the braces).

The comma on the DT form should probably be dropped. The NULL sentinel's
only job is to delimit the list, so it never makes sense to place
something after it.

Cheers,
Mark.

[PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

Hi Olof,

On Sun, Jul 27, 2014 at 03:34:48AM +0100, Olof Johansson wrote:
> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > From: Graeme Gregory <graeme.gregory@linaro.org>
> >
> > Add documentation for the guidelines of how to use ACPI
> > on ARM64.
>
> As the most vocal participant against ACPI being adopted, I would have
> appreciated a cc on this patch set -- it's not like you were going for
> a minimal set of cc recipients already. It makes it seem like you're
> trying to sneak it past me for comments. Not cool. I know that's
> probably not your intent, but still.
>
> Some comments below. Overall the doc looks pretty good, but the
> details about _DSD and clocks are somewhat worrisome.
>
> > Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> > Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> > ---
> >  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 240 insertions(+)
> >  create mode 100644 Documentation/arm64/arm-acpi.txt
> >
> > diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> > new file mode 100644
> > index 0000000..12cd550
> > --- /dev/null
> > +++ b/Documentation/arm64/arm-acpi.txt
> > @@ -0,0 +1,240 @@
> > +ACPI on ARMv8 Servers
> > +---------------------
> > +
> > +ACPI will be used for ARMv8 general purpose servers designed to follow
>
> "ACPI might be used"    or     "can be used"
>
> > +the SBSA specification (currently available to people with an ARM login at
> > +http://silver.arm.com)
> > +
> > +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> > +which is available at <http://www.uefi.org/acpi/specs>.
>
> The implemented version where? The kernel implements that version?
> Worth clarifying.
>
> > +If the machine does not meet these requirements then it is likely that Device
> > +Tree (DT) is more suitable for the hardware.
>
> This is should be a very clear statement that is currently vague
> w.r.t. which requirements are met or not, especially based on the
> sentence above.
>
> > +Relationship with Device Tree
> > +-----------------------------
> > +
> > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > +exclusive with DT support at compile time.
> > +
> > +At boot time the kernel will only use one description method depending on
> > +parameters passed from the bootloader.
>
> Possibly overriden by kernel bootargs. And as debated for quite a
> while earlier this year, acpi should still default to off -- if a DT
> and ACPI are both passed in, DT should at this time be given priority.

Why? I really don't see the logic in doing that.

Currently the kernel can only boot using DT, so DT will be used even if
ACPI is present. In the presence of ACPI support in the kernel, ACPI
would be used on said systems.

>From the discussions at the last Linaro Connect, this was seen as
important for virtual machines which want to provide ACPI services to
guests while still being able to boot DT-only kernels. I'll leave it to
Grant, Rob, and Christoffer to cover that.

> (Where can I learn more about how the boot loaders currently handle
> this? Do some of them pass in both DT and ACPI on some platforms, for
> example?)

All will pass in some form of DT. If booted through UEFI, the DT will be
augmented with data about the UEFI memory map (and if no DT is provided,
a /chosen only DT will eb created by the EFI stub).

A kernel with ACPI support will query EFI for ACPI tables, and if found
use them.

> > +Regardless of whether DT or ACPI is used, the kernel must always be capable
> > +of booting with either scheme.
>
> It should always be possible to compile out ACPI. There will be plenty
> of platforms that will not implement it, so disabling CONFIG_ACPI
> needs to be possible.

A better description would be that the two must never be mutually
exclusive. It must always be possible to have a kernel which supports
both, and code must never assume the absence of the other.

At run time, the kernel will decide to use one for system description
and use that.

[...]

> > +Device Enumeration
> > +------------------
> > +
> > +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> > +These are far simpler than the information provided via Device Tree. Drivers
> > +should take into account this simplicity and work with sensible defaults.
> > +
> > +On no account should a Device Tree attempt to be replicated in ASL using such
> > +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> > +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> > +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
>
> I see these two sentences as contradictory, given that the _DSD doc
> linked below contains examples that mirror over several properties,
> such as "linux,default-trigger" and other LED-specific properties.
> (section 2.4.2 in the below doc). "default-state" seems to come from
> DT too?

Urrgh. Those should never been placed in the ACPI spec. It's bad enough
in DT.

> Care to elaborate and explain what the intention here is? This could
> worst case turn into quite a mess.
>
> Given that ACPI can present completely different data based on what OS
> is running, it's quite common to indeed have OS specific data in
> there. How does that relate to this document and these practices?
>
> > +Common _DSD bindings should be submitted to ASWG to be included in the
> > +document :-
> > +
> > +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
>
> So, for these that are a mirror of the device tree bindings, there
> needs to be a wording here around reviewing the DT binding first so we
> don't get diverging bindings.

We shouldn't work on the assumption that the two should be identical.
ACPI already has standard mechanisms for describing certain linkages
that are divergent from DT.

This really needs higher-level thought, and I'd hoped that things
wouldn't blindly be copied one way or the other.

[...]

> > +values before the kernel is executed. If a driver requires to know rates of
> > +clocks set by firmware then they can be passed to kernel using _DSD.
> > +
> > +example :-
> > +
> > +Device (CLK0) {
> > +       ...
> > +
> > +       Name (_DSD, Package() {
> > +               ToUUID("XXXXX"),
> > +               Package() {
> > +                       Package(2) {"#clock-cells", 0},
>
> Clock-cells? What do they mean here? Is this specified in the ACPI
> standards? I had to register to get access to it, and didn't feel like
> doing that right now. I guess it's not _all_ that open a spec. :(

Yeah, this is complete nonsense.

If people are going to blindly copy elements from DT into ACPI without
actually understanding them, then ACPI is clearly no better than DT.

[...]

> > +static int device_probe(stuct platform_device *pdev)
> > +{
> > +       ...
> > +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
> > +       struct device_node node = pdev->dev.of_node;
> > +       ...
> > +
> > +       if (node)
> > +               ret = device_probe_dt(pdev);
> > +       else if (handle)
> > +               ret = device_probe_acpi(pdev);
> > +       else
> > +               /* other initialisation */
> > +               ...
> > +       /* Continue with any generic probe operations */
> > +       ...
> > +}
>
> This looks good to me, and it's also my preferred way of ACPI-enabling
> drivers. I guess we might discuss this at KS since it was a proposed
> topic there, and others will object. :)

This is almost precisely the form of probe I want to see (it would be
nicer IMO to have separate entry points for ACPI / DT / platform data
that can all call a common probe core, but this isn't too far off).

>
> > +
> > +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
> > +the different names the driver is probed for, both from DT and from ACPI.
> > +
> > +module device tables :-
> > +
> > +static struct of_device_id virtio_mmio_match[] = {
> > +        { .compatible = "virtio,mmio", },
> > +        {},
> > +};
> > +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
> > +
> > +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
> > +        { "LNRO0005", },
> > +        { }
>
> No comma here, but a comma on DT. Probably make them equivalent for
> consistency (including space between the braces).

The comma on the DT form should probably be dropped. The NULL sentinel's
only job is to delimit the list, so it never makes sense to place
something after it.

Cheers,
Mark.

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Mon, Jul 28, 2014 at 10:07:50AM +0100, Arnd Bergmann wrote:
> On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > +Relationship with Device Tree
> > > +-----------------------------
> > > +
> > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > +exclusive with DT support at compile time.
> > > +
> > > +At boot time the kernel will only use one description method depending on
> > > +parameters passed from the bootloader.
> > 
> > Possibly overriden by kernel bootargs. And as debated for quite a
> > while earlier this year, acpi should still default to off -- if a DT
> > and ACPI are both passed in, DT should at this time be given priority.
> 
> I think this would be harder to do with the way that ACPI is passed in
> to the kernel. IIRC, you always have a minimal DT information based on
> the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> to the ACPI tables, which are then used for populating the Linux platform
> devices (unless acpi=disabled is set), while the other contents of the
> DTB may be present but we skip the of_platform_populate state.
> 
> If this is correct, then replacing the firmware-generated dtb with a
> user-provided on would implicitly remove the ACPI tables from visibility,
> which is exactly what we want.

That's not quite true.

There might not be any DTB, or the user might have provided a DTB with
only /chosen/bootargs. Trying to distinguish the many cases of possible
DTB is broken as a concept.

The EFI stub will attempt to get a DTB from somewhere (provided by
filename or as a system table with a magic UUID), and if it can't find
one will generate an empty stub DTB.

Then it will go and perform some EFI memory setup, placing some
properties in the DTB (which might be a stub) describing the EFI memory
map.

Then we boot the kernel proper, which sees the EFI pointers and looks
for an ACPI table. If they are found, ACPI is used. Otherwise we attempt
to use the DTB (which might be a stub).

Unless ACPI is explcitly disabled, ACPI will be used if present.

Thanks,
Mark.

[PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Mon, Jul 28, 2014 at 10:07:50AM +0100, Arnd Bergmann wrote:
> On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > +Relationship with Device Tree
> > > +-----------------------------
> > > +
> > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > +exclusive with DT support at compile time.
> > > +
> > > +At boot time the kernel will only use one description method depending on
> > > +parameters passed from the bootloader.
> > 
> > Possibly overriden by kernel bootargs. And as debated for quite a
> > while earlier this year, acpi should still default to off -- if a DT
> > and ACPI are both passed in, DT should at this time be given priority.
> 
> I think this would be harder to do with the way that ACPI is passed in
> to the kernel. IIRC, you always have a minimal DT information based on
> the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> to the ACPI tables, which are then used for populating the Linux platform
> devices (unless acpi=disabled is set), while the other contents of the
> DTB may be present but we skip the of_platform_populate state.
> 
> If this is correct, then replacing the firmware-generated dtb with a
> user-provided on would implicitly remove the ACPI tables from visibility,
> which is exactly what we want.

That's not quite true.

There might not be any DTB, or the user might have provided a DTB with
only /chosen/bootargs. Trying to distinguish the many cases of possible
DTB is broken as a concept.

The EFI stub will attempt to get a DTB from somewhere (provided by
filename or as a system table with a magic UUID), and if it can't find
one will generate an empty stub DTB.

Then it will go and perform some EFI memory setup, placing some
properties in the DTB (which might be a stub) describing the EFI memory
map.

Then we boot the kernel proper, which sees the EFI pointers and looks
for an ACPI table. If they are found, ACPI is used. Otherwise we attempt
to use the DTB (which might be a stub).

Unless ACPI is explcitly disabled, ACPI will be used if present.

Thanks,
Mark.

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
> The PL011 UART is the use-case I keep hitting, that IP block has a 
> variable input clock on pretty much everything I have seen in the wild. 

Ok, I see. What does ACPI-5.1 say about pl011?

Interestingly, the subset of pl011 that is specified by SBSA does not
contain the IBRD/FBRD registers, effectively making it a fixed-rated
UART (I guess that would be a ART, without the U then), and you
consequently don't even need to know the clock rate.

However, my guess is that most hardware in the real world contains
an actual pl011 and it does make a lot of sense to allow setting
the baud rate on it, which then requires knowing the input clock.

If there is any hardware that implements just the SBSA-mandated subset
rather than the full pl011, we should probably implement both
in the kernel: a dumb driver that can only send and receive, and the
more complex one that can set the bit rates and flow-control but that
requires a standardized ACPI table with the input clock rate.

Whether the two would belong into one file or two separate driver
modules is something I can't tell, it would be up to the serial
maintainers to decide.

> I really hope that this use does not spread beyond a few essential 
> devices like the UART. IMO all real hardware should be the other side of 
> a PCIe bridge.

I would definitely agree with that.

	Arnd

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
> The PL011 UART is the use-case I keep hitting, that IP block has a 
> variable input clock on pretty much everything I have seen in the wild. 

Ok, I see. What does ACPI-5.1 say about pl011?

Interestingly, the subset of pl011 that is specified by SBSA does not
contain the IBRD/FBRD registers, effectively making it a fixed-rated
UART (I guess that would be a ART, without the U then), and you
consequently don't even need to know the clock rate.

However, my guess is that most hardware in the real world contains
an actual pl011 and it does make a lot of sense to allow setting
the baud rate on it, which then requires knowing the input clock.

If there is any hardware that implements just the SBSA-mandated subset
rather than the full pl011, we should probably implement both
in the kernel: a dumb driver that can only send and receive, and the
more complex one that can set the bit rates and flow-control but that
requires a standardized ACPI table with the input clock rate.

Whether the two would belong into one file or two separate driver
modules is something I can't tell, it would be up to the serial
maintainers to decide.

> I really hope that this use does not spread beyond a few essential 
> devices like the UART. IMO all real hardware should be the other side of 
> a PCIe bridge.

I would definitely agree with that.

	Arnd

[PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
> The PL011 UART is the use-case I keep hitting, that IP block has a 
> variable input clock on pretty much everything I have seen in the wild. 

Ok, I see. What does ACPI-5.1 say about pl011?

Interestingly, the subset of pl011 that is specified by SBSA does not
contain the IBRD/FBRD registers, effectively making it a fixed-rated
UART (I guess that would be a ART, without the U then), and you
consequently don't even need to know the clock rate.

However, my guess is that most hardware in the real world contains
an actual pl011 and it does make a lot of sense to allow setting
the baud rate on it, which then requires knowing the input clock.

If there is any hardware that implements just the SBSA-mandated subset
rather than the full pl011, we should probably implement both
in the kernel: a dumb driver that can only send and receive, and the
more complex one that can set the bit rates and flow-control but that
requires a standardized ACPI table with the input clock rate.

Whether the two would belong into one file or two separate driver
modules is something I can't tell, it would be up to the serial
maintainers to decide.

> I really hope that this use does not spread beyond a few essential 
> devices like the UART. IMO all real hardware should be the other side of 
> a PCIe bridge.

I would definitely agree with that.

	Arnd

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Andre Przywara]

On 28/07/14 11:46, Arnd Bergmann wrote:
> On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
>> The PL011 UART is the use-case I keep hitting, that IP block has a 
>> variable input clock on pretty much everything I have seen in the wild. 
> 
> Ok, I see. What does ACPI-5.1 say about pl011?
> 
> Interestingly, the subset of pl011 that is specified by SBSA does not
> contain the IBRD/FBRD registers, effectively making it a fixed-rated
> UART (I guess that would be a ART, without the U then), and you
> consequently don't even need to know the clock rate.

The idea of this was probably to let the baudrate set by some firmware
code to the "right" value and the spec just didn't want to expose the
details for the generic UART:
"This specification does not cover registers needed to configure the
UART as these are considered hardware-specific and will be set up by
hardware-specific software."
To me that reads like the SBSA UART is just for debugging, and you are
expected just to access the data register.

> However, my guess is that most hardware in the real world contains
> an actual pl011 and it does make a lot of sense to allow setting
> the baud rate on it, which then requires knowing the input clock.
> 
> If there is any hardware that implements just the SBSA-mandated subset
> rather than the full pl011, we should probably implement both
> in the kernel: a dumb driver that can only send and receive, and the
> more complex one that can set the bit rates and flow-control but that
> requires a standardized ACPI table with the input clock rate.

The fast model I use can be switched to use the SBSA restricted PL011,
and as expected the Linux kernel crashes at the device doesn't support
DMA (and a lot more stuff) - but the current code requires it.
So I am about to implement a new driver for that SBSA subset. So far
this will be a separate driver, starting from a copy of amba-pl011.c,
but removing most of the code ;-)

> Whether the two would belong into one file or two separate driver
> modules is something I can't tell, it would be up to the serial
> maintainers to decide.

Sharing support for both devices in the same file doesn't seem to make
too much sense to me so far (but I may amend this later).
Will post a version as soon as I have it finished.

Cheers,
Andre.

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Andre Przywara]

On 28/07/14 11:46, Arnd Bergmann wrote:
> On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
>> The PL011 UART is the use-case I keep hitting, that IP block has a 
>> variable input clock on pretty much everything I have seen in the wild. 
> 
> Ok, I see. What does ACPI-5.1 say about pl011?
> 
> Interestingly, the subset of pl011 that is specified by SBSA does not
> contain the IBRD/FBRD registers, effectively making it a fixed-rated
> UART (I guess that would be a ART, without the U then), and you
> consequently don't even need to know the clock rate.

The idea of this was probably to let the baudrate set by some firmware
code to the "right" value and the spec just didn't want to expose the
details for the generic UART:
"This specification does not cover registers needed to configure the
UART as these are considered hardware-specific and will be set up by
hardware-specific software."
To me that reads like the SBSA UART is just for debugging, and you are
expected just to access the data register.

> However, my guess is that most hardware in the real world contains
> an actual pl011 and it does make a lot of sense to allow setting
> the baud rate on it, which then requires knowing the input clock.
> 
> If there is any hardware that implements just the SBSA-mandated subset
> rather than the full pl011, we should probably implement both
> in the kernel: a dumb driver that can only send and receive, and the
> more complex one that can set the bit rates and flow-control but that
> requires a standardized ACPI table with the input clock rate.

The fast model I use can be switched to use the SBSA restricted PL011,
and as expected the Linux kernel crashes at the device doesn't support
DMA (and a lot more stuff) - but the current code requires it.
So I am about to implement a new driver for that SBSA subset. So far
this will be a separate driver, starting from a copy of amba-pl011.c,
but removing most of the code ;-)

> Whether the two would belong into one file or two separate driver
> modules is something I can't tell, it would be up to the serial
> maintainers to decide.

Sharing support for both devices in the same file doesn't seem to make
too much sense to me so far (but I may amend this later).
Will post a version as soon as I have it finished.

Cheers,
Andre.

[PATCH 19/19] Documentation: ACPI for ARM64

[Andre Przywara]

On 28/07/14 11:46, Arnd Bergmann wrote:
> On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
>> The PL011 UART is the use-case I keep hitting, that IP block has a 
>> variable input clock on pretty much everything I have seen in the wild. 
> 
> Ok, I see. What does ACPI-5.1 say about pl011?
> 
> Interestingly, the subset of pl011 that is specified by SBSA does not
> contain the IBRD/FBRD registers, effectively making it a fixed-rated
> UART (I guess that would be a ART, without the U then), and you
> consequently don't even need to know the clock rate.

The idea of this was probably to let the baudrate set by some firmware
code to the "right" value and the spec just didn't want to expose the
details for the generic UART:
"This specification does not cover registers needed to configure the
UART as these are considered hardware-specific and will be set up by
hardware-specific software."
To me that reads like the SBSA UART is just for debugging, and you are
expected just to access the data register.

> However, my guess is that most hardware in the real world contains
> an actual pl011 and it does make a lot of sense to allow setting
> the baud rate on it, which then requires knowing the input clock.
> 
> If there is any hardware that implements just the SBSA-mandated subset
> rather than the full pl011, we should probably implement both
> in the kernel: a dumb driver that can only send and receive, and the
> more complex one that can set the bit rates and flow-control but that
> requires a standardized ACPI table with the input clock rate.

The fast model I use can be switched to use the SBSA restricted PL011,
and as expected the Linux kernel crashes at the device doesn't support
DMA (and a lot more stuff) - but the current code requires it.
So I am about to implement a new driver for that SBSA subset. So far
this will be a separate driver, starting from a copy of amba-pl011.c,
but removing most of the code ;-)

> Whether the two would belong into one file or two separate driver
> modules is something I can't tell, it would be up to the serial
> maintainers to decide.

Sharing support for both devices in the same file doesn't seem to make
too much sense to me so far (but I may amend this later).
Will post a version as soon as I have it finished.

Cheers,
Andre.

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Monday 28 July 2014 15:20:06 Andre Przywara wrote:
> On 28/07/14 11:46, Arnd Bergmann wrote:
> > On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
> >> The PL011 UART is the use-case I keep hitting, that IP block has a 
> >> variable input clock on pretty much everything I have seen in the wild. 
> > 
> > Ok, I see. What does ACPI-5.1 say about pl011?
> > 
> > Interestingly, the subset of pl011 that is specified by SBSA does not
> > contain the IBRD/FBRD registers, effectively making it a fixed-rated
> > UART (I guess that would be a ART, without the U then), and you
> > consequently don't even need to know the clock rate.
> 
> The idea of this was probably to let the baudrate set by some firmware
> code to the "right" value and the spec just didn't want to expose the
> details for the generic UART:
> "This specification does not cover registers needed to configure the
> UART as these are considered hardware-specific and will be set up by
> hardware-specific software."
> To me that reads like the SBSA UART is just for debugging, and you are
> expected just to access the data register.

Right, makes sense. It also avoids the case where Linux for some reason
ends up using a different line rate than the firmware, which can
cause a lot of unnecessary pain.

> > However, my guess is that most hardware in the real world contains
> > an actual pl011 and it does make a lot of sense to allow setting
> > the baud rate on it, which then requires knowing the input clock.
> > 
> > If there is any hardware that implements just the SBSA-mandated subset
> > rather than the full pl011, we should probably implement both
> > in the kernel: a dumb driver that can only send and receive, and the
> > more complex one that can set the bit rates and flow-control but that
> > requires a standardized ACPI table with the input clock rate.
> 
> The fast model I use can be switched to use the SBSA restricted PL011,
> and as expected the Linux kernel crashes at the device doesn't support
> DMA (and a lot more stuff) - but the current code requires it.

It does? We have a lot of platforms that don't have DMA support for
pl011.

> So I am about to implement a new driver for that SBSA subset. So far
> this will be a separate driver, starting from a copy of amba-pl011.c,
> but removing most of the code ;-)

Ok. You might want to consider starting from a different base though.
IIRC, pl011 uses uart_port as the basic abstraction, while the
new driver should probably use the raw tty_port instead.
drivers/tty/goldfish.c is probably a good example to look at for
that.

You could also make it a hvc_driver like drivers/tty/hvc/hvc_vio.c,
but I'm not sure if that model seen favorable by the tty maintainers.
It would probably be the shortest driver though.

	Arnd

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Monday 28 July 2014 15:20:06 Andre Przywara wrote:
> On 28/07/14 11:46, Arnd Bergmann wrote:
> > On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
> >> The PL011 UART is the use-case I keep hitting, that IP block has a 
> >> variable input clock on pretty much everything I have seen in the wild. 
> > 
> > Ok, I see. What does ACPI-5.1 say about pl011?
> > 
> > Interestingly, the subset of pl011 that is specified by SBSA does not
> > contain the IBRD/FBRD registers, effectively making it a fixed-rated
> > UART (I guess that would be a ART, without the U then), and you
> > consequently don't even need to know the clock rate.
> 
> The idea of this was probably to let the baudrate set by some firmware
> code to the "right" value and the spec just didn't want to expose the
> details for the generic UART:
> "This specification does not cover registers needed to configure the
> UART as these are considered hardware-specific and will be set up by
> hardware-specific software."
> To me that reads like the SBSA UART is just for debugging, and you are
> expected just to access the data register.

Right, makes sense. It also avoids the case where Linux for some reason
ends up using a different line rate than the firmware, which can
cause a lot of unnecessary pain.

> > However, my guess is that most hardware in the real world contains
> > an actual pl011 and it does make a lot of sense to allow setting
> > the baud rate on it, which then requires knowing the input clock.
> > 
> > If there is any hardware that implements just the SBSA-mandated subset
> > rather than the full pl011, we should probably implement both
> > in the kernel: a dumb driver that can only send and receive, and the
> > more complex one that can set the bit rates and flow-control but that
> > requires a standardized ACPI table with the input clock rate.
> 
> The fast model I use can be switched to use the SBSA restricted PL011,
> and as expected the Linux kernel crashes at the device doesn't support
> DMA (and a lot more stuff) - but the current code requires it.

It does? We have a lot of platforms that don't have DMA support for
pl011.

> So I am about to implement a new driver for that SBSA subset. So far
> this will be a separate driver, starting from a copy of amba-pl011.c,
> but removing most of the code ;-)

Ok. You might want to consider starting from a different base though.
IIRC, pl011 uses uart_port as the basic abstraction, while the
new driver should probably use the raw tty_port instead.
drivers/tty/goldfish.c is probably a good example to look at for
that.

You could also make it a hvc_driver like drivers/tty/hvc/hvc_vio.c,
but I'm not sure if that model seen favorable by the tty maintainers.
It would probably be the shortest driver though.

	Arnd

[PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Monday 28 July 2014 15:20:06 Andre Przywara wrote:
> On 28/07/14 11:46, Arnd Bergmann wrote:
> > On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
> >> The PL011 UART is the use-case I keep hitting, that IP block has a 
> >> variable input clock on pretty much everything I have seen in the wild. 
> > 
> > Ok, I see. What does ACPI-5.1 say about pl011?
> > 
> > Interestingly, the subset of pl011 that is specified by SBSA does not
> > contain the IBRD/FBRD registers, effectively making it a fixed-rated
> > UART (I guess that would be a ART, without the U then), and you
> > consequently don't even need to know the clock rate.
> 
> The idea of this was probably to let the baudrate set by some firmware
> code to the "right" value and the spec just didn't want to expose the
> details for the generic UART:
> "This specification does not cover registers needed to configure the
> UART as these are considered hardware-specific and will be set up by
> hardware-specific software."
> To me that reads like the SBSA UART is just for debugging, and you are
> expected just to access the data register.

Right, makes sense. It also avoids the case where Linux for some reason
ends up using a different line rate than the firmware, which can
cause a lot of unnecessary pain.

> > However, my guess is that most hardware in the real world contains
> > an actual pl011 and it does make a lot of sense to allow setting
> > the baud rate on it, which then requires knowing the input clock.
> > 
> > If there is any hardware that implements just the SBSA-mandated subset
> > rather than the full pl011, we should probably implement both
> > in the kernel: a dumb driver that can only send and receive, and the
> > more complex one that can set the bit rates and flow-control but that
> > requires a standardized ACPI table with the input clock rate.
> 
> The fast model I use can be switched to use the SBSA restricted PL011,
> and as expected the Linux kernel crashes at the device doesn't support
> DMA (and a lot more stuff) - but the current code requires it.

It does? We have a lot of platforms that don't have DMA support for
pl011.

> So I am about to implement a new driver for that SBSA subset. So far
> this will be a separate driver, starting from a copy of amba-pl011.c,
> but removing most of the code ;-)

Ok. You might want to consider starting from a different base though.
IIRC, pl011 uses uart_port as the basic abstraction, while the
new driver should probably use the raw tty_port instead.
drivers/tty/goldfish.c is probably a good example to look at for
that.

You could also make it a hvc_driver like drivers/tty/hvc/hvc_vio.c,
but I'm not sure if that model seen favorable by the tty maintainers.
It would probably be the shortest driver though.

	Arnd

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Andre Przywara]

On 28/07/14 16:23, Arnd Bergmann wrote:
> On Monday 28 July 2014 15:20:06 Andre Przywara wrote:
>> On 28/07/14 11:46, Arnd Bergmann wrote:
>>> On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
>>>> The PL011 UART is the use-case I keep hitting, that IP block has a 
>>>> variable input clock on pretty much everything I have seen in the wild. 
>>>
>>> Ok, I see. What does ACPI-5.1 say about pl011?
>>>
>>> Interestingly, the subset of pl011 that is specified by SBSA does not
>>> contain the IBRD/FBRD registers, effectively making it a fixed-rated
>>> UART (I guess that would be a ART, without the U then), and you
>>> consequently don't even need to know the clock rate.
>>
>> The idea of this was probably to let the baudrate set by some firmware
>> code to the "right" value and the spec just didn't want to expose the
>> details for the generic UART:
>> "This specification does not cover registers needed to configure the
>> UART as these are considered hardware-specific and will be set up by
>> hardware-specific software."
>> To me that reads like the SBSA UART is just for debugging, and you are
>> expected just to access the data register.
> 
> Right, makes sense. It also avoids the case where Linux for some reason
> ends up using a different line rate than the firmware, which can
> cause a lot of unnecessary pain.
> 
>>> However, my guess is that most hardware in the real world contains
>>> an actual pl011 and it does make a lot of sense to allow setting
>>> the baud rate on it, which then requires knowing the input clock.
>>>
>>> If there is any hardware that implements just the SBSA-mandated subset
>>> rather than the full pl011, we should probably implement both
>>> in the kernel: a dumb driver that can only send and receive, and the
>>> more complex one that can set the bit rates and flow-control but that
>>> requires a standardized ACPI table with the input clock rate.
>>
>> The fast model I use can be switched to use the SBSA restricted PL011,
>> and as expected the Linux kernel crashes at the device doesn't support
>> DMA (and a lot more stuff) - but the current code requires it.
> 
> It does? We have a lot of platforms that don't have DMA support for
> pl011.

Well, to be honest I just booted the full featured kernel with the
changed fast model config, so the platform and the DT claimed DMA
support, just the emulated hardware doesn't implement it ;-)
And beside that a whole lot of other PL011 registers are not available,
so the crash could be caused by anything. I didn't look to closely why
it broke.

>> So I am about to implement a new driver for that SBSA subset. So far
>> this will be a separate driver, starting from a copy of amba-pl011.c,
>> but removing most of the code ;-)
> 
> Ok. You might want to consider starting from a different base though.
> IIRC, pl011 uses uart_port as the basic abstraction, while the
> new driver should probably use the raw tty_port instead.
> drivers/tty/goldfish.c is probably a good example to look at for
> that.

Good hint, will look at this.

Cheers,
Andre.

> 
> You could also make it a hvc_driver like drivers/tty/hvc/hvc_vio.c,
> but I'm not sure if that model seen favorable by the tty maintainers.
> It would probably be the shortest driver though.
> 
> 	Arnd
> 
> 

[PATCH 19/19] Documentation: ACPI for ARM64

[Andre Przywara]

On 28/07/14 16:23, Arnd Bergmann wrote:
> On Monday 28 July 2014 15:20:06 Andre Przywara wrote:
>> On 28/07/14 11:46, Arnd Bergmann wrote:
>>> On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
>>>> The PL011 UART is the use-case I keep hitting, that IP block has a 
>>>> variable input clock on pretty much everything I have seen in the wild. 
>>>
>>> Ok, I see. What does ACPI-5.1 say about pl011?
>>>
>>> Interestingly, the subset of pl011 that is specified by SBSA does not
>>> contain the IBRD/FBRD registers, effectively making it a fixed-rated
>>> UART (I guess that would be a ART, without the U then), and you
>>> consequently don't even need to know the clock rate.
>>
>> The idea of this was probably to let the baudrate set by some firmware
>> code to the "right" value and the spec just didn't want to expose the
>> details for the generic UART:
>> "This specification does not cover registers needed to configure the
>> UART as these are considered hardware-specific and will be set up by
>> hardware-specific software."
>> To me that reads like the SBSA UART is just for debugging, and you are
>> expected just to access the data register.
> 
> Right, makes sense. It also avoids the case where Linux for some reason
> ends up using a different line rate than the firmware, which can
> cause a lot of unnecessary pain.
> 
>>> However, my guess is that most hardware in the real world contains
>>> an actual pl011 and it does make a lot of sense to allow setting
>>> the baud rate on it, which then requires knowing the input clock.
>>>
>>> If there is any hardware that implements just the SBSA-mandated subset
>>> rather than the full pl011, we should probably implement both
>>> in the kernel: a dumb driver that can only send and receive, and the
>>> more complex one that can set the bit rates and flow-control but that
>>> requires a standardized ACPI table with the input clock rate.
>>
>> The fast model I use can be switched to use the SBSA restricted PL011,
>> and as expected the Linux kernel crashes at the device doesn't support
>> DMA (and a lot more stuff) - but the current code requires it.
> 
> It does? We have a lot of platforms that don't have DMA support for
> pl011.

Well, to be honest I just booted the full featured kernel with the
changed fast model config, so the platform and the DT claimed DMA
support, just the emulated hardware doesn't implement it ;-)
And beside that a whole lot of other PL011 registers are not available,
so the crash could be caused by anything. I didn't look to closely why
it broke.

>> So I am about to implement a new driver for that SBSA subset. So far
>> this will be a separate driver, starting from a copy of amba-pl011.c,
>> but removing most of the code ;-)
> 
> Ok. You might want to consider starting from a different base though.
> IIRC, pl011 uses uart_port as the basic abstraction, while the
> new driver should probably use the raw tty_port instead.
> drivers/tty/goldfish.c is probably a good example to look at for
> that.

Good hint, will look at this.

Cheers,
Andre.

> 
> You could also make it a hvc_driver like drivers/tty/hvc/hvc_vio.c,
> but I'm not sure if that model seen favorable by the tty maintainers.
> It would probably be the shortest driver though.
> 
> 	Arnd
> 
> 

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 09:42:57AM +0100, Graeme Gregory wrote:
> 
> On 27/07/2014 03:34, Olof Johansson wrote:
> >On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> >>From: Graeme Gregory <graeme.gregory@linaro.org>
> >>
> >>Add documentation for the guidelines of how to use ACPI
> >>on ARM64.
> >As the most vocal participant against ACPI being adopted, I would have
> >appreciated a cc on this patch set -- it's not like you were going for
> >a minimal set of cc recipients already. It makes it seem like you're
> >trying to sneak it past me for comments. Not cool. I know that's
> >probably not your intent, but still.
> >
> >Some comments below. Overall the doc looks pretty good, but the
> >details about _DSD and clocks are somewhat worrisome.
> >
> >>Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> >>Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >>---
> >>  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 240 insertions(+)
> >>  create mode 100644 Documentation/arm64/arm-acpi.txt
> >>
> >>diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> >>new file mode 100644
> >>index 0000000..12cd550
> >>--- /dev/null
> >>+++ b/Documentation/arm64/arm-acpi.txt
> >>@@ -0,0 +1,240 @@
> >>+ACPI on ARMv8 Servers
> >>+---------------------
> >>+
> >>+ACPI will be used for ARMv8 general purpose servers designed to follow
> >"ACPI might be used"    or     "can be used"
> >
> >>+the SBSA specification (currently available to people with an ARM login at
> >>+http://silver.arm.com)
> >>+
> >>+The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> >>+which is available at <http://www.uefi.org/acpi/specs>.
> >The implemented version where? The kernel implements that version?
> >Worth clarifying.
> ok
> 
> the tables passed must be acpi 5.1+, the kernel must then obviously
> implement the 5.1 features, will clarify.
> >>+If the machine does not meet these requirements then it is likely that Device
> >>+Tree (DT) is more suitable for the hardware.
> >This is should be a very clear statement that is currently vague
> >w.r.t. which requirements are met or not, especially based on the
> >sentence above.
> The SBSA is the set of requirements, will clarify.
> 
> >>+Relationship with Device Tree
> >>+-----------------------------
> >>+
> >>+ACPI support in drivers and subsystems for ARMv8 should never be mutually
> >>+exclusive with DT support at compile time.
> >>+
> >>+At boot time the kernel will only use one description method depending on
> >>+parameters passed from the bootloader.
> >Possibly overriden by kernel bootargs. And as debated for quite a
> >while earlier this year, acpi should still default to off -- if a DT
> >and ACPI are both passed in, DT should at this time be given priority.
> This does not work due to DT being misused as the kernel/bootloader
> communication layer as well. So a DT is always passed to the kernel.
> We cannot tell whether this is a useful DT without unpacking it and
> trying to boot platform from it.
> 
> There is an acpi=off parameter that can be passed to always disable
> acpi runtime.

Right, but the agreement we had from earlier this year was to keep ACPI
default off until we've seen at least the first generation of real hardware,
since we have no confidence that the system vendors will do sane things with
ACPI yet. If they completely mess it up, we at least will retain basic
functionality without accuring huge technical debt dealing with the messed up
ACPI tables forever.

In other words, to boot with ACPI enabled, the requrement is that you have to
pass 'acpi' or 'acpi=on' on the command line (or equivalent). Not the other way
around -- to have it on by default and give an option to turn it off.

If you need a refresher: http://www.secretlab.ca/archives/27

> >(Where can I learn more about how the boot loaders currently handle
> >this? Do some of them pass in both DT and ACPI on some platforms, for
> >example?)
> Currently only one bootloader protocol is supported for ACPI and
> thats UEFI. As noted above due to abuse of DT in the /chosen/ node a
> DT is always passed to the kernel.

The above is hard to understand. I suppose I should restate my question:
I presume actual end users will use something like Grub2 to load
a kernel/ramdisk/dtb. Where can I learn more about how it handles ACPI?

> >>+Regardless of whether DT or ACPI is used, the kernel must always be capable
> >>+of booting with either scheme.
> >It should always be possible to compile out ACPI. There will be plenty
> >of platforms that will not implement it, so disabling CONFIG_ACPI
> >needs to be possible.
> This will always be possible!

Yes, I commented because it should also be clear in the doc.

> >>+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.
> >>+
> >>+Booting using ACPI tables
> >>+-------------------------
> >>+
> >>+Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
> >>+is via the UEFI system configuration table.
> >>+
> >>+The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
> >>+RSDP table (the table with the ACPI signature "RSD PTR ").
> >>+
> >>+The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
> >>+
> >>+Processing of ACPI tables may be disabled by passing acpi=off on the kernel
> >>+command line.
> >>+
> >>+DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
> >>+only allow for 32bit addresses.
> >>+
> >>+DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
> >>+64-bit alternatives MUST be used.
> >>+
> >>+The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
> >>+and GTDT. If PCI is used the MCFG table MUST also be present.
> >>+
> >>+ACPI Detection
> >>+--------------
> >>+
> >>+Drivers should determine their probe() type by checking for ACPI_HANDLE,
> >>+or .of_node, or other information in the device structure. This is
> >>+detailed further in the "Driver Recomendations" section.
> >>+
> >>+If the presence of ACPI needs to be detected at runtime, then check the value
> >>+of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
> >Just to make sure, if acpi_disabled is 0, then there will be no acpi
> >handle associated with the device, right? I.e. there should be no need
> >to have every single driver check for whether ACPI is disabled, the
> >handle check should just fail instead.
> I need to clarify this obviously, I meant for the second paragraph
> for that to be for code outside driver probing. Inside drivers they
> should only check for ACPI_HANDLE presence. But other bits of code
> espcially bits parsing tables for information in early boot should
> check for acpi_disabled before hunting for the tables etc.

Yep, that sounds sane.

> >>+Device Enumeration
> >>+------------------
> >>+
> >>+Device descriptions in ACPI should use standard recognised ACPI interfaces.
> >>+These are far simpler than the information provided via Device Tree. Drivers
> >>+should take into account this simplicity and work with sensible defaults.
> >>+
> >>+On no account should a Device Tree attempt to be replicated in ASL using such
> >>+constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> >>+data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> >>+_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
> >I see these two sentences as contradictory, given that the _DSD doc
> >linked below contains examples that mirror over several properties,
> >such as "linux,default-trigger" and other LED-specific properties.
> >(section 2.4.2 in the below doc). "default-state" seems to come from
> >DT too?
> >
> >Care to elaborate and explain what the intention here is? This could
> >worst case turn into quite a mess.
> >
> >Given that ACPI can present completely different data based on what OS
> >is running, it's quite common to indeed have OS specific data in
> >there. How does that relate to this document and these practices?
> OS specific data has traditionally not worked out well for ACPI, I
> would like to "persuade" people not to use it on ARM.

It hasn't? I think Microsoft disagrees. It's also how vendors have been able to
present an older machine description to keep their newer hardware compatible
with older software, isn't it? How do you expect to handle that if you can
only present one table? It's the same challenge that DT has.

> The _DSD was quite late to the standards process and the supporting
> documentation is still catching up. We are working with ARM to bring
> these issues up and to define proper OS agnostic bindings for ARM.

I'm guessing that the first ARM should be ACPI? Or is ARM Ltd on critical path
on this?!

> >>+Common _DSD bindings should be submitted to ASWG to be included in the
> >>+document :-
> >>+
> >>+http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
> >So, for these that are a mirror of the device tree bindings, there
> >needs to be a wording here around reviewing the DT binding first so we
> >don't get diverging bindings.
> >
> >>+TODO: Clarification and examples from Juno implementation.
> >>+
> >>+Programmable Power Control Resources
> >>+------------------------------------
> >>+
> >>+Programmable power control resources include such resources as voltage/current
> >>+providers (regulators) and clock sources.
> >>+
> >>+For power control of these resources they should be represented with Power
> >>+Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
> >>+enabling/disabling of resources as they are needed.
> >>+
> >>+There exists in the ACPI 5.1 specification no standard binding for these objects
> >>+to enable programmable levels or rates so this should be avoid if possible and
> >>+the resources set to appropriate level by the firmware. If this is not possible
> >>+then any manipulation should be abstracted in ASL.
> >>+
> >>+Each device in ACPI has D-states and these can be controlled through
> >>+the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
> >>+
> >>+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 organise that it is allocated/enabled using the _PS0 method.
> >>+
> >>+Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
> >>+in the _PS3 method.
> >>+
> >>+Such code in _PS? methods will of course be very platform specific but
> >>+should allow the driver to operate the device without special non standard
> >>+values being read from ASL. Further, abstracting the use of these resources
> >>+allows hardware revisions without requiring updates to the kernel.
> >>+
> >>+TODO: Clarification and examples from Juno implementation.
> >>+
> >>+Clocks
> >>+------
> >>+
> >>+Like clocks that are part of the power resources there is no standard way
> >>+to represent a clock tree in ACPI 5.1 in a similar manner to how it is
> >>+described in DT.
> >>+
> >>+Devices affected by this include things like UARTs, SoC driven LCD displays,
> >>+etc.
> >>+
> >>+The firmware for example UEFI should initialise these clocks to fixed working
> >Odd wording.  Maube "The firmware (for example UEFI) should..."
> agreed!
> >>+values before the kernel is executed. If a driver requires to know rates of
> >>+clocks set by firmware then they can be passed to kernel using _DSD.
> >>+
> >>+example :-
> >>+
> >>+Device (CLK0) {
> >>+       ...
> >>+
> >>+       Name (_DSD, Package() {
> >>+               ToUUID("XXXXX"),
> >>+               Package() {
> >>+                       Package(2) {"#clock-cells", 0},
> >Clock-cells? What do they mean here? Is this specified in the ACPI
> >standards? I had to register to get access to it, and didn't feel like
> >doing that right now. I guess it's not _all_ that open a spec. :(
> >
> >>+                       Package(2) {"clock-frequency", "10000"}
> >>+               }
> >>+       })
> >>+
> >>+       ...
> >>+}
> >>+
> >>+Device (USR1) {
> >>+       ...
> >>+
> >>+       Name (_DSD, Package() {
> >>+               ToUUID("XXXXX"),
> >>+               Package() {
> >>+                       Package(2) {"clocks", Package() {1, ^CLK0}}},
> >A clock is a device in the ACPI model? Why not just provide the rate
> >as data into the device here? You said you're not trying to model the
> >clock tree, so why reference an external node for it?
> This section is still a bit WIP due to the above noted issues with
> _DSD documentation catching up with the standards process. I will
> need to work with the clock maintainers to see if we can agree a
> proper set of bindings for this. #blah-cells always was my least
> favorite DT feature.

Ok, work in progress is fine with me. But it is the reason for why we need to
continue defaulting to ACPI off for now -- just because we don't want to have
to support it in case some vendor picks up and use something half-baked while
it's still being worked on.

> >>+               }
> >>+       })
> >>+
> >>+       ...
> >>+}
> >>+
> >>+Driver Recommendations
> >>+----------------------
> >>+
> >>+DO NOT remove any FDT handling when adding ACPI support for a driver, different
> >>+systems may use the same device.
> >>+
> >>+DO try and keep complex sections of ACPI and DT functionality seperate. This
> >>+may mean a patch to break out some complex DT to another function before
> >>+the patch to add ACPI. This may happen in other functions but is most likely
> >>+in probe function. This gives a clearer flow of data for reviewing driver
> >>+source.
> >>+
> >>+probe() :-
> >>+
> >>+TODO: replace this with a specific real example from Juno?
> >>+
> >>+static int device_probe_dt(struct platform_device *pdev)
> >>+{
> >>+       /* DT specific functionality */
> >>+       ...
> >>+}
> >>+
> >>+static int device_probe_acpi(struct platform_device *pdev)
> >>+{
> >>+       /* ACPI specific functionality */
> >>+       ...
> >>+}
> >>+
> >>+static int device_probe(stuct platform_device *pdev)
> >>+{
> >>+       ...
> >>+       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
> >>+       struct device_node node = pdev->dev.of_node;
> >>+       ...
> >>+
> >>+       if (node)
> >>+               ret = device_probe_dt(pdev);
> >>+       else if (handle)
> >>+               ret = device_probe_acpi(pdev);
> >>+       else
> >>+               /* other initialisation */
> >>+               ...
> >>+       /* Continue with any generic probe operations */
> >>+       ...
> >>+}
> >This looks good to me, and it's also my preferred way of ACPI-enabling
> >drivers. I guess we might discuss this at KS since it was a proposed
> >topic there, and others will object. :)
> Hopefully someone can summarise the discussion at KS for me, I will
> not be there.

LWN.net usually has good summaries. I hope they'll be in the room this
time too. If not, we'll send out a summary separately.

> >>+
> >>+DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
> >>+the different names the driver is probed for, both from DT and from ACPI.
> >>+
> >>+module device tables :-
> >>+
> >>+static struct of_device_id virtio_mmio_match[] = {
> >>+        { .compatible = "virtio,mmio", },
> >>+        {},
> >>+};
> >>+MODULE_DEVICE_TABLE(of, virtio_mmio_match);
> >>+
> >>+static const struct acpi_device_id virtio_mmio_acpi_match[] = {
> >>+        { "LNRO0005", },
> >>+        { }
> >No comma here, but a comma on DT. Probably make them equivalent for
> >consistency (including space between the braces).
> ok
> >>+};
> >>+MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
> >>+
> >>+TODO: Add any other helpful rules that develop from Juno ACPI work.
> >Looks like this should be fixed before the patch is merged, or this
> >TODO removed.
> The plan is to fix these TODOs with actual data from Juno as that
> will be in the UEFI for Juno.
> >>+
> >>+ASWG
> >>+----
> >>+
> >>+The following areas are not yet well defined for ARM in the current ACPI
> >>+specification and are expected to be worked through in the UEFI ACPI
> >>+Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
> >>+Participation in this group is open to all UEFI members.
> >>+
> >>+       - ACPI based CPU topology
> >>+       - ACPI based Power management
> >>+       - CPU idle control based on PSCI
> >>+       - CPU performance control (CPPC)
> >>+
> >>+No code shall be accepted into the kernel unless it complies with the released
> >>+standards from UEFI ASWG. If there are features missing from ACPI to make it
> >>+function on a platform ECRs should be submitted to ASWG and go through the
> >>+approval process.
> >Thanks for listing the things that are not in place yet. Please keep
> >this doc up to date as new areas are discovered.
> >
> >
> >-Olof
> Thanks for the feedback, we shall work to incorporate it into the document.

Happy to help. Besides readiness to flip ACPI on by default, I don't
think we're in substantial technical disagreements here.


-Olof

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 09:42:57AM +0100, Graeme Gregory wrote:
> 
> On 27/07/2014 03:34, Olof Johansson wrote:
> >On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> >>From: Graeme Gregory <graeme.gregory@linaro.org>
> >>
> >>Add documentation for the guidelines of how to use ACPI
> >>on ARM64.
> >As the most vocal participant against ACPI being adopted, I would have
> >appreciated a cc on this patch set -- it's not like you were going for
> >a minimal set of cc recipients already. It makes it seem like you're
> >trying to sneak it past me for comments. Not cool. I know that's
> >probably not your intent, but still.
> >
> >Some comments below. Overall the doc looks pretty good, but the
> >details about _DSD and clocks are somewhat worrisome.
> >
> >>Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> >>Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >>---
> >>  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 240 insertions(+)
> >>  create mode 100644 Documentation/arm64/arm-acpi.txt
> >>
> >>diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> >>new file mode 100644
> >>index 0000000..12cd550
> >>--- /dev/null
> >>+++ b/Documentation/arm64/arm-acpi.txt
> >>@@ -0,0 +1,240 @@
> >>+ACPI on ARMv8 Servers
> >>+---------------------
> >>+
> >>+ACPI will be used for ARMv8 general purpose servers designed to follow
> >"ACPI might be used"    or     "can be used"
> >
> >>+the SBSA specification (currently available to people with an ARM login at
> >>+http://silver.arm.com)
> >>+
> >>+The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> >>+which is available at <http://www.uefi.org/acpi/specs>.
> >The implemented version where? The kernel implements that version?
> >Worth clarifying.
> ok
> 
> the tables passed must be acpi 5.1+, the kernel must then obviously
> implement the 5.1 features, will clarify.
> >>+If the machine does not meet these requirements then it is likely that Device
> >>+Tree (DT) is more suitable for the hardware.
> >This is should be a very clear statement that is currently vague
> >w.r.t. which requirements are met or not, especially based on the
> >sentence above.
> The SBSA is the set of requirements, will clarify.
> 
> >>+Relationship with Device Tree
> >>+-----------------------------
> >>+
> >>+ACPI support in drivers and subsystems for ARMv8 should never be mutually
> >>+exclusive with DT support at compile time.
> >>+
> >>+At boot time the kernel will only use one description method depending on
> >>+parameters passed from the bootloader.
> >Possibly overriden by kernel bootargs. And as debated for quite a
> >while earlier this year, acpi should still default to off -- if a DT
> >and ACPI are both passed in, DT should at this time be given priority.
> This does not work due to DT being misused as the kernel/bootloader
> communication layer as well. So a DT is always passed to the kernel.
> We cannot tell whether this is a useful DT without unpacking it and
> trying to boot platform from it.
> 
> There is an acpi=off parameter that can be passed to always disable
> acpi runtime.

Right, but the agreement we had from earlier this year was to keep ACPI
default off until we've seen at least the first generation of real hardware,
since we have no confidence that the system vendors will do sane things with
ACPI yet. If they completely mess it up, we at least will retain basic
functionality without accuring huge technical debt dealing with the messed up
ACPI tables forever.

In other words, to boot with ACPI enabled, the requrement is that you have to
pass 'acpi' or 'acpi=on' on the command line (or equivalent). Not the other way
around -- to have it on by default and give an option to turn it off.

If you need a refresher: http://www.secretlab.ca/archives/27

> >(Where can I learn more about how the boot loaders currently handle
> >this? Do some of them pass in both DT and ACPI on some platforms, for
> >example?)
> Currently only one bootloader protocol is supported for ACPI and
> thats UEFI. As noted above due to abuse of DT in the /chosen/ node a
> DT is always passed to the kernel.

The above is hard to understand. I suppose I should restate my question:
I presume actual end users will use something like Grub2 to load
a kernel/ramdisk/dtb. Where can I learn more about how it handles ACPI?

> >>+Regardless of whether DT or ACPI is used, the kernel must always be capable
> >>+of booting with either scheme.
> >It should always be possible to compile out ACPI. There will be plenty
> >of platforms that will not implement it, so disabling CONFIG_ACPI
> >needs to be possible.
> This will always be possible!

Yes, I commented because it should also be clear in the doc.

> >>+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.
> >>+
> >>+Booting using ACPI tables
> >>+-------------------------
> >>+
> >>+Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
> >>+is via the UEFI system configuration table.
> >>+
> >>+The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
> >>+RSDP table (the table with the ACPI signature "RSD PTR ").
> >>+
> >>+The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
> >>+
> >>+Processing of ACPI tables may be disabled by passing acpi=off on the kernel
> >>+command line.
> >>+
> >>+DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
> >>+only allow for 32bit addresses.
> >>+
> >>+DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
> >>+64-bit alternatives MUST be used.
> >>+
> >>+The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
> >>+and GTDT. If PCI is used the MCFG table MUST also be present.
> >>+
> >>+ACPI Detection
> >>+--------------
> >>+
> >>+Drivers should determine their probe() type by checking for ACPI_HANDLE,
> >>+or .of_node, or other information in the device structure. This is
> >>+detailed further in the "Driver Recomendations" section.
> >>+
> >>+If the presence of ACPI needs to be detected at runtime, then check the value
> >>+of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
> >Just to make sure, if acpi_disabled is 0, then there will be no acpi
> >handle associated with the device, right? I.e. there should be no need
> >to have every single driver check for whether ACPI is disabled, the
> >handle check should just fail instead.
> I need to clarify this obviously, I meant for the second paragraph
> for that to be for code outside driver probing. Inside drivers they
> should only check for ACPI_HANDLE presence. But other bits of code
> espcially bits parsing tables for information in early boot should
> check for acpi_disabled before hunting for the tables etc.

Yep, that sounds sane.

> >>+Device Enumeration
> >>+------------------
> >>+
> >>+Device descriptions in ACPI should use standard recognised ACPI interfaces.
> >>+These are far simpler than the information provided via Device Tree. Drivers
> >>+should take into account this simplicity and work with sensible defaults.
> >>+
> >>+On no account should a Device Tree attempt to be replicated in ASL using such
> >>+constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> >>+data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> >>+_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
> >I see these two sentences as contradictory, given that the _DSD doc
> >linked below contains examples that mirror over several properties,
> >such as "linux,default-trigger" and other LED-specific properties.
> >(section 2.4.2 in the below doc). "default-state" seems to come from
> >DT too?
> >
> >Care to elaborate and explain what the intention here is? This could
> >worst case turn into quite a mess.
> >
> >Given that ACPI can present completely different data based on what OS
> >is running, it's quite common to indeed have OS specific data in
> >there. How does that relate to this document and these practices?
> OS specific data has traditionally not worked out well for ACPI, I
> would like to "persuade" people not to use it on ARM.

It hasn't? I think Microsoft disagrees. It's also how vendors have been able to
present an older machine description to keep their newer hardware compatible
with older software, isn't it? How do you expect to handle that if you can
only present one table? It's the same challenge that DT has.

> The _DSD was quite late to the standards process and the supporting
> documentation is still catching up. We are working with ARM to bring
> these issues up and to define proper OS agnostic bindings for ARM.

I'm guessing that the first ARM should be ACPI? Or is ARM Ltd on critical path
on this?!

> >>+Common _DSD bindings should be submitted to ASWG to be included in the
> >>+document :-
> >>+
> >>+http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
> >So, for these that are a mirror of the device tree bindings, there
> >needs to be a wording here around reviewing the DT binding first so we
> >don't get diverging bindings.
> >
> >>+TODO: Clarification and examples from Juno implementation.
> >>+
> >>+Programmable Power Control Resources
> >>+------------------------------------
> >>+
> >>+Programmable power control resources include such resources as voltage/current
> >>+providers (regulators) and clock sources.
> >>+
> >>+For power control of these resources they should be represented with Power
> >>+Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
> >>+enabling/disabling of resources as they are needed.
> >>+
> >>+There exists in the ACPI 5.1 specification no standard binding for these objects
> >>+to enable programmable levels or rates so this should be avoid if possible and
> >>+the resources set to appropriate level by the firmware. If this is not possible
> >>+then any manipulation should be abstracted in ASL.
> >>+
> >>+Each device in ACPI has D-states and these can be controlled through
> >>+the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
> >>+
> >>+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 organise that it is allocated/enabled using the _PS0 method.
> >>+
> >>+Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
> >>+in the _PS3 method.
> >>+
> >>+Such code in _PS? methods will of course be very platform specific but
> >>+should allow the driver to operate the device without special non standard
> >>+values being read from ASL. Further, abstracting the use of these resources
> >>+allows hardware revisions without requiring updates to the kernel.
> >>+
> >>+TODO: Clarification and examples from Juno implementation.
> >>+
> >>+Clocks
> >>+------
> >>+
> >>+Like clocks that are part of the power resources there is no standard way
> >>+to represent a clock tree in ACPI 5.1 in a similar manner to how it is
> >>+described in DT.
> >>+
> >>+Devices affected by this include things like UARTs, SoC driven LCD displays,
> >>+etc.
> >>+
> >>+The firmware for example UEFI should initialise these clocks to fixed working
> >Odd wording.  Maube "The firmware (for example UEFI) should..."
> agreed!
> >>+values before the kernel is executed. If a driver requires to know rates of
> >>+clocks set by firmware then they can be passed to kernel using _DSD.
> >>+
> >>+example :-
> >>+
> >>+Device (CLK0) {
> >>+       ...
> >>+
> >>+       Name (_DSD, Package() {
> >>+               ToUUID("XXXXX"),
> >>+               Package() {
> >>+                       Package(2) {"#clock-cells", 0},
> >Clock-cells? What do they mean here? Is this specified in the ACPI
> >standards? I had to register to get access to it, and didn't feel like
> >doing that right now. I guess it's not _all_ that open a spec. :(
> >
> >>+                       Package(2) {"clock-frequency", "10000"}
> >>+               }
> >>+       })
> >>+
> >>+       ...
> >>+}
> >>+
> >>+Device (USR1) {
> >>+       ...
> >>+
> >>+       Name (_DSD, Package() {
> >>+               ToUUID("XXXXX"),
> >>+               Package() {
> >>+                       Package(2) {"clocks", Package() {1, ^CLK0}}},
> >A clock is a device in the ACPI model? Why not just provide the rate
> >as data into the device here? You said you're not trying to model the
> >clock tree, so why reference an external node for it?
> This section is still a bit WIP due to the above noted issues with
> _DSD documentation catching up with the standards process. I will
> need to work with the clock maintainers to see if we can agree a
> proper set of bindings for this. #blah-cells always was my least
> favorite DT feature.

Ok, work in progress is fine with me. But it is the reason for why we need to
continue defaulting to ACPI off for now -- just because we don't want to have
to support it in case some vendor picks up and use something half-baked while
it's still being worked on.

> >>+               }
> >>+       })
> >>+
> >>+       ...
> >>+}
> >>+
> >>+Driver Recommendations
> >>+----------------------
> >>+
> >>+DO NOT remove any FDT handling when adding ACPI support for a driver, different
> >>+systems may use the same device.
> >>+
> >>+DO try and keep complex sections of ACPI and DT functionality seperate. This
> >>+may mean a patch to break out some complex DT to another function before
> >>+the patch to add ACPI. This may happen in other functions but is most likely
> >>+in probe function. This gives a clearer flow of data for reviewing driver
> >>+source.
> >>+
> >>+probe() :-
> >>+
> >>+TODO: replace this with a specific real example from Juno?
> >>+
> >>+static int device_probe_dt(struct platform_device *pdev)
> >>+{
> >>+       /* DT specific functionality */
> >>+       ...
> >>+}
> >>+
> >>+static int device_probe_acpi(struct platform_device *pdev)
> >>+{
> >>+       /* ACPI specific functionality */
> >>+       ...
> >>+}
> >>+
> >>+static int device_probe(stuct platform_device *pdev)
> >>+{
> >>+       ...
> >>+       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
> >>+       struct device_node node = pdev->dev.of_node;
> >>+       ...
> >>+
> >>+       if (node)
> >>+               ret = device_probe_dt(pdev);
> >>+       else if (handle)
> >>+               ret = device_probe_acpi(pdev);
> >>+       else
> >>+               /* other initialisation */
> >>+               ...
> >>+       /* Continue with any generic probe operations */
> >>+       ...
> >>+}
> >This looks good to me, and it's also my preferred way of ACPI-enabling
> >drivers. I guess we might discuss this at KS since it was a proposed
> >topic there, and others will object. :)
> Hopefully someone can summarise the discussion at KS for me, I will
> not be there.

LWN.net usually has good summaries. I hope they'll be in the room this
time too. If not, we'll send out a summary separately.

> >>+
> >>+DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
> >>+the different names the driver is probed for, both from DT and from ACPI.
> >>+
> >>+module device tables :-
> >>+
> >>+static struct of_device_id virtio_mmio_match[] = {
> >>+        { .compatible = "virtio,mmio", },
> >>+        {},
> >>+};
> >>+MODULE_DEVICE_TABLE(of, virtio_mmio_match);
> >>+
> >>+static const struct acpi_device_id virtio_mmio_acpi_match[] = {
> >>+        { "LNRO0005", },
> >>+        { }
> >No comma here, but a comma on DT. Probably make them equivalent for
> >consistency (including space between the braces).
> ok
> >>+};
> >>+MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
> >>+
> >>+TODO: Add any other helpful rules that develop from Juno ACPI work.
> >Looks like this should be fixed before the patch is merged, or this
> >TODO removed.
> The plan is to fix these TODOs with actual data from Juno as that
> will be in the UEFI for Juno.
> >>+
> >>+ASWG
> >>+----
> >>+
> >>+The following areas are not yet well defined for ARM in the current ACPI
> >>+specification and are expected to be worked through in the UEFI ACPI
> >>+Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
> >>+Participation in this group is open to all UEFI members.
> >>+
> >>+       - ACPI based CPU topology
> >>+       - ACPI based Power management
> >>+       - CPU idle control based on PSCI
> >>+       - CPU performance control (CPPC)
> >>+
> >>+No code shall be accepted into the kernel unless it complies with the released
> >>+standards from UEFI ASWG. If there are features missing from ACPI to make it
> >>+function on a platform ECRs should be submitted to ASWG and go through the
> >>+approval process.
> >Thanks for listing the things that are not in place yet. Please keep
> >this doc up to date as new areas are discovered.
> >
> >
> >-Olof
> Thanks for the feedback, we shall work to incorporate it into the document.

Happy to help. Besides readiness to flip ACPI on by default, I don't
think we're in substantial technical disagreements here.


-Olof

[PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 09:42:57AM +0100, Graeme Gregory wrote:
> 
> On 27/07/2014 03:34, Olof Johansson wrote:
> >On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> >>From: Graeme Gregory <graeme.gregory@linaro.org>
> >>
> >>Add documentation for the guidelines of how to use ACPI
> >>on ARM64.
> >As the most vocal participant against ACPI being adopted, I would have
> >appreciated a cc on this patch set -- it's not like you were going for
> >a minimal set of cc recipients already. It makes it seem like you're
> >trying to sneak it past me for comments. Not cool. I know that's
> >probably not your intent, but still.
> >
> >Some comments below. Overall the doc looks pretty good, but the
> >details about _DSD and clocks are somewhat worrisome.
> >
> >>Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> >>Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >>---
> >>  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
> >>  1 file changed, 240 insertions(+)
> >>  create mode 100644 Documentation/arm64/arm-acpi.txt
> >>
> >>diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> >>new file mode 100644
> >>index 0000000..12cd550
> >>--- /dev/null
> >>+++ b/Documentation/arm64/arm-acpi.txt
> >>@@ -0,0 +1,240 @@
> >>+ACPI on ARMv8 Servers
> >>+---------------------
> >>+
> >>+ACPI will be used for ARMv8 general purpose servers designed to follow
> >"ACPI might be used"    or     "can be used"
> >
> >>+the SBSA specification (currently available to people with an ARM login at
> >>+http://silver.arm.com)
> >>+
> >>+The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> >>+which is available at <http://www.uefi.org/acpi/specs>.
> >The implemented version where? The kernel implements that version?
> >Worth clarifying.
> ok
> 
> the tables passed must be acpi 5.1+, the kernel must then obviously
> implement the 5.1 features, will clarify.
> >>+If the machine does not meet these requirements then it is likely that Device
> >>+Tree (DT) is more suitable for the hardware.
> >This is should be a very clear statement that is currently vague
> >w.r.t. which requirements are met or not, especially based on the
> >sentence above.
> The SBSA is the set of requirements, will clarify.
> 
> >>+Relationship with Device Tree
> >>+-----------------------------
> >>+
> >>+ACPI support in drivers and subsystems for ARMv8 should never be mutually
> >>+exclusive with DT support at compile time.
> >>+
> >>+At boot time the kernel will only use one description method depending on
> >>+parameters passed from the bootloader.
> >Possibly overriden by kernel bootargs. And as debated for quite a
> >while earlier this year, acpi should still default to off -- if a DT
> >and ACPI are both passed in, DT should at this time be given priority.
> This does not work due to DT being misused as the kernel/bootloader
> communication layer as well. So a DT is always passed to the kernel.
> We cannot tell whether this is a useful DT without unpacking it and
> trying to boot platform from it.
> 
> There is an acpi=off parameter that can be passed to always disable
> acpi runtime.

Right, but the agreement we had from earlier this year was to keep ACPI
default off until we've seen at least the first generation of real hardware,
since we have no confidence that the system vendors will do sane things with
ACPI yet. If they completely mess it up, we at least will retain basic
functionality without accuring huge technical debt dealing with the messed up
ACPI tables forever.

In other words, to boot with ACPI enabled, the requrement is that you have to
pass 'acpi' or 'acpi=on' on the command line (or equivalent). Not the other way
around -- to have it on by default and give an option to turn it off.

If you need a refresher: http://www.secretlab.ca/archives/27

> >(Where can I learn more about how the boot loaders currently handle
> >this? Do some of them pass in both DT and ACPI on some platforms, for
> >example?)
> Currently only one bootloader protocol is supported for ACPI and
> thats UEFI. As noted above due to abuse of DT in the /chosen/ node a
> DT is always passed to the kernel.

The above is hard to understand. I suppose I should restate my question:
I presume actual end users will use something like Grub2 to load
a kernel/ramdisk/dtb. Where can I learn more about how it handles ACPI?

> >>+Regardless of whether DT or ACPI is used, the kernel must always be capable
> >>+of booting with either scheme.
> >It should always be possible to compile out ACPI. There will be plenty
> >of platforms that will not implement it, so disabling CONFIG_ACPI
> >needs to be possible.
> This will always be possible!

Yes, I commented because it should also be clear in the doc.

> >>+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.
> >>+
> >>+Booting using ACPI tables
> >>+-------------------------
> >>+
> >>+Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
> >>+is via the UEFI system configuration table.
> >>+
> >>+The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
> >>+RSDP table (the table with the ACPI signature "RSD PTR ").
> >>+
> >>+The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
> >>+
> >>+Processing of ACPI tables may be disabled by passing acpi=off on the kernel
> >>+command line.
> >>+
> >>+DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
> >>+only allow for 32bit addresses.
> >>+
> >>+DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
> >>+64-bit alternatives MUST be used.
> >>+
> >>+The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
> >>+and GTDT. If PCI is used the MCFG table MUST also be present.
> >>+
> >>+ACPI Detection
> >>+--------------
> >>+
> >>+Drivers should determine their probe() type by checking for ACPI_HANDLE,
> >>+or .of_node, or other information in the device structure. This is
> >>+detailed further in the "Driver Recomendations" section.
> >>+
> >>+If the presence of ACPI needs to be detected at runtime, then check the value
> >>+of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
> >Just to make sure, if acpi_disabled is 0, then there will be no acpi
> >handle associated with the device, right? I.e. there should be no need
> >to have every single driver check for whether ACPI is disabled, the
> >handle check should just fail instead.
> I need to clarify this obviously, I meant for the second paragraph
> for that to be for code outside driver probing. Inside drivers they
> should only check for ACPI_HANDLE presence. But other bits of code
> espcially bits parsing tables for information in early boot should
> check for acpi_disabled before hunting for the tables etc.

Yep, that sounds sane.

> >>+Device Enumeration
> >>+------------------
> >>+
> >>+Device descriptions in ACPI should use standard recognised ACPI interfaces.
> >>+These are far simpler than the information provided via Device Tree. Drivers
> >>+should take into account this simplicity and work with sensible defaults.
> >>+
> >>+On no account should a Device Tree attempt to be replicated in ASL using such
> >>+constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> >>+data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> >>+_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
> >I see these two sentences as contradictory, given that the _DSD doc
> >linked below contains examples that mirror over several properties,
> >such as "linux,default-trigger" and other LED-specific properties.
> >(section 2.4.2 in the below doc). "default-state" seems to come from
> >DT too?
> >
> >Care to elaborate and explain what the intention here is? This could
> >worst case turn into quite a mess.
> >
> >Given that ACPI can present completely different data based on what OS
> >is running, it's quite common to indeed have OS specific data in
> >there. How does that relate to this document and these practices?
> OS specific data has traditionally not worked out well for ACPI, I
> would like to "persuade" people not to use it on ARM.

It hasn't? I think Microsoft disagrees. It's also how vendors have been able to
present an older machine description to keep their newer hardware compatible
with older software, isn't it? How do you expect to handle that if you can
only present one table? It's the same challenge that DT has.

> The _DSD was quite late to the standards process and the supporting
> documentation is still catching up. We are working with ARM to bring
> these issues up and to define proper OS agnostic bindings for ARM.

I'm guessing that the first ARM should be ACPI? Or is ARM Ltd on critical path
on this?!

> >>+Common _DSD bindings should be submitted to ASWG to be included in the
> >>+document :-
> >>+
> >>+http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
> >So, for these that are a mirror of the device tree bindings, there
> >needs to be a wording here around reviewing the DT binding first so we
> >don't get diverging bindings.
> >
> >>+TODO: Clarification and examples from Juno implementation.
> >>+
> >>+Programmable Power Control Resources
> >>+------------------------------------
> >>+
> >>+Programmable power control resources include such resources as voltage/current
> >>+providers (regulators) and clock sources.
> >>+
> >>+For power control of these resources they should be represented with Power
> >>+Resource Objects (ACPI Section 7.1). The ACPI core will then handle correctly
> >>+enabling/disabling of resources as they are needed.
> >>+
> >>+There exists in the ACPI 5.1 specification no standard binding for these objects
> >>+to enable programmable levels or rates so this should be avoid if possible and
> >>+the resources set to appropriate level by the firmware. If this is not possible
> >>+then any manipulation should be abstracted in ASL.
> >>+
> >>+Each device in ACPI has D-states and these can be controlled through
> >>+the optional methods _PS0..._PS3 where _PS0 is full on and _PS3 is full off.
> >>+
> >>+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 organise that it is allocated/enabled using the _PS0 method.
> >>+
> >>+Resources allocated/enabled in the _PS0 method should be disabled/de-allocated
> >>+in the _PS3 method.
> >>+
> >>+Such code in _PS? methods will of course be very platform specific but
> >>+should allow the driver to operate the device without special non standard
> >>+values being read from ASL. Further, abstracting the use of these resources
> >>+allows hardware revisions without requiring updates to the kernel.
> >>+
> >>+TODO: Clarification and examples from Juno implementation.
> >>+
> >>+Clocks
> >>+------
> >>+
> >>+Like clocks that are part of the power resources there is no standard way
> >>+to represent a clock tree in ACPI 5.1 in a similar manner to how it is
> >>+described in DT.
> >>+
> >>+Devices affected by this include things like UARTs, SoC driven LCD displays,
> >>+etc.
> >>+
> >>+The firmware for example UEFI should initialise these clocks to fixed working
> >Odd wording.  Maube "The firmware (for example UEFI) should..."
> agreed!
> >>+values before the kernel is executed. If a driver requires to know rates of
> >>+clocks set by firmware then they can be passed to kernel using _DSD.
> >>+
> >>+example :-
> >>+
> >>+Device (CLK0) {
> >>+       ...
> >>+
> >>+       Name (_DSD, Package() {
> >>+               ToUUID("XXXXX"),
> >>+               Package() {
> >>+                       Package(2) {"#clock-cells", 0},
> >Clock-cells? What do they mean here? Is this specified in the ACPI
> >standards? I had to register to get access to it, and didn't feel like
> >doing that right now. I guess it's not _all_ that open a spec. :(
> >
> >>+                       Package(2) {"clock-frequency", "10000"}
> >>+               }
> >>+       })
> >>+
> >>+       ...
> >>+}
> >>+
> >>+Device (USR1) {
> >>+       ...
> >>+
> >>+       Name (_DSD, Package() {
> >>+               ToUUID("XXXXX"),
> >>+               Package() {
> >>+                       Package(2) {"clocks", Package() {1, ^CLK0}}},
> >A clock is a device in the ACPI model? Why not just provide the rate
> >as data into the device here? You said you're not trying to model the
> >clock tree, so why reference an external node for it?
> This section is still a bit WIP due to the above noted issues with
> _DSD documentation catching up with the standards process. I will
> need to work with the clock maintainers to see if we can agree a
> proper set of bindings for this. #blah-cells always was my least
> favorite DT feature.

Ok, work in progress is fine with me. But it is the reason for why we need to
continue defaulting to ACPI off for now -- just because we don't want to have
to support it in case some vendor picks up and use something half-baked while
it's still being worked on.

> >>+               }
> >>+       })
> >>+
> >>+       ...
> >>+}
> >>+
> >>+Driver Recommendations
> >>+----------------------
> >>+
> >>+DO NOT remove any FDT handling when adding ACPI support for a driver, different
> >>+systems may use the same device.
> >>+
> >>+DO try and keep complex sections of ACPI and DT functionality seperate. This
> >>+may mean a patch to break out some complex DT to another function before
> >>+the patch to add ACPI. This may happen in other functions but is most likely
> >>+in probe function. This gives a clearer flow of data for reviewing driver
> >>+source.
> >>+
> >>+probe() :-
> >>+
> >>+TODO: replace this with a specific real example from Juno?
> >>+
> >>+static int device_probe_dt(struct platform_device *pdev)
> >>+{
> >>+       /* DT specific functionality */
> >>+       ...
> >>+}
> >>+
> >>+static int device_probe_acpi(struct platform_device *pdev)
> >>+{
> >>+       /* ACPI specific functionality */
> >>+       ...
> >>+}
> >>+
> >>+static int device_probe(stuct platform_device *pdev)
> >>+{
> >>+       ...
> >>+       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
> >>+       struct device_node node = pdev->dev.of_node;
> >>+       ...
> >>+
> >>+       if (node)
> >>+               ret = device_probe_dt(pdev);
> >>+       else if (handle)
> >>+               ret = device_probe_acpi(pdev);
> >>+       else
> >>+               /* other initialisation */
> >>+               ...
> >>+       /* Continue with any generic probe operations */
> >>+       ...
> >>+}
> >This looks good to me, and it's also my preferred way of ACPI-enabling
> >drivers. I guess we might discuss this at KS since it was a proposed
> >topic there, and others will object. :)
> Hopefully someone can summarise the discussion at KS for me, I will
> not be there.

LWN.net usually has good summaries. I hope they'll be in the room this
time too. If not, we'll send out a summary separately.

> >>+
> >>+DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
> >>+the different names the driver is probed for, both from DT and from ACPI.
> >>+
> >>+module device tables :-
> >>+
> >>+static struct of_device_id virtio_mmio_match[] = {
> >>+        { .compatible = "virtio,mmio", },
> >>+        {},
> >>+};
> >>+MODULE_DEVICE_TABLE(of, virtio_mmio_match);
> >>+
> >>+static const struct acpi_device_id virtio_mmio_acpi_match[] = {
> >>+        { "LNRO0005", },
> >>+        { }
> >No comma here, but a comma on DT. Probably make them equivalent for
> >consistency (including space between the braces).
> ok
> >>+};
> >>+MODULE_DEVICE_TABLE(acpi, virtio_mmio_acpi_match);
> >>+
> >>+TODO: Add any other helpful rules that develop from Juno ACPI work.
> >Looks like this should be fixed before the patch is merged, or this
> >TODO removed.
> The plan is to fix these TODOs with actual data from Juno as that
> will be in the UEFI for Juno.
> >>+
> >>+ASWG
> >>+----
> >>+
> >>+The following areas are not yet well defined for ARM in the current ACPI
> >>+specification and are expected to be worked through in the UEFI ACPI
> >>+Specification Working Group (ASWG) <http://www.uefi.org/workinggroups>.
> >>+Participation in this group is open to all UEFI members.
> >>+
> >>+       - ACPI based CPU topology
> >>+       - ACPI based Power management
> >>+       - CPU idle control based on PSCI
> >>+       - CPU performance control (CPPC)
> >>+
> >>+No code shall be accepted into the kernel unless it complies with the released
> >>+standards from UEFI ASWG. If there are features missing from ACPI to make it
> >>+function on a platform ECRs should be submitted to ASWG and go through the
> >>+approval process.
> >Thanks for listing the things that are not in place yet. Please keep
> >this doc up to date as new areas are discovered.
> >
> >
> >-Olof
> Thanks for the feedback, we shall work to incorporate it into the document.

Happy to help. Besides readiness to flip ACPI on by default, I don't
think we're in substantial technical disagreements here.


-Olof

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 11:07:50AM +0200, Arnd Bergmann wrote:
> On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > +Relationship with Device Tree
> > > +-----------------------------
> > > +
> > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > +exclusive with DT support at compile time.
> > > +
> > > +At boot time the kernel will only use one description method depending on
> > > +parameters passed from the bootloader.
> > 
> > Possibly overriden by kernel bootargs. And as debated for quite a
> > while earlier this year, acpi should still default to off -- if a DT
> > and ACPI are both passed in, DT should at this time be given priority.
> 
> I think this would be harder to do with the way that ACPI is passed in
> to the kernel. IIRC, you always have a minimal DT information based on
> the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> to the ACPI tables, which are then used for populating the Linux platform
> devices (unless acpi=disabled is set), while the other contents of the
> DTB may be present but we skip the of_platform_populate state.

How can it be harder to do? If you support acpi=off, then you should support
acpi=on.

Another alternative would be to have an early fixup that stubs out
the acpi properties from the DTB unless there's an 'acpi' or 'acpi=on'
argument on the cmdline. Not quite as tidy a solution, though.

> If this is correct, then replacing the firmware-generated dtb with a
> user-provided on would implicitly remove the ACPI tables from visibility,
> which is exactly what we want.

I was of the impression that firmware patches in the ACPI entries into either
device-tree before launching the kernel. Is that not the case? And what if
some bootloader chooses to do it that way in the future? It's better to not
assume that they get it right.

> It's possible that I'm misremembering it though, and it should be
> documented better.

Yes, definitely needs to be documented to not leave room for random
interpretation later on.


-Olof

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 11:07:50AM +0200, Arnd Bergmann wrote:
> On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > +Relationship with Device Tree
> > > +-----------------------------
> > > +
> > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > +exclusive with DT support at compile time.
> > > +
> > > +At boot time the kernel will only use one description method depending on
> > > +parameters passed from the bootloader.
> > 
> > Possibly overriden by kernel bootargs. And as debated for quite a
> > while earlier this year, acpi should still default to off -- if a DT
> > and ACPI are both passed in, DT should at this time be given priority.
> 
> I think this would be harder to do with the way that ACPI is passed in
> to the kernel. IIRC, you always have a minimal DT information based on
> the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> to the ACPI tables, which are then used for populating the Linux platform
> devices (unless acpi=disabled is set), while the other contents of the
> DTB may be present but we skip the of_platform_populate state.

How can it be harder to do? If you support acpi=off, then you should support
acpi=on.

Another alternative would be to have an early fixup that stubs out
the acpi properties from the DTB unless there's an 'acpi' or 'acpi=on'
argument on the cmdline. Not quite as tidy a solution, though.

> If this is correct, then replacing the firmware-generated dtb with a
> user-provided on would implicitly remove the ACPI tables from visibility,
> which is exactly what we want.

I was of the impression that firmware patches in the ACPI entries into either
device-tree before launching the kernel. Is that not the case? And what if
some bootloader chooses to do it that way in the future? It's better to not
assume that they get it right.

> It's possible that I'm misremembering it though, and it should be
> documented better.

Yes, definitely needs to be documented to not leave room for random
interpretation later on.


-Olof

[PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 11:07:50AM +0200, Arnd Bergmann wrote:
> On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > +Relationship with Device Tree
> > > +-----------------------------
> > > +
> > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > +exclusive with DT support at compile time.
> > > +
> > > +At boot time the kernel will only use one description method depending on
> > > +parameters passed from the bootloader.
> > 
> > Possibly overriden by kernel bootargs. And as debated for quite a
> > while earlier this year, acpi should still default to off -- if a DT
> > and ACPI are both passed in, DT should at this time be given priority.
> 
> I think this would be harder to do with the way that ACPI is passed in
> to the kernel. IIRC, you always have a minimal DT information based on
> the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> to the ACPI tables, which are then used for populating the Linux platform
> devices (unless acpi=disabled is set), while the other contents of the
> DTB may be present but we skip the of_platform_populate state.

How can it be harder to do? If you support acpi=off, then you should support
acpi=on.

Another alternative would be to have an early fixup that stubs out
the acpi properties from the DTB unless there's an 'acpi' or 'acpi=on'
argument on the cmdline. Not quite as tidy a solution, though.

> If this is correct, then replacing the firmware-generated dtb with a
> user-provided on would implicitly remove the ACPI tables from visibility,
> which is exactly what we want.

I was of the impression that firmware patches in the ACPI entries into either
device-tree before launching the kernel. Is that not the case? And what if
some bootloader chooses to do it that way in the future? It's better to not
assume that they get it right.

> It's possible that I'm misremembering it though, and it should be
> documented better.

Yes, definitely needs to be documented to not leave room for random
interpretation later on.


-Olof

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 11:12:29AM +0100, Mark Rutland wrote:
> On Mon, Jul 28, 2014 at 10:07:50AM +0100, Arnd Bergmann wrote:
> > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > > +Relationship with Device Tree
> > > > +-----------------------------
> > > > +
> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > > +exclusive with DT support at compile time.
> > > > +
> > > > +At boot time the kernel will only use one description method depending on
> > > > +parameters passed from the bootloader.
> > > 
> > > Possibly overriden by kernel bootargs. And as debated for quite a
> > > while earlier this year, acpi should still default to off -- if a DT
> > > and ACPI are both passed in, DT should at this time be given priority.
> > 
> > I think this would be harder to do with the way that ACPI is passed in
> > to the kernel. IIRC, you always have a minimal DT information based on
> > the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> > to the ACPI tables, which are then used for populating the Linux platform
> > devices (unless acpi=disabled is set), while the other contents of the
> > DTB may be present but we skip the of_platform_populate state.
> > 
> > If this is correct, then replacing the firmware-generated dtb with a
> > user-provided on would implicitly remove the ACPI tables from visibility,
> > which is exactly what we want.
> 
> That's not quite true.
> 
> There might not be any DTB, or the user might have provided a DTB with
> only /chosen/bootargs. Trying to distinguish the many cases of possible
> DTB is broken as a concept.
> 
> The EFI stub will attempt to get a DTB from somewhere (provided by
> filename or as a system table with a magic UUID), and if it can't find
> one will generate an empty stub DTB.
> 
> Then it will go and perform some EFI memory setup, placing some
> properties in the DTB (which might be a stub) describing the EFI memory
> map.
> 
> Then we boot the kernel proper, which sees the EFI pointers and looks
> for an ACPI table. If they are found, ACPI is used. Otherwise we attempt
> to use the DTB (which might be a stub).
> 
> Unless ACPI is explcitly disabled, ACPI will be used if present.

Ah, I saw this after I replied to Arnd's email.

The above sounds more like how I envisioned things working, so based on that,
the default just needs to be flipped and we should be fine (i.e. ACPI needs to
be explicitly enabled).


-Olof

[PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 11:12:29AM +0100, Mark Rutland wrote:
> On Mon, Jul 28, 2014 at 10:07:50AM +0100, Arnd Bergmann wrote:
> > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > > +Relationship with Device Tree
> > > > +-----------------------------
> > > > +
> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > > +exclusive with DT support at compile time.
> > > > +
> > > > +At boot time the kernel will only use one description method depending on
> > > > +parameters passed from the bootloader.
> > > 
> > > Possibly overriden by kernel bootargs. And as debated for quite a
> > > while earlier this year, acpi should still default to off -- if a DT
> > > and ACPI are both passed in, DT should at this time be given priority.
> > 
> > I think this would be harder to do with the way that ACPI is passed in
> > to the kernel. IIRC, you always have a minimal DT information based on
> > the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> > to the ACPI tables, which are then used for populating the Linux platform
> > devices (unless acpi=disabled is set), while the other contents of the
> > DTB may be present but we skip the of_platform_populate state.
> > 
> > If this is correct, then replacing the firmware-generated dtb with a
> > user-provided on would implicitly remove the ACPI tables from visibility,
> > which is exactly what we want.
> 
> That's not quite true.
> 
> There might not be any DTB, or the user might have provided a DTB with
> only /chosen/bootargs. Trying to distinguish the many cases of possible
> DTB is broken as a concept.
> 
> The EFI stub will attempt to get a DTB from somewhere (provided by
> filename or as a system table with a magic UUID), and if it can't find
> one will generate an empty stub DTB.
> 
> Then it will go and perform some EFI memory setup, placing some
> properties in the DTB (which might be a stub) describing the EFI memory
> map.
> 
> Then we boot the kernel proper, which sees the EFI pointers and looks
> for an ACPI table. If they are found, ACPI is used. Otherwise we attempt
> to use the DTB (which might be a stub).
> 
> Unless ACPI is explcitly disabled, ACPI will be used if present.

Ah, I saw this after I replied to Arnd's email.

The above sounds more like how I envisioned things working, so based on that,
the default just needs to be flipped and we should be fine (i.e. ACPI needs to
be explicitly enabled).


-Olof

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
> Hi Olof,
> 
> On Sun, Jul 27, 2014 at 03:34:48AM +0100, Olof Johansson wrote:
> > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > From: Graeme Gregory <graeme.gregory@linaro.org>
> > >
> > > Add documentation for the guidelines of how to use ACPI
> > > on ARM64.
> >
> > As the most vocal participant against ACPI being adopted, I would have
> > appreciated a cc on this patch set -- it's not like you were going for
> > a minimal set of cc recipients already. It makes it seem like you're
> > trying to sneak it past me for comments. Not cool. I know that's
> > probably not your intent, but still.
> >
> > Some comments below. Overall the doc looks pretty good, but the
> > details about _DSD and clocks are somewhat worrisome.
> >
> > > Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> > > Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> > > ---
> > >  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
> > >  1 file changed, 240 insertions(+)
> > >  create mode 100644 Documentation/arm64/arm-acpi.txt
> > >
> > > diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> > > new file mode 100644
> > > index 0000000..12cd550
> > > --- /dev/null
> > > +++ b/Documentation/arm64/arm-acpi.txt
> > > @@ -0,0 +1,240 @@
> > > +ACPI on ARMv8 Servers
> > > +---------------------
> > > +
> > > +ACPI will be used for ARMv8 general purpose servers designed to follow
> >
> > "ACPI might be used"    or     "can be used"
> >
> > > +the SBSA specification (currently available to people with an ARM login at
> > > +http://silver.arm.com)
> > > +
> > > +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> > > +which is available at <http://www.uefi.org/acpi/specs>.
> >
> > The implemented version where? The kernel implements that version?
> > Worth clarifying.
> >
> > > +If the machine does not meet these requirements then it is likely that Device
> > > +Tree (DT) is more suitable for the hardware.
> >
> > This is should be a very clear statement that is currently vague
> > w.r.t. which requirements are met or not, especially based on the
> > sentence above.
> >
> > > +Relationship with Device Tree
> > > +-----------------------------
> > > +
> > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > +exclusive with DT support at compile time.
> > > +
> > > +At boot time the kernel will only use one description method depending on
> > > +parameters passed from the bootloader.
> >
> > Possibly overriden by kernel bootargs. And as debated for quite a
> > while earlier this year, acpi should still default to off -- if a DT
> > and ACPI are both passed in, DT should at this time be given priority.
> 
> Why? I really don't see the logic in doing that.

Seems like I am replying to your emails in reverse order.

> Currently the kernel can only boot using DT, so DT will be used even if
> ACPI is present. In the presence of ACPI support in the kernel, ACPI
> would be used on said systems.

For all the reasons we hashed out earlier this year: We can't trust that
vendors will know how to do ACPI from day one, so instead of loading up the
kernel with lots of quirks and workarounds, we'll default to not using it until
we're at a point where things look mature enough.

The alternative is to keep this patch set out of the kernel. We can do that
too, but I don't think that really helps anyone.

> From the discussions at the last Linaro Connect, this was seen as
> important for virtual machines which want to provide ACPI services to
> guests while still being able to boot DT-only kernels. I'll leave it to
> Grant, Rob, and Christoffer to cover that.

Ok, waiting to see what they have to say then.

> > (Where can I learn more about how the boot loaders currently handle
> > this? Do some of them pass in both DT and ACPI on some platforms, for
> > example?)
> 
> All will pass in some form of DT. If booted through UEFI, the DT will be
> augmented with data about the UEFI memory map (and if no DT is provided,
> a /chosen only DT will eb created by the EFI stub).

The in-kernel EFI stub?

> A kernel with ACPI support will query EFI for ACPI tables, and if found
> use them.
> 
> > > +Regardless of whether DT or ACPI is used, the kernel must always be capable
> > > +of booting with either scheme.
> >
> > It should always be possible to compile out ACPI. There will be plenty
> > of platforms that will not implement it, so disabling CONFIG_ACPI
> > needs to be possible.
> 
> A better description would be that the two must never be mutually
> exclusive. It must always be possible to have a kernel which supports
> both, and code must never assume the absence of the other.

No. "Not mutually exclusive" and "possible to turn off one of them" is not the
same thing.

> At run time, the kernel will decide to use one for system description
> and use that.
> 
> [...]
> 
> > > +Device Enumeration
> > > +------------------
> > > +
> > > +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> > > +These are far simpler than the information provided via Device Tree. Drivers
> > > +should take into account this simplicity and work with sensible defaults.
> > > +
> > > +On no account should a Device Tree attempt to be replicated in ASL using such
> > > +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> > > +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> > > +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
> >
> > I see these two sentences as contradictory, given that the _DSD doc
> > linked below contains examples that mirror over several properties,
> > such as "linux,default-trigger" and other LED-specific properties.
> > (section 2.4.2 in the below doc). "default-state" seems to come from
> > DT too?
> 
> Urrgh. Those should never been placed in the ACPI spec. It's bad enough
> in DT.

+1

> > Care to elaborate and explain what the intention here is? This could
> > worst case turn into quite a mess.
> >
> > Given that ACPI can present completely different data based on what OS
> > is running, it's quite common to indeed have OS specific data in
> > there. How does that relate to this document and these practices?
> >
> > > +Common _DSD bindings should be submitted to ASWG to be included in the
> > > +document :-
> > > +
> > > +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
> >
> > So, for these that are a mirror of the device tree bindings, there
> > needs to be a wording here around reviewing the DT binding first so we
> > don't get diverging bindings.
> 
> We shouldn't work on the assumption that the two should be identical.
> ACPI already has standard mechanisms for describing certain linkages
> that are divergent from DT.

I can't tell what is worse, identical mirroring over into DT of FDT (and the
lack of being able to fix it up in case of description bugs) or _DSD doing
things subtly different and now the kernel needs to handle both variants.

> This really needs higher-level thought, and I'd hoped that things
> wouldn't blindly be copied one way or the other.

Agreed. Besides, the whole idea of ACPI is to not have to model clocks. Sigh.

> [...]
> 
> > > +values before the kernel is executed. If a driver requires to know rates of
> > > +clocks set by firmware then they can be passed to kernel using _DSD.
> > > +
> > > +example :-
> > > +
> > > +Device (CLK0) {
> > > +       ...
> > > +
> > > +       Name (_DSD, Package() {
> > > +               ToUUID("XXXXX"),
> > > +               Package() {
> > > +                       Package(2) {"#clock-cells", 0},
> >
> > Clock-cells? What do they mean here? Is this specified in the ACPI
> > standards? I had to register to get access to it, and didn't feel like
> > doing that right now. I guess it's not _all_ that open a spec. :(
> 
> Yeah, this is complete nonsense.
> 
> If people are going to blindly copy elements from DT into ACPI without
> actually understanding them, then ACPI is clearly no better than DT.
> 
> [...]
> 
> > > +static int device_probe(stuct platform_device *pdev)
> > > +{
> > > +       ...
> > > +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
> > > +       struct device_node node = pdev->dev.of_node;
> > > +       ...
> > > +
> > > +       if (node)
> > > +               ret = device_probe_dt(pdev);
> > > +       else if (handle)
> > > +               ret = device_probe_acpi(pdev);
> > > +       else
> > > +               /* other initialisation */
> > > +               ...
> > > +       /* Continue with any generic probe operations */
> > > +       ...
> > > +}
> >
> > This looks good to me, and it's also my preferred way of ACPI-enabling
> > drivers. I guess we might discuss this at KS since it was a proposed
> > topic there, and others will object. :)
> 
> This is almost precisely the form of probe I want to see (it would be
> nicer IMO to have separate entry points for ACPI / DT / platform data
> that can all call a common probe core, but this isn't too far off).

I disagree, but it's also not something we're looking to change at this time.
We'll take that debate when you post the patches changing how device probing
works. :-)

> > > +
> > > +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
> > > +the different names the driver is probed for, both from DT and from ACPI.
> > > +
> > > +module device tables :-
> > > +
> > > +static struct of_device_id virtio_mmio_match[] = {
> > > +        { .compatible = "virtio,mmio", },
> > > +        {},
> > > +};
> > > +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
> > > +
> > > +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
> > > +        { "LNRO0005", },
> > > +        { }
> >
> > No comma here, but a comma on DT. Probably make them equivalent for
> > consistency (including space between the braces).
> 
> The comma on the DT form should probably be dropped. The NULL sentinel's
> only job is to delimit the list, so it never makes sense to place
> something after it.

Yep.


-Olof

[PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
> Hi Olof,
> 
> On Sun, Jul 27, 2014 at 03:34:48AM +0100, Olof Johansson wrote:
> > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > From: Graeme Gregory <graeme.gregory@linaro.org>
> > >
> > > Add documentation for the guidelines of how to use ACPI
> > > on ARM64.
> >
> > As the most vocal participant against ACPI being adopted, I would have
> > appreciated a cc on this patch set -- it's not like you were going for
> > a minimal set of cc recipients already. It makes it seem like you're
> > trying to sneak it past me for comments. Not cool. I know that's
> > probably not your intent, but still.
> >
> > Some comments below. Overall the doc looks pretty good, but the
> > details about _DSD and clocks are somewhat worrisome.
> >
> > > Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> > > Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> > > ---
> > >  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
> > >  1 file changed, 240 insertions(+)
> > >  create mode 100644 Documentation/arm64/arm-acpi.txt
> > >
> > > diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> > > new file mode 100644
> > > index 0000000..12cd550
> > > --- /dev/null
> > > +++ b/Documentation/arm64/arm-acpi.txt
> > > @@ -0,0 +1,240 @@
> > > +ACPI on ARMv8 Servers
> > > +---------------------
> > > +
> > > +ACPI will be used for ARMv8 general purpose servers designed to follow
> >
> > "ACPI might be used"    or     "can be used"
> >
> > > +the SBSA specification (currently available to people with an ARM login at
> > > +http://silver.arm.com)
> > > +
> > > +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> > > +which is available at <http://www.uefi.org/acpi/specs>.
> >
> > The implemented version where? The kernel implements that version?
> > Worth clarifying.
> >
> > > +If the machine does not meet these requirements then it is likely that Device
> > > +Tree (DT) is more suitable for the hardware.
> >
> > This is should be a very clear statement that is currently vague
> > w.r.t. which requirements are met or not, especially based on the
> > sentence above.
> >
> > > +Relationship with Device Tree
> > > +-----------------------------
> > > +
> > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > +exclusive with DT support at compile time.
> > > +
> > > +At boot time the kernel will only use one description method depending on
> > > +parameters passed from the bootloader.
> >
> > Possibly overriden by kernel bootargs. And as debated for quite a
> > while earlier this year, acpi should still default to off -- if a DT
> > and ACPI are both passed in, DT should at this time be given priority.
> 
> Why? I really don't see the logic in doing that.

Seems like I am replying to your emails in reverse order.

> Currently the kernel can only boot using DT, so DT will be used even if
> ACPI is present. In the presence of ACPI support in the kernel, ACPI
> would be used on said systems.

For all the reasons we hashed out earlier this year: We can't trust that
vendors will know how to do ACPI from day one, so instead of loading up the
kernel with lots of quirks and workarounds, we'll default to not using it until
we're at a point where things look mature enough.

The alternative is to keep this patch set out of the kernel. We can do that
too, but I don't think that really helps anyone.

> From the discussions at the last Linaro Connect, this was seen as
> important for virtual machines which want to provide ACPI services to
> guests while still being able to boot DT-only kernels. I'll leave it to
> Grant, Rob, and Christoffer to cover that.

Ok, waiting to see what they have to say then.

> > (Where can I learn more about how the boot loaders currently handle
> > this? Do some of them pass in both DT and ACPI on some platforms, for
> > example?)
> 
> All will pass in some form of DT. If booted through UEFI, the DT will be
> augmented with data about the UEFI memory map (and if no DT is provided,
> a /chosen only DT will eb created by the EFI stub).

The in-kernel EFI stub?

> A kernel with ACPI support will query EFI for ACPI tables, and if found
> use them.
> 
> > > +Regardless of whether DT or ACPI is used, the kernel must always be capable
> > > +of booting with either scheme.
> >
> > It should always be possible to compile out ACPI. There will be plenty
> > of platforms that will not implement it, so disabling CONFIG_ACPI
> > needs to be possible.
> 
> A better description would be that the two must never be mutually
> exclusive. It must always be possible to have a kernel which supports
> both, and code must never assume the absence of the other.

No. "Not mutually exclusive" and "possible to turn off one of them" is not the
same thing.

> At run time, the kernel will decide to use one for system description
> and use that.
> 
> [...]
> 
> > > +Device Enumeration
> > > +------------------
> > > +
> > > +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> > > +These are far simpler than the information provided via Device Tree. Drivers
> > > +should take into account this simplicity and work with sensible defaults.
> > > +
> > > +On no account should a Device Tree attempt to be replicated in ASL using such
> > > +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> > > +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> > > +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
> >
> > I see these two sentences as contradictory, given that the _DSD doc
> > linked below contains examples that mirror over several properties,
> > such as "linux,default-trigger" and other LED-specific properties.
> > (section 2.4.2 in the below doc). "default-state" seems to come from
> > DT too?
> 
> Urrgh. Those should never been placed in the ACPI spec. It's bad enough
> in DT.

+1

> > Care to elaborate and explain what the intention here is? This could
> > worst case turn into quite a mess.
> >
> > Given that ACPI can present completely different data based on what OS
> > is running, it's quite common to indeed have OS specific data in
> > there. How does that relate to this document and these practices?
> >
> > > +Common _DSD bindings should be submitted to ASWG to be included in the
> > > +document :-
> > > +
> > > +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
> >
> > So, for these that are a mirror of the device tree bindings, there
> > needs to be a wording here around reviewing the DT binding first so we
> > don't get diverging bindings.
> 
> We shouldn't work on the assumption that the two should be identical.
> ACPI already has standard mechanisms for describing certain linkages
> that are divergent from DT.

I can't tell what is worse, identical mirroring over into DT of FDT (and the
lack of being able to fix it up in case of description bugs) or _DSD doing
things subtly different and now the kernel needs to handle both variants.

> This really needs higher-level thought, and I'd hoped that things
> wouldn't blindly be copied one way or the other.

Agreed. Besides, the whole idea of ACPI is to not have to model clocks. Sigh.

> [...]
> 
> > > +values before the kernel is executed. If a driver requires to know rates of
> > > +clocks set by firmware then they can be passed to kernel using _DSD.
> > > +
> > > +example :-
> > > +
> > > +Device (CLK0) {
> > > +       ...
> > > +
> > > +       Name (_DSD, Package() {
> > > +               ToUUID("XXXXX"),
> > > +               Package() {
> > > +                       Package(2) {"#clock-cells", 0},
> >
> > Clock-cells? What do they mean here? Is this specified in the ACPI
> > standards? I had to register to get access to it, and didn't feel like
> > doing that right now. I guess it's not _all_ that open a spec. :(
> 
> Yeah, this is complete nonsense.
> 
> If people are going to blindly copy elements from DT into ACPI without
> actually understanding them, then ACPI is clearly no better than DT.
> 
> [...]
> 
> > > +static int device_probe(stuct platform_device *pdev)
> > > +{
> > > +       ...
> > > +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
> > > +       struct device_node node = pdev->dev.of_node;
> > > +       ...
> > > +
> > > +       if (node)
> > > +               ret = device_probe_dt(pdev);
> > > +       else if (handle)
> > > +               ret = device_probe_acpi(pdev);
> > > +       else
> > > +               /* other initialisation */
> > > +               ...
> > > +       /* Continue with any generic probe operations */
> > > +       ...
> > > +}
> >
> > This looks good to me, and it's also my preferred way of ACPI-enabling
> > drivers. I guess we might discuss this at KS since it was a proposed
> > topic there, and others will object. :)
> 
> This is almost precisely the form of probe I want to see (it would be
> nicer IMO to have separate entry points for ACPI / DT / platform data
> that can all call a common probe core, but this isn't too far off).

I disagree, but it's also not something we're looking to change at this time.
We'll take that debate when you post the patches changing how device probing
works. :-)

> > > +
> > > +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
> > > +the different names the driver is probed for, both from DT and from ACPI.
> > > +
> > > +module device tables :-
> > > +
> > > +static struct of_device_id virtio_mmio_match[] = {
> > > +        { .compatible = "virtio,mmio", },
> > > +        {},
> > > +};
> > > +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
> > > +
> > > +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
> > > +        { "LNRO0005", },
> > > +        { }
> >
> > No comma here, but a comma on DT. Probably make them equivalent for
> > consistency (including space between the braces).
> 
> The comma on the DT form should probably be dropped. The NULL sentinel's
> only job is to delimit the list, so it never makes sense to place
> something after it.

Yep.


-Olof

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Mon, Jul 28, 2014 at 05:27:50PM +0100, Olof Johansson wrote:
> On Mon, Jul 28, 2014 at 11:07:50AM +0200, Arnd Bergmann wrote:
> > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > > +Relationship with Device Tree
> > > > +-----------------------------
> > > > +
> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > > +exclusive with DT support at compile time.
> > > > +
> > > > +At boot time the kernel will only use one description method depending on
> > > > +parameters passed from the bootloader.
> > > 
> > > Possibly overriden by kernel bootargs. And as debated for quite a
> > > while earlier this year, acpi should still default to off -- if a DT
> > > and ACPI are both passed in, DT should at this time be given priority.
> > 
> > I think this would be harder to do with the way that ACPI is passed in
> > to the kernel. IIRC, you always have a minimal DT information based on
> > the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> > to the ACPI tables, which are then used for populating the Linux platform
> > devices (unless acpi=disabled is set), while the other contents of the
> > DTB may be present but we skip the of_platform_populate state.
> 
> How can it be harder to do? If you support acpi=off, then you should support
> acpi=on.
> 
> Another alternative would be to have an early fixup that stubs out
> the acpi properties from the DTB unless there's an 'acpi' or 'acpi=on'
> argument on the cmdline. Not quite as tidy a solution, though.

I don't follow:

If you want to disable ACPI, you can pass acpi=off. This is your
workaround for broken ACPI (and only if you happen to have wrirten your
own DTB, because many/most ACPI systems WILL NOT have a DTB to begin
with).

If you have ACPI, for what technical reason would you not attempt to use
it by default?

There will be systems which _DO NOT_ have any sort of DTB to begin with.
For VMs, both may be provided. By the necessity of a DTB being present
for bootargs, ACPI _MUST_ take precedence. If you don't want it, you
pass acpi=off, or configure your VM software to not pass an ACPI
configuration table.

Why avoid ACPI by default? So that we can later enable it and discover
it's completely broken? Then we need short-sighted hacks to work around
short-sighted decisions.

The best thing to do is to try and use things, be as strict as possible,
stress the implementation, and blow up early and loudly so that said
systems must be fixed.

People are using Linux for bringup; it is the closest thing to a
validation suite. Being lazy and hacking around things for now will only
make things worse in the long run.

We _CANNOT_ place our fingers in our ears and blind ourselves with the
DT banner. ACPI is ugly, sure, but so is DT. Neither is fundamentally
better than the other. The best thing we can do is make it as easy as
possible to highlight bugs in ACPI implementations and barf such that
people are forced to fix their ACPI implementations.

No other OS supports ACPI on 64-bit arm systems. Being strict should
force implementors to try harder.

> > If this is correct, then replacing the firmware-generated dtb with a
> > user-provided on would implicitly remove the ACPI tables from visibility,
> > which is exactly what we want.
> 
> I was of the impression that firmware patches in the ACPI entries into either
> device-tree before launching the kernel. Is that not the case?

1) The ACPI tables will be registered as UEFI configuration tables,
   within platform-specific UEFI code. Nothing outside of UEFI is
   involved.

1a) A loader (e.g. GRUB, the EFI stub) COULD override the loaded tables.
   This is a workaround, and should never be the standard way of doing
   things. It defeats the point, much like appended DTB.

2) The EFI stub will patch UEFI memory map properties into the DTB. The
   firmware is not involved.

3) The kernel will detect whether EFI is present by the presence of the
   memory map, and try to use it if so. The memory map comes from UEFI,
   and memory nodes (and memreserves) are ignored. Only select
   properties under /chosen (e.g. bootargs) will be used.

4) If booted via EFI, the kernel will look for known UEFI configuration
   tables by (G|U)UID, and set up some pointers.

5) The ACPI code will go and look to see if the ACPI table pointers have
   been initialised. If so, the kernel will attempt to use the ACPI
   tables unlesss instructed otherwise. If using ACPI, the DTB will be
   ignored outside of /chosen.

The ACPI tables or pointers to them are not directly patched into the
DTB at any stage. The choice of using ACPI is left with the kernel.

> And what if some bootloader chooses to do it that way in the future?
> It's better to not assume that they get it right.

For the firmware/loader to do so it would have to work around the kernel
version parameter the stub places in the DTB and the kernel verifies. If
it does so, I would argue said firmware is actively malicious.

> > It's possible that I'm misremembering it though, and it should be
> > documented better.
> 
> Yes, definitely needs to be documented to not leave room for random
> interpretation later on.

We should definitely make the documentation as strict as possible on
what's allowed, and have the kernel barf early on if requirements are
not met.

Thanks,
Mark.

[PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Mon, Jul 28, 2014 at 05:27:50PM +0100, Olof Johansson wrote:
> On Mon, Jul 28, 2014 at 11:07:50AM +0200, Arnd Bergmann wrote:
> > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > > +Relationship with Device Tree
> > > > +-----------------------------
> > > > +
> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > > +exclusive with DT support at compile time.
> > > > +
> > > > +At boot time the kernel will only use one description method depending on
> > > > +parameters passed from the bootloader.
> > > 
> > > Possibly overriden by kernel bootargs. And as debated for quite a
> > > while earlier this year, acpi should still default to off -- if a DT
> > > and ACPI are both passed in, DT should at this time be given priority.
> > 
> > I think this would be harder to do with the way that ACPI is passed in
> > to the kernel. IIRC, you always have a minimal DT information based on
> > the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> > to the ACPI tables, which are then used for populating the Linux platform
> > devices (unless acpi=disabled is set), while the other contents of the
> > DTB may be present but we skip the of_platform_populate state.
> 
> How can it be harder to do? If you support acpi=off, then you should support
> acpi=on.
> 
> Another alternative would be to have an early fixup that stubs out
> the acpi properties from the DTB unless there's an 'acpi' or 'acpi=on'
> argument on the cmdline. Not quite as tidy a solution, though.

I don't follow:

If you want to disable ACPI, you can pass acpi=off. This is your
workaround for broken ACPI (and only if you happen to have wrirten your
own DTB, because many/most ACPI systems WILL NOT have a DTB to begin
with).

If you have ACPI, for what technical reason would you not attempt to use
it by default?

There will be systems which _DO NOT_ have any sort of DTB to begin with.
For VMs, both may be provided. By the necessity of a DTB being present
for bootargs, ACPI _MUST_ take precedence. If you don't want it, you
pass acpi=off, or configure your VM software to not pass an ACPI
configuration table.

Why avoid ACPI by default? So that we can later enable it and discover
it's completely broken? Then we need short-sighted hacks to work around
short-sighted decisions.

The best thing to do is to try and use things, be as strict as possible,
stress the implementation, and blow up early and loudly so that said
systems must be fixed.

People are using Linux for bringup; it is the closest thing to a
validation suite. Being lazy and hacking around things for now will only
make things worse in the long run.

We _CANNOT_ place our fingers in our ears and blind ourselves with the
DT banner. ACPI is ugly, sure, but so is DT. Neither is fundamentally
better than the other. The best thing we can do is make it as easy as
possible to highlight bugs in ACPI implementations and barf such that
people are forced to fix their ACPI implementations.

No other OS supports ACPI on 64-bit arm systems. Being strict should
force implementors to try harder.

> > If this is correct, then replacing the firmware-generated dtb with a
> > user-provided on would implicitly remove the ACPI tables from visibility,
> > which is exactly what we want.
> 
> I was of the impression that firmware patches in the ACPI entries into either
> device-tree before launching the kernel. Is that not the case?

1) The ACPI tables will be registered as UEFI configuration tables,
   within platform-specific UEFI code. Nothing outside of UEFI is
   involved.

1a) A loader (e.g. GRUB, the EFI stub) COULD override the loaded tables.
   This is a workaround, and should never be the standard way of doing
   things. It defeats the point, much like appended DTB.

2) The EFI stub will patch UEFI memory map properties into the DTB. The
   firmware is not involved.

3) The kernel will detect whether EFI is present by the presence of the
   memory map, and try to use it if so. The memory map comes from UEFI,
   and memory nodes (and memreserves) are ignored. Only select
   properties under /chosen (e.g. bootargs) will be used.

4) If booted via EFI, the kernel will look for known UEFI configuration
   tables by (G|U)UID, and set up some pointers.

5) The ACPI code will go and look to see if the ACPI table pointers have
   been initialised. If so, the kernel will attempt to use the ACPI
   tables unlesss instructed otherwise. If using ACPI, the DTB will be
   ignored outside of /chosen.

The ACPI tables or pointers to them are not directly patched into the
DTB at any stage. The choice of using ACPI is left with the kernel.

> And what if some bootloader chooses to do it that way in the future?
> It's better to not assume that they get it right.

For the firmware/loader to do so it would have to work around the kernel
version parameter the stub places in the DTB and the kernel verifies. If
it does so, I would argue said firmware is actively malicious.

> > It's possible that I'm misremembering it though, and it should be
> > documented better.
> 
> Yes, definitely needs to be documented to not leave room for random
> interpretation later on.

We should definitely make the documentation as strict as possible on
what's allowed, and have the kernel barf early on if requirements are
not met.

Thanks,
Mark.

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Mon, Jul 28, 2014 at 05:44:59PM +0100, Olof Johansson wrote:
> On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
> > Hi Olof,
> >
> > On Sun, Jul 27, 2014 at 03:34:48AM +0100, Olof Johansson wrote:
> > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > > From: Graeme Gregory <graeme.gregory@linaro.org>
> > > >
> > > > Add documentation for the guidelines of how to use ACPI
> > > > on ARM64.
> > >
> > > As the most vocal participant against ACPI being adopted, I would have
> > > appreciated a cc on this patch set -- it's not like you were going for
> > > a minimal set of cc recipients already. It makes it seem like you're
> > > trying to sneak it past me for comments. Not cool. I know that's
> > > probably not your intent, but still.
> > >
> > > Some comments below. Overall the doc looks pretty good, but the
> > > details about _DSD and clocks are somewhat worrisome.
> > >
> > > > Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> > > > Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> > > > ---
> > > >  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 240 insertions(+)
> > > >  create mode 100644 Documentation/arm64/arm-acpi.txt
> > > >
> > > > diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> > > > new file mode 100644
> > > > index 0000000..12cd550
> > > > --- /dev/null
> > > > +++ b/Documentation/arm64/arm-acpi.txt
> > > > @@ -0,0 +1,240 @@
> > > > +ACPI on ARMv8 Servers
> > > > +---------------------
> > > > +
> > > > +ACPI will be used for ARMv8 general purpose servers designed to follow
> > >
> > > "ACPI might be used"    or     "can be used"
> > >
> > > > +the SBSA specification (currently available to people with an ARM login at
> > > > +http://silver.arm.com)
> > > > +
> > > > +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> > > > +which is available at <http://www.uefi.org/acpi/specs>.
> > >
> > > The implemented version where? The kernel implements that version?
> > > Worth clarifying.
> > >
> > > > +If the machine does not meet these requirements then it is likely that Device
> > > > +Tree (DT) is more suitable for the hardware.
> > >
> > > This is should be a very clear statement that is currently vague
> > > w.r.t. which requirements are met or not, especially based on the
> > > sentence above.
> > >
> > > > +Relationship with Device Tree
> > > > +-----------------------------
> > > > +
> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > > +exclusive with DT support at compile time.
> > > > +
> > > > +At boot time the kernel will only use one description method depending on
> > > > +parameters passed from the bootloader.
> > >
> > > Possibly overriden by kernel bootargs. And as debated for quite a
> > > while earlier this year, acpi should still default to off -- if a DT
> > > and ACPI are both passed in, DT should at this time be given priority.
> >
> > Why? I really don't see the logic in doing that.
> 
> Seems like I am replying to your emails in reverse order.

Oh well; it makes the discussion more fun to read :)

> > Currently the kernel can only boot using DT, so DT will be used even if
> > ACPI is present. In the presence of ACPI support in the kernel, ACPI
> > would be used on said systems.
> 
> For all the reasons we hashed out earlier this year: We can't trust that
> vendors will know how to do ACPI from day one, so instead of loading up the
> kernel with lots of quirks and workarounds, we'll default to not using it until
> we're at a point where things look mature enough.

I am not arguing for quirks and workarounds.

What I would like to see is for the kernel barf horrifically right now
on even slightly dodgy ACPI implementations before they are out in the
wild. Otherwise the later switching on of ACPI support is what will
necessitate workarounds for said systems.

> The alternative is to keep this patch set out of the kernel. We can do that
> too, but I don't think that really helps anyone.

That's just another way of disabling it by default. IMO that's worse
because only a subset of people will discover how broken their ACPI
implementation is.

> > From the discussions at the last Linaro Connect, this was seen as
> > important for virtual machines which want to provide ACPI services to
> > guests while still being able to boot DT-only kernels. I'll leave it to
> > Grant, Rob, and Christoffer to cover that.
> 
> Ok, waiting to see what they have to say then.
> 
> > > (Where can I learn more about how the boot loaders currently handle
> > > this? Do some of them pass in both DT and ACPI on some platforms, for
> > > example?)
> >
> > All will pass in some form of DT. If booted through UEFI, the DT will be
> > augmented with data about the UEFI memory map (and if no DT is provided,
> > a /chosen only DT will eb created by the EFI stub).
> 
> The in-kernel EFI stub?

Yes. If a kernel with the stub is booted as an EFI application, the stub
code will be executed and augment / create a DTB with handles for the
UEFI memory map.

There is a tight coupling between the stub and the kernel. Only the stub
is able to do this currently.

> > A kernel with ACPI support will query EFI for ACPI tables, and if found
> > use them.
> >
> > > > +Regardless of whether DT or ACPI is used, the kernel must always be capable
> > > > +of booting with either scheme.
> > >
> > > It should always be possible to compile out ACPI. There will be plenty
> > > of platforms that will not implement it, so disabling CONFIG_ACPI
> > > needs to be possible.
> >
> > A better description would be that the two must never be mutually
> > exclusive. It must always be possible to have a kernel which supports
> > both, and code must never assume the absence of the other.
> 
> No. "Not mutually exclusive" and "possible to turn off one of them" is not the
> same thing.

I think we're talking cross purposes. Those sentences are indeed not
equivalent. We want two things:

1) A single kernel image must be able to support both ACPI and DT.

2) It must be possible to build a kernel supporting only DT.

Of the two (1) is the most important, or single image is dead. That does
not mean that (2) is not important, but it is an optimisation to remove
unused code and save on size.

Any wording we have here must express both these points.

> > At run time, the kernel will decide to use one for system description
> > and use that.
> >
> > [...]
> >
> > > > +Device Enumeration
> > > > +------------------
> > > > +
> > > > +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> > > > +These are far simpler than the information provided via Device Tree. Drivers
> > > > +should take into account this simplicity and work with sensible defaults.
> > > > +
> > > > +On no account should a Device Tree attempt to be replicated in ASL using such
> > > > +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> > > > +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> > > > +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
> > >
> > > I see these two sentences as contradictory, given that the _DSD doc
> > > linked below contains examples that mirror over several properties,
> > > such as "linux,default-trigger" and other LED-specific properties.
> > > (section 2.4.2 in the below doc). "default-state" seems to come from
> > > DT too?
> >
> > Urrgh. Those should never been placed in the ACPI spec. It's bad enough
> > in DT.
> 
> +1
> 
> > > Care to elaborate and explain what the intention here is? This could
> > > worst case turn into quite a mess.
> > >
> > > Given that ACPI can present completely different data based on what OS
> > > is running, it's quite common to indeed have OS specific data in
> > > there. How does that relate to this document and these practices?
> > >
> > > > +Common _DSD bindings should be submitted to ASWG to be included in the
> > > > +document :-
> > > > +
> > > > +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
> > >
> > > So, for these that are a mirror of the device tree bindings, there
> > > needs to be a wording here around reviewing the DT binding first so we
> > > don't get diverging bindings.
> >
> > We shouldn't work on the assumption that the two should be identical.
> > ACPI already has standard mechanisms for describing certain linkages
> > that are divergent from DT.
> 
> I can't tell what is worse, identical mirroring over into DT of FDT (and the
> lack of being able to fix it up in case of description bugs) or _DSD doing
> things subtly different and now the kernel needs to handle both variants.

ACPI and DT are already doing different things. It's fine to do the same
thing where it makes sense to, but we shouldn't go for a false
equivalence here.

> > This really needs higher-level thought, and I'd hoped that things
> > wouldn't blindly be copied one way or the other.
> 
> Agreed. Besides, the whole idea of ACPI is to not have to model clocks. Sigh.

Well, maybe not the _whole_ idea. I hear ACPI actually tries to model
other devices...

> > [...]
> >
> > > > +values before the kernel is executed. If a driver requires to know rates of
> > > > +clocks set by firmware then they can be passed to kernel using _DSD.
> > > > +
> > > > +example :-
> > > > +
> > > > +Device (CLK0) {
> > > > +       ...
> > > > +
> > > > +       Name (_DSD, Package() {
> > > > +               ToUUID("XXXXX"),
> > > > +               Package() {
> > > > +                       Package(2) {"#clock-cells", 0},
> > >
> > > Clock-cells? What do they mean here? Is this specified in the ACPI
> > > standards? I had to register to get access to it, and didn't feel like
> > > doing that right now. I guess it's not _all_ that open a spec. :(
> >
> > Yeah, this is complete nonsense.
> >
> > If people are going to blindly copy elements from DT into ACPI without
> > actually understanding them, then ACPI is clearly no better than DT.
> >
> > [...]
> >
> > > > +static int device_probe(stuct platform_device *pdev)
> > > > +{
> > > > +       ...
> > > > +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
> > > > +       struct device_node node = pdev->dev.of_node;
> > > > +       ...
> > > > +
> > > > +       if (node)
> > > > +               ret = device_probe_dt(pdev);
> > > > +       else if (handle)
> > > > +               ret = device_probe_acpi(pdev);
> > > > +       else
> > > > +               /* other initialisation */
> > > > +               ...
> > > > +       /* Continue with any generic probe operations */
> > > > +       ...
> > > > +}
> > >
> > > This looks good to me, and it's also my preferred way of ACPI-enabling
> > > drivers. I guess we might discuss this at KS since it was a proposed
> > > topic there, and others will object. :)
> >
> > This is almost precisely the form of probe I want to see (it would be
> > nicer IMO to have separate entry points for ACPI / DT / platform data
> > that can all call a common probe core, but this isn't too far off).
> 
> I disagree, but it's also not something we're looking to change at this time.
> We'll take that debate when you post the patches changing how device probing
> works. :-)

Sure :)

Cheers,
Mark.
 
> > > > +
> > > > +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
> > > > +the different names the driver is probed for, both from DT and from ACPI.
> > > > +
> > > > +module device tables :-
> > > > +
> > > > +static struct of_device_id virtio_mmio_match[] = {
> > > > +        { .compatible = "virtio,mmio", },
> > > > +        {},
> > > > +};
> > > > +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
> > > > +
> > > > +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
> > > > +        { "LNRO0005", },
> > > > +        { }
> > >
> > > No comma here, but a comma on DT. Probably make them equivalent for
> > > consistency (including space between the braces).
> >
> > The comma on the DT form should probably be dropped. The NULL sentinel's
> > only job is to delimit the list, so it never makes sense to place
> > something after it.
> 
> Yep.
> 
> 
> -Olof
> 

[PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Mon, Jul 28, 2014 at 05:44:59PM +0100, Olof Johansson wrote:
> On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
> > Hi Olof,
> >
> > On Sun, Jul 27, 2014 at 03:34:48AM +0100, Olof Johansson wrote:
> > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > > From: Graeme Gregory <graeme.gregory@linaro.org>
> > > >
> > > > Add documentation for the guidelines of how to use ACPI
> > > > on ARM64.
> > >
> > > As the most vocal participant against ACPI being adopted, I would have
> > > appreciated a cc on this patch set -- it's not like you were going for
> > > a minimal set of cc recipients already. It makes it seem like you're
> > > trying to sneak it past me for comments. Not cool. I know that's
> > > probably not your intent, but still.
> > >
> > > Some comments below. Overall the doc looks pretty good, but the
> > > details about _DSD and clocks are somewhat worrisome.
> > >
> > > > Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> > > > Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> > > > ---
> > > >  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 240 insertions(+)
> > > >  create mode 100644 Documentation/arm64/arm-acpi.txt
> > > >
> > > > diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> > > > new file mode 100644
> > > > index 0000000..12cd550
> > > > --- /dev/null
> > > > +++ b/Documentation/arm64/arm-acpi.txt
> > > > @@ -0,0 +1,240 @@
> > > > +ACPI on ARMv8 Servers
> > > > +---------------------
> > > > +
> > > > +ACPI will be used for ARMv8 general purpose servers designed to follow
> > >
> > > "ACPI might be used"    or     "can be used"
> > >
> > > > +the SBSA specification (currently available to people with an ARM login at
> > > > +http://silver.arm.com)
> > > > +
> > > > +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> > > > +which is available at <http://www.uefi.org/acpi/specs>.
> > >
> > > The implemented version where? The kernel implements that version?
> > > Worth clarifying.
> > >
> > > > +If the machine does not meet these requirements then it is likely that Device
> > > > +Tree (DT) is more suitable for the hardware.
> > >
> > > This is should be a very clear statement that is currently vague
> > > w.r.t. which requirements are met or not, especially based on the
> > > sentence above.
> > >
> > > > +Relationship with Device Tree
> > > > +-----------------------------
> > > > +
> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > > +exclusive with DT support at compile time.
> > > > +
> > > > +At boot time the kernel will only use one description method depending on
> > > > +parameters passed from the bootloader.
> > >
> > > Possibly overriden by kernel bootargs. And as debated for quite a
> > > while earlier this year, acpi should still default to off -- if a DT
> > > and ACPI are both passed in, DT should at this time be given priority.
> >
> > Why? I really don't see the logic in doing that.
> 
> Seems like I am replying to your emails in reverse order.

Oh well; it makes the discussion more fun to read :)

> > Currently the kernel can only boot using DT, so DT will be used even if
> > ACPI is present. In the presence of ACPI support in the kernel, ACPI
> > would be used on said systems.
> 
> For all the reasons we hashed out earlier this year: We can't trust that
> vendors will know how to do ACPI from day one, so instead of loading up the
> kernel with lots of quirks and workarounds, we'll default to not using it until
> we're at a point where things look mature enough.

I am not arguing for quirks and workarounds.

What I would like to see is for the kernel barf horrifically right now
on even slightly dodgy ACPI implementations before they are out in the
wild. Otherwise the later switching on of ACPI support is what will
necessitate workarounds for said systems.

> The alternative is to keep this patch set out of the kernel. We can do that
> too, but I don't think that really helps anyone.

That's just another way of disabling it by default. IMO that's worse
because only a subset of people will discover how broken their ACPI
implementation is.

> > From the discussions at the last Linaro Connect, this was seen as
> > important for virtual machines which want to provide ACPI services to
> > guests while still being able to boot DT-only kernels. I'll leave it to
> > Grant, Rob, and Christoffer to cover that.
> 
> Ok, waiting to see what they have to say then.
> 
> > > (Where can I learn more about how the boot loaders currently handle
> > > this? Do some of them pass in both DT and ACPI on some platforms, for
> > > example?)
> >
> > All will pass in some form of DT. If booted through UEFI, the DT will be
> > augmented with data about the UEFI memory map (and if no DT is provided,
> > a /chosen only DT will eb created by the EFI stub).
> 
> The in-kernel EFI stub?

Yes. If a kernel with the stub is booted as an EFI application, the stub
code will be executed and augment / create a DTB with handles for the
UEFI memory map.

There is a tight coupling between the stub and the kernel. Only the stub
is able to do this currently.

> > A kernel with ACPI support will query EFI for ACPI tables, and if found
> > use them.
> >
> > > > +Regardless of whether DT or ACPI is used, the kernel must always be capable
> > > > +of booting with either scheme.
> > >
> > > It should always be possible to compile out ACPI. There will be plenty
> > > of platforms that will not implement it, so disabling CONFIG_ACPI
> > > needs to be possible.
> >
> > A better description would be that the two must never be mutually
> > exclusive. It must always be possible to have a kernel which supports
> > both, and code must never assume the absence of the other.
> 
> No. "Not mutually exclusive" and "possible to turn off one of them" is not the
> same thing.

I think we're talking cross purposes. Those sentences are indeed not
equivalent. We want two things:

1) A single kernel image must be able to support both ACPI and DT.

2) It must be possible to build a kernel supporting only DT.

Of the two (1) is the most important, or single image is dead. That does
not mean that (2) is not important, but it is an optimisation to remove
unused code and save on size.

Any wording we have here must express both these points.

> > At run time, the kernel will decide to use one for system description
> > and use that.
> >
> > [...]
> >
> > > > +Device Enumeration
> > > > +------------------
> > > > +
> > > > +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> > > > +These are far simpler than the information provided via Device Tree. Drivers
> > > > +should take into account this simplicity and work with sensible defaults.
> > > > +
> > > > +On no account should a Device Tree attempt to be replicated in ASL using such
> > > > +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> > > > +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> > > > +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
> > >
> > > I see these two sentences as contradictory, given that the _DSD doc
> > > linked below contains examples that mirror over several properties,
> > > such as "linux,default-trigger" and other LED-specific properties.
> > > (section 2.4.2 in the below doc). "default-state" seems to come from
> > > DT too?
> >
> > Urrgh. Those should never been placed in the ACPI spec. It's bad enough
> > in DT.
> 
> +1
> 
> > > Care to elaborate and explain what the intention here is? This could
> > > worst case turn into quite a mess.
> > >
> > > Given that ACPI can present completely different data based on what OS
> > > is running, it's quite common to indeed have OS specific data in
> > > there. How does that relate to this document and these practices?
> > >
> > > > +Common _DSD bindings should be submitted to ASWG to be included in the
> > > > +document :-
> > > > +
> > > > +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
> > >
> > > So, for these that are a mirror of the device tree bindings, there
> > > needs to be a wording here around reviewing the DT binding first so we
> > > don't get diverging bindings.
> >
> > We shouldn't work on the assumption that the two should be identical.
> > ACPI already has standard mechanisms for describing certain linkages
> > that are divergent from DT.
> 
> I can't tell what is worse, identical mirroring over into DT of FDT (and the
> lack of being able to fix it up in case of description bugs) or _DSD doing
> things subtly different and now the kernel needs to handle both variants.

ACPI and DT are already doing different things. It's fine to do the same
thing where it makes sense to, but we shouldn't go for a false
equivalence here.

> > This really needs higher-level thought, and I'd hoped that things
> > wouldn't blindly be copied one way or the other.
> 
> Agreed. Besides, the whole idea of ACPI is to not have to model clocks. Sigh.

Well, maybe not the _whole_ idea. I hear ACPI actually tries to model
other devices...

> > [...]
> >
> > > > +values before the kernel is executed. If a driver requires to know rates of
> > > > +clocks set by firmware then they can be passed to kernel using _DSD.
> > > > +
> > > > +example :-
> > > > +
> > > > +Device (CLK0) {
> > > > +       ...
> > > > +
> > > > +       Name (_DSD, Package() {
> > > > +               ToUUID("XXXXX"),
> > > > +               Package() {
> > > > +                       Package(2) {"#clock-cells", 0},
> > >
> > > Clock-cells? What do they mean here? Is this specified in the ACPI
> > > standards? I had to register to get access to it, and didn't feel like
> > > doing that right now. I guess it's not _all_ that open a spec. :(
> >
> > Yeah, this is complete nonsense.
> >
> > If people are going to blindly copy elements from DT into ACPI without
> > actually understanding them, then ACPI is clearly no better than DT.
> >
> > [...]
> >
> > > > +static int device_probe(stuct platform_device *pdev)
> > > > +{
> > > > +       ...
> > > > +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
> > > > +       struct device_node node = pdev->dev.of_node;
> > > > +       ...
> > > > +
> > > > +       if (node)
> > > > +               ret = device_probe_dt(pdev);
> > > > +       else if (handle)
> > > > +               ret = device_probe_acpi(pdev);
> > > > +       else
> > > > +               /* other initialisation */
> > > > +               ...
> > > > +       /* Continue with any generic probe operations */
> > > > +       ...
> > > > +}
> > >
> > > This looks good to me, and it's also my preferred way of ACPI-enabling
> > > drivers. I guess we might discuss this at KS since it was a proposed
> > > topic there, and others will object. :)
> >
> > This is almost precisely the form of probe I want to see (it would be
> > nicer IMO to have separate entry points for ACPI / DT / platform data
> > that can all call a common probe core, but this isn't too far off).
> 
> I disagree, but it's also not something we're looking to change at this time.
> We'll take that debate when you post the patches changing how device probing
> works. :-)

Sure :)

Cheers,
Mark.
 
> > > > +
> > > > +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
> > > > +the different names the driver is probed for, both from DT and from ACPI.
> > > > +
> > > > +module device tables :-
> > > > +
> > > > +static struct of_device_id virtio_mmio_match[] = {
> > > > +        { .compatible = "virtio,mmio", },
> > > > +        {},
> > > > +};
> > > > +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
> > > > +
> > > > +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
> > > > +        { "LNRO0005", },
> > > > +        { }
> > >
> > > No comma here, but a comma on DT. Probably make them equivalent for
> > > consistency (including space between the braces).
> >
> > The comma on the DT form should probably be dropped. The NULL sentinel's
> > only job is to delimit the list, so it never makes sense to place
> > something after it.
> 
> Yep.
> 
> 
> -Olof
> 

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2100 bytes --]

On Mon, Jul 28, 2014 at 09:23:40AM -0700, Olof Johansson wrote:
> On Mon, Jul 28, 2014 at 09:42:57AM +0100, Graeme Gregory wrote:

> > >>+On no account should a Device Tree attempt to be replicated in ASL using such
> > >>+constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> > >>+data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> > >>+_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.

...

> > >I see these two sentences as contradictory, given that the _DSD doc
> > >worst case turn into quite a mess.

> > >Given that ACPI can present completely different data based on what OS
> > >is running, it's quite common to indeed have OS specific data in
> > >there. How does that relate to this document and these practices?

> > OS specific data has traditionally not worked out well for ACPI, I
> > would like to "persuade" people not to use it on ARM.

> It hasn't? I think Microsoft disagrees. It's also how vendors have been able to
> present an older machine description to keep their newer hardware compatible
> with older software, isn't it? How do you expect to handle that if you can
> only present one table? It's the same challenge that DT has.

It seems sensible to recommend against using OS specifics if possible if
only from the point of view of improving the robustness of the system -
the less paths there are to test in the BIOS the more likely it is that
the active path is one that's been well tested.  It's legal in the spec
and you can do it but encouraging people not to do it will hopefully
make life easier down the line.  Similarly encouraging people to put as
little as possible in there should reduce the opportunities they have to
get things wrong.

The best use case for OS testing is to enable a non-default workaround
for older versions of the OS but in the case of Linux that's a bit
tricky since we don't have clear versions to test against - even with
the kernel version number it's never clear if it's been patched by a
distro or something.  Windows is a much more fixed target here.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2100 bytes --]

On Mon, Jul 28, 2014 at 09:23:40AM -0700, Olof Johansson wrote:
> On Mon, Jul 28, 2014 at 09:42:57AM +0100, Graeme Gregory wrote:

> > >>+On no account should a Device Tree attempt to be replicated in ASL using such
> > >>+constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> > >>+data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> > >>+_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.

...

> > >I see these two sentences as contradictory, given that the _DSD doc
> > >worst case turn into quite a mess.

> > >Given that ACPI can present completely different data based on what OS
> > >is running, it's quite common to indeed have OS specific data in
> > >there. How does that relate to this document and these practices?

> > OS specific data has traditionally not worked out well for ACPI, I
> > would like to "persuade" people not to use it on ARM.

> It hasn't? I think Microsoft disagrees. It's also how vendors have been able to
> present an older machine description to keep their newer hardware compatible
> with older software, isn't it? How do you expect to handle that if you can
> only present one table? It's the same challenge that DT has.

It seems sensible to recommend against using OS specifics if possible if
only from the point of view of improving the robustness of the system -
the less paths there are to test in the BIOS the more likely it is that
the active path is one that's been well tested.  It's legal in the spec
and you can do it but encouraging people not to do it will hopefully
make life easier down the line.  Similarly encouraging people to put as
little as possible in there should reduce the opportunities they have to
get things wrong.

The best use case for OS testing is to enable a non-default workaround
for older versions of the OS but in the case of Linux that's a bit
tricky since we don't have clear versions to test against - even with
the kernel version number it's never clear if it's been patched by a
distro or something.  Windows is a much more fixed target here.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 19/19] Documentation: ACPI for ARM64

[Mark Brown]

On Mon, Jul 28, 2014 at 09:23:40AM -0700, Olof Johansson wrote:
> On Mon, Jul 28, 2014 at 09:42:57AM +0100, Graeme Gregory wrote:

> > >>+On no account should a Device Tree attempt to be replicated in ASL using such
> > >>+constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
> > >>+data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> > >>+_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.

...

> > >I see these two sentences as contradictory, given that the _DSD doc
> > >worst case turn into quite a mess.

> > >Given that ACPI can present completely different data based on what OS
> > >is running, it's quite common to indeed have OS specific data in
> > >there. How does that relate to this document and these practices?

> > OS specific data has traditionally not worked out well for ACPI, I
> > would like to "persuade" people not to use it on ARM.

> It hasn't? I think Microsoft disagrees. It's also how vendors have been able to
> present an older machine description to keep their newer hardware compatible
> with older software, isn't it? How do you expect to handle that if you can
> only present one table? It's the same challenge that DT has.

It seems sensible to recommend against using OS specifics if possible if
only from the point of view of improving the robustness of the system -
the less paths there are to test in the BIOS the more likely it is that
the active path is one that's been well tested.  It's legal in the spec
and you can do it but encouraging people not to do it will hopefully
make life easier down the line.  Similarly encouraging people to put as
little as possible in there should reduce the opportunities they have to
get things wrong.

The best use case for OS testing is to enable a non-default workaround
for older versions of the OS but in the case of Linux that's a bit
tricky since we don't have clear versions to test against - even with
the kernel version number it's never clear if it's been patched by a
distro or something.  Windows is a much more fixed target here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140728/2f24bc2a/attachment.sig>

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 10:00 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Jul 28, 2014 at 05:27:50PM +0100, Olof Johansson wrote:
>> On Mon, Jul 28, 2014 at 11:07:50AM +0200, Arnd Bergmann wrote:
>> > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
>> > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> > > > +Relationship with Device Tree
>> > > > +-----------------------------
>> > > > +
>> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>> > > > +exclusive with DT support at compile time.
>> > > > +
>> > > > +At boot time the kernel will only use one description method depending on
>> > > > +parameters passed from the bootloader.
>> > >
>> > > Possibly overriden by kernel bootargs. And as debated for quite a
>> > > while earlier this year, acpi should still default to off -- if a DT
>> > > and ACPI are both passed in, DT should at this time be given priority.
>> >
>> > I think this would be harder to do with the way that ACPI is passed in
>> > to the kernel. IIRC, you always have a minimal DT information based on
>> > the ARM64 boot protocol, but in the case of ACPI, this contains pointers
>> > to the ACPI tables, which are then used for populating the Linux platform
>> > devices (unless acpi=disabled is set), while the other contents of the
>> > DTB may be present but we skip the of_platform_populate state.
>>
>> How can it be harder to do? If you support acpi=off, then you should support
>> acpi=on.
>>
>> Another alternative would be to have an early fixup that stubs out
>> the acpi properties from the DTB unless there's an 'acpi' or 'acpi=on'
>> argument on the cmdline. Not quite as tidy a solution, though.
>
> I don't follow:
>
> If you want to disable ACPI, you can pass acpi=off. This is your
> workaround for broken ACPI (and only if you happen to have wrirten your
> own DTB, because many/most ACPI systems WILL NOT have a DTB to begin
> with).

All ACPI should be assumed broken at this time, so acpi=off _must_ be
the default.

> If you have ACPI, for what technical reason would you not attempt to use
> it by default?

Because it will be broken, or the company you bought the machine from
implemented it wrong because they're still learning how to do this
too. The original doc even mentioned that there are parts of the
binding that aren't even sorted out. The _DSD stuff, too. Overall,
it's not yet ready to be the default boot method.

> There will be systems which _DO NOT_ have any sort of DTB to begin with.

Listen, we've been really clear about this: DT is the default that
everybody has to use for mainline kernel for the near term. If you
have an ACPI-only system, then you either have to write a DT for it,
or you won't be booting mainline on it.

If people have not been listening to the advice we've been giving, and
that sucks for them. Even worse, I suspect there are players out there
who have taken bad advice from certain players. At the end of the day,
it is not our problem. We were quite clear, and Grant even wrote a
long and good blog post about this.

If they really want to, they can boot with acpi=on instead. It's not
like it's hard to add.

> For VMs, both may be provided. By the necessity of a DTB being present
> for bootargs, ACPI _MUST_ take precedence. If you don't want it, you
> pass acpi=off, or configure your VM software to not pass an ACPI
> configuration table.
>
> Why avoid ACPI by default? So that we can later enable it and discover
> it's completely broken? Then we need short-sighted hacks to work around
> short-sighted decisions.

We have answered this multiple times in the past already. Please go
read the archives.

It is highly unlikely that we will retroactively enable it in the
future for the first-generation devices either. Chances are there'll
be a rev or two more of ACPI before then, so we can do something such
as "only automatically accept ACPI 5.4 or higher" or whatever. That
can all be sorted when the time comes.

> The best thing to do is to try and use things, be as strict as possible,
> stress the implementation, and blow up early and loudly so that said
> systems must be fixed.

"Try", sure. Make it the default and blow up and make a system
unbootable when it's wrong? No, absolutely not. Not while bindings are
still being hashed out and vendors are still figuring things out.

> People are using Linux for bringup; it is the closest thing to a
> validation suite. Being lazy and hacking around things for now will only
> make things worse in the long run.

Who's hacking around what?

And holy shit, there is no validation suite? Then ACPI is doomed.
Literally. Linux can't be a validation suite for it. It means that
potentially every single code change to anything related to ACPI
(drivers or core) on Linux means that it's now using completely
untested pieces of firmware. Fodder for nightmares.

> We _CANNOT_ place our fingers in our ears and blind ourselves with the
> DT banner. ACPI is ugly, sure, but so is DT. Neither is fundamentally
> better than the other. The best thing we can do is make it as easy as
> possible to highlight bugs in ACPI implementations and barf such that
> people are forced to fix their ACPI implementations.

It's not about what's better than the other. They both suck. But one
is already here and we've learned by now most of the ways in which it
sucks and we have a good idea of how to avoid the worst of it. On the
other, we have all of that in front of us still. Guess which one it
makes sense to stick to?

> No other OS supports ACPI on 64-bit arm systems. Being strict should
> force implementors to try harder.

Thanks for _finally_ stating what we've all known for a very long time
but everybody's been pretending isn't the case.

>> > If this is correct, then replacing the firmware-generated dtb with a
>> > user-provided on would implicitly remove the ACPI tables from visibility,
>> > which is exactly what we want.
>>
>> I was of the impression that firmware patches in the ACPI entries into either
>> device-tree before launching the kernel. Is that not the case?
>
> 1) The ACPI tables will be registered as UEFI configuration tables,
>    within platform-specific UEFI code. Nothing outside of UEFI is
>    involved.
>
> 1a) A loader (e.g. GRUB, the EFI stub) COULD override the loaded tables.
>    This is a workaround, and should never be the standard way of doing
>    things. It defeats the point, much like appended DTB.
>
> 2) The EFI stub will patch UEFI memory map properties into the DTB. The
>    firmware is not involved.
>
> 3) The kernel will detect whether EFI is present by the presence of the
>    memory map, and try to use it if so. The memory map comes from UEFI,
>    and memory nodes (and memreserves) are ignored. Only select
>    properties under /chosen (e.g. bootargs) will be used.
>
> 4) If booted via EFI, the kernel will look for known UEFI configuration
>    tables by (G|U)UID, and set up some pointers.
>
> 5) The ACPI code will go and look to see if the ACPI table pointers have
>    been initialised. If so, the kernel will attempt to use the ACPI
>    tables unlesss instructed otherwise. If using ACPI, the DTB will be
>    ignored outside of /chosen.
>
> The ACPI tables or pointers to them are not directly patched into the
> DTB at any stage. The choice of using ACPI is left with the kernel.

Thanks, excellent summary.

>> And what if some bootloader chooses to do it that way in the future?
>> It's better to not assume that they get it right.
>
> For the firmware/loader to do so it would have to work around the kernel
> version parameter the stub places in the DTB and the kernel verifies. If
> it does so, I would argue said firmware is actively malicious.

Ok.

>> > It's possible that I'm misremembering it though, and it should be
>> > documented better.
>>
>> Yes, definitely needs to be documented to not leave room for random
>> interpretation later on.
>
> We should definitely make the documentation as strict as possible on
> what's allowed, and have the kernel barf early on if requirements are
> not met.

It should definitely complain when it finds bad entries, but making
the kernel unusable for end-users because someone is still under
development is the wrong answer. While the ACPI bindings are sorted
out, we'll ship platforms using DT support in the kernel. This must
not change just because some piece of the ACPI work is starting to
land in-tree while other pieces are still being worked out.

And again: The kernel is not a compliance suite for ACPI, and if the
vendors doing bringup is treating it that way then I'm quite scared of
the whole endeavor.



-Olof

[PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 10:00 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Jul 28, 2014 at 05:27:50PM +0100, Olof Johansson wrote:
>> On Mon, Jul 28, 2014 at 11:07:50AM +0200, Arnd Bergmann wrote:
>> > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
>> > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> > > > +Relationship with Device Tree
>> > > > +-----------------------------
>> > > > +
>> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>> > > > +exclusive with DT support at compile time.
>> > > > +
>> > > > +At boot time the kernel will only use one description method depending on
>> > > > +parameters passed from the bootloader.
>> > >
>> > > Possibly overriden by kernel bootargs. And as debated for quite a
>> > > while earlier this year, acpi should still default to off -- if a DT
>> > > and ACPI are both passed in, DT should at this time be given priority.
>> >
>> > I think this would be harder to do with the way that ACPI is passed in
>> > to the kernel. IIRC, you always have a minimal DT information based on
>> > the ARM64 boot protocol, but in the case of ACPI, this contains pointers
>> > to the ACPI tables, which are then used for populating the Linux platform
>> > devices (unless acpi=disabled is set), while the other contents of the
>> > DTB may be present but we skip the of_platform_populate state.
>>
>> How can it be harder to do? If you support acpi=off, then you should support
>> acpi=on.
>>
>> Another alternative would be to have an early fixup that stubs out
>> the acpi properties from the DTB unless there's an 'acpi' or 'acpi=on'
>> argument on the cmdline. Not quite as tidy a solution, though.
>
> I don't follow:
>
> If you want to disable ACPI, you can pass acpi=off. This is your
> workaround for broken ACPI (and only if you happen to have wrirten your
> own DTB, because many/most ACPI systems WILL NOT have a DTB to begin
> with).

All ACPI should be assumed broken at this time, so acpi=off _must_ be
the default.

> If you have ACPI, for what technical reason would you not attempt to use
> it by default?

Because it will be broken, or the company you bought the machine from
implemented it wrong because they're still learning how to do this
too. The original doc even mentioned that there are parts of the
binding that aren't even sorted out. The _DSD stuff, too. Overall,
it's not yet ready to be the default boot method.

> There will be systems which _DO NOT_ have any sort of DTB to begin with.

Listen, we've been really clear about this: DT is the default that
everybody has to use for mainline kernel for the near term. If you
have an ACPI-only system, then you either have to write a DT for it,
or you won't be booting mainline on it.

If people have not been listening to the advice we've been giving, and
that sucks for them. Even worse, I suspect there are players out there
who have taken bad advice from certain players. At the end of the day,
it is not our problem. We were quite clear, and Grant even wrote a
long and good blog post about this.

If they really want to, they can boot with acpi=on instead. It's not
like it's hard to add.

> For VMs, both may be provided. By the necessity of a DTB being present
> for bootargs, ACPI _MUST_ take precedence. If you don't want it, you
> pass acpi=off, or configure your VM software to not pass an ACPI
> configuration table.
>
> Why avoid ACPI by default? So that we can later enable it and discover
> it's completely broken? Then we need short-sighted hacks to work around
> short-sighted decisions.

We have answered this multiple times in the past already. Please go
read the archives.

It is highly unlikely that we will retroactively enable it in the
future for the first-generation devices either. Chances are there'll
be a rev or two more of ACPI before then, so we can do something such
as "only automatically accept ACPI 5.4 or higher" or whatever. That
can all be sorted when the time comes.

> The best thing to do is to try and use things, be as strict as possible,
> stress the implementation, and blow up early and loudly so that said
> systems must be fixed.

"Try", sure. Make it the default and blow up and make a system
unbootable when it's wrong? No, absolutely not. Not while bindings are
still being hashed out and vendors are still figuring things out.

> People are using Linux for bringup; it is the closest thing to a
> validation suite. Being lazy and hacking around things for now will only
> make things worse in the long run.

Who's hacking around what?

And holy shit, there is no validation suite? Then ACPI is doomed.
Literally. Linux can't be a validation suite for it. It means that
potentially every single code change to anything related to ACPI
(drivers or core) on Linux means that it's now using completely
untested pieces of firmware. Fodder for nightmares.

> We _CANNOT_ place our fingers in our ears and blind ourselves with the
> DT banner. ACPI is ugly, sure, but so is DT. Neither is fundamentally
> better than the other. The best thing we can do is make it as easy as
> possible to highlight bugs in ACPI implementations and barf such that
> people are forced to fix their ACPI implementations.

It's not about what's better than the other. They both suck. But one
is already here and we've learned by now most of the ways in which it
sucks and we have a good idea of how to avoid the worst of it. On the
other, we have all of that in front of us still. Guess which one it
makes sense to stick to?

> No other OS supports ACPI on 64-bit arm systems. Being strict should
> force implementors to try harder.

Thanks for _finally_ stating what we've all known for a very long time
but everybody's been pretending isn't the case.

>> > If this is correct, then replacing the firmware-generated dtb with a
>> > user-provided on would implicitly remove the ACPI tables from visibility,
>> > which is exactly what we want.
>>
>> I was of the impression that firmware patches in the ACPI entries into either
>> device-tree before launching the kernel. Is that not the case?
>
> 1) The ACPI tables will be registered as UEFI configuration tables,
>    within platform-specific UEFI code. Nothing outside of UEFI is
>    involved.
>
> 1a) A loader (e.g. GRUB, the EFI stub) COULD override the loaded tables.
>    This is a workaround, and should never be the standard way of doing
>    things. It defeats the point, much like appended DTB.
>
> 2) The EFI stub will patch UEFI memory map properties into the DTB. The
>    firmware is not involved.
>
> 3) The kernel will detect whether EFI is present by the presence of the
>    memory map, and try to use it if so. The memory map comes from UEFI,
>    and memory nodes (and memreserves) are ignored. Only select
>    properties under /chosen (e.g. bootargs) will be used.
>
> 4) If booted via EFI, the kernel will look for known UEFI configuration
>    tables by (G|U)UID, and set up some pointers.
>
> 5) The ACPI code will go and look to see if the ACPI table pointers have
>    been initialised. If so, the kernel will attempt to use the ACPI
>    tables unlesss instructed otherwise. If using ACPI, the DTB will be
>    ignored outside of /chosen.
>
> The ACPI tables or pointers to them are not directly patched into the
> DTB at any stage. The choice of using ACPI is left with the kernel.

Thanks, excellent summary.

>> And what if some bootloader chooses to do it that way in the future?
>> It's better to not assume that they get it right.
>
> For the firmware/loader to do so it would have to work around the kernel
> version parameter the stub places in the DTB and the kernel verifies. If
> it does so, I would argue said firmware is actively malicious.

Ok.

>> > It's possible that I'm misremembering it though, and it should be
>> > documented better.
>>
>> Yes, definitely needs to be documented to not leave room for random
>> interpretation later on.
>
> We should definitely make the documentation as strict as possible on
> what's allowed, and have the kernel barf early on if requirements are
> not met.

It should definitely complain when it finds bad entries, but making
the kernel unusable for end-users because someone is still under
development is the wrong answer. While the ACPI bindings are sorted
out, we'll ship platforms using DT support in the kernel. This must
not change just because some piece of the ACPI work is starting to
land in-tree while other pieces are still being worked out.

And again: The kernel is not a compliance suite for ACPI, and if the
vendors doing bringup is treating it that way then I'm quite scared of
the whole endeavor.



-Olof

Re: [PATCH 03/19] ARM64 / ACPI: Introduce lowlevel suspend function

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> From: Graeme Gregory <graeme.gregory@linaro.org>
>
> acpi_wakeup_address is used on x86 as the address bios jumps into
> when machine wakes up from suspend. As arm64 does not have such a
> bios this mechanism will be provided by other means. But the define
> is still required inside the acpi core.
>
> Introduce a null stub for acpi_suspend_lowlevel as this is also
> required by core. This will be filled in when standards are
> defined for arm64 ACPI global power states.
>
> Reviewed-by: Grant Likely <grant.likely@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/acpi.h |   12 ++++++++++++
>   arch/arm64/kernel/acpi.c      |    7 +++++++
>   2 files changed, 19 insertions(+)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index e8581ea..44b617f 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -36,6 +36,18 @@ static inline bool acpi_has_cpu_in_madt(void)
>   	return 1;
>   }
>
> +/* Low-level suspend routine.
> + *
> + * ACPI S-states for ARM64 have to be defined
> + * and approved before doing anything else, maybe
> + * we need update the ACPI spec, here we
> + * just introduce function and macro needed by
> + * ACPI core as IA64 did, and revisit them when
> + * the spec is ready.
> + */
> +extern int (*acpi_suspend_lowlevel)(void);
> +#define acpi_wakeup_address 0
> +

While I understand that this is temporary solution, but will this be
sufficient to make sure we don't enter acpi_suspend_enter ?

A brief look at acpi_suspend_enter showed access to write to
ACPI_BITREG_SCI_ENABLE which might just explode. But if you are sure that
it will not be executed, then it should be fine for now.

Regards,
Sudeep

Re: [PATCH 03/19] ARM64 / ACPI: Introduce lowlevel suspend function

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> From: Graeme Gregory <graeme.gregory@linaro.org>
>
> acpi_wakeup_address is used on x86 as the address bios jumps into
> when machine wakes up from suspend. As arm64 does not have such a
> bios this mechanism will be provided by other means. But the define
> is still required inside the acpi core.
>
> Introduce a null stub for acpi_suspend_lowlevel as this is also
> required by core. This will be filled in when standards are
> defined for arm64 ACPI global power states.
>
> Reviewed-by: Grant Likely <grant.likely@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/acpi.h |   12 ++++++++++++
>   arch/arm64/kernel/acpi.c      |    7 +++++++
>   2 files changed, 19 insertions(+)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index e8581ea..44b617f 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -36,6 +36,18 @@ static inline bool acpi_has_cpu_in_madt(void)
>   	return 1;
>   }
>
> +/* Low-level suspend routine.
> + *
> + * ACPI S-states for ARM64 have to be defined
> + * and approved before doing anything else, maybe
> + * we need update the ACPI spec, here we
> + * just introduce function and macro needed by
> + * ACPI core as IA64 did, and revisit them when
> + * the spec is ready.
> + */
> +extern int (*acpi_suspend_lowlevel)(void);
> +#define acpi_wakeup_address 0
> +

While I understand that this is temporary solution, but will this be
sufficient to make sure we don't enter acpi_suspend_enter ?

A brief look at acpi_suspend_enter showed access to write to
ACPI_BITREG_SCI_ENABLE which might just explode. But if you are sure that
it will not be executed, then it should be fine for now.

Regards,
Sudeep

[PATCH 03/19] ARM64 / ACPI: Introduce lowlevel suspend function

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> From: Graeme Gregory <graeme.gregory@linaro.org>
>
> acpi_wakeup_address is used on x86 as the address bios jumps into
> when machine wakes up from suspend. As arm64 does not have such a
> bios this mechanism will be provided by other means. But the define
> is still required inside the acpi core.
>
> Introduce a null stub for acpi_suspend_lowlevel as this is also
> required by core. This will be filled in when standards are
> defined for arm64 ACPI global power states.
>
> Reviewed-by: Grant Likely <grant.likely@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/acpi.h |   12 ++++++++++++
>   arch/arm64/kernel/acpi.c      |    7 +++++++
>   2 files changed, 19 insertions(+)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index e8581ea..44b617f 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -36,6 +36,18 @@ static inline bool acpi_has_cpu_in_madt(void)
>   	return 1;
>   }
>
> +/* Low-level suspend routine.
> + *
> + * ACPI S-states for ARM64 have to be defined
> + * and approved before doing anything else, maybe
> + * we need update the ACPI spec, here we
> + * just introduce function and macro needed by
> + * ACPI core as IA64 did, and revisit them when
> + * the spec is ready.
> + */
> +extern int (*acpi_suspend_lowlevel)(void);
> +#define acpi_wakeup_address 0
> +

While I understand that this is temporary solution, but will this be
sufficient to make sure we don't enter acpi_suspend_enter ?

A brief look at acpi_suspend_enter showed access to write to
ACPI_BITREG_SCI_ENABLE which might just explode. But if you are sure that
it will not be executed, then it should be fine for now.

Regards,
Sudeep

Re: [PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> From: Al Stone <al.stone@linaro.org>
>
> As we want to get ACPI tables to parse and then use the information
> for system initialization, we should get the RSDP (Root System
> Description Pointer) first, it then locates Extended Root Description
> Table (XSDT) which contains all the 64-bit physical address that
> pointer to other boot-time tables.
>
> Introduce acpi.c and its related head file in this patch to provide
> fundamental needs of extern variables and functions for ACPI core,
> and then get boot-time tables as needed.
>    - asm/cpu.h need for ACPI core and will be updated in the future to
>      add definitions for arch_(un)register_cpu which are required for
>      ACPI based physical CPU hotplug;
>    - asm/acenv.h for arch specific ACPICA environments and
>      implementation;
>    - asm/acpi.h for arch specific variables and functions needed by
>      ACPI driver core;
>    - acpi.c for ARM64 related ACPI implementation for ACPI driver
>      core;
>
> acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
> it will be called in setup_arch() before paging_init(), so we should
> use eary_memremap() mechanism here to get the RSDP and all the table
> pointers.
>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/acenv.h |   18 ++++++++++
>   arch/arm64/include/asm/acpi.h  |   41 ++++++++++++++++++++++
>   arch/arm64/include/asm/cpu.h   |   11 ++++++
>   arch/arm64/kernel/Makefile     |    1 +
>   arch/arm64/kernel/acpi.c       |   76 ++++++++++++++++++++++++++++++++++++++++
>   arch/arm64/kernel/setup.c      |    4 +++
>   6 files changed, 151 insertions(+)
>   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/cpu.h
>   create mode 100644 arch/arm64/kernel/acpi.c
>
> diff --git a/arch/arm64/include/asm/acenv.h b/arch/arm64/include/asm/acenv.h
> new file mode 100644
> index 0000000..3899ee6
> --- /dev/null
> +++ b/arch/arm64/include/asm/acenv.h
> @@ -0,0 +1,18 @@
> +/*
> + * ARM64 specific ACPICA environments and implementation
> + *
> + * Copyright (C) 2014, Linaro Ltd.
> + *   Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *   Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _ASM_ACENV_H
> +#define _ASM_ACENV_H
> +
> +#define ACPI_FLUSH_CPU_CACHE() WARN_ONCE(1, "Not currently supported on ARM64")
> +
> +#endif /* _ASM_ACENV_H */
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> new file mode 100644
> index 0000000..e8581ea
> --- /dev/null
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -0,0 +1,41 @@
> +/*
> + *  Copyright (C) 2013-2014, Linaro Ltd.
> + *     Author: Al Stone <al.stone@linaro.org>
> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation;
> + */
> +
> +#ifndef _ASM_ACPI_H
> +#define _ASM_ACPI_H
> +
> +/* Basic configuration for ACPI */
> +#ifdef CONFIG_ACPI
> +extern int acpi_disabled;
> +extern int acpi_noirq;
> +extern int acpi_pci_disabled;
> +extern int acpi_strict;

Until we need to enable workarounds, we should have acpi_strict
as macro rather than variable similar to IA64.

> +
> +static inline void disable_acpi(void)
> +{
> +       acpi_disabled = 1;
> +       acpi_pci_disabled = 1;
> +       acpi_noirq = 1;
> +}
> +
> +/*
> + * MADT must provide at least one GICC structure
> + * for GIC initialization, so CPU will be
> + * always available in MADT on ARM64
> + */
> +static inline bool acpi_has_cpu_in_madt(void)
> +{
> +       return 1;
> +}
> +

I don't see the user of this function in the series, it's better to
remove. Moreover the comment is so misleading. We will have CPU UID
not the CPU itself in MADT.

> +#endif /* CONFIG_ACPI */
> +
> +#endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
> new file mode 100644
> index 0000000..cee7d3f
> --- /dev/null
> +++ b/arch/arm64/include/asm/cpu.h
> @@ -0,0 +1,11 @@
> +/*
> + *  Copyright (C) 2013-2014 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef __ASM_CPU_H
> +#define __ASM_CPU_H
> +
> +#endif
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index cdaedad..b568c26 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o suspend.o
>   arm64-obj-$(CONFIG_JUMP_LABEL)         += jump_label.o
>   arm64-obj-$(CONFIG_KGDB)               += kgdb.o
>   arm64-obj-$(CONFIG_EFI)                        += efi.o efi-stub.o efi-entry.o
> +arm64-obj-$(CONFIG_ACPI)               += acpi.o
>
>   obj-y                                  += $(arm64-obj-y) vdso/
>   obj-m                                  += $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> new file mode 100644
> index 0000000..c62fce6
> --- /dev/null
> +++ b/arch/arm64/kernel/acpi.c
> @@ -0,0 +1,76 @@
> +/*
> + *  ARM64 Specific Low-Level ACPI Boot Support
> + *
> + *  Copyright (C) 2013-2014, Linaro Ltd.
> + *     Author: Al Stone <al.stone@linaro.org>
> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/acpi.h>
> +#include <linux/cpumask.h>
> +#include <linux/memblock.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/bootmem.h>
> +#include <linux/smp.h>
> +
> +/*
> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> + * variable is still required by the ACPI core
> + */
> +u32 acpi_rsdt_forced;

This looks like yet another stray variable not used anywhere including
core ACPI

> +
> +int acpi_noirq;                        /* skip ACPI IRQ initialization */
> +int acpi_strict;
> +int acpi_disabled;
> +EXPORT_SYMBOL(acpi_disabled);
> +
> +int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
> +EXPORT_SYMBOL(acpi_pci_disabled);
> +
> +/*
> + * __acpi_map_table() will be called before page_init(), so early_ioremap()
> + * or early_memremap() should be called here to for ACPI table mapping.
> + */
> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
> +{
> +       if (!phys || !size)
> +               return NULL;
> +
> +       return early_memremap(phys, size);
> +}
> +
> +void __init __acpi_unmap_table(char *map, unsigned long size)
> +{
> +       if (!map || !size)
> +               return;
> +
> +       early_iounmap(map, size);

Why not early_memunmap for consistency ?
Also now there's generic implementation of early mappings does it make
sense to move this also to acpi core ?

Regards,
Sudeep

Re: [PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> From: Al Stone <al.stone@linaro.org>
>
> As we want to get ACPI tables to parse and then use the information
> for system initialization, we should get the RSDP (Root System
> Description Pointer) first, it then locates Extended Root Description
> Table (XSDT) which contains all the 64-bit physical address that
> pointer to other boot-time tables.
>
> Introduce acpi.c and its related head file in this patch to provide
> fundamental needs of extern variables and functions for ACPI core,
> and then get boot-time tables as needed.
>    - asm/cpu.h need for ACPI core and will be updated in the future to
>      add definitions for arch_(un)register_cpu which are required for
>      ACPI based physical CPU hotplug;
>    - asm/acenv.h for arch specific ACPICA environments and
>      implementation;
>    - asm/acpi.h for arch specific variables and functions needed by
>      ACPI driver core;
>    - acpi.c for ARM64 related ACPI implementation for ACPI driver
>      core;
>
> acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
> it will be called in setup_arch() before paging_init(), so we should
> use eary_memremap() mechanism here to get the RSDP and all the table
> pointers.
>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/acenv.h |   18 ++++++++++
>   arch/arm64/include/asm/acpi.h  |   41 ++++++++++++++++++++++
>   arch/arm64/include/asm/cpu.h   |   11 ++++++
>   arch/arm64/kernel/Makefile     |    1 +
>   arch/arm64/kernel/acpi.c       |   76 ++++++++++++++++++++++++++++++++++++++++
>   arch/arm64/kernel/setup.c      |    4 +++
>   6 files changed, 151 insertions(+)
>   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/cpu.h
>   create mode 100644 arch/arm64/kernel/acpi.c
>
> diff --git a/arch/arm64/include/asm/acenv.h b/arch/arm64/include/asm/acenv.h
> new file mode 100644
> index 0000000..3899ee6
> --- /dev/null
> +++ b/arch/arm64/include/asm/acenv.h
> @@ -0,0 +1,18 @@
> +/*
> + * ARM64 specific ACPICA environments and implementation
> + *
> + * Copyright (C) 2014, Linaro Ltd.
> + *   Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *   Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _ASM_ACENV_H
> +#define _ASM_ACENV_H
> +
> +#define ACPI_FLUSH_CPU_CACHE() WARN_ONCE(1, "Not currently supported on ARM64")
> +
> +#endif /* _ASM_ACENV_H */
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> new file mode 100644
> index 0000000..e8581ea
> --- /dev/null
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -0,0 +1,41 @@
> +/*
> + *  Copyright (C) 2013-2014, Linaro Ltd.
> + *     Author: Al Stone <al.stone@linaro.org>
> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation;
> + */
> +
> +#ifndef _ASM_ACPI_H
> +#define _ASM_ACPI_H
> +
> +/* Basic configuration for ACPI */
> +#ifdef CONFIG_ACPI
> +extern int acpi_disabled;
> +extern int acpi_noirq;
> +extern int acpi_pci_disabled;
> +extern int acpi_strict;

Until we need to enable workarounds, we should have acpi_strict
as macro rather than variable similar to IA64.

> +
> +static inline void disable_acpi(void)
> +{
> +       acpi_disabled = 1;
> +       acpi_pci_disabled = 1;
> +       acpi_noirq = 1;
> +}
> +
> +/*
> + * MADT must provide at least one GICC structure
> + * for GIC initialization, so CPU will be
> + * always available in MADT on ARM64
> + */
> +static inline bool acpi_has_cpu_in_madt(void)
> +{
> +       return 1;
> +}
> +

I don't see the user of this function in the series, it's better to
remove. Moreover the comment is so misleading. We will have CPU UID
not the CPU itself in MADT.

> +#endif /* CONFIG_ACPI */
> +
> +#endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
> new file mode 100644
> index 0000000..cee7d3f
> --- /dev/null
> +++ b/arch/arm64/include/asm/cpu.h
> @@ -0,0 +1,11 @@
> +/*
> + *  Copyright (C) 2013-2014 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef __ASM_CPU_H
> +#define __ASM_CPU_H
> +
> +#endif
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index cdaedad..b568c26 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o suspend.o
>   arm64-obj-$(CONFIG_JUMP_LABEL)         += jump_label.o
>   arm64-obj-$(CONFIG_KGDB)               += kgdb.o
>   arm64-obj-$(CONFIG_EFI)                        += efi.o efi-stub.o efi-entry.o
> +arm64-obj-$(CONFIG_ACPI)               += acpi.o
>
>   obj-y                                  += $(arm64-obj-y) vdso/
>   obj-m                                  += $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> new file mode 100644
> index 0000000..c62fce6
> --- /dev/null
> +++ b/arch/arm64/kernel/acpi.c
> @@ -0,0 +1,76 @@
> +/*
> + *  ARM64 Specific Low-Level ACPI Boot Support
> + *
> + *  Copyright (C) 2013-2014, Linaro Ltd.
> + *     Author: Al Stone <al.stone@linaro.org>
> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/acpi.h>
> +#include <linux/cpumask.h>
> +#include <linux/memblock.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/bootmem.h>
> +#include <linux/smp.h>
> +
> +/*
> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> + * variable is still required by the ACPI core
> + */
> +u32 acpi_rsdt_forced;

This looks like yet another stray variable not used anywhere including
core ACPI

> +
> +int acpi_noirq;                        /* skip ACPI IRQ initialization */
> +int acpi_strict;
> +int acpi_disabled;
> +EXPORT_SYMBOL(acpi_disabled);
> +
> +int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
> +EXPORT_SYMBOL(acpi_pci_disabled);
> +
> +/*
> + * __acpi_map_table() will be called before page_init(), so early_ioremap()
> + * or early_memremap() should be called here to for ACPI table mapping.
> + */
> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
> +{
> +       if (!phys || !size)
> +               return NULL;
> +
> +       return early_memremap(phys, size);
> +}
> +
> +void __init __acpi_unmap_table(char *map, unsigned long size)
> +{
> +       if (!map || !size)
> +               return;
> +
> +       early_iounmap(map, size);

Why not early_memunmap for consistency ?
Also now there's generic implementation of early mappings does it make
sense to move this also to acpi core ?

Regards,
Sudeep

[PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> From: Al Stone <al.stone@linaro.org>
>
> As we want to get ACPI tables to parse and then use the information
> for system initialization, we should get the RSDP (Root System
> Description Pointer) first, it then locates Extended Root Description
> Table (XSDT) which contains all the 64-bit physical address that
> pointer to other boot-time tables.
>
> Introduce acpi.c and its related head file in this patch to provide
> fundamental needs of extern variables and functions for ACPI core,
> and then get boot-time tables as needed.
>    - asm/cpu.h need for ACPI core and will be updated in the future to
>      add definitions for arch_(un)register_cpu which are required for
>      ACPI based physical CPU hotplug;
>    - asm/acenv.h for arch specific ACPICA environments and
>      implementation;
>    - asm/acpi.h for arch specific variables and functions needed by
>      ACPI driver core;
>    - acpi.c for ARM64 related ACPI implementation for ACPI driver
>      core;
>
> acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
> it will be called in setup_arch() before paging_init(), so we should
> use eary_memremap() mechanism here to get the RSDP and all the table
> pointers.
>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/acenv.h |   18 ++++++++++
>   arch/arm64/include/asm/acpi.h  |   41 ++++++++++++++++++++++
>   arch/arm64/include/asm/cpu.h   |   11 ++++++
>   arch/arm64/kernel/Makefile     |    1 +
>   arch/arm64/kernel/acpi.c       |   76 ++++++++++++++++++++++++++++++++++++++++
>   arch/arm64/kernel/setup.c      |    4 +++
>   6 files changed, 151 insertions(+)
>   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/cpu.h
>   create mode 100644 arch/arm64/kernel/acpi.c
>
> diff --git a/arch/arm64/include/asm/acenv.h b/arch/arm64/include/asm/acenv.h
> new file mode 100644
> index 0000000..3899ee6
> --- /dev/null
> +++ b/arch/arm64/include/asm/acenv.h
> @@ -0,0 +1,18 @@
> +/*
> + * ARM64 specific ACPICA environments and implementation
> + *
> + * Copyright (C) 2014, Linaro Ltd.
> + *   Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *   Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _ASM_ACENV_H
> +#define _ASM_ACENV_H
> +
> +#define ACPI_FLUSH_CPU_CACHE() WARN_ONCE(1, "Not currently supported on ARM64")
> +
> +#endif /* _ASM_ACENV_H */
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> new file mode 100644
> index 0000000..e8581ea
> --- /dev/null
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -0,0 +1,41 @@
> +/*
> + *  Copyright (C) 2013-2014, Linaro Ltd.
> + *     Author: Al Stone <al.stone@linaro.org>
> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation;
> + */
> +
> +#ifndef _ASM_ACPI_H
> +#define _ASM_ACPI_H
> +
> +/* Basic configuration for ACPI */
> +#ifdef CONFIG_ACPI
> +extern int acpi_disabled;
> +extern int acpi_noirq;
> +extern int acpi_pci_disabled;
> +extern int acpi_strict;

Until we need to enable workarounds, we should have acpi_strict
as macro rather than variable similar to IA64.

> +
> +static inline void disable_acpi(void)
> +{
> +       acpi_disabled = 1;
> +       acpi_pci_disabled = 1;
> +       acpi_noirq = 1;
> +}
> +
> +/*
> + * MADT must provide at least one GICC structure
> + * for GIC initialization, so CPU will be
> + * always available in MADT on ARM64
> + */
> +static inline bool acpi_has_cpu_in_madt(void)
> +{
> +       return 1;
> +}
> +

I don't see the user of this function in the series, it's better to
remove. Moreover the comment is so misleading. We will have CPU UID
not the CPU itself in MADT.

> +#endif /* CONFIG_ACPI */
> +
> +#endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
> new file mode 100644
> index 0000000..cee7d3f
> --- /dev/null
> +++ b/arch/arm64/include/asm/cpu.h
> @@ -0,0 +1,11 @@
> +/*
> + *  Copyright (C) 2013-2014 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef __ASM_CPU_H
> +#define __ASM_CPU_H
> +
> +#endif
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index cdaedad..b568c26 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o suspend.o
>   arm64-obj-$(CONFIG_JUMP_LABEL)         += jump_label.o
>   arm64-obj-$(CONFIG_KGDB)               += kgdb.o
>   arm64-obj-$(CONFIG_EFI)                        += efi.o efi-stub.o efi-entry.o
> +arm64-obj-$(CONFIG_ACPI)               += acpi.o
>
>   obj-y                                  += $(arm64-obj-y) vdso/
>   obj-m                                  += $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> new file mode 100644
> index 0000000..c62fce6
> --- /dev/null
> +++ b/arch/arm64/kernel/acpi.c
> @@ -0,0 +1,76 @@
> +/*
> + *  ARM64 Specific Low-Level ACPI Boot Support
> + *
> + *  Copyright (C) 2013-2014, Linaro Ltd.
> + *     Author: Al Stone <al.stone@linaro.org>
> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/acpi.h>
> +#include <linux/cpumask.h>
> +#include <linux/memblock.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/bootmem.h>
> +#include <linux/smp.h>
> +
> +/*
> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> + * variable is still required by the ACPI core
> + */
> +u32 acpi_rsdt_forced;

This looks like yet another stray variable not used anywhere including
core ACPI

> +
> +int acpi_noirq;                        /* skip ACPI IRQ initialization */
> +int acpi_strict;
> +int acpi_disabled;
> +EXPORT_SYMBOL(acpi_disabled);
> +
> +int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
> +EXPORT_SYMBOL(acpi_pci_disabled);
> +
> +/*
> + * __acpi_map_table() will be called before page_init(), so early_ioremap()
> + * or early_memremap() should be called here to for ACPI table mapping.
> + */
> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
> +{
> +       if (!phys || !size)
> +               return NULL;
> +
> +       return early_memremap(phys, size);
> +}
> +
> +void __init __acpi_unmap_table(char *map, unsigned long size)
> +{
> +       if (!map || !size)
> +               return;
> +
> +       early_iounmap(map, size);

Why not early_memunmap for consistency ?
Also now there's generic implementation of early mappings does it make
sense to move this also to acpi core ?

Regards,
Sudeep

Re: [PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> From: Al Stone <al.stone@linaro.org>
>
> As we want to get ACPI tables to parse and then use the information
> for system initialization, we should get the RSDP (Root System
> Description Pointer) first, it then locates Extended Root Description
> Table (XSDT) which contains all the 64-bit physical address that
> pointer to other boot-time tables.
>
> Introduce acpi.c and its related head file in this patch to provide
> fundamental needs of extern variables and functions for ACPI core,
> and then get boot-time tables as needed.
>    - asm/cpu.h need for ACPI core and will be updated in the future to
>      add definitions for arch_(un)register_cpu which are required for
>      ACPI based physical CPU hotplug;
>    - asm/acenv.h for arch specific ACPICA environments and
>      implementation;
>    - asm/acpi.h for arch specific variables and functions needed by
>      ACPI driver core;
>    - acpi.c for ARM64 related ACPI implementation for ACPI driver
>      core;
>
> acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
> it will be called in setup_arch() before paging_init(), so we should
> use eary_memremap() mechanism here to get the RSDP and all the table
> pointers.
>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/acenv.h |   18 ++++++++++
>   arch/arm64/include/asm/acpi.h  |   41 ++++++++++++++++++++++
>   arch/arm64/include/asm/cpu.h   |   11 ++++++
>   arch/arm64/kernel/Makefile     |    1 +
>   arch/arm64/kernel/acpi.c       |   76 ++++++++++++++++++++++++++++++++++++++++
>   arch/arm64/kernel/setup.c      |    4 +++
>   6 files changed, 151 insertions(+)
>   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/cpu.h
>   create mode 100644 arch/arm64/kernel/acpi.c
>
> diff --git a/arch/arm64/include/asm/acenv.h b/arch/arm64/include/asm/acenv.h
> new file mode 100644
> index 0000000..3899ee6
> --- /dev/null
> +++ b/arch/arm64/include/asm/acenv.h
> @@ -0,0 +1,18 @@
> +/*
> + * ARM64 specific ACPICA environments and implementation
> + *
> + * Copyright (C) 2014, Linaro Ltd.
> + *   Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *   Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _ASM_ACENV_H
> +#define _ASM_ACENV_H
> +
> +#define ACPI_FLUSH_CPU_CACHE() WARN_ONCE(1, "Not currently supported on ARM64")
> +
> +#endif /* _ASM_ACENV_H */
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> new file mode 100644
> index 0000000..e8581ea
> --- /dev/null
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -0,0 +1,41 @@
> +/*
> + *  Copyright (C) 2013-2014, Linaro Ltd.
> + *     Author: Al Stone <al.stone@linaro.org>
> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation;
> + */
> +
> +#ifndef _ASM_ACPI_H
> +#define _ASM_ACPI_H
> +
> +/* Basic configuration for ACPI */
> +#ifdef CONFIG_ACPI
> +extern int acpi_disabled;
> +extern int acpi_noirq;
> +extern int acpi_pci_disabled;
> +extern int acpi_strict;

Until we need to enable workarounds, we should have acpi_strict
as macro rather than variable similar to IA64.

> +
> +static inline void disable_acpi(void)
> +{
> +       acpi_disabled = 1;
> +       acpi_pci_disabled = 1;
> +       acpi_noirq = 1;
> +}
> +
> +/*
> + * MADT must provide at least one GICC structure
> + * for GIC initialization, so CPU will be
> + * always available in MADT on ARM64
> + */
> +static inline bool acpi_has_cpu_in_madt(void)
> +{
> +       return 1;
> +}
> +

I don't see the user of this function in the series, it's better to
remove. Moreover the comment is so misleading. We will have CPU UID
not the CPU itself in MADT.

> +#endif /* CONFIG_ACPI */
> +
> +#endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
> new file mode 100644
> index 0000000..cee7d3f
> --- /dev/null
> +++ b/arch/arm64/include/asm/cpu.h
> @@ -0,0 +1,11 @@
> +/*
> + *  Copyright (C) 2013-2014 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef __ASM_CPU_H
> +#define __ASM_CPU_H
> +
> +#endif
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index cdaedad..b568c26 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o suspend.o
>   arm64-obj-$(CONFIG_JUMP_LABEL)         += jump_label.o
>   arm64-obj-$(CONFIG_KGDB)               += kgdb.o
>   arm64-obj-$(CONFIG_EFI)                        += efi.o efi-stub.o efi-entry.o
> +arm64-obj-$(CONFIG_ACPI)               += acpi.o
>
>   obj-y                                  += $(arm64-obj-y) vdso/
>   obj-m                                  += $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> new file mode 100644
> index 0000000..c62fce6
> --- /dev/null
> +++ b/arch/arm64/kernel/acpi.c
> @@ -0,0 +1,76 @@
> +/*
> + *  ARM64 Specific Low-Level ACPI Boot Support
> + *
> + *  Copyright (C) 2013-2014, Linaro Ltd.
> + *     Author: Al Stone <al.stone@linaro.org>
> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/acpi.h>
> +#include <linux/cpumask.h>
> +#include <linux/memblock.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/bootmem.h>
> +#include <linux/smp.h>
> +
> +/*
> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> + * variable is still required by the ACPI core
> + */
> +u32 acpi_rsdt_forced;

This looks like yet another stray variable not used anywhere including
core ACPI

> +
> +int acpi_noirq;                        /* skip ACPI IRQ initialization */
> +int acpi_strict;
> +int acpi_disabled;
> +EXPORT_SYMBOL(acpi_disabled);
> +
> +int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
> +EXPORT_SYMBOL(acpi_pci_disabled);
> +
> +/*
> + * __acpi_map_table() will be called before page_init(), so early_ioremap()
> + * or early_memremap() should be called here to for ACPI table mapping.
> + */
> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
> +{
> +       if (!phys || !size)
> +               return NULL;
> +
> +       return early_memremap(phys, size);
> +}
> +
> +void __init __acpi_unmap_table(char *map, unsigned long size)
> +{
> +       if (!map || !size)
> +               return;
> +
> +       early_iounmap(map, size);

Why not early_memunmap for consistency ?
Also now there's generic implementation of early mappings does it make
sense to move this also to acpi core ?

Regards,
Sudeep

Re: [PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> From: Al Stone <al.stone@linaro.org>
>
> As we want to get ACPI tables to parse and then use the information
> for system initialization, we should get the RSDP (Root System
> Description Pointer) first, it then locates Extended Root Description
> Table (XSDT) which contains all the 64-bit physical address that
> pointer to other boot-time tables.
>
> Introduce acpi.c and its related head file in this patch to provide
> fundamental needs of extern variables and functions for ACPI core,
> and then get boot-time tables as needed.
>    - asm/cpu.h need for ACPI core and will be updated in the future to
>      add definitions for arch_(un)register_cpu which are required for
>      ACPI based physical CPU hotplug;
>    - asm/acenv.h for arch specific ACPICA environments and
>      implementation;
>    - asm/acpi.h for arch specific variables and functions needed by
>      ACPI driver core;
>    - acpi.c for ARM64 related ACPI implementation for ACPI driver
>      core;
>
> acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
> it will be called in setup_arch() before paging_init(), so we should
> use eary_memremap() mechanism here to get the RSDP and all the table
> pointers.
>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/acenv.h |   18 ++++++++++
>   arch/arm64/include/asm/acpi.h  |   41 ++++++++++++++++++++++
>   arch/arm64/include/asm/cpu.h   |   11 ++++++
>   arch/arm64/kernel/Makefile     |    1 +
>   arch/arm64/kernel/acpi.c       |   76 ++++++++++++++++++++++++++++++++++++++++
>   arch/arm64/kernel/setup.c      |    4 +++
>   6 files changed, 151 insertions(+)
>   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/cpu.h
>   create mode 100644 arch/arm64/kernel/acpi.c
>
> diff --git a/arch/arm64/include/asm/acenv.h b/arch/arm64/include/asm/acenv.h
> new file mode 100644
> index 0000000..3899ee6
> --- /dev/null
> +++ b/arch/arm64/include/asm/acenv.h
> @@ -0,0 +1,18 @@
> +/*
> + * ARM64 specific ACPICA environments and implementation
> + *
> + * Copyright (C) 2014, Linaro Ltd.
> + *   Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *   Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _ASM_ACENV_H
> +#define _ASM_ACENV_H
> +
> +#define ACPI_FLUSH_CPU_CACHE() WARN_ONCE(1, "Not currently supported on ARM64")
> +
> +#endif /* _ASM_ACENV_H */
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> new file mode 100644
> index 0000000..e8581ea
> --- /dev/null
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -0,0 +1,41 @@
> +/*
> + *  Copyright (C) 2013-2014, Linaro Ltd.
> + *     Author: Al Stone <al.stone@linaro.org>
> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation;
> + */
> +
> +#ifndef _ASM_ACPI_H
> +#define _ASM_ACPI_H
> +
> +/* Basic configuration for ACPI */
> +#ifdef CONFIG_ACPI
> +extern int acpi_disabled;
> +extern int acpi_noirq;
> +extern int acpi_pci_disabled;
> +extern int acpi_strict;

Until we need to enable workarounds, we should have acpi_strict
as macro rather than variable similar to IA64.

> +
> +static inline void disable_acpi(void)
> +{
> +       acpi_disabled = 1;
> +       acpi_pci_disabled = 1;
> +       acpi_noirq = 1;
> +}
> +
> +/*
> + * MADT must provide at least one GICC structure
> + * for GIC initialization, so CPU will be
> + * always available in MADT on ARM64
> + */
> +static inline bool acpi_has_cpu_in_madt(void)
> +{
> +       return 1;
> +}
> +

I don't see the user of this function in the series, it's better to
remove. Moreover the comment is so misleading. We will have CPU UID
not the CPU itself in MADT.

> +#endif /* CONFIG_ACPI */
> +
> +#endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
> new file mode 100644
> index 0000000..cee7d3f
> --- /dev/null
> +++ b/arch/arm64/include/asm/cpu.h
> @@ -0,0 +1,11 @@
> +/*
> + *  Copyright (C) 2013-2014 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef __ASM_CPU_H
> +#define __ASM_CPU_H
> +
> +#endif
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index cdaedad..b568c26 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o suspend.o
>   arm64-obj-$(CONFIG_JUMP_LABEL)         += jump_label.o
>   arm64-obj-$(CONFIG_KGDB)               += kgdb.o
>   arm64-obj-$(CONFIG_EFI)                        += efi.o efi-stub.o efi-entry.o
> +arm64-obj-$(CONFIG_ACPI)               += acpi.o
>
>   obj-y                                  += $(arm64-obj-y) vdso/
>   obj-m                                  += $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> new file mode 100644
> index 0000000..c62fce6
> --- /dev/null
> +++ b/arch/arm64/kernel/acpi.c
> @@ -0,0 +1,76 @@
> +/*
> + *  ARM64 Specific Low-Level ACPI Boot Support
> + *
> + *  Copyright (C) 2013-2014, Linaro Ltd.
> + *     Author: Al Stone <al.stone@linaro.org>
> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/acpi.h>
> +#include <linux/cpumask.h>
> +#include <linux/memblock.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/bootmem.h>
> +#include <linux/smp.h>
> +
> +/*
> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> + * variable is still required by the ACPI core
> + */
> +u32 acpi_rsdt_forced;

This looks like yet another stray variable not used anywhere including
core ACPI

> +
> +int acpi_noirq;                        /* skip ACPI IRQ initialization */
> +int acpi_strict;
> +int acpi_disabled;
> +EXPORT_SYMBOL(acpi_disabled);
> +
> +int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
> +EXPORT_SYMBOL(acpi_pci_disabled);
> +
> +/*
> + * __acpi_map_table() will be called before page_init(), so early_ioremap()
> + * or early_memremap() should be called here to for ACPI table mapping.
> + */
> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
> +{
> +       if (!phys || !size)
> +               return NULL;
> +
> +       return early_memremap(phys, size);
> +}
> +
> +void __init __acpi_unmap_table(char *map, unsigned long size)
> +{
> +       if (!map || !size)
> +               return;
> +
> +       early_iounmap(map, size);

Why not early_memunmap for consistency ?
Also now there's generic implementation of early mappings does it make
sense to move this also to acpi core ?

Regards,
Sudeep

[PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> From: Al Stone <al.stone@linaro.org>
>
> As we want to get ACPI tables to parse and then use the information
> for system initialization, we should get the RSDP (Root System
> Description Pointer) first, it then locates Extended Root Description
> Table (XSDT) which contains all the 64-bit physical address that
> pointer to other boot-time tables.
>
> Introduce acpi.c and its related head file in this patch to provide
> fundamental needs of extern variables and functions for ACPI core,
> and then get boot-time tables as needed.
>    - asm/cpu.h need for ACPI core and will be updated in the future to
>      add definitions for arch_(un)register_cpu which are required for
>      ACPI based physical CPU hotplug;
>    - asm/acenv.h for arch specific ACPICA environments and
>      implementation;
>    - asm/acpi.h for arch specific variables and functions needed by
>      ACPI driver core;
>    - acpi.c for ARM64 related ACPI implementation for ACPI driver
>      core;
>
> acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
> it will be called in setup_arch() before paging_init(), so we should
> use eary_memremap() mechanism here to get the RSDP and all the table
> pointers.
>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/acenv.h |   18 ++++++++++
>   arch/arm64/include/asm/acpi.h  |   41 ++++++++++++++++++++++
>   arch/arm64/include/asm/cpu.h   |   11 ++++++
>   arch/arm64/kernel/Makefile     |    1 +
>   arch/arm64/kernel/acpi.c       |   76 ++++++++++++++++++++++++++++++++++++++++
>   arch/arm64/kernel/setup.c      |    4 +++
>   6 files changed, 151 insertions(+)
>   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/cpu.h
>   create mode 100644 arch/arm64/kernel/acpi.c
>
> diff --git a/arch/arm64/include/asm/acenv.h b/arch/arm64/include/asm/acenv.h
> new file mode 100644
> index 0000000..3899ee6
> --- /dev/null
> +++ b/arch/arm64/include/asm/acenv.h
> @@ -0,0 +1,18 @@
> +/*
> + * ARM64 specific ACPICA environments and implementation
> + *
> + * Copyright (C) 2014, Linaro Ltd.
> + *   Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *   Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef _ASM_ACENV_H
> +#define _ASM_ACENV_H
> +
> +#define ACPI_FLUSH_CPU_CACHE() WARN_ONCE(1, "Not currently supported on ARM64")
> +
> +#endif /* _ASM_ACENV_H */
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> new file mode 100644
> index 0000000..e8581ea
> --- /dev/null
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -0,0 +1,41 @@
> +/*
> + *  Copyright (C) 2013-2014, Linaro Ltd.
> + *     Author: Al Stone <al.stone@linaro.org>
> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation;
> + */
> +
> +#ifndef _ASM_ACPI_H
> +#define _ASM_ACPI_H
> +
> +/* Basic configuration for ACPI */
> +#ifdef CONFIG_ACPI
> +extern int acpi_disabled;
> +extern int acpi_noirq;
> +extern int acpi_pci_disabled;
> +extern int acpi_strict;

Until we need to enable workarounds, we should have acpi_strict
as macro rather than variable similar to IA64.

> +
> +static inline void disable_acpi(void)
> +{
> +       acpi_disabled = 1;
> +       acpi_pci_disabled = 1;
> +       acpi_noirq = 1;
> +}
> +
> +/*
> + * MADT must provide at least one GICC structure
> + * for GIC initialization, so CPU will be
> + * always available in MADT on ARM64
> + */
> +static inline bool acpi_has_cpu_in_madt(void)
> +{
> +       return 1;
> +}
> +

I don't see the user of this function in the series, it's better to
remove. Moreover the comment is so misleading. We will have CPU UID
not the CPU itself in MADT.

> +#endif /* CONFIG_ACPI */
> +
> +#endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
> new file mode 100644
> index 0000000..cee7d3f
> --- /dev/null
> +++ b/arch/arm64/include/asm/cpu.h
> @@ -0,0 +1,11 @@
> +/*
> + *  Copyright (C) 2013-2014 ARM Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef __ASM_CPU_H
> +#define __ASM_CPU_H
> +
> +#endif
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index cdaedad..b568c26 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o suspend.o
>   arm64-obj-$(CONFIG_JUMP_LABEL)         += jump_label.o
>   arm64-obj-$(CONFIG_KGDB)               += kgdb.o
>   arm64-obj-$(CONFIG_EFI)                        += efi.o efi-stub.o efi-entry.o
> +arm64-obj-$(CONFIG_ACPI)               += acpi.o
>
>   obj-y                                  += $(arm64-obj-y) vdso/
>   obj-m                                  += $(arm64-obj-m)
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> new file mode 100644
> index 0000000..c62fce6
> --- /dev/null
> +++ b/arch/arm64/kernel/acpi.c
> @@ -0,0 +1,76 @@
> +/*
> + *  ARM64 Specific Low-Level ACPI Boot Support
> + *
> + *  Copyright (C) 2013-2014, Linaro Ltd.
> + *     Author: Al Stone <al.stone@linaro.org>
> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2 as
> + *  published by the Free Software Foundation.
> + */
> +
> +#include <linux/init.h>
> +#include <linux/acpi.h>
> +#include <linux/cpumask.h>
> +#include <linux/memblock.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/bootmem.h>
> +#include <linux/smp.h>
> +
> +/*
> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
> + * variable is still required by the ACPI core
> + */
> +u32 acpi_rsdt_forced;

This looks like yet another stray variable not used anywhere including
core ACPI

> +
> +int acpi_noirq;                        /* skip ACPI IRQ initialization */
> +int acpi_strict;
> +int acpi_disabled;
> +EXPORT_SYMBOL(acpi_disabled);
> +
> +int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
> +EXPORT_SYMBOL(acpi_pci_disabled);
> +
> +/*
> + * __acpi_map_table() will be called before page_init(), so early_ioremap()
> + * or early_memremap() should be called here to for ACPI table mapping.
> + */
> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
> +{
> +       if (!phys || !size)
> +               return NULL;
> +
> +       return early_memremap(phys, size);
> +}
> +
> +void __init __acpi_unmap_table(char *map, unsigned long size)
> +{
> +       if (!map || !size)
> +               return;
> +
> +       early_iounmap(map, size);

Why not early_memunmap for consistency ?
Also now there's generic implementation of early mappings does it make
sense to move this also to acpi core ?

Regards,
Sudeep

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 10:36 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Jul 28, 2014 at 05:44:59PM +0100, Olof Johansson wrote:
>> On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
>> > Hi Olof,
>> >
>> > On Sun, Jul 27, 2014 at 03:34:48AM +0100, Olof Johansson wrote:
>> > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> > > > From: Graeme Gregory <graeme.gregory@linaro.org>
>> > > >
>> > > > Add documentation for the guidelines of how to use ACPI
>> > > > on ARM64.
>> > >
>> > > As the most vocal participant against ACPI being adopted, I would have
>> > > appreciated a cc on this patch set -- it's not like you were going for
>> > > a minimal set of cc recipients already. It makes it seem like you're
>> > > trying to sneak it past me for comments. Not cool. I know that's
>> > > probably not your intent, but still.
>> > >
>> > > Some comments below. Overall the doc looks pretty good, but the
>> > > details about _DSD and clocks are somewhat worrisome.
>> > >
>> > > > Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> > > > Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> > > > ---
>> > > >  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>> > > >  1 file changed, 240 insertions(+)
>> > > >  create mode 100644 Documentation/arm64/arm-acpi.txt
>> > > >
>> > > > diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
>> > > > new file mode 100644
>> > > > index 0000000..12cd550
>> > > > --- /dev/null
>> > > > +++ b/Documentation/arm64/arm-acpi.txt
>> > > > @@ -0,0 +1,240 @@
>> > > > +ACPI on ARMv8 Servers
>> > > > +---------------------
>> > > > +
>> > > > +ACPI will be used for ARMv8 general purpose servers designed to follow
>> > >
>> > > "ACPI might be used"    or     "can be used"
>> > >
>> > > > +the SBSA specification (currently available to people with an ARM login at
>> > > > +http://silver.arm.com)
>> > > > +
>> > > > +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
>> > > > +which is available at <http://www.uefi.org/acpi/specs>.
>> > >
>> > > The implemented version where? The kernel implements that version?
>> > > Worth clarifying.
>> > >
>> > > > +If the machine does not meet these requirements then it is likely that Device
>> > > > +Tree (DT) is more suitable for the hardware.
>> > >
>> > > This is should be a very clear statement that is currently vague
>> > > w.r.t. which requirements are met or not, especially based on the
>> > > sentence above.
>> > >
>> > > > +Relationship with Device Tree
>> > > > +-----------------------------
>> > > > +
>> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>> > > > +exclusive with DT support at compile time.
>> > > > +
>> > > > +At boot time the kernel will only use one description method depending on
>> > > > +parameters passed from the bootloader.
>> > >
>> > > Possibly overriden by kernel bootargs. And as debated for quite a
>> > > while earlier this year, acpi should still default to off -- if a DT
>> > > and ACPI are both passed in, DT should at this time be given priority.
>> >
>> > Why? I really don't see the logic in doing that.
>>
>> Seems like I am replying to your emails in reverse order.
>
> Oh well; it makes the discussion more fun to read :)
>
>> > Currently the kernel can only boot using DT, so DT will be used even if
>> > ACPI is present. In the presence of ACPI support in the kernel, ACPI
>> > would be used on said systems.
>>
>> For all the reasons we hashed out earlier this year: We can't trust that
>> vendors will know how to do ACPI from day one, so instead of loading up the
>> kernel with lots of quirks and workarounds, we'll default to not using it until
>> we're at a point where things look mature enough.
>
> I am not arguing for quirks and workarounds.
>
> What I would like to see is for the kernel barf horrifically right now
> on even slightly dodgy ACPI implementations before they are out in the
> wild. Otherwise the later switching on of ACPI support is what will
> necessitate workarounds for said systems.

That's the job of a compliance test suite, not of the Linux kernel.
We're here to make systems usable and ship a computing environment
that people can use to get work done. We're not a bringup tool and a
test suite.

Turning it on by option means that those who want to test it can do
so. I'd be happy to do both acpi and non-acpi boots of my boot farm,
for example, if anyone ever sends me 64-bit hardware for it.

>> The alternative is to keep this patch set out of the kernel. We can do that
>> too, but I don't think that really helps anyone.
>
> That's just another way of disabling it by default. IMO that's worse
> because only a subset of people will discover how broken their ACPI
> implementation is.

Yes, I think that's worse too. I don't want to do that, but if people
aren't listening to reason on why it can be merged as long as it's
disabled by default, then not merging it is the answer.

>> > From the discussions at the last Linaro Connect, this was seen as
>> > important for virtual machines which want to provide ACPI services to
>> > guests while still being able to boot DT-only kernels. I'll leave it to
>> > Grant, Rob, and Christoffer to cover that.
>>
>> Ok, waiting to see what they have to say then.
>>
>> > > (Where can I learn more about how the boot loaders currently handle
>> > > this? Do some of them pass in both DT and ACPI on some platforms, for
>> > > example?)
>> >
>> > All will pass in some form of DT. If booted through UEFI, the DT will be
>> > augmented with data about the UEFI memory map (and if no DT is provided,
>> > a /chosen only DT will eb created by the EFI stub).
>>
>> The in-kernel EFI stub?
>
> Yes. If a kernel with the stub is booted as an EFI application, the stub
> code will be executed and augment / create a DTB with handles for the
> UEFI memory map.
>
> There is a tight coupling between the stub and the kernel. Only the stub
> is able to do this currently.

Ok, just making clear in case the common bootloaders had their own
functionality for the same.

>> > A kernel with ACPI support will query EFI for ACPI tables, and if found
>> > use them.
>> >
>> > > > +Regardless of whether DT or ACPI is used, the kernel must always be capable
>> > > > +of booting with either scheme.
>> > >
>> > > It should always be possible to compile out ACPI. There will be plenty
>> > > of platforms that will not implement it, so disabling CONFIG_ACPI
>> > > needs to be possible.
>> >
>> > A better description would be that the two must never be mutually
>> > exclusive. It must always be possible to have a kernel which supports
>> > both, and code must never assume the absence of the other.
>>
>> No. "Not mutually exclusive" and "possible to turn off one of them" is not the
>> same thing.
>
> I think we're talking cross purposes. Those sentences are indeed not
> equivalent. We want two things:
>
> 1) A single kernel image must be able to support both ACPI and DT.
>
> 2) It must be possible to build a kernel supporting only DT.
>
> Of the two (1) is the most important, or single image is dead. That does
> not mean that (2) is not important, but it is an optimisation to remove
> unused code and save on size.
>
> Any wording we have here must express both these points.

Yes, agreed (1) is clearly stated elsewhere, it's the (2) portion that
needs to be reflected in the docs, which was what my initial comment
was as well. Then you took it for a drive around the block with your
"not mutually exclusive" comment. Now we're back where we started.

>> > At run time, the kernel will decide to use one for system description
>> > and use that.
>> >
>> > [...]
>> >
>> > > > +Device Enumeration
>> > > > +------------------
>> > > > +
>> > > > +Device descriptions in ACPI should use standard recognised ACPI interfaces.
>> > > > +These are far simpler than the information provided via Device Tree. Drivers
>> > > > +should take into account this simplicity and work with sensible defaults.
>> > > > +
>> > > > +On no account should a Device Tree attempt to be replicated in ASL using such
>> > > > +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
>> > > > +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
>> > > > +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
>> > >
>> > > I see these two sentences as contradictory, given that the _DSD doc
>> > > linked below contains examples that mirror over several properties,
>> > > such as "linux,default-trigger" and other LED-specific properties.
>> > > (section 2.4.2 in the below doc). "default-state" seems to come from
>> > > DT too?
>> >
>> > Urrgh. Those should never been placed in the ACPI spec. It's bad enough
>> > in DT.
>>
>> +1
>>
>> > > Care to elaborate and explain what the intention here is? This could
>> > > worst case turn into quite a mess.
>> > >
>> > > Given that ACPI can present completely different data based on what OS
>> > > is running, it's quite common to indeed have OS specific data in
>> > > there. How does that relate to this document and these practices?
>> > >
>> > > > +Common _DSD bindings should be submitted to ASWG to be included in the
>> > > > +document :-
>> > > > +
>> > > > +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
>> > >
>> > > So, for these that are a mirror of the device tree bindings, there
>> > > needs to be a wording here around reviewing the DT binding first so we
>> > > don't get diverging bindings.
>> >
>> > We shouldn't work on the assumption that the two should be identical.
>> > ACPI already has standard mechanisms for describing certain linkages
>> > that are divergent from DT.
>>
>> I can't tell what is worse, identical mirroring over into DT of FDT (and the
>> lack of being able to fix it up in case of description bugs) or _DSD doing
>> things subtly different and now the kernel needs to handle both variants.
>
> ACPI and DT are already doing different things. It's fine to do the same
> thing where it makes sense to, but we shouldn't go for a false
> equivalence here.
>
>> > This really needs higher-level thought, and I'd hoped that things
>> > wouldn't blindly be copied one way or the other.
>>
>> Agreed. Besides, the whole idea of ACPI is to not have to model clocks. Sigh.
>
> Well, maybe not the _whole_ idea. I hear ACPI actually tries to model
> other devices...

One of the most significant reasons for ACPI is to abstract away the
hardware such that the kernel doesn't have to bother about knowing
intimate details about it, such as clock trees. We can discuss this
some more if you want, but I've got other work to do.

>> > [...]
>> >
>> > > > +values before the kernel is executed. If a driver requires to know rates of
>> > > > +clocks set by firmware then they can be passed to kernel using _DSD.
>> > > > +
>> > > > +example :-
>> > > > +
>> > > > +Device (CLK0) {
>> > > > +       ...
>> > > > +
>> > > > +       Name (_DSD, Package() {
>> > > > +               ToUUID("XXXXX"),
>> > > > +               Package() {
>> > > > +                       Package(2) {"#clock-cells", 0},
>> > >
>> > > Clock-cells? What do they mean here? Is this specified in the ACPI
>> > > standards? I had to register to get access to it, and didn't feel like
>> > > doing that right now. I guess it's not _all_ that open a spec. :(
>> >
>> > Yeah, this is complete nonsense.
>> >
>> > If people are going to blindly copy elements from DT into ACPI without
>> > actually understanding them, then ACPI is clearly no better than DT.
>> >
>> > [...]
>> >
>> > > > +static int device_probe(stuct platform_device *pdev)
>> > > > +{
>> > > > +       ...
>> > > > +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
>> > > > +       struct device_node node = pdev->dev.of_node;
>> > > > +       ...
>> > > > +
>> > > > +       if (node)
>> > > > +               ret = device_probe_dt(pdev);
>> > > > +       else if (handle)
>> > > > +               ret = device_probe_acpi(pdev);
>> > > > +       else
>> > > > +               /* other initialisation */
>> > > > +               ...
>> > > > +       /* Continue with any generic probe operations */
>> > > > +       ...
>> > > > +}
>> > >
>> > > This looks good to me, and it's also my preferred way of ACPI-enabling
>> > > drivers. I guess we might discuss this at KS since it was a proposed
>> > > topic there, and others will object. :)
>> >
>> > This is almost precisely the form of probe I want to see (it would be
>> > nicer IMO to have separate entry points for ACPI / DT / platform data
>> > that can all call a common probe core, but this isn't too far off).
>>
>> I disagree, but it's also not something we're looking to change at this time.
>> We'll take that debate when you post the patches changing how device probing
>> works. :-)
>
> Sure :)
>
> Cheers,
> Mark.
>
>> > > > +
>> > > > +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
>> > > > +the different names the driver is probed for, both from DT and from ACPI.
>> > > > +
>> > > > +module device tables :-
>> > > > +
>> > > > +static struct of_device_id virtio_mmio_match[] = {
>> > > > +        { .compatible = "virtio,mmio", },
>> > > > +        {},
>> > > > +};
>> > > > +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
>> > > > +
>> > > > +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
>> > > > +        { "LNRO0005", },
>> > > > +        { }
>> > >
>> > > No comma here, but a comma on DT. Probably make them equivalent for
>> > > consistency (including space between the braces).
>> >
>> > The comma on the DT form should probably be dropped. The NULL sentinel's
>> > only job is to delimit the list, so it never makes sense to place
>> > something after it.
>>
>> Yep.
>>
>>
>> -Olof
>>

[PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 10:36 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Jul 28, 2014 at 05:44:59PM +0100, Olof Johansson wrote:
>> On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
>> > Hi Olof,
>> >
>> > On Sun, Jul 27, 2014 at 03:34:48AM +0100, Olof Johansson wrote:
>> > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> > > > From: Graeme Gregory <graeme.gregory@linaro.org>
>> > > >
>> > > > Add documentation for the guidelines of how to use ACPI
>> > > > on ARM64.
>> > >
>> > > As the most vocal participant against ACPI being adopted, I would have
>> > > appreciated a cc on this patch set -- it's not like you were going for
>> > > a minimal set of cc recipients already. It makes it seem like you're
>> > > trying to sneak it past me for comments. Not cool. I know that's
>> > > probably not your intent, but still.
>> > >
>> > > Some comments below. Overall the doc looks pretty good, but the
>> > > details about _DSD and clocks are somewhat worrisome.
>> > >
>> > > > Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> > > > Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> > > > ---
>> > > >  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>> > > >  1 file changed, 240 insertions(+)
>> > > >  create mode 100644 Documentation/arm64/arm-acpi.txt
>> > > >
>> > > > diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
>> > > > new file mode 100644
>> > > > index 0000000..12cd550
>> > > > --- /dev/null
>> > > > +++ b/Documentation/arm64/arm-acpi.txt
>> > > > @@ -0,0 +1,240 @@
>> > > > +ACPI on ARMv8 Servers
>> > > > +---------------------
>> > > > +
>> > > > +ACPI will be used for ARMv8 general purpose servers designed to follow
>> > >
>> > > "ACPI might be used"    or     "can be used"
>> > >
>> > > > +the SBSA specification (currently available to people with an ARM login at
>> > > > +http://silver.arm.com)
>> > > > +
>> > > > +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
>> > > > +which is available at <http://www.uefi.org/acpi/specs>.
>> > >
>> > > The implemented version where? The kernel implements that version?
>> > > Worth clarifying.
>> > >
>> > > > +If the machine does not meet these requirements then it is likely that Device
>> > > > +Tree (DT) is more suitable for the hardware.
>> > >
>> > > This is should be a very clear statement that is currently vague
>> > > w.r.t. which requirements are met or not, especially based on the
>> > > sentence above.
>> > >
>> > > > +Relationship with Device Tree
>> > > > +-----------------------------
>> > > > +
>> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>> > > > +exclusive with DT support at compile time.
>> > > > +
>> > > > +At boot time the kernel will only use one description method depending on
>> > > > +parameters passed from the bootloader.
>> > >
>> > > Possibly overriden by kernel bootargs. And as debated for quite a
>> > > while earlier this year, acpi should still default to off -- if a DT
>> > > and ACPI are both passed in, DT should at this time be given priority.
>> >
>> > Why? I really don't see the logic in doing that.
>>
>> Seems like I am replying to your emails in reverse order.
>
> Oh well; it makes the discussion more fun to read :)
>
>> > Currently the kernel can only boot using DT, so DT will be used even if
>> > ACPI is present. In the presence of ACPI support in the kernel, ACPI
>> > would be used on said systems.
>>
>> For all the reasons we hashed out earlier this year: We can't trust that
>> vendors will know how to do ACPI from day one, so instead of loading up the
>> kernel with lots of quirks and workarounds, we'll default to not using it until
>> we're at a point where things look mature enough.
>
> I am not arguing for quirks and workarounds.
>
> What I would like to see is for the kernel barf horrifically right now
> on even slightly dodgy ACPI implementations before they are out in the
> wild. Otherwise the later switching on of ACPI support is what will
> necessitate workarounds for said systems.

That's the job of a compliance test suite, not of the Linux kernel.
We're here to make systems usable and ship a computing environment
that people can use to get work done. We're not a bringup tool and a
test suite.

Turning it on by option means that those who want to test it can do
so. I'd be happy to do both acpi and non-acpi boots of my boot farm,
for example, if anyone ever sends me 64-bit hardware for it.

>> The alternative is to keep this patch set out of the kernel. We can do that
>> too, but I don't think that really helps anyone.
>
> That's just another way of disabling it by default. IMO that's worse
> because only a subset of people will discover how broken their ACPI
> implementation is.

Yes, I think that's worse too. I don't want to do that, but if people
aren't listening to reason on why it can be merged as long as it's
disabled by default, then not merging it is the answer.

>> > From the discussions at the last Linaro Connect, this was seen as
>> > important for virtual machines which want to provide ACPI services to
>> > guests while still being able to boot DT-only kernels. I'll leave it to
>> > Grant, Rob, and Christoffer to cover that.
>>
>> Ok, waiting to see what they have to say then.
>>
>> > > (Where can I learn more about how the boot loaders currently handle
>> > > this? Do some of them pass in both DT and ACPI on some platforms, for
>> > > example?)
>> >
>> > All will pass in some form of DT. If booted through UEFI, the DT will be
>> > augmented with data about the UEFI memory map (and if no DT is provided,
>> > a /chosen only DT will eb created by the EFI stub).
>>
>> The in-kernel EFI stub?
>
> Yes. If a kernel with the stub is booted as an EFI application, the stub
> code will be executed and augment / create a DTB with handles for the
> UEFI memory map.
>
> There is a tight coupling between the stub and the kernel. Only the stub
> is able to do this currently.

Ok, just making clear in case the common bootloaders had their own
functionality for the same.

>> > A kernel with ACPI support will query EFI for ACPI tables, and if found
>> > use them.
>> >
>> > > > +Regardless of whether DT or ACPI is used, the kernel must always be capable
>> > > > +of booting with either scheme.
>> > >
>> > > It should always be possible to compile out ACPI. There will be plenty
>> > > of platforms that will not implement it, so disabling CONFIG_ACPI
>> > > needs to be possible.
>> >
>> > A better description would be that the two must never be mutually
>> > exclusive. It must always be possible to have a kernel which supports
>> > both, and code must never assume the absence of the other.
>>
>> No. "Not mutually exclusive" and "possible to turn off one of them" is not the
>> same thing.
>
> I think we're talking cross purposes. Those sentences are indeed not
> equivalent. We want two things:
>
> 1) A single kernel image must be able to support both ACPI and DT.
>
> 2) It must be possible to build a kernel supporting only DT.
>
> Of the two (1) is the most important, or single image is dead. That does
> not mean that (2) is not important, but it is an optimisation to remove
> unused code and save on size.
>
> Any wording we have here must express both these points.

Yes, agreed (1) is clearly stated elsewhere, it's the (2) portion that
needs to be reflected in the docs, which was what my initial comment
was as well. Then you took it for a drive around the block with your
"not mutually exclusive" comment. Now we're back where we started.

>> > At run time, the kernel will decide to use one for system description
>> > and use that.
>> >
>> > [...]
>> >
>> > > > +Device Enumeration
>> > > > +------------------
>> > > > +
>> > > > +Device descriptions in ACPI should use standard recognised ACPI interfaces.
>> > > > +These are far simpler than the information provided via Device Tree. Drivers
>> > > > +should take into account this simplicity and work with sensible defaults.
>> > > > +
>> > > > +On no account should a Device Tree attempt to be replicated in ASL using such
>> > > > +constructs as Name(KEY0, "Value1") type constructs. Additional driver specific
>> > > > +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
>> > > > +_DSD (ACPI Section 6.2.5). This data should be rare and not OS specific.
>> > >
>> > > I see these two sentences as contradictory, given that the _DSD doc
>> > > linked below contains examples that mirror over several properties,
>> > > such as "linux,default-trigger" and other LED-specific properties.
>> > > (section 2.4.2 in the below doc). "default-state" seems to come from
>> > > DT too?
>> >
>> > Urrgh. Those should never been placed in the ACPI spec. It's bad enough
>> > in DT.
>>
>> +1
>>
>> > > Care to elaborate and explain what the intention here is? This could
>> > > worst case turn into quite a mess.
>> > >
>> > > Given that ACPI can present completely different data based on what OS
>> > > is running, it's quite common to indeed have OS specific data in
>> > > there. How does that relate to this document and these practices?
>> > >
>> > > > +Common _DSD bindings should be submitted to ASWG to be included in the
>> > > > +document :-
>> > > > +
>> > > > +http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
>> > >
>> > > So, for these that are a mirror of the device tree bindings, there
>> > > needs to be a wording here around reviewing the DT binding first so we
>> > > don't get diverging bindings.
>> >
>> > We shouldn't work on the assumption that the two should be identical.
>> > ACPI already has standard mechanisms for describing certain linkages
>> > that are divergent from DT.
>>
>> I can't tell what is worse, identical mirroring over into DT of FDT (and the
>> lack of being able to fix it up in case of description bugs) or _DSD doing
>> things subtly different and now the kernel needs to handle both variants.
>
> ACPI and DT are already doing different things. It's fine to do the same
> thing where it makes sense to, but we shouldn't go for a false
> equivalence here.
>
>> > This really needs higher-level thought, and I'd hoped that things
>> > wouldn't blindly be copied one way or the other.
>>
>> Agreed. Besides, the whole idea of ACPI is to not have to model clocks. Sigh.
>
> Well, maybe not the _whole_ idea. I hear ACPI actually tries to model
> other devices...

One of the most significant reasons for ACPI is to abstract away the
hardware such that the kernel doesn't have to bother about knowing
intimate details about it, such as clock trees. We can discuss this
some more if you want, but I've got other work to do.

>> > [...]
>> >
>> > > > +values before the kernel is executed. If a driver requires to know rates of
>> > > > +clocks set by firmware then they can be passed to kernel using _DSD.
>> > > > +
>> > > > +example :-
>> > > > +
>> > > > +Device (CLK0) {
>> > > > +       ...
>> > > > +
>> > > > +       Name (_DSD, Package() {
>> > > > +               ToUUID("XXXXX"),
>> > > > +               Package() {
>> > > > +                       Package(2) {"#clock-cells", 0},
>> > >
>> > > Clock-cells? What do they mean here? Is this specified in the ACPI
>> > > standards? I had to register to get access to it, and didn't feel like
>> > > doing that right now. I guess it's not _all_ that open a spec. :(
>> >
>> > Yeah, this is complete nonsense.
>> >
>> > If people are going to blindly copy elements from DT into ACPI without
>> > actually understanding them, then ACPI is clearly no better than DT.
>> >
>> > [...]
>> >
>> > > > +static int device_probe(stuct platform_device *pdev)
>> > > > +{
>> > > > +       ...
>> > > > +       acpi_handle handle = ACPI_HANDLE(&pdev->dev);
>> > > > +       struct device_node node = pdev->dev.of_node;
>> > > > +       ...
>> > > > +
>> > > > +       if (node)
>> > > > +               ret = device_probe_dt(pdev);
>> > > > +       else if (handle)
>> > > > +               ret = device_probe_acpi(pdev);
>> > > > +       else
>> > > > +               /* other initialisation */
>> > > > +               ...
>> > > > +       /* Continue with any generic probe operations */
>> > > > +       ...
>> > > > +}
>> > >
>> > > This looks good to me, and it's also my preferred way of ACPI-enabling
>> > > drivers. I guess we might discuss this at KS since it was a proposed
>> > > topic there, and others will object. :)
>> >
>> > This is almost precisely the form of probe I want to see (it would be
>> > nicer IMO to have separate entry points for ACPI / DT / platform data
>> > that can all call a common probe core, but this isn't too far off).
>>
>> I disagree, but it's also not something we're looking to change at this time.
>> We'll take that debate when you post the patches changing how device probing
>> works. :-)
>
> Sure :)
>
> Cheers,
> Mark.
>
>> > > > +
>> > > > +DO keep the MODULE_DEVICE_TABLE entries together in the driver to make it clear
>> > > > +the different names the driver is probed for, both from DT and from ACPI.
>> > > > +
>> > > > +module device tables :-
>> > > > +
>> > > > +static struct of_device_id virtio_mmio_match[] = {
>> > > > +        { .compatible = "virtio,mmio", },
>> > > > +        {},
>> > > > +};
>> > > > +MODULE_DEVICE_TABLE(of, virtio_mmio_match);
>> > > > +
>> > > > +static const struct acpi_device_id virtio_mmio_acpi_match[] = {
>> > > > +        { "LNRO0005", },
>> > > > +        { }
>> > >
>> > > No comma here, but a comma on DT. Probably make them equivalent for
>> > > consistency (including space between the braces).
>> >
>> > The comma on the DT form should probably be dropped. The NULL sentinel's
>> > only job is to delimit the list, so it never makes sense to place
>> > something after it.
>>
>> Yep.
>>
>>
>> -Olof
>>

Re: [PATCH 02/19] ARM64 / ACPI: Introduce early_param for "acpi"

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> From: Al Stone <al.stone@linaro.org>
>
> Introduce two early parameters for "acpi", one is the parameter
> to disable ACPI on ARM64 and another one is acpi=strict to disable
> out-of-spec workarounds.
>
> Reviewed-by: Grant Likely <grant.likely@linaro.org>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   Documentation/kernel-parameters.txt |    3 ++-
>   arch/arm64/kernel/acpi.c            |   21 +++++++++++++++++++++
>   2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index b7fa2f5..d130bd5 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -165,7 +165,7 @@ multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 2^20, and 2^30
>   bytes respectively. Such letter suffixes can also be entirely omitted.
>
>
> -	acpi=		[HW,ACPI,X86]
> +	acpi=		[HW,ACPI,X86,ARM]
>   			Advanced Configuration and Power Interface
>   			Format: { force | off | strict | noirq | rsdt }
>   			force -- enable ACPI if default was off
> @@ -175,6 +175,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>   				strictly ACPI specification compliant.
>   			rsdt -- prefer RSDT over (default) XSDT
>   			copy_dsdt -- copy DSDT to memory
> +			For ARM64, ONLY "off" and "strict" are available.
>
>   			See also Documentation/power/runtime_pm.txt, pci=noacpi
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index c62fce6..ac78e4e 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -74,3 +74,24 @@ void __init acpi_boot_table_init(void)
>   		return;
>   	}
>   }
> +
> +static int __init parse_acpi(char *arg)
> +{
> +	if (!arg)
> +		return -EINVAL;
> +
> +	/* "acpi=off" disables both ACPI table parsing and interpreter */
> +	if (strcmp(arg, "off") == 0) {
> +		disable_acpi();
> +	}
> +	/* acpi=strict disables out-of-spec workarounds */
> +	else if (strcmp(arg, "strict") == 0) {
> +		acpi_strict = 1;

This should be default set as I mentioned in patch#1. We can introduce
this option if required in future.

Regards,
Sudeep

Re: [PATCH 02/19] ARM64 / ACPI: Introduce early_param for "acpi"

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> From: Al Stone <al.stone@linaro.org>
>
> Introduce two early parameters for "acpi", one is the parameter
> to disable ACPI on ARM64 and another one is acpi=strict to disable
> out-of-spec workarounds.
>
> Reviewed-by: Grant Likely <grant.likely@linaro.org>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   Documentation/kernel-parameters.txt |    3 ++-
>   arch/arm64/kernel/acpi.c            |   21 +++++++++++++++++++++
>   2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index b7fa2f5..d130bd5 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -165,7 +165,7 @@ multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 2^20, and 2^30
>   bytes respectively. Such letter suffixes can also be entirely omitted.
>
>
> -	acpi=		[HW,ACPI,X86]
> +	acpi=		[HW,ACPI,X86,ARM]
>   			Advanced Configuration and Power Interface
>   			Format: { force | off | strict | noirq | rsdt }
>   			force -- enable ACPI if default was off
> @@ -175,6 +175,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>   				strictly ACPI specification compliant.
>   			rsdt -- prefer RSDT over (default) XSDT
>   			copy_dsdt -- copy DSDT to memory
> +			For ARM64, ONLY "off" and "strict" are available.
>
>   			See also Documentation/power/runtime_pm.txt, pci=noacpi
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index c62fce6..ac78e4e 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -74,3 +74,24 @@ void __init acpi_boot_table_init(void)
>   		return;
>   	}
>   }
> +
> +static int __init parse_acpi(char *arg)
> +{
> +	if (!arg)
> +		return -EINVAL;
> +
> +	/* "acpi=off" disables both ACPI table parsing and interpreter */
> +	if (strcmp(arg, "off") == 0) {
> +		disable_acpi();
> +	}
> +	/* acpi=strict disables out-of-spec workarounds */
> +	else if (strcmp(arg, "strict") == 0) {
> +		acpi_strict = 1;

This should be default set as I mentioned in patch#1. We can introduce
this option if required in future.

Regards,
Sudeep

[PATCH 02/19] ARM64 / ACPI: Introduce early_param for "acpi"

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> From: Al Stone <al.stone@linaro.org>
>
> Introduce two early parameters for "acpi", one is the parameter
> to disable ACPI on ARM64 and another one is acpi=strict to disable
> out-of-spec workarounds.
>
> Reviewed-by: Grant Likely <grant.likely@linaro.org>
> Signed-off-by: Al Stone <al.stone@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   Documentation/kernel-parameters.txt |    3 ++-
>   arch/arm64/kernel/acpi.c            |   21 +++++++++++++++++++++
>   2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index b7fa2f5..d130bd5 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -165,7 +165,7 @@ multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 2^20, and 2^30
>   bytes respectively. Such letter suffixes can also be entirely omitted.
>
>
> -	acpi=		[HW,ACPI,X86]
> +	acpi=		[HW,ACPI,X86,ARM]
>   			Advanced Configuration and Power Interface
>   			Format: { force | off | strict | noirq | rsdt }
>   			force -- enable ACPI if default was off
> @@ -175,6 +175,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>   				strictly ACPI specification compliant.
>   			rsdt -- prefer RSDT over (default) XSDT
>   			copy_dsdt -- copy DSDT to memory
> +			For ARM64, ONLY "off" and "strict" are available.
>
>   			See also Documentation/power/runtime_pm.txt, pci=noacpi
>
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index c62fce6..ac78e4e 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -74,3 +74,24 @@ void __init acpi_boot_table_init(void)
>   		return;
>   	}
>   }
> +
> +static int __init parse_acpi(char *arg)
> +{
> +	if (!arg)
> +		return -EINVAL;
> +
> +	/* "acpi=off" disables both ACPI table parsing and interpreter */
> +	if (strcmp(arg, "off") == 0) {
> +		disable_acpi();
> +	}
> +	/* acpi=strict disables out-of-spec workarounds */
> +	else if (strcmp(arg, "strict") == 0) {
> +		acpi_strict = 1;

This should be default set as I mentioned in patch#1. We can introduce
this option if required in future.

Regards,
Sudeep

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Mon, Jul 28, 2014 at 05:33:13PM +0100, Olof Johansson wrote:
> On Mon, Jul 28, 2014 at 11:12:29AM +0100, Mark Rutland wrote:
> > On Mon, Jul 28, 2014 at 10:07:50AM +0100, Arnd Bergmann wrote:
> > > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> > > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > > > +Relationship with Device Tree
> > > > > +-----------------------------
> > > > > +
> > > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > > > +exclusive with DT support at compile time.
> > > > > +
> > > > > +At boot time the kernel will only use one description method depending on
> > > > > +parameters passed from the bootloader.
> > > > 
> > > > Possibly overriden by kernel bootargs. And as debated for quite a
> > > > while earlier this year, acpi should still default to off -- if a DT
> > > > and ACPI are both passed in, DT should at this time be given priority.
> > > 
> > > I think this would be harder to do with the way that ACPI is passed in
> > > to the kernel. IIRC, you always have a minimal DT information based on
> > > the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> > > to the ACPI tables, which are then used for populating the Linux platform
> > > devices (unless acpi=disabled is set), while the other contents of the
> > > DTB may be present but we skip the of_platform_populate state.
> > > 
> > > If this is correct, then replacing the firmware-generated dtb with a
> > > user-provided on would implicitly remove the ACPI tables from visibility,
> > > which is exactly what we want.
> > 
> > That's not quite true.
> > 
> > There might not be any DTB, or the user might have provided a DTB with
> > only /chosen/bootargs. Trying to distinguish the many cases of possible
> > DTB is broken as a concept.
> > 
> > The EFI stub will attempt to get a DTB from somewhere (provided by
> > filename or as a system table with a magic UUID), and if it can't find
> > one will generate an empty stub DTB.
> > 
> > Then it will go and perform some EFI memory setup, placing some
> > properties in the DTB (which might be a stub) describing the EFI memory
> > map.
> > 
> > Then we boot the kernel proper, which sees the EFI pointers and looks
> > for an ACPI table. If they are found, ACPI is used. Otherwise we attempt
> > to use the DTB (which might be a stub).
> > 
> > Unless ACPI is explcitly disabled, ACPI will be used if present.
> 
> Ah, I saw this after I replied to Arnd's email.
> 
> The above sounds more like how I envisioned things working, so based on that,
> the default just needs to be flipped and we should be fine (i.e. ACPI needs to
> be explicitly enabled).

Sorry, but I don't follow your reasoning. What is the rationale for
disabling ACPI by default?

That's not going to work for ACPI-only systems which may not have any HW
described in a DTB. I fear it will result in more pain on any systems
which try to ship both ACPI and DT, where ACPI will not get the testing
it requires, leading to a greater possibility of quirks/workarounds
being required later.

Thanks,
Mark.

[PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Mon, Jul 28, 2014 at 05:33:13PM +0100, Olof Johansson wrote:
> On Mon, Jul 28, 2014 at 11:12:29AM +0100, Mark Rutland wrote:
> > On Mon, Jul 28, 2014 at 10:07:50AM +0100, Arnd Bergmann wrote:
> > > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> > > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > > > +Relationship with Device Tree
> > > > > +-----------------------------
> > > > > +
> > > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > > > +exclusive with DT support at compile time.
> > > > > +
> > > > > +At boot time the kernel will only use one description method depending on
> > > > > +parameters passed from the bootloader.
> > > > 
> > > > Possibly overriden by kernel bootargs. And as debated for quite a
> > > > while earlier this year, acpi should still default to off -- if a DT
> > > > and ACPI are both passed in, DT should at this time be given priority.
> > > 
> > > I think this would be harder to do with the way that ACPI is passed in
> > > to the kernel. IIRC, you always have a minimal DT information based on
> > > the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> > > to the ACPI tables, which are then used for populating the Linux platform
> > > devices (unless acpi=disabled is set), while the other contents of the
> > > DTB may be present but we skip the of_platform_populate state.
> > > 
> > > If this is correct, then replacing the firmware-generated dtb with a
> > > user-provided on would implicitly remove the ACPI tables from visibility,
> > > which is exactly what we want.
> > 
> > That's not quite true.
> > 
> > There might not be any DTB, or the user might have provided a DTB with
> > only /chosen/bootargs. Trying to distinguish the many cases of possible
> > DTB is broken as a concept.
> > 
> > The EFI stub will attempt to get a DTB from somewhere (provided by
> > filename or as a system table with a magic UUID), and if it can't find
> > one will generate an empty stub DTB.
> > 
> > Then it will go and perform some EFI memory setup, placing some
> > properties in the DTB (which might be a stub) describing the EFI memory
> > map.
> > 
> > Then we boot the kernel proper, which sees the EFI pointers and looks
> > for an ACPI table. If they are found, ACPI is used. Otherwise we attempt
> > to use the DTB (which might be a stub).
> > 
> > Unless ACPI is explcitly disabled, ACPI will be used if present.
> 
> Ah, I saw this after I replied to Arnd's email.
> 
> The above sounds more like how I envisioned things working, so based on that,
> the default just needs to be flipped and we should be fine (i.e. ACPI needs to
> be explicitly enabled).

Sorry, but I don't follow your reasoning. What is the rationale for
disabling ACPI by default?

That's not going to work for ACPI-only systems which may not have any HW
described in a DTB. I fear it will result in more pain on any systems
which try to ship both ACPI and DT, where ACPI will not get the testing
it requires, leading to a greater possibility of quirks/workarounds
being required later.

Thanks,
Mark.

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 11:37 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Jul 28, 2014 at 05:33:13PM +0100, Olof Johansson wrote:
>> On Mon, Jul 28, 2014 at 11:12:29AM +0100, Mark Rutland wrote:
>> > On Mon, Jul 28, 2014 at 10:07:50AM +0100, Arnd Bergmann wrote:
>> > > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
>> > > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> > > > > +Relationship with Device Tree
>> > > > > +-----------------------------
>> > > > > +
>> > > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>> > > > > +exclusive with DT support at compile time.
>> > > > > +
>> > > > > +At boot time the kernel will only use one description method depending on
>> > > > > +parameters passed from the bootloader.
>> > > >
>> > > > Possibly overriden by kernel bootargs. And as debated for quite a
>> > > > while earlier this year, acpi should still default to off -- if a DT
>> > > > and ACPI are both passed in, DT should at this time be given priority.
>> > >
>> > > I think this would be harder to do with the way that ACPI is passed in
>> > > to the kernel. IIRC, you always have a minimal DT information based on
>> > > the ARM64 boot protocol, but in the case of ACPI, this contains pointers
>> > > to the ACPI tables, which are then used for populating the Linux platform
>> > > devices (unless acpi=disabled is set), while the other contents of the
>> > > DTB may be present but we skip the of_platform_populate state.
>> > >
>> > > If this is correct, then replacing the firmware-generated dtb with a
>> > > user-provided on would implicitly remove the ACPI tables from visibility,
>> > > which is exactly what we want.
>> >
>> > That's not quite true.
>> >
>> > There might not be any DTB, or the user might have provided a DTB with
>> > only /chosen/bootargs. Trying to distinguish the many cases of possible
>> > DTB is broken as a concept.
>> >
>> > The EFI stub will attempt to get a DTB from somewhere (provided by
>> > filename or as a system table with a magic UUID), and if it can't find
>> > one will generate an empty stub DTB.
>> >
>> > Then it will go and perform some EFI memory setup, placing some
>> > properties in the DTB (which might be a stub) describing the EFI memory
>> > map.
>> >
>> > Then we boot the kernel proper, which sees the EFI pointers and looks
>> > for an ACPI table. If they are found, ACPI is used. Otherwise we attempt
>> > to use the DTB (which might be a stub).
>> >
>> > Unless ACPI is explcitly disabled, ACPI will be used if present.
>>
>> Ah, I saw this after I replied to Arnd's email.
>>
>> The above sounds more like how I envisioned things working, so based on that,
>> the default just needs to be flipped and we should be fine (i.e. ACPI needs to
>> be explicitly enabled).
>
> Sorry, but I don't follow your reasoning. What is the rationale for
> disabling ACPI by default?
>
> That's not going to work for ACPI-only systems which may not have any HW
> described in a DTB. I fear it will result in more pain on any systems
> which try to ship both ACPI and DT, where ACPI will not get the testing
> it requires, leading to a greater possibility of quirks/workarounds
> being required later.

We have said that we are not going to support ACPI-only systems at
this time. If vendors choose to use ACPI only then we can choose to
write a DT for them. We've been *very* clear on this.

There's no difference between quirks "now or later". Once we need a
quirk, it's around forever. So by giving them a chance to avoid some
now, we can reduce the need to ever see them. The alternative is to
pick them up now and forever carry them.

For ACPI test coverage, I suggest you get your validation test suite
work going if it hasn't been started. Beyond that, there's always
testing with acpi=on.


-Olof

[PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Jul 28, 2014 at 11:37 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Mon, Jul 28, 2014 at 05:33:13PM +0100, Olof Johansson wrote:
>> On Mon, Jul 28, 2014 at 11:12:29AM +0100, Mark Rutland wrote:
>> > On Mon, Jul 28, 2014 at 10:07:50AM +0100, Arnd Bergmann wrote:
>> > > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
>> > > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> > > > > +Relationship with Device Tree
>> > > > > +-----------------------------
>> > > > > +
>> > > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>> > > > > +exclusive with DT support at compile time.
>> > > > > +
>> > > > > +At boot time the kernel will only use one description method depending on
>> > > > > +parameters passed from the bootloader.
>> > > >
>> > > > Possibly overriden by kernel bootargs. And as debated for quite a
>> > > > while earlier this year, acpi should still default to off -- if a DT
>> > > > and ACPI are both passed in, DT should at this time be given priority.
>> > >
>> > > I think this would be harder to do with the way that ACPI is passed in
>> > > to the kernel. IIRC, you always have a minimal DT information based on
>> > > the ARM64 boot protocol, but in the case of ACPI, this contains pointers
>> > > to the ACPI tables, which are then used for populating the Linux platform
>> > > devices (unless acpi=disabled is set), while the other contents of the
>> > > DTB may be present but we skip the of_platform_populate state.
>> > >
>> > > If this is correct, then replacing the firmware-generated dtb with a
>> > > user-provided on would implicitly remove the ACPI tables from visibility,
>> > > which is exactly what we want.
>> >
>> > That's not quite true.
>> >
>> > There might not be any DTB, or the user might have provided a DTB with
>> > only /chosen/bootargs. Trying to distinguish the many cases of possible
>> > DTB is broken as a concept.
>> >
>> > The EFI stub will attempt to get a DTB from somewhere (provided by
>> > filename or as a system table with a magic UUID), and if it can't find
>> > one will generate an empty stub DTB.
>> >
>> > Then it will go and perform some EFI memory setup, placing some
>> > properties in the DTB (which might be a stub) describing the EFI memory
>> > map.
>> >
>> > Then we boot the kernel proper, which sees the EFI pointers and looks
>> > for an ACPI table. If they are found, ACPI is used. Otherwise we attempt
>> > to use the DTB (which might be a stub).
>> >
>> > Unless ACPI is explcitly disabled, ACPI will be used if present.
>>
>> Ah, I saw this after I replied to Arnd's email.
>>
>> The above sounds more like how I envisioned things working, so based on that,
>> the default just needs to be flipped and we should be fine (i.e. ACPI needs to
>> be explicitly enabled).
>
> Sorry, but I don't follow your reasoning. What is the rationale for
> disabling ACPI by default?
>
> That's not going to work for ACPI-only systems which may not have any HW
> described in a DTB. I fear it will result in more pain on any systems
> which try to ship both ACPI and DT, where ACPI will not get the testing
> it requires, leading to a greater possibility of quirks/workarounds
> being required later.

We have said that we are not going to support ACPI-only systems at
this time. If vendors choose to use ACPI only then we can choose to
write a DT for them. We've been *very* clear on this.

There's no difference between quirks "now or later". Once we need a
quirk, it's around forever. So by giving them a chance to avoid some
now, we can reduce the need to ever see them. The alternative is to
pick them up now and forever carry them.

For ACPI test coverage, I suggest you get your validation test suite
work going if it hasn't been started. Beyond that, there's always
testing with acpi=on.


-Olof

Re: [PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> arch_fix_phys_package_id() will be called in ACPI core to use
> the slot number provided by ACPI to update the physical package
> id, then we can get the right value in the "physical id" field
> of /proc/cpuinfo.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/topology.h |    2 ++
>   arch/arm64/kernel/topology.c      |   14 ++++++++++++++
>   2 files changed, 16 insertions(+)
>
> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> index 7ebcd31..2b216d4 100644
> --- a/arch/arm64/include/asm/topology.h
> +++ b/arch/arm64/include/asm/topology.h
> @@ -23,11 +23,13 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
>   void init_cpu_topology(void);
>   void store_cpu_topology(unsigned int cpuid);
>   const struct cpumask *cpu_coregroup_mask(int cpu);
> +void arch_fix_phys_package_id(int num, u32 slot);
>
>   #else
>
>   static inline void init_cpu_topology(void) { }
>   static inline void store_cpu_topology(unsigned int cpuid) { }
> +static inline void arch_fix_phys_package_id(int num, u32 slot) { }
>
>   #endif
>
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index 43514f9..c547885 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
> @@ -281,3 +281,17 @@ void __init init_cpu_topology(void)
>   	if (parse_dt_topology())
>   		reset_cpu_topology();
>   }
> +
> +/*
> + * Use the CPU slot number provided by ACPI to update the physical
> + * package id when cpuid_topo->cluster_id is not available, then we
> + * can get the right value in the "physical id" field of /proc/cpuinfo.
> + */

We don't have "physical id" field in /proc/cpuinfo on ARM64.

> +void arch_fix_phys_package_id(int num, u32 slot)
> +{
> +	struct cpu_topology *cpuid_topo = &cpu_topology[num];
> +
> +	if (cpuid_topo->cluster_id == -1)
> +		cpuid_topo->cluster_id = slot;
> +}
> +EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
>

The ACPI core uses this function to set the package id as read from
_SUN from the device. As per spec, _SUN is used by OSPM UI to identify
slots for the user. Do we know how will this be used on ARM64 ?

If not clear at this time, better to define it or keep it empty. I see
even x86 does nothing in that function.

Regards,
Sudeep

Re: [PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> arch_fix_phys_package_id() will be called in ACPI core to use
> the slot number provided by ACPI to update the physical package
> id, then we can get the right value in the "physical id" field
> of /proc/cpuinfo.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/topology.h |    2 ++
>   arch/arm64/kernel/topology.c      |   14 ++++++++++++++
>   2 files changed, 16 insertions(+)
>
> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> index 7ebcd31..2b216d4 100644
> --- a/arch/arm64/include/asm/topology.h
> +++ b/arch/arm64/include/asm/topology.h
> @@ -23,11 +23,13 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
>   void init_cpu_topology(void);
>   void store_cpu_topology(unsigned int cpuid);
>   const struct cpumask *cpu_coregroup_mask(int cpu);
> +void arch_fix_phys_package_id(int num, u32 slot);
>
>   #else
>
>   static inline void init_cpu_topology(void) { }
>   static inline void store_cpu_topology(unsigned int cpuid) { }
> +static inline void arch_fix_phys_package_id(int num, u32 slot) { }
>
>   #endif
>
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index 43514f9..c547885 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
> @@ -281,3 +281,17 @@ void __init init_cpu_topology(void)
>   	if (parse_dt_topology())
>   		reset_cpu_topology();
>   }
> +
> +/*
> + * Use the CPU slot number provided by ACPI to update the physical
> + * package id when cpuid_topo->cluster_id is not available, then we
> + * can get the right value in the "physical id" field of /proc/cpuinfo.
> + */

We don't have "physical id" field in /proc/cpuinfo on ARM64.

> +void arch_fix_phys_package_id(int num, u32 slot)
> +{
> +	struct cpu_topology *cpuid_topo = &cpu_topology[num];
> +
> +	if (cpuid_topo->cluster_id == -1)
> +		cpuid_topo->cluster_id = slot;
> +}
> +EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
>

The ACPI core uses this function to set the package id as read from
_SUN from the device. As per spec, _SUN is used by OSPM UI to identify
slots for the user. Do we know how will this be used on ARM64 ?

If not clear at this time, better to define it or keep it empty. I see
even x86 does nothing in that function.

Regards,
Sudeep

[PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> arch_fix_phys_package_id() will be called in ACPI core to use
> the slot number provided by ACPI to update the physical package
> id, then we can get the right value in the "physical id" field
> of /proc/cpuinfo.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/topology.h |    2 ++
>   arch/arm64/kernel/topology.c      |   14 ++++++++++++++
>   2 files changed, 16 insertions(+)
>
> diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
> index 7ebcd31..2b216d4 100644
> --- a/arch/arm64/include/asm/topology.h
> +++ b/arch/arm64/include/asm/topology.h
> @@ -23,11 +23,13 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
>   void init_cpu_topology(void);
>   void store_cpu_topology(unsigned int cpuid);
>   const struct cpumask *cpu_coregroup_mask(int cpu);
> +void arch_fix_phys_package_id(int num, u32 slot);
>
>   #else
>
>   static inline void init_cpu_topology(void) { }
>   static inline void store_cpu_topology(unsigned int cpuid) { }
> +static inline void arch_fix_phys_package_id(int num, u32 slot) { }
>
>   #endif
>
> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
> index 43514f9..c547885 100644
> --- a/arch/arm64/kernel/topology.c
> +++ b/arch/arm64/kernel/topology.c
> @@ -281,3 +281,17 @@ void __init init_cpu_topology(void)
>   	if (parse_dt_topology())
>   		reset_cpu_topology();
>   }
> +
> +/*
> + * Use the CPU slot number provided by ACPI to update the physical
> + * package id when cpuid_topo->cluster_id is not available, then we
> + * can get the right value in the "physical id" field of /proc/cpuinfo.
> + */

We don't have "physical id" field in /proc/cpuinfo on ARM64.

> +void arch_fix_phys_package_id(int num, u32 slot)
> +{
> +	struct cpu_topology *cpuid_topo = &cpu_topology[num];
> +
> +	if (cpuid_topo->cluster_id == -1)
> +		cpuid_topo->cluster_id = slot;
> +}
> +EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
>

The ACPI core uses this function to set the package id as read from
_SUN from the device. As per spec, _SUN is used by OSPM UI to identify
slots for the user. Do we know how will this be used on ARM64 ?

If not clear at this time, better to define it or keep it empty. I see
even x86 does nothing in that function.

Regards,
Sudeep

Re: [PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Graeme Gregory]

On 28/07/2014 19:29, Sudeep Holla wrote:
>
>
> On 24/07/14 14:00, Hanjun Guo wrote:
>> From: Al Stone <al.stone@linaro.org>
>>
>> As we want to get ACPI tables to parse and then use the information
>> for system initialization, we should get the RSDP (Root System
>> Description Pointer) first, it then locates Extended Root Description
>> Table (XSDT) which contains all the 64-bit physical address that
>> pointer to other boot-time tables.
>>
>> Introduce acpi.c and its related head file in this patch to provide
>> fundamental needs of extern variables and functions for ACPI core,
>> and then get boot-time tables as needed.
>>    - asm/cpu.h need for ACPI core and will be updated in the future to
>>      add definitions for arch_(un)register_cpu which are required for
>>      ACPI based physical CPU hotplug;
>>    - asm/acenv.h for arch specific ACPICA environments and
>>      implementation;
>>    - asm/acpi.h for arch specific variables and functions needed by
>>      ACPI driver core;
>>    - acpi.c for ARM64 related ACPI implementation for ACPI driver
>>      core;
>>
>> acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
>> it will be called in setup_arch() before paging_init(), so we should
>> use eary_memremap() mechanism here to get the RSDP and all the table
>> pointers.
>>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   arch/arm64/include/asm/acenv.h |   18 ++++++++++
>>   arch/arm64/include/asm/acpi.h  |   41 ++++++++++++++++++++++
>>   arch/arm64/include/asm/cpu.h   |   11 ++++++
>>   arch/arm64/kernel/Makefile     |    1 +
>>   arch/arm64/kernel/acpi.c       |   76 
>> ++++++++++++++++++++++++++++++++++++++++
>>   arch/arm64/kernel/setup.c      |    4 +++
>>   6 files changed, 151 insertions(+)
>>   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/cpu.h
>>   create mode 100644 arch/arm64/kernel/acpi.c
>>
>> diff --git a/arch/arm64/include/asm/acenv.h 
>> b/arch/arm64/include/asm/acenv.h
>> new file mode 100644
>> index 0000000..3899ee6
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/acenv.h
>> @@ -0,0 +1,18 @@
>> +/*
>> + * ARM64 specific ACPICA environments and implementation
>> + *
>> + * Copyright (C) 2014, Linaro Ltd.
>> + *   Author: Hanjun Guo <hanjun.guo@linaro.org>
>> + *   Author: Graeme Gregory <graeme.gregory@linaro.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#ifndef _ASM_ACENV_H
>> +#define _ASM_ACENV_H
>> +
>> +#define ACPI_FLUSH_CPU_CACHE() WARN_ONCE(1, "Not currently supported 
>> on ARM64")
>> +
>> +#endif /* _ASM_ACENV_H */
>> diff --git a/arch/arm64/include/asm/acpi.h 
>> b/arch/arm64/include/asm/acpi.h
>> new file mode 100644
>> index 0000000..e8581ea
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -0,0 +1,41 @@
>> +/*
>> + *  Copyright (C) 2013-2014, Linaro Ltd.
>> + *     Author: Al Stone <al.stone@linaro.org>
>> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
>> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
>> + *
>> + *  This program is free software; you can redistribute it and/or 
>> modify
>> + *  it under the terms of the GNU General Public License version 2 as
>> + *  published by the Free Software Foundation;
>> + */
>> +
>> +#ifndef _ASM_ACPI_H
>> +#define _ASM_ACPI_H
>> +
>> +/* Basic configuration for ACPI */
>> +#ifdef CONFIG_ACPI
>> +extern int acpi_disabled;
>> +extern int acpi_noirq;
>> +extern int acpi_pci_disabled;
>> +extern int acpi_strict;
>
> Until we need to enable workarounds, we should have acpi_strict
> as macro rather than variable similar to IA64.
>
>> +
>> +static inline void disable_acpi(void)
>> +{
>> +       acpi_disabled = 1;
>> +       acpi_pci_disabled = 1;
>> +       acpi_noirq = 1;
>> +}
>> +
>> +/*
>> + * MADT must provide at least one GICC structure
>> + * for GIC initialization, so CPU will be
>> + * always available in MADT on ARM64
>> + */
>> +static inline bool acpi_has_cpu_in_madt(void)
>> +{
>> +       return 1;
>> +}
>> +
>
> I don't see the user of this function in the series, it's better to
> remove. Moreover the comment is so misleading. We will have CPU UID
> not the CPU itself in MADT.
>
This is actually required for a patch that is now upstreamed. Comment 
should actually say that its checking for the posibility that the CPU 
can be initialised from the MADT. Its used from core in crash kernel 
case where boot CPU is not necessarily CPU0 like spec demands.

Graeme

>> +#endif /* CONFIG_ACPI */
>> +
>> +#endif /*_ASM_ACPI_H*/
>> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
>> new file mode 100644
>> index 0000000..cee7d3f
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/cpu.h
>> @@ -0,0 +1,11 @@
>> +/*
>> + *  Copyright (C) 2013-2014 ARM Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +#ifndef __ASM_CPU_H
>> +#define __ASM_CPU_H
>> +
>> +#endif
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index cdaedad..b568c26 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o 
>> suspend.o
>>   arm64-obj-$(CONFIG_JUMP_LABEL)         += jump_label.o
>>   arm64-obj-$(CONFIG_KGDB)               += kgdb.o
>>   arm64-obj-$(CONFIG_EFI)                        += efi.o efi-stub.o 
>> efi-entry.o
>> +arm64-obj-$(CONFIG_ACPI)               += acpi.o
>>
>>   obj-y                                  += $(arm64-obj-y) vdso/
>>   obj-m                                  += $(arm64-obj-m)
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> new file mode 100644
>> index 0000000..c62fce6
>> --- /dev/null
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -0,0 +1,76 @@
>> +/*
>> + *  ARM64 Specific Low-Level ACPI Boot Support
>> + *
>> + *  Copyright (C) 2013-2014, Linaro Ltd.
>> + *     Author: Al Stone <al.stone@linaro.org>
>> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
>> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
>> + *
>> + *  This program is free software; you can redistribute it and/or 
>> modify
>> + *  it under the terms of the GNU General Public License version 2 as
>> + *  published by the Free Software Foundation.
>> + */
>> +
>> +#include <linux/init.h>
>> +#include <linux/acpi.h>
>> +#include <linux/cpumask.h>
>> +#include <linux/memblock.h>
>> +#include <linux/irq.h>
>> +#include <linux/irqdomain.h>
>> +#include <linux/bootmem.h>
>> +#include <linux/smp.h>
>> +
>> +/*
>> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec 
>> but this
>> + * variable is still required by the ACPI core
>> + */
>> +u32 acpi_rsdt_forced;
>
> This looks like yet another stray variable not used anywhere including
> core ACPI
>
>> +
>> +int acpi_noirq;                        /* skip ACPI IRQ 
>> initialization */
>> +int acpi_strict;
>> +int acpi_disabled;
>> +EXPORT_SYMBOL(acpi_disabled);
>> +
>> +int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ 
>> initialization */
>> +EXPORT_SYMBOL(acpi_pci_disabled);
>> +
>> +/*
>> + * __acpi_map_table() will be called before page_init(), so 
>> early_ioremap()
>> + * or early_memremap() should be called here to for ACPI table mapping.
>> + */
>> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
>> +{
>> +       if (!phys || !size)
>> +               return NULL;
>> +
>> +       return early_memremap(phys, size);
>> +}
>> +
>> +void __init __acpi_unmap_table(char *map, unsigned long size)
>> +{
>> +       if (!map || !size)
>> +               return;
>> +
>> +       early_iounmap(map, size);
>
> Why not early_memunmap for consistency ?
> Also now there's generic implementation of early mappings does it make
> sense to move this also to acpi core ?
>
> Regards,
> Sudeep
>

Re: [PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Graeme Gregory]

On 28/07/2014 19:29, Sudeep Holla wrote:
>
>
> On 24/07/14 14:00, Hanjun Guo wrote:
>> From: Al Stone <al.stone@linaro.org>
>>
>> As we want to get ACPI tables to parse and then use the information
>> for system initialization, we should get the RSDP (Root System
>> Description Pointer) first, it then locates Extended Root Description
>> Table (XSDT) which contains all the 64-bit physical address that
>> pointer to other boot-time tables.
>>
>> Introduce acpi.c and its related head file in this patch to provide
>> fundamental needs of extern variables and functions for ACPI core,
>> and then get boot-time tables as needed.
>>    - asm/cpu.h need for ACPI core and will be updated in the future to
>>      add definitions for arch_(un)register_cpu which are required for
>>      ACPI based physical CPU hotplug;
>>    - asm/acenv.h for arch specific ACPICA environments and
>>      implementation;
>>    - asm/acpi.h for arch specific variables and functions needed by
>>      ACPI driver core;
>>    - acpi.c for ARM64 related ACPI implementation for ACPI driver
>>      core;
>>
>> acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
>> it will be called in setup_arch() before paging_init(), so we should
>> use eary_memremap() mechanism here to get the RSDP and all the table
>> pointers.
>>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   arch/arm64/include/asm/acenv.h |   18 ++++++++++
>>   arch/arm64/include/asm/acpi.h  |   41 ++++++++++++++++++++++
>>   arch/arm64/include/asm/cpu.h   |   11 ++++++
>>   arch/arm64/kernel/Makefile     |    1 +
>>   arch/arm64/kernel/acpi.c       |   76 
>> ++++++++++++++++++++++++++++++++++++++++
>>   arch/arm64/kernel/setup.c      |    4 +++
>>   6 files changed, 151 insertions(+)
>>   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/cpu.h
>>   create mode 100644 arch/arm64/kernel/acpi.c
>>
>> diff --git a/arch/arm64/include/asm/acenv.h 
>> b/arch/arm64/include/asm/acenv.h
>> new file mode 100644
>> index 0000000..3899ee6
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/acenv.h
>> @@ -0,0 +1,18 @@
>> +/*
>> + * ARM64 specific ACPICA environments and implementation
>> + *
>> + * Copyright (C) 2014, Linaro Ltd.
>> + *   Author: Hanjun Guo <hanjun.guo@linaro.org>
>> + *   Author: Graeme Gregory <graeme.gregory@linaro.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#ifndef _ASM_ACENV_H
>> +#define _ASM_ACENV_H
>> +
>> +#define ACPI_FLUSH_CPU_CACHE() WARN_ONCE(1, "Not currently supported 
>> on ARM64")
>> +
>> +#endif /* _ASM_ACENV_H */
>> diff --git a/arch/arm64/include/asm/acpi.h 
>> b/arch/arm64/include/asm/acpi.h
>> new file mode 100644
>> index 0000000..e8581ea
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -0,0 +1,41 @@
>> +/*
>> + *  Copyright (C) 2013-2014, Linaro Ltd.
>> + *     Author: Al Stone <al.stone@linaro.org>
>> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
>> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
>> + *
>> + *  This program is free software; you can redistribute it and/or 
>> modify
>> + *  it under the terms of the GNU General Public License version 2 as
>> + *  published by the Free Software Foundation;
>> + */
>> +
>> +#ifndef _ASM_ACPI_H
>> +#define _ASM_ACPI_H
>> +
>> +/* Basic configuration for ACPI */
>> +#ifdef CONFIG_ACPI
>> +extern int acpi_disabled;
>> +extern int acpi_noirq;
>> +extern int acpi_pci_disabled;
>> +extern int acpi_strict;
>
> Until we need to enable workarounds, we should have acpi_strict
> as macro rather than variable similar to IA64.
>
>> +
>> +static inline void disable_acpi(void)
>> +{
>> +       acpi_disabled = 1;
>> +       acpi_pci_disabled = 1;
>> +       acpi_noirq = 1;
>> +}
>> +
>> +/*
>> + * MADT must provide at least one GICC structure
>> + * for GIC initialization, so CPU will be
>> + * always available in MADT on ARM64
>> + */
>> +static inline bool acpi_has_cpu_in_madt(void)
>> +{
>> +       return 1;
>> +}
>> +
>
> I don't see the user of this function in the series, it's better to
> remove. Moreover the comment is so misleading. We will have CPU UID
> not the CPU itself in MADT.
>
This is actually required for a patch that is now upstreamed. Comment 
should actually say that its checking for the posibility that the CPU 
can be initialised from the MADT. Its used from core in crash kernel 
case where boot CPU is not necessarily CPU0 like spec demands.

Graeme

>> +#endif /* CONFIG_ACPI */
>> +
>> +#endif /*_ASM_ACPI_H*/
>> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
>> new file mode 100644
>> index 0000000..cee7d3f
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/cpu.h
>> @@ -0,0 +1,11 @@
>> +/*
>> + *  Copyright (C) 2013-2014 ARM Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +#ifndef __ASM_CPU_H
>> +#define __ASM_CPU_H
>> +
>> +#endif
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index cdaedad..b568c26 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o 
>> suspend.o
>>   arm64-obj-$(CONFIG_JUMP_LABEL)         += jump_label.o
>>   arm64-obj-$(CONFIG_KGDB)               += kgdb.o
>>   arm64-obj-$(CONFIG_EFI)                        += efi.o efi-stub.o 
>> efi-entry.o
>> +arm64-obj-$(CONFIG_ACPI)               += acpi.o
>>
>>   obj-y                                  += $(arm64-obj-y) vdso/
>>   obj-m                                  += $(arm64-obj-m)
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> new file mode 100644
>> index 0000000..c62fce6
>> --- /dev/null
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -0,0 +1,76 @@
>> +/*
>> + *  ARM64 Specific Low-Level ACPI Boot Support
>> + *
>> + *  Copyright (C) 2013-2014, Linaro Ltd.
>> + *     Author: Al Stone <al.stone@linaro.org>
>> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
>> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
>> + *
>> + *  This program is free software; you can redistribute it and/or 
>> modify
>> + *  it under the terms of the GNU General Public License version 2 as
>> + *  published by the Free Software Foundation.
>> + */
>> +
>> +#include <linux/init.h>
>> +#include <linux/acpi.h>
>> +#include <linux/cpumask.h>
>> +#include <linux/memblock.h>
>> +#include <linux/irq.h>
>> +#include <linux/irqdomain.h>
>> +#include <linux/bootmem.h>
>> +#include <linux/smp.h>
>> +
>> +/*
>> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec 
>> but this
>> + * variable is still required by the ACPI core
>> + */
>> +u32 acpi_rsdt_forced;
>
> This looks like yet another stray variable not used anywhere including
> core ACPI
>
>> +
>> +int acpi_noirq;                        /* skip ACPI IRQ 
>> initialization */
>> +int acpi_strict;
>> +int acpi_disabled;
>> +EXPORT_SYMBOL(acpi_disabled);
>> +
>> +int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ 
>> initialization */
>> +EXPORT_SYMBOL(acpi_pci_disabled);
>> +
>> +/*
>> + * __acpi_map_table() will be called before page_init(), so 
>> early_ioremap()
>> + * or early_memremap() should be called here to for ACPI table mapping.
>> + */
>> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
>> +{
>> +       if (!phys || !size)
>> +               return NULL;
>> +
>> +       return early_memremap(phys, size);
>> +}
>> +
>> +void __init __acpi_unmap_table(char *map, unsigned long size)
>> +{
>> +       if (!map || !size)
>> +               return;
>> +
>> +       early_iounmap(map, size);
>
> Why not early_memunmap for consistency ?
> Also now there's generic implementation of early mappings does it make
> sense to move this also to acpi core ?
>
> Regards,
> Sudeep
>

[PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Graeme Gregory]

On 28/07/2014 19:29, Sudeep Holla wrote:
>
>
> On 24/07/14 14:00, Hanjun Guo wrote:
>> From: Al Stone <al.stone@linaro.org>
>>
>> As we want to get ACPI tables to parse and then use the information
>> for system initialization, we should get the RSDP (Root System
>> Description Pointer) first, it then locates Extended Root Description
>> Table (XSDT) which contains all the 64-bit physical address that
>> pointer to other boot-time tables.
>>
>> Introduce acpi.c and its related head file in this patch to provide
>> fundamental needs of extern variables and functions for ACPI core,
>> and then get boot-time tables as needed.
>>    - asm/cpu.h need for ACPI core and will be updated in the future to
>>      add definitions for arch_(un)register_cpu which are required for
>>      ACPI based physical CPU hotplug;
>>    - asm/acenv.h for arch specific ACPICA environments and
>>      implementation;
>>    - asm/acpi.h for arch specific variables and functions needed by
>>      ACPI driver core;
>>    - acpi.c for ARM64 related ACPI implementation for ACPI driver
>>      core;
>>
>> acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
>> it will be called in setup_arch() before paging_init(), so we should
>> use eary_memremap() mechanism here to get the RSDP and all the table
>> pointers.
>>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   arch/arm64/include/asm/acenv.h |   18 ++++++++++
>>   arch/arm64/include/asm/acpi.h  |   41 ++++++++++++++++++++++
>>   arch/arm64/include/asm/cpu.h   |   11 ++++++
>>   arch/arm64/kernel/Makefile     |    1 +
>>   arch/arm64/kernel/acpi.c       |   76 
>> ++++++++++++++++++++++++++++++++++++++++
>>   arch/arm64/kernel/setup.c      |    4 +++
>>   6 files changed, 151 insertions(+)
>>   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/cpu.h
>>   create mode 100644 arch/arm64/kernel/acpi.c
>>
>> diff --git a/arch/arm64/include/asm/acenv.h 
>> b/arch/arm64/include/asm/acenv.h
>> new file mode 100644
>> index 0000000..3899ee6
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/acenv.h
>> @@ -0,0 +1,18 @@
>> +/*
>> + * ARM64 specific ACPICA environments and implementation
>> + *
>> + * Copyright (C) 2014, Linaro Ltd.
>> + *   Author: Hanjun Guo <hanjun.guo@linaro.org>
>> + *   Author: Graeme Gregory <graeme.gregory@linaro.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#ifndef _ASM_ACENV_H
>> +#define _ASM_ACENV_H
>> +
>> +#define ACPI_FLUSH_CPU_CACHE() WARN_ONCE(1, "Not currently supported 
>> on ARM64")
>> +
>> +#endif /* _ASM_ACENV_H */
>> diff --git a/arch/arm64/include/asm/acpi.h 
>> b/arch/arm64/include/asm/acpi.h
>> new file mode 100644
>> index 0000000..e8581ea
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -0,0 +1,41 @@
>> +/*
>> + *  Copyright (C) 2013-2014, Linaro Ltd.
>> + *     Author: Al Stone <al.stone@linaro.org>
>> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
>> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
>> + *
>> + *  This program is free software; you can redistribute it and/or 
>> modify
>> + *  it under the terms of the GNU General Public License version 2 as
>> + *  published by the Free Software Foundation;
>> + */
>> +
>> +#ifndef _ASM_ACPI_H
>> +#define _ASM_ACPI_H
>> +
>> +/* Basic configuration for ACPI */
>> +#ifdef CONFIG_ACPI
>> +extern int acpi_disabled;
>> +extern int acpi_noirq;
>> +extern int acpi_pci_disabled;
>> +extern int acpi_strict;
>
> Until we need to enable workarounds, we should have acpi_strict
> as macro rather than variable similar to IA64.
>
>> +
>> +static inline void disable_acpi(void)
>> +{
>> +       acpi_disabled = 1;
>> +       acpi_pci_disabled = 1;
>> +       acpi_noirq = 1;
>> +}
>> +
>> +/*
>> + * MADT must provide at least one GICC structure
>> + * for GIC initialization, so CPU will be
>> + * always available in MADT on ARM64
>> + */
>> +static inline bool acpi_has_cpu_in_madt(void)
>> +{
>> +       return 1;
>> +}
>> +
>
> I don't see the user of this function in the series, it's better to
> remove. Moreover the comment is so misleading. We will have CPU UID
> not the CPU itself in MADT.
>
This is actually required for a patch that is now upstreamed. Comment 
should actually say that its checking for the posibility that the CPU 
can be initialised from the MADT. Its used from core in crash kernel 
case where boot CPU is not necessarily CPU0 like spec demands.

Graeme

>> +#endif /* CONFIG_ACPI */
>> +
>> +#endif /*_ASM_ACPI_H*/
>> diff --git a/arch/arm64/include/asm/cpu.h b/arch/arm64/include/asm/cpu.h
>> new file mode 100644
>> index 0000000..cee7d3f
>> --- /dev/null
>> +++ b/arch/arm64/include/asm/cpu.h
>> @@ -0,0 +1,11 @@
>> +/*
>> + *  Copyright (C) 2013-2014 ARM Ltd.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +#ifndef __ASM_CPU_H
>> +#define __ASM_CPU_H
>> +
>> +#endif
>> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
>> index cdaedad..b568c26 100644
>> --- a/arch/arm64/kernel/Makefile
>> +++ b/arch/arm64/kernel/Makefile
>> @@ -29,6 +29,7 @@ arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o 
>> suspend.o
>>   arm64-obj-$(CONFIG_JUMP_LABEL)         += jump_label.o
>>   arm64-obj-$(CONFIG_KGDB)               += kgdb.o
>>   arm64-obj-$(CONFIG_EFI)                        += efi.o efi-stub.o 
>> efi-entry.o
>> +arm64-obj-$(CONFIG_ACPI)               += acpi.o
>>
>>   obj-y                                  += $(arm64-obj-y) vdso/
>>   obj-m                                  += $(arm64-obj-m)
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> new file mode 100644
>> index 0000000..c62fce6
>> --- /dev/null
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -0,0 +1,76 @@
>> +/*
>> + *  ARM64 Specific Low-Level ACPI Boot Support
>> + *
>> + *  Copyright (C) 2013-2014, Linaro Ltd.
>> + *     Author: Al Stone <al.stone@linaro.org>
>> + *     Author: Graeme Gregory <graeme.gregory@linaro.org>
>> + *     Author: Hanjun Guo <hanjun.guo@linaro.org>
>> + *
>> + *  This program is free software; you can redistribute it and/or 
>> modify
>> + *  it under the terms of the GNU General Public License version 2 as
>> + *  published by the Free Software Foundation.
>> + */
>> +
>> +#include <linux/init.h>
>> +#include <linux/acpi.h>
>> +#include <linux/cpumask.h>
>> +#include <linux/memblock.h>
>> +#include <linux/irq.h>
>> +#include <linux/irqdomain.h>
>> +#include <linux/bootmem.h>
>> +#include <linux/smp.h>
>> +
>> +/*
>> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec 
>> but this
>> + * variable is still required by the ACPI core
>> + */
>> +u32 acpi_rsdt_forced;
>
> This looks like yet another stray variable not used anywhere including
> core ACPI
>
>> +
>> +int acpi_noirq;                        /* skip ACPI IRQ 
>> initialization */
>> +int acpi_strict;
>> +int acpi_disabled;
>> +EXPORT_SYMBOL(acpi_disabled);
>> +
>> +int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ 
>> initialization */
>> +EXPORT_SYMBOL(acpi_pci_disabled);
>> +
>> +/*
>> + * __acpi_map_table() will be called before page_init(), so 
>> early_ioremap()
>> + * or early_memremap() should be called here to for ACPI table mapping.
>> + */
>> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
>> +{
>> +       if (!phys || !size)
>> +               return NULL;
>> +
>> +       return early_memremap(phys, size);
>> +}
>> +
>> +void __init __acpi_unmap_table(char *map, unsigned long size)
>> +{
>> +       if (!map || !size)
>> +               return;
>> +
>> +       early_iounmap(map, size);
>
> Why not early_memunmap for consistency ?
> Also now there's generic implementation of early mappings does it make
> sense to move this also to acpi core ?
>
> Regards,
> Sudeep
>

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-7-27 10:34, Olof Johansson wrote:
> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> From: Graeme Gregory <graeme.gregory@linaro.org>
>>
>> Add documentation for the guidelines of how to use ACPI
>> on ARM64.
> 
> As the most vocal participant against ACPI being adopted, I would have
> appreciated a cc on this patch set -- it's not like you were going for
> a minimal set of cc recipients already. It makes it seem like you're
> trying to sneak it past me for comments. Not cool. I know that's
> probably not your intent, but still.

My bad, I'm sorry for that. Actually it was not my intention, I was not
playing with a full deck when I sent this patch set out, I missed someone
else (such as Rob) in the CC list and I even added private mailing list
in CC.

I'm sure you will in the CC list with next version.

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-7-27 10:34, Olof Johansson wrote:
> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> From: Graeme Gregory <graeme.gregory@linaro.org>
>>
>> Add documentation for the guidelines of how to use ACPI
>> on ARM64.
> 
> As the most vocal participant against ACPI being adopted, I would have
> appreciated a cc on this patch set -- it's not like you were going for
> a minimal set of cc recipients already. It makes it seem like you're
> trying to sneak it past me for comments. Not cool. I know that's
> probably not your intent, but still.

My bad, I'm sorry for that. Actually it was not my intention, I was not
playing with a full deck when I sent this patch set out, I missed someone
else (such as Rob) in the CC list and I even added private mailing list
in CC.

I'm sure you will in the CC list with next version.

Thanks
Hanjun

[PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-7-27 10:34, Olof Johansson wrote:
> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> From: Graeme Gregory <graeme.gregory@linaro.org>
>>
>> Add documentation for the guidelines of how to use ACPI
>> on ARM64.
> 
> As the most vocal participant against ACPI being adopted, I would have
> appreciated a cc on this patch set -- it's not like you were going for
> a minimal set of cc recipients already. It makes it seem like you're
> trying to sneak it past me for comments. Not cool. I know that's
> probably not your intent, but still.

My bad, I'm sorry for that. Actually it was not my intention, I was not
playing with a full deck when I sent this patch set out, I missed someone
else (such as Rob) in the CC list and I even added private mailing list
in CC.

I'm sure you will in the CC list with next version.

Thanks
Hanjun

Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

On 2014-7-25 20:24, Mark Rutland wrote:
> On Fri, Jul 25, 2014 at 11:51:37AM +0100, Hanjun Guo wrote:
>> On 2014-7-24 23:47, Mark Rutland wrote:
>>> On Thu, Jul 24, 2014 at 02:00:16PM +0100, Hanjun Guo wrote:
>>>> ACPI 5.1 only has two explicit methods to boot up SMP,
>>>> PSCI and Parking protocol, but the Parking protocol is
>>>> only suitable for ARMv7 now, so make PSCI as the only way
>>>> for the SMP boot protocol before some updates for the
>>>> ACPI spec or the Parking protocol spec.
>>>>
[...]
>>>> -#include <asm/cpu_ops.h>
>>>> -#include <asm/smp_plat.h>
>>>>  #include <linux/errno.h>
>>>>  #include <linux/of.h>
>>>>  #include <linux/string.h>
>>>> +#include <linux/acpi.h>
>>>> +
>>>> +#include <asm/cpu_ops.h>
>>>> +#include <asm/smp_plat.h>
>>>
>>> Was the header move just for consistency with other files, or is there
>>> some ordering requirement here?
>>
>> Ordering requirement, it will meet compile error for "return -ENODEV;"
>> in the head file which I introduced, I know I can include the right
>> head file in asm/cpu_ops.h, but I think move the asm/xx.h after the
>> include of linux/xx.h would be fine.
> 
> If a file uses something defined in a header, it should include that
> header. So if you need ENODEV in cpu_ops.h, make cpu_ops.h include
> <linux/errno.h>. It is not fine to deliberately rely on implicit
> includes.

ok, will fix that in next version.

> 
> Moving the headers around is a separate issue. I have no problem with
> doing that for consistency with other files.
> 
>>
>>>
>>>>
>>>>  extern const struct cpu_operations smp_spin_table_ops;
>>>>  extern const struct cpu_operations cpu_psci_ops;
>>>> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
>>>>  /*
>>>>   * Read a cpu's enable method from the device tree and record it in cpu_ops.
>>>>   */
>>>> -int __init cpu_read_ops(struct device_node *dn, int cpu)
>>>> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
>>>>  {
>>>>         const char *enable_method = of_get_property(dn, "enable-method", NULL);
>>>>         if (!enable_method) {
>>>> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
>>>>         return 0;
>>>>  }
>>>>
>>>> +#ifdef CONFIG_ACPI
>>>> +/*
>>>> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
>>>> + */
>>>> +int __init cpu_acpi_read_ops(int cpu)
>>>> +{
>>>> +       /*
>>>> +        * For ACPI 5.1, only two kind of methods are provided,
>>>> +        * Parking protocol and PSCI, but Parking protocol is
>>>> +        * used on ARMv7 only, so make PSCI as the only method
>>>> +        * for SMP initialization before the ACPI spec or Parking
>>>> +        * protocol spec is updated.
>>>> +        */
>>>
>>> That comment is a little misleading. The parking protocol is _specified_
>>> for ARMv7 only.
>>
>> Agreed. But I'm just wondering if the Parking protocol is modified and
>> then support ARMv8, how to describe it in the comments?
> 
> We update the comments if and when that happens.

Ok.

Thanks
Hanjun

[PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

On 2014-7-25 20:24, Mark Rutland wrote:
> On Fri, Jul 25, 2014 at 11:51:37AM +0100, Hanjun Guo wrote:
>> On 2014-7-24 23:47, Mark Rutland wrote:
>>> On Thu, Jul 24, 2014 at 02:00:16PM +0100, Hanjun Guo wrote:
>>>> ACPI 5.1 only has two explicit methods to boot up SMP,
>>>> PSCI and Parking protocol, but the Parking protocol is
>>>> only suitable for ARMv7 now, so make PSCI as the only way
>>>> for the SMP boot protocol before some updates for the
>>>> ACPI spec or the Parking protocol spec.
>>>>
[...]
>>>> -#include <asm/cpu_ops.h>
>>>> -#include <asm/smp_plat.h>
>>>>  #include <linux/errno.h>
>>>>  #include <linux/of.h>
>>>>  #include <linux/string.h>
>>>> +#include <linux/acpi.h>
>>>> +
>>>> +#include <asm/cpu_ops.h>
>>>> +#include <asm/smp_plat.h>
>>>
>>> Was the header move just for consistency with other files, or is there
>>> some ordering requirement here?
>>
>> Ordering requirement, it will meet compile error for "return -ENODEV;"
>> in the head file which I introduced, I know I can include the right
>> head file in asm/cpu_ops.h, but I think move the asm/xx.h after the
>> include of linux/xx.h would be fine.
> 
> If a file uses something defined in a header, it should include that
> header. So if you need ENODEV in cpu_ops.h, make cpu_ops.h include
> <linux/errno.h>. It is not fine to deliberately rely on implicit
> includes.

ok, will fix that in next version.

> 
> Moving the headers around is a separate issue. I have no problem with
> doing that for consistency with other files.
> 
>>
>>>
>>>>
>>>>  extern const struct cpu_operations smp_spin_table_ops;
>>>>  extern const struct cpu_operations cpu_psci_ops;
>>>> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
>>>>  /*
>>>>   * Read a cpu's enable method from the device tree and record it in cpu_ops.
>>>>   */
>>>> -int __init cpu_read_ops(struct device_node *dn, int cpu)
>>>> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
>>>>  {
>>>>         const char *enable_method = of_get_property(dn, "enable-method", NULL);
>>>>         if (!enable_method) {
>>>> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
>>>>         return 0;
>>>>  }
>>>>
>>>> +#ifdef CONFIG_ACPI
>>>> +/*
>>>> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
>>>> + */
>>>> +int __init cpu_acpi_read_ops(int cpu)
>>>> +{
>>>> +       /*
>>>> +        * For ACPI 5.1, only two kind of methods are provided,
>>>> +        * Parking protocol and PSCI, but Parking protocol is
>>>> +        * used on ARMv7 only, so make PSCI as the only method
>>>> +        * for SMP initialization before the ACPI spec or Parking
>>>> +        * protocol spec is updated.
>>>> +        */
>>>
>>> That comment is a little misleading. The parking protocol is _specified_
>>> for ARMv7 only.
>>
>> Agreed. But I'm just wondering if the Parking protocol is modified and
>> then support ARMv8, how to describe it in the comments?
> 
> We update the comments if and when that happens.

Ok.

Thanks
Hanjun

Re: [PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Sudeep Holla]

On 28/07/14 23:49, Graeme Gregory wrote:
>
> On 28/07/2014 19:29, Sudeep Holla wrote:
>>
>>
>> On 24/07/14 14:00, Hanjun Guo wrote:
>>> From: Al Stone <al.stone@linaro.org>
>>>
>>> As we want to get ACPI tables to parse and then use the information
>>> for system initialization, we should get the RSDP (Root System
>>> Description Pointer) first, it then locates Extended Root Description
>>> Table (XSDT) which contains all the 64-bit physical address that
>>> pointer to other boot-time tables.
>>>
>>> Introduce acpi.c and its related head file in this patch to provide
>>> fundamental needs of extern variables and functions for ACPI core,
>>> and then get boot-time tables as needed.
>>>     - asm/cpu.h need for ACPI core and will be updated in the future to
>>>       add definitions for arch_(un)register_cpu which are required for
>>>       ACPI based physical CPU hotplug;
>>>     - asm/acenv.h for arch specific ACPICA environments and
>>>       implementation;
>>>     - asm/acpi.h for arch specific variables and functions needed by
>>>       ACPI driver core;
>>>     - acpi.c for ARM64 related ACPI implementation for ACPI driver
>>>       core;
>>>
>>> acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
>>> it will be called in setup_arch() before paging_init(), so we should
>>> use eary_memremap() mechanism here to get the RSDP and all the table
>>> pointers.
>>>
>>> Signed-off-by: Al Stone <al.stone@linaro.org>
>>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> ---
>>>    arch/arm64/include/asm/acenv.h |   18 ++++++++++
>>>    arch/arm64/include/asm/acpi.h  |   41 ++++++++++++++++++++++
>>>    arch/arm64/include/asm/cpu.h   |   11 ++++++
>>>    arch/arm64/kernel/Makefile     |    1 +
>>>    arch/arm64/kernel/acpi.c       |   76
>>> ++++++++++++++++++++++++++++++++++++++++
>>>    arch/arm64/kernel/setup.c      |    4 +++
>>>    6 files changed, 151 insertions(+)
>>>    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/cpu.h
>>>    create mode 100644 arch/arm64/kernel/acpi.c
>>>

[...]

>>> +
>>> +/*
>>> + * MADT must provide at least one GICC structure
>>> + * for GIC initialization, so CPU will be
>>> + * always available in MADT on ARM64
>>> + */
>>> +static inline bool acpi_has_cpu_in_madt(void)
>>> +{
>>> +       return 1;
>>> +}
>>> +
>>
>> I don't see the user of this function in the series, it's better to
>> remove. Moreover the comment is so misleading. We will have CPU UID
>> not the CPU itself in MADT.
>>
> This is actually required for a patch that is now upstreamed. Comment
> should actually say that its checking for the posibility that the CPU
> can be initialised from the MADT. Its used from core in crash kernel
> case where boot CPU is not necessarily CPU0 like spec demands.
>

Ah OK, I now see that in Rafael's linux-pm/linux-next. Sorry I might have
missed to notice that and I assumed this series is based on mainline.

Regards,
Sudeep

Re: [PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Sudeep Holla]

On 28/07/14 23:49, Graeme Gregory wrote:
>
> On 28/07/2014 19:29, Sudeep Holla wrote:
>>
>>
>> On 24/07/14 14:00, Hanjun Guo wrote:
>>> From: Al Stone <al.stone@linaro.org>
>>>
>>> As we want to get ACPI tables to parse and then use the information
>>> for system initialization, we should get the RSDP (Root System
>>> Description Pointer) first, it then locates Extended Root Description
>>> Table (XSDT) which contains all the 64-bit physical address that
>>> pointer to other boot-time tables.
>>>
>>> Introduce acpi.c and its related head file in this patch to provide
>>> fundamental needs of extern variables and functions for ACPI core,
>>> and then get boot-time tables as needed.
>>>     - asm/cpu.h need for ACPI core and will be updated in the future to
>>>       add definitions for arch_(un)register_cpu which are required for
>>>       ACPI based physical CPU hotplug;
>>>     - asm/acenv.h for arch specific ACPICA environments and
>>>       implementation;
>>>     - asm/acpi.h for arch specific variables and functions needed by
>>>       ACPI driver core;
>>>     - acpi.c for ARM64 related ACPI implementation for ACPI driver
>>>       core;
>>>
>>> acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
>>> it will be called in setup_arch() before paging_init(), so we should
>>> use eary_memremap() mechanism here to get the RSDP and all the table
>>> pointers.
>>>
>>> Signed-off-by: Al Stone <al.stone@linaro.org>
>>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> ---
>>>    arch/arm64/include/asm/acenv.h |   18 ++++++++++
>>>    arch/arm64/include/asm/acpi.h  |   41 ++++++++++++++++++++++
>>>    arch/arm64/include/asm/cpu.h   |   11 ++++++
>>>    arch/arm64/kernel/Makefile     |    1 +
>>>    arch/arm64/kernel/acpi.c       |   76
>>> ++++++++++++++++++++++++++++++++++++++++
>>>    arch/arm64/kernel/setup.c      |    4 +++
>>>    6 files changed, 151 insertions(+)
>>>    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/cpu.h
>>>    create mode 100644 arch/arm64/kernel/acpi.c
>>>

[...]

>>> +
>>> +/*
>>> + * MADT must provide at least one GICC structure
>>> + * for GIC initialization, so CPU will be
>>> + * always available in MADT on ARM64
>>> + */
>>> +static inline bool acpi_has_cpu_in_madt(void)
>>> +{
>>> +       return 1;
>>> +}
>>> +
>>
>> I don't see the user of this function in the series, it's better to
>> remove. Moreover the comment is so misleading. We will have CPU UID
>> not the CPU itself in MADT.
>>
> This is actually required for a patch that is now upstreamed. Comment
> should actually say that its checking for the posibility that the CPU
> can be initialised from the MADT. Its used from core in crash kernel
> case where boot CPU is not necessarily CPU0 like spec demands.
>

Ah OK, I now see that in Rafael's linux-pm/linux-next. Sorry I might have
missed to notice that and I assumed this series is based on mainline.

Regards,
Sudeep

[PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Sudeep Holla]

On 28/07/14 23:49, Graeme Gregory wrote:
>
> On 28/07/2014 19:29, Sudeep Holla wrote:
>>
>>
>> On 24/07/14 14:00, Hanjun Guo wrote:
>>> From: Al Stone <al.stone@linaro.org>
>>>
>>> As we want to get ACPI tables to parse and then use the information
>>> for system initialization, we should get the RSDP (Root System
>>> Description Pointer) first, it then locates Extended Root Description
>>> Table (XSDT) which contains all the 64-bit physical address that
>>> pointer to other boot-time tables.
>>>
>>> Introduce acpi.c and its related head file in this patch to provide
>>> fundamental needs of extern variables and functions for ACPI core,
>>> and then get boot-time tables as needed.
>>>     - asm/cpu.h need for ACPI core and will be updated in the future to
>>>       add definitions for arch_(un)register_cpu which are required for
>>>       ACPI based physical CPU hotplug;
>>>     - asm/acenv.h for arch specific ACPICA environments and
>>>       implementation;
>>>     - asm/acpi.h for arch specific variables and functions needed by
>>>       ACPI driver core;
>>>     - acpi.c for ARM64 related ACPI implementation for ACPI driver
>>>       core;
>>>
>>> acpi_boot_table_init() is introduced to get RSDP and boot-time tables,
>>> it will be called in setup_arch() before paging_init(), so we should
>>> use eary_memremap() mechanism here to get the RSDP and all the table
>>> pointers.
>>>
>>> Signed-off-by: Al Stone <al.stone@linaro.org>
>>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> ---
>>>    arch/arm64/include/asm/acenv.h |   18 ++++++++++
>>>    arch/arm64/include/asm/acpi.h  |   41 ++++++++++++++++++++++
>>>    arch/arm64/include/asm/cpu.h   |   11 ++++++
>>>    arch/arm64/kernel/Makefile     |    1 +
>>>    arch/arm64/kernel/acpi.c       |   76
>>> ++++++++++++++++++++++++++++++++++++++++
>>>    arch/arm64/kernel/setup.c      |    4 +++
>>>    6 files changed, 151 insertions(+)
>>>    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/cpu.h
>>>    create mode 100644 arch/arm64/kernel/acpi.c
>>>

[...]

>>> +
>>> +/*
>>> + * MADT must provide at least one GICC structure
>>> + * for GIC initialization, so CPU will be
>>> + * always available in MADT on ARM64
>>> + */
>>> +static inline bool acpi_has_cpu_in_madt(void)
>>> +{
>>> +       return 1;
>>> +}
>>> +
>>
>> I don't see the user of this function in the series, it's better to
>> remove. Moreover the comment is so misleading. We will have CPU UID
>> not the CPU itself in MADT.
>>
> This is actually required for a patch that is now upstreamed. Comment
> should actually say that its checking for the posibility that the CPU
> can be initialised from the MADT. Its used from core in crash kernel
> case where boot CPU is not necessarily CPU0 like spec demands.
>

Ah OK, I now see that in Rafael's linux-pm/linux-next. Sorry I might have
missed to notice that and I assumed this series is based on mainline.

Regards,
Sudeep

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-7-28 17:07, Arnd Bergmann wrote:
> On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
>> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>>> +Relationship with Device Tree
>>> +-----------------------------
>>> +
>>> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>>> +exclusive with DT support at compile time.
>>> +
>>> +At boot time the kernel will only use one description method depending on
>>> +parameters passed from the bootloader.
>>
>> Possibly overriden by kernel bootargs. And as debated for quite a
>> while earlier this year, acpi should still default to off -- if a DT
>> and ACPI are both passed in, DT should at this time be given priority.
> 
> I think this would be harder to do with the way that ACPI is passed in
> to the kernel. IIRC, you always have a minimal DT information based on
> the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> to the ACPI tables, which are then used for populating the Linux platform
> devices (unless acpi=disabled is set), while the other contents of the
> DTB may be present but we skip the of_platform_populate state.
> 
> If this is correct, then replacing the firmware-generated dtb with a
> user-provided on would implicitly remove the ACPI tables from visibility,
> which is exactly what we want.
> 
> It's possible that I'm misremembering it though, and it should be
> documented better.
> 
>>> +Regardless of whether DT or ACPI is used, the kernel must always be capable
>>> +of booting with either scheme.
>>
>> It should always be possible to compile out ACPI. There will be plenty
>> of platforms that will not implement it, so disabling CONFIG_ACPI
>> needs to be possible.
> 
> Right.

Actually, if platforms don't implement ACPI, acpi_disabled will always be set to
1 at early boot stage which before the device tree is unflattened, so device
tree will work as expected even if CONFIG_ACPI=y on such platforms.

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-7-28 17:07, Arnd Bergmann wrote:
> On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
>> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>>> +Relationship with Device Tree
>>> +-----------------------------
>>> +
>>> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>>> +exclusive with DT support at compile time.
>>> +
>>> +At boot time the kernel will only use one description method depending on
>>> +parameters passed from the bootloader.
>>
>> Possibly overriden by kernel bootargs. And as debated for quite a
>> while earlier this year, acpi should still default to off -- if a DT
>> and ACPI are both passed in, DT should at this time be given priority.
> 
> I think this would be harder to do with the way that ACPI is passed in
> to the kernel. IIRC, you always have a minimal DT information based on
> the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> to the ACPI tables, which are then used for populating the Linux platform
> devices (unless acpi=disabled is set), while the other contents of the
> DTB may be present but we skip the of_platform_populate state.
> 
> If this is correct, then replacing the firmware-generated dtb with a
> user-provided on would implicitly remove the ACPI tables from visibility,
> which is exactly what we want.
> 
> It's possible that I'm misremembering it though, and it should be
> documented better.
> 
>>> +Regardless of whether DT or ACPI is used, the kernel must always be capable
>>> +of booting with either scheme.
>>
>> It should always be possible to compile out ACPI. There will be plenty
>> of platforms that will not implement it, so disabling CONFIG_ACPI
>> needs to be possible.
> 
> Right.

Actually, if platforms don't implement ACPI, acpi_disabled will always be set to
1 at early boot stage which before the device tree is unflattened, so device
tree will work as expected even if CONFIG_ACPI=y on such platforms.

Thanks
Hanjun

[PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-7-28 17:07, Arnd Bergmann wrote:
> On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
>> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>>> +Relationship with Device Tree
>>> +-----------------------------
>>> +
>>> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>>> +exclusive with DT support at compile time.
>>> +
>>> +At boot time the kernel will only use one description method depending on
>>> +parameters passed from the bootloader.
>>
>> Possibly overriden by kernel bootargs. And as debated for quite a
>> while earlier this year, acpi should still default to off -- if a DT
>> and ACPI are both passed in, DT should at this time be given priority.
> 
> I think this would be harder to do with the way that ACPI is passed in
> to the kernel. IIRC, you always have a minimal DT information based on
> the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> to the ACPI tables, which are then used for populating the Linux platform
> devices (unless acpi=disabled is set), while the other contents of the
> DTB may be present but we skip the of_platform_populate state.
> 
> If this is correct, then replacing the firmware-generated dtb with a
> user-provided on would implicitly remove the ACPI tables from visibility,
> which is exactly what we want.
> 
> It's possible that I'm misremembering it though, and it should be
> documented better.
> 
>>> +Regardless of whether DT or ACPI is used, the kernel must always be capable
>>> +of booting with either scheme.
>>
>> It should always be possible to compile out ACPI. There will be plenty
>> of platforms that will not implement it, so disabling CONFIG_ACPI
>> needs to be possible.
> 
> Right.

Actually, if platforms don't implement ACPI, acpi_disabled will always be set to
1 at early boot stage which before the device tree is unflattened, so device
tree will work as expected even if CONFIG_ACPI=y on such platforms.

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Graeme Gregory]

On 28/07/2014 17:14, Andre Przywara wrote:
>
> On 28/07/14 16:23, Arnd Bergmann wrote:
>> On Monday 28 July 2014 15:20:06 Andre Przywara wrote:
>>> On 28/07/14 11:46, Arnd Bergmann wrote:
>>>> On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
>>>>> The PL011 UART is the use-case I keep hitting, that IP block has a
>>>>> variable input clock on pretty much everything I have seen in the wild.
>>>> Ok, I see. What does ACPI-5.1 say about pl011?
>>>>
>>>> Interestingly, the subset of pl011 that is specified by SBSA does not
>>>> contain the IBRD/FBRD registers, effectively making it a fixed-rated
>>>> UART (I guess that would be a ART, without the U then), and you
>>>> consequently don't even need to know the clock rate.
>>> The idea of this was probably to let the baudrate set by some firmware
>>> code to the "right" value and the spec just didn't want to expose the
>>> details for the generic UART:
>>> "This specification does not cover registers needed to configure the
>>> UART as these are considered hardware-specific and will be set up by
>>> hardware-specific software."
>>> To me that reads like the SBSA UART is just for debugging, and you are
>>> expected just to access the data register.
>> Right, makes sense. It also avoids the case where Linux for some reason
>> ends up using a different line rate than the firmware, which can
>> cause a lot of unnecessary pain.
I must be suffering snow blindness reading specs, I totally missed that 
the pl011 subset does not allow baud setting. This means that my current 
test hardware "Juno" does not actually need any clocks defined in DSDT 
at this stage (given that this new driver is created).

I may then return to my original opinion of not defining clocks in the 
DSDT at all.

Graeme

>>>> However, my guess is that most hardware in the real world contains
>>>> an actual pl011 and it does make a lot of sense to allow setting
>>>> the baud rate on it, which then requires knowing the input clock.
>>>>
>>>> If there is any hardware that implements just the SBSA-mandated subset
>>>> rather than the full pl011, we should probably implement both
>>>> in the kernel: a dumb driver that can only send and receive, and the
>>>> more complex one that can set the bit rates and flow-control but that
>>>> requires a standardized ACPI table with the input clock rate.
>>> The fast model I use can be switched to use the SBSA restricted PL011,
>>> and as expected the Linux kernel crashes at the device doesn't support
>>> DMA (and a lot more stuff) - but the current code requires it.
>> It does? We have a lot of platforms that don't have DMA support for
>> pl011.
> Well, to be honest I just booted the full featured kernel with the
> changed fast model config, so the platform and the DT claimed DMA
> support, just the emulated hardware doesn't implement it ;-)
> And beside that a whole lot of other PL011 registers are not available,
> so the crash could be caused by anything. I didn't look to closely why
> it broke.
>
>>> So I am about to implement a new driver for that SBSA subset. So far
>>> this will be a separate driver, starting from a copy of amba-pl011.c,
>>> but removing most of the code ;-)
>> Ok. You might want to consider starting from a different base though.
>> IIRC, pl011 uses uart_port as the basic abstraction, while the
>> new driver should probably use the raw tty_port instead.
>> drivers/tty/goldfish.c is probably a good example to look at for
>> that.
> Good hint, will look at this.
>
> Cheers,
> Andre.
>
>> You could also make it a hvc_driver like drivers/tty/hvc/hvc_vio.c,
>> but I'm not sure if that model seen favorable by the tty maintainers.
>> It would probably be the shortest driver though.
>>
>> 	Arnd
>>
>>

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Graeme Gregory]

On 28/07/2014 17:14, Andre Przywara wrote:
>
> On 28/07/14 16:23, Arnd Bergmann wrote:
>> On Monday 28 July 2014 15:20:06 Andre Przywara wrote:
>>> On 28/07/14 11:46, Arnd Bergmann wrote:
>>>> On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
>>>>> The PL011 UART is the use-case I keep hitting, that IP block has a
>>>>> variable input clock on pretty much everything I have seen in the wild.
>>>> Ok, I see. What does ACPI-5.1 say about pl011?
>>>>
>>>> Interestingly, the subset of pl011 that is specified by SBSA does not
>>>> contain the IBRD/FBRD registers, effectively making it a fixed-rated
>>>> UART (I guess that would be a ART, without the U then), and you
>>>> consequently don't even need to know the clock rate.
>>> The idea of this was probably to let the baudrate set by some firmware
>>> code to the "right" value and the spec just didn't want to expose the
>>> details for the generic UART:
>>> "This specification does not cover registers needed to configure the
>>> UART as these are considered hardware-specific and will be set up by
>>> hardware-specific software."
>>> To me that reads like the SBSA UART is just for debugging, and you are
>>> expected just to access the data register.
>> Right, makes sense. It also avoids the case where Linux for some reason
>> ends up using a different line rate than the firmware, which can
>> cause a lot of unnecessary pain.
I must be suffering snow blindness reading specs, I totally missed that 
the pl011 subset does not allow baud setting. This means that my current 
test hardware "Juno" does not actually need any clocks defined in DSDT 
at this stage (given that this new driver is created).

I may then return to my original opinion of not defining clocks in the 
DSDT at all.

Graeme

>>>> However, my guess is that most hardware in the real world contains
>>>> an actual pl011 and it does make a lot of sense to allow setting
>>>> the baud rate on it, which then requires knowing the input clock.
>>>>
>>>> If there is any hardware that implements just the SBSA-mandated subset
>>>> rather than the full pl011, we should probably implement both
>>>> in the kernel: a dumb driver that can only send and receive, and the
>>>> more complex one that can set the bit rates and flow-control but that
>>>> requires a standardized ACPI table with the input clock rate.
>>> The fast model I use can be switched to use the SBSA restricted PL011,
>>> and as expected the Linux kernel crashes at the device doesn't support
>>> DMA (and a lot more stuff) - but the current code requires it.
>> It does? We have a lot of platforms that don't have DMA support for
>> pl011.
> Well, to be honest I just booted the full featured kernel with the
> changed fast model config, so the platform and the DT claimed DMA
> support, just the emulated hardware doesn't implement it ;-)
> And beside that a whole lot of other PL011 registers are not available,
> so the crash could be caused by anything. I didn't look to closely why
> it broke.
>
>>> So I am about to implement a new driver for that SBSA subset. So far
>>> this will be a separate driver, starting from a copy of amba-pl011.c,
>>> but removing most of the code ;-)
>> Ok. You might want to consider starting from a different base though.
>> IIRC, pl011 uses uart_port as the basic abstraction, while the
>> new driver should probably use the raw tty_port instead.
>> drivers/tty/goldfish.c is probably a good example to look at for
>> that.
> Good hint, will look at this.
>
> Cheers,
> Andre.
>
>> You could also make it a hvc_driver like drivers/tty/hvc/hvc_vio.c,
>> but I'm not sure if that model seen favorable by the tty maintainers.
>> It would probably be the shortest driver though.
>>
>> 	Arnd
>>
>>

[PATCH 19/19] Documentation: ACPI for ARM64

[Graeme Gregory]

On 28/07/2014 17:14, Andre Przywara wrote:
>
> On 28/07/14 16:23, Arnd Bergmann wrote:
>> On Monday 28 July 2014 15:20:06 Andre Przywara wrote:
>>> On 28/07/14 11:46, Arnd Bergmann wrote:
>>>> On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
>>>>> The PL011 UART is the use-case I keep hitting, that IP block has a
>>>>> variable input clock on pretty much everything I have seen in the wild.
>>>> Ok, I see. What does ACPI-5.1 say about pl011?
>>>>
>>>> Interestingly, the subset of pl011 that is specified by SBSA does not
>>>> contain the IBRD/FBRD registers, effectively making it a fixed-rated
>>>> UART (I guess that would be a ART, without the U then), and you
>>>> consequently don't even need to know the clock rate.
>>> The idea of this was probably to let the baudrate set by some firmware
>>> code to the "right" value and the spec just didn't want to expose the
>>> details for the generic UART:
>>> "This specification does not cover registers needed to configure the
>>> UART as these are considered hardware-specific and will be set up by
>>> hardware-specific software."
>>> To me that reads like the SBSA UART is just for debugging, and you are
>>> expected just to access the data register.
>> Right, makes sense. It also avoids the case where Linux for some reason
>> ends up using a different line rate than the firmware, which can
>> cause a lot of unnecessary pain.
I must be suffering snow blindness reading specs, I totally missed that 
the pl011 subset does not allow baud setting. This means that my current 
test hardware "Juno" does not actually need any clocks defined in DSDT 
at this stage (given that this new driver is created).

I may then return to my original opinion of not defining clocks in the 
DSDT at all.

Graeme

>>>> However, my guess is that most hardware in the real world contains
>>>> an actual pl011 and it does make a lot of sense to allow setting
>>>> the baud rate on it, which then requires knowing the input clock.
>>>>
>>>> If there is any hardware that implements just the SBSA-mandated subset
>>>> rather than the full pl011, we should probably implement both
>>>> in the kernel: a dumb driver that can only send and receive, and the
>>>> more complex one that can set the bit rates and flow-control but that
>>>> requires a standardized ACPI table with the input clock rate.
>>> The fast model I use can be switched to use the SBSA restricted PL011,
>>> and as expected the Linux kernel crashes at the device doesn't support
>>> DMA (and a lot more stuff) - but the current code requires it.
>> It does? We have a lot of platforms that don't have DMA support for
>> pl011.
> Well, to be honest I just booted the full featured kernel with the
> changed fast model config, so the platform and the DT claimed DMA
> support, just the emulated hardware doesn't implement it ;-)
> And beside that a whole lot of other PL011 registers are not available,
> so the crash could be caused by anything. I didn't look to closely why
> it broke.
>
>>> So I am about to implement a new driver for that SBSA subset. So far
>>> this will be a separate driver, starting from a copy of amba-pl011.c,
>>> but removing most of the code ;-)
>> Ok. You might want to consider starting from a different base though.
>> IIRC, pl011 uses uart_port as the basic abstraction, while the
>> new driver should probably use the raw tty_port instead.
>> drivers/tty/goldfish.c is probably a good example to look at for
>> that.
> Good hint, will look at this.
>
> Cheers,
> Andre.
>
>> You could also make it a hvc_driver like drivers/tty/hvc/hvc_vio.c,
>> but I'm not sure if that model seen favorable by the tty maintainers.
>> It would probably be the shortest driver though.
>>
>> 	Arnd
>>
>>

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Tuesday 29 July 2014 10:17:22 Graeme Gregory wrote:
> On 28/07/2014 17:14, Andre Przywara wrote:
> >
> > On 28/07/14 16:23, Arnd Bergmann wrote:
> >> On Monday 28 July 2014 15:20:06 Andre Przywara wrote:
> >>> On 28/07/14 11:46, Arnd Bergmann wrote:
> >>>> On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
> >>>>> The PL011 UART is the use-case I keep hitting, that IP block has a
> >>>>> variable input clock on pretty much everything I have seen in the wild.
> >>>> Ok, I see. What does ACPI-5.1 say about pl011?
> >>>>
> >>>> Interestingly, the subset of pl011 that is specified by SBSA does not
> >>>> contain the IBRD/FBRD registers, effectively making it a fixed-rated
> >>>> UART (I guess that would be a ART, without the U then), and you
> >>>> consequently don't even need to know the clock rate.
> >>> The idea of this was probably to let the baudrate set by some firmware
> >>> code to the "right" value and the spec just didn't want to expose the
> >>> details for the generic UART:
> >>> "This specification does not cover registers needed to configure the
> >>> UART as these are considered hardware-specific and will be set up by
> >>> hardware-specific software."
> >>> To me that reads like the SBSA UART is just for debugging, and you are
> >>> expected just to access the data register.
> >> Right, makes sense. It also avoids the case where Linux for some reason
> >> ends up using a different line rate than the firmware, which can
> >> cause a lot of unnecessary pain.
> I must be suffering snow blindness reading specs, I totally missed that 
> the pl011 subset does not allow baud setting. This means that my current 
> test hardware "Juno" does not actually need any clocks defined in DSDT 
> at this stage (given that this new driver is created).
> 
> I may then return to my original opinion of not defining clocks in the 
> DSDT at all.

Ok, that certainly simplifies it a lot, thanks!

	Arnd

[PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Tuesday 29 July 2014 10:17:22 Graeme Gregory wrote:
> On 28/07/2014 17:14, Andre Przywara wrote:
> >
> > On 28/07/14 16:23, Arnd Bergmann wrote:
> >> On Monday 28 July 2014 15:20:06 Andre Przywara wrote:
> >>> On 28/07/14 11:46, Arnd Bergmann wrote:
> >>>> On Monday 28 July 2014 10:23:57 Graeme Gregory wrote:
> >>>>> The PL011 UART is the use-case I keep hitting, that IP block has a
> >>>>> variable input clock on pretty much everything I have seen in the wild.
> >>>> Ok, I see. What does ACPI-5.1 say about pl011?
> >>>>
> >>>> Interestingly, the subset of pl011 that is specified by SBSA does not
> >>>> contain the IBRD/FBRD registers, effectively making it a fixed-rated
> >>>> UART (I guess that would be a ART, without the U then), and you
> >>>> consequently don't even need to know the clock rate.
> >>> The idea of this was probably to let the baudrate set by some firmware
> >>> code to the "right" value and the spec just didn't want to expose the
> >>> details for the generic UART:
> >>> "This specification does not cover registers needed to configure the
> >>> UART as these are considered hardware-specific and will be set up by
> >>> hardware-specific software."
> >>> To me that reads like the SBSA UART is just for debugging, and you are
> >>> expected just to access the data register.
> >> Right, makes sense. It also avoids the case where Linux for some reason
> >> ends up using a different line rate than the firmware, which can
> >> cause a lot of unnecessary pain.
> I must be suffering snow blindness reading specs, I totally missed that 
> the pl011 subset does not allow baud setting. This means that my current 
> test hardware "Juno" does not actually need any clocks defined in DSDT 
> at this stage (given that this new driver is created).
> 
> I may then return to my original opinion of not defining clocks in the 
> DSDT at all.

Ok, that certainly simplifies it a lot, thanks!

	Arnd

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On Thu, Jul 24, 2014 at 02:19:14PM -0700, Randy Dunlap wrote:
> On 07/24/2014 02:16 PM, Naresh Bhat wrote:
> > 
> > On 24 July 2014 18:30, Hanjun Guo <hanjun.guo@linaro.org <mailto:hanjun.guo@linaro.org>> wrote:
> > 
> >     From: Graeme Gregory <graeme.gregory@linaro.org <mailto:graeme.gregory@linaro.org>>
> > 
> >     Add documentation for the guidelines of how to use ACPI
> >     on ARM64.
> > 
> >     Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org <mailto:graeme.gregory@linaro.org>>
> >     Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org <mailto:hanjun.guo@linaro.org>>
> >     ---
> >      Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
> >      1 file changed, 240 insertions(+)
> >      create mode 100644 Documentation/arm64/arm-acpi.txt
> > 
> >     diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> >     new file mode 100644
> >     index 0000000..12cd550
> >     --- /dev/null
> >     +++ b/Documentation/arm64/arm-acpi.txt
> >     @@ -0,0 +1,240 @@
> >     +ACPI on ARMv8 Servers
> >     +---------------------
> >     +
> >     +ACPI will be used for ARMv8 general purpose servers designed to follow
> >     +the SBSA specification (currently available to people with an ARM login at
> >     +http://silver.arm.com)
> >     +
> >     +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> >     +which is available at <http://www.uefi.org/acpi/specs>.
> >     +
> >     +If the machine does not meet these requirements then it is likely that Device
> >     +Tree (DT) is more suitable for the hardware.
> >     +
> >     +Relationship with Device Tree
> >     +-----------------------------
> >     +
> >     +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> >     +exclusive with DT support at compile time.
> >     +
> >     +At boot time the kernel will only use one description method depending on
> >     +parameters passed from the bootloader.
> >     +
> >     +Regardless of whether DT or ACPI is used, the kernel must always be capable
> >     +of booting with either scheme.
> >     +
> >     +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.
> >     +
> >     +Booting using ACPI tables
> >     +-------------------------
> >     +
> >     +Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
> >     +is via the UEFI system configuration table.
> >     +
> >     +The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
> >     +RSDP table (the table with the ACPI signature "RSD PTR ").
> >     +
> >     +The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
> >     +
> >     +Processing of ACPI tables may be disabled by passing acpi=off on the kernel
> >     +command line.
> >     +
> >     +DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
> >     +only allow for 32bit addresses.
> >     +
> >     +DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
> >     +64-bit alternatives MUST be used.
> >     +
> >     +The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
> >     +and GTDT. If PCI is used the MCFG table MUST also be present.
> >     +
> >     +ACPI Detection
> >     +--------------
> >     +
> >     +Drivers should determine their probe() type by checking for ACPI_HANDLE,
> >     +or .of_node, or other information in the device structure. This is
> >     +detailed further in the "Driver Recomendations" section.
> >     +
> >     +If the presence of ACPI needs to be detected at runtime, then check the value
> >     +of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
> >     +
> >     +Device Enumeration
> >     +------------------
> >     +
> >     +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> > 
> > 
> > recognized
> 
> Yeah, I saw all of these also, but we accept British or American spelling of these words.
> 
Would be good to check for a consistent spelling in this doc though.

-Christoffer

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On Thu, Jul 24, 2014 at 02:19:14PM -0700, Randy Dunlap wrote:
> On 07/24/2014 02:16 PM, Naresh Bhat wrote:
> > 
> > On 24 July 2014 18:30, Hanjun Guo <hanjun.guo@linaro.org <mailto:hanjun.guo@linaro.org>> wrote:
> > 
> >     From: Graeme Gregory <graeme.gregory@linaro.org <mailto:graeme.gregory@linaro.org>>
> > 
> >     Add documentation for the guidelines of how to use ACPI
> >     on ARM64.
> > 
> >     Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org <mailto:graeme.gregory@linaro.org>>
> >     Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org <mailto:hanjun.guo@linaro.org>>
> >     ---
> >      Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
> >      1 file changed, 240 insertions(+)
> >      create mode 100644 Documentation/arm64/arm-acpi.txt
> > 
> >     diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> >     new file mode 100644
> >     index 0000000..12cd550
> >     --- /dev/null
> >     +++ b/Documentation/arm64/arm-acpi.txt
> >     @@ -0,0 +1,240 @@
> >     +ACPI on ARMv8 Servers
> >     +---------------------
> >     +
> >     +ACPI will be used for ARMv8 general purpose servers designed to follow
> >     +the SBSA specification (currently available to people with an ARM login at
> >     +http://silver.arm.com)
> >     +
> >     +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> >     +which is available at <http://www.uefi.org/acpi/specs>.
> >     +
> >     +If the machine does not meet these requirements then it is likely that Device
> >     +Tree (DT) is more suitable for the hardware.
> >     +
> >     +Relationship with Device Tree
> >     +-----------------------------
> >     +
> >     +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> >     +exclusive with DT support at compile time.
> >     +
> >     +At boot time the kernel will only use one description method depending on
> >     +parameters passed from the bootloader.
> >     +
> >     +Regardless of whether DT or ACPI is used, the kernel must always be capable
> >     +of booting with either scheme.
> >     +
> >     +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.
> >     +
> >     +Booting using ACPI tables
> >     +-------------------------
> >     +
> >     +Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
> >     +is via the UEFI system configuration table.
> >     +
> >     +The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
> >     +RSDP table (the table with the ACPI signature "RSD PTR ").
> >     +
> >     +The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
> >     +
> >     +Processing of ACPI tables may be disabled by passing acpi=off on the kernel
> >     +command line.
> >     +
> >     +DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
> >     +only allow for 32bit addresses.
> >     +
> >     +DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
> >     +64-bit alternatives MUST be used.
> >     +
> >     +The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
> >     +and GTDT. If PCI is used the MCFG table MUST also be present.
> >     +
> >     +ACPI Detection
> >     +--------------
> >     +
> >     +Drivers should determine their probe() type by checking for ACPI_HANDLE,
> >     +or .of_node, or other information in the device structure. This is
> >     +detailed further in the "Driver Recomendations" section.
> >     +
> >     +If the presence of ACPI needs to be detected at runtime, then check the value
> >     +of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
> >     +
> >     +Device Enumeration
> >     +------------------
> >     +
> >     +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> > 
> > 
> > recognized
> 
> Yeah, I saw all of these also, but we accept British or American spelling of these words.
> 
Would be good to check for a consistent spelling in this doc though.

-Christoffer

[PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On Thu, Jul 24, 2014 at 02:19:14PM -0700, Randy Dunlap wrote:
> On 07/24/2014 02:16 PM, Naresh Bhat wrote:
> > 
> > On 24 July 2014 18:30, Hanjun Guo <hanjun.guo at linaro.org <mailto:hanjun.guo@linaro.org>> wrote:
> > 
> >     From: Graeme Gregory <graeme.gregory at linaro.org <mailto:graeme.gregory@linaro.org>>
> > 
> >     Add documentation for the guidelines of how to use ACPI
> >     on ARM64.
> > 
> >     Signed-off-by: Graeme Gregory <graeme.gregory at linaro.org <mailto:graeme.gregory@linaro.org>>
> >     Signed-off-by: Hanjun Guo <hanjun.guo at linaro.org <mailto:hanjun.guo@linaro.org>>
> >     ---
> >      Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
> >      1 file changed, 240 insertions(+)
> >      create mode 100644 Documentation/arm64/arm-acpi.txt
> > 
> >     diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> >     new file mode 100644
> >     index 0000000..12cd550
> >     --- /dev/null
> >     +++ b/Documentation/arm64/arm-acpi.txt
> >     @@ -0,0 +1,240 @@
> >     +ACPI on ARMv8 Servers
> >     +---------------------
> >     +
> >     +ACPI will be used for ARMv8 general purpose servers designed to follow
> >     +the SBSA specification (currently available to people with an ARM login at
> >     +http://silver.arm.com)
> >     +
> >     +The implemented ACPI version is 5.1 + errata as released by the UEFI Forum,
> >     +which is available at <http://www.uefi.org/acpi/specs>.
> >     +
> >     +If the machine does not meet these requirements then it is likely that Device
> >     +Tree (DT) is more suitable for the hardware.
> >     +
> >     +Relationship with Device Tree
> >     +-----------------------------
> >     +
> >     +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> >     +exclusive with DT support at compile time.
> >     +
> >     +At boot time the kernel will only use one description method depending on
> >     +parameters passed from the bootloader.
> >     +
> >     +Regardless of whether DT or ACPI is used, the kernel must always be capable
> >     +of booting with either scheme.
> >     +
> >     +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.
> >     +
> >     +Booting using ACPI tables
> >     +-------------------------
> >     +
> >     +Currently, the only defined method to pass ACPI tables to the kernel on ARMv8
> >     +is via the UEFI system configuration table.
> >     +
> >     +The UEFI implementation MUST set the ACPI_20_TABLE_GUID to point to the
> >     +RSDP table (the table with the ACPI signature "RSD PTR ").
> >     +
> >     +The pointer to the RSDP table will be retrieved from EFI by the ACPI core.
> >     +
> >     +Processing of ACPI tables may be disabled by passing acpi=off on the kernel
> >     +command line.
> >     +
> >     +DO use an XSDT, RSDTs are deprecated and should not be used on arm64. They
> >     +only allow for 32bit addresses.
> >     +
> >     +DO NOT use the 32-bit address fields in the FADT, they are deprecated, the
> >     +64-bit alternatives MUST be used.
> >     +
> >     +The minimum set of tables MUST include RSDP, XSDT, FACS, FADT, DSDT, MADT
> >     +and GTDT. If PCI is used the MCFG table MUST also be present.
> >     +
> >     +ACPI Detection
> >     +--------------
> >     +
> >     +Drivers should determine their probe() type by checking for ACPI_HANDLE,
> >     +or .of_node, or other information in the device structure. This is
> >     +detailed further in the "Driver Recomendations" section.
> >     +
> >     +If the presence of ACPI needs to be detected at runtime, then check the value
> >     +of acpi_disabled. If CONFIG_ACPI not being set acpi_disabled will always be 1.
> >     +
> >     +Device Enumeration
> >     +------------------
> >     +
> >     +Device descriptions in ACPI should use standard recognised ACPI interfaces.
> > 
> > 
> > recognized
> 
> Yeah, I saw all of these also, but we accept British or American spelling of these words.
> 
Would be good to check for a consistent spelling in this doc though.

-Christoffer

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On Mon, Jul 28, 2014 at 09:44:59AM -0700, Olof Johansson wrote:
> On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:

[...]

> > >
> > > > +Relationship with Device Tree
> > > > +-----------------------------
> > > > +
> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > > +exclusive with DT support at compile time.
> > > > +
> > > > +At boot time the kernel will only use one description method depending on
> > > > +parameters passed from the bootloader.
> > >
> > > Possibly overriden by kernel bootargs. And as debated for quite a
> > > while earlier this year, acpi should still default to off -- if a DT
> > > and ACPI are both passed in, DT should at this time be given priority.
> > 
> > Why? I really don't see the logic in doing that.
> 
> Seems like I am replying to your emails in reverse order.
> 
> > Currently the kernel can only boot using DT, so DT will be used even if
> > ACPI is present. In the presence of ACPI support in the kernel, ACPI
> > would be used on said systems.
> 
> For all the reasons we hashed out earlier this year: We can't trust that
> vendors will know how to do ACPI from day one, so instead of loading up the
> kernel with lots of quirks and workarounds, we'll default to not using it until
> we're at a point where things look mature enough.
> 
> The alternative is to keep this patch set out of the kernel. We can do that
> too, but I don't think that really helps anyone.
> 
> > From the discussions at the last Linaro Connect, this was seen as
> > important for virtual machines which want to provide ACPI services to
> > guests while still being able to boot DT-only kernels. I'll leave it to
> > Grant, Rob, and Christoffer to cover that.
> 
> Ok, waiting to see what they have to say then.
> 

Hmm, a virtual machine implementaion may provide either a DT or ACPI (or
both).  I think the point at Linaro Connect was that for a first cut,
there is no obvious need to provide ACPI to VMs and to be spec
compliant, server kernels must be able to boot with DT-only.  In most
cases such systems will only access a few limited emulated devices
(UART, GIC, RTC, flash controller) and VirtIO devices, which should just
work using DT only.

People are talking about adding ACPI for VM guests as well for various
reasons (device passthrough for example) in which case I would always
expect people to run UEFI inside their guests too (perhaps this is not
100% true in the case of Xen fast-boot scenarios though) and I would
expect Linux to only see the little stub DT and ACPI.

Does this clarify anything or add futher to the confusion?

-Christoffer

[PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On Mon, Jul 28, 2014 at 09:44:59AM -0700, Olof Johansson wrote:
> On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:

[...]

> > >
> > > > +Relationship with Device Tree
> > > > +-----------------------------
> > > > +
> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > > +exclusive with DT support at compile time.
> > > > +
> > > > +At boot time the kernel will only use one description method depending on
> > > > +parameters passed from the bootloader.
> > >
> > > Possibly overriden by kernel bootargs. And as debated for quite a
> > > while earlier this year, acpi should still default to off -- if a DT
> > > and ACPI are both passed in, DT should at this time be given priority.
> > 
> > Why? I really don't see the logic in doing that.
> 
> Seems like I am replying to your emails in reverse order.
> 
> > Currently the kernel can only boot using DT, so DT will be used even if
> > ACPI is present. In the presence of ACPI support in the kernel, ACPI
> > would be used on said systems.
> 
> For all the reasons we hashed out earlier this year: We can't trust that
> vendors will know how to do ACPI from day one, so instead of loading up the
> kernel with lots of quirks and workarounds, we'll default to not using it until
> we're at a point where things look mature enough.
> 
> The alternative is to keep this patch set out of the kernel. We can do that
> too, but I don't think that really helps anyone.
> 
> > From the discussions at the last Linaro Connect, this was seen as
> > important for virtual machines which want to provide ACPI services to
> > guests while still being able to boot DT-only kernels. I'll leave it to
> > Grant, Rob, and Christoffer to cover that.
> 
> Ok, waiting to see what they have to say then.
> 

Hmm, a virtual machine implementaion may provide either a DT or ACPI (or
both).  I think the point at Linaro Connect was that for a first cut,
there is no obvious need to provide ACPI to VMs and to be spec
compliant, server kernels must be able to boot with DT-only.  In most
cases such systems will only access a few limited emulated devices
(UART, GIC, RTC, flash controller) and VirtIO devices, which should just
work using DT only.

People are talking about adding ACPI for VM guests as well for various
reasons (device passthrough for example) in which case I would always
expect people to run UEFI inside their guests too (perhaps this is not
100% true in the case of Xen fast-boot scenarios though) and I would
expect Linux to only see the little stub DT and ACPI.

Does this clarify anything or add futher to the confusion?

-Christoffer

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On Thu, Jul 24, 2014 at 09:00:25PM +0800, Hanjun Guo wrote:
> From: Graeme Gregory <graeme.gregory@linaro.org>
> 
> Add documentation for the guidelines of how to use ACPI
> on ARM64.
> 
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 240 insertions(+)
>  create mode 100644 Documentation/arm64/arm-acpi.txt
> 
> diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> new file mode 100644
> index 0000000..12cd550
> --- /dev/null
> +++ b/Documentation/arm64/arm-acpi.txt
> @@ -0,0 +1,240 @@
> +ACPI on ARMv8 Servers
> +---------------------

[...]

> +
> +
> +There exists in the ACPI 5.1 specification no standard binding for these objects
> +to enable programmable levels or rates so this should be avoid if possible and
> +the resources set to appropriate level by the firmware. If this is not possible
> +then any manipulation should be abstracted in ASL.
> +

I'm not a native English speaker, but this wording sounds strange to me.
I would suggest "There exists no specification in the the..." or more
simply "The ACPI 5.1 specification does not contain any standard...".

-Christoffer

[PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On Thu, Jul 24, 2014 at 09:00:25PM +0800, Hanjun Guo wrote:
> From: Graeme Gregory <graeme.gregory@linaro.org>
> 
> Add documentation for the guidelines of how to use ACPI
> on ARM64.
> 
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>  Documentation/arm64/arm-acpi.txt |  240 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 240 insertions(+)
>  create mode 100644 Documentation/arm64/arm-acpi.txt
> 
> diff --git a/Documentation/arm64/arm-acpi.txt b/Documentation/arm64/arm-acpi.txt
> new file mode 100644
> index 0000000..12cd550
> --- /dev/null
> +++ b/Documentation/arm64/arm-acpi.txt
> @@ -0,0 +1,240 @@
> +ACPI on ARMv8 Servers
> +---------------------

[...]

> +
> +
> +There exists in the ACPI 5.1 specification no standard binding for these objects
> +to enable programmable levels or rates so this should be avoid if possible and
> +the resources set to appropriate level by the firmware. If this is not possible
> +then any manipulation should be abstracted in ASL.
> +

I'm not a native English speaker, but this wording sounds strange to me.
I would suggest "There exists no specification in the the..." or more
simply "The ACPI 5.1 specification does not contain any standard...".

-Christoffer

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Tuesday 29 July 2014 12:29:40 Christoffer Dall wrote:
> On Mon, Jul 28, 2014 at 09:44:59AM -0700, Olof Johansson wrote:
> > On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
> > 
> > > From the discussions at the last Linaro Connect, this was seen as
> > > important for virtual machines which want to provide ACPI services to
> > > guests while still being able to boot DT-only kernels. I'll leave it to
> > > Grant, Rob, and Christoffer to cover that.
> > 
> > Ok, waiting to see what they have to say then.
> > 
> 
> Hmm, a virtual machine implementaion may provide either a DT or ACPI (or
> both).  I think the point at Linaro Connect was that for a first cut,
> there is no obvious need to provide ACPI to VMs and to be spec
> compliant, server kernels must be able to boot with DT-only.  In most
> cases such systems will only access a few limited emulated devices
> (UART, GIC, RTC, flash controller) and VirtIO devices, which should just
> work using DT only.

Right

> People are talking about adding ACPI for VM guests as well for various
> reasons (device passthrough for example) in which case I would always
> expect people to run UEFI inside their guests too (perhaps this is not
> 100% true in the case of Xen fast-boot scenarios though) and I would
> expect Linux to only see the little stub DT and ACPI.
> 
> Does this clarify anything or add futher to the confusion?

I think the only reason that was given for ACPI in a virtual machine
was Red Hat's insistence on intentionally breaking DT support in their
enterprise distro.

I believe both the cases of device pass-through and running something
other than UEFI are outside of the scope of the standard virtual machine
model, for different reasons. Outside of that model, anybody is of course
free to run whatever they like in their guests.

	Arnd

[PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Tuesday 29 July 2014 12:29:40 Christoffer Dall wrote:
> On Mon, Jul 28, 2014 at 09:44:59AM -0700, Olof Johansson wrote:
> > On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
> > 
> > > From the discussions at the last Linaro Connect, this was seen as
> > > important for virtual machines which want to provide ACPI services to
> > > guests while still being able to boot DT-only kernels. I'll leave it to
> > > Grant, Rob, and Christoffer to cover that.
> > 
> > Ok, waiting to see what they have to say then.
> > 
> 
> Hmm, a virtual machine implementaion may provide either a DT or ACPI (or
> both).  I think the point at Linaro Connect was that for a first cut,
> there is no obvious need to provide ACPI to VMs and to be spec
> compliant, server kernels must be able to boot with DT-only.  In most
> cases such systems will only access a few limited emulated devices
> (UART, GIC, RTC, flash controller) and VirtIO devices, which should just
> work using DT only.

Right

> People are talking about adding ACPI for VM guests as well for various
> reasons (device passthrough for example) in which case I would always
> expect people to run UEFI inside their guests too (perhaps this is not
> 100% true in the case of Xen fast-boot scenarios though) and I would
> expect Linux to only see the little stub DT and ACPI.
> 
> Does this clarify anything or add futher to the confusion?

I think the only reason that was given for ACPI in a virtual machine
was Red Hat's insistence on intentionally breaking DT support in their
enterprise distro.

I believe both the cases of device pass-through and running something
other than UEFI are outside of the scope of the standard virtual machine
model, for different reasons. Outside of that model, anybody is of course
free to run whatever they like in their guests.

	Arnd

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Tue, Jul 29, 2014 at 11:29:40AM +0100, Christoffer Dall wrote:
> On Mon, Jul 28, 2014 at 09:44:59AM -0700, Olof Johansson wrote:
> > On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
> 
> [...]
> 
> > > >
> > > > > +Relationship with Device Tree
> > > > > +-----------------------------
> > > > > +
> > > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > > > +exclusive with DT support at compile time.
> > > > > +
> > > > > +At boot time the kernel will only use one description method depending on
> > > > > +parameters passed from the bootloader.
> > > >
> > > > Possibly overriden by kernel bootargs. And as debated for quite a
> > > > while earlier this year, acpi should still default to off -- if a DT
> > > > and ACPI are both passed in, DT should at this time be given priority.
> > > 
> > > Why? I really don't see the logic in doing that.
> > 
> > Seems like I am replying to your emails in reverse order.
> > 
> > > Currently the kernel can only boot using DT, so DT will be used even if
> > > ACPI is present. In the presence of ACPI support in the kernel, ACPI
> > > would be used on said systems.
> > 
> > For all the reasons we hashed out earlier this year: We can't trust that
> > vendors will know how to do ACPI from day one, so instead of loading up the
> > kernel with lots of quirks and workarounds, we'll default to not using it until
> > we're at a point where things look mature enough.
> > 
> > The alternative is to keep this patch set out of the kernel. We can do that
> > too, but I don't think that really helps anyone.
> > 
> > > From the discussions at the last Linaro Connect, this was seen as
> > > important for virtual machines which want to provide ACPI services to
> > > guests while still being able to boot DT-only kernels. I'll leave it to
> > > Grant, Rob, and Christoffer to cover that.
> > 
> > Ok, waiting to see what they have to say then.
> > 
> 
> Hmm, a virtual machine implementaion may provide either a DT or ACPI (or
> both).  I think the point at Linaro Connect was that for a first cut,
> there is no obvious need to provide ACPI to VMs and to be spec
> compliant, server kernels must be able to boot with DT-only.  In most
> cases such systems will only access a few limited emulated devices
> (UART, GIC, RTC, flash controller) and VirtIO devices, which should just
> work using DT only.
> 
> People are talking about adding ACPI for VM guests as well for various
> reasons (device passthrough for example) in which case I would always
> expect people to run UEFI inside their guests too (perhaps this is not
> 100% true in the case of Xen fast-boot scenarios though) and I would
> expect Linux to only see the little stub DT and ACPI.
> 
> Does this clarify anything or add futher to the confusion?

I was under the impression that there was a case where we'd have a DT
with HW description in a VM which also had ACPI tables, to enable a
kernel without ACPI support to boot in said VM (albeit with reduced
functionality).

I may have got confused since the VM standards discussion at LCA-14.

If we we expect a hypervisor to provide DT only by default (for
compatibility), and ACPI only when the user has explicitly enabled it
for an ACPI-specific feature, then that sounds OK.

Thanks,
Mark.

[PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Tue, Jul 29, 2014 at 11:29:40AM +0100, Christoffer Dall wrote:
> On Mon, Jul 28, 2014 at 09:44:59AM -0700, Olof Johansson wrote:
> > On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
> 
> [...]
> 
> > > >
> > > > > +Relationship with Device Tree
> > > > > +-----------------------------
> > > > > +
> > > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > > > +exclusive with DT support at compile time.
> > > > > +
> > > > > +At boot time the kernel will only use one description method depending on
> > > > > +parameters passed from the bootloader.
> > > >
> > > > Possibly overriden by kernel bootargs. And as debated for quite a
> > > > while earlier this year, acpi should still default to off -- if a DT
> > > > and ACPI are both passed in, DT should at this time be given priority.
> > > 
> > > Why? I really don't see the logic in doing that.
> > 
> > Seems like I am replying to your emails in reverse order.
> > 
> > > Currently the kernel can only boot using DT, so DT will be used even if
> > > ACPI is present. In the presence of ACPI support in the kernel, ACPI
> > > would be used on said systems.
> > 
> > For all the reasons we hashed out earlier this year: We can't trust that
> > vendors will know how to do ACPI from day one, so instead of loading up the
> > kernel with lots of quirks and workarounds, we'll default to not using it until
> > we're at a point where things look mature enough.
> > 
> > The alternative is to keep this patch set out of the kernel. We can do that
> > too, but I don't think that really helps anyone.
> > 
> > > From the discussions at the last Linaro Connect, this was seen as
> > > important for virtual machines which want to provide ACPI services to
> > > guests while still being able to boot DT-only kernels. I'll leave it to
> > > Grant, Rob, and Christoffer to cover that.
> > 
> > Ok, waiting to see what they have to say then.
> > 
> 
> Hmm, a virtual machine implementaion may provide either a DT or ACPI (or
> both).  I think the point at Linaro Connect was that for a first cut,
> there is no obvious need to provide ACPI to VMs and to be spec
> compliant, server kernels must be able to boot with DT-only.  In most
> cases such systems will only access a few limited emulated devices
> (UART, GIC, RTC, flash controller) and VirtIO devices, which should just
> work using DT only.
> 
> People are talking about adding ACPI for VM guests as well for various
> reasons (device passthrough for example) in which case I would always
> expect people to run UEFI inside their guests too (perhaps this is not
> 100% true in the case of Xen fast-boot scenarios though) and I would
> expect Linux to only see the little stub DT and ACPI.
> 
> Does this clarify anything or add futher to the confusion?

I was under the impression that there was a case where we'd have a DT
with HW description in a VM which also had ACPI tables, to enable a
kernel without ACPI support to boot in said VM (albeit with reduced
functionality).

I may have got confused since the VM standards discussion at LCA-14.

If we we expect a hypervisor to provide DT only by default (for
compatibility), and ACPI only when the user has explicitly enabled it
for an ACPI-specific feature, then that sounds OK.

Thanks,
Mark.

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Tue, Jul 29, 2014 at 11:55:43AM +0100, Mark Rutland wrote:
> On Tue, Jul 29, 2014 at 11:29:40AM +0100, Christoffer Dall wrote:
> > On Mon, Jul 28, 2014 at 09:44:59AM -0700, Olof Johansson wrote:
> > > On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
> > 
> > [...]
> > 
> > > > >
> > > > > > +Relationship with Device Tree
> > > > > > +-----------------------------
> > > > > > +
> > > > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > > > > +exclusive with DT support at compile time.
> > > > > > +
> > > > > > +At boot time the kernel will only use one description method depending on
> > > > > > +parameters passed from the bootloader.
> > > > >
> > > > > Possibly overriden by kernel bootargs. And as debated for quite a
> > > > > while earlier this year, acpi should still default to off -- if a DT
> > > > > and ACPI are both passed in, DT should at this time be given priority.
> > > > 
> > > > Why? I really don't see the logic in doing that.
> > > 
> > > Seems like I am replying to your emails in reverse order.
> > > 
> > > > Currently the kernel can only boot using DT, so DT will be used even if
> > > > ACPI is present. In the presence of ACPI support in the kernel, ACPI
> > > > would be used on said systems.
> > > 
> > > For all the reasons we hashed out earlier this year: We can't trust that
> > > vendors will know how to do ACPI from day one, so instead of loading up the
> > > kernel with lots of quirks and workarounds, we'll default to not using it until
> > > we're at a point where things look mature enough.
> > > 
> > > The alternative is to keep this patch set out of the kernel. We can do that
> > > too, but I don't think that really helps anyone.
> > > 
> > > > From the discussions at the last Linaro Connect, this was seen as
> > > > important for virtual machines which want to provide ACPI services to
> > > > guests while still being able to boot DT-only kernels. I'll leave it to
> > > > Grant, Rob, and Christoffer to cover that.
> > > 
> > > Ok, waiting to see what they have to say then.
> > > 
> > 
> > Hmm, a virtual machine implementaion may provide either a DT or ACPI (or
> > both).  I think the point at Linaro Connect was that for a first cut,
> > there is no obvious need to provide ACPI to VMs and to be spec
> > compliant, server kernels must be able to boot with DT-only.  In most
> > cases such systems will only access a few limited emulated devices
> > (UART, GIC, RTC, flash controller) and VirtIO devices, which should just
> > work using DT only.
> > 
> > People are talking about adding ACPI for VM guests as well for various
> > reasons (device passthrough for example) in which case I would always
> > expect people to run UEFI inside their guests too (perhaps this is not
> > 100% true in the case of Xen fast-boot scenarios though) and I would
> > expect Linux to only see the little stub DT and ACPI.
> > 
> > Does this clarify anything or add futher to the confusion?
> 
> I was under the impression that there was a case where we'd have a DT
> with HW description in a VM which also had ACPI tables, to enable a
> kernel without ACPI support to boot in said VM (albeit with reduced
> functionality).
> 
> I may have got confused since the VM standards discussion at LCA-14.

I took a look at the video [1,2] of said session [3], and it looks like
I was the one arguing for the case of full description in both DT and
ACPI, so either I was confused or I've forgotten some hallway
discussion.

I think my reasoning was somewhat flawed; if the hypervisor defaults to
providing DT, with an option to use ACPI in certain cases (where not all
guests would be expected to work), then that would cover the "grab an
iso, it just works™" use case for Linux images while allowing for
the cases where people want ACPI in the VM.

The only issue with that would be catering for OSs which support ACPI
but not DT or whose DT support is not Linux-compatible.

Thanks,
Mark.

[1] http://www.youtube.com/watch?v=Qh3SX3p3B74
[2] http://people.linaro.org/linaro-connect/lca14/videos/03-03-Monday/LCA14-101-%20ARM%20VM%20Standards.mp4
[3] http://lca-14.zerista.com/event/member/102395

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Tue, Jul 29, 2014 at 11:55:43AM +0100, Mark Rutland wrote:
> On Tue, Jul 29, 2014 at 11:29:40AM +0100, Christoffer Dall wrote:
> > On Mon, Jul 28, 2014 at 09:44:59AM -0700, Olof Johansson wrote:
> > > On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
> > 
> > [...]
> > 
> > > > >
> > > > > > +Relationship with Device Tree
> > > > > > +-----------------------------
> > > > > > +
> > > > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > > > > > +exclusive with DT support at compile time.
> > > > > > +
> > > > > > +At boot time the kernel will only use one description method depending on
> > > > > > +parameters passed from the bootloader.
> > > > >
> > > > > Possibly overriden by kernel bootargs. And as debated for quite a
> > > > > while earlier this year, acpi should still default to off -- if a DT
> > > > > and ACPI are both passed in, DT should at this time be given priority.
> > > > 
> > > > Why? I really don't see the logic in doing that.
> > > 
> > > Seems like I am replying to your emails in reverse order.
> > > 
> > > > Currently the kernel can only boot using DT, so DT will be used even if
> > > > ACPI is present. In the presence of ACPI support in the kernel, ACPI
> > > > would be used on said systems.
> > > 
> > > For all the reasons we hashed out earlier this year: We can't trust that
> > > vendors will know how to do ACPI from day one, so instead of loading up the
> > > kernel with lots of quirks and workarounds, we'll default to not using it until
> > > we're at a point where things look mature enough.
> > > 
> > > The alternative is to keep this patch set out of the kernel. We can do that
> > > too, but I don't think that really helps anyone.
> > > 
> > > > From the discussions at the last Linaro Connect, this was seen as
> > > > important for virtual machines which want to provide ACPI services to
> > > > guests while still being able to boot DT-only kernels. I'll leave it to
> > > > Grant, Rob, and Christoffer to cover that.
> > > 
> > > Ok, waiting to see what they have to say then.
> > > 
> > 
> > Hmm, a virtual machine implementaion may provide either a DT or ACPI (or
> > both).  I think the point at Linaro Connect was that for a first cut,
> > there is no obvious need to provide ACPI to VMs and to be spec
> > compliant, server kernels must be able to boot with DT-only.  In most
> > cases such systems will only access a few limited emulated devices
> > (UART, GIC, RTC, flash controller) and VirtIO devices, which should just
> > work using DT only.
> > 
> > People are talking about adding ACPI for VM guests as well for various
> > reasons (device passthrough for example) in which case I would always
> > expect people to run UEFI inside their guests too (perhaps this is not
> > 100% true in the case of Xen fast-boot scenarios though) and I would
> > expect Linux to only see the little stub DT and ACPI.
> > 
> > Does this clarify anything or add futher to the confusion?
> 
> I was under the impression that there was a case where we'd have a DT
> with HW description in a VM which also had ACPI tables, to enable a
> kernel without ACPI support to boot in said VM (albeit with reduced
> functionality).
> 
> I may have got confused since the VM standards discussion at LCA-14.

I took a look at the video [1,2] of said session [3], and it looks like
I was the one arguing for the case of full description in both DT and
ACPI, so either I was confused or I've forgotten some hallway
discussion.

I think my reasoning was somewhat flawed; if the hypervisor defaults to
providing DT, with an option to use ACPI in certain cases (where not all
guests would be expected to work), then that would cover the "grab an
iso, it just works?" use case for Linux images while allowing for
the cases where people want ACPI in the VM.

The only issue with that would be catering for OSs which support ACPI
but not DT or whose DT support is not Linux-compatible.

Thanks,
Mark.

[1] http://www.youtube.com/watch?v=Qh3SX3p3B74
[2] http://people.linaro.org/linaro-connect/lca14/videos/03-03-Monday/LCA14-101-%20ARM%20VM%20Standards.mp4
[3] http://lca-14.zerista.com/event/member/102395

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On 29 July 2014 13:28, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Jul 29, 2014 at 11:55:43AM +0100, Mark Rutland wrote:
>> On Tue, Jul 29, 2014 at 11:29:40AM +0100, Christoffer Dall wrote:
>> > On Mon, Jul 28, 2014 at 09:44:59AM -0700, Olof Johansson wrote:
>> > > On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
>> >
>> > [...]
>> >
>> > > > >
>> > > > > > +Relationship with Device Tree
>> > > > > > +-----------------------------
>> > > > > > +
>> > > > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>> > > > > > +exclusive with DT support at compile time.
>> > > > > > +
>> > > > > > +At boot time the kernel will only use one description method depending on
>> > > > > > +parameters passed from the bootloader.
>> > > > >
>> > > > > Possibly overriden by kernel bootargs. And as debated for quite a
>> > > > > while earlier this year, acpi should still default to off -- if a DT
>> > > > > and ACPI are both passed in, DT should at this time be given priority.
>> > > >
>> > > > Why? I really don't see the logic in doing that.
>> > >
>> > > Seems like I am replying to your emails in reverse order.
>> > >
>> > > > Currently the kernel can only boot using DT, so DT will be used even if
>> > > > ACPI is present. In the presence of ACPI support in the kernel, ACPI
>> > > > would be used on said systems.
>> > >
>> > > For all the reasons we hashed out earlier this year: We can't trust that
>> > > vendors will know how to do ACPI from day one, so instead of loading up the
>> > > kernel with lots of quirks and workarounds, we'll default to not using it until
>> > > we're at a point where things look mature enough.
>> > >
>> > > The alternative is to keep this patch set out of the kernel. We can do that
>> > > too, but I don't think that really helps anyone.
>> > >
>> > > > From the discussions at the last Linaro Connect, this was seen as
>> > > > important for virtual machines which want to provide ACPI services to
>> > > > guests while still being able to boot DT-only kernels. I'll leave it to
>> > > > Grant, Rob, and Christoffer to cover that.
>> > >
>> > > Ok, waiting to see what they have to say then.
>> > >
>> >
>> > Hmm, a virtual machine implementaion may provide either a DT or ACPI (or
>> > both).  I think the point at Linaro Connect was that for a first cut,
>> > there is no obvious need to provide ACPI to VMs and to be spec
>> > compliant, server kernels must be able to boot with DT-only.  In most
>> > cases such systems will only access a few limited emulated devices
>> > (UART, GIC, RTC, flash controller) and VirtIO devices, which should just
>> > work using DT only.
>> >
>> > People are talking about adding ACPI for VM guests as well for various
>> > reasons (device passthrough for example) in which case I would always
>> > expect people to run UEFI inside their guests too (perhaps this is not
>> > 100% true in the case of Xen fast-boot scenarios though) and I would
>> > expect Linux to only see the little stub DT and ACPI.
>> >
>> > Does this clarify anything or add futher to the confusion?
>>
>> I was under the impression that there was a case where we'd have a DT
>> with HW description in a VM which also had ACPI tables, to enable a
>> kernel without ACPI support to boot in said VM (albeit with reduced
>> functionality).
>>
>> I may have got confused since the VM standards discussion at LCA-14.
>
> I took a look at the video [1,2] of said session [3], and it looks like
> I was the one arguing for the case of full description in both DT and
> ACPI, so either I was confused or I've forgotten some hallway
> discussion.
>
> I think my reasoning was somewhat flawed; if the hypervisor defaults to
> providing DT, with an option to use ACPI in certain cases (where not all
> guests would be expected to work), then that would cover the "grab an
> iso, it just works™" use case for Linux images while allowing for
> the cases where people want ACPI in the VM.
>
> The only issue with that would be catering for OSs which support ACPI
> but not DT or whose DT support is not Linux-compatible.
>
So I think this is where the spec is really useful.  Either you're
spec compliant or you're not.  Distro images will need to support DT
if they're spec compliant to v1 of the spec (yes, it's on my todo list
to publish this properly, but the hold up is not all my fault).

A v2 of the spec may mention ACPI, and it may not, and we can deal
with that problem then.

For reference, Red Hat's current arguing point for ACPI in VMs is
hotplug of things like CPUs and memory for very large VMs, but I
haven't thought too carefully about this just yet, as I don't have a
100+ core ARM 64-bit hardware lying around...

-Christoffer

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On 29 July 2014 13:28, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Jul 29, 2014 at 11:55:43AM +0100, Mark Rutland wrote:
>> On Tue, Jul 29, 2014 at 11:29:40AM +0100, Christoffer Dall wrote:
>> > On Mon, Jul 28, 2014 at 09:44:59AM -0700, Olof Johansson wrote:
>> > > On Mon, Jul 28, 2014 at 11:06:54AM +0100, Mark Rutland wrote:
>> >
>> > [...]
>> >
>> > > > >
>> > > > > > +Relationship with Device Tree
>> > > > > > +-----------------------------
>> > > > > > +
>> > > > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>> > > > > > +exclusive with DT support at compile time.
>> > > > > > +
>> > > > > > +At boot time the kernel will only use one description method depending on
>> > > > > > +parameters passed from the bootloader.
>> > > > >
>> > > > > Possibly overriden by kernel bootargs. And as debated for quite a
>> > > > > while earlier this year, acpi should still default to off -- if a DT
>> > > > > and ACPI are both passed in, DT should at this time be given priority.
>> > > >
>> > > > Why? I really don't see the logic in doing that.
>> > >
>> > > Seems like I am replying to your emails in reverse order.
>> > >
>> > > > Currently the kernel can only boot using DT, so DT will be used even if
>> > > > ACPI is present. In the presence of ACPI support in the kernel, ACPI
>> > > > would be used on said systems.
>> > >
>> > > For all the reasons we hashed out earlier this year: We can't trust that
>> > > vendors will know how to do ACPI from day one, so instead of loading up the
>> > > kernel with lots of quirks and workarounds, we'll default to not using it until
>> > > we're at a point where things look mature enough.
>> > >
>> > > The alternative is to keep this patch set out of the kernel. We can do that
>> > > too, but I don't think that really helps anyone.
>> > >
>> > > > From the discussions at the last Linaro Connect, this was seen as
>> > > > important for virtual machines which want to provide ACPI services to
>> > > > guests while still being able to boot DT-only kernels. I'll leave it to
>> > > > Grant, Rob, and Christoffer to cover that.
>> > >
>> > > Ok, waiting to see what they have to say then.
>> > >
>> >
>> > Hmm, a virtual machine implementaion may provide either a DT or ACPI (or
>> > both).  I think the point at Linaro Connect was that for a first cut,
>> > there is no obvious need to provide ACPI to VMs and to be spec
>> > compliant, server kernels must be able to boot with DT-only.  In most
>> > cases such systems will only access a few limited emulated devices
>> > (UART, GIC, RTC, flash controller) and VirtIO devices, which should just
>> > work using DT only.
>> >
>> > People are talking about adding ACPI for VM guests as well for various
>> > reasons (device passthrough for example) in which case I would always
>> > expect people to run UEFI inside their guests too (perhaps this is not
>> > 100% true in the case of Xen fast-boot scenarios though) and I would
>> > expect Linux to only see the little stub DT and ACPI.
>> >
>> > Does this clarify anything or add futher to the confusion?
>>
>> I was under the impression that there was a case where we'd have a DT
>> with HW description in a VM which also had ACPI tables, to enable a
>> kernel without ACPI support to boot in said VM (albeit with reduced
>> functionality).
>>
>> I may have got confused since the VM standards discussion at LCA-14.
>
> I took a look at the video [1,2] of said session [3], and it looks like
> I was the one arguing for the case of full description in both DT and
> ACPI, so either I was confused or I've forgotten some hallway
> discussion.
>
> I think my reasoning was somewhat flawed; if the hypervisor defaults to
> providing DT, with an option to use ACPI in certain cases (where not all
> guests would be expected to work), then that would cover the "grab an
> iso, it just works?" use case for Linux images while allowing for
> the cases where people want ACPI in the VM.
>
> The only issue with that would be catering for OSs which support ACPI
> but not DT or whose DT support is not Linux-compatible.
>
So I think this is where the spec is really useful.  Either you're
spec compliant or you're not.  Distro images will need to support DT
if they're spec compliant to v1 of the spec (yes, it's on my todo list
to publish this properly, but the hold up is not all my fault).

A v2 of the spec may mention ACPI, and it may not, and we can deal
with that problem then.

For reference, Red Hat's current arguing point for ACPI in VMs is
hotplug of things like CPUs and memory for very large VMs, but I
haven't thought too carefully about this just yet, as I don't have a
100+ core ARM 64-bit hardware lying around...

-Christoffer

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
> 
> For reference, Red Hat's current arguing point for ACPI in VMs is
> hotplug of things like CPUs and memory for very large VMs, but I
> haven't thought too carefully about this just yet, as I don't have a
> 100+ core ARM 64-bit hardware lying around...

I thought you could run guests with more virtual CPUs that you have
physical CPUs on the host.

Regarding CPU and memory hotplug, don't we already have PSCI and
xen-balloon/virtio-balloon for that?

	Arnd

[PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
> 
> For reference, Red Hat's current arguing point for ACPI in VMs is
> hotplug of things like CPUs and memory for very large VMs, but I
> haven't thought too carefully about this just yet, as I don't have a
> 100+ core ARM 64-bit hardware lying around...

I thought you could run guests with more virtual CPUs that you have
physical CPUs on the host.

Regarding CPU and memory hotplug, don't we already have PSCI and
xen-balloon/virtio-balloon for that?

	Arnd

Re: [PATCH 03/19] ARM64 / ACPI: Introduce lowlevel suspend function

[Hanjun Guo]

On 2014-7-29 2:28, Sudeep Holla wrote:
> 
> 
> On 24/07/14 14:00, Hanjun Guo wrote:
>> From: Graeme Gregory <graeme.gregory@linaro.org>
>>
>> acpi_wakeup_address is used on x86 as the address bios jumps into
>> when machine wakes up from suspend. As arm64 does not have such a
>> bios this mechanism will be provided by other means. But the define
>> is still required inside the acpi core.
>>
>> Introduce a null stub for acpi_suspend_lowlevel as this is also
>> required by core. This will be filled in when standards are
>> defined for arm64 ACPI global power states.
>>
>> Reviewed-by: Grant Likely <grant.likely@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   arch/arm64/include/asm/acpi.h |   12 ++++++++++++
>>   arch/arm64/kernel/acpi.c      |    7 +++++++
>>   2 files changed, 19 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index e8581ea..44b617f 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -36,6 +36,18 @@ static inline bool acpi_has_cpu_in_madt(void)
>>       return 1;
>>   }
>>
>> +/* Low-level suspend routine.
>> + *
>> + * ACPI S-states for ARM64 have to be defined
>> + * and approved before doing anything else, maybe
>> + * we need update the ACPI spec, here we
>> + * just introduce function and macro needed by
>> + * ACPI core as IA64 did, and revisit them when
>> + * the spec is ready.
>> + */
>> +extern int (*acpi_suspend_lowlevel)(void);
>> +#define acpi_wakeup_address 0
>> +
> 
> While I understand that this is temporary solution, but will this be
> sufficient to make sure we don't enter acpi_suspend_enter ?
> 
> A brief look at acpi_suspend_enter showed access to write to
> ACPI_BITREG_SCI_ENABLE which might just explode. But if you are sure that
> it will not be executed, then it should be fine for now.

I think it will not be executed, since ARM64 do not support S1 and S3 in ACPI
for now, and that state will not defined, then acpi_suspend_enter will not be
called.

Thanks
Hanjun

Re: [PATCH 03/19] ARM64 / ACPI: Introduce lowlevel suspend function

[Hanjun Guo]

On 2014-7-29 2:28, Sudeep Holla wrote:
> 
> 
> On 24/07/14 14:00, Hanjun Guo wrote:
>> From: Graeme Gregory <graeme.gregory@linaro.org>
>>
>> acpi_wakeup_address is used on x86 as the address bios jumps into
>> when machine wakes up from suspend. As arm64 does not have such a
>> bios this mechanism will be provided by other means. But the define
>> is still required inside the acpi core.
>>
>> Introduce a null stub for acpi_suspend_lowlevel as this is also
>> required by core. This will be filled in when standards are
>> defined for arm64 ACPI global power states.
>>
>> Reviewed-by: Grant Likely <grant.likely@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   arch/arm64/include/asm/acpi.h |   12 ++++++++++++
>>   arch/arm64/kernel/acpi.c      |    7 +++++++
>>   2 files changed, 19 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index e8581ea..44b617f 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -36,6 +36,18 @@ static inline bool acpi_has_cpu_in_madt(void)
>>       return 1;
>>   }
>>
>> +/* Low-level suspend routine.
>> + *
>> + * ACPI S-states for ARM64 have to be defined
>> + * and approved before doing anything else, maybe
>> + * we need update the ACPI spec, here we
>> + * just introduce function and macro needed by
>> + * ACPI core as IA64 did, and revisit them when
>> + * the spec is ready.
>> + */
>> +extern int (*acpi_suspend_lowlevel)(void);
>> +#define acpi_wakeup_address 0
>> +
> 
> While I understand that this is temporary solution, but will this be
> sufficient to make sure we don't enter acpi_suspend_enter ?
> 
> A brief look at acpi_suspend_enter showed access to write to
> ACPI_BITREG_SCI_ENABLE which might just explode. But if you are sure that
> it will not be executed, then it should be fine for now.

I think it will not be executed, since ARM64 do not support S1 and S3 in ACPI
for now, and that state will not defined, then acpi_suspend_enter will not be
called.

Thanks
Hanjun

[PATCH 03/19] ARM64 / ACPI: Introduce lowlevel suspend function

[Hanjun Guo]

On 2014-7-29 2:28, Sudeep Holla wrote:
> 
> 
> On 24/07/14 14:00, Hanjun Guo wrote:
>> From: Graeme Gregory <graeme.gregory@linaro.org>
>>
>> acpi_wakeup_address is used on x86 as the address bios jumps into
>> when machine wakes up from suspend. As arm64 does not have such a
>> bios this mechanism will be provided by other means. But the define
>> is still required inside the acpi core.
>>
>> Introduce a null stub for acpi_suspend_lowlevel as this is also
>> required by core. This will be filled in when standards are
>> defined for arm64 ACPI global power states.
>>
>> Reviewed-by: Grant Likely <grant.likely@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   arch/arm64/include/asm/acpi.h |   12 ++++++++++++
>>   arch/arm64/kernel/acpi.c      |    7 +++++++
>>   2 files changed, 19 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index e8581ea..44b617f 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -36,6 +36,18 @@ static inline bool acpi_has_cpu_in_madt(void)
>>       return 1;
>>   }
>>
>> +/* Low-level suspend routine.
>> + *
>> + * ACPI S-states for ARM64 have to be defined
>> + * and approved before doing anything else, maybe
>> + * we need update the ACPI spec, here we
>> + * just introduce function and macro needed by
>> + * ACPI core as IA64 did, and revisit them when
>> + * the spec is ready.
>> + */
>> +extern int (*acpi_suspend_lowlevel)(void);
>> +#define acpi_wakeup_address 0
>> +
> 
> While I understand that this is temporary solution, but will this be
> sufficient to make sure we don't enter acpi_suspend_enter ?
> 
> A brief look at acpi_suspend_enter showed access to write to
> ACPI_BITREG_SCI_ENABLE which might just explode. But if you are sure that
> it will not be executed, then it should be fine for now.

I think it will not be executed, since ARM64 do not support S1 and S3 in ACPI
for now, and that state will not defined, then acpi_suspend_enter will not be
called.

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
> > 
> > For reference, Red Hat's current arguing point for ACPI in VMs is
> > hotplug of things like CPUs and memory for very large VMs, but I
> > haven't thought too carefully about this just yet, as I don't have a
> > 100+ core ARM 64-bit hardware lying around...
> 
> I thought you could run guests with more virtual CPUs that you have
> physical CPUs on the host.
> 
> Regarding CPU and memory hotplug, don't we already have PSCI and
> xen-balloon/virtio-balloon for that?

PSCI (0.1) was there for guests from the start, and ACPI doesn't do
anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
be used by guests supporting only PSCI 0.1). So there's no magic for
CPU hotplug provided by ACPI.

Do either of the balloon drivers allow for memory to be hot-added to a
system initially provisioned with less?

Thanks,
Mark.

[PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
> > 
> > For reference, Red Hat's current arguing point for ACPI in VMs is
> > hotplug of things like CPUs and memory for very large VMs, but I
> > haven't thought too carefully about this just yet, as I don't have a
> > 100+ core ARM 64-bit hardware lying around...
> 
> I thought you could run guests with more virtual CPUs that you have
> physical CPUs on the host.
> 
> Regarding CPU and memory hotplug, don't we already have PSCI and
> xen-balloon/virtio-balloon for that?

PSCI (0.1) was there for guests from the start, and ACPI doesn't do
anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
be used by guests supporting only PSCI 0.1). So there's no magic for
CPU hotplug provided by ACPI.

Do either of the balloon drivers allow for memory to be hot-added to a
system initially provisioned with less?

Thanks,
Mark.

Re: [PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Hanjun Guo]

On 2014-7-29 2:29, Sudeep Holla wrote:
[...]
>> +
>> +/*
>> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>> + * variable is still required by the ACPI core
>> + */
>> +u32 acpi_rsdt_forced;
> 
> This looks like yet another stray variable not used anywhere including
> core ACPI

It will be used by ACPICA to get the RSDP in acpi_tb_parse_root_table()
in tbutils.c.

> 
>> +
>> +int acpi_noirq;                        /* skip ACPI IRQ initialization */
>> +int acpi_strict;
>> +int acpi_disabled;
>> +EXPORT_SYMBOL(acpi_disabled);
>> +
>> +int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
>> +EXPORT_SYMBOL(acpi_pci_disabled);
>> +
>> +/*
>> + * __acpi_map_table() will be called before page_init(), so early_ioremap()
>> + * or early_memremap() should be called here to for ACPI table mapping.
>> + */
>> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
>> +{
>> +       if (!phys || !size)
>> +               return NULL;
>> +
>> +       return early_memremap(phys, size);
>> +}
>> +
>> +void __init __acpi_unmap_table(char *map, unsigned long size)
>> +{
>> +       if (!map || !size)
>> +               return;
>> +
>> +       early_iounmap(map, size);
> 
> Why not early_memunmap for consistency ?

ok.

> Also now there's generic implementation of early mappings does it make
> sense to move this also to acpi core ?

Good point, how about clean it up after this patch set is merged?

Thanks
Hanjun

Re: [PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Hanjun Guo]

On 2014-7-29 2:29, Sudeep Holla wrote:
[...]
>> +
>> +/*
>> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>> + * variable is still required by the ACPI core
>> + */
>> +u32 acpi_rsdt_forced;
> 
> This looks like yet another stray variable not used anywhere including
> core ACPI

It will be used by ACPICA to get the RSDP in acpi_tb_parse_root_table()
in tbutils.c.

> 
>> +
>> +int acpi_noirq;                        /* skip ACPI IRQ initialization */
>> +int acpi_strict;
>> +int acpi_disabled;
>> +EXPORT_SYMBOL(acpi_disabled);
>> +
>> +int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
>> +EXPORT_SYMBOL(acpi_pci_disabled);
>> +
>> +/*
>> + * __acpi_map_table() will be called before page_init(), so early_ioremap()
>> + * or early_memremap() should be called here to for ACPI table mapping.
>> + */
>> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
>> +{
>> +       if (!phys || !size)
>> +               return NULL;
>> +
>> +       return early_memremap(phys, size);
>> +}
>> +
>> +void __init __acpi_unmap_table(char *map, unsigned long size)
>> +{
>> +       if (!map || !size)
>> +               return;
>> +
>> +       early_iounmap(map, size);
> 
> Why not early_memunmap for consistency ?

ok.

> Also now there's generic implementation of early mappings does it make
> sense to move this also to acpi core ?

Good point, how about clean it up after this patch set is merged?

Thanks
Hanjun

[PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Hanjun Guo]

On 2014-7-29 2:29, Sudeep Holla wrote:
[...]
>> +
>> +/*
>> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>> + * variable is still required by the ACPI core
>> + */
>> +u32 acpi_rsdt_forced;
> 
> This looks like yet another stray variable not used anywhere including
> core ACPI

It will be used by ACPICA to get the RSDP in acpi_tb_parse_root_table()
in tbutils.c.

> 
>> +
>> +int acpi_noirq;                        /* skip ACPI IRQ initialization */
>> +int acpi_strict;
>> +int acpi_disabled;
>> +EXPORT_SYMBOL(acpi_disabled);
>> +
>> +int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
>> +EXPORT_SYMBOL(acpi_pci_disabled);
>> +
>> +/*
>> + * __acpi_map_table() will be called before page_init(), so early_ioremap()
>> + * or early_memremap() should be called here to for ACPI table mapping.
>> + */
>> +char *__init __acpi_map_table(unsigned long phys, unsigned long size)
>> +{
>> +       if (!phys || !size)
>> +               return NULL;
>> +
>> +       return early_memremap(phys, size);
>> +}
>> +
>> +void __init __acpi_unmap_table(char *map, unsigned long size)
>> +{
>> +       if (!map || !size)
>> +               return;
>> +
>> +       early_iounmap(map, size);
> 
> Why not early_memunmap for consistency ?

ok.

> Also now there's generic implementation of early mappings does it make
> sense to move this also to acpi core ?

Good point, how about clean it up after this patch set is merged?

Thanks
Hanjun

Re: [PATCH 02/19] ARM64 / ACPI: Introduce early_param for "acpi"

[Hanjun Guo]

On 2014-7-29 2:35, Sudeep Holla wrote:
> 
> 
> On 24/07/14 14:00, Hanjun Guo wrote:
>> From: Al Stone <al.stone@linaro.org>
>>
>> Introduce two early parameters for "acpi", one is the parameter
>> to disable ACPI on ARM64 and another one is acpi=strict to disable
>> out-of-spec workarounds.
>>
>> Reviewed-by: Grant Likely <grant.likely@linaro.org>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   Documentation/kernel-parameters.txt |    3 ++-
>>   arch/arm64/kernel/acpi.c            |   21 +++++++++++++++++++++
>>   2 files changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/kernel-parameters.txt
>> b/Documentation/kernel-parameters.txt
>> index b7fa2f5..d130bd5 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -165,7 +165,7 @@ multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10,
>> 2^20, and 2^30
>>   bytes respectively. Such letter suffixes can also be entirely omitted.
>>
>>
>> -    acpi=        [HW,ACPI,X86]
>> +    acpi=        [HW,ACPI,X86,ARM]
>>               Advanced Configuration and Power Interface
>>               Format: { force | off | strict | noirq | rsdt }
>>               force -- enable ACPI if default was off
>> @@ -175,6 +175,7 @@ bytes respectively. Such letter suffixes can also be
>> entirely omitted.
>>                   strictly ACPI specification compliant.
>>               rsdt -- prefer RSDT over (default) XSDT
>>               copy_dsdt -- copy DSDT to memory
>> +            For ARM64, ONLY "off" and "strict" are available.
>>
>>               See also Documentation/power/runtime_pm.txt, pci=noacpi
>>
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index c62fce6..ac78e4e 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -74,3 +74,24 @@ void __init acpi_boot_table_init(void)
>>           return;
>>       }
>>   }
>> +
>> +static int __init parse_acpi(char *arg)
>> +{
>> +    if (!arg)
>> +        return -EINVAL;
>> +
>> +    /* "acpi=off" disables both ACPI table parsing and interpreter */
>> +    if (strcmp(arg, "off") == 0) {
>> +        disable_acpi();
>> +    }
>> +    /* acpi=strict disables out-of-spec workarounds */
>> +    else if (strcmp(arg, "strict") == 0) {
>> +        acpi_strict = 1;
> 
> This should be default set as I mentioned in patch#1. We can introduce
> this option if required in future.

Agreed, Let's keep it strict in the beginning to support ACPI.

Thanks
Hanjun

Re: [PATCH 02/19] ARM64 / ACPI: Introduce early_param for "acpi"

[Hanjun Guo]

On 2014-7-29 2:35, Sudeep Holla wrote:
> 
> 
> On 24/07/14 14:00, Hanjun Guo wrote:
>> From: Al Stone <al.stone@linaro.org>
>>
>> Introduce two early parameters for "acpi", one is the parameter
>> to disable ACPI on ARM64 and another one is acpi=strict to disable
>> out-of-spec workarounds.
>>
>> Reviewed-by: Grant Likely <grant.likely@linaro.org>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   Documentation/kernel-parameters.txt |    3 ++-
>>   arch/arm64/kernel/acpi.c            |   21 +++++++++++++++++++++
>>   2 files changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/kernel-parameters.txt
>> b/Documentation/kernel-parameters.txt
>> index b7fa2f5..d130bd5 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -165,7 +165,7 @@ multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10,
>> 2^20, and 2^30
>>   bytes respectively. Such letter suffixes can also be entirely omitted.
>>
>>
>> -    acpi=        [HW,ACPI,X86]
>> +    acpi=        [HW,ACPI,X86,ARM]
>>               Advanced Configuration and Power Interface
>>               Format: { force | off | strict | noirq | rsdt }
>>               force -- enable ACPI if default was off
>> @@ -175,6 +175,7 @@ bytes respectively. Such letter suffixes can also be
>> entirely omitted.
>>                   strictly ACPI specification compliant.
>>               rsdt -- prefer RSDT over (default) XSDT
>>               copy_dsdt -- copy DSDT to memory
>> +            For ARM64, ONLY "off" and "strict" are available.
>>
>>               See also Documentation/power/runtime_pm.txt, pci=noacpi
>>
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index c62fce6..ac78e4e 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -74,3 +74,24 @@ void __init acpi_boot_table_init(void)
>>           return;
>>       }
>>   }
>> +
>> +static int __init parse_acpi(char *arg)
>> +{
>> +    if (!arg)
>> +        return -EINVAL;
>> +
>> +    /* "acpi=off" disables both ACPI table parsing and interpreter */
>> +    if (strcmp(arg, "off") == 0) {
>> +        disable_acpi();
>> +    }
>> +    /* acpi=strict disables out-of-spec workarounds */
>> +    else if (strcmp(arg, "strict") == 0) {
>> +        acpi_strict = 1;
> 
> This should be default set as I mentioned in patch#1. We can introduce
> this option if required in future.

Agreed, Let's keep it strict in the beginning to support ACPI.

Thanks
Hanjun

[PATCH 02/19] ARM64 / ACPI: Introduce early_param for "acpi"

[Hanjun Guo]

On 2014-7-29 2:35, Sudeep Holla wrote:
> 
> 
> On 24/07/14 14:00, Hanjun Guo wrote:
>> From: Al Stone <al.stone@linaro.org>
>>
>> Introduce two early parameters for "acpi", one is the parameter
>> to disable ACPI on ARM64 and another one is acpi=strict to disable
>> out-of-spec workarounds.
>>
>> Reviewed-by: Grant Likely <grant.likely@linaro.org>
>> Signed-off-by: Al Stone <al.stone@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   Documentation/kernel-parameters.txt |    3 ++-
>>   arch/arm64/kernel/acpi.c            |   21 +++++++++++++++++++++
>>   2 files changed, 23 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/kernel-parameters.txt
>> b/Documentation/kernel-parameters.txt
>> index b7fa2f5..d130bd5 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -165,7 +165,7 @@ multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10,
>> 2^20, and 2^30
>>   bytes respectively. Such letter suffixes can also be entirely omitted.
>>
>>
>> -    acpi=        [HW,ACPI,X86]
>> +    acpi=        [HW,ACPI,X86,ARM]
>>               Advanced Configuration and Power Interface
>>               Format: { force | off | strict | noirq | rsdt }
>>               force -- enable ACPI if default was off
>> @@ -175,6 +175,7 @@ bytes respectively. Such letter suffixes can also be
>> entirely omitted.
>>                   strictly ACPI specification compliant.
>>               rsdt -- prefer RSDT over (default) XSDT
>>               copy_dsdt -- copy DSDT to memory
>> +            For ARM64, ONLY "off" and "strict" are available.
>>
>>               See also Documentation/power/runtime_pm.txt, pci=noacpi
>>
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index c62fce6..ac78e4e 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -74,3 +74,24 @@ void __init acpi_boot_table_init(void)
>>           return;
>>       }
>>   }
>> +
>> +static int __init parse_acpi(char *arg)
>> +{
>> +    if (!arg)
>> +        return -EINVAL;
>> +
>> +    /* "acpi=off" disables both ACPI table parsing and interpreter */
>> +    if (strcmp(arg, "off") == 0) {
>> +        disable_acpi();
>> +    }
>> +    /* acpi=strict disables out-of-spec workarounds */
>> +    else if (strcmp(arg, "strict") == 0) {
>> +        acpi_strict = 1;
> 
> This should be default set as I mentioned in patch#1. We can introduce
> this option if required in future.

Agreed, Let's keep it strict in the beginning to support ACPI.

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On 29 July 2014 15:08, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
>> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
>> >
>> > For reference, Red Hat's current arguing point for ACPI in VMs is
>> > hotplug of things like CPUs and memory for very large VMs, but I
>> > haven't thought too carefully about this just yet, as I don't have a
>> > 100+ core ARM 64-bit hardware lying around...
>>
>> I thought you could run guests with more virtual CPUs that you have
>> physical CPUs on the host.
>>
>> Regarding CPU and memory hotplug, don't we already have PSCI and
>> xen-balloon/virtio-balloon for that?
>
> PSCI (0.1) was there for guests from the start, and ACPI doesn't do
> anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
> be used by guests supporting only PSCI 0.1). So there's no magic for
> CPU hotplug provided by ACPI.

With PSCI you can only provide your VM a bunch of CPUs and say that
they're all turned off, and then turn some of them on later.  I
honestly don't know if you can do proper CPU hotplug with ACPI, but
the RH guys seem to argue that you can.  Again, I didn't think too
carefully about this.

>
> Do either of the balloon drivers allow for memory to be hot-added to a
> system initially provisioned with less?
>
No, it's just about reclaiming memory.  Same argument as above.

-Christoffer

[PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On 29 July 2014 15:08, Mark Rutland <mark.rutland@arm.com> wrote:
> On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
>> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
>> >
>> > For reference, Red Hat's current arguing point for ACPI in VMs is
>> > hotplug of things like CPUs and memory for very large VMs, but I
>> > haven't thought too carefully about this just yet, as I don't have a
>> > 100+ core ARM 64-bit hardware lying around...
>>
>> I thought you could run guests with more virtual CPUs that you have
>> physical CPUs on the host.
>>
>> Regarding CPU and memory hotplug, don't we already have PSCI and
>> xen-balloon/virtio-balloon for that?
>
> PSCI (0.1) was there for guests from the start, and ACPI doesn't do
> anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
> be used by guests supporting only PSCI 0.1). So there's no magic for
> CPU hotplug provided by ACPI.

With PSCI you can only provide your VM a bunch of CPUs and say that
they're all turned off, and then turn some of them on later.  I
honestly don't know if you can do proper CPU hotplug with ACPI, but
the RH guys seem to argue that you can.  Again, I didn't think too
carefully about this.

>
> Do either of the balloon drivers allow for memory to be hot-added to a
> system initially provisioned with less?
>
No, it's just about reclaiming memory.  Same argument as above.

-Christoffer

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On 29 July 2014 14:52, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
>>
>> For reference, Red Hat's current arguing point for ACPI in VMs is
>> hotplug of things like CPUs and memory for very large VMs, but I
>> haven't thought too carefully about this just yet, as I don't have a
>> 100+ core ARM 64-bit hardware lying around...
>
> I thought you could run guests with more virtual CPUs that you have
> physical CPUs on the host.
>

you can, my sentence was meant to be a bit tongue-in-cheek, running
100 VCPUs on the Foundation Model (which is the only thing I have on
my desk as of now) is not very useful, so I just don't care at this
point.  Let me see or give me access to something with at least 8
physical cores before I start caring (with my community hat on, as a
Linaro employee I may be told to care).

> Regarding CPU and memory hotplug, don't we already have PSCI and
> xen-balloon/virtio-balloon for that?
>
Virtio-balloon don't do anything for you wrt. CPUs, wrt. memory you
have to provision it beforehand.

-Christoffer

[PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On 29 July 2014 14:52, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
>>
>> For reference, Red Hat's current arguing point for ACPI in VMs is
>> hotplug of things like CPUs and memory for very large VMs, but I
>> haven't thought too carefully about this just yet, as I don't have a
>> 100+ core ARM 64-bit hardware lying around...
>
> I thought you could run guests with more virtual CPUs that you have
> physical CPUs on the host.
>

you can, my sentence was meant to be a bit tongue-in-cheek, running
100 VCPUs on the Foundation Model (which is the only thing I have on
my desk as of now) is not very useful, so I just don't care at this
point.  Let me see or give me access to something with at least 8
physical cores before I start caring (with my community hat on, as a
Linaro employee I may be told to care).

> Regarding CPU and memory hotplug, don't we already have PSCI and
> xen-balloon/virtio-balloon for that?
>
Virtio-balloon don't do anything for you wrt. CPUs, wrt. memory you
have to provision it beforehand.

-Christoffer

Re: [PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Sudeep Holla]

On 29/07/14 14:08, Hanjun Guo wrote:
> On 2014-7-29 2:29, Sudeep Holla wrote:
> [...]
>>> +
>>> +/*
>>> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>>> + * variable is still required by the ACPI core
>>> + */
>>> +u32 acpi_rsdt_forced;
>>
>> This looks like yet another stray variable not used anywhere including
>> core ACPI
>
> It will be used by ACPICA to get the RSDP in acpi_tb_parse_root_table()
> in tbutils.c.
>

No I couldn't find it in mainline/acpica/linux-next(pm tree).

On further digging found that commit fab461058385("ACPICA: Cleanup the
option of forcing the use of the RSDT") has renamed it to
acpi_gbl_do_not_use_xsdt and moved it into acpica with default false.
So you can remove this.

Regards,
Sudeep

Re: [PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Sudeep Holla]

On 29/07/14 14:08, Hanjun Guo wrote:
> On 2014-7-29 2:29, Sudeep Holla wrote:
> [...]
>>> +
>>> +/*
>>> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>>> + * variable is still required by the ACPI core
>>> + */
>>> +u32 acpi_rsdt_forced;
>>
>> This looks like yet another stray variable not used anywhere including
>> core ACPI
>
> It will be used by ACPICA to get the RSDP in acpi_tb_parse_root_table()
> in tbutils.c.
>

No I couldn't find it in mainline/acpica/linux-next(pm tree).

On further digging found that commit fab461058385("ACPICA: Cleanup the
option of forcing the use of the RSDT") has renamed it to
acpi_gbl_do_not_use_xsdt and moved it into acpica with default false.
So you can remove this.

Regards,
Sudeep

[PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Sudeep Holla]

On 29/07/14 14:08, Hanjun Guo wrote:
> On 2014-7-29 2:29, Sudeep Holla wrote:
> [...]
>>> +
>>> +/*
>>> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>>> + * variable is still required by the ACPI core
>>> + */
>>> +u32 acpi_rsdt_forced;
>>
>> This looks like yet another stray variable not used anywhere including
>> core ACPI
>
> It will be used by ACPICA to get the RSDP in acpi_tb_parse_root_table()
> in tbutils.c.
>

No I couldn't find it in mainline/acpica/linux-next(pm tree).

On further digging found that commit fab461058385("ACPICA: Cleanup the
option of forcing the use of the RSDT") has renamed it to
acpi_gbl_do_not_use_xsdt and moved it into acpica with default false.
So you can remove this.

Regards,
Sudeep

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Tue, Jul 29, 2014 at 02:31:16PM +0100, Christoffer Dall wrote:
> On 29 July 2014 15:08, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
> >> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
> >> >
> >> > For reference, Red Hat's current arguing point for ACPI in VMs is
> >> > hotplug of things like CPUs and memory for very large VMs, but I
> >> > haven't thought too carefully about this just yet, as I don't have a
> >> > 100+ core ARM 64-bit hardware lying around...
> >>
> >> I thought you could run guests with more virtual CPUs that you have
> >> physical CPUs on the host.
> >>
> >> Regarding CPU and memory hotplug, don't we already have PSCI and
> >> xen-balloon/virtio-balloon for that?
> >
> > PSCI (0.1) was there for guests from the start, and ACPI doesn't do
> > anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
> > be used by guests supporting only PSCI 0.1). So there's no magic for
> > CPU hotplug provided by ACPI.
> 
> With PSCI you can only provide your VM a bunch of CPUs and say that
> they're all turned off, and then turn some of them on later.  I
> honestly don't know if you can do proper CPU hotplug with ACPI, but
> the RH guys seem to argue that you can.  Again, I didn't think too
> carefully about this.

Ah, I see. That would make some sense.

> >
> > Do either of the balloon drivers allow for memory to be hot-added to a
> > system initially provisioned with less?
> >
> No, it's just about reclaiming memory.  Same argument as above.

Ok. Thanks for the clarifications.

Cheers,
Mark.

[PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Tue, Jul 29, 2014 at 02:31:16PM +0100, Christoffer Dall wrote:
> On 29 July 2014 15:08, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
> >> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
> >> >
> >> > For reference, Red Hat's current arguing point for ACPI in VMs is
> >> > hotplug of things like CPUs and memory for very large VMs, but I
> >> > haven't thought too carefully about this just yet, as I don't have a
> >> > 100+ core ARM 64-bit hardware lying around...
> >>
> >> I thought you could run guests with more virtual CPUs that you have
> >> physical CPUs on the host.
> >>
> >> Regarding CPU and memory hotplug, don't we already have PSCI and
> >> xen-balloon/virtio-balloon for that?
> >
> > PSCI (0.1) was there for guests from the start, and ACPI doesn't do
> > anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
> > be used by guests supporting only PSCI 0.1). So there's no magic for
> > CPU hotplug provided by ACPI.
> 
> With PSCI you can only provide your VM a bunch of CPUs and say that
> they're all turned off, and then turn some of them on later.  I
> honestly don't know if you can do proper CPU hotplug with ACPI, but
> the RH guys seem to argue that you can.  Again, I didn't think too
> carefully about this.

Ah, I see. That would make some sense.

> >
> > Do either of the balloon drivers allow for memory to be hot-added to a
> > system initially provisioned with less?
> >
> No, it's just about reclaiming memory.  Same argument as above.

Ok. Thanks for the clarifications.

Cheers,
Mark.

Re: [PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Hanjun Guo]

On 2014年07月29日 21:50, Sudeep Holla wrote:
>
> On 29/07/14 14:08, Hanjun Guo wrote:
>> On 2014-7-29 2:29, Sudeep Holla wrote:
>> [...]
>>>> +
>>>> +/*
>>>> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>>>> + * variable is still required by the ACPI core
>>>> + */
>>>> +u32 acpi_rsdt_forced;
>>>
>>> This looks like yet another stray variable not used anywhere including
>>> core ACPI
>>
>> It will be used by ACPICA to get the RSDP in acpi_tb_parse_root_table()
>> in tbutils.c.
>>
>
> No I couldn't find it in mainline/acpica/linux-next(pm tree).
>
> On further digging found that commit fab461058385("ACPICA: Cleanup the
> option of forcing the use of the RSDT") has renamed it to
> acpi_gbl_do_not_use_xsdt and moved it into acpica with default false.
> So you can remove this.

Ah, my bad. I grepped it in another version of kernel and found the outdated
result, I will update this patch.

Thanks
Hanjun


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 01/19] ARM64 / ACPI: Get RSDP and ACPI boot-time tables

[Hanjun Guo]

On 2014?07?29? 21:50, Sudeep Holla wrote:
>
> On 29/07/14 14:08, Hanjun Guo wrote:
>> On 2014-7-29 2:29, Sudeep Holla wrote:
>> [...]
>>>> +
>>>> +/*
>>>> + * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>>>> + * variable is still required by the ACPI core
>>>> + */
>>>> +u32 acpi_rsdt_forced;
>>>
>>> This looks like yet another stray variable not used anywhere including
>>> core ACPI
>>
>> It will be used by ACPICA to get the RSDP in acpi_tb_parse_root_table()
>> in tbutils.c.
>>
>
> No I couldn't find it in mainline/acpica/linux-next(pm tree).
>
> On further digging found that commit fab461058385("ACPICA: Cleanup the
> option of forcing the use of the RSDT") has renamed it to
> acpi_gbl_do_not_use_xsdt and moved it into acpica with default false.
> So you can remove this.

Ah, my bad. I grepped it in another version of kernel and found the outdated
result, I will update this patch.

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Tuesday 29 July 2014 15:31:16 Christoffer Dall wrote:
> On 29 July 2014 15:08, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
> >> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
> >> >
> >> > For reference, Red Hat's current arguing point for ACPI in VMs is
> >> > hotplug of things like CPUs and memory for very large VMs, but I
> >> > haven't thought too carefully about this just yet, as I don't have a
> >> > 100+ core ARM 64-bit hardware lying around...
> >>
> >> I thought you could run guests with more virtual CPUs that you have
> >> physical CPUs on the host.
> >>
> >> Regarding CPU and memory hotplug, don't we already have PSCI and
> >> xen-balloon/virtio-balloon for that?
> >
> > PSCI (0.1) was there for guests from the start, and ACPI doesn't do
> > anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
> > be used by guests supporting only PSCI 0.1). So there's no magic for
> > CPU hotplug provided by ACPI.
> 
> With PSCI you can only provide your VM a bunch of CPUs and say that
> they're all turned off, and then turn some of them on later.  I
> honestly don't know if you can do proper CPU hotplug with ACPI, but
> the RH guys seem to argue that you can.  Again, I didn't think too
> carefully about this.

Xen does this in drivers/xen/cpu_hotplug.c, acpi does it in
drivers/acpi/acpi_processor.c.

> > Do either of the balloon drivers allow for memory to be hot-added to a
> > system initially provisioned with less?
> >
> No, it's just about reclaiming memory.  Same argument as above.

Again, Xen seems to be able to add more memory:

config XEN_BALLOON_MEMORY_HOTPLUG
        bool "Memory hotplug support for Xen balloon driver"
        default n
        depends on XEN_BALLOON && MEMORY_HOTPLUG
        help
          Memory hotplug support for Xen balloon driver allows expanding memory
          available for the system above limit declared at system startup.
          It is very useful on critical systems which require long
          run without rebooting.
	  ...

The same goes for hyperv, s390 and vmware. It should not be hard to add it
for KVM.

	Arnd

[PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Tuesday 29 July 2014 15:31:16 Christoffer Dall wrote:
> On 29 July 2014 15:08, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
> >> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
> >> >
> >> > For reference, Red Hat's current arguing point for ACPI in VMs is
> >> > hotplug of things like CPUs and memory for very large VMs, but I
> >> > haven't thought too carefully about this just yet, as I don't have a
> >> > 100+ core ARM 64-bit hardware lying around...
> >>
> >> I thought you could run guests with more virtual CPUs that you have
> >> physical CPUs on the host.
> >>
> >> Regarding CPU and memory hotplug, don't we already have PSCI and
> >> xen-balloon/virtio-balloon for that?
> >
> > PSCI (0.1) was there for guests from the start, and ACPI doesn't do
> > anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
> > be used by guests supporting only PSCI 0.1). So there's no magic for
> > CPU hotplug provided by ACPI.
> 
> With PSCI you can only provide your VM a bunch of CPUs and say that
> they're all turned off, and then turn some of them on later.  I
> honestly don't know if you can do proper CPU hotplug with ACPI, but
> the RH guys seem to argue that you can.  Again, I didn't think too
> carefully about this.

Xen does this in drivers/xen/cpu_hotplug.c, acpi does it in
drivers/acpi/acpi_processor.c.

> > Do either of the balloon drivers allow for memory to be hot-added to a
> > system initially provisioned with less?
> >
> No, it's just about reclaiming memory.  Same argument as above.

Again, Xen seems to be able to add more memory:

config XEN_BALLOON_MEMORY_HOTPLUG
        bool "Memory hotplug support for Xen balloon driver"
        default n
        depends on XEN_BALLOON && MEMORY_HOTPLUG
        help
          Memory hotplug support for Xen balloon driver allows expanding memory
          available for the system above limit declared at system startup.
          It is very useful on critical systems which require long
          run without rebooting.
	  ...

The same goes for hyperv, s390 and vmware. It should not be hard to add it
for KVM.

	Arnd

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On 29 July 2014 16:41, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 29 July 2014 15:31:16 Christoffer Dall wrote:
>> On 29 July 2014 15:08, Mark Rutland <mark.rutland@arm.com> wrote:
>> > On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
>> >> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
>> >> >
>> >> > For reference, Red Hat's current arguing point for ACPI in VMs is
>> >> > hotplug of things like CPUs and memory for very large VMs, but I
>> >> > haven't thought too carefully about this just yet, as I don't have a
>> >> > 100+ core ARM 64-bit hardware lying around...
>> >>
>> >> I thought you could run guests with more virtual CPUs that you have
>> >> physical CPUs on the host.
>> >>
>> >> Regarding CPU and memory hotplug, don't we already have PSCI and
>> >> xen-balloon/virtio-balloon for that?
>> >
>> > PSCI (0.1) was there for guests from the start, and ACPI doesn't do
>> > anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
>> > be used by guests supporting only PSCI 0.1). So there's no magic for
>> > CPU hotplug provided by ACPI.
>>
>> With PSCI you can only provide your VM a bunch of CPUs and say that
>> they're all turned off, and then turn some of them on later.  I
>> honestly don't know if you can do proper CPU hotplug with ACPI, but
>> the RH guys seem to argue that you can.  Again, I didn't think too
>> carefully about this.
>
> Xen does this in drivers/xen/cpu_hotplug.c, acpi does it in
> drivers/acpi/acpi_processor.c.
>
>> > Do either of the balloon drivers allow for memory to be hot-added to a
>> > system initially provisioned with less?
>> >
>> No, it's just about reclaiming memory.  Same argument as above.
>
> Again, Xen seems to be able to add more memory:
>
> config XEN_BALLOON_MEMORY_HOTPLUG
>         bool "Memory hotplug support for Xen balloon driver"
>         default n
>         depends on XEN_BALLOON && MEMORY_HOTPLUG
>         help
>           Memory hotplug support for Xen balloon driver allows expanding memory
>           available for the system above limit declared at system startup.
>           It is very useful on critical systems which require long
>           run without rebooting.
>           ...
>
> The same goes for hyperv, s390 and vmware. It should not be hard to add it
> for KVM.
>
Absolutely, and I would prefer doing that over adding ACPI in guests
as things stand right now.  We can have another fun discussion about
this at LCU...

-Christoffer

[PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On 29 July 2014 16:41, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday 29 July 2014 15:31:16 Christoffer Dall wrote:
>> On 29 July 2014 15:08, Mark Rutland <mark.rutland@arm.com> wrote:
>> > On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
>> >> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
>> >> >
>> >> > For reference, Red Hat's current arguing point for ACPI in VMs is
>> >> > hotplug of things like CPUs and memory for very large VMs, but I
>> >> > haven't thought too carefully about this just yet, as I don't have a
>> >> > 100+ core ARM 64-bit hardware lying around...
>> >>
>> >> I thought you could run guests with more virtual CPUs that you have
>> >> physical CPUs on the host.
>> >>
>> >> Regarding CPU and memory hotplug, don't we already have PSCI and
>> >> xen-balloon/virtio-balloon for that?
>> >
>> > PSCI (0.1) was there for guests from the start, and ACPI doesn't do
>> > anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
>> > be used by guests supporting only PSCI 0.1). So there's no magic for
>> > CPU hotplug provided by ACPI.
>>
>> With PSCI you can only provide your VM a bunch of CPUs and say that
>> they're all turned off, and then turn some of them on later.  I
>> honestly don't know if you can do proper CPU hotplug with ACPI, but
>> the RH guys seem to argue that you can.  Again, I didn't think too
>> carefully about this.
>
> Xen does this in drivers/xen/cpu_hotplug.c, acpi does it in
> drivers/acpi/acpi_processor.c.
>
>> > Do either of the balloon drivers allow for memory to be hot-added to a
>> > system initially provisioned with less?
>> >
>> No, it's just about reclaiming memory.  Same argument as above.
>
> Again, Xen seems to be able to add more memory:
>
> config XEN_BALLOON_MEMORY_HOTPLUG
>         bool "Memory hotplug support for Xen balloon driver"
>         default n
>         depends on XEN_BALLOON && MEMORY_HOTPLUG
>         help
>           Memory hotplug support for Xen balloon driver allows expanding memory
>           available for the system above limit declared at system startup.
>           It is very useful on critical systems which require long
>           run without rebooting.
>           ...
>
> The same goes for hyperv, s390 and vmware. It should not be hard to add it
> for KVM.
>
Absolutely, and I would prefer doing that over adding ACPI in guests
as things stand right now.  We can have another fun discussion about
this at LCU...

-Christoffer

Re: [PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> the former signals to the OS that the hardware is PSCI compliant.
> The latter selects the appropriate conduit for PSCI calls by
> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> (SMC).
>
> FADT table contains such information, parse FADT to get the flags
> for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
> function IDs, which means that only PSCI 0.2+ is supported in ACPI.
>
> At the same time, only ACPI 5.1 or higher verison supports PSCI,
> and FADT Major.Minor version was introduced in ACPI 5.1, so we
> will check the version and only parse FADT table with version >= 5.1.
>
> If firmware provides ACPI tables with ACPI version less than 5.1,
> OS will be messed up with those information and have no way to
> bring up secondery CPUs, so disable ACPI if we get an FADT table
> with version less that 5.1.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> ---
>   arch/arm64/include/asm/acpi.h |    2 +
>   arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
>   arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
>   arch/arm64/kernel/setup.c     |    2 +
>   4 files changed, 121 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 44b617f..67dac90 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -18,6 +18,8 @@ extern int acpi_disabled;
>   extern int acpi_noirq;
>   extern int acpi_pci_disabled;
>   extern int acpi_strict;
> +extern int acpi_psci_present;
> +extern int acpi_psci_use_hvc;
>
>   static inline void disable_acpi(void)
>   {
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index f5a10b5..374926f 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -11,6 +11,8 @@
>    *  published by the Free Software Foundation.
>    */
>
> +#define pr_fmt(fmt) "ACPI: " fmt
> +
>   #include <linux/init.h>
>   #include <linux/acpi.h>
>   #include <linux/cpumask.h>
> @@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
>   int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
>   EXPORT_SYMBOL(acpi_pci_disabled);
>
> +/* 1 to indicate PSCI is implemented */
> +int acpi_psci_present;
> +
> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> +int acpi_psci_use_hvc;
> +

These can be boolean but can be removed IMO, see below.

>   /*
>    * __acpi_map_table() will be called before page_init(), so early_ioremap()
>    * or early_memremap() should be called here to for ACPI table mapping.
> @@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>   	early_iounmap(map, size);
>   }
>
> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> +{
> +	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> +
> +	/*
> +	 * Revision in table header is the FADT Major version,
> +	 * and there is a minor version of FADT which was introduced
> +	 * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
> +	 * to get arm boot flags, or we will disable ACPI.
> +	 */
> +	if (table->revision < 5 || fadt->minor_version < 1) {
> +		pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
> +			table->revision, fadt->minor_version);
> +		acpi_psci_present = 0;
> +		disable_acpi();
> +		return -EINVAL;
> +	}
> +
> +	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
> +		acpi_psci_present = 1;
> +
> +	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
> +		acpi_psci_use_hvc = 1;
> +

Why not make this macros instead of global variables as I suggested in
previous version. acpi_gbl_FADT is already global and you can avoid
creating new one especially they are just used on boot/init.

Regards,
Sudeep

Re: [PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> the former signals to the OS that the hardware is PSCI compliant.
> The latter selects the appropriate conduit for PSCI calls by
> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> (SMC).
>
> FADT table contains such information, parse FADT to get the flags
> for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
> function IDs, which means that only PSCI 0.2+ is supported in ACPI.
>
> At the same time, only ACPI 5.1 or higher verison supports PSCI,
> and FADT Major.Minor version was introduced in ACPI 5.1, so we
> will check the version and only parse FADT table with version >= 5.1.
>
> If firmware provides ACPI tables with ACPI version less than 5.1,
> OS will be messed up with those information and have no way to
> bring up secondery CPUs, so disable ACPI if we get an FADT table
> with version less that 5.1.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> ---
>   arch/arm64/include/asm/acpi.h |    2 +
>   arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
>   arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
>   arch/arm64/kernel/setup.c     |    2 +
>   4 files changed, 121 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 44b617f..67dac90 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -18,6 +18,8 @@ extern int acpi_disabled;
>   extern int acpi_noirq;
>   extern int acpi_pci_disabled;
>   extern int acpi_strict;
> +extern int acpi_psci_present;
> +extern int acpi_psci_use_hvc;
>
>   static inline void disable_acpi(void)
>   {
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index f5a10b5..374926f 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -11,6 +11,8 @@
>    *  published by the Free Software Foundation.
>    */
>
> +#define pr_fmt(fmt) "ACPI: " fmt
> +
>   #include <linux/init.h>
>   #include <linux/acpi.h>
>   #include <linux/cpumask.h>
> @@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
>   int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
>   EXPORT_SYMBOL(acpi_pci_disabled);
>
> +/* 1 to indicate PSCI is implemented */
> +int acpi_psci_present;
> +
> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> +int acpi_psci_use_hvc;
> +

These can be boolean but can be removed IMO, see below.

>   /*
>    * __acpi_map_table() will be called before page_init(), so early_ioremap()
>    * or early_memremap() should be called here to for ACPI table mapping.
> @@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>   	early_iounmap(map, size);
>   }
>
> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> +{
> +	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> +
> +	/*
> +	 * Revision in table header is the FADT Major version,
> +	 * and there is a minor version of FADT which was introduced
> +	 * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
> +	 * to get arm boot flags, or we will disable ACPI.
> +	 */
> +	if (table->revision < 5 || fadt->minor_version < 1) {
> +		pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
> +			table->revision, fadt->minor_version);
> +		acpi_psci_present = 0;
> +		disable_acpi();
> +		return -EINVAL;
> +	}
> +
> +	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
> +		acpi_psci_present = 1;
> +
> +	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
> +		acpi_psci_use_hvc = 1;
> +

Why not make this macros instead of global variables as I suggested in
previous version. acpi_gbl_FADT is already global and you can avoid
creating new one especially they are just used on boot/init.

Regards,
Sudeep

[PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> the former signals to the OS that the hardware is PSCI compliant.
> The latter selects the appropriate conduit for PSCI calls by
> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> (SMC).
>
> FADT table contains such information, parse FADT to get the flags
> for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
> function IDs, which means that only PSCI 0.2+ is supported in ACPI.
>
> At the same time, only ACPI 5.1 or higher verison supports PSCI,
> and FADT Major.Minor version was introduced in ACPI 5.1, so we
> will check the version and only parse FADT table with version >= 5.1.
>
> If firmware provides ACPI tables with ACPI version less than 5.1,
> OS will be messed up with those information and have no way to
> bring up secondery CPUs, so disable ACPI if we get an FADT table
> with version less that 5.1.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> ---
>   arch/arm64/include/asm/acpi.h |    2 +
>   arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
>   arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
>   arch/arm64/kernel/setup.c     |    2 +
>   4 files changed, 121 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 44b617f..67dac90 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -18,6 +18,8 @@ extern int acpi_disabled;
>   extern int acpi_noirq;
>   extern int acpi_pci_disabled;
>   extern int acpi_strict;
> +extern int acpi_psci_present;
> +extern int acpi_psci_use_hvc;
>
>   static inline void disable_acpi(void)
>   {
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index f5a10b5..374926f 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -11,6 +11,8 @@
>    *  published by the Free Software Foundation.
>    */
>
> +#define pr_fmt(fmt) "ACPI: " fmt
> +
>   #include <linux/init.h>
>   #include <linux/acpi.h>
>   #include <linux/cpumask.h>
> @@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
>   int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
>   EXPORT_SYMBOL(acpi_pci_disabled);
>
> +/* 1 to indicate PSCI is implemented */
> +int acpi_psci_present;
> +
> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> +int acpi_psci_use_hvc;
> +

These can be boolean but can be removed IMO, see below.

>   /*
>    * __acpi_map_table() will be called before page_init(), so early_ioremap()
>    * or early_memremap() should be called here to for ACPI table mapping.
> @@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>   	early_iounmap(map, size);
>   }
>
> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> +{
> +	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> +
> +	/*
> +	 * Revision in table header is the FADT Major version,
> +	 * and there is a minor version of FADT which was introduced
> +	 * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
> +	 * to get arm boot flags, or we will disable ACPI.
> +	 */
> +	if (table->revision < 5 || fadt->minor_version < 1) {
> +		pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
> +			table->revision, fadt->minor_version);
> +		acpi_psci_present = 0;
> +		disable_acpi();
> +		return -EINVAL;
> +	}
> +
> +	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
> +		acpi_psci_present = 1;
> +
> +	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
> +		acpi_psci_use_hvc = 1;
> +

Why not make this macros instead of global variables as I suggested in
previous version. acpi_gbl_FADT is already global and you can avoid
creating new one especially they are just used on boot/init.

Regards,
Sudeep

Re: [PATCH 05/19] ARM64 / ACPI: Make PCI optional for ACPI on ARM64

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> As PCI for ARM64 is not ready, so introduce some stub functions
> to make PCI optional for ACPI, and make ACPI core run without
> CONFIG_PCI on ARM64.
>
> Since ACPI on X86 and IA64 depends on PCI and this patch only makes
> PCI optinal for ARM64, it will not break anything on X86 and IA64.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/pci.h |   11 +++++++++++
>   drivers/acpi/Makefile        |    2 +-
>   drivers/acpi/internal.h      |    5 +++++
>   include/linux/pci.h          |   37 +++++++++++++++++++++++++++----------
>   4 files changed, 44 insertions(+), 11 deletions(-)
>   create mode 100644 arch/arm64/include/asm/pci.h
>
> diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> new file mode 100644
> index 0000000..250cd24
> --- /dev/null
> +++ b/arch/arm64/include/asm/pci.h
> @@ -0,0 +1,11 @@
> +#ifndef __ASM_PCI_H
> +#define __ASM_PCI_H
> +#ifdef __KERNEL__
> +
> +/*
> + * PCI address space differs from physical memory address space
> + */
> +#define PCI_DMA_BUS_IS_PHYS	(0)
> +
> +#endif  /* __KERNEL__ */
> +#endif  /* __ASM_PCI_H */
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 505d4d7..8e9bbe6 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -39,7 +39,7 @@ acpi-y				+= processor_core.o
>   acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
>   acpi-y				+= ec.o
>   acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
> -acpi-y				+= pci_root.o pci_link.o pci_irq.o
> +acpi-$(CONFIG_PCI)		+= pci_root.o pci_link.o pci_irq.o
>   acpi-y				+= acpi_lpss.o
>   acpi-y				+= acpi_platform.o
>   acpi-y				+= acpi_pnp.o
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 4c5cf77..e1e6487 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -26,8 +26,13 @@
>   acpi_status acpi_os_initialize1(void);
>   int init_acpi_device_notify(void);
>   int acpi_scan_init(void);
> +#ifdef CONFIG_PCI
>   void acpi_pci_root_init(void);
>   void acpi_pci_link_init(void);
> +#else
> +static inline void acpi_pci_root_init(void) {}
> +static inline void acpi_pci_link_init(void) {}
> +#endif
>   void acpi_processor_init(void);
>   void acpi_platform_init(void);
>   void acpi_pnp_init(void);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 466bcd1..27d7354 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h

[...]

> @@ -1394,6 +1395,23 @@ static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
>   						unsigned int devfn)
>   { return NULL; }
>
> +static inline struct pci_bus *pci_find_bus(int domain, int busnr)
> +{ return NULL; }
> +
> +static inline int pci_bus_write_config_byte(struct pci_bus *bus,
> +				unsigned int devfn, int where, u8 val)
> +{ return -ENODEV; }
> +
> +static inline int raw_pci_read(unsigned int domain, unsigned int bus,
> +			unsigned int devfn, int reg, int len, u32 *val)
> +{ return -EINVAL; }
> +
> +static inline int raw_pci_write(unsigned int domain, unsigned int bus,
> +			unsigned int devfn, int reg, int len, u32 val)
> +{ return -EINVAL; }

IMO -ENOSYS is more suitable as these functions are not implemented
for !CONFIG_PCI

Regards,
Sudeep

Re: [PATCH 05/19] ARM64 / ACPI: Make PCI optional for ACPI on ARM64

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> As PCI for ARM64 is not ready, so introduce some stub functions
> to make PCI optional for ACPI, and make ACPI core run without
> CONFIG_PCI on ARM64.
>
> Since ACPI on X86 and IA64 depends on PCI and this patch only makes
> PCI optinal for ARM64, it will not break anything on X86 and IA64.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/pci.h |   11 +++++++++++
>   drivers/acpi/Makefile        |    2 +-
>   drivers/acpi/internal.h      |    5 +++++
>   include/linux/pci.h          |   37 +++++++++++++++++++++++++++----------
>   4 files changed, 44 insertions(+), 11 deletions(-)
>   create mode 100644 arch/arm64/include/asm/pci.h
>
> diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> new file mode 100644
> index 0000000..250cd24
> --- /dev/null
> +++ b/arch/arm64/include/asm/pci.h
> @@ -0,0 +1,11 @@
> +#ifndef __ASM_PCI_H
> +#define __ASM_PCI_H
> +#ifdef __KERNEL__
> +
> +/*
> + * PCI address space differs from physical memory address space
> + */
> +#define PCI_DMA_BUS_IS_PHYS	(0)
> +
> +#endif  /* __KERNEL__ */
> +#endif  /* __ASM_PCI_H */
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 505d4d7..8e9bbe6 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -39,7 +39,7 @@ acpi-y				+= processor_core.o
>   acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
>   acpi-y				+= ec.o
>   acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
> -acpi-y				+= pci_root.o pci_link.o pci_irq.o
> +acpi-$(CONFIG_PCI)		+= pci_root.o pci_link.o pci_irq.o
>   acpi-y				+= acpi_lpss.o
>   acpi-y				+= acpi_platform.o
>   acpi-y				+= acpi_pnp.o
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 4c5cf77..e1e6487 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -26,8 +26,13 @@
>   acpi_status acpi_os_initialize1(void);
>   int init_acpi_device_notify(void);
>   int acpi_scan_init(void);
> +#ifdef CONFIG_PCI
>   void acpi_pci_root_init(void);
>   void acpi_pci_link_init(void);
> +#else
> +static inline void acpi_pci_root_init(void) {}
> +static inline void acpi_pci_link_init(void) {}
> +#endif
>   void acpi_processor_init(void);
>   void acpi_platform_init(void);
>   void acpi_pnp_init(void);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 466bcd1..27d7354 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h

[...]

> @@ -1394,6 +1395,23 @@ static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
>   						unsigned int devfn)
>   { return NULL; }
>
> +static inline struct pci_bus *pci_find_bus(int domain, int busnr)
> +{ return NULL; }
> +
> +static inline int pci_bus_write_config_byte(struct pci_bus *bus,
> +				unsigned int devfn, int where, u8 val)
> +{ return -ENODEV; }
> +
> +static inline int raw_pci_read(unsigned int domain, unsigned int bus,
> +			unsigned int devfn, int reg, int len, u32 *val)
> +{ return -EINVAL; }
> +
> +static inline int raw_pci_write(unsigned int domain, unsigned int bus,
> +			unsigned int devfn, int reg, int len, u32 val)
> +{ return -EINVAL; }

IMO -ENOSYS is more suitable as these functions are not implemented
for !CONFIG_PCI

Regards,
Sudeep

[PATCH 05/19] ARM64 / ACPI: Make PCI optional for ACPI on ARM64

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> As PCI for ARM64 is not ready, so introduce some stub functions
> to make PCI optional for ACPI, and make ACPI core run without
> CONFIG_PCI on ARM64.
>
> Since ACPI on X86 and IA64 depends on PCI and this patch only makes
> PCI optinal for ARM64, it will not break anything on X86 and IA64.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> ---
>   arch/arm64/include/asm/pci.h |   11 +++++++++++
>   drivers/acpi/Makefile        |    2 +-
>   drivers/acpi/internal.h      |    5 +++++
>   include/linux/pci.h          |   37 +++++++++++++++++++++++++++----------
>   4 files changed, 44 insertions(+), 11 deletions(-)
>   create mode 100644 arch/arm64/include/asm/pci.h
>
> diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> new file mode 100644
> index 0000000..250cd24
> --- /dev/null
> +++ b/arch/arm64/include/asm/pci.h
> @@ -0,0 +1,11 @@
> +#ifndef __ASM_PCI_H
> +#define __ASM_PCI_H
> +#ifdef __KERNEL__
> +
> +/*
> + * PCI address space differs from physical memory address space
> + */
> +#define PCI_DMA_BUS_IS_PHYS	(0)
> +
> +#endif  /* __KERNEL__ */
> +#endif  /* __ASM_PCI_H */
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 505d4d7..8e9bbe6 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -39,7 +39,7 @@ acpi-y				+= processor_core.o
>   acpi-$(CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC) += processor_pdc.o
>   acpi-y				+= ec.o
>   acpi-$(CONFIG_ACPI_DOCK)	+= dock.o
> -acpi-y				+= pci_root.o pci_link.o pci_irq.o
> +acpi-$(CONFIG_PCI)		+= pci_root.o pci_link.o pci_irq.o
>   acpi-y				+= acpi_lpss.o
>   acpi-y				+= acpi_platform.o
>   acpi-y				+= acpi_pnp.o
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 4c5cf77..e1e6487 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -26,8 +26,13 @@
>   acpi_status acpi_os_initialize1(void);
>   int init_acpi_device_notify(void);
>   int acpi_scan_init(void);
> +#ifdef CONFIG_PCI
>   void acpi_pci_root_init(void);
>   void acpi_pci_link_init(void);
> +#else
> +static inline void acpi_pci_root_init(void) {}
> +static inline void acpi_pci_link_init(void) {}
> +#endif
>   void acpi_processor_init(void);
>   void acpi_platform_init(void);
>   void acpi_pnp_init(void);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 466bcd1..27d7354 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h

[...]

> @@ -1394,6 +1395,23 @@ static inline struct pci_dev *pci_get_bus_and_slot(unsigned int bus,
>   						unsigned int devfn)
>   { return NULL; }
>
> +static inline struct pci_bus *pci_find_bus(int domain, int busnr)
> +{ return NULL; }
> +
> +static inline int pci_bus_write_config_byte(struct pci_bus *bus,
> +				unsigned int devfn, int where, u8 val)
> +{ return -ENODEV; }
> +
> +static inline int raw_pci_read(unsigned int domain, unsigned int bus,
> +			unsigned int devfn, int reg, int len, u32 *val)
> +{ return -EINVAL; }
> +
> +static inline int raw_pci_write(unsigned int domain, unsigned int bus,
> +			unsigned int devfn, int reg, int len, u32 val)
> +{ return -EINVAL; }

IMO -ENOSYS is more suitable as these functions are not implemented
for !CONFIG_PCI

Regards,
Sudeep

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-7-29 21:31, Christoffer Dall wrote:
> On 29 July 2014 15:08, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
>>> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
>>>>
>>>> For reference, Red Hat's current arguing point for ACPI in VMs is
>>>> hotplug of things like CPUs and memory for very large VMs, but I
>>>> haven't thought too carefully about this just yet, as I don't have a
>>>> 100+ core ARM 64-bit hardware lying around...
>>>
>>> I thought you could run guests with more virtual CPUs that you have
>>> physical CPUs on the host.
>>>
>>> Regarding CPU and memory hotplug, don't we already have PSCI and
>>> xen-balloon/virtio-balloon for that?
>>
>> PSCI (0.1) was there for guests from the start, and ACPI doesn't do
>> anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
>> be used by guests supporting only PSCI 0.1). So there's no magic for
>> CPU hotplug provided by ACPI.
> 
> With PSCI you can only provide your VM a bunch of CPUs and say that
> they're all turned off, and then turn some of them on later.  

Yes, agreed.

> I honestly don't know if you can do proper CPU hotplug with ACPI, but
> the RH guys seem to argue that you can.  Again, I didn't think too
> carefully about this.

Yes, we can do proper CPU hotplug with ACPI based physical hotplug (named
dynamic device configuration in ACPI spec), you can refer to section 6.3
"Device Insertion, Removal, and Status Objects" in ACPI 5.1.

There are mechanisms for handling dynamic insertion and removal of devices
and for determining device and notification processing status. When removing
a processor,

a) we will call PSCI or similar interface to offline a CPU from OS, then
   OS will not use it any more;

b) call ACPI API to trim the resources that allocated during device
   enumeration;

c) Call ACPI method _EJ0 and then will notify firmware or hypervisor device
   will be removed, jump to firmware or hypervisor to remove the device
   from that level;

CPU hotplug with ACPI is pretty mature on x86 and it works on VM too. I prepared
some patches to support CPU hotplug on ARM64 and simulated the hot add/remove
notify to test those patches, it worked as expected, I will send them out
when this patchset is ready for mainline.

Thanks
Hanjun

[PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-7-29 21:31, Christoffer Dall wrote:
> On 29 July 2014 15:08, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
>>> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
>>>>
>>>> For reference, Red Hat's current arguing point for ACPI in VMs is
>>>> hotplug of things like CPUs and memory for very large VMs, but I
>>>> haven't thought too carefully about this just yet, as I don't have a
>>>> 100+ core ARM 64-bit hardware lying around...
>>>
>>> I thought you could run guests with more virtual CPUs that you have
>>> physical CPUs on the host.
>>>
>>> Regarding CPU and memory hotplug, don't we already have PSCI and
>>> xen-balloon/virtio-balloon for that?
>>
>> PSCI (0.1) was there for guests from the start, and ACPI doesn't do
>> anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
>> be used by guests supporting only PSCI 0.1). So there's no magic for
>> CPU hotplug provided by ACPI.
> 
> With PSCI you can only provide your VM a bunch of CPUs and say that
> they're all turned off, and then turn some of them on later.  

Yes, agreed.

> I honestly don't know if you can do proper CPU hotplug with ACPI, but
> the RH guys seem to argue that you can.  Again, I didn't think too
> carefully about this.

Yes, we can do proper CPU hotplug with ACPI based physical hotplug (named
dynamic device configuration in ACPI spec), you can refer to section 6.3
"Device Insertion, Removal, and Status Objects" in ACPI 5.1.

There are mechanisms for handling dynamic insertion and removal of devices
and for determining device and notification processing status. When removing
a processor,

a) we will call PSCI or similar interface to offline a CPU from OS, then
   OS will not use it any more;

b) call ACPI API to trim the resources that allocated during device
   enumeration;

c) Call ACPI method _EJ0 and then will notify firmware or hypervisor device
   will be removed, jump to firmware or hypervisor to remove the device
   from that level;

CPU hotplug with ACPI is pretty mature on x86 and it works on VM too. I prepared
some patches to support CPU hotplug on ARM64 and simulated the hot add/remove
notify to test those patches, it worked as expected, I will send them out
when this patchset is ready for mainline.

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On 30 July 2014 08:47, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> On 2014-7-29 21:31, Christoffer Dall wrote:
>> On 29 July 2014 15:08, Mark Rutland <mark.rutland@arm.com> wrote:
>>> On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
>>>> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
>>>>>
>>>>> For reference, Red Hat's current arguing point for ACPI in VMs is
>>>>> hotplug of things like CPUs and memory for very large VMs, but I
>>>>> haven't thought too carefully about this just yet, as I don't have a
>>>>> 100+ core ARM 64-bit hardware lying around...
>>>>
>>>> I thought you could run guests with more virtual CPUs that you have
>>>> physical CPUs on the host.
>>>>
>>>> Regarding CPU and memory hotplug, don't we already have PSCI and
>>>> xen-balloon/virtio-balloon for that?
>>>
>>> PSCI (0.1) was there for guests from the start, and ACPI doesn't do
>>> anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
>>> be used by guests supporting only PSCI 0.1). So there's no magic for
>>> CPU hotplug provided by ACPI.
>>
>> With PSCI you can only provide your VM a bunch of CPUs and say that
>> they're all turned off, and then turn some of them on later.
>
> Yes, agreed.
>
>> I honestly don't know if you can do proper CPU hotplug with ACPI, but
>> the RH guys seem to argue that you can.  Again, I didn't think too
>> carefully about this.
>
> Yes, we can do proper CPU hotplug with ACPI based physical hotplug (named
> dynamic device configuration in ACPI spec), you can refer to section 6.3
> "Device Insertion, Removal, and Status Objects" in ACPI 5.1.
>
> There are mechanisms for handling dynamic insertion and removal of devices
> and for determining device and notification processing status. When removing
> a processor,
>
> a) we will call PSCI or similar interface to offline a CPU from OS, then
>    OS will not use it any more;
>
> b) call ACPI API to trim the resources that allocated during device
>    enumeration;
>
> c) Call ACPI method _EJ0 and then will notify firmware or hypervisor device
>    will be removed, jump to firmware or hypervisor to remove the device
>    from that level;

When you say notify hypervisor, would we really need a
hypervisor-specific interface if you're running UEFI as your firmware?
 Can you not just call whatever UEFI service to remove a CPU and let
that UEFI implementation deal with the hypervisor/hardware interface?

-Christoffer

[PATCH 19/19] Documentation: ACPI for ARM64

[Christoffer Dall]

On 30 July 2014 08:47, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> On 2014-7-29 21:31, Christoffer Dall wrote:
>> On 29 July 2014 15:08, Mark Rutland <mark.rutland@arm.com> wrote:
>>> On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
>>>> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
>>>>>
>>>>> For reference, Red Hat's current arguing point for ACPI in VMs is
>>>>> hotplug of things like CPUs and memory for very large VMs, but I
>>>>> haven't thought too carefully about this just yet, as I don't have a
>>>>> 100+ core ARM 64-bit hardware lying around...
>>>>
>>>> I thought you could run guests with more virtual CPUs that you have
>>>> physical CPUs on the host.
>>>>
>>>> Regarding CPU and memory hotplug, don't we already have PSCI and
>>>> xen-balloon/virtio-balloon for that?
>>>
>>> PSCI (0.1) was there for guests from the start, and ACPI doesn't do
>>> anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
>>> be used by guests supporting only PSCI 0.1). So there's no magic for
>>> CPU hotplug provided by ACPI.
>>
>> With PSCI you can only provide your VM a bunch of CPUs and say that
>> they're all turned off, and then turn some of them on later.
>
> Yes, agreed.
>
>> I honestly don't know if you can do proper CPU hotplug with ACPI, but
>> the RH guys seem to argue that you can.  Again, I didn't think too
>> carefully about this.
>
> Yes, we can do proper CPU hotplug with ACPI based physical hotplug (named
> dynamic device configuration in ACPI spec), you can refer to section 6.3
> "Device Insertion, Removal, and Status Objects" in ACPI 5.1.
>
> There are mechanisms for handling dynamic insertion and removal of devices
> and for determining device and notification processing status. When removing
> a processor,
>
> a) we will call PSCI or similar interface to offline a CPU from OS, then
>    OS will not use it any more;
>
> b) call ACPI API to trim the resources that allocated during device
>    enumeration;
>
> c) Call ACPI method _EJ0 and then will notify firmware or hypervisor device
>    will be removed, jump to firmware or hypervisor to remove the device
>    from that level;

When you say notify hypervisor, would we really need a
hypervisor-specific interface if you're running UEFI as your firmware?
 Can you not just call whatever UEFI service to remove a CPU and let
that UEFI implementation deal with the hypervisor/hardware interface?

-Christoffer

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-7-30 15:14, Christoffer Dall wrote:
> On 30 July 2014 08:47, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> On 2014-7-29 21:31, Christoffer Dall wrote:
>>> On 29 July 2014 15:08, Mark Rutland <mark.rutland@arm.com> wrote:
>>>> On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
>>>>> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
>>>>>>
>>>>>> For reference, Red Hat's current arguing point for ACPI in VMs is
>>>>>> hotplug of things like CPUs and memory for very large VMs, but I
>>>>>> haven't thought too carefully about this just yet, as I don't have a
>>>>>> 100+ core ARM 64-bit hardware lying around...
>>>>>
>>>>> I thought you could run guests with more virtual CPUs that you have
>>>>> physical CPUs on the host.
>>>>>
>>>>> Regarding CPU and memory hotplug, don't we already have PSCI and
>>>>> xen-balloon/virtio-balloon for that?
>>>>
>>>> PSCI (0.1) was there for guests from the start, and ACPI doesn't do
>>>> anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
>>>> be used by guests supporting only PSCI 0.1). So there's no magic for
>>>> CPU hotplug provided by ACPI.
>>>
>>> With PSCI you can only provide your VM a bunch of CPUs and say that
>>> they're all turned off, and then turn some of them on later.
>>
>> Yes, agreed.
>>
>>> I honestly don't know if you can do proper CPU hotplug with ACPI, but
>>> the RH guys seem to argue that you can.  Again, I didn't think too
>>> carefully about this.
>>
>> Yes, we can do proper CPU hotplug with ACPI based physical hotplug (named
>> dynamic device configuration in ACPI spec), you can refer to section 6.3
>> "Device Insertion, Removal, and Status Objects" in ACPI 5.1.
>>
>> There are mechanisms for handling dynamic insertion and removal of devices
>> and for determining device and notification processing status. When removing
>> a processor,
>>
>> a) we will call PSCI or similar interface to offline a CPU from OS, then
>>    OS will not use it any more;
>>
>> b) call ACPI API to trim the resources that allocated during device
>>    enumeration;
>>
>> c) Call ACPI method _EJ0 and then will notify firmware or hypervisor device
>>    will be removed, jump to firmware or hypervisor to remove the device
>>    from that level;
> 
> When you say notify hypervisor, would we really need a
> hypervisor-specific interface if you're running UEFI as your firmware?
>  Can you not just call whatever UEFI service to remove a CPU and let
> that UEFI implementation deal with the hypervisor/hardware interface?

Yes, it should work as you said, OS will notfy UEFI and then UEFI deal with
hypervisor interface, sorry, I didn't describe it clearly.

Thanks
Hanjun

[PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-7-30 15:14, Christoffer Dall wrote:
> On 30 July 2014 08:47, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> On 2014-7-29 21:31, Christoffer Dall wrote:
>>> On 29 July 2014 15:08, Mark Rutland <mark.rutland@arm.com> wrote:
>>>> On Tue, Jul 29, 2014 at 01:52:40PM +0100, Arnd Bergmann wrote:
>>>>> On Tuesday 29 July 2014 14:37:38 Christoffer Dall wrote:
>>>>>>
>>>>>> For reference, Red Hat's current arguing point for ACPI in VMs is
>>>>>> hotplug of things like CPUs and memory for very large VMs, but I
>>>>>> haven't thought too carefully about this just yet, as I don't have a
>>>>>> 100+ core ARM 64-bit hardware lying around...
>>>>>
>>>>> I thought you could run guests with more virtual CPUs that you have
>>>>> physical CPUs on the host.
>>>>>
>>>>> Regarding CPU and memory hotplug, don't we already have PSCI and
>>>>> xen-balloon/virtio-balloon for that?
>>>>
>>>> PSCI (0.1) was there for guests from the start, and ACPI doesn't do
>>>> anything different w.r.t. PSCI other than requiring PSCI 0.2 (which can
>>>> be used by guests supporting only PSCI 0.1). So there's no magic for
>>>> CPU hotplug provided by ACPI.
>>>
>>> With PSCI you can only provide your VM a bunch of CPUs and say that
>>> they're all turned off, and then turn some of them on later.
>>
>> Yes, agreed.
>>
>>> I honestly don't know if you can do proper CPU hotplug with ACPI, but
>>> the RH guys seem to argue that you can.  Again, I didn't think too
>>> carefully about this.
>>
>> Yes, we can do proper CPU hotplug with ACPI based physical hotplug (named
>> dynamic device configuration in ACPI spec), you can refer to section 6.3
>> "Device Insertion, Removal, and Status Objects" in ACPI 5.1.
>>
>> There are mechanisms for handling dynamic insertion and removal of devices
>> and for determining device and notification processing status. When removing
>> a processor,
>>
>> a) we will call PSCI or similar interface to offline a CPU from OS, then
>>    OS will not use it any more;
>>
>> b) call ACPI API to trim the resources that allocated during device
>>    enumeration;
>>
>> c) Call ACPI method _EJ0 and then will notify firmware or hypervisor device
>>    will be removed, jump to firmware or hypervisor to remove the device
>>    from that level;
> 
> When you say notify hypervisor, would we really need a
> hypervisor-specific interface if you're running UEFI as your firmware?
>  Can you not just call whatever UEFI service to remove a CPU and let
> that UEFI implementation deal with the hypervisor/hardware interface?

Yes, it should work as you said, OS will notfy UEFI and then UEFI deal with
hypervisor interface, sorry, I didn't describe it clearly.

Thanks
Hanjun

Re: [PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> MADT contains the information for MPIDR which is essential for
> SMP initialization, parse the GIC cpu interface structures to
> get the MPIDR value and map it to cpu_logical_map(), and add
> enabled cpu with valid MPIDR into cpu_possible_map and
> cpu_present_map.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>   arch/arm64/include/asm/acpi.h |    2 +
>   arch/arm64/kernel/acpi.c      |  127 +++++++++++++++++++++++++++++++++++++++++
>   arch/arm64/kernel/smp.c       |   10 +++-
>   3 files changed, 138 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 67dac90..5ce85f8 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -50,6 +50,8 @@ static inline bool acpi_has_cpu_in_madt(void)
>   extern int (*acpi_suspend_lowlevel)(void);
>   #define acpi_wakeup_address 0
>
> +#define MAX_GIC_CPU_INTERFACE 65535
> +

Can this me made something like MAX_MADT_INTERRUPT_CONTROLLER_ENTRIES ?
And assuming each entry to be at-least 4 or 8 bytes, it can be reduced.

>   #endif /* CONFIG_ACPI */
>
>   #endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 374926f..801e268 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -22,6 +22,9 @@
>   #include <linux/bootmem.h>
>   #include <linux/smp.h>
>
> +#include <asm/smp_plat.h>
> +#include <asm/cputype.h>
> +
>   /*
>    * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>    * variable is still required by the ACPI core
> @@ -42,6 +45,9 @@ int acpi_psci_present;
>   /* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>   int acpi_psci_use_hvc;
>
> +/* Processors (GICC) with enabled flag in MADT */
> +static int enabled_cpus;
> +
>   /*
>    * __acpi_map_table() will be called before page_init(), so early_ioremap()
>    * or early_memremap() should be called here to for ACPI table mapping.
> @@ -62,6 +68,122 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>   	early_iounmap(map, size);
>   }
>
> +/**
> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
> + * generates a logic cpu number
> + * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
> + * @enabled: this cpu is enabled or not
> + *
> + * Returns the logic cpu number which maps to the gic cpu interface
> + */
> +static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)

Honestly this function doesn't deal anything with GIC cpu interface.

> +{
> +	int cpu;
> +
> +	if (mpidr == INVALID_HWID) {
> +		pr_info("Skip invalid cpu hardware ID\n");
> +		return -EINVAL;
> +	}
> +
> +	total_cpus++;
> +	if (!enabled)
> +		return -EINVAL;
> +
> +	if (enabled_cpus >=  NR_CPUS) {
> +		pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
> +			NR_CPUS, total_cpus, mpidr);
> +		return -EINVAL;
> +	}
> +
> +	/* If it is the first CPU, no need to check duplicate MPIDRs */
> +	if (!enabled_cpus)
> +		goto skip_mpidr_check;
> +
> +	/*
> +	 * Duplicate MPIDRs are a recipe for disaster. Scan
> +	 * all initialized entries and check for
> +	 * duplicates. If any is found just ignore the CPU.
> +	 */
> +	for_each_present_cpu(cpu) {
> +		if (cpu_logical_map(cpu) == mpidr) {
> +			pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
> +			       mpidr);
> +			return -EINVAL;
> +		}
> +	}
> +
> +skip_mpidr_check:
> +	enabled_cpus++;
> +
> +	/* allocate a logic cpu id for the new comer */
> +	if (cpu_logical_map(0) == mpidr) {
> +		/*
> +		 * boot_cpu_init() already hold bit 0 in cpu_present_mask
> +		 * for BSP, no need to allocte again.
> +		 */
> +		cpu = 0;
> +	} else {
> +		cpu = cpumask_next_zero(-1, cpu_present_mask);
> +	}
> +
> +	/* map the logic cpu id to cpu MPIDR */
> +	cpu_logical_map(cpu) = mpidr;
> +
> +	set_cpu_possible(cpu, true);
> +	set_cpu_present(cpu, true);
> +

I need to think more about this function and will comment later but I
think these cpumasks should be set only if SMP and probably belong to smp.c

> +	return cpu;
> +}
> +
> +static int __init
> +acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
> +				const unsigned long end)
> +{
> +	struct acpi_madt_generic_interrupt *processor;
> +
> +	processor = (struct acpi_madt_generic_interrupt *)header;
> +
> +	if (BAD_MADT_ENTRY(processor, end))
> +		return -EINVAL;
> +
> +	acpi_table_print_madt_entry(header);
> +
> +	acpi_register_gic_cpu_interface(processor->mpidr,
> +		processor->flags & ACPI_MADT_ENABLED);
> +
> +	return 0;
> +}
> +
> +/*
> + * Parse GIC cpu interface related entries in MADT
> + * returns 0 on success, < 0 on error
> + */
> +static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
> +{
> +	int count;
> +
> +	/*
> +	 * do a partial walk of MADT to determine how many CPUs
> +	 * we have including disabled CPUs, and get information
> +	 * we need for SMP init
> +	 */
> +	count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
> +			acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
> +
> +	if (!count) {
> +		pr_err("No GIC CPU interface entries present\n");
> +		return -ENODEV;
> +	} else if (count < 0) {
> +		pr_err("Error parsing GIC CPU interface entry\n");
> +		return count;
> +	}
> +
> +	/* Make boot-up look pretty */
> +	pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
> +
> +	return 0;
> +}
> +
>   static int __init acpi_parse_fadt(struct acpi_table_header *table)
>   {
>   	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> @@ -122,6 +244,11 @@ int __init acpi_boot_init(void)
>   	if (err)
>   		pr_err("Can't find FADT\n");
>
> +	/* Get the boot CPU's MPIDR before MADT parsing */
> +	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> +

As Mark suggested better to move this prior to ACPI changes.

> +	err = acpi_parse_madt_gic_cpu_interface_entries();
> +

OK, so now you ignore if there was any FADT error if MADT is
successfully parsed ?

>   	return err;
>   }
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 40f38f4..8f1d37c 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -36,6 +36,7 @@
>   #include <linux/completion.h>
>   #include <linux/of.h>
>   #include <linux/irq_work.h>
> +#include <linux/acpi.h>
>
>   #include <asm/atomic.h>
>   #include <asm/cacheflush.h>
> @@ -458,7 +459,14 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>   		if (err)
>   			continue;
>
> -		set_cpu_present(cpu, true);
> +		/*
> +		 * In ACPI mode, cpu_present_map was initialised when
> +		 * MADT table was parsed which before this function
> +		 * is called.
> +		 */
> +		if (acpi_disabled)
> +			set_cpu_present(cpu, true);
> +

This is what I said above, it belongs here and we need to see how we do
that. I will give it a thought.

Regards,
Sudeep

Re: [PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> MADT contains the information for MPIDR which is essential for
> SMP initialization, parse the GIC cpu interface structures to
> get the MPIDR value and map it to cpu_logical_map(), and add
> enabled cpu with valid MPIDR into cpu_possible_map and
> cpu_present_map.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>   arch/arm64/include/asm/acpi.h |    2 +
>   arch/arm64/kernel/acpi.c      |  127 +++++++++++++++++++++++++++++++++++++++++
>   arch/arm64/kernel/smp.c       |   10 +++-
>   3 files changed, 138 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 67dac90..5ce85f8 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -50,6 +50,8 @@ static inline bool acpi_has_cpu_in_madt(void)
>   extern int (*acpi_suspend_lowlevel)(void);
>   #define acpi_wakeup_address 0
>
> +#define MAX_GIC_CPU_INTERFACE 65535
> +

Can this me made something like MAX_MADT_INTERRUPT_CONTROLLER_ENTRIES ?
And assuming each entry to be at-least 4 or 8 bytes, it can be reduced.

>   #endif /* CONFIG_ACPI */
>
>   #endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 374926f..801e268 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -22,6 +22,9 @@
>   #include <linux/bootmem.h>
>   #include <linux/smp.h>
>
> +#include <asm/smp_plat.h>
> +#include <asm/cputype.h>
> +
>   /*
>    * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>    * variable is still required by the ACPI core
> @@ -42,6 +45,9 @@ int acpi_psci_present;
>   /* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>   int acpi_psci_use_hvc;
>
> +/* Processors (GICC) with enabled flag in MADT */
> +static int enabled_cpus;
> +
>   /*
>    * __acpi_map_table() will be called before page_init(), so early_ioremap()
>    * or early_memremap() should be called here to for ACPI table mapping.
> @@ -62,6 +68,122 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>   	early_iounmap(map, size);
>   }
>
> +/**
> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
> + * generates a logic cpu number
> + * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
> + * @enabled: this cpu is enabled or not
> + *
> + * Returns the logic cpu number which maps to the gic cpu interface
> + */
> +static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)

Honestly this function doesn't deal anything with GIC cpu interface.

> +{
> +	int cpu;
> +
> +	if (mpidr == INVALID_HWID) {
> +		pr_info("Skip invalid cpu hardware ID\n");
> +		return -EINVAL;
> +	}
> +
> +	total_cpus++;
> +	if (!enabled)
> +		return -EINVAL;
> +
> +	if (enabled_cpus >=  NR_CPUS) {
> +		pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
> +			NR_CPUS, total_cpus, mpidr);
> +		return -EINVAL;
> +	}
> +
> +	/* If it is the first CPU, no need to check duplicate MPIDRs */
> +	if (!enabled_cpus)
> +		goto skip_mpidr_check;
> +
> +	/*
> +	 * Duplicate MPIDRs are a recipe for disaster. Scan
> +	 * all initialized entries and check for
> +	 * duplicates. If any is found just ignore the CPU.
> +	 */
> +	for_each_present_cpu(cpu) {
> +		if (cpu_logical_map(cpu) == mpidr) {
> +			pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
> +			       mpidr);
> +			return -EINVAL;
> +		}
> +	}
> +
> +skip_mpidr_check:
> +	enabled_cpus++;
> +
> +	/* allocate a logic cpu id for the new comer */
> +	if (cpu_logical_map(0) == mpidr) {
> +		/*
> +		 * boot_cpu_init() already hold bit 0 in cpu_present_mask
> +		 * for BSP, no need to allocte again.
> +		 */
> +		cpu = 0;
> +	} else {
> +		cpu = cpumask_next_zero(-1, cpu_present_mask);
> +	}
> +
> +	/* map the logic cpu id to cpu MPIDR */
> +	cpu_logical_map(cpu) = mpidr;
> +
> +	set_cpu_possible(cpu, true);
> +	set_cpu_present(cpu, true);
> +

I need to think more about this function and will comment later but I
think these cpumasks should be set only if SMP and probably belong to smp.c

> +	return cpu;
> +}
> +
> +static int __init
> +acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
> +				const unsigned long end)
> +{
> +	struct acpi_madt_generic_interrupt *processor;
> +
> +	processor = (struct acpi_madt_generic_interrupt *)header;
> +
> +	if (BAD_MADT_ENTRY(processor, end))
> +		return -EINVAL;
> +
> +	acpi_table_print_madt_entry(header);
> +
> +	acpi_register_gic_cpu_interface(processor->mpidr,
> +		processor->flags & ACPI_MADT_ENABLED);
> +
> +	return 0;
> +}
> +
> +/*
> + * Parse GIC cpu interface related entries in MADT
> + * returns 0 on success, < 0 on error
> + */
> +static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
> +{
> +	int count;
> +
> +	/*
> +	 * do a partial walk of MADT to determine how many CPUs
> +	 * we have including disabled CPUs, and get information
> +	 * we need for SMP init
> +	 */
> +	count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
> +			acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
> +
> +	if (!count) {
> +		pr_err("No GIC CPU interface entries present\n");
> +		return -ENODEV;
> +	} else if (count < 0) {
> +		pr_err("Error parsing GIC CPU interface entry\n");
> +		return count;
> +	}
> +
> +	/* Make boot-up look pretty */
> +	pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
> +
> +	return 0;
> +}
> +
>   static int __init acpi_parse_fadt(struct acpi_table_header *table)
>   {
>   	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> @@ -122,6 +244,11 @@ int __init acpi_boot_init(void)
>   	if (err)
>   		pr_err("Can't find FADT\n");
>
> +	/* Get the boot CPU's MPIDR before MADT parsing */
> +	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> +

As Mark suggested better to move this prior to ACPI changes.

> +	err = acpi_parse_madt_gic_cpu_interface_entries();
> +

OK, so now you ignore if there was any FADT error if MADT is
successfully parsed ?

>   	return err;
>   }
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 40f38f4..8f1d37c 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -36,6 +36,7 @@
>   #include <linux/completion.h>
>   #include <linux/of.h>
>   #include <linux/irq_work.h>
> +#include <linux/acpi.h>
>
>   #include <asm/atomic.h>
>   #include <asm/cacheflush.h>
> @@ -458,7 +459,14 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>   		if (err)
>   			continue;
>
> -		set_cpu_present(cpu, true);
> +		/*
> +		 * In ACPI mode, cpu_present_map was initialised when
> +		 * MADT table was parsed which before this function
> +		 * is called.
> +		 */
> +		if (acpi_disabled)
> +			set_cpu_present(cpu, true);
> +

This is what I said above, it belongs here and we need to see how we do
that. I will give it a thought.

Regards,
Sudeep

[PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> MADT contains the information for MPIDR which is essential for
> SMP initialization, parse the GIC cpu interface structures to
> get the MPIDR value and map it to cpu_logical_map(), and add
> enabled cpu with valid MPIDR into cpu_possible_map and
> cpu_present_map.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>   arch/arm64/include/asm/acpi.h |    2 +
>   arch/arm64/kernel/acpi.c      |  127 +++++++++++++++++++++++++++++++++++++++++
>   arch/arm64/kernel/smp.c       |   10 +++-
>   3 files changed, 138 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 67dac90..5ce85f8 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -50,6 +50,8 @@ static inline bool acpi_has_cpu_in_madt(void)
>   extern int (*acpi_suspend_lowlevel)(void);
>   #define acpi_wakeup_address 0
>
> +#define MAX_GIC_CPU_INTERFACE 65535
> +

Can this me made something like MAX_MADT_INTERRUPT_CONTROLLER_ENTRIES ?
And assuming each entry to be at-least 4 or 8 bytes, it can be reduced.

>   #endif /* CONFIG_ACPI */
>
>   #endif /*_ASM_ACPI_H*/
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index 374926f..801e268 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -22,6 +22,9 @@
>   #include <linux/bootmem.h>
>   #include <linux/smp.h>
>
> +#include <asm/smp_plat.h>
> +#include <asm/cputype.h>
> +
>   /*
>    * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>    * variable is still required by the ACPI core
> @@ -42,6 +45,9 @@ int acpi_psci_present;
>   /* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>   int acpi_psci_use_hvc;
>
> +/* Processors (GICC) with enabled flag in MADT */
> +static int enabled_cpus;
> +
>   /*
>    * __acpi_map_table() will be called before page_init(), so early_ioremap()
>    * or early_memremap() should be called here to for ACPI table mapping.
> @@ -62,6 +68,122 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>   	early_iounmap(map, size);
>   }
>
> +/**
> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
> + * generates a logic cpu number
> + * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
> + * @enabled: this cpu is enabled or not
> + *
> + * Returns the logic cpu number which maps to the gic cpu interface
> + */
> +static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)

Honestly this function doesn't deal anything with GIC cpu interface.

> +{
> +	int cpu;
> +
> +	if (mpidr == INVALID_HWID) {
> +		pr_info("Skip invalid cpu hardware ID\n");
> +		return -EINVAL;
> +	}
> +
> +	total_cpus++;
> +	if (!enabled)
> +		return -EINVAL;
> +
> +	if (enabled_cpus >=  NR_CPUS) {
> +		pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
> +			NR_CPUS, total_cpus, mpidr);
> +		return -EINVAL;
> +	}
> +
> +	/* If it is the first CPU, no need to check duplicate MPIDRs */
> +	if (!enabled_cpus)
> +		goto skip_mpidr_check;
> +
> +	/*
> +	 * Duplicate MPIDRs are a recipe for disaster. Scan
> +	 * all initialized entries and check for
> +	 * duplicates. If any is found just ignore the CPU.
> +	 */
> +	for_each_present_cpu(cpu) {
> +		if (cpu_logical_map(cpu) == mpidr) {
> +			pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
> +			       mpidr);
> +			return -EINVAL;
> +		}
> +	}
> +
> +skip_mpidr_check:
> +	enabled_cpus++;
> +
> +	/* allocate a logic cpu id for the new comer */
> +	if (cpu_logical_map(0) == mpidr) {
> +		/*
> +		 * boot_cpu_init() already hold bit 0 in cpu_present_mask
> +		 * for BSP, no need to allocte again.
> +		 */
> +		cpu = 0;
> +	} else {
> +		cpu = cpumask_next_zero(-1, cpu_present_mask);
> +	}
> +
> +	/* map the logic cpu id to cpu MPIDR */
> +	cpu_logical_map(cpu) = mpidr;
> +
> +	set_cpu_possible(cpu, true);
> +	set_cpu_present(cpu, true);
> +

I need to think more about this function and will comment later but I
think these cpumasks should be set only if SMP and probably belong to smp.c

> +	return cpu;
> +}
> +
> +static int __init
> +acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
> +				const unsigned long end)
> +{
> +	struct acpi_madt_generic_interrupt *processor;
> +
> +	processor = (struct acpi_madt_generic_interrupt *)header;
> +
> +	if (BAD_MADT_ENTRY(processor, end))
> +		return -EINVAL;
> +
> +	acpi_table_print_madt_entry(header);
> +
> +	acpi_register_gic_cpu_interface(processor->mpidr,
> +		processor->flags & ACPI_MADT_ENABLED);
> +
> +	return 0;
> +}
> +
> +/*
> + * Parse GIC cpu interface related entries in MADT
> + * returns 0 on success, < 0 on error
> + */
> +static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
> +{
> +	int count;
> +
> +	/*
> +	 * do a partial walk of MADT to determine how many CPUs
> +	 * we have including disabled CPUs, and get information
> +	 * we need for SMP init
> +	 */
> +	count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
> +			acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
> +
> +	if (!count) {
> +		pr_err("No GIC CPU interface entries present\n");
> +		return -ENODEV;
> +	} else if (count < 0) {
> +		pr_err("Error parsing GIC CPU interface entry\n");
> +		return count;
> +	}
> +
> +	/* Make boot-up look pretty */
> +	pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
> +
> +	return 0;
> +}
> +
>   static int __init acpi_parse_fadt(struct acpi_table_header *table)
>   {
>   	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> @@ -122,6 +244,11 @@ int __init acpi_boot_init(void)
>   	if (err)
>   		pr_err("Can't find FADT\n");
>
> +	/* Get the boot CPU's MPIDR before MADT parsing */
> +	cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
> +

As Mark suggested better to move this prior to ACPI changes.

> +	err = acpi_parse_madt_gic_cpu_interface_entries();
> +

OK, so now you ignore if there was any FADT error if MADT is
successfully parsed ?

>   	return err;
>   }
>
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 40f38f4..8f1d37c 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -36,6 +36,7 @@
>   #include <linux/completion.h>
>   #include <linux/of.h>
>   #include <linux/irq_work.h>
> +#include <linux/acpi.h>
>
>   #include <asm/atomic.h>
>   #include <asm/cacheflush.h>
> @@ -458,7 +459,14 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>   		if (err)
>   			continue;
>
> -		set_cpu_present(cpu, true);
> +		/*
> +		 * In ACPI mode, cpu_present_map was initialised when
> +		 * MADT table was parsed which before this function
> +		 * is called.
> +		 */
> +		if (acpi_disabled)
> +			set_cpu_present(cpu, true);
> +

This is what I said above, it belongs here and we need to see how we do
that. I will give it a thought.

Regards,
Sudeep

Re: [PATCH 08/19] ACPI / table: Print GIC information when MADT is parsed

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> When MADT is parsed, print GIC information to make the boot
> log look pretty.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>   drivers/acpi/tables.c |   39 ++++++++++++++++++++++++++++++++++++++-
>   1 file changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index 6d5a6cd..8bb8159 100644
> --- a/drivers/acpi/tables.c
> +++ b/drivers/acpi/tables.c
> @@ -183,6 +183,44 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header)
>   		}
>   		break;
>
> +	case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
> +		{
> +			struct acpi_madt_generic_interrupt *p =
> +				(struct acpi_madt_generic_interrupt *)header;
> +			pr_info("GICC (acpi_id[0x%04x] cpu_address[0x%08llx] MPDIR[0x%llx] %s)\n",

What exactly does cpu_address mean ? Better s/cpu_address/address

> +				p->uid, p->base_address, p->mpidr,
> +				(p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled");
> +
> +		}
> +		break;
> +
> +	case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
> +		{
> +			struct acpi_madt_generic_distributor *p =
> +				(struct acpi_madt_generic_distributor *)header;
> +			pr_info("GIC Distributor (id[0x%04x] address[0x%08llx] gsi_base[%d])\n",
> +				p->gic_id, p->base_address, p->global_irq_base);
> +		}
> +		break;
> +
> +	case ACPI_MADT_TYPE_GIC_MSI_FRAME:
> +		{
> +			struct acpi_madt_gic_msi_frame *p =
> +				(struct acpi_madt_gic_msi_frame *)header;
> +			pr_info("GIC MSI Frame (address[0x%08llx] msi_fame_id[%d])\n",
> +				p->base_address, p->gic_msi_frame_id);
> +		}
> +		break;
> +
> +	case ACPI_MADT_TYPE_GIC_REDISTRIBUTOR:
> +		{
> +			struct acpi_madt_gic_redistributor *p =
> +				(struct acpi_madt_gic_redistributor *)header;
> +			pr_info("GIC Redistributor (address[0x%08llx] region_size[0x%x])\n",
> +				p->base_address, p->region_size);
> +		}
> +		break;
> +

You may need to rework on the variable names when you rebase on ACPICA 
20140724

Regards,
Sudeep

Re: [PATCH 08/19] ACPI / table: Print GIC information when MADT is parsed

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> When MADT is parsed, print GIC information to make the boot
> log look pretty.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>   drivers/acpi/tables.c |   39 ++++++++++++++++++++++++++++++++++++++-
>   1 file changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index 6d5a6cd..8bb8159 100644
> --- a/drivers/acpi/tables.c
> +++ b/drivers/acpi/tables.c
> @@ -183,6 +183,44 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header)
>   		}
>   		break;
>
> +	case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
> +		{
> +			struct acpi_madt_generic_interrupt *p =
> +				(struct acpi_madt_generic_interrupt *)header;
> +			pr_info("GICC (acpi_id[0x%04x] cpu_address[0x%08llx] MPDIR[0x%llx] %s)\n",

What exactly does cpu_address mean ? Better s/cpu_address/address

> +				p->uid, p->base_address, p->mpidr,
> +				(p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled");
> +
> +		}
> +		break;
> +
> +	case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
> +		{
> +			struct acpi_madt_generic_distributor *p =
> +				(struct acpi_madt_generic_distributor *)header;
> +			pr_info("GIC Distributor (id[0x%04x] address[0x%08llx] gsi_base[%d])\n",
> +				p->gic_id, p->base_address, p->global_irq_base);
> +		}
> +		break;
> +
> +	case ACPI_MADT_TYPE_GIC_MSI_FRAME:
> +		{
> +			struct acpi_madt_gic_msi_frame *p =
> +				(struct acpi_madt_gic_msi_frame *)header;
> +			pr_info("GIC MSI Frame (address[0x%08llx] msi_fame_id[%d])\n",
> +				p->base_address, p->gic_msi_frame_id);
> +		}
> +		break;
> +
> +	case ACPI_MADT_TYPE_GIC_REDISTRIBUTOR:
> +		{
> +			struct acpi_madt_gic_redistributor *p =
> +				(struct acpi_madt_gic_redistributor *)header;
> +			pr_info("GIC Redistributor (address[0x%08llx] region_size[0x%x])\n",
> +				p->base_address, p->region_size);
> +		}
> +		break;
> +

You may need to rework on the variable names when you rebase on ACPICA 
20140724

Regards,
Sudeep

[PATCH 08/19] ACPI / table: Print GIC information when MADT is parsed

[Sudeep Holla]

On 24/07/14 14:00, Hanjun Guo wrote:
> When MADT is parsed, print GIC information to make the boot
> log look pretty.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>   drivers/acpi/tables.c |   39 ++++++++++++++++++++++++++++++++++++++-
>   1 file changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index 6d5a6cd..8bb8159 100644
> --- a/drivers/acpi/tables.c
> +++ b/drivers/acpi/tables.c
> @@ -183,6 +183,44 @@ void acpi_table_print_madt_entry(struct acpi_subtable_header *header)
>   		}
>   		break;
>
> +	case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
> +		{
> +			struct acpi_madt_generic_interrupt *p =
> +				(struct acpi_madt_generic_interrupt *)header;
> +			pr_info("GICC (acpi_id[0x%04x] cpu_address[0x%08llx] MPDIR[0x%llx] %s)\n",

What exactly does cpu_address mean ? Better s/cpu_address/address

> +				p->uid, p->base_address, p->mpidr,
> +				(p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled");
> +
> +		}
> +		break;
> +
> +	case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
> +		{
> +			struct acpi_madt_generic_distributor *p =
> +				(struct acpi_madt_generic_distributor *)header;
> +			pr_info("GIC Distributor (id[0x%04x] address[0x%08llx] gsi_base[%d])\n",
> +				p->gic_id, p->base_address, p->global_irq_base);
> +		}
> +		break;
> +
> +	case ACPI_MADT_TYPE_GIC_MSI_FRAME:
> +		{
> +			struct acpi_madt_gic_msi_frame *p =
> +				(struct acpi_madt_gic_msi_frame *)header;
> +			pr_info("GIC MSI Frame (address[0x%08llx] msi_fame_id[%d])\n",
> +				p->base_address, p->gic_msi_frame_id);
> +		}
> +		break;
> +
> +	case ACPI_MADT_TYPE_GIC_REDISTRIBUTOR:
> +		{
> +			struct acpi_madt_gic_redistributor *p =
> +				(struct acpi_madt_gic_redistributor *)header;
> +			pr_info("GIC Redistributor (address[0x%08llx] region_size[0x%x])\n",
> +				p->base_address, p->region_size);
> +		}
> +		break;
> +

You may need to rework on the variable names when you rebase on ACPICA 
20140724

Regards,
Sudeep

Re: [PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Hanjun Guo]

On 2014-7-30 0:40, Sudeep Holla wrote:
[...]
>>
>> +/* 1 to indicate PSCI is implemented */
>> +int acpi_psci_present;
>> +
>> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>> +int acpi_psci_use_hvc;
>> +
> 
> These can be boolean but can be removed IMO, see below.
> 
>>   /*
>>    * __acpi_map_table() will be called before page_init(), so early_ioremap()
>>    * or early_memremap() should be called here to for ACPI table mapping.
>> @@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>>       early_iounmap(map, size);
>>   }
>>
>> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
>> +{
>> +    struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> +
>> +    /*
>> +     * Revision in table header is the FADT Major version,
>> +     * and there is a minor version of FADT which was introduced
>> +     * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
>> +     * to get arm boot flags, or we will disable ACPI.
>> +     */
>> +    if (table->revision < 5 || fadt->minor_version < 1) {
>> +        pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or
>> higher\n",
>> +            table->revision, fadt->minor_version);
>> +        acpi_psci_present = 0;
>> +        disable_acpi();
>> +        return -EINVAL;
>> +    }
>> +
>> +    if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
>> +        acpi_psci_present = 1;
>> +
>> +    if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
>> +        acpi_psci_use_hvc = 1;
>> +
> 
> Why not make this macros instead of global variables as I suggested in
> previous version. acpi_gbl_FADT is already global and you can avoid
> creating new one especially they are just used on boot/init.

Ok, it makes sense to me, I will update it in next version.

Thanks
Hanjun

Re: [PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Hanjun Guo]

On 2014-7-30 0:40, Sudeep Holla wrote:
[...]
>>
>> +/* 1 to indicate PSCI is implemented */
>> +int acpi_psci_present;
>> +
>> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>> +int acpi_psci_use_hvc;
>> +
> 
> These can be boolean but can be removed IMO, see below.
> 
>>   /*
>>    * __acpi_map_table() will be called before page_init(), so early_ioremap()
>>    * or early_memremap() should be called here to for ACPI table mapping.
>> @@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>>       early_iounmap(map, size);
>>   }
>>
>> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
>> +{
>> +    struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> +
>> +    /*
>> +     * Revision in table header is the FADT Major version,
>> +     * and there is a minor version of FADT which was introduced
>> +     * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
>> +     * to get arm boot flags, or we will disable ACPI.
>> +     */
>> +    if (table->revision < 5 || fadt->minor_version < 1) {
>> +        pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or
>> higher\n",
>> +            table->revision, fadt->minor_version);
>> +        acpi_psci_present = 0;
>> +        disable_acpi();
>> +        return -EINVAL;
>> +    }
>> +
>> +    if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
>> +        acpi_psci_present = 1;
>> +
>> +    if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
>> +        acpi_psci_use_hvc = 1;
>> +
> 
> Why not make this macros instead of global variables as I suggested in
> previous version. acpi_gbl_FADT is already global and you can avoid
> creating new one especially they are just used on boot/init.

Ok, it makes sense to me, I will update it in next version.

Thanks
Hanjun

[PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Hanjun Guo]

On 2014-7-30 0:40, Sudeep Holla wrote:
[...]
>>
>> +/* 1 to indicate PSCI is implemented */
>> +int acpi_psci_present;
>> +
>> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>> +int acpi_psci_use_hvc;
>> +
> 
> These can be boolean but can be removed IMO, see below.
> 
>>   /*
>>    * __acpi_map_table() will be called before page_init(), so early_ioremap()
>>    * or early_memremap() should be called here to for ACPI table mapping.
>> @@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>>       early_iounmap(map, size);
>>   }
>>
>> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
>> +{
>> +    struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> +
>> +    /*
>> +     * Revision in table header is the FADT Major version,
>> +     * and there is a minor version of FADT which was introduced
>> +     * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
>> +     * to get arm boot flags, or we will disable ACPI.
>> +     */
>> +    if (table->revision < 5 || fadt->minor_version < 1) {
>> +        pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or
>> higher\n",
>> +            table->revision, fadt->minor_version);
>> +        acpi_psci_present = 0;
>> +        disable_acpi();
>> +        return -EINVAL;
>> +    }
>> +
>> +    if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
>> +        acpi_psci_present = 1;
>> +
>> +    if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
>> +        acpi_psci_use_hvc = 1;
>> +
> 
> Why not make this macros instead of global variables as I suggested in
> previous version. acpi_gbl_FADT is already global and you can avoid
> creating new one especially they are just used on boot/init.

Ok, it makes sense to me, I will update it in next version.

Thanks
Hanjun

Re: [PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Olof Johansson]

Hi,

On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> the former signals to the OS that the hardware is PSCI compliant.
> The latter selects the appropriate conduit for PSCI calls by
> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> (SMC).
>
> FADT table contains such information, parse FADT to get the flags
> for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
> function IDs, which means that only PSCI 0.2+ is supported in ACPI.
>
> At the same time, only ACPI 5.1 or higher verison supports PSCI,
> and FADT Major.Minor version was introduced in ACPI 5.1, so we
> will check the version and only parse FADT table with version >= 5.1.
>
> If firmware provides ACPI tables with ACPI version less than 5.1,
> OS will be messed up with those information and have no way to
> bring up secondery CPUs, so disable ACPI if we get an FADT table
> with version less that 5.1.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h |    2 +
>  arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
>  arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
>  arch/arm64/kernel/setup.c     |    2 +
>  4 files changed, 121 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 44b617f..67dac90 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -18,6 +18,8 @@ extern int acpi_disabled;
>  extern int acpi_noirq;
>  extern int acpi_pci_disabled;
>  extern int acpi_strict;
> +extern int acpi_psci_present;
> +extern int acpi_psci_use_hvc;
>
>  static inline void disable_acpi(void)
>  {
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index f5a10b5..374926f 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -11,6 +11,8 @@
>   *  published by the Free Software Foundation.
>   */
>
> +#define pr_fmt(fmt) "ACPI: " fmt
> +
>  #include <linux/init.h>
>  #include <linux/acpi.h>
>  #include <linux/cpumask.h>
> @@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
>  int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
>  EXPORT_SYMBOL(acpi_pci_disabled);
>
> +/* 1 to indicate PSCI is implemented */
> +int acpi_psci_present;
> +
> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> +int acpi_psci_use_hvc;

Here's a prime example of where it would just make more sense to
populate DT based on what's in the ACPI info.

Have a acpi_parse_fadt() that, if needed, creates a /psci node in the
system-wide DT and populates it with the few properties needed.

That way, the rest of the code path in the kernel setup is identical,
instead of dealing with separate functions for setup, two exported
variables just to communicate the state, and so on. It's just extra
complexity for no good reason. The ACPi side code isn't even adding
significant complexity compared to this. We'll need to add an
of_add_node() property though.

>  /*
>   * __acpi_map_table() will be called before page_init(), so early_ioremap()
>   * or early_memremap() should be called here to for ACPI table mapping.
> @@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>         early_iounmap(map, size);
>  }
>
> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> +{
> +       struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> +
> +       /*
> +        * Revision in table header is the FADT Major version,
> +        * and there is a minor version of FADT which was introduced
> +        * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
> +        * to get arm boot flags, or we will disable ACPI.
> +        */
> +       if (table->revision < 5 || fadt->minor_version < 1) {
> +               pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
> +                       table->revision, fadt->minor_version);
> +               acpi_psci_present = 0;
> +               disable_acpi();

This does more than just check for FADT/PSCI, it disables ACPI
alltogether. That kind of side effect from parse_fadt() doesn't seem
appropriate.

> +               return -EINVAL;
> +       }
> +
> +       if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
> +               acpi_psci_present = 1;
> +
> +       if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
> +               acpi_psci_use_hvc = 1;
> +
> +       return 0;
> +}
> +
>  /*
>   * acpi_boot_table_init() called from setup_arch(), always.
>   *     1. find RSDP and get its address, and then find XSDT
> @@ -75,6 +110,21 @@ void __init acpi_boot_table_init(void)
>         }
>  }
>
> +int __init acpi_boot_init(void)
> +{
> +       int err = 0;
> +
> +       /* If acpi_disabled, bail out */
> +       if (acpi_disabled)
> +               return -ENODEV;
> +
> +       err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
> +       if (err)
> +               pr_err("Can't find FADT\n");
> +
> +       return err;
> +}
> +
>  static int __init parse_acpi(char *arg)
>  {
>         if (!arg)
> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> index 9e9798f..adb25f3 100644
> --- a/arch/arm64/kernel/psci.c
> +++ b/arch/arm64/kernel/psci.c
> @@ -15,6 +15,7 @@
>
>  #define pr_fmt(fmt) "psci: " fmt
>
> +#include <linux/acpi.h>
>  #include <linux/init.h>
>  #include <linux/of.h>
>  #include <linux/smp.h>
> @@ -231,6 +232,33 @@ static void psci_sys_poweroff(void)
>         invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
>  }
>
> +static void psci_0_2_set_functions(void)
> +{
> +       pr_info("Using standard PSCI v0.2 function IDs\n");
> +       psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
> +       psci_ops.cpu_suspend = psci_cpu_suspend;
> +
> +       psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
> +       psci_ops.cpu_off = psci_cpu_off;
> +
> +       psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
> +       psci_ops.cpu_on = psci_cpu_on;
> +
> +       psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
> +       psci_ops.migrate = psci_migrate;
> +
> +       psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
> +       psci_ops.affinity_info = psci_affinity_info;
> +
> +       psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
> +               PSCI_0_2_FN_MIGRATE_INFO_TYPE;
> +       psci_ops.migrate_info_type = psci_migrate_info_type;
> +
> +       arm_pm_restart = psci_sys_reset;
> +
> +       pm_power_off = psci_sys_poweroff;
> +}
> +
>  /*
>   * PSCI Function IDs for v0.2+ are well defined so use
>   * standard values.
> @@ -264,29 +292,7 @@ static int psci_0_2_init(struct device_node *np)
>                 }
>         }
>
> -       pr_info("Using standard PSCI v0.2 function IDs\n");
> -       psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
> -       psci_ops.cpu_suspend = psci_cpu_suspend;
> -
> -       psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
> -       psci_ops.cpu_off = psci_cpu_off;
> -
> -       psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
> -       psci_ops.cpu_on = psci_cpu_on;
> -
> -       psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
> -       psci_ops.migrate = psci_migrate;
> -
> -       psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
> -       psci_ops.affinity_info = psci_affinity_info;
> -
> -       psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
> -               PSCI_0_2_FN_MIGRATE_INFO_TYPE;
> -       psci_ops.migrate_info_type = psci_migrate_info_type;
> -
> -       arm_pm_restart = psci_sys_reset;
> -
> -       pm_power_off = psci_sys_poweroff;
> +       psci_0_2_set_functions();
>
>  out_put_node:
>         of_node_put(np);
> @@ -333,6 +339,33 @@ out_put_node:
>         return err;
>  }
>
> +#ifdef CONFIG_ACPI
> +static int get_set_conduit_method_acpi(void)
> +{
> +       if (acpi_psci_use_hvc)
> +               invoke_psci_fn = __invoke_psci_fn_hvc;
> +       else
> +               invoke_psci_fn = __invoke_psci_fn_smc;
> +
> +       return 0;
> +}
> +
> +/* We use PSCI 0.2+ when ACPI is deployed */
> +static int psci_0_2_init_acpi(void)
> +{
> +       get_set_conduit_method_acpi();
> +
> +       psci_0_2_set_functions();

Here's a good example of the two code paths doing different things.
The DT code paths does a test call into PSCI to make sure it's
actually supported, while you blindly trust it. Keeping the code paths
common has value w.r.t these kind of things.

> +       return 0;
> +}
> +#else
> +static inline int psci_0_2_init_acpi(void)
> +{
> +       return -ENODEV;
> +}
> +#endif
> +
>  static const struct of_device_id psci_of_match[] __initconst = {
>         { .compatible = "arm,psci",     .data = psci_0_1_init},
>         { .compatible = "arm,psci-0.2", .data = psci_0_2_init},
> @@ -345,13 +378,19 @@ int __init psci_init(void)
>         const struct of_device_id *matched_np;
>         psci_initcall_t init_fn;
>
> -       np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> +       if (acpi_disabled) {
> +               np = of_find_matching_node_and_match(NULL,
> +                               psci_of_match, &matched_np);

Ideally this code should go away by changing the rest of it, but for
future cases: It'd be a lot cleaner to do this as:

        if (!acpi_disabled)
                return psci_0_2_init_acpi();

... then fall through to the current implementation instead.

But sharing the whole code path is even better, so let's do that.

>
> -       if (!np)
> -               return -ENODEV;
> +               if (!np)
> +                       return -ENODEV;
> +
> +               init_fn = (psci_initcall_t)matched_np->data;
> +
> +               return init_fn(np);
> +       }
>
> -       init_fn = (psci_initcall_t)matched_np->data;
> -       return init_fn(np);
> +       return psci_0_2_init_acpi();
>  }
>
>  #ifdef CONFIG_SMP
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 9dedb0b..e00d40c 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -394,6 +394,8 @@ void __init setup_arch(char **cmdline_p)
>
>         efi_idmap_init();
>
> +       acpi_boot_init();
> +
>         unflatten_device_tree();

The above two will need to be swapped when you move over to populating
the DT instead.

>
>         psci_init();


-Olof

[PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Olof Johansson]

Hi,

On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> the former signals to the OS that the hardware is PSCI compliant.
> The latter selects the appropriate conduit for PSCI calls by
> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> (SMC).
>
> FADT table contains such information, parse FADT to get the flags
> for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
> function IDs, which means that only PSCI 0.2+ is supported in ACPI.
>
> At the same time, only ACPI 5.1 or higher verison supports PSCI,
> and FADT Major.Minor version was introduced in ACPI 5.1, so we
> will check the version and only parse FADT table with version >= 5.1.
>
> If firmware provides ACPI tables with ACPI version less than 5.1,
> OS will be messed up with those information and have no way to
> bring up secondery CPUs, so disable ACPI if we get an FADT table
> with version less that 5.1.
>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h |    2 +
>  arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
>  arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
>  arch/arm64/kernel/setup.c     |    2 +
>  4 files changed, 121 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 44b617f..67dac90 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -18,6 +18,8 @@ extern int acpi_disabled;
>  extern int acpi_noirq;
>  extern int acpi_pci_disabled;
>  extern int acpi_strict;
> +extern int acpi_psci_present;
> +extern int acpi_psci_use_hvc;
>
>  static inline void disable_acpi(void)
>  {
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index f5a10b5..374926f 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -11,6 +11,8 @@
>   *  published by the Free Software Foundation.
>   */
>
> +#define pr_fmt(fmt) "ACPI: " fmt
> +
>  #include <linux/init.h>
>  #include <linux/acpi.h>
>  #include <linux/cpumask.h>
> @@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
>  int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
>  EXPORT_SYMBOL(acpi_pci_disabled);
>
> +/* 1 to indicate PSCI is implemented */
> +int acpi_psci_present;
> +
> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> +int acpi_psci_use_hvc;

Here's a prime example of where it would just make more sense to
populate DT based on what's in the ACPI info.

Have a acpi_parse_fadt() that, if needed, creates a /psci node in the
system-wide DT and populates it with the few properties needed.

That way, the rest of the code path in the kernel setup is identical,
instead of dealing with separate functions for setup, two exported
variables just to communicate the state, and so on. It's just extra
complexity for no good reason. The ACPi side code isn't even adding
significant complexity compared to this. We'll need to add an
of_add_node() property though.

>  /*
>   * __acpi_map_table() will be called before page_init(), so early_ioremap()
>   * or early_memremap() should be called here to for ACPI table mapping.
> @@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>         early_iounmap(map, size);
>  }
>
> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> +{
> +       struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> +
> +       /*
> +        * Revision in table header is the FADT Major version,
> +        * and there is a minor version of FADT which was introduced
> +        * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
> +        * to get arm boot flags, or we will disable ACPI.
> +        */
> +       if (table->revision < 5 || fadt->minor_version < 1) {
> +               pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
> +                       table->revision, fadt->minor_version);
> +               acpi_psci_present = 0;
> +               disable_acpi();

This does more than just check for FADT/PSCI, it disables ACPI
alltogether. That kind of side effect from parse_fadt() doesn't seem
appropriate.

> +               return -EINVAL;
> +       }
> +
> +       if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
> +               acpi_psci_present = 1;
> +
> +       if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
> +               acpi_psci_use_hvc = 1;
> +
> +       return 0;
> +}
> +
>  /*
>   * acpi_boot_table_init() called from setup_arch(), always.
>   *     1. find RSDP and get its address, and then find XSDT
> @@ -75,6 +110,21 @@ void __init acpi_boot_table_init(void)
>         }
>  }
>
> +int __init acpi_boot_init(void)
> +{
> +       int err = 0;
> +
> +       /* If acpi_disabled, bail out */
> +       if (acpi_disabled)
> +               return -ENODEV;
> +
> +       err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
> +       if (err)
> +               pr_err("Can't find FADT\n");
> +
> +       return err;
> +}
> +
>  static int __init parse_acpi(char *arg)
>  {
>         if (!arg)
> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> index 9e9798f..adb25f3 100644
> --- a/arch/arm64/kernel/psci.c
> +++ b/arch/arm64/kernel/psci.c
> @@ -15,6 +15,7 @@
>
>  #define pr_fmt(fmt) "psci: " fmt
>
> +#include <linux/acpi.h>
>  #include <linux/init.h>
>  #include <linux/of.h>
>  #include <linux/smp.h>
> @@ -231,6 +232,33 @@ static void psci_sys_poweroff(void)
>         invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
>  }
>
> +static void psci_0_2_set_functions(void)
> +{
> +       pr_info("Using standard PSCI v0.2 function IDs\n");
> +       psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
> +       psci_ops.cpu_suspend = psci_cpu_suspend;
> +
> +       psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
> +       psci_ops.cpu_off = psci_cpu_off;
> +
> +       psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
> +       psci_ops.cpu_on = psci_cpu_on;
> +
> +       psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
> +       psci_ops.migrate = psci_migrate;
> +
> +       psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
> +       psci_ops.affinity_info = psci_affinity_info;
> +
> +       psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
> +               PSCI_0_2_FN_MIGRATE_INFO_TYPE;
> +       psci_ops.migrate_info_type = psci_migrate_info_type;
> +
> +       arm_pm_restart = psci_sys_reset;
> +
> +       pm_power_off = psci_sys_poweroff;
> +}
> +
>  /*
>   * PSCI Function IDs for v0.2+ are well defined so use
>   * standard values.
> @@ -264,29 +292,7 @@ static int psci_0_2_init(struct device_node *np)
>                 }
>         }
>
> -       pr_info("Using standard PSCI v0.2 function IDs\n");
> -       psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
> -       psci_ops.cpu_suspend = psci_cpu_suspend;
> -
> -       psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
> -       psci_ops.cpu_off = psci_cpu_off;
> -
> -       psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
> -       psci_ops.cpu_on = psci_cpu_on;
> -
> -       psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
> -       psci_ops.migrate = psci_migrate;
> -
> -       psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
> -       psci_ops.affinity_info = psci_affinity_info;
> -
> -       psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
> -               PSCI_0_2_FN_MIGRATE_INFO_TYPE;
> -       psci_ops.migrate_info_type = psci_migrate_info_type;
> -
> -       arm_pm_restart = psci_sys_reset;
> -
> -       pm_power_off = psci_sys_poweroff;
> +       psci_0_2_set_functions();
>
>  out_put_node:
>         of_node_put(np);
> @@ -333,6 +339,33 @@ out_put_node:
>         return err;
>  }
>
> +#ifdef CONFIG_ACPI
> +static int get_set_conduit_method_acpi(void)
> +{
> +       if (acpi_psci_use_hvc)
> +               invoke_psci_fn = __invoke_psci_fn_hvc;
> +       else
> +               invoke_psci_fn = __invoke_psci_fn_smc;
> +
> +       return 0;
> +}
> +
> +/* We use PSCI 0.2+ when ACPI is deployed */
> +static int psci_0_2_init_acpi(void)
> +{
> +       get_set_conduit_method_acpi();
> +
> +       psci_0_2_set_functions();

Here's a good example of the two code paths doing different things.
The DT code paths does a test call into PSCI to make sure it's
actually supported, while you blindly trust it. Keeping the code paths
common has value w.r.t these kind of things.

> +       return 0;
> +}
> +#else
> +static inline int psci_0_2_init_acpi(void)
> +{
> +       return -ENODEV;
> +}
> +#endif
> +
>  static const struct of_device_id psci_of_match[] __initconst = {
>         { .compatible = "arm,psci",     .data = psci_0_1_init},
>         { .compatible = "arm,psci-0.2", .data = psci_0_2_init},
> @@ -345,13 +378,19 @@ int __init psci_init(void)
>         const struct of_device_id *matched_np;
>         psci_initcall_t init_fn;
>
> -       np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> +       if (acpi_disabled) {
> +               np = of_find_matching_node_and_match(NULL,
> +                               psci_of_match, &matched_np);

Ideally this code should go away by changing the rest of it, but for
future cases: It'd be a lot cleaner to do this as:

        if (!acpi_disabled)
                return psci_0_2_init_acpi();

... then fall through to the current implementation instead.

But sharing the whole code path is even better, so let's do that.

>
> -       if (!np)
> -               return -ENODEV;
> +               if (!np)
> +                       return -ENODEV;
> +
> +               init_fn = (psci_initcall_t)matched_np->data;
> +
> +               return init_fn(np);
> +       }
>
> -       init_fn = (psci_initcall_t)matched_np->data;
> -       return init_fn(np);
> +       return psci_0_2_init_acpi();
>  }
>
>  #ifdef CONFIG_SMP
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 9dedb0b..e00d40c 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -394,6 +394,8 @@ void __init setup_arch(char **cmdline_p)
>
>         efi_idmap_init();
>
> +       acpi_boot_init();
> +
>         unflatten_device_tree();

The above two will need to be swapped when you move over to populating
the DT instead.

>
>         psci_init();


-Olof

Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Olof Johansson]

Hi,

On Thu, Jul 24, 2014 at 09:00:16PM +0800, Hanjun Guo wrote:
> +/*
> + * In ACPI mode, the cpu possible map was enumerated before SMP
> + * initialization when MADT table was parsed, so we can get the
> + * possible map here to initialize CPUs.
> + */

The DT smp init will warn if the kernel has been build with too low NR_CPUS.
Does the ACPI core already warn, or did that go missing with this separate code
path?

> +static void __init acpi_smp_init_cpus(void)
> +{
> +	int cpu;
> +
> +	for_each_possible_cpu(cpu) {
> +		if (cpu_acpi_read_ops(cpu) != 0)
> +			continue;
> +
> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
> +	}
> +}
> +
> +void __init smp_init_cpus(void)
> +{
> +	if (acpi_disabled)
> +		of_smp_init_cpus();
> +	else
> +		acpi_smp_init_cpus();

I'm liking these deeply split code paths less and less every time I see
them. :(

I would prefer to set up shared state in separate functions, but keep the
control flow the same. Right now you're splitting it completely.

I.e. split data setup between the two, but do the loop calling cpu_init()
the same way. (Yes, that will require you to refactor the DT code path
a bit too...)


-Olof

Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Olof Johansson]

Hi,

On Thu, Jul 24, 2014 at 09:00:16PM +0800, Hanjun Guo wrote:
> +/*
> + * In ACPI mode, the cpu possible map was enumerated before SMP
> + * initialization when MADT table was parsed, so we can get the
> + * possible map here to initialize CPUs.
> + */

The DT smp init will warn if the kernel has been build with too low NR_CPUS.
Does the ACPI core already warn, or did that go missing with this separate code
path?

> +static void __init acpi_smp_init_cpus(void)
> +{
> +	int cpu;
> +
> +	for_each_possible_cpu(cpu) {
> +		if (cpu_acpi_read_ops(cpu) != 0)
> +			continue;
> +
> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
> +	}
> +}
> +
> +void __init smp_init_cpus(void)
> +{
> +	if (acpi_disabled)
> +		of_smp_init_cpus();
> +	else
> +		acpi_smp_init_cpus();

I'm liking these deeply split code paths less and less every time I see
them. :(

I would prefer to set up shared state in separate functions, but keep the
control flow the same. Right now you're splitting it completely.

I.e. split data setup between the two, but do the loop calling cpu_init()
the same way. (Yes, that will require you to refactor the DT code path
a bit too...)


-Olof

[PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Olof Johansson]

Hi,

On Thu, Jul 24, 2014 at 09:00:16PM +0800, Hanjun Guo wrote:
> +/*
> + * In ACPI mode, the cpu possible map was enumerated before SMP
> + * initialization when MADT table was parsed, so we can get the
> + * possible map here to initialize CPUs.
> + */

The DT smp init will warn if the kernel has been build with too low NR_CPUS.
Does the ACPI core already warn, or did that go missing with this separate code
path?

> +static void __init acpi_smp_init_cpus(void)
> +{
> +	int cpu;
> +
> +	for_each_possible_cpu(cpu) {
> +		if (cpu_acpi_read_ops(cpu) != 0)
> +			continue;
> +
> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
> +	}
> +}
> +
> +void __init smp_init_cpus(void)
> +{
> +	if (acpi_disabled)
> +		of_smp_init_cpus();
> +	else
> +		acpi_smp_init_cpus();

I'm liking these deeply split code paths less and less every time I see
them. :(

I would prefer to set up shared state in separate functions, but keep the
control flow the same. Right now you're splitting it completely.

I.e. split data setup between the two, but do the loop calling cpu_init()
the same way. (Yes, that will require you to refactor the DT code path
a bit too...)


-Olof

Re: [PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Hanjun Guo]

On 2014-7-31 2:20, Sudeep Holla wrote:
> 
> 
> On 24/07/14 14:00, Hanjun Guo wrote:
>> MADT contains the information for MPIDR which is essential for
>> SMP initialization, parse the GIC cpu interface structures to
>> get the MPIDR value and map it to cpu_logical_map(), and add
>> enabled cpu with valid MPIDR into cpu_possible_map and
>> cpu_present_map.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> ---
>>   arch/arm64/include/asm/acpi.h |    2 +
>>   arch/arm64/kernel/acpi.c      |  127 +++++++++++++++++++++++++++++++++++++++++
>>   arch/arm64/kernel/smp.c       |   10 +++-
>>   3 files changed, 138 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 67dac90..5ce85f8 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -50,6 +50,8 @@ static inline bool acpi_has_cpu_in_madt(void)
>>   extern int (*acpi_suspend_lowlevel)(void);
>>   #define acpi_wakeup_address 0
>>
>> +#define MAX_GIC_CPU_INTERFACE 65535
>> +
> 
> Can this me made something like MAX_MADT_INTERRUPT_CONTROLLER_ENTRIES ?

It is GIC CPU interface structure, I think we can keep the name as it
is or as ACPI_GIC_MAX_CPU_INTERFACE which modified in later patches.

> And assuming each entry to be at-least 4 or 8 bytes, it can be reduced.

Sorry, I didn't catch up with you here, can you explain it?

> 
>>   #endif /* CONFIG_ACPI */
>>
>>   #endif /*_ASM_ACPI_H*/
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index 374926f..801e268 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -22,6 +22,9 @@
>>   #include <linux/bootmem.h>
>>   #include <linux/smp.h>
>>
>> +#include <asm/smp_plat.h>
>> +#include <asm/cputype.h>
>> +
>>   /*
>>    * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>>    * variable is still required by the ACPI core
>> @@ -42,6 +45,9 @@ int acpi_psci_present;
>>   /* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>>   int acpi_psci_use_hvc;
>>
>> +/* Processors (GICC) with enabled flag in MADT */
>> +static int enabled_cpus;
>> +
>>   /*
>>    * __acpi_map_table() will be called before page_init(), so early_ioremap()
>>    * or early_memremap() should be called here to for ACPI table mapping.
>> @@ -62,6 +68,122 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>>       early_iounmap(map, size);
>>   }
>>
>> +/**
>> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
>> + * generates a logic cpu number
>> + * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
>> + * @enabled: this cpu is enabled or not
>> + *
>> + * Returns the logic cpu number which maps to the gic cpu interface
>> + */
>> +static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)
> 
> Honestly this function doesn't deal anything with GIC cpu interface.

Yes, but every GIC cpu interface structure represents a CPU in the
system, it is about the SMP init.

> 
>> +{
>> +    int cpu;
>> +
>> +    if (mpidr == INVALID_HWID) {
>> +        pr_info("Skip invalid cpu hardware ID\n");
>> +        return -EINVAL;
>> +    }
>> +
>> +    total_cpus++;
>> +    if (!enabled)
>> +        return -EINVAL;
>> +
>> +    if (enabled_cpus >=  NR_CPUS) {
>> +        pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
>> +            NR_CPUS, total_cpus, mpidr);
>> +        return -EINVAL;
>> +    }
>> +
>> +    /* If it is the first CPU, no need to check duplicate MPIDRs */
>> +    if (!enabled_cpus)
>> +        goto skip_mpidr_check;
>> +
>> +    /*
>> +     * Duplicate MPIDRs are a recipe for disaster. Scan
>> +     * all initialized entries and check for
>> +     * duplicates. If any is found just ignore the CPU.
>> +     */
>> +    for_each_present_cpu(cpu) {
>> +        if (cpu_logical_map(cpu) == mpidr) {
>> +            pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
>> +                   mpidr);
>> +            return -EINVAL;
>> +        }
>> +    }
>> +
>> +skip_mpidr_check:
>> +    enabled_cpus++;
>> +
>> +    /* allocate a logic cpu id for the new comer */
>> +    if (cpu_logical_map(0) == mpidr) {
>> +        /*
>> +         * boot_cpu_init() already hold bit 0 in cpu_present_mask
>> +         * for BSP, no need to allocte again.
>> +         */
>> +        cpu = 0;
>> +    } else {
>> +        cpu = cpumask_next_zero(-1, cpu_present_mask);
>> +    }
>> +
>> +    /* map the logic cpu id to cpu MPIDR */
>> +    cpu_logical_map(cpu) = mpidr;
>> +
>> +    set_cpu_possible(cpu, true);
>> +    set_cpu_present(cpu, true);
>> +
> 
> I need to think more about this function and will comment later but I
> think these cpumasks should be set only if SMP and probably belong to smp.c

No, I don't think so, it is because of the CPU hot add.

Considering a CPU will be added at run-time (you may fine out this function
without __init), it will go through the ACPI routing and call this function
to map its MPIDR to cpu logical num and then call cpu_up() to online it,
so if you move these cpumasks to __init functions in smp.c, new CPUs added
at run-time will never be set for there possible and present mask.

> 
>> +    return cpu;
>> +}
>> +
>> +static int __init
>> +acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
>> +                const unsigned long end)
>> +{
>> +    struct acpi_madt_generic_interrupt *processor;
>> +
>> +    processor = (struct acpi_madt_generic_interrupt *)header;
>> +
>> +    if (BAD_MADT_ENTRY(processor, end))
>> +        return -EINVAL;
>> +
>> +    acpi_table_print_madt_entry(header);
>> +
>> +    acpi_register_gic_cpu_interface(processor->mpidr,
>> +        processor->flags & ACPI_MADT_ENABLED);
>> +
>> +    return 0;
>> +}
>> +
>> +/*
>> + * Parse GIC cpu interface related entries in MADT
>> + * returns 0 on success, < 0 on error
>> + */
>> +static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
>> +{
>> +    int count;
>> +
>> +    /*
>> +     * do a partial walk of MADT to determine how many CPUs
>> +     * we have including disabled CPUs, and get information
>> +     * we need for SMP init
>> +     */
>> +    count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
>> +            acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
>> +
>> +    if (!count) {
>> +        pr_err("No GIC CPU interface entries present\n");
>> +        return -ENODEV;
>> +    } else if (count < 0) {
>> +        pr_err("Error parsing GIC CPU interface entry\n");
>> +        return count;
>> +    }
>> +
>> +    /* Make boot-up look pretty */
>> +    pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
>> +
>> +    return 0;
>> +}
>> +
>>   static int __init acpi_parse_fadt(struct acpi_table_header *table)
>>   {
>>       struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> @@ -122,6 +244,11 @@ int __init acpi_boot_init(void)
>>       if (err)
>>           pr_err("Can't find FADT\n");
>>
>> +    /* Get the boot CPU's MPIDR before MADT parsing */
>> +    cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>> +
> 
> As Mark suggested better to move this prior to ACPI changes.

I will.

> 
>> +    err = acpi_parse_madt_gic_cpu_interface_entries();
>> +
> 
> OK, so now you ignore if there was any FADT error if MADT is
> successfully parsed ?

My original intention is that we can continue the MADT table
parsing even if we meet some error when parsing FADT, just
as x86 did. But now ACPI is disabled when FADT version is not
correct, so I think we need check here as you said.

> 
>>       return err;
>>   }
>>
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index 40f38f4..8f1d37c 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -36,6 +36,7 @@
>>   #include <linux/completion.h>
>>   #include <linux/of.h>
>>   #include <linux/irq_work.h>
>> +#include <linux/acpi.h>
>>
>>   #include <asm/atomic.h>
>>   #include <asm/cacheflush.h>
>> @@ -458,7 +459,14 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>>           if (err)
>>               continue;
>>
>> -        set_cpu_present(cpu, true);
>> +        /*
>> +         * In ACPI mode, cpu_present_map was initialised when
>> +         * MADT table was parsed which before this function
>> +         * is called.
>> +         */
>> +        if (acpi_disabled)
>> +            set_cpu_present(cpu, true);
>> +
> 
> This is what I said above, it belongs here and we need to see how we do
> that. I will give it a thought.

Please refer to the comments above.

Thanks
Hanjun

Re: [PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Hanjun Guo]

On 2014-7-31 2:20, Sudeep Holla wrote:
> 
> 
> On 24/07/14 14:00, Hanjun Guo wrote:
>> MADT contains the information for MPIDR which is essential for
>> SMP initialization, parse the GIC cpu interface structures to
>> get the MPIDR value and map it to cpu_logical_map(), and add
>> enabled cpu with valid MPIDR into cpu_possible_map and
>> cpu_present_map.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> ---
>>   arch/arm64/include/asm/acpi.h |    2 +
>>   arch/arm64/kernel/acpi.c      |  127 +++++++++++++++++++++++++++++++++++++++++
>>   arch/arm64/kernel/smp.c       |   10 +++-
>>   3 files changed, 138 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 67dac90..5ce85f8 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -50,6 +50,8 @@ static inline bool acpi_has_cpu_in_madt(void)
>>   extern int (*acpi_suspend_lowlevel)(void);
>>   #define acpi_wakeup_address 0
>>
>> +#define MAX_GIC_CPU_INTERFACE 65535
>> +
> 
> Can this me made something like MAX_MADT_INTERRUPT_CONTROLLER_ENTRIES ?

It is GIC CPU interface structure, I think we can keep the name as it
is or as ACPI_GIC_MAX_CPU_INTERFACE which modified in later patches.

> And assuming each entry to be at-least 4 or 8 bytes, it can be reduced.

Sorry, I didn't catch up with you here, can you explain it?

> 
>>   #endif /* CONFIG_ACPI */
>>
>>   #endif /*_ASM_ACPI_H*/
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index 374926f..801e268 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -22,6 +22,9 @@
>>   #include <linux/bootmem.h>
>>   #include <linux/smp.h>
>>
>> +#include <asm/smp_plat.h>
>> +#include <asm/cputype.h>
>> +
>>   /*
>>    * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>>    * variable is still required by the ACPI core
>> @@ -42,6 +45,9 @@ int acpi_psci_present;
>>   /* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>>   int acpi_psci_use_hvc;
>>
>> +/* Processors (GICC) with enabled flag in MADT */
>> +static int enabled_cpus;
>> +
>>   /*
>>    * __acpi_map_table() will be called before page_init(), so early_ioremap()
>>    * or early_memremap() should be called here to for ACPI table mapping.
>> @@ -62,6 +68,122 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>>       early_iounmap(map, size);
>>   }
>>
>> +/**
>> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
>> + * generates a logic cpu number
>> + * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
>> + * @enabled: this cpu is enabled or not
>> + *
>> + * Returns the logic cpu number which maps to the gic cpu interface
>> + */
>> +static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)
> 
> Honestly this function doesn't deal anything with GIC cpu interface.

Yes, but every GIC cpu interface structure represents a CPU in the
system, it is about the SMP init.

> 
>> +{
>> +    int cpu;
>> +
>> +    if (mpidr == INVALID_HWID) {
>> +        pr_info("Skip invalid cpu hardware ID\n");
>> +        return -EINVAL;
>> +    }
>> +
>> +    total_cpus++;
>> +    if (!enabled)
>> +        return -EINVAL;
>> +
>> +    if (enabled_cpus >=  NR_CPUS) {
>> +        pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
>> +            NR_CPUS, total_cpus, mpidr);
>> +        return -EINVAL;
>> +    }
>> +
>> +    /* If it is the first CPU, no need to check duplicate MPIDRs */
>> +    if (!enabled_cpus)
>> +        goto skip_mpidr_check;
>> +
>> +    /*
>> +     * Duplicate MPIDRs are a recipe for disaster. Scan
>> +     * all initialized entries and check for
>> +     * duplicates. If any is found just ignore the CPU.
>> +     */
>> +    for_each_present_cpu(cpu) {
>> +        if (cpu_logical_map(cpu) == mpidr) {
>> +            pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
>> +                   mpidr);
>> +            return -EINVAL;
>> +        }
>> +    }
>> +
>> +skip_mpidr_check:
>> +    enabled_cpus++;
>> +
>> +    /* allocate a logic cpu id for the new comer */
>> +    if (cpu_logical_map(0) == mpidr) {
>> +        /*
>> +         * boot_cpu_init() already hold bit 0 in cpu_present_mask
>> +         * for BSP, no need to allocte again.
>> +         */
>> +        cpu = 0;
>> +    } else {
>> +        cpu = cpumask_next_zero(-1, cpu_present_mask);
>> +    }
>> +
>> +    /* map the logic cpu id to cpu MPIDR */
>> +    cpu_logical_map(cpu) = mpidr;
>> +
>> +    set_cpu_possible(cpu, true);
>> +    set_cpu_present(cpu, true);
>> +
> 
> I need to think more about this function and will comment later but I
> think these cpumasks should be set only if SMP and probably belong to smp.c

No, I don't think so, it is because of the CPU hot add.

Considering a CPU will be added at run-time (you may fine out this function
without __init), it will go through the ACPI routing and call this function
to map its MPIDR to cpu logical num and then call cpu_up() to online it,
so if you move these cpumasks to __init functions in smp.c, new CPUs added
at run-time will never be set for there possible and present mask.

> 
>> +    return cpu;
>> +}
>> +
>> +static int __init
>> +acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
>> +                const unsigned long end)
>> +{
>> +    struct acpi_madt_generic_interrupt *processor;
>> +
>> +    processor = (struct acpi_madt_generic_interrupt *)header;
>> +
>> +    if (BAD_MADT_ENTRY(processor, end))
>> +        return -EINVAL;
>> +
>> +    acpi_table_print_madt_entry(header);
>> +
>> +    acpi_register_gic_cpu_interface(processor->mpidr,
>> +        processor->flags & ACPI_MADT_ENABLED);
>> +
>> +    return 0;
>> +}
>> +
>> +/*
>> + * Parse GIC cpu interface related entries in MADT
>> + * returns 0 on success, < 0 on error
>> + */
>> +static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
>> +{
>> +    int count;
>> +
>> +    /*
>> +     * do a partial walk of MADT to determine how many CPUs
>> +     * we have including disabled CPUs, and get information
>> +     * we need for SMP init
>> +     */
>> +    count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
>> +            acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
>> +
>> +    if (!count) {
>> +        pr_err("No GIC CPU interface entries present\n");
>> +        return -ENODEV;
>> +    } else if (count < 0) {
>> +        pr_err("Error parsing GIC CPU interface entry\n");
>> +        return count;
>> +    }
>> +
>> +    /* Make boot-up look pretty */
>> +    pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
>> +
>> +    return 0;
>> +}
>> +
>>   static int __init acpi_parse_fadt(struct acpi_table_header *table)
>>   {
>>       struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> @@ -122,6 +244,11 @@ int __init acpi_boot_init(void)
>>       if (err)
>>           pr_err("Can't find FADT\n");
>>
>> +    /* Get the boot CPU's MPIDR before MADT parsing */
>> +    cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>> +
> 
> As Mark suggested better to move this prior to ACPI changes.

I will.

> 
>> +    err = acpi_parse_madt_gic_cpu_interface_entries();
>> +
> 
> OK, so now you ignore if there was any FADT error if MADT is
> successfully parsed ?

My original intention is that we can continue the MADT table
parsing even if we meet some error when parsing FADT, just
as x86 did. But now ACPI is disabled when FADT version is not
correct, so I think we need check here as you said.

> 
>>       return err;
>>   }
>>
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index 40f38f4..8f1d37c 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -36,6 +36,7 @@
>>   #include <linux/completion.h>
>>   #include <linux/of.h>
>>   #include <linux/irq_work.h>
>> +#include <linux/acpi.h>
>>
>>   #include <asm/atomic.h>
>>   #include <asm/cacheflush.h>
>> @@ -458,7 +459,14 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>>           if (err)
>>               continue;
>>
>> -        set_cpu_present(cpu, true);
>> +        /*
>> +         * In ACPI mode, cpu_present_map was initialised when
>> +         * MADT table was parsed which before this function
>> +         * is called.
>> +         */
>> +        if (acpi_disabled)
>> +            set_cpu_present(cpu, true);
>> +
> 
> This is what I said above, it belongs here and we need to see how we do
> that. I will give it a thought.

Please refer to the comments above.

Thanks
Hanjun

[PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Hanjun Guo]

On 2014-7-31 2:20, Sudeep Holla wrote:
> 
> 
> On 24/07/14 14:00, Hanjun Guo wrote:
>> MADT contains the information for MPIDR which is essential for
>> SMP initialization, parse the GIC cpu interface structures to
>> get the MPIDR value and map it to cpu_logical_map(), and add
>> enabled cpu with valid MPIDR into cpu_possible_map and
>> cpu_present_map.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> ---
>>   arch/arm64/include/asm/acpi.h |    2 +
>>   arch/arm64/kernel/acpi.c      |  127 +++++++++++++++++++++++++++++++++++++++++
>>   arch/arm64/kernel/smp.c       |   10 +++-
>>   3 files changed, 138 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 67dac90..5ce85f8 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -50,6 +50,8 @@ static inline bool acpi_has_cpu_in_madt(void)
>>   extern int (*acpi_suspend_lowlevel)(void);
>>   #define acpi_wakeup_address 0
>>
>> +#define MAX_GIC_CPU_INTERFACE 65535
>> +
> 
> Can this me made something like MAX_MADT_INTERRUPT_CONTROLLER_ENTRIES ?

It is GIC CPU interface structure, I think we can keep the name as it
is or as ACPI_GIC_MAX_CPU_INTERFACE which modified in later patches.

> And assuming each entry to be at-least 4 or 8 bytes, it can be reduced.

Sorry, I didn't catch up with you here, can you explain it?

> 
>>   #endif /* CONFIG_ACPI */
>>
>>   #endif /*_ASM_ACPI_H*/
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index 374926f..801e268 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -22,6 +22,9 @@
>>   #include <linux/bootmem.h>
>>   #include <linux/smp.h>
>>
>> +#include <asm/smp_plat.h>
>> +#include <asm/cputype.h>
>> +
>>   /*
>>    * We never plan to use RSDT on arm/arm64 as its deprecated in spec but this
>>    * variable is still required by the ACPI core
>> @@ -42,6 +45,9 @@ int acpi_psci_present;
>>   /* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>>   int acpi_psci_use_hvc;
>>
>> +/* Processors (GICC) with enabled flag in MADT */
>> +static int enabled_cpus;
>> +
>>   /*
>>    * __acpi_map_table() will be called before page_init(), so early_ioremap()
>>    * or early_memremap() should be called here to for ACPI table mapping.
>> @@ -62,6 +68,122 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>>       early_iounmap(map, size);
>>   }
>>
>> +/**
>> + * acpi_register_gic_cpu_interface - register a gic cpu interface and
>> + * generates a logic cpu number
>> + * @mpidr: CPU's hardware id to register, MPIDR represented in MADT
>> + * @enabled: this cpu is enabled or not
>> + *
>> + * Returns the logic cpu number which maps to the gic cpu interface
>> + */
>> +static int acpi_register_gic_cpu_interface(u64 mpidr, u8 enabled)
> 
> Honestly this function doesn't deal anything with GIC cpu interface.

Yes, but every GIC cpu interface structure represents a CPU in the
system, it is about the SMP init.

> 
>> +{
>> +    int cpu;
>> +
>> +    if (mpidr == INVALID_HWID) {
>> +        pr_info("Skip invalid cpu hardware ID\n");
>> +        return -EINVAL;
>> +    }
>> +
>> +    total_cpus++;
>> +    if (!enabled)
>> +        return -EINVAL;
>> +
>> +    if (enabled_cpus >=  NR_CPUS) {
>> +        pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
>> +            NR_CPUS, total_cpus, mpidr);
>> +        return -EINVAL;
>> +    }
>> +
>> +    /* If it is the first CPU, no need to check duplicate MPIDRs */
>> +    if (!enabled_cpus)
>> +        goto skip_mpidr_check;
>> +
>> +    /*
>> +     * Duplicate MPIDRs are a recipe for disaster. Scan
>> +     * all initialized entries and check for
>> +     * duplicates. If any is found just ignore the CPU.
>> +     */
>> +    for_each_present_cpu(cpu) {
>> +        if (cpu_logical_map(cpu) == mpidr) {
>> +            pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
>> +                   mpidr);
>> +            return -EINVAL;
>> +        }
>> +    }
>> +
>> +skip_mpidr_check:
>> +    enabled_cpus++;
>> +
>> +    /* allocate a logic cpu id for the new comer */
>> +    if (cpu_logical_map(0) == mpidr) {
>> +        /*
>> +         * boot_cpu_init() already hold bit 0 in cpu_present_mask
>> +         * for BSP, no need to allocte again.
>> +         */
>> +        cpu = 0;
>> +    } else {
>> +        cpu = cpumask_next_zero(-1, cpu_present_mask);
>> +    }
>> +
>> +    /* map the logic cpu id to cpu MPIDR */
>> +    cpu_logical_map(cpu) = mpidr;
>> +
>> +    set_cpu_possible(cpu, true);
>> +    set_cpu_present(cpu, true);
>> +
> 
> I need to think more about this function and will comment later but I
> think these cpumasks should be set only if SMP and probably belong to smp.c

No, I don't think so, it is because of the CPU hot add.

Considering a CPU will be added at run-time (you may fine out this function
without __init), it will go through the ACPI routing and call this function
to map its MPIDR to cpu logical num and then call cpu_up() to online it,
so if you move these cpumasks to __init functions in smp.c, new CPUs added
at run-time will never be set for there possible and present mask.

> 
>> +    return cpu;
>> +}
>> +
>> +static int __init
>> +acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
>> +                const unsigned long end)
>> +{
>> +    struct acpi_madt_generic_interrupt *processor;
>> +
>> +    processor = (struct acpi_madt_generic_interrupt *)header;
>> +
>> +    if (BAD_MADT_ENTRY(processor, end))
>> +        return -EINVAL;
>> +
>> +    acpi_table_print_madt_entry(header);
>> +
>> +    acpi_register_gic_cpu_interface(processor->mpidr,
>> +        processor->flags & ACPI_MADT_ENABLED);
>> +
>> +    return 0;
>> +}
>> +
>> +/*
>> + * Parse GIC cpu interface related entries in MADT
>> + * returns 0 on success, < 0 on error
>> + */
>> +static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
>> +{
>> +    int count;
>> +
>> +    /*
>> +     * do a partial walk of MADT to determine how many CPUs
>> +     * we have including disabled CPUs, and get information
>> +     * we need for SMP init
>> +     */
>> +    count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
>> +            acpi_parse_gic_cpu_interface, MAX_GIC_CPU_INTERFACE);
>> +
>> +    if (!count) {
>> +        pr_err("No GIC CPU interface entries present\n");
>> +        return -ENODEV;
>> +    } else if (count < 0) {
>> +        pr_err("Error parsing GIC CPU interface entry\n");
>> +        return count;
>> +    }
>> +
>> +    /* Make boot-up look pretty */
>> +    pr_info("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
>> +
>> +    return 0;
>> +}
>> +
>>   static int __init acpi_parse_fadt(struct acpi_table_header *table)
>>   {
>>       struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> @@ -122,6 +244,11 @@ int __init acpi_boot_init(void)
>>       if (err)
>>           pr_err("Can't find FADT\n");
>>
>> +    /* Get the boot CPU's MPIDR before MADT parsing */
>> +    cpu_logical_map(0) = read_cpuid_mpidr() & MPIDR_HWID_BITMASK;
>> +
> 
> As Mark suggested better to move this prior to ACPI changes.

I will.

> 
>> +    err = acpi_parse_madt_gic_cpu_interface_entries();
>> +
> 
> OK, so now you ignore if there was any FADT error if MADT is
> successfully parsed ?

My original intention is that we can continue the MADT table
parsing even if we meet some error when parsing FADT, just
as x86 did. But now ACPI is disabled when FADT version is not
correct, so I think we need check here as you said.

> 
>>       return err;
>>   }
>>
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index 40f38f4..8f1d37c 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -36,6 +36,7 @@
>>   #include <linux/completion.h>
>>   #include <linux/of.h>
>>   #include <linux/irq_work.h>
>> +#include <linux/acpi.h>
>>
>>   #include <asm/atomic.h>
>>   #include <asm/cacheflush.h>
>> @@ -458,7 +459,14 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
>>           if (err)
>>               continue;
>>
>> -        set_cpu_present(cpu, true);
>> +        /*
>> +         * In ACPI mode, cpu_present_map was initialised when
>> +         * MADT table was parsed which before this function
>> +         * is called.
>> +         */
>> +        if (acpi_disabled)
>> +            set_cpu_present(cpu, true);
>> +
> 
> This is what I said above, it belongs here and we need to see how we do
> that. I will give it a thought.

Please refer to the comments above.

Thanks
Hanjun

Re: [PATCH 08/19] ACPI / table: Print GIC information when MADT is parsed

[Hanjun Guo]

On 2014-7-31 2:21, Sudeep Holla wrote:
> On 24/07/14 14:00, Hanjun Guo wrote:
>> When MADT is parsed, print GIC information to make the boot
>> log look pretty.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> ---
>>   drivers/acpi/tables.c |   39 ++++++++++++++++++++++++++++++++++++++-
>>   1 file changed, 38 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
>> index 6d5a6cd..8bb8159 100644
>> --- a/drivers/acpi/tables.c
>> +++ b/drivers/acpi/tables.c
>> @@ -183,6 +183,44 @@ void acpi_table_print_madt_entry(struct
>> acpi_subtable_header *header)
>>           }
>>           break;
>>
>> +    case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
>> +        {
>> +            struct acpi_madt_generic_interrupt *p =
>> +                (struct acpi_madt_generic_interrupt *)header;
>> +            pr_info("GICC (acpi_id[0x%04x] cpu_address[0x%08llx]
>> MPDIR[0x%llx] %s)\n",
> 
> What exactly does cpu_address mean ? Better s/cpu_address/address

Agreed.

> 
>> +                p->uid, p->base_address, p->mpidr,
>> +                (p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled");
>> +
>> +        }
>> +        break;
>> +
>> +    case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
>> +        {
>> +            struct acpi_madt_generic_distributor *p =
>> +                (struct acpi_madt_generic_distributor *)header;
>> +            pr_info("GIC Distributor (id[0x%04x] address[0x%08llx]
>> gsi_base[%d])\n",
>> +                p->gic_id, p->base_address, p->global_irq_base);
>> +        }
>> +        break;
>> +
>> +    case ACPI_MADT_TYPE_GIC_MSI_FRAME:
>> +        {
>> +            struct acpi_madt_gic_msi_frame *p =
>> +                (struct acpi_madt_gic_msi_frame *)header;
>> +            pr_info("GIC MSI Frame (address[0x%08llx] msi_fame_id[%d])\n",
>> +                p->base_address, p->gic_msi_frame_id);
>> +        }
>> +        break;
>> +
>> +    case ACPI_MADT_TYPE_GIC_REDISTRIBUTOR:
>> +        {
>> +            struct acpi_madt_gic_redistributor *p =
>> +                (struct acpi_madt_gic_redistributor *)header;
>> +            pr_info("GIC Redistributor (address[0x%08llx] region_size[0x%x])\n",
>> +                p->base_address, p->region_size);
>> +        }
>> +        break;
>> +
> 
> You may need to rework on the variable names when you rebase on ACPICA 20140724

Yes, I'm working on it :)

Thanks
Hanjun

Re: [PATCH 08/19] ACPI / table: Print GIC information when MADT is parsed

[Hanjun Guo]

On 2014-7-31 2:21, Sudeep Holla wrote:
> On 24/07/14 14:00, Hanjun Guo wrote:
>> When MADT is parsed, print GIC information to make the boot
>> log look pretty.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> ---
>>   drivers/acpi/tables.c |   39 ++++++++++++++++++++++++++++++++++++++-
>>   1 file changed, 38 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
>> index 6d5a6cd..8bb8159 100644
>> --- a/drivers/acpi/tables.c
>> +++ b/drivers/acpi/tables.c
>> @@ -183,6 +183,44 @@ void acpi_table_print_madt_entry(struct
>> acpi_subtable_header *header)
>>           }
>>           break;
>>
>> +    case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
>> +        {
>> +            struct acpi_madt_generic_interrupt *p =
>> +                (struct acpi_madt_generic_interrupt *)header;
>> +            pr_info("GICC (acpi_id[0x%04x] cpu_address[0x%08llx]
>> MPDIR[0x%llx] %s)\n",
> 
> What exactly does cpu_address mean ? Better s/cpu_address/address

Agreed.

> 
>> +                p->uid, p->base_address, p->mpidr,
>> +                (p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled");
>> +
>> +        }
>> +        break;
>> +
>> +    case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
>> +        {
>> +            struct acpi_madt_generic_distributor *p =
>> +                (struct acpi_madt_generic_distributor *)header;
>> +            pr_info("GIC Distributor (id[0x%04x] address[0x%08llx]
>> gsi_base[%d])\n",
>> +                p->gic_id, p->base_address, p->global_irq_base);
>> +        }
>> +        break;
>> +
>> +    case ACPI_MADT_TYPE_GIC_MSI_FRAME:
>> +        {
>> +            struct acpi_madt_gic_msi_frame *p =
>> +                (struct acpi_madt_gic_msi_frame *)header;
>> +            pr_info("GIC MSI Frame (address[0x%08llx] msi_fame_id[%d])\n",
>> +                p->base_address, p->gic_msi_frame_id);
>> +        }
>> +        break;
>> +
>> +    case ACPI_MADT_TYPE_GIC_REDISTRIBUTOR:
>> +        {
>> +            struct acpi_madt_gic_redistributor *p =
>> +                (struct acpi_madt_gic_redistributor *)header;
>> +            pr_info("GIC Redistributor (address[0x%08llx] region_size[0x%x])\n",
>> +                p->base_address, p->region_size);
>> +        }
>> +        break;
>> +
> 
> You may need to rework on the variable names when you rebase on ACPICA 20140724

Yes, I'm working on it :)

Thanks
Hanjun

[PATCH 08/19] ACPI / table: Print GIC information when MADT is parsed

[Hanjun Guo]

On 2014-7-31 2:21, Sudeep Holla wrote:
> On 24/07/14 14:00, Hanjun Guo wrote:
>> When MADT is parsed, print GIC information to make the boot
>> log look pretty.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> ---
>>   drivers/acpi/tables.c |   39 ++++++++++++++++++++++++++++++++++++++-
>>   1 file changed, 38 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
>> index 6d5a6cd..8bb8159 100644
>> --- a/drivers/acpi/tables.c
>> +++ b/drivers/acpi/tables.c
>> @@ -183,6 +183,44 @@ void acpi_table_print_madt_entry(struct
>> acpi_subtable_header *header)
>>           }
>>           break;
>>
>> +    case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
>> +        {
>> +            struct acpi_madt_generic_interrupt *p =
>> +                (struct acpi_madt_generic_interrupt *)header;
>> +            pr_info("GICC (acpi_id[0x%04x] cpu_address[0x%08llx]
>> MPDIR[0x%llx] %s)\n",
> 
> What exactly does cpu_address mean ? Better s/cpu_address/address

Agreed.

> 
>> +                p->uid, p->base_address, p->mpidr,
>> +                (p->flags & ACPI_MADT_ENABLED) ? "enabled" : "disabled");
>> +
>> +        }
>> +        break;
>> +
>> +    case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
>> +        {
>> +            struct acpi_madt_generic_distributor *p =
>> +                (struct acpi_madt_generic_distributor *)header;
>> +            pr_info("GIC Distributor (id[0x%04x] address[0x%08llx]
>> gsi_base[%d])\n",
>> +                p->gic_id, p->base_address, p->global_irq_base);
>> +        }
>> +        break;
>> +
>> +    case ACPI_MADT_TYPE_GIC_MSI_FRAME:
>> +        {
>> +            struct acpi_madt_gic_msi_frame *p =
>> +                (struct acpi_madt_gic_msi_frame *)header;
>> +            pr_info("GIC MSI Frame (address[0x%08llx] msi_fame_id[%d])\n",
>> +                p->base_address, p->gic_msi_frame_id);
>> +        }
>> +        break;
>> +
>> +    case ACPI_MADT_TYPE_GIC_REDISTRIBUTOR:
>> +        {
>> +            struct acpi_madt_gic_redistributor *p =
>> +                (struct acpi_madt_gic_redistributor *)header;
>> +            pr_info("GIC Redistributor (address[0x%08llx] region_size[0x%x])\n",
>> +                p->base_address, p->region_size);
>> +        }
>> +        break;
>> +
> 
> You may need to rework on the variable names when you rebase on ACPICA 20140724

Yes, I'm working on it :)

Thanks
Hanjun

Re: [PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Hanjun Guo]

On 2014-7-31 12:22, Olof Johansson wrote:
> Hi,

Hi Olof,

> 
> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
>> the former signals to the OS that the hardware is PSCI compliant.
>> The latter selects the appropriate conduit for PSCI calls by
>> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
>> (SMC).
>>
>> FADT table contains such information, parse FADT to get the flags
>> for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
>> function IDs, which means that only PSCI 0.2+ is supported in ACPI.
>>
>> At the same time, only ACPI 5.1 or higher verison supports PSCI,
>> and FADT Major.Minor version was introduced in ACPI 5.1, so we
>> will check the version and only parse FADT table with version >= 5.1.
>>
>> If firmware provides ACPI tables with ACPI version less than 5.1,
>> OS will be messed up with those information and have no way to
>> bring up secondery CPUs, so disable ACPI if we get an FADT table
>> with version less that 5.1.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> ---
>>  arch/arm64/include/asm/acpi.h |    2 +
>>  arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
>>  arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
>>  arch/arm64/kernel/setup.c     |    2 +
>>  4 files changed, 121 insertions(+), 28 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 44b617f..67dac90 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -18,6 +18,8 @@ extern int acpi_disabled;
>>  extern int acpi_noirq;
>>  extern int acpi_pci_disabled;
>>  extern int acpi_strict;
>> +extern int acpi_psci_present;
>> +extern int acpi_psci_use_hvc;
>>
>>  static inline void disable_acpi(void)
>>  {
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index f5a10b5..374926f 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -11,6 +11,8 @@
>>   *  published by the Free Software Foundation.
>>   */
>>
>> +#define pr_fmt(fmt) "ACPI: " fmt
>> +
>>  #include <linux/init.h>
>>  #include <linux/acpi.h>
>>  #include <linux/cpumask.h>
>> @@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
>>  int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
>>  EXPORT_SYMBOL(acpi_pci_disabled);
>>
>> +/* 1 to indicate PSCI is implemented */
>> +int acpi_psci_present;
>> +
>> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>> +int acpi_psci_use_hvc;
> 
> Here's a prime example of where it would just make more sense to
> populate DT based on what's in the ACPI info.
> 
> Have a acpi_parse_fadt() that, if needed, creates a /psci node in the
> system-wide DT and populates it with the few properties needed.
> 
> That way, the rest of the code path in the kernel setup is identical,
> instead of dealing with separate functions for setup, two exported
> variables just to communicate the state, and so on. It's just extra
> complexity for no good reason. The ACPi side code isn't even adding
> significant complexity compared to this. We'll need to add an
> of_add_node() property though.

Yes, this will make the code path in the kernel setup is identical, but
I think mixture of ACPI and DT (converting ACPI into DT at run-time) is
not a good solution, and this had been discussed last year:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/211662.html


> 
>>  /*
>>   * __acpi_map_table() will be called before page_init(), so early_ioremap()
>>   * or early_memremap() should be called here to for ACPI table mapping.
>> @@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>>         early_iounmap(map, size);
>>  }
>>
>> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
>> +{
>> +       struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> +
>> +       /*
>> +        * Revision in table header is the FADT Major version,
>> +        * and there is a minor version of FADT which was introduced
>> +        * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
>> +        * to get arm boot flags, or we will disable ACPI.
>> +        */
>> +       if (table->revision < 5 || fadt->minor_version < 1) {
>> +               pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
>> +                       table->revision, fadt->minor_version);
>> +               acpi_psci_present = 0;
>> +               disable_acpi();
> 
> This does more than just check for FADT/PSCI, it disables ACPI
> alltogether. That kind of side effect from parse_fadt() doesn't seem
> appropriate.

As the this version of patch set only handle ACPI 5.1 version or higher,
and when we test this patch set when we passing ACPI tables with version
5.0, it messed up the kernel at boot-time, so we disable ACPI when
we got tables with ACPI version less that 5.1.

> 
>> +               return -EINVAL;
>> +       }
>> +
>> +       if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
>> +               acpi_psci_present = 1;
>> +
>> +       if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
>> +               acpi_psci_use_hvc = 1;
>> +
>> +       return 0;
>> +}
>> +
>>  /*
>>   * acpi_boot_table_init() called from setup_arch(), always.
>>   *     1. find RSDP and get its address, and then find XSDT
>> @@ -75,6 +110,21 @@ void __init acpi_boot_table_init(void)
>>         }
>>  }
>>
>> +int __init acpi_boot_init(void)
>> +{
>> +       int err = 0;
>> +
>> +       /* If acpi_disabled, bail out */
>> +       if (acpi_disabled)
>> +               return -ENODEV;
>> +
>> +       err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
>> +       if (err)
>> +               pr_err("Can't find FADT\n");
>> +
>> +       return err;
>> +}
>> +
>>  static int __init parse_acpi(char *arg)
>>  {
>>         if (!arg)
>> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
>> index 9e9798f..adb25f3 100644
>> --- a/arch/arm64/kernel/psci.c
>> +++ b/arch/arm64/kernel/psci.c
>> @@ -15,6 +15,7 @@
>>
>>  #define pr_fmt(fmt) "psci: " fmt
>>
>> +#include <linux/acpi.h>
>>  #include <linux/init.h>
>>  #include <linux/of.h>
>>  #include <linux/smp.h>
>> @@ -231,6 +232,33 @@ static void psci_sys_poweroff(void)
>>         invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
>>  }
>>
>> +static void psci_0_2_set_functions(void)
>> +{
>> +       pr_info("Using standard PSCI v0.2 function IDs\n");
>> +       psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
>> +       psci_ops.cpu_suspend = psci_cpu_suspend;
>> +
>> +       psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
>> +       psci_ops.cpu_off = psci_cpu_off;
>> +
>> +       psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
>> +       psci_ops.cpu_on = psci_cpu_on;
>> +
>> +       psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
>> +       psci_ops.migrate = psci_migrate;
>> +
>> +       psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
>> +       psci_ops.affinity_info = psci_affinity_info;
>> +
>> +       psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
>> +               PSCI_0_2_FN_MIGRATE_INFO_TYPE;
>> +       psci_ops.migrate_info_type = psci_migrate_info_type;
>> +
>> +       arm_pm_restart = psci_sys_reset;
>> +
>> +       pm_power_off = psci_sys_poweroff;
>> +}
>> +
>>  /*
>>   * PSCI Function IDs for v0.2+ are well defined so use
>>   * standard values.
>> @@ -264,29 +292,7 @@ static int psci_0_2_init(struct device_node *np)
>>                 }
>>         }
>>
>> -       pr_info("Using standard PSCI v0.2 function IDs\n");
>> -       psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
>> -       psci_ops.cpu_suspend = psci_cpu_suspend;
>> -
>> -       psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
>> -       psci_ops.cpu_off = psci_cpu_off;
>> -
>> -       psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
>> -       psci_ops.cpu_on = psci_cpu_on;
>> -
>> -       psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
>> -       psci_ops.migrate = psci_migrate;
>> -
>> -       psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
>> -       psci_ops.affinity_info = psci_affinity_info;
>> -
>> -       psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
>> -               PSCI_0_2_FN_MIGRATE_INFO_TYPE;
>> -       psci_ops.migrate_info_type = psci_migrate_info_type;
>> -
>> -       arm_pm_restart = psci_sys_reset;
>> -
>> -       pm_power_off = psci_sys_poweroff;
>> +       psci_0_2_set_functions();
>>
>>  out_put_node:
>>         of_node_put(np);
>> @@ -333,6 +339,33 @@ out_put_node:
>>         return err;
>>  }
>>
>> +#ifdef CONFIG_ACPI
>> +static int get_set_conduit_method_acpi(void)
>> +{
>> +       if (acpi_psci_use_hvc)
>> +               invoke_psci_fn = __invoke_psci_fn_hvc;
>> +       else
>> +               invoke_psci_fn = __invoke_psci_fn_smc;
>> +
>> +       return 0;
>> +}
>> +
>> +/* We use PSCI 0.2+ when ACPI is deployed */
>> +static int psci_0_2_init_acpi(void)
>> +{
>> +       get_set_conduit_method_acpi();
>> +
>> +       psci_0_2_set_functions();
> 
> Here's a good example of the two code paths doing different things.
> The DT code paths does a test call into PSCI to make sure it's
> actually supported, while you blindly trust it. Keeping the code paths
> common has value w.r.t these kind of things.

I should check acpi_psci_present first, and I will check if I can reuse
the DT code.

> 
>> +       return 0;
>> +}
>> +#else
>> +static inline int psci_0_2_init_acpi(void)
>> +{
>> +       return -ENODEV;
>> +}
>> +#endif
>> +
>>  static const struct of_device_id psci_of_match[] __initconst = {
>>         { .compatible = "arm,psci",     .data = psci_0_1_init},
>>         { .compatible = "arm,psci-0.2", .data = psci_0_2_init},
>> @@ -345,13 +378,19 @@ int __init psci_init(void)
>>         const struct of_device_id *matched_np;
>>         psci_initcall_t init_fn;
>>
>> -       np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
>> +       if (acpi_disabled) {
>> +               np = of_find_matching_node_and_match(NULL,
>> +                               psci_of_match, &matched_np);
> 
> Ideally this code should go away by changing the rest of it, but for
> future cases: It'd be a lot cleaner to do this as:
> 
>         if (!acpi_disabled)
>                 return psci_0_2_init_acpi();
> 
> ... then fall through to the current implementation instead.

I prefer this one :)

Thanks
Hanjun

> 
> But sharing the whole code path is even better, so let's do that.
> 
>>
>> -       if (!np)
>> -               return -ENODEV;
>> +               if (!np)
>> +                       return -ENODEV;
>> +
>> +               init_fn = (psci_initcall_t)matched_np->data;
>> +
>> +               return init_fn(np);
>> +       }
>>
>> -       init_fn = (psci_initcall_t)matched_np->data;
>> -       return init_fn(np);
>> +       return psci_0_2_init_acpi();
>>  }
>>
>>  #ifdef CONFIG_SMP
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index 9dedb0b..e00d40c 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -394,6 +394,8 @@ void __init setup_arch(char **cmdline_p)
>>
>>         efi_idmap_init();
>>
>> +       acpi_boot_init();
>> +
>>         unflatten_device_tree();
> 
> The above two will need to be swapped when you move over to populating
> the DT instead.
> 
>>
>>         psci_init();
> 
> 
> -Olof
> 

[PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Hanjun Guo]

On 2014-7-31 12:22, Olof Johansson wrote:
> Hi,

Hi Olof,

> 
> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
>> the former signals to the OS that the hardware is PSCI compliant.
>> The latter selects the appropriate conduit for PSCI calls by
>> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
>> (SMC).
>>
>> FADT table contains such information, parse FADT to get the flags
>> for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
>> function IDs, which means that only PSCI 0.2+ is supported in ACPI.
>>
>> At the same time, only ACPI 5.1 or higher verison supports PSCI,
>> and FADT Major.Minor version was introduced in ACPI 5.1, so we
>> will check the version and only parse FADT table with version >= 5.1.
>>
>> If firmware provides ACPI tables with ACPI version less than 5.1,
>> OS will be messed up with those information and have no way to
>> bring up secondery CPUs, so disable ACPI if we get an FADT table
>> with version less that 5.1.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
>> ---
>>  arch/arm64/include/asm/acpi.h |    2 +
>>  arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
>>  arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
>>  arch/arm64/kernel/setup.c     |    2 +
>>  4 files changed, 121 insertions(+), 28 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 44b617f..67dac90 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -18,6 +18,8 @@ extern int acpi_disabled;
>>  extern int acpi_noirq;
>>  extern int acpi_pci_disabled;
>>  extern int acpi_strict;
>> +extern int acpi_psci_present;
>> +extern int acpi_psci_use_hvc;
>>
>>  static inline void disable_acpi(void)
>>  {
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index f5a10b5..374926f 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -11,6 +11,8 @@
>>   *  published by the Free Software Foundation.
>>   */
>>
>> +#define pr_fmt(fmt) "ACPI: " fmt
>> +
>>  #include <linux/init.h>
>>  #include <linux/acpi.h>
>>  #include <linux/cpumask.h>
>> @@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
>>  int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
>>  EXPORT_SYMBOL(acpi_pci_disabled);
>>
>> +/* 1 to indicate PSCI is implemented */
>> +int acpi_psci_present;
>> +
>> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
>> +int acpi_psci_use_hvc;
> 
> Here's a prime example of where it would just make more sense to
> populate DT based on what's in the ACPI info.
> 
> Have a acpi_parse_fadt() that, if needed, creates a /psci node in the
> system-wide DT and populates it with the few properties needed.
> 
> That way, the rest of the code path in the kernel setup is identical,
> instead of dealing with separate functions for setup, two exported
> variables just to communicate the state, and so on. It's just extra
> complexity for no good reason. The ACPi side code isn't even adding
> significant complexity compared to this. We'll need to add an
> of_add_node() property though.

Yes, this will make the code path in the kernel setup is identical, but
I think mixture of ACPI and DT (converting ACPI into DT at run-time) is
not a good solution, and this had been discussed last year:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/211662.html


> 
>>  /*
>>   * __acpi_map_table() will be called before page_init(), so early_ioremap()
>>   * or early_memremap() should be called here to for ACPI table mapping.
>> @@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>>         early_iounmap(map, size);
>>  }
>>
>> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
>> +{
>> +       struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> +
>> +       /*
>> +        * Revision in table header is the FADT Major version,
>> +        * and there is a minor version of FADT which was introduced
>> +        * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
>> +        * to get arm boot flags, or we will disable ACPI.
>> +        */
>> +       if (table->revision < 5 || fadt->minor_version < 1) {
>> +               pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
>> +                       table->revision, fadt->minor_version);
>> +               acpi_psci_present = 0;
>> +               disable_acpi();
> 
> This does more than just check for FADT/PSCI, it disables ACPI
> alltogether. That kind of side effect from parse_fadt() doesn't seem
> appropriate.

As the this version of patch set only handle ACPI 5.1 version or higher,
and when we test this patch set when we passing ACPI tables with version
5.0, it messed up the kernel at boot-time, so we disable ACPI when
we got tables with ACPI version less that 5.1.

> 
>> +               return -EINVAL;
>> +       }
>> +
>> +       if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
>> +               acpi_psci_present = 1;
>> +
>> +       if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
>> +               acpi_psci_use_hvc = 1;
>> +
>> +       return 0;
>> +}
>> +
>>  /*
>>   * acpi_boot_table_init() called from setup_arch(), always.
>>   *     1. find RSDP and get its address, and then find XSDT
>> @@ -75,6 +110,21 @@ void __init acpi_boot_table_init(void)
>>         }
>>  }
>>
>> +int __init acpi_boot_init(void)
>> +{
>> +       int err = 0;
>> +
>> +       /* If acpi_disabled, bail out */
>> +       if (acpi_disabled)
>> +               return -ENODEV;
>> +
>> +       err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
>> +       if (err)
>> +               pr_err("Can't find FADT\n");
>> +
>> +       return err;
>> +}
>> +
>>  static int __init parse_acpi(char *arg)
>>  {
>>         if (!arg)
>> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
>> index 9e9798f..adb25f3 100644
>> --- a/arch/arm64/kernel/psci.c
>> +++ b/arch/arm64/kernel/psci.c
>> @@ -15,6 +15,7 @@
>>
>>  #define pr_fmt(fmt) "psci: " fmt
>>
>> +#include <linux/acpi.h>
>>  #include <linux/init.h>
>>  #include <linux/of.h>
>>  #include <linux/smp.h>
>> @@ -231,6 +232,33 @@ static void psci_sys_poweroff(void)
>>         invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
>>  }
>>
>> +static void psci_0_2_set_functions(void)
>> +{
>> +       pr_info("Using standard PSCI v0.2 function IDs\n");
>> +       psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
>> +       psci_ops.cpu_suspend = psci_cpu_suspend;
>> +
>> +       psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
>> +       psci_ops.cpu_off = psci_cpu_off;
>> +
>> +       psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
>> +       psci_ops.cpu_on = psci_cpu_on;
>> +
>> +       psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
>> +       psci_ops.migrate = psci_migrate;
>> +
>> +       psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
>> +       psci_ops.affinity_info = psci_affinity_info;
>> +
>> +       psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
>> +               PSCI_0_2_FN_MIGRATE_INFO_TYPE;
>> +       psci_ops.migrate_info_type = psci_migrate_info_type;
>> +
>> +       arm_pm_restart = psci_sys_reset;
>> +
>> +       pm_power_off = psci_sys_poweroff;
>> +}
>> +
>>  /*
>>   * PSCI Function IDs for v0.2+ are well defined so use
>>   * standard values.
>> @@ -264,29 +292,7 @@ static int psci_0_2_init(struct device_node *np)
>>                 }
>>         }
>>
>> -       pr_info("Using standard PSCI v0.2 function IDs\n");
>> -       psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
>> -       psci_ops.cpu_suspend = psci_cpu_suspend;
>> -
>> -       psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
>> -       psci_ops.cpu_off = psci_cpu_off;
>> -
>> -       psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
>> -       psci_ops.cpu_on = psci_cpu_on;
>> -
>> -       psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
>> -       psci_ops.migrate = psci_migrate;
>> -
>> -       psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
>> -       psci_ops.affinity_info = psci_affinity_info;
>> -
>> -       psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
>> -               PSCI_0_2_FN_MIGRATE_INFO_TYPE;
>> -       psci_ops.migrate_info_type = psci_migrate_info_type;
>> -
>> -       arm_pm_restart = psci_sys_reset;
>> -
>> -       pm_power_off = psci_sys_poweroff;
>> +       psci_0_2_set_functions();
>>
>>  out_put_node:
>>         of_node_put(np);
>> @@ -333,6 +339,33 @@ out_put_node:
>>         return err;
>>  }
>>
>> +#ifdef CONFIG_ACPI
>> +static int get_set_conduit_method_acpi(void)
>> +{
>> +       if (acpi_psci_use_hvc)
>> +               invoke_psci_fn = __invoke_psci_fn_hvc;
>> +       else
>> +               invoke_psci_fn = __invoke_psci_fn_smc;
>> +
>> +       return 0;
>> +}
>> +
>> +/* We use PSCI 0.2+ when ACPI is deployed */
>> +static int psci_0_2_init_acpi(void)
>> +{
>> +       get_set_conduit_method_acpi();
>> +
>> +       psci_0_2_set_functions();
> 
> Here's a good example of the two code paths doing different things.
> The DT code paths does a test call into PSCI to make sure it's
> actually supported, while you blindly trust it. Keeping the code paths
> common has value w.r.t these kind of things.

I should check acpi_psci_present first, and I will check if I can reuse
the DT code.

> 
>> +       return 0;
>> +}
>> +#else
>> +static inline int psci_0_2_init_acpi(void)
>> +{
>> +       return -ENODEV;
>> +}
>> +#endif
>> +
>>  static const struct of_device_id psci_of_match[] __initconst = {
>>         { .compatible = "arm,psci",     .data = psci_0_1_init},
>>         { .compatible = "arm,psci-0.2", .data = psci_0_2_init},
>> @@ -345,13 +378,19 @@ int __init psci_init(void)
>>         const struct of_device_id *matched_np;
>>         psci_initcall_t init_fn;
>>
>> -       np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
>> +       if (acpi_disabled) {
>> +               np = of_find_matching_node_and_match(NULL,
>> +                               psci_of_match, &matched_np);
> 
> Ideally this code should go away by changing the rest of it, but for
> future cases: It'd be a lot cleaner to do this as:
> 
>         if (!acpi_disabled)
>                 return psci_0_2_init_acpi();
> 
> ... then fall through to the current implementation instead.

I prefer this one :)

Thanks
Hanjun

> 
> But sharing the whole code path is even better, so let's do that.
> 
>>
>> -       if (!np)
>> -               return -ENODEV;
>> +               if (!np)
>> +                       return -ENODEV;
>> +
>> +               init_fn = (psci_initcall_t)matched_np->data;
>> +
>> +               return init_fn(np);
>> +       }
>>
>> -       init_fn = (psci_initcall_t)matched_np->data;
>> -       return init_fn(np);
>> +       return psci_0_2_init_acpi();
>>  }
>>
>>  #ifdef CONFIG_SMP
>> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
>> index 9dedb0b..e00d40c 100644
>> --- a/arch/arm64/kernel/setup.c
>> +++ b/arch/arm64/kernel/setup.c
>> @@ -394,6 +394,8 @@ void __init setup_arch(char **cmdline_p)
>>
>>         efi_idmap_init();
>>
>> +       acpi_boot_init();
>> +
>>         unflatten_device_tree();
> 
> The above two will need to be swapped when you move over to populating
> the DT instead.
> 
>>
>>         psci_init();
> 
> 
> -Olof
> 

Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

On 2014-7-31 14:54, Olof Johansson wrote:
> Hi,
> 
> On Thu, Jul 24, 2014 at 09:00:16PM +0800, Hanjun Guo wrote:
>> +/*
>> + * In ACPI mode, the cpu possible map was enumerated before SMP
>> + * initialization when MADT table was parsed, so we can get the
>> + * possible map here to initialize CPUs.
>> + */
> 
> The DT smp init will warn if the kernel has been build with too low NR_CPUS.
> Does the ACPI core already warn, or did that go missing with this separate code
> path?

ACPI code will warn, it is in PATCH 07/19,

+	if (enabled_cpus >=  NR_CPUS) {
+		pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
+			NR_CPUS, total_cpus, mpidr);
+		return -EINVAL;
+	}

> 
>> +static void __init acpi_smp_init_cpus(void)
>> +{
>> +	int cpu;
>> +
>> +	for_each_possible_cpu(cpu) {
>> +		if (cpu_acpi_read_ops(cpu) != 0)
>> +			continue;
>> +
>> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
>> +	}
>> +}
>> +
>> +void __init smp_init_cpus(void)
>> +{
>> +	if (acpi_disabled)
>> +		of_smp_init_cpus();
>> +	else
>> +		acpi_smp_init_cpus();
> 
> I'm liking these deeply split code paths less and less every time I see
> them. :(
> 
> I would prefer to set up shared state in separate functions, but keep the
> control flow the same. Right now you're splitting it completely.
> 
> I.e. split data setup between the two, but do the loop calling cpu_init()
> the same way. (Yes, that will require you to refactor the DT code path
> a bit too...)

OK, I will dive into the code and figure out if I can fix that as you
suggested, thanks for your comments :)

Best Regards
Hanjun

Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

On 2014-7-31 14:54, Olof Johansson wrote:
> Hi,
> 
> On Thu, Jul 24, 2014 at 09:00:16PM +0800, Hanjun Guo wrote:
>> +/*
>> + * In ACPI mode, the cpu possible map was enumerated before SMP
>> + * initialization when MADT table was parsed, so we can get the
>> + * possible map here to initialize CPUs.
>> + */
> 
> The DT smp init will warn if the kernel has been build with too low NR_CPUS.
> Does the ACPI core already warn, or did that go missing with this separate code
> path?

ACPI code will warn, it is in PATCH 07/19,

+	if (enabled_cpus >=  NR_CPUS) {
+		pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
+			NR_CPUS, total_cpus, mpidr);
+		return -EINVAL;
+	}

> 
>> +static void __init acpi_smp_init_cpus(void)
>> +{
>> +	int cpu;
>> +
>> +	for_each_possible_cpu(cpu) {
>> +		if (cpu_acpi_read_ops(cpu) != 0)
>> +			continue;
>> +
>> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
>> +	}
>> +}
>> +
>> +void __init smp_init_cpus(void)
>> +{
>> +	if (acpi_disabled)
>> +		of_smp_init_cpus();
>> +	else
>> +		acpi_smp_init_cpus();
> 
> I'm liking these deeply split code paths less and less every time I see
> them. :(
> 
> I would prefer to set up shared state in separate functions, but keep the
> control flow the same. Right now you're splitting it completely.
> 
> I.e. split data setup between the two, but do the loop calling cpu_init()
> the same way. (Yes, that will require you to refactor the DT code path
> a bit too...)

OK, I will dive into the code and figure out if I can fix that as you
suggested, thanks for your comments :)

Best Regards
Hanjun

[PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

On 2014-7-31 14:54, Olof Johansson wrote:
> Hi,
> 
> On Thu, Jul 24, 2014 at 09:00:16PM +0800, Hanjun Guo wrote:
>> +/*
>> + * In ACPI mode, the cpu possible map was enumerated before SMP
>> + * initialization when MADT table was parsed, so we can get the
>> + * possible map here to initialize CPUs.
>> + */
> 
> The DT smp init will warn if the kernel has been build with too low NR_CPUS.
> Does the ACPI core already warn, or did that go missing with this separate code
> path?

ACPI code will warn, it is in PATCH 07/19,

+	if (enabled_cpus >=  NR_CPUS) {
+		pr_warn("NR_CPUS limit of %d reached, Processor %d/0x%llx ignored.\n",
+			NR_CPUS, total_cpus, mpidr);
+		return -EINVAL;
+	}

> 
>> +static void __init acpi_smp_init_cpus(void)
>> +{
>> +	int cpu;
>> +
>> +	for_each_possible_cpu(cpu) {
>> +		if (cpu_acpi_read_ops(cpu) != 0)
>> +			continue;
>> +
>> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
>> +	}
>> +}
>> +
>> +void __init smp_init_cpus(void)
>> +{
>> +	if (acpi_disabled)
>> +		of_smp_init_cpus();
>> +	else
>> +		acpi_smp_init_cpus();
> 
> I'm liking these deeply split code paths less and less every time I see
> them. :(
> 
> I would prefer to set up shared state in separate functions, but keep the
> control flow the same. Right now you're splitting it completely.
> 
> I.e. split data setup between the two, but do the loop calling cpu_init()
> the same way. (Yes, that will require you to refactor the DT code path
> a bit too...)

OK, I will dive into the code and figure out if I can fix that as you
suggested, thanks for your comments :)

Best Regards
Hanjun

Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Geoff Levand]

Hi Hanjun,

On Thu, 2014-07-24 at 21:00 +0800, Hanjun Guo wrote:
> ACPI 5.1 only has two explicit methods to boot up SMP,
> PSCI and Parking protocol, but the Parking protocol is
> only suitable for ARMv7 now, so make PSCI as the only way
> for the SMP boot protocol before some updates for the
> ACPI spec or the Parking protocol spec.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h    |   21 +++++++++++++++
>  arch/arm64/include/asm/cpu_ops.h |    9 ++++++-
>  arch/arm64/include/asm/smp.h     |    2 +-
>  arch/arm64/kernel/acpi.c         |    9 +++++++
>  arch/arm64/kernel/cpu_ops.c      |   52 ++++++++++++++++++++++++++++++++++----
>  arch/arm64/kernel/smp.c          |   29 +++++++++++++++++++--
>  6 files changed, 113 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 5ce85f8..6240327 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -14,6 +14,27 @@
>  
>  /* Basic configuration for ACPI */
>  #ifdef	CONFIG_ACPI

^^ This seems to be a tab (\t) character here, which is a strange thing
for me to see...

> +/*
> + * ACPI 5.1 only has two explicit methods to
> + * boot up SMP, PSCI and Parking protocol,
> + * but the Parking protocol is only defined
> + * for ARMv7 now, so make PSCI as the only
> + * way for the SMP boot protocol before some
> + * updates for the ACPI spec or the Parking
> + * protocol spec.
> + *
> + * This enum is intend to make the boot method
> + * scalable when above updates are happended,
> + * which NOT means to support all of them.
> + */

This comment will become out of date soon (I hope), and it is often the
case that these short term comments are not removed, so I think it
better to put this kind of note into the commit message, not the code.

> +enum acpi_smp_boot_protocol {
> +	ACPI_SMP_BOOT_PSCI,
> +	ACPI_SMP_BOOT_PARKING_PROTOCOL,
> +	ACPI_SMP_BOOT_PROTOCOL_MAX
> +};
> +
> +enum acpi_smp_boot_protocol smp_boot_protocol(void);
> +
>  extern int acpi_disabled;
>  extern int acpi_noirq;
>  extern int acpi_pci_disabled;
> diff --git a/arch/arm64/include/asm/cpu_ops.h b/arch/arm64/include/asm/cpu_ops.h
> index d7b4b38..2a7c6fd 100644
> --- a/arch/arm64/include/asm/cpu_ops.h
> +++ b/arch/arm64/include/asm/cpu_ops.h
> @@ -61,7 +61,14 @@ struct cpu_operations {
>  };
>  
>  extern const struct cpu_operations *cpu_ops[NR_CPUS];
> -extern int __init cpu_read_ops(struct device_node *dn, int cpu);
> +extern int __init cpu_of_read_ops(struct device_node *dn, int cpu);
> +
> +#ifdef CONFIG_ACPI
> +extern int __init cpu_acpi_read_ops(int cpu);
> +#else
> +static inline int __init cpu_acpi_read_ops(int cpu) { return -ENODEV; }
> +#endif

This looks messy and not scalable for new enable methods.  It
seems a better way is to retain cpu_read_ops() and its functionality,
which is to return the proper enable method for that cpu in a generic
way.

Is there some reason you can't integrate acpi into the existing
cpu_ops and need to make this completely parallel method?

>  extern void __init cpu_read_bootcpu_ops(void);
>  
>  #endif /* ifndef __ASM_CPU_OPS_H */
> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> index a498f2c..a5cea56 100644
> --- a/arch/arm64/include/asm/smp.h
> +++ b/arch/arm64/include/asm/smp.h
> @@ -39,7 +39,7 @@ extern void show_ipi_list(struct seq_file *p, int prec);
>  extern void handle_IPI(int ipinr, struct pt_regs *regs);
>  
>  /*
> - * Setup the set of possible CPUs (via set_cpu_possible)
> + * Platform specific SMP operations
>   */
>  extern void smp_init_cpus(void);
>  
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index ff0f6a0..2af6662 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
>  	return 0;
>  }
>  
> +/* Protocol to bring up secondary CPUs */
> +enum acpi_smp_boot_protocol smp_boot_protocol(void)
> +{
> +	if (acpi_psci_present)
> +		return ACPI_SMP_BOOT_PSCI;
> +	else
> +		return ACPI_SMP_BOOT_PARKING_PROTOCOL;
> +}
> +
>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
>  {
>  	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
> index d62d12f..4d9b3cf 100644
> --- a/arch/arm64/kernel/cpu_ops.c
> +++ b/arch/arm64/kernel/cpu_ops.c
> @@ -16,11 +16,13 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> -#include <asm/cpu_ops.h>
> -#include <asm/smp_plat.h>
>  #include <linux/errno.h>
>  #include <linux/of.h>
>  #include <linux/string.h>
> +#include <linux/acpi.h>
> +
> +#include <asm/cpu_ops.h>
> +#include <asm/smp_plat.h>
>  
>  extern const struct cpu_operations smp_spin_table_ops;
>  extern const struct cpu_operations cpu_psci_ops;
> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
>  /*
>   * Read a cpu's enable method from the device tree and record it in cpu_ops.
>   */
> -int __init cpu_read_ops(struct device_node *dn, int cpu)
> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
>  {
>  	const char *enable_method = of_get_property(dn, "enable-method", NULL);
>  	if (!enable_method) {
> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_ACPI
> +/*
> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
> + */
> +int __init cpu_acpi_read_ops(int cpu)
> +{
> +	/*
> +	 * For ACPI 5.1, only two kind of methods are provided,
> +	 * Parking protocol and PSCI, but Parking protocol is
> +	 * used on ARMv7 only, so make PSCI as the only method
> +	 * for SMP initialization before the ACPI spec or Parking
> +	 * protocol spec is updated.
> +	 */

Again, this comment will get old fast (I hope).

> +	switch (smp_boot_protocol()) {
> +	case ACPI_SMP_BOOT_PSCI:
> +		cpu_ops[cpu] = cpu_get_ops("psci");
> +		break;
> +	case ACPI_SMP_BOOT_PARKING_PROTOCOL:
> +	default:
> +		cpu_ops[cpu] = NULL;
> +		break;
> +	}
> +
> +	if (!cpu_ops[cpu]) {
> +		pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
> +			cpu);
> +		return -EOPNOTSUPP;
> +	}
> +
> +	return 0;
> +}
> +#endif
> +
>  void __init cpu_read_bootcpu_ops(void)
>  {
> -	struct device_node *dn = of_get_cpu_node(0, NULL);
> +	struct device_node *dn;
> +
> +	if (!acpi_disabled) {
> +		cpu_acpi_read_ops(0);
> +		return;
> +	}
> +
> +	dn = of_get_cpu_node(0, NULL);
>  	if (!dn) {
>  		pr_err("Failed to find device node for boot cpu\n");
>  		return;
>  	}
> -	cpu_read_ops(dn, 0);
> +	cpu_of_read_ops(dn, 0);
>  }
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 8f1d37c..cb71662 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -315,7 +315,7 @@ static void (*smp_cross_call)(const struct cpumask *, unsigned int);
>   * cpu logical map array containing MPIDR values related to logical
>   * cpus. Assumes that cpu_logical_map(0) has already been initialized.
>   */
> -void __init smp_init_cpus(void)
> +static void __init of_smp_init_cpus(void)
>  {
>  	struct device_node *dn = NULL;
>  	unsigned int i, cpu = 1;
> @@ -387,7 +387,7 @@ void __init smp_init_cpus(void)
>  		if (cpu >= NR_CPUS)
>  			goto next;
>  
> -		if (cpu_read_ops(dn, cpu) != 0)
> +		if (cpu_of_read_ops(dn, cpu) != 0)
>  			goto next;
>  
>  		if (cpu_ops[cpu]->cpu_init(dn, cpu))
> @@ -418,6 +418,31 @@ next:
>  			set_cpu_possible(i, true);
>  }
>  
> +/*
> + * In ACPI mode, the cpu possible map was enumerated before SMP
> + * initialization when MADT table was parsed, so we can get the
> + * possible map here to initialize CPUs.
> + */
> +static void __init acpi_smp_init_cpus(void)
> +{
> +	int cpu;
> +
> +	for_each_possible_cpu(cpu) {
> +		if (cpu_acpi_read_ops(cpu) != 0)
> +			continue;
> +
> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
> +	}
> +}
> +
> +void __init smp_init_cpus(void)
> +{
> +	if (acpi_disabled)
> +		of_smp_init_cpus();
> +	else
> +		acpi_smp_init_cpus();
> +}

This is the same as cpu_ops, is acpi so special we need a completely
parallel method of initializing secondary cpus?

-Geoff

Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Geoff Levand]

Hi Hanjun,

On Thu, 2014-07-24 at 21:00 +0800, Hanjun Guo wrote:
> ACPI 5.1 only has two explicit methods to boot up SMP,
> PSCI and Parking protocol, but the Parking protocol is
> only suitable for ARMv7 now, so make PSCI as the only way
> for the SMP boot protocol before some updates for the
> ACPI spec or the Parking protocol spec.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h    |   21 +++++++++++++++
>  arch/arm64/include/asm/cpu_ops.h |    9 ++++++-
>  arch/arm64/include/asm/smp.h     |    2 +-
>  arch/arm64/kernel/acpi.c         |    9 +++++++
>  arch/arm64/kernel/cpu_ops.c      |   52 ++++++++++++++++++++++++++++++++++----
>  arch/arm64/kernel/smp.c          |   29 +++++++++++++++++++--
>  6 files changed, 113 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 5ce85f8..6240327 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -14,6 +14,27 @@
>  
>  /* Basic configuration for ACPI */
>  #ifdef	CONFIG_ACPI

^^ This seems to be a tab (\t) character here, which is a strange thing
for me to see...

> +/*
> + * ACPI 5.1 only has two explicit methods to
> + * boot up SMP, PSCI and Parking protocol,
> + * but the Parking protocol is only defined
> + * for ARMv7 now, so make PSCI as the only
> + * way for the SMP boot protocol before some
> + * updates for the ACPI spec or the Parking
> + * protocol spec.
> + *
> + * This enum is intend to make the boot method
> + * scalable when above updates are happended,
> + * which NOT means to support all of them.
> + */

This comment will become out of date soon (I hope), and it is often the
case that these short term comments are not removed, so I think it
better to put this kind of note into the commit message, not the code.

> +enum acpi_smp_boot_protocol {
> +	ACPI_SMP_BOOT_PSCI,
> +	ACPI_SMP_BOOT_PARKING_PROTOCOL,
> +	ACPI_SMP_BOOT_PROTOCOL_MAX
> +};
> +
> +enum acpi_smp_boot_protocol smp_boot_protocol(void);
> +
>  extern int acpi_disabled;
>  extern int acpi_noirq;
>  extern int acpi_pci_disabled;
> diff --git a/arch/arm64/include/asm/cpu_ops.h b/arch/arm64/include/asm/cpu_ops.h
> index d7b4b38..2a7c6fd 100644
> --- a/arch/arm64/include/asm/cpu_ops.h
> +++ b/arch/arm64/include/asm/cpu_ops.h
> @@ -61,7 +61,14 @@ struct cpu_operations {
>  };
>  
>  extern const struct cpu_operations *cpu_ops[NR_CPUS];
> -extern int __init cpu_read_ops(struct device_node *dn, int cpu);
> +extern int __init cpu_of_read_ops(struct device_node *dn, int cpu);
> +
> +#ifdef CONFIG_ACPI
> +extern int __init cpu_acpi_read_ops(int cpu);
> +#else
> +static inline int __init cpu_acpi_read_ops(int cpu) { return -ENODEV; }
> +#endif

This looks messy and not scalable for new enable methods.  It
seems a better way is to retain cpu_read_ops() and its functionality,
which is to return the proper enable method for that cpu in a generic
way.

Is there some reason you can't integrate acpi into the existing
cpu_ops and need to make this completely parallel method?

>  extern void __init cpu_read_bootcpu_ops(void);
>  
>  #endif /* ifndef __ASM_CPU_OPS_H */
> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> index a498f2c..a5cea56 100644
> --- a/arch/arm64/include/asm/smp.h
> +++ b/arch/arm64/include/asm/smp.h
> @@ -39,7 +39,7 @@ extern void show_ipi_list(struct seq_file *p, int prec);
>  extern void handle_IPI(int ipinr, struct pt_regs *regs);
>  
>  /*
> - * Setup the set of possible CPUs (via set_cpu_possible)
> + * Platform specific SMP operations
>   */
>  extern void smp_init_cpus(void);
>  
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index ff0f6a0..2af6662 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
>  	return 0;
>  }
>  
> +/* Protocol to bring up secondary CPUs */
> +enum acpi_smp_boot_protocol smp_boot_protocol(void)
> +{
> +	if (acpi_psci_present)
> +		return ACPI_SMP_BOOT_PSCI;
> +	else
> +		return ACPI_SMP_BOOT_PARKING_PROTOCOL;
> +}
> +
>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
>  {
>  	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
> index d62d12f..4d9b3cf 100644
> --- a/arch/arm64/kernel/cpu_ops.c
> +++ b/arch/arm64/kernel/cpu_ops.c
> @@ -16,11 +16,13 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> -#include <asm/cpu_ops.h>
> -#include <asm/smp_plat.h>
>  #include <linux/errno.h>
>  #include <linux/of.h>
>  #include <linux/string.h>
> +#include <linux/acpi.h>
> +
> +#include <asm/cpu_ops.h>
> +#include <asm/smp_plat.h>
>  
>  extern const struct cpu_operations smp_spin_table_ops;
>  extern const struct cpu_operations cpu_psci_ops;
> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
>  /*
>   * Read a cpu's enable method from the device tree and record it in cpu_ops.
>   */
> -int __init cpu_read_ops(struct device_node *dn, int cpu)
> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
>  {
>  	const char *enable_method = of_get_property(dn, "enable-method", NULL);
>  	if (!enable_method) {
> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_ACPI
> +/*
> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
> + */
> +int __init cpu_acpi_read_ops(int cpu)
> +{
> +	/*
> +	 * For ACPI 5.1, only two kind of methods are provided,
> +	 * Parking protocol and PSCI, but Parking protocol is
> +	 * used on ARMv7 only, so make PSCI as the only method
> +	 * for SMP initialization before the ACPI spec or Parking
> +	 * protocol spec is updated.
> +	 */

Again, this comment will get old fast (I hope).

> +	switch (smp_boot_protocol()) {
> +	case ACPI_SMP_BOOT_PSCI:
> +		cpu_ops[cpu] = cpu_get_ops("psci");
> +		break;
> +	case ACPI_SMP_BOOT_PARKING_PROTOCOL:
> +	default:
> +		cpu_ops[cpu] = NULL;
> +		break;
> +	}
> +
> +	if (!cpu_ops[cpu]) {
> +		pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
> +			cpu);
> +		return -EOPNOTSUPP;
> +	}
> +
> +	return 0;
> +}
> +#endif
> +
>  void __init cpu_read_bootcpu_ops(void)
>  {
> -	struct device_node *dn = of_get_cpu_node(0, NULL);
> +	struct device_node *dn;
> +
> +	if (!acpi_disabled) {
> +		cpu_acpi_read_ops(0);
> +		return;
> +	}
> +
> +	dn = of_get_cpu_node(0, NULL);
>  	if (!dn) {
>  		pr_err("Failed to find device node for boot cpu\n");
>  		return;
>  	}
> -	cpu_read_ops(dn, 0);
> +	cpu_of_read_ops(dn, 0);
>  }
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 8f1d37c..cb71662 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -315,7 +315,7 @@ static void (*smp_cross_call)(const struct cpumask *, unsigned int);
>   * cpu logical map array containing MPIDR values related to logical
>   * cpus. Assumes that cpu_logical_map(0) has already been initialized.
>   */
> -void __init smp_init_cpus(void)
> +static void __init of_smp_init_cpus(void)
>  {
>  	struct device_node *dn = NULL;
>  	unsigned int i, cpu = 1;
> @@ -387,7 +387,7 @@ void __init smp_init_cpus(void)
>  		if (cpu >= NR_CPUS)
>  			goto next;
>  
> -		if (cpu_read_ops(dn, cpu) != 0)
> +		if (cpu_of_read_ops(dn, cpu) != 0)
>  			goto next;
>  
>  		if (cpu_ops[cpu]->cpu_init(dn, cpu))
> @@ -418,6 +418,31 @@ next:
>  			set_cpu_possible(i, true);
>  }
>  
> +/*
> + * In ACPI mode, the cpu possible map was enumerated before SMP
> + * initialization when MADT table was parsed, so we can get the
> + * possible map here to initialize CPUs.
> + */
> +static void __init acpi_smp_init_cpus(void)
> +{
> +	int cpu;
> +
> +	for_each_possible_cpu(cpu) {
> +		if (cpu_acpi_read_ops(cpu) != 0)
> +			continue;
> +
> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
> +	}
> +}
> +
> +void __init smp_init_cpus(void)
> +{
> +	if (acpi_disabled)
> +		of_smp_init_cpus();
> +	else
> +		acpi_smp_init_cpus();
> +}

This is the same as cpu_ops, is acpi so special we need a completely
parallel method of initializing secondary cpus?

-Geoff

[PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Geoff Levand]

Hi Hanjun,

On Thu, 2014-07-24 at 21:00 +0800, Hanjun Guo wrote:
> ACPI 5.1 only has two explicit methods to boot up SMP,
> PSCI and Parking protocol, but the Parking protocol is
> only suitable for ARMv7 now, so make PSCI as the only way
> for the SMP boot protocol before some updates for the
> ACPI spec or the Parking protocol spec.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h    |   21 +++++++++++++++
>  arch/arm64/include/asm/cpu_ops.h |    9 ++++++-
>  arch/arm64/include/asm/smp.h     |    2 +-
>  arch/arm64/kernel/acpi.c         |    9 +++++++
>  arch/arm64/kernel/cpu_ops.c      |   52 ++++++++++++++++++++++++++++++++++----
>  arch/arm64/kernel/smp.c          |   29 +++++++++++++++++++--
>  6 files changed, 113 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 5ce85f8..6240327 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -14,6 +14,27 @@
>  
>  /* Basic configuration for ACPI */
>  #ifdef	CONFIG_ACPI

^^ This seems to be a tab (\t) character here, which is a strange thing
for me to see...

> +/*
> + * ACPI 5.1 only has two explicit methods to
> + * boot up SMP, PSCI and Parking protocol,
> + * but the Parking protocol is only defined
> + * for ARMv7 now, so make PSCI as the only
> + * way for the SMP boot protocol before some
> + * updates for the ACPI spec or the Parking
> + * protocol spec.
> + *
> + * This enum is intend to make the boot method
> + * scalable when above updates are happended,
> + * which NOT means to support all of them.
> + */

This comment will become out of date soon (I hope), and it is often the
case that these short term comments are not removed, so I think it
better to put this kind of note into the commit message, not the code.

> +enum acpi_smp_boot_protocol {
> +	ACPI_SMP_BOOT_PSCI,
> +	ACPI_SMP_BOOT_PARKING_PROTOCOL,
> +	ACPI_SMP_BOOT_PROTOCOL_MAX
> +};
> +
> +enum acpi_smp_boot_protocol smp_boot_protocol(void);
> +
>  extern int acpi_disabled;
>  extern int acpi_noirq;
>  extern int acpi_pci_disabled;
> diff --git a/arch/arm64/include/asm/cpu_ops.h b/arch/arm64/include/asm/cpu_ops.h
> index d7b4b38..2a7c6fd 100644
> --- a/arch/arm64/include/asm/cpu_ops.h
> +++ b/arch/arm64/include/asm/cpu_ops.h
> @@ -61,7 +61,14 @@ struct cpu_operations {
>  };
>  
>  extern const struct cpu_operations *cpu_ops[NR_CPUS];
> -extern int __init cpu_read_ops(struct device_node *dn, int cpu);
> +extern int __init cpu_of_read_ops(struct device_node *dn, int cpu);
> +
> +#ifdef CONFIG_ACPI
> +extern int __init cpu_acpi_read_ops(int cpu);
> +#else
> +static inline int __init cpu_acpi_read_ops(int cpu) { return -ENODEV; }
> +#endif

This looks messy and not scalable for new enable methods.  It
seems a better way is to retain cpu_read_ops() and its functionality,
which is to return the proper enable method for that cpu in a generic
way.

Is there some reason you can't integrate acpi into the existing
cpu_ops and need to make this completely parallel method?

>  extern void __init cpu_read_bootcpu_ops(void);
>  
>  #endif /* ifndef __ASM_CPU_OPS_H */
> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
> index a498f2c..a5cea56 100644
> --- a/arch/arm64/include/asm/smp.h
> +++ b/arch/arm64/include/asm/smp.h
> @@ -39,7 +39,7 @@ extern void show_ipi_list(struct seq_file *p, int prec);
>  extern void handle_IPI(int ipinr, struct pt_regs *regs);
>  
>  /*
> - * Setup the set of possible CPUs (via set_cpu_possible)
> + * Platform specific SMP operations
>   */
>  extern void smp_init_cpus(void);
>  
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index ff0f6a0..2af6662 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
>  	return 0;
>  }
>  
> +/* Protocol to bring up secondary CPUs */
> +enum acpi_smp_boot_protocol smp_boot_protocol(void)
> +{
> +	if (acpi_psci_present)
> +		return ACPI_SMP_BOOT_PSCI;
> +	else
> +		return ACPI_SMP_BOOT_PARKING_PROTOCOL;
> +}
> +
>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
>  {
>  	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
> index d62d12f..4d9b3cf 100644
> --- a/arch/arm64/kernel/cpu_ops.c
> +++ b/arch/arm64/kernel/cpu_ops.c
> @@ -16,11 +16,13 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> -#include <asm/cpu_ops.h>
> -#include <asm/smp_plat.h>
>  #include <linux/errno.h>
>  #include <linux/of.h>
>  #include <linux/string.h>
> +#include <linux/acpi.h>
> +
> +#include <asm/cpu_ops.h>
> +#include <asm/smp_plat.h>
>  
>  extern const struct cpu_operations smp_spin_table_ops;
>  extern const struct cpu_operations cpu_psci_ops;
> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
>  /*
>   * Read a cpu's enable method from the device tree and record it in cpu_ops.
>   */
> -int __init cpu_read_ops(struct device_node *dn, int cpu)
> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
>  {
>  	const char *enable_method = of_get_property(dn, "enable-method", NULL);
>  	if (!enable_method) {
> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
>  	return 0;
>  }
>  
> +#ifdef CONFIG_ACPI
> +/*
> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
> + */
> +int __init cpu_acpi_read_ops(int cpu)
> +{
> +	/*
> +	 * For ACPI 5.1, only two kind of methods are provided,
> +	 * Parking protocol and PSCI, but Parking protocol is
> +	 * used on ARMv7 only, so make PSCI as the only method
> +	 * for SMP initialization before the ACPI spec or Parking
> +	 * protocol spec is updated.
> +	 */

Again, this comment will get old fast (I hope).

> +	switch (smp_boot_protocol()) {
> +	case ACPI_SMP_BOOT_PSCI:
> +		cpu_ops[cpu] = cpu_get_ops("psci");
> +		break;
> +	case ACPI_SMP_BOOT_PARKING_PROTOCOL:
> +	default:
> +		cpu_ops[cpu] = NULL;
> +		break;
> +	}
> +
> +	if (!cpu_ops[cpu]) {
> +		pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
> +			cpu);
> +		return -EOPNOTSUPP;
> +	}
> +
> +	return 0;
> +}
> +#endif
> +
>  void __init cpu_read_bootcpu_ops(void)
>  {
> -	struct device_node *dn = of_get_cpu_node(0, NULL);
> +	struct device_node *dn;
> +
> +	if (!acpi_disabled) {
> +		cpu_acpi_read_ops(0);
> +		return;
> +	}
> +
> +	dn = of_get_cpu_node(0, NULL);
>  	if (!dn) {
>  		pr_err("Failed to find device node for boot cpu\n");
>  		return;
>  	}
> -	cpu_read_ops(dn, 0);
> +	cpu_of_read_ops(dn, 0);
>  }
> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> index 8f1d37c..cb71662 100644
> --- a/arch/arm64/kernel/smp.c
> +++ b/arch/arm64/kernel/smp.c
> @@ -315,7 +315,7 @@ static void (*smp_cross_call)(const struct cpumask *, unsigned int);
>   * cpu logical map array containing MPIDR values related to logical
>   * cpus. Assumes that cpu_logical_map(0) has already been initialized.
>   */
> -void __init smp_init_cpus(void)
> +static void __init of_smp_init_cpus(void)
>  {
>  	struct device_node *dn = NULL;
>  	unsigned int i, cpu = 1;
> @@ -387,7 +387,7 @@ void __init smp_init_cpus(void)
>  		if (cpu >= NR_CPUS)
>  			goto next;
>  
> -		if (cpu_read_ops(dn, cpu) != 0)
> +		if (cpu_of_read_ops(dn, cpu) != 0)
>  			goto next;
>  
>  		if (cpu_ops[cpu]->cpu_init(dn, cpu))
> @@ -418,6 +418,31 @@ next:
>  			set_cpu_possible(i, true);
>  }
>  
> +/*
> + * In ACPI mode, the cpu possible map was enumerated before SMP
> + * initialization when MADT table was parsed, so we can get the
> + * possible map here to initialize CPUs.
> + */
> +static void __init acpi_smp_init_cpus(void)
> +{
> +	int cpu;
> +
> +	for_each_possible_cpu(cpu) {
> +		if (cpu_acpi_read_ops(cpu) != 0)
> +			continue;
> +
> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
> +	}
> +}
> +
> +void __init smp_init_cpus(void)
> +{
> +	if (acpi_disabled)
> +		of_smp_init_cpus();
> +	else
> +		acpi_smp_init_cpus();
> +}

This is the same as cpu_ops, is acpi so special we need a completely
parallel method of initializing secondary cpus?

-Geoff

Re: [PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Hanjun Guo]

On 2014-7-29 2:51, Sudeep Holla wrote:
> On 24/07/14 14:00, Hanjun Guo wrote:
>> arch_fix_phys_package_id() will be called in ACPI core to use
>> the slot number provided by ACPI to update the physical package
>> id, then we can get the right value in the "physical id" field
>> of /proc/cpuinfo.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   arch/arm64/include/asm/topology.h |    2 ++
>>   arch/arm64/kernel/topology.c      |   14 ++++++++++++++
>>   2 files changed, 16 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/topology.h
>> b/arch/arm64/include/asm/topology.h
>> index 7ebcd31..2b216d4 100644
>> --- a/arch/arm64/include/asm/topology.h
>> +++ b/arch/arm64/include/asm/topology.h
>> @@ -23,11 +23,13 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
>>   void init_cpu_topology(void);
>>   void store_cpu_topology(unsigned int cpuid);
>>   const struct cpumask *cpu_coregroup_mask(int cpu);
>> +void arch_fix_phys_package_id(int num, u32 slot);
>>
>>   #else
>>
>>   static inline void init_cpu_topology(void) { }
>>   static inline void store_cpu_topology(unsigned int cpuid) { }
>> +static inline void arch_fix_phys_package_id(int num, u32 slot) { }
>>
>>   #endif
>>
>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
>> index 43514f9..c547885 100644
>> --- a/arch/arm64/kernel/topology.c
>> +++ b/arch/arm64/kernel/topology.c
>> @@ -281,3 +281,17 @@ void __init init_cpu_topology(void)
>>       if (parse_dt_topology())
>>           reset_cpu_topology();
>>   }
>> +
>> +/*
>> + * Use the CPU slot number provided by ACPI to update the physical
>> + * package id when cpuid_topo->cluster_id is not available, then we
>> + * can get the right value in the "physical id" field of /proc/cpuinfo.
>> + */
> 
> We don't have "physical id" field in /proc/cpuinfo on ARM64.

I'm just curious, if there are two or more CPU (SoC) chips and connected
into one system, how to tell one SoC from another?

> 
>> +void arch_fix_phys_package_id(int num, u32 slot)
>> +{
>> +    struct cpu_topology *cpuid_topo = &cpu_topology[num];
>> +
>> +    if (cpuid_topo->cluster_id == -1)
>> +        cpuid_topo->cluster_id = slot;
>> +}
>> +EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
>>
> 
> The ACPI core uses this function to set the package id as read from
> _SUN from the device. As per spec, _SUN is used by OSPM UI to identify
> slots for the user. Do we know how will this be used on ARM64 ?
> 
> If not clear at this time, better to define it or keep it empty. I see
> even x86 does nothing in that function.

I'm ok with it, will introduce a stub function for it and remove this patch.

Thanks
Hanjun

Re: [PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Hanjun Guo]

On 2014-7-29 2:51, Sudeep Holla wrote:
> On 24/07/14 14:00, Hanjun Guo wrote:
>> arch_fix_phys_package_id() will be called in ACPI core to use
>> the slot number provided by ACPI to update the physical package
>> id, then we can get the right value in the "physical id" field
>> of /proc/cpuinfo.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   arch/arm64/include/asm/topology.h |    2 ++
>>   arch/arm64/kernel/topology.c      |   14 ++++++++++++++
>>   2 files changed, 16 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/topology.h
>> b/arch/arm64/include/asm/topology.h
>> index 7ebcd31..2b216d4 100644
>> --- a/arch/arm64/include/asm/topology.h
>> +++ b/arch/arm64/include/asm/topology.h
>> @@ -23,11 +23,13 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
>>   void init_cpu_topology(void);
>>   void store_cpu_topology(unsigned int cpuid);
>>   const struct cpumask *cpu_coregroup_mask(int cpu);
>> +void arch_fix_phys_package_id(int num, u32 slot);
>>
>>   #else
>>
>>   static inline void init_cpu_topology(void) { }
>>   static inline void store_cpu_topology(unsigned int cpuid) { }
>> +static inline void arch_fix_phys_package_id(int num, u32 slot) { }
>>
>>   #endif
>>
>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
>> index 43514f9..c547885 100644
>> --- a/arch/arm64/kernel/topology.c
>> +++ b/arch/arm64/kernel/topology.c
>> @@ -281,3 +281,17 @@ void __init init_cpu_topology(void)
>>       if (parse_dt_topology())
>>           reset_cpu_topology();
>>   }
>> +
>> +/*
>> + * Use the CPU slot number provided by ACPI to update the physical
>> + * package id when cpuid_topo->cluster_id is not available, then we
>> + * can get the right value in the "physical id" field of /proc/cpuinfo.
>> + */
> 
> We don't have "physical id" field in /proc/cpuinfo on ARM64.

I'm just curious, if there are two or more CPU (SoC) chips and connected
into one system, how to tell one SoC from another?

> 
>> +void arch_fix_phys_package_id(int num, u32 slot)
>> +{
>> +    struct cpu_topology *cpuid_topo = &cpu_topology[num];
>> +
>> +    if (cpuid_topo->cluster_id == -1)
>> +        cpuid_topo->cluster_id = slot;
>> +}
>> +EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
>>
> 
> The ACPI core uses this function to set the package id as read from
> _SUN from the device. As per spec, _SUN is used by OSPM UI to identify
> slots for the user. Do we know how will this be used on ARM64 ?
> 
> If not clear at this time, better to define it or keep it empty. I see
> even x86 does nothing in that function.

I'm ok with it, will introduce a stub function for it and remove this patch.

Thanks
Hanjun

[PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Hanjun Guo]

On 2014-7-29 2:51, Sudeep Holla wrote:
> On 24/07/14 14:00, Hanjun Guo wrote:
>> arch_fix_phys_package_id() will be called in ACPI core to use
>> the slot number provided by ACPI to update the physical package
>> id, then we can get the right value in the "physical id" field
>> of /proc/cpuinfo.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> ---
>>   arch/arm64/include/asm/topology.h |    2 ++
>>   arch/arm64/kernel/topology.c      |   14 ++++++++++++++
>>   2 files changed, 16 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/topology.h
>> b/arch/arm64/include/asm/topology.h
>> index 7ebcd31..2b216d4 100644
>> --- a/arch/arm64/include/asm/topology.h
>> +++ b/arch/arm64/include/asm/topology.h
>> @@ -23,11 +23,13 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
>>   void init_cpu_topology(void);
>>   void store_cpu_topology(unsigned int cpuid);
>>   const struct cpumask *cpu_coregroup_mask(int cpu);
>> +void arch_fix_phys_package_id(int num, u32 slot);
>>
>>   #else
>>
>>   static inline void init_cpu_topology(void) { }
>>   static inline void store_cpu_topology(unsigned int cpuid) { }
>> +static inline void arch_fix_phys_package_id(int num, u32 slot) { }
>>
>>   #endif
>>
>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
>> index 43514f9..c547885 100644
>> --- a/arch/arm64/kernel/topology.c
>> +++ b/arch/arm64/kernel/topology.c
>> @@ -281,3 +281,17 @@ void __init init_cpu_topology(void)
>>       if (parse_dt_topology())
>>           reset_cpu_topology();
>>   }
>> +
>> +/*
>> + * Use the CPU slot number provided by ACPI to update the physical
>> + * package id when cpuid_topo->cluster_id is not available, then we
>> + * can get the right value in the "physical id" field of /proc/cpuinfo.
>> + */
> 
> We don't have "physical id" field in /proc/cpuinfo on ARM64.

I'm just curious, if there are two or more CPU (SoC) chips and connected
into one system, how to tell one SoC from another?

> 
>> +void arch_fix_phys_package_id(int num, u32 slot)
>> +{
>> +    struct cpu_topology *cpuid_topo = &cpu_topology[num];
>> +
>> +    if (cpuid_topo->cluster_id == -1)
>> +        cpuid_topo->cluster_id = slot;
>> +}
>> +EXPORT_SYMBOL_GPL(arch_fix_phys_package_id);
>>
> 
> The ACPI core uses this function to set the package id as read from
> _SUN from the device. As per spec, _SUN is used by OSPM UI to identify
> slots for the user. Do we know how will this be used on ARM64 ?
> 
> If not clear at this time, better to define it or keep it empty. I see
> even x86 does nothing in that function.

I'm ok with it, will introduce a stub function for it and remove this patch.

Thanks
Hanjun

Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

On 2014-8-1 2:52, Geoff Levand wrote:
> Hi Hanjun,

Hi Geoff,

> 
> On Thu, 2014-07-24 at 21:00 +0800, Hanjun Guo wrote:
>> ACPI 5.1 only has two explicit methods to boot up SMP,
>> PSCI and Parking protocol, but the Parking protocol is
>> only suitable for ARMv7 now, so make PSCI as the only way
>> for the SMP boot protocol before some updates for the
>> ACPI spec or the Parking protocol spec.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> ---
>>  arch/arm64/include/asm/acpi.h    |   21 +++++++++++++++
>>  arch/arm64/include/asm/cpu_ops.h |    9 ++++++-
>>  arch/arm64/include/asm/smp.h     |    2 +-
>>  arch/arm64/kernel/acpi.c         |    9 +++++++
>>  arch/arm64/kernel/cpu_ops.c      |   52 ++++++++++++++++++++++++++++++++++----
>>  arch/arm64/kernel/smp.c          |   29 +++++++++++++++++++--
>>  6 files changed, 113 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 5ce85f8..6240327 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -14,6 +14,27 @@
>>  
>>  /* Basic configuration for ACPI */
>>  #ifdef	CONFIG_ACPI
> 
> ^^ This seems to be a tab (\t) character here, which is a strange thing
> for me to see...

Yes, seems to be a tab but actually not :)

> 
>> +/*
>> + * ACPI 5.1 only has two explicit methods to
>> + * boot up SMP, PSCI and Parking protocol,
>> + * but the Parking protocol is only defined
>> + * for ARMv7 now, so make PSCI as the only
>> + * way for the SMP boot protocol before some
>> + * updates for the ACPI spec or the Parking
>> + * protocol spec.
>> + *
>> + * This enum is intend to make the boot method
>> + * scalable when above updates are happended,
>> + * which NOT means to support all of them.
>> + */
> 
> This comment will become out of date soon (I hope), and it is often the
> case that these short term comments are not removed, so I think it
> better to put this kind of note into the commit message, not the code.

This will need some time, the spec is not ready and we still need more time
for people to implement Parking protocol, I think we can keep this comments
until Parking protocol driver is ready, and update them at that time.

> 
>> +enum acpi_smp_boot_protocol {
>> +	ACPI_SMP_BOOT_PSCI,
>> +	ACPI_SMP_BOOT_PARKING_PROTOCOL,
>> +	ACPI_SMP_BOOT_PROTOCOL_MAX
>> +};
>> +
>> +enum acpi_smp_boot_protocol smp_boot_protocol(void);
>> +
>>  extern int acpi_disabled;
>>  extern int acpi_noirq;
>>  extern int acpi_pci_disabled;
>> diff --git a/arch/arm64/include/asm/cpu_ops.h b/arch/arm64/include/asm/cpu_ops.h
>> index d7b4b38..2a7c6fd 100644
>> --- a/arch/arm64/include/asm/cpu_ops.h
>> +++ b/arch/arm64/include/asm/cpu_ops.h
>> @@ -61,7 +61,14 @@ struct cpu_operations {
>>  };
>>  
>>  extern const struct cpu_operations *cpu_ops[NR_CPUS];
>> -extern int __init cpu_read_ops(struct device_node *dn, int cpu);
>> +extern int __init cpu_of_read_ops(struct device_node *dn, int cpu);
>> +
>> +#ifdef CONFIG_ACPI
>> +extern int __init cpu_acpi_read_ops(int cpu);
>> +#else
>> +static inline int __init cpu_acpi_read_ops(int cpu) { return -ENODEV; }
>> +#endif
> 
> This looks messy and not scalable for new enable methods.  It
> seems a better way is to retain cpu_read_ops() and its functionality,
> which is to return the proper enable method for that cpu in a generic
> way.
> 
> Is there some reason you can't integrate acpi into the existing
> cpu_ops and need to make this completely parallel method?
> 
>>  extern void __init cpu_read_bootcpu_ops(void);
>>  
>>  #endif /* ifndef __ASM_CPU_OPS_H */
>> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
>> index a498f2c..a5cea56 100644
>> --- a/arch/arm64/include/asm/smp.h
>> +++ b/arch/arm64/include/asm/smp.h
>> @@ -39,7 +39,7 @@ extern void show_ipi_list(struct seq_file *p, int prec);
>>  extern void handle_IPI(int ipinr, struct pt_regs *regs);
>>  
>>  /*
>> - * Setup the set of possible CPUs (via set_cpu_possible)
>> + * Platform specific SMP operations
>>   */
>>  extern void smp_init_cpus(void);
>>  
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index ff0f6a0..2af6662 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
>>  	return 0;
>>  }
>>  
>> +/* Protocol to bring up secondary CPUs */
>> +enum acpi_smp_boot_protocol smp_boot_protocol(void)
>> +{
>> +	if (acpi_psci_present)
>> +		return ACPI_SMP_BOOT_PSCI;
>> +	else
>> +		return ACPI_SMP_BOOT_PARKING_PROTOCOL;
>> +}
>> +
>>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
>>  {
>>  	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
>> index d62d12f..4d9b3cf 100644
>> --- a/arch/arm64/kernel/cpu_ops.c
>> +++ b/arch/arm64/kernel/cpu_ops.c
>> @@ -16,11 +16,13 @@
>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>   */
>>  
>> -#include <asm/cpu_ops.h>
>> -#include <asm/smp_plat.h>
>>  #include <linux/errno.h>
>>  #include <linux/of.h>
>>  #include <linux/string.h>
>> +#include <linux/acpi.h>
>> +
>> +#include <asm/cpu_ops.h>
>> +#include <asm/smp_plat.h>
>>  
>>  extern const struct cpu_operations smp_spin_table_ops;
>>  extern const struct cpu_operations cpu_psci_ops;
>> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
>>  /*
>>   * Read a cpu's enable method from the device tree and record it in cpu_ops.
>>   */
>> -int __init cpu_read_ops(struct device_node *dn, int cpu)
>> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
>>  {
>>  	const char *enable_method = of_get_property(dn, "enable-method", NULL);
>>  	if (!enable_method) {
>> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
>>  	return 0;
>>  }
>>  
>> +#ifdef CONFIG_ACPI
>> +/*
>> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
>> + */
>> +int __init cpu_acpi_read_ops(int cpu)
>> +{
>> +	/*
>> +	 * For ACPI 5.1, only two kind of methods are provided,
>> +	 * Parking protocol and PSCI, but Parking protocol is
>> +	 * used on ARMv7 only, so make PSCI as the only method
>> +	 * for SMP initialization before the ACPI spec or Parking
>> +	 * protocol spec is updated.
>> +	 */
> 
> Again, this comment will get old fast (I hope).
> 
>> +	switch (smp_boot_protocol()) {
>> +	case ACPI_SMP_BOOT_PSCI:
>> +		cpu_ops[cpu] = cpu_get_ops("psci");
>> +		break;
>> +	case ACPI_SMP_BOOT_PARKING_PROTOCOL:
>> +	default:
>> +		cpu_ops[cpu] = NULL;
>> +		break;
>> +	}
>> +
>> +	if (!cpu_ops[cpu]) {
>> +		pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
>> +			cpu);
>> +		return -EOPNOTSUPP;
>> +	}
>> +
>> +	return 0;
>> +}
>> +#endif
>> +
>>  void __init cpu_read_bootcpu_ops(void)
>>  {
>> -	struct device_node *dn = of_get_cpu_node(0, NULL);
>> +	struct device_node *dn;
>> +
>> +	if (!acpi_disabled) {
>> +		cpu_acpi_read_ops(0);
>> +		return;
>> +	}
>> +
>> +	dn = of_get_cpu_node(0, NULL);
>>  	if (!dn) {
>>  		pr_err("Failed to find device node for boot cpu\n");
>>  		return;
>>  	}
>> -	cpu_read_ops(dn, 0);
>> +	cpu_of_read_ops(dn, 0);
>>  }
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index 8f1d37c..cb71662 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -315,7 +315,7 @@ static void (*smp_cross_call)(const struct cpumask *, unsigned int);
>>   * cpu logical map array containing MPIDR values related to logical
>>   * cpus. Assumes that cpu_logical_map(0) has already been initialized.
>>   */
>> -void __init smp_init_cpus(void)
>> +static void __init of_smp_init_cpus(void)
>>  {
>>  	struct device_node *dn = NULL;
>>  	unsigned int i, cpu = 1;
>> @@ -387,7 +387,7 @@ void __init smp_init_cpus(void)
>>  		if (cpu >= NR_CPUS)
>>  			goto next;
>>  
>> -		if (cpu_read_ops(dn, cpu) != 0)
>> +		if (cpu_of_read_ops(dn, cpu) != 0)
>>  			goto next;
>>  
>>  		if (cpu_ops[cpu]->cpu_init(dn, cpu))
>> @@ -418,6 +418,31 @@ next:
>>  			set_cpu_possible(i, true);
>>  }
>>  
>> +/*
>> + * In ACPI mode, the cpu possible map was enumerated before SMP
>> + * initialization when MADT table was parsed, so we can get the
>> + * possible map here to initialize CPUs.
>> + */
>> +static void __init acpi_smp_init_cpus(void)
>> +{
>> +	int cpu;
>> +
>> +	for_each_possible_cpu(cpu) {
>> +		if (cpu_acpi_read_ops(cpu) != 0)
>> +			continue;
>> +
>> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
>> +	}
>> +}
>> +
>> +void __init smp_init_cpus(void)
>> +{
>> +	if (acpi_disabled)
>> +		of_smp_init_cpus();
>> +	else
>> +		acpi_smp_init_cpus();
>> +}
> 
> This is the same as cpu_ops, is acpi so special we need a completely
> parallel method of initializing secondary cpus?

Good point, Olof suggested the same here, I'm working on it and try to
implement the code as you suggested, if I can't I will comment on it for
the reasons that why I can't make it.

Thanks
Hanjun

Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

On 2014-8-1 2:52, Geoff Levand wrote:
> Hi Hanjun,

Hi Geoff,

> 
> On Thu, 2014-07-24 at 21:00 +0800, Hanjun Guo wrote:
>> ACPI 5.1 only has two explicit methods to boot up SMP,
>> PSCI and Parking protocol, but the Parking protocol is
>> only suitable for ARMv7 now, so make PSCI as the only way
>> for the SMP boot protocol before some updates for the
>> ACPI spec or the Parking protocol spec.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> ---
>>  arch/arm64/include/asm/acpi.h    |   21 +++++++++++++++
>>  arch/arm64/include/asm/cpu_ops.h |    9 ++++++-
>>  arch/arm64/include/asm/smp.h     |    2 +-
>>  arch/arm64/kernel/acpi.c         |    9 +++++++
>>  arch/arm64/kernel/cpu_ops.c      |   52 ++++++++++++++++++++++++++++++++++----
>>  arch/arm64/kernel/smp.c          |   29 +++++++++++++++++++--
>>  6 files changed, 113 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 5ce85f8..6240327 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -14,6 +14,27 @@
>>  
>>  /* Basic configuration for ACPI */
>>  #ifdef	CONFIG_ACPI
> 
> ^^ This seems to be a tab (\t) character here, which is a strange thing
> for me to see...

Yes, seems to be a tab but actually not :)

> 
>> +/*
>> + * ACPI 5.1 only has two explicit methods to
>> + * boot up SMP, PSCI and Parking protocol,
>> + * but the Parking protocol is only defined
>> + * for ARMv7 now, so make PSCI as the only
>> + * way for the SMP boot protocol before some
>> + * updates for the ACPI spec or the Parking
>> + * protocol spec.
>> + *
>> + * This enum is intend to make the boot method
>> + * scalable when above updates are happended,
>> + * which NOT means to support all of them.
>> + */
> 
> This comment will become out of date soon (I hope), and it is often the
> case that these short term comments are not removed, so I think it
> better to put this kind of note into the commit message, not the code.

This will need some time, the spec is not ready and we still need more time
for people to implement Parking protocol, I think we can keep this comments
until Parking protocol driver is ready, and update them at that time.

> 
>> +enum acpi_smp_boot_protocol {
>> +	ACPI_SMP_BOOT_PSCI,
>> +	ACPI_SMP_BOOT_PARKING_PROTOCOL,
>> +	ACPI_SMP_BOOT_PROTOCOL_MAX
>> +};
>> +
>> +enum acpi_smp_boot_protocol smp_boot_protocol(void);
>> +
>>  extern int acpi_disabled;
>>  extern int acpi_noirq;
>>  extern int acpi_pci_disabled;
>> diff --git a/arch/arm64/include/asm/cpu_ops.h b/arch/arm64/include/asm/cpu_ops.h
>> index d7b4b38..2a7c6fd 100644
>> --- a/arch/arm64/include/asm/cpu_ops.h
>> +++ b/arch/arm64/include/asm/cpu_ops.h
>> @@ -61,7 +61,14 @@ struct cpu_operations {
>>  };
>>  
>>  extern const struct cpu_operations *cpu_ops[NR_CPUS];
>> -extern int __init cpu_read_ops(struct device_node *dn, int cpu);
>> +extern int __init cpu_of_read_ops(struct device_node *dn, int cpu);
>> +
>> +#ifdef CONFIG_ACPI
>> +extern int __init cpu_acpi_read_ops(int cpu);
>> +#else
>> +static inline int __init cpu_acpi_read_ops(int cpu) { return -ENODEV; }
>> +#endif
> 
> This looks messy and not scalable for new enable methods.  It
> seems a better way is to retain cpu_read_ops() and its functionality,
> which is to return the proper enable method for that cpu in a generic
> way.
> 
> Is there some reason you can't integrate acpi into the existing
> cpu_ops and need to make this completely parallel method?
> 
>>  extern void __init cpu_read_bootcpu_ops(void);
>>  
>>  #endif /* ifndef __ASM_CPU_OPS_H */
>> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
>> index a498f2c..a5cea56 100644
>> --- a/arch/arm64/include/asm/smp.h
>> +++ b/arch/arm64/include/asm/smp.h
>> @@ -39,7 +39,7 @@ extern void show_ipi_list(struct seq_file *p, int prec);
>>  extern void handle_IPI(int ipinr, struct pt_regs *regs);
>>  
>>  /*
>> - * Setup the set of possible CPUs (via set_cpu_possible)
>> + * Platform specific SMP operations
>>   */
>>  extern void smp_init_cpus(void);
>>  
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index ff0f6a0..2af6662 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
>>  	return 0;
>>  }
>>  
>> +/* Protocol to bring up secondary CPUs */
>> +enum acpi_smp_boot_protocol smp_boot_protocol(void)
>> +{
>> +	if (acpi_psci_present)
>> +		return ACPI_SMP_BOOT_PSCI;
>> +	else
>> +		return ACPI_SMP_BOOT_PARKING_PROTOCOL;
>> +}
>> +
>>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
>>  {
>>  	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
>> index d62d12f..4d9b3cf 100644
>> --- a/arch/arm64/kernel/cpu_ops.c
>> +++ b/arch/arm64/kernel/cpu_ops.c
>> @@ -16,11 +16,13 @@
>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>   */
>>  
>> -#include <asm/cpu_ops.h>
>> -#include <asm/smp_plat.h>
>>  #include <linux/errno.h>
>>  #include <linux/of.h>
>>  #include <linux/string.h>
>> +#include <linux/acpi.h>
>> +
>> +#include <asm/cpu_ops.h>
>> +#include <asm/smp_plat.h>
>>  
>>  extern const struct cpu_operations smp_spin_table_ops;
>>  extern const struct cpu_operations cpu_psci_ops;
>> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
>>  /*
>>   * Read a cpu's enable method from the device tree and record it in cpu_ops.
>>   */
>> -int __init cpu_read_ops(struct device_node *dn, int cpu)
>> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
>>  {
>>  	const char *enable_method = of_get_property(dn, "enable-method", NULL);
>>  	if (!enable_method) {
>> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
>>  	return 0;
>>  }
>>  
>> +#ifdef CONFIG_ACPI
>> +/*
>> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
>> + */
>> +int __init cpu_acpi_read_ops(int cpu)
>> +{
>> +	/*
>> +	 * For ACPI 5.1, only two kind of methods are provided,
>> +	 * Parking protocol and PSCI, but Parking protocol is
>> +	 * used on ARMv7 only, so make PSCI as the only method
>> +	 * for SMP initialization before the ACPI spec or Parking
>> +	 * protocol spec is updated.
>> +	 */
> 
> Again, this comment will get old fast (I hope).
> 
>> +	switch (smp_boot_protocol()) {
>> +	case ACPI_SMP_BOOT_PSCI:
>> +		cpu_ops[cpu] = cpu_get_ops("psci");
>> +		break;
>> +	case ACPI_SMP_BOOT_PARKING_PROTOCOL:
>> +	default:
>> +		cpu_ops[cpu] = NULL;
>> +		break;
>> +	}
>> +
>> +	if (!cpu_ops[cpu]) {
>> +		pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
>> +			cpu);
>> +		return -EOPNOTSUPP;
>> +	}
>> +
>> +	return 0;
>> +}
>> +#endif
>> +
>>  void __init cpu_read_bootcpu_ops(void)
>>  {
>> -	struct device_node *dn = of_get_cpu_node(0, NULL);
>> +	struct device_node *dn;
>> +
>> +	if (!acpi_disabled) {
>> +		cpu_acpi_read_ops(0);
>> +		return;
>> +	}
>> +
>> +	dn = of_get_cpu_node(0, NULL);
>>  	if (!dn) {
>>  		pr_err("Failed to find device node for boot cpu\n");
>>  		return;
>>  	}
>> -	cpu_read_ops(dn, 0);
>> +	cpu_of_read_ops(dn, 0);
>>  }
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index 8f1d37c..cb71662 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -315,7 +315,7 @@ static void (*smp_cross_call)(const struct cpumask *, unsigned int);
>>   * cpu logical map array containing MPIDR values related to logical
>>   * cpus. Assumes that cpu_logical_map(0) has already been initialized.
>>   */
>> -void __init smp_init_cpus(void)
>> +static void __init of_smp_init_cpus(void)
>>  {
>>  	struct device_node *dn = NULL;
>>  	unsigned int i, cpu = 1;
>> @@ -387,7 +387,7 @@ void __init smp_init_cpus(void)
>>  		if (cpu >= NR_CPUS)
>>  			goto next;
>>  
>> -		if (cpu_read_ops(dn, cpu) != 0)
>> +		if (cpu_of_read_ops(dn, cpu) != 0)
>>  			goto next;
>>  
>>  		if (cpu_ops[cpu]->cpu_init(dn, cpu))
>> @@ -418,6 +418,31 @@ next:
>>  			set_cpu_possible(i, true);
>>  }
>>  
>> +/*
>> + * In ACPI mode, the cpu possible map was enumerated before SMP
>> + * initialization when MADT table was parsed, so we can get the
>> + * possible map here to initialize CPUs.
>> + */
>> +static void __init acpi_smp_init_cpus(void)
>> +{
>> +	int cpu;
>> +
>> +	for_each_possible_cpu(cpu) {
>> +		if (cpu_acpi_read_ops(cpu) != 0)
>> +			continue;
>> +
>> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
>> +	}
>> +}
>> +
>> +void __init smp_init_cpus(void)
>> +{
>> +	if (acpi_disabled)
>> +		of_smp_init_cpus();
>> +	else
>> +		acpi_smp_init_cpus();
>> +}
> 
> This is the same as cpu_ops, is acpi so special we need a completely
> parallel method of initializing secondary cpus?

Good point, Olof suggested the same here, I'm working on it and try to
implement the code as you suggested, if I can't I will comment on it for
the reasons that why I can't make it.

Thanks
Hanjun

[PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

On 2014-8-1 2:52, Geoff Levand wrote:
> Hi Hanjun,

Hi Geoff,

> 
> On Thu, 2014-07-24 at 21:00 +0800, Hanjun Guo wrote:
>> ACPI 5.1 only has two explicit methods to boot up SMP,
>> PSCI and Parking protocol, but the Parking protocol is
>> only suitable for ARMv7 now, so make PSCI as the only way
>> for the SMP boot protocol before some updates for the
>> ACPI spec or the Parking protocol spec.
>>
>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>> ---
>>  arch/arm64/include/asm/acpi.h    |   21 +++++++++++++++
>>  arch/arm64/include/asm/cpu_ops.h |    9 ++++++-
>>  arch/arm64/include/asm/smp.h     |    2 +-
>>  arch/arm64/kernel/acpi.c         |    9 +++++++
>>  arch/arm64/kernel/cpu_ops.c      |   52 ++++++++++++++++++++++++++++++++++----
>>  arch/arm64/kernel/smp.c          |   29 +++++++++++++++++++--
>>  6 files changed, 113 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 5ce85f8..6240327 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -14,6 +14,27 @@
>>  
>>  /* Basic configuration for ACPI */
>>  #ifdef	CONFIG_ACPI
> 
> ^^ This seems to be a tab (\t) character here, which is a strange thing
> for me to see...

Yes, seems to be a tab but actually not :)

> 
>> +/*
>> + * ACPI 5.1 only has two explicit methods to
>> + * boot up SMP, PSCI and Parking protocol,
>> + * but the Parking protocol is only defined
>> + * for ARMv7 now, so make PSCI as the only
>> + * way for the SMP boot protocol before some
>> + * updates for the ACPI spec or the Parking
>> + * protocol spec.
>> + *
>> + * This enum is intend to make the boot method
>> + * scalable when above updates are happended,
>> + * which NOT means to support all of them.
>> + */
> 
> This comment will become out of date soon (I hope), and it is often the
> case that these short term comments are not removed, so I think it
> better to put this kind of note into the commit message, not the code.

This will need some time, the spec is not ready and we still need more time
for people to implement Parking protocol, I think we can keep this comments
until Parking protocol driver is ready, and update them at that time.

> 
>> +enum acpi_smp_boot_protocol {
>> +	ACPI_SMP_BOOT_PSCI,
>> +	ACPI_SMP_BOOT_PARKING_PROTOCOL,
>> +	ACPI_SMP_BOOT_PROTOCOL_MAX
>> +};
>> +
>> +enum acpi_smp_boot_protocol smp_boot_protocol(void);
>> +
>>  extern int acpi_disabled;
>>  extern int acpi_noirq;
>>  extern int acpi_pci_disabled;
>> diff --git a/arch/arm64/include/asm/cpu_ops.h b/arch/arm64/include/asm/cpu_ops.h
>> index d7b4b38..2a7c6fd 100644
>> --- a/arch/arm64/include/asm/cpu_ops.h
>> +++ b/arch/arm64/include/asm/cpu_ops.h
>> @@ -61,7 +61,14 @@ struct cpu_operations {
>>  };
>>  
>>  extern const struct cpu_operations *cpu_ops[NR_CPUS];
>> -extern int __init cpu_read_ops(struct device_node *dn, int cpu);
>> +extern int __init cpu_of_read_ops(struct device_node *dn, int cpu);
>> +
>> +#ifdef CONFIG_ACPI
>> +extern int __init cpu_acpi_read_ops(int cpu);
>> +#else
>> +static inline int __init cpu_acpi_read_ops(int cpu) { return -ENODEV; }
>> +#endif
> 
> This looks messy and not scalable for new enable methods.  It
> seems a better way is to retain cpu_read_ops() and its functionality,
> which is to return the proper enable method for that cpu in a generic
> way.
> 
> Is there some reason you can't integrate acpi into the existing
> cpu_ops and need to make this completely parallel method?
> 
>>  extern void __init cpu_read_bootcpu_ops(void);
>>  
>>  #endif /* ifndef __ASM_CPU_OPS_H */
>> diff --git a/arch/arm64/include/asm/smp.h b/arch/arm64/include/asm/smp.h
>> index a498f2c..a5cea56 100644
>> --- a/arch/arm64/include/asm/smp.h
>> +++ b/arch/arm64/include/asm/smp.h
>> @@ -39,7 +39,7 @@ extern void show_ipi_list(struct seq_file *p, int prec);
>>  extern void handle_IPI(int ipinr, struct pt_regs *regs);
>>  
>>  /*
>> - * Setup the set of possible CPUs (via set_cpu_possible)
>> + * Platform specific SMP operations
>>   */
>>  extern void smp_init_cpus(void);
>>  
>> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
>> index ff0f6a0..2af6662 100644
>> --- a/arch/arm64/kernel/acpi.c
>> +++ b/arch/arm64/kernel/acpi.c
>> @@ -184,6 +184,15 @@ static int __init acpi_parse_madt_gic_cpu_interface_entries(void)
>>  	return 0;
>>  }
>>  
>> +/* Protocol to bring up secondary CPUs */
>> +enum acpi_smp_boot_protocol smp_boot_protocol(void)
>> +{
>> +	if (acpi_psci_present)
>> +		return ACPI_SMP_BOOT_PSCI;
>> +	else
>> +		return ACPI_SMP_BOOT_PARKING_PROTOCOL;
>> +}
>> +
>>  static int __init acpi_parse_fadt(struct acpi_table_header *table)
>>  {
>>  	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
>> diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
>> index d62d12f..4d9b3cf 100644
>> --- a/arch/arm64/kernel/cpu_ops.c
>> +++ b/arch/arm64/kernel/cpu_ops.c
>> @@ -16,11 +16,13 @@
>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>   */
>>  
>> -#include <asm/cpu_ops.h>
>> -#include <asm/smp_plat.h>
>>  #include <linux/errno.h>
>>  #include <linux/of.h>
>>  #include <linux/string.h>
>> +#include <linux/acpi.h>
>> +
>> +#include <asm/cpu_ops.h>
>> +#include <asm/smp_plat.h>
>>  
>>  extern const struct cpu_operations smp_spin_table_ops;
>>  extern const struct cpu_operations cpu_psci_ops;
>> @@ -52,7 +54,7 @@ static const struct cpu_operations * __init cpu_get_ops(const char *name)
>>  /*
>>   * Read a cpu's enable method from the device tree and record it in cpu_ops.
>>   */
>> -int __init cpu_read_ops(struct device_node *dn, int cpu)
>> +int __init cpu_of_read_ops(struct device_node *dn, int cpu)
>>  {
>>  	const char *enable_method = of_get_property(dn, "enable-method", NULL);
>>  	if (!enable_method) {
>> @@ -76,12 +78,52 @@ int __init cpu_read_ops(struct device_node *dn, int cpu)
>>  	return 0;
>>  }
>>  
>> +#ifdef CONFIG_ACPI
>> +/*
>> + * Read a cpu's enable method in the ACPI way and record it in cpu_ops.
>> + */
>> +int __init cpu_acpi_read_ops(int cpu)
>> +{
>> +	/*
>> +	 * For ACPI 5.1, only two kind of methods are provided,
>> +	 * Parking protocol and PSCI, but Parking protocol is
>> +	 * used on ARMv7 only, so make PSCI as the only method
>> +	 * for SMP initialization before the ACPI spec or Parking
>> +	 * protocol spec is updated.
>> +	 */
> 
> Again, this comment will get old fast (I hope).
> 
>> +	switch (smp_boot_protocol()) {
>> +	case ACPI_SMP_BOOT_PSCI:
>> +		cpu_ops[cpu] = cpu_get_ops("psci");
>> +		break;
>> +	case ACPI_SMP_BOOT_PARKING_PROTOCOL:
>> +	default:
>> +		cpu_ops[cpu] = NULL;
>> +		break;
>> +	}
>> +
>> +	if (!cpu_ops[cpu]) {
>> +		pr_warn("CPU %d: unsupported enable-method, only PSCI is supported\n",
>> +			cpu);
>> +		return -EOPNOTSUPP;
>> +	}
>> +
>> +	return 0;
>> +}
>> +#endif
>> +
>>  void __init cpu_read_bootcpu_ops(void)
>>  {
>> -	struct device_node *dn = of_get_cpu_node(0, NULL);
>> +	struct device_node *dn;
>> +
>> +	if (!acpi_disabled) {
>> +		cpu_acpi_read_ops(0);
>> +		return;
>> +	}
>> +
>> +	dn = of_get_cpu_node(0, NULL);
>>  	if (!dn) {
>>  		pr_err("Failed to find device node for boot cpu\n");
>>  		return;
>>  	}
>> -	cpu_read_ops(dn, 0);
>> +	cpu_of_read_ops(dn, 0);
>>  }
>> diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
>> index 8f1d37c..cb71662 100644
>> --- a/arch/arm64/kernel/smp.c
>> +++ b/arch/arm64/kernel/smp.c
>> @@ -315,7 +315,7 @@ static void (*smp_cross_call)(const struct cpumask *, unsigned int);
>>   * cpu logical map array containing MPIDR values related to logical
>>   * cpus. Assumes that cpu_logical_map(0) has already been initialized.
>>   */
>> -void __init smp_init_cpus(void)
>> +static void __init of_smp_init_cpus(void)
>>  {
>>  	struct device_node *dn = NULL;
>>  	unsigned int i, cpu = 1;
>> @@ -387,7 +387,7 @@ void __init smp_init_cpus(void)
>>  		if (cpu >= NR_CPUS)
>>  			goto next;
>>  
>> -		if (cpu_read_ops(dn, cpu) != 0)
>> +		if (cpu_of_read_ops(dn, cpu) != 0)
>>  			goto next;
>>  
>>  		if (cpu_ops[cpu]->cpu_init(dn, cpu))
>> @@ -418,6 +418,31 @@ next:
>>  			set_cpu_possible(i, true);
>>  }
>>  
>> +/*
>> + * In ACPI mode, the cpu possible map was enumerated before SMP
>> + * initialization when MADT table was parsed, so we can get the
>> + * possible map here to initialize CPUs.
>> + */
>> +static void __init acpi_smp_init_cpus(void)
>> +{
>> +	int cpu;
>> +
>> +	for_each_possible_cpu(cpu) {
>> +		if (cpu_acpi_read_ops(cpu) != 0)
>> +			continue;
>> +
>> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
>> +	}
>> +}
>> +
>> +void __init smp_init_cpus(void)
>> +{
>> +	if (acpi_disabled)
>> +		of_smp_init_cpus();
>> +	else
>> +		acpi_smp_init_cpus();
>> +}
> 
> This is the same as cpu_ops, is acpi so special we need a completely
> parallel method of initializing secondary cpus?

Good point, Olof suggested the same here, I'm working on it and try to
implement the code as you suggested, if I can't I will comment on it for
the reasons that why I can't make it.

Thanks
Hanjun

Re: [PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Sudeep Holla]

On 01/08/14 07:35, Hanjun Guo wrote:
> On 2014-7-29 2:51, Sudeep Holla wrote:
>> On 24/07/14 14:00, Hanjun Guo wrote:
>>> arch_fix_phys_package_id() will be called in ACPI core to use
>>> the slot number provided by ACPI to update the physical package
>>> id, then we can get the right value in the "physical id" field
>>> of /proc/cpuinfo.
>>>
>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> ---
>>>    arch/arm64/include/asm/topology.h |    2 ++
>>>    arch/arm64/kernel/topology.c      |   14 ++++++++++++++
>>>    2 files changed, 16 insertions(+)
>>>
>>> diff --git a/arch/arm64/include/asm/topology.h
>>> b/arch/arm64/include/asm/topology.h
>>> index 7ebcd31..2b216d4 100644
>>> --- a/arch/arm64/include/asm/topology.h
>>> +++ b/arch/arm64/include/asm/topology.h
>>> @@ -23,11 +23,13 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
>>>    void init_cpu_topology(void);
>>>    void store_cpu_topology(unsigned int cpuid);
>>>    const struct cpumask *cpu_coregroup_mask(int cpu);
>>> +void arch_fix_phys_package_id(int num, u32 slot);
>>>
>>>    #else
>>>
>>>    static inline void init_cpu_topology(void) { }
>>>    static inline void store_cpu_topology(unsigned int cpuid) { }
>>> +static inline void arch_fix_phys_package_id(int num, u32 slot) { }
>>>
>>>    #endif
>>>
>>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
>>> index 43514f9..c547885 100644
>>> --- a/arch/arm64/kernel/topology.c
>>> +++ b/arch/arm64/kernel/topology.c
>>> @@ -281,3 +281,17 @@ void __init init_cpu_topology(void)
>>>        if (parse_dt_topology())
>>>            reset_cpu_topology();
>>>    }
>>> +
>>> +/*
>>> + * Use the CPU slot number provided by ACPI to update the physical
>>> + * package id when cpuid_topo->cluster_id is not available, then we
>>> + * can get the right value in the "physical id" field of /proc/cpuinfo.
>>> + */
>>
>> We don't have "physical id" field in /proc/cpuinfo on ARM64.
>
> I'm just curious, if there are two or more CPU (SoC) chips and connected
> into one system, how to tell one SoC from another?
>

There was some discussion on ARM64 /proc/cpuinfo recently[1]. Even ARM
doesn't have this. IMO we might want to present complete MPIDR in future
if really needed.

Not sure, why we need this "physical id" field as these cpuid topology
is already visible via sysfs explicitly(we really don't need that again
elsewhere ?)

Regards,
Sudeep

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/264390.html

Re: [PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Sudeep Holla]

On 01/08/14 07:35, Hanjun Guo wrote:
> On 2014-7-29 2:51, Sudeep Holla wrote:
>> On 24/07/14 14:00, Hanjun Guo wrote:
>>> arch_fix_phys_package_id() will be called in ACPI core to use
>>> the slot number provided by ACPI to update the physical package
>>> id, then we can get the right value in the "physical id" field
>>> of /proc/cpuinfo.
>>>
>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> ---
>>>    arch/arm64/include/asm/topology.h |    2 ++
>>>    arch/arm64/kernel/topology.c      |   14 ++++++++++++++
>>>    2 files changed, 16 insertions(+)
>>>
>>> diff --git a/arch/arm64/include/asm/topology.h
>>> b/arch/arm64/include/asm/topology.h
>>> index 7ebcd31..2b216d4 100644
>>> --- a/arch/arm64/include/asm/topology.h
>>> +++ b/arch/arm64/include/asm/topology.h
>>> @@ -23,11 +23,13 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
>>>    void init_cpu_topology(void);
>>>    void store_cpu_topology(unsigned int cpuid);
>>>    const struct cpumask *cpu_coregroup_mask(int cpu);
>>> +void arch_fix_phys_package_id(int num, u32 slot);
>>>
>>>    #else
>>>
>>>    static inline void init_cpu_topology(void) { }
>>>    static inline void store_cpu_topology(unsigned int cpuid) { }
>>> +static inline void arch_fix_phys_package_id(int num, u32 slot) { }
>>>
>>>    #endif
>>>
>>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
>>> index 43514f9..c547885 100644
>>> --- a/arch/arm64/kernel/topology.c
>>> +++ b/arch/arm64/kernel/topology.c
>>> @@ -281,3 +281,17 @@ void __init init_cpu_topology(void)
>>>        if (parse_dt_topology())
>>>            reset_cpu_topology();
>>>    }
>>> +
>>> +/*
>>> + * Use the CPU slot number provided by ACPI to update the physical
>>> + * package id when cpuid_topo->cluster_id is not available, then we
>>> + * can get the right value in the "physical id" field of /proc/cpuinfo.
>>> + */
>>
>> We don't have "physical id" field in /proc/cpuinfo on ARM64.
>
> I'm just curious, if there are two or more CPU (SoC) chips and connected
> into one system, how to tell one SoC from another?
>

There was some discussion on ARM64 /proc/cpuinfo recently[1]. Even ARM
doesn't have this. IMO we might want to present complete MPIDR in future
if really needed.

Not sure, why we need this "physical id" field as these cpuid topology
is already visible via sysfs explicitly(we really don't need that again
elsewhere ?)

Regards,
Sudeep

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/264390.html

[PATCH 04/19] ARM64 / ACPI: Introduce arch_fix_phys_package_id() for cpu topology

[Sudeep Holla]

On 01/08/14 07:35, Hanjun Guo wrote:
> On 2014-7-29 2:51, Sudeep Holla wrote:
>> On 24/07/14 14:00, Hanjun Guo wrote:
>>> arch_fix_phys_package_id() will be called in ACPI core to use
>>> the slot number provided by ACPI to update the physical package
>>> id, then we can get the right value in the "physical id" field
>>> of /proc/cpuinfo.
>>>
>>> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
>>> ---
>>>    arch/arm64/include/asm/topology.h |    2 ++
>>>    arch/arm64/kernel/topology.c      |   14 ++++++++++++++
>>>    2 files changed, 16 insertions(+)
>>>
>>> diff --git a/arch/arm64/include/asm/topology.h
>>> b/arch/arm64/include/asm/topology.h
>>> index 7ebcd31..2b216d4 100644
>>> --- a/arch/arm64/include/asm/topology.h
>>> +++ b/arch/arm64/include/asm/topology.h
>>> @@ -23,11 +23,13 @@ extern struct cpu_topology cpu_topology[NR_CPUS];
>>>    void init_cpu_topology(void);
>>>    void store_cpu_topology(unsigned int cpuid);
>>>    const struct cpumask *cpu_coregroup_mask(int cpu);
>>> +void arch_fix_phys_package_id(int num, u32 slot);
>>>
>>>    #else
>>>
>>>    static inline void init_cpu_topology(void) { }
>>>    static inline void store_cpu_topology(unsigned int cpuid) { }
>>> +static inline void arch_fix_phys_package_id(int num, u32 slot) { }
>>>
>>>    #endif
>>>
>>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
>>> index 43514f9..c547885 100644
>>> --- a/arch/arm64/kernel/topology.c
>>> +++ b/arch/arm64/kernel/topology.c
>>> @@ -281,3 +281,17 @@ void __init init_cpu_topology(void)
>>>        if (parse_dt_topology())
>>>            reset_cpu_topology();
>>>    }
>>> +
>>> +/*
>>> + * Use the CPU slot number provided by ACPI to update the physical
>>> + * package id when cpuid_topo->cluster_id is not available, then we
>>> + * can get the right value in the "physical id" field of /proc/cpuinfo.
>>> + */
>>
>> We don't have "physical id" field in /proc/cpuinfo on ARM64.
>
> I'm just curious, if there are two or more CPU (SoC) chips and connected
> into one system, how to tell one SoC from another?
>

There was some discussion on ARM64 /proc/cpuinfo recently[1]. Even ARM
doesn't have this. IMO we might want to present complete MPIDR in future
if really needed.

Not sure, why we need this "physical id" field as these cpuid topology
is already visible via sysfs explicitly(we really don't need that again
elsewhere ?)

Regards,
Sudeep

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/264390.html

Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

Hi Olof,

On 2014-7-31 18:57, Hanjun Guo wrote:
> On 2014-7-31 14:54, Olof Johansson wrote:
[...]
>>> +static void __init acpi_smp_init_cpus(void)
>>> +{
>>> +	int cpu;
>>> +
>>> +	for_each_possible_cpu(cpu) {
>>> +		if (cpu_acpi_read_ops(cpu) != 0)
>>> +			continue;
>>> +
>>> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
>>> +	}
>>> +}
>>> +
>>> +void __init smp_init_cpus(void)
>>> +{
>>> +	if (acpi_disabled)
>>> +		of_smp_init_cpus();
>>> +	else
>>> +		acpi_smp_init_cpus();
>>
>> I'm liking these deeply split code paths less and less every time I see
>> them. :(
>>
>> I would prefer to set up shared state in separate functions, but keep the
>> control flow the same. Right now you're splitting it completely.
>>
>> I.e. split data setup between the two, but do the loop calling cpu_init()
>> the same way. (Yes, that will require you to refactor the DT code path
>> a bit too...)
> 
> OK, I will dive into the code and figure out if I can fix that as you
> suggested, thanks for your comments :)

After some investigation of the code, it seems that it is pretty hard
to do so, the major gap to do that is DT needs the device node of CPU
to init CPUs, but ACPI just needs the logical CPU number. In DT mode,
it needs to search the DT and get the CPU device node to get its enable
method, but in ACPI mode, it is a flag to indicate the CPU enable (boot)
method.

the code can be modified as below, but the logic is the same:

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 40f38f4..71a625b 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -320,6 +320,17 @@ void __init smp_init_cpus(void)
        unsigned int i, cpu = 1;
        bool bootcpu_valid = false;

+       if (!acpi_disabled) {
+               for_each_possible_cpu(cpu) {
+                       if (cpu_read_ops(NULL, cpu) != 0)
+                               continue;
+
+                       cpu_ops[cpu]->cpu_init(NULL, cpu);
+               }
+
+               return;
+       }
+
        while ((dn = of_find_node_by_type(dn, "cpu"))) {
                const u32 *cell;
                u64 hwid;

Does it make sense to you?

Thanks
Hanjun

Re: [PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

Hi Olof,

On 2014-7-31 18:57, Hanjun Guo wrote:
> On 2014-7-31 14:54, Olof Johansson wrote:
[...]
>>> +static void __init acpi_smp_init_cpus(void)
>>> +{
>>> +	int cpu;
>>> +
>>> +	for_each_possible_cpu(cpu) {
>>> +		if (cpu_acpi_read_ops(cpu) != 0)
>>> +			continue;
>>> +
>>> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
>>> +	}
>>> +}
>>> +
>>> +void __init smp_init_cpus(void)
>>> +{
>>> +	if (acpi_disabled)
>>> +		of_smp_init_cpus();
>>> +	else
>>> +		acpi_smp_init_cpus();
>>
>> I'm liking these deeply split code paths less and less every time I see
>> them. :(
>>
>> I would prefer to set up shared state in separate functions, but keep the
>> control flow the same. Right now you're splitting it completely.
>>
>> I.e. split data setup between the two, but do the loop calling cpu_init()
>> the same way. (Yes, that will require you to refactor the DT code path
>> a bit too...)
> 
> OK, I will dive into the code and figure out if I can fix that as you
> suggested, thanks for your comments :)

After some investigation of the code, it seems that it is pretty hard
to do so, the major gap to do that is DT needs the device node of CPU
to init CPUs, but ACPI just needs the logical CPU number. In DT mode,
it needs to search the DT and get the CPU device node to get its enable
method, but in ACPI mode, it is a flag to indicate the CPU enable (boot)
method.

the code can be modified as below, but the logic is the same:

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 40f38f4..71a625b 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -320,6 +320,17 @@ void __init smp_init_cpus(void)
        unsigned int i, cpu = 1;
        bool bootcpu_valid = false;

+       if (!acpi_disabled) {
+               for_each_possible_cpu(cpu) {
+                       if (cpu_read_ops(NULL, cpu) != 0)
+                               continue;
+
+                       cpu_ops[cpu]->cpu_init(NULL, cpu);
+               }
+
+               return;
+       }
+
        while ((dn = of_find_node_by_type(dn, "cpu"))) {
                const u32 *cell;
                u64 hwid;

Does it make sense to you?

Thanks
Hanjun

[PATCH 10/19] ARM64 / ACPI: Get the enable method for SMP initialization in ACPI way

[Hanjun Guo]

Hi Olof,

On 2014-7-31 18:57, Hanjun Guo wrote:
> On 2014-7-31 14:54, Olof Johansson wrote:
[...]
>>> +static void __init acpi_smp_init_cpus(void)
>>> +{
>>> +	int cpu;
>>> +
>>> +	for_each_possible_cpu(cpu) {
>>> +		if (cpu_acpi_read_ops(cpu) != 0)
>>> +			continue;
>>> +
>>> +		cpu_ops[cpu]->cpu_init(NULL, cpu);
>>> +	}
>>> +}
>>> +
>>> +void __init smp_init_cpus(void)
>>> +{
>>> +	if (acpi_disabled)
>>> +		of_smp_init_cpus();
>>> +	else
>>> +		acpi_smp_init_cpus();
>>
>> I'm liking these deeply split code paths less and less every time I see
>> them. :(
>>
>> I would prefer to set up shared state in separate functions, but keep the
>> control flow the same. Right now you're splitting it completely.
>>
>> I.e. split data setup between the two, but do the loop calling cpu_init()
>> the same way. (Yes, that will require you to refactor the DT code path
>> a bit too...)
> 
> OK, I will dive into the code and figure out if I can fix that as you
> suggested, thanks for your comments :)

After some investigation of the code, it seems that it is pretty hard
to do so, the major gap to do that is DT needs the device node of CPU
to init CPUs, but ACPI just needs the logical CPU number. In DT mode,
it needs to search the DT and get the CPU device node to get its enable
method, but in ACPI mode, it is a flag to indicate the CPU enable (boot)
method.

the code can be modified as below, but the logic is the same:

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 40f38f4..71a625b 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -320,6 +320,17 @@ void __init smp_init_cpus(void)
        unsigned int i, cpu = 1;
        bool bootcpu_valid = false;

+       if (!acpi_disabled) {
+               for_each_possible_cpu(cpu) {
+                       if (cpu_read_ops(NULL, cpu) != 0)
+                               continue;
+
+                       cpu_ops[cpu]->cpu_init(NULL, cpu);
+               }
+
+               return;
+       }
+
        while ((dn = of_find_node_by_type(dn, "cpu"))) {
                const u32 *cell;
                u64 hwid;

Does it make sense to you?

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Catalin Marinas]

On Mon, Jul 28, 2014 at 07:27:52PM +0100, Olof Johansson wrote:
> On Mon, Jul 28, 2014 at 10:00 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Mon, Jul 28, 2014 at 05:27:50PM +0100, Olof Johansson wrote:
> >> On Mon, Jul 28, 2014 at 11:07:50AM +0200, Arnd Bergmann wrote:
> >> > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> >> > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> >> > > > +Relationship with Device Tree
> >> > > > +-----------------------------
> >> > > > +
> >> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> >> > > > +exclusive with DT support at compile time.
> >> > > > +
> >> > > > +At boot time the kernel will only use one description method depending on
> >> > > > +parameters passed from the bootloader.
> >> > >
> >> > > Possibly overriden by kernel bootargs. And as debated for quite a
> >> > > while earlier this year, acpi should still default to off -- if a DT
> >> > > and ACPI are both passed in, DT should at this time be given priority.
> >> >
> >> > I think this would be harder to do with the way that ACPI is passed in
> >> > to the kernel. IIRC, you always have a minimal DT information based on
> >> > the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> >> > to the ACPI tables, which are then used for populating the Linux platform
> >> > devices (unless acpi=disabled is set), while the other contents of the
> >> > DTB may be present but we skip the of_platform_populate state.
> >>
> >> How can it be harder to do? If you support acpi=off, then you should support
> >> acpi=on.
> >>
> >> Another alternative would be to have an early fixup that stubs out
> >> the acpi properties from the DTB unless there's an 'acpi' or 'acpi=on'
> >> argument on the cmdline. Not quite as tidy a solution, though.
> >
> > I don't follow:
> >
> > If you want to disable ACPI, you can pass acpi=off. This is your
> > workaround for broken ACPI (and only if you happen to have wrirten your
> > own DTB, because many/most ACPI systems WILL NOT have a DTB to begin
> > with).
> 
> All ACPI should be assumed broken at this time, so acpi=off _must_ be
> the default.

(catching up with emails after holiday and I may have missed some of
your arguments)

If we consider ACPI unusable on ARM but we still want to start merging
patches, we should rather make the config option depend on BROKEN
(though if it is that unusable that no real platform can use it, I would
rather not merge it at all at this stage).

I don't really see what requiring acpi=on explicitly would buy us as
vendors firmware providing only ACPI tables would simply always set this
command line option. Defaulting to off is not really a way for mandating
valid DT to be provided by firmware (rather a statement we try to make
that ACPI is not a first class citizen yet).

I would also expect platforms to be ACPI only and handle for example
D-states via AML. If they work fine, do we really need to bother adding
DT support for them, potentially with additional drivers? IOW, do we
want to mandate all ARM(v8) platforms to work with "acpi=off" out of
firmware?

> > If you have ACPI, for what technical reason would you not attempt to use
> > it by default?
> 
> Because it will be broken, or the company you bought the machine from
> implemented it wrong because they're still learning how to do this
> too. The original doc even mentioned that there are parts of the
> binding that aren't even sorted out. The _DSD stuff, too.

I assume with the current patches, a (sane) platform could still boot
and run without the missing features listed in the document, though it
may not be optimal. We should definitely be strict and not accept quirks
in the kernel to work around missing features until the UEFI forum
accepted the specification.

> Overall, it's not yet ready to be the default boot method.

Then make CONFIG_ACPI default off and depend on EXPERT as a better
statement (but as with acpi=on, it's still just a statement we try to
make). Once the concerns are addressed, we make it an equal citizen.

> > There will be systems which _DO NOT_ have any sort of DTB to begin with.
> 
> Listen, we've been really clear about this: DT is the default that
> everybody has to use for mainline kernel for the near term. If you
> have an ACPI-only system, then you either have to write a DT for it,
> or you won't be booting mainline on it.

OK, this answers one of my questions above (I may have forgotten the old
threads but at the time we were primarily talking about ACPI 5.0 which
wasn't of much use on ARM).

So you want to mandate DT for all platforms, even if some choose
ACPI only longer term. I'm not arguing against this (especially for the
first generation of devices), but how would default acpi=off enforce it?
The firmware would simply pass acpi=on by default and run mainline just
fine (as well as it can based on the implemented features).

We should also not accepted any ACPI features in drivers without a DT
counterpart.

> If they really want to, they can boot with acpi=on instead. It's not
> like it's hard to add.

And this would be the default argument passed by their firmware.

As I said, it's rather just a statement the kernel people want to make,
nothing more. If you want to make the DT requirement stricter, what
about adding code for checking the validity of the DT passed even though
it's booting with ACPI? IMO, it's not worth it, we should rather be
very strict with what ACPI code we accept in the kernel (primarily
drivers, avoid random clock descriptors etc). If a platform cannot work
(optimally) with the strict ACPI set, the vendor either provides DT or
shouldn't bother us with upstreaming at all.

-- 
Catalin

[PATCH 19/19] Documentation: ACPI for ARM64

[Catalin Marinas]

On Mon, Jul 28, 2014 at 07:27:52PM +0100, Olof Johansson wrote:
> On Mon, Jul 28, 2014 at 10:00 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Mon, Jul 28, 2014 at 05:27:50PM +0100, Olof Johansson wrote:
> >> On Mon, Jul 28, 2014 at 11:07:50AM +0200, Arnd Bergmann wrote:
> >> > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> >> > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> >> > > > +Relationship with Device Tree
> >> > > > +-----------------------------
> >> > > > +
> >> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> >> > > > +exclusive with DT support at compile time.
> >> > > > +
> >> > > > +At boot time the kernel will only use one description method depending on
> >> > > > +parameters passed from the bootloader.
> >> > >
> >> > > Possibly overriden by kernel bootargs. And as debated for quite a
> >> > > while earlier this year, acpi should still default to off -- if a DT
> >> > > and ACPI are both passed in, DT should at this time be given priority.
> >> >
> >> > I think this would be harder to do with the way that ACPI is passed in
> >> > to the kernel. IIRC, you always have a minimal DT information based on
> >> > the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> >> > to the ACPI tables, which are then used for populating the Linux platform
> >> > devices (unless acpi=disabled is set), while the other contents of the
> >> > DTB may be present but we skip the of_platform_populate state.
> >>
> >> How can it be harder to do? If you support acpi=off, then you should support
> >> acpi=on.
> >>
> >> Another alternative would be to have an early fixup that stubs out
> >> the acpi properties from the DTB unless there's an 'acpi' or 'acpi=on'
> >> argument on the cmdline. Not quite as tidy a solution, though.
> >
> > I don't follow:
> >
> > If you want to disable ACPI, you can pass acpi=off. This is your
> > workaround for broken ACPI (and only if you happen to have wrirten your
> > own DTB, because many/most ACPI systems WILL NOT have a DTB to begin
> > with).
> 
> All ACPI should be assumed broken at this time, so acpi=off _must_ be
> the default.

(catching up with emails after holiday and I may have missed some of
your arguments)

If we consider ACPI unusable on ARM but we still want to start merging
patches, we should rather make the config option depend on BROKEN
(though if it is that unusable that no real platform can use it, I would
rather not merge it at all at this stage).

I don't really see what requiring acpi=on explicitly would buy us as
vendors firmware providing only ACPI tables would simply always set this
command line option. Defaulting to off is not really a way for mandating
valid DT to be provided by firmware (rather a statement we try to make
that ACPI is not a first class citizen yet).

I would also expect platforms to be ACPI only and handle for example
D-states via AML. If they work fine, do we really need to bother adding
DT support for them, potentially with additional drivers? IOW, do we
want to mandate all ARM(v8) platforms to work with "acpi=off" out of
firmware?

> > If you have ACPI, for what technical reason would you not attempt to use
> > it by default?
> 
> Because it will be broken, or the company you bought the machine from
> implemented it wrong because they're still learning how to do this
> too. The original doc even mentioned that there are parts of the
> binding that aren't even sorted out. The _DSD stuff, too.

I assume with the current patches, a (sane) platform could still boot
and run without the missing features listed in the document, though it
may not be optimal. We should definitely be strict and not accept quirks
in the kernel to work around missing features until the UEFI forum
accepted the specification.

> Overall, it's not yet ready to be the default boot method.

Then make CONFIG_ACPI default off and depend on EXPERT as a better
statement (but as with acpi=on, it's still just a statement we try to
make). Once the concerns are addressed, we make it an equal citizen.

> > There will be systems which _DO NOT_ have any sort of DTB to begin with.
> 
> Listen, we've been really clear about this: DT is the default that
> everybody has to use for mainline kernel for the near term. If you
> have an ACPI-only system, then you either have to write a DT for it,
> or you won't be booting mainline on it.

OK, this answers one of my questions above (I may have forgotten the old
threads but at the time we were primarily talking about ACPI 5.0 which
wasn't of much use on ARM).

So you want to mandate DT for all platforms, even if some choose
ACPI only longer term. I'm not arguing against this (especially for the
first generation of devices), but how would default acpi=off enforce it?
The firmware would simply pass acpi=on by default and run mainline just
fine (as well as it can based on the implemented features).

We should also not accepted any ACPI features in drivers without a DT
counterpart.

> If they really want to, they can boot with acpi=on instead. It's not
> like it's hard to add.

And this would be the default argument passed by their firmware.

As I said, it's rather just a statement the kernel people want to make,
nothing more. If you want to make the DT requirement stricter, what
about adding code for checking the validity of the DT passed even though
it's booting with ACPI? IMO, it's not worth it, we should rather be
very strict with what ACPI code we accept in the kernel (primarily
drivers, avoid random clock descriptors etc). If a platform cannot work
(optimally) with the strict ACPI set, the vendor either provides DT or
shouldn't bother us with upstreaming at all.

-- 
Catalin

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Rafael J. Wysocki]

On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> On Mon, Jul 28, 2014 at 07:27:52PM +0100, Olof Johansson wrote:
> > On Mon, Jul 28, 2014 at 10:00 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > > On Mon, Jul 28, 2014 at 05:27:50PM +0100, Olof Johansson wrote:
> > >> On Mon, Jul 28, 2014 at 11:07:50AM +0200, Arnd Bergmann wrote:
> > >> > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> > >> > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > >> > > > +Relationship with Device Tree
> > >> > > > +-----------------------------
> > >> > > > +
> > >> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > >> > > > +exclusive with DT support at compile time.
> > >> > > > +
> > >> > > > +At boot time the kernel will only use one description method depending on
> > >> > > > +parameters passed from the bootloader.
> > >> > >
> > >> > > Possibly overriden by kernel bootargs. And as debated for quite a
> > >> > > while earlier this year, acpi should still default to off -- if a DT
> > >> > > and ACPI are both passed in, DT should at this time be given priority.
> > >> >
> > >> > I think this would be harder to do with the way that ACPI is passed in
> > >> > to the kernel. IIRC, you always have a minimal DT information based on
> > >> > the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> > >> > to the ACPI tables, which are then used for populating the Linux platform
> > >> > devices (unless acpi=disabled is set), while the other contents of the
> > >> > DTB may be present but we skip the of_platform_populate state.
> > >>
> > >> How can it be harder to do? If you support acpi=off, then you should support
> > >> acpi=on.
> > >>
> > >> Another alternative would be to have an early fixup that stubs out
> > >> the acpi properties from the DTB unless there's an 'acpi' or 'acpi=on'
> > >> argument on the cmdline. Not quite as tidy a solution, though.
> > >
> > > I don't follow:
> > >
> > > If you want to disable ACPI, you can pass acpi=off. This is your
> > > workaround for broken ACPI (and only if you happen to have wrirten your
> > > own DTB, because many/most ACPI systems WILL NOT have a DTB to begin
> > > with).
> > 
> > All ACPI should be assumed broken at this time, so acpi=off _must_ be
> > the default.
> 
> (catching up with emails after holiday and I may have missed some of
> your arguments)
> 
> If we consider ACPI unusable on ARM but we still want to start merging
> patches, we should rather make the config option depend on BROKEN
> (though if it is that unusable that no real platform can use it, I would
> rather not merge it at all at this stage).

I agree here.

I would recommend creating a separate branch for that living outside of the
mainline kernel and merging it when there are real users.

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

[PATCH 19/19] Documentation: ACPI for ARM64

[Rafael J. Wysocki]

On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> On Mon, Jul 28, 2014 at 07:27:52PM +0100, Olof Johansson wrote:
> > On Mon, Jul 28, 2014 at 10:00 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> > > On Mon, Jul 28, 2014 at 05:27:50PM +0100, Olof Johansson wrote:
> > >> On Mon, Jul 28, 2014 at 11:07:50AM +0200, Arnd Bergmann wrote:
> > >> > On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
> > >> > > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > >> > > > +Relationship with Device Tree
> > >> > > > +-----------------------------
> > >> > > > +
> > >> > > > +ACPI support in drivers and subsystems for ARMv8 should never be mutually
> > >> > > > +exclusive with DT support at compile time.
> > >> > > > +
> > >> > > > +At boot time the kernel will only use one description method depending on
> > >> > > > +parameters passed from the bootloader.
> > >> > >
> > >> > > Possibly overriden by kernel bootargs. And as debated for quite a
> > >> > > while earlier this year, acpi should still default to off -- if a DT
> > >> > > and ACPI are both passed in, DT should at this time be given priority.
> > >> >
> > >> > I think this would be harder to do with the way that ACPI is passed in
> > >> > to the kernel. IIRC, you always have a minimal DT information based on
> > >> > the ARM64 boot protocol, but in the case of ACPI, this contains pointers
> > >> > to the ACPI tables, which are then used for populating the Linux platform
> > >> > devices (unless acpi=disabled is set), while the other contents of the
> > >> > DTB may be present but we skip the of_platform_populate state.
> > >>
> > >> How can it be harder to do? If you support acpi=off, then you should support
> > >> acpi=on.
> > >>
> > >> Another alternative would be to have an early fixup that stubs out
> > >> the acpi properties from the DTB unless there's an 'acpi' or 'acpi=on'
> > >> argument on the cmdline. Not quite as tidy a solution, though.
> > >
> > > I don't follow:
> > >
> > > If you want to disable ACPI, you can pass acpi=off. This is your
> > > workaround for broken ACPI (and only if you happen to have wrirten your
> > > own DTB, because many/most ACPI systems WILL NOT have a DTB to begin
> > > with).
> > 
> > All ACPI should be assumed broken at this time, so acpi=off _must_ be
> > the default.
> 
> (catching up with emails after holiday and I may have missed some of
> your arguments)
> 
> If we consider ACPI unusable on ARM but we still want to start merging
> patches, we should rather make the config option depend on BROKEN
> (though if it is that unusable that no real platform can use it, I would
> rather not merge it at all at this stage).

I agree here.

I would recommend creating a separate branch for that living outside of the
mainline kernel and merging it when there are real users.

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>> On Mon, Jul 28, 2014 at 07:27:52PM +0100, Olof Johansson wrote:
>>> On Mon, Jul 28, 2014 at 10:00 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>> On Mon, Jul 28, 2014 at 05:27:50PM +0100, Olof Johansson wrote:
>>>>> On Mon, Jul 28, 2014 at 11:07:50AM +0200, Arnd Bergmann wrote:
>>>>>> On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
>>>>>>> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>>>>>>>> +Relationship with Device Tree
>>>>>>>> +-----------------------------
>>>>>>>> +
>>>>>>>> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>>>>>>>> +exclusive with DT support at compile time.
>>>>>>>> +
>>>>>>>> +At boot time the kernel will only use one description method depending on
>>>>>>>> +parameters passed from the bootloader.
>>>>>>>
>>>>>>> Possibly overriden by kernel bootargs. And as debated for quite a
>>>>>>> while earlier this year, acpi should still default to off -- if a DT
>>>>>>> and ACPI are both passed in, DT should at this time be given priority.
>>>>>>
>>>>>> I think this would be harder to do with the way that ACPI is passed in
>>>>>> to the kernel. IIRC, you always have a minimal DT information based on
>>>>>> the ARM64 boot protocol, but in the case of ACPI, this contains pointers
>>>>>> to the ACPI tables, which are then used for populating the Linux platform
>>>>>> devices (unless acpi=disabled is set), while the other contents of the
>>>>>> DTB may be present but we skip the of_platform_populate state.
>>>>>
>>>>> How can it be harder to do? If you support acpi=off, then you should support
>>>>> acpi=on.
>>>>>
>>>>> Another alternative would be to have an early fixup that stubs out
>>>>> the acpi properties from the DTB unless there's an 'acpi' or 'acpi=on'
>>>>> argument on the cmdline. Not quite as tidy a solution, though.
>>>>
>>>> I don't follow:
>>>>
>>>> If you want to disable ACPI, you can pass acpi=off. This is your
>>>> workaround for broken ACPI (and only if you happen to have wrirten your
>>>> own DTB, because many/most ACPI systems WILL NOT have a DTB to begin
>>>> with).
>>>
>>> All ACPI should be assumed broken at this time, so acpi=off _must_ be
>>> the default.
>>
>> (catching up with emails after holiday and I may have missed some of
>> your arguments)
>>
>> If we consider ACPI unusable on ARM but we still want to start merging
>> patches, we should rather make the config option depend on BROKEN
>> (though if it is that unusable that no real platform can use it, I would
>> rather not merge it at all at this stage).
> 
> I agree here.
> 
> I would recommend creating a separate branch for that living outside of the
> mainline kernel and merging it when there are real users.

Real users will coming soon, we already tested this patch set on real hardware
(ARM64 Juno platform), and I think ARM64 server chips and platforms will show
up before 3.18 is released.

For this patch set, DT is the first class citizen at now:

a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;

b) Even if we set CONFIG_ACPI=Y, we also can use DT as normal:

  - Pass DT blob without (valid) ACPI tables (just as we boot the kernel now),
    ACPI will disabled in the very early stage and FDT will still to be
    unflattened, so will not break DT booting.

  - We can pass ACPI=off to disable ACPI and use DT even if we got valid
    ACPI tables (in the v1 patch set);

So it is safe for people who want to use DT, and didn't change any behavior
of DT booting except some extra test of if(acpi_disabled).

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>> On Mon, Jul 28, 2014 at 07:27:52PM +0100, Olof Johansson wrote:
>>> On Mon, Jul 28, 2014 at 10:00 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>> On Mon, Jul 28, 2014 at 05:27:50PM +0100, Olof Johansson wrote:
>>>>> On Mon, Jul 28, 2014 at 11:07:50AM +0200, Arnd Bergmann wrote:
>>>>>> On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
>>>>>>> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>>>>>>>> +Relationship with Device Tree
>>>>>>>> +-----------------------------
>>>>>>>> +
>>>>>>>> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>>>>>>>> +exclusive with DT support at compile time.
>>>>>>>> +
>>>>>>>> +At boot time the kernel will only use one description method depending on
>>>>>>>> +parameters passed from the bootloader.
>>>>>>>
>>>>>>> Possibly overriden by kernel bootargs. And as debated for quite a
>>>>>>> while earlier this year, acpi should still default to off -- if a DT
>>>>>>> and ACPI are both passed in, DT should at this time be given priority.
>>>>>>
>>>>>> I think this would be harder to do with the way that ACPI is passed in
>>>>>> to the kernel. IIRC, you always have a minimal DT information based on
>>>>>> the ARM64 boot protocol, but in the case of ACPI, this contains pointers
>>>>>> to the ACPI tables, which are then used for populating the Linux platform
>>>>>> devices (unless acpi=disabled is set), while the other contents of the
>>>>>> DTB may be present but we skip the of_platform_populate state.
>>>>>
>>>>> How can it be harder to do? If you support acpi=off, then you should support
>>>>> acpi=on.
>>>>>
>>>>> Another alternative would be to have an early fixup that stubs out
>>>>> the acpi properties from the DTB unless there's an 'acpi' or 'acpi=on'
>>>>> argument on the cmdline. Not quite as tidy a solution, though.
>>>>
>>>> I don't follow:
>>>>
>>>> If you want to disable ACPI, you can pass acpi=off. This is your
>>>> workaround for broken ACPI (and only if you happen to have wrirten your
>>>> own DTB, because many/most ACPI systems WILL NOT have a DTB to begin
>>>> with).
>>>
>>> All ACPI should be assumed broken at this time, so acpi=off _must_ be
>>> the default.
>>
>> (catching up with emails after holiday and I may have missed some of
>> your arguments)
>>
>> If we consider ACPI unusable on ARM but we still want to start merging
>> patches, we should rather make the config option depend on BROKEN
>> (though if it is that unusable that no real platform can use it, I would
>> rather not merge it at all at this stage).
> 
> I agree here.
> 
> I would recommend creating a separate branch for that living outside of the
> mainline kernel and merging it when there are real users.

Real users will coming soon, we already tested this patch set on real hardware
(ARM64 Juno platform), and I think ARM64 server chips and platforms will show
up before 3.18 is released.

For this patch set, DT is the first class citizen at now:

a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;

b) Even if we set CONFIG_ACPI=Y, we also can use DT as normal:

  - Pass DT blob without (valid) ACPI tables (just as we boot the kernel now),
    ACPI will disabled in the very early stage and FDT will still to be
    unflattened, so will not break DT booting.

  - We can pass ACPI=off to disable ACPI and use DT even if we got valid
    ACPI tables (in the v1 patch set);

So it is safe for people who want to use DT, and didn't change any behavior
of DT booting except some extra test of if(acpi_disabled).

Thanks
Hanjun

[PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>> On Mon, Jul 28, 2014 at 07:27:52PM +0100, Olof Johansson wrote:
>>> On Mon, Jul 28, 2014 at 10:00 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>> On Mon, Jul 28, 2014 at 05:27:50PM +0100, Olof Johansson wrote:
>>>>> On Mon, Jul 28, 2014 at 11:07:50AM +0200, Arnd Bergmann wrote:
>>>>>> On Saturday 26 July 2014 19:34:48 Olof Johansson wrote:
>>>>>>> On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
>>>>>>>> +Relationship with Device Tree
>>>>>>>> +-----------------------------
>>>>>>>> +
>>>>>>>> +ACPI support in drivers and subsystems for ARMv8 should never be mutually
>>>>>>>> +exclusive with DT support at compile time.
>>>>>>>> +
>>>>>>>> +At boot time the kernel will only use one description method depending on
>>>>>>>> +parameters passed from the bootloader.
>>>>>>>
>>>>>>> Possibly overriden by kernel bootargs. And as debated for quite a
>>>>>>> while earlier this year, acpi should still default to off -- if a DT
>>>>>>> and ACPI are both passed in, DT should at this time be given priority.
>>>>>>
>>>>>> I think this would be harder to do with the way that ACPI is passed in
>>>>>> to the kernel. IIRC, you always have a minimal DT information based on
>>>>>> the ARM64 boot protocol, but in the case of ACPI, this contains pointers
>>>>>> to the ACPI tables, which are then used for populating the Linux platform
>>>>>> devices (unless acpi=disabled is set), while the other contents of the
>>>>>> DTB may be present but we skip the of_platform_populate state.
>>>>>
>>>>> How can it be harder to do? If you support acpi=off, then you should support
>>>>> acpi=on.
>>>>>
>>>>> Another alternative would be to have an early fixup that stubs out
>>>>> the acpi properties from the DTB unless there's an 'acpi' or 'acpi=on'
>>>>> argument on the cmdline. Not quite as tidy a solution, though.
>>>>
>>>> I don't follow:
>>>>
>>>> If you want to disable ACPI, you can pass acpi=off. This is your
>>>> workaround for broken ACPI (and only if you happen to have wrirten your
>>>> own DTB, because many/most ACPI systems WILL NOT have a DTB to begin
>>>> with).
>>>
>>> All ACPI should be assumed broken at this time, so acpi=off _must_ be
>>> the default.
>>
>> (catching up with emails after holiday and I may have missed some of
>> your arguments)
>>
>> If we consider ACPI unusable on ARM but we still want to start merging
>> patches, we should rather make the config option depend on BROKEN
>> (though if it is that unusable that no real platform can use it, I would
>> rather not merge it at all at this stage).
> 
> I agree here.
> 
> I would recommend creating a separate branch for that living outside of the
> mainline kernel and merging it when there are real users.

Real users will coming soon, we already tested this patch set on real hardware
(ARM64 Juno platform), and I think ARM64 server chips and platforms will show
up before 3.18 is released.

For this patch set, DT is the first class citizen at now:

a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;

b) Even if we set CONFIG_ACPI=Y, we also can use DT as normal:

  - Pass DT blob without (valid) ACPI tables (just as we boot the kernel now),
    ACPI will disabled in the very early stage and FDT will still to be
    unflattened, so will not break DT booting.

  - We can pass ACPI=off to disable ACPI and use DT even if we got valid
    ACPI tables (in the v1 patch set);

So it is safe for people who want to use DT, and didn't change any behavior
of DT booting except some extra test of if(acpi_disabled).

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Catalin Marinas]

On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> > On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> >> If we consider ACPI unusable on ARM but we still want to start merging
> >> patches, we should rather make the config option depend on BROKEN
> >> (though if it is that unusable that no real platform can use it, I would
> >> rather not merge it at all at this stage).
> > 
> > I agree here.
> > 
> > I would recommend creating a separate branch for that living outside of the
> > mainline kernel and merging it when there are real users.
> 
> Real users will coming soon, we already tested this patch set on real hardware
> (ARM64 Juno platform),

I don't consider Juno a server platform ;) (but it's good enough for
development).

> and I think ARM64 server chips and platforms will show up before 3.18
> is released.

That's what I've heard/seen. The questions I have are (a) whether
current ACPI patchset is enough to successfully run Linux on such
_hardware_ platform (maybe not fully optimised, for example just WFI
cpuidle) and (b) whether we still want to mandate a DT in the kernel for
such platforms.

Given the answer to (a) and what other features are needed, we may or
may not mandate (b). We were pretty clear few months ago that (b) is
still required but at the time we were only openly talking about ACPI
5.0 which was lacking many features. I think we need to revisit that
position based on how usable ACPI 5.1 for ARM (and current kernel
implementation) is. Would you mind elaborating what an ACPI-only
platform miss?

I would expect a new server platform designed with ACPI in mind to
require minimal SoC specific code, so we may only see a few patches
under drivers/ for such platforms adding ACPI-specific probing (possibly
new drivers as well if it's a new component).

> For this patch set, DT is the first class citizen at now:
> 
> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;

Not just off but, based on maturity, depend on EXPERT.

> b) Even if we set CONFIG_ACPI=Y, we also can use DT as normal:
> 
>   - Pass DT blob without (valid) ACPI tables (just as we boot the kernel now),
>     ACPI will disabled in the very early stage and FDT will still to be
>     unflattened, so will not break DT booting.
> 
>   - We can pass ACPI=off to disable ACPI and use DT even if we got valid
>     ACPI tables (in the v1 patch set);
> 
> So it is safe for people who want to use DT, and didn't change any behavior
> of DT booting except some extra test of if(acpi_disabled).

But should we require SoC firmware to provide both valid DT and ACPI
tables so that the user can decide which one to select at boot-time?

-- 
Catalin

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Catalin Marinas]

On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> > On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> >> If we consider ACPI unusable on ARM but we still want to start merging
> >> patches, we should rather make the config option depend on BROKEN
> >> (though if it is that unusable that no real platform can use it, I would
> >> rather not merge it at all at this stage).
> > 
> > I agree here.
> > 
> > I would recommend creating a separate branch for that living outside of the
> > mainline kernel and merging it when there are real users.
> 
> Real users will coming soon, we already tested this patch set on real hardware
> (ARM64 Juno platform),

I don't consider Juno a server platform ;) (but it's good enough for
development).

> and I think ARM64 server chips and platforms will show up before 3.18
> is released.

That's what I've heard/seen. The questions I have are (a) whether
current ACPI patchset is enough to successfully run Linux on such
_hardware_ platform (maybe not fully optimised, for example just WFI
cpuidle) and (b) whether we still want to mandate a DT in the kernel for
such platforms.

Given the answer to (a) and what other features are needed, we may or
may not mandate (b). We were pretty clear few months ago that (b) is
still required but at the time we were only openly talking about ACPI
5.0 which was lacking many features. I think we need to revisit that
position based on how usable ACPI 5.1 for ARM (and current kernel
implementation) is. Would you mind elaborating what an ACPI-only
platform miss?

I would expect a new server platform designed with ACPI in mind to
require minimal SoC specific code, so we may only see a few patches
under drivers/ for such platforms adding ACPI-specific probing (possibly
new drivers as well if it's a new component).

> For this patch set, DT is the first class citizen at now:
> 
> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;

Not just off but, based on maturity, depend on EXPERT.

> b) Even if we set CONFIG_ACPI=Y, we also can use DT as normal:
> 
>   - Pass DT blob without (valid) ACPI tables (just as we boot the kernel now),
>     ACPI will disabled in the very early stage and FDT will still to be
>     unflattened, so will not break DT booting.
> 
>   - We can pass ACPI=off to disable ACPI and use DT even if we got valid
>     ACPI tables (in the v1 patch set);
> 
> So it is safe for people who want to use DT, and didn't change any behavior
> of DT booting except some extra test of if(acpi_disabled).

But should we require SoC firmware to provide both valid DT and ACPI
tables so that the user can decide which one to select at boot-time?

-- 
Catalin

[PATCH 19/19] Documentation: ACPI for ARM64

[Catalin Marinas]

On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> > On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> >> If we consider ACPI unusable on ARM but we still want to start merging
> >> patches, we should rather make the config option depend on BROKEN
> >> (though if it is that unusable that no real platform can use it, I would
> >> rather not merge it at all at this stage).
> > 
> > I agree here.
> > 
> > I would recommend creating a separate branch for that living outside of the
> > mainline kernel and merging it when there are real users.
> 
> Real users will coming soon, we already tested this patch set on real hardware
> (ARM64 Juno platform),

I don't consider Juno a server platform ;) (but it's good enough for
development).

> and I think ARM64 server chips and platforms will show up before 3.18
> is released.

That's what I've heard/seen. The questions I have are (a) whether
current ACPI patchset is enough to successfully run Linux on such
_hardware_ platform (maybe not fully optimised, for example just WFI
cpuidle) and (b) whether we still want to mandate a DT in the kernel for
such platforms.

Given the answer to (a) and what other features are needed, we may or
may not mandate (b). We were pretty clear few months ago that (b) is
still required but at the time we were only openly talking about ACPI
5.0 which was lacking many features. I think we need to revisit that
position based on how usable ACPI 5.1 for ARM (and current kernel
implementation) is. Would you mind elaborating what an ACPI-only
platform miss?

I would expect a new server platform designed with ACPI in mind to
require minimal SoC specific code, so we may only see a few patches
under drivers/ for such platforms adding ACPI-specific probing (possibly
new drivers as well if it's a new component).

> For this patch set, DT is the first class citizen at now:
> 
> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;

Not just off but, based on maturity, depend on EXPERT.

> b) Even if we set CONFIG_ACPI=Y, we also can use DT as normal:
> 
>   - Pass DT blob without (valid) ACPI tables (just as we boot the kernel now),
>     ACPI will disabled in the very early stage and FDT will still to be
>     unflattened, so will not break DT booting.
> 
>   - We can pass ACPI=off to disable ACPI and use DT even if we got valid
>     ACPI tables (in the v1 patch set);
> 
> So it is safe for people who want to use DT, and didn't change any behavior
> of DT booting except some extra test of if(acpi_disabled).

But should we require SoC firmware to provide both valid DT and ACPI
tables so that the user can decide which one to select at boot-time?

-- 
Catalin

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Thursday 14 August 2014 11:27:23 Catalin Marinas wrote:
> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> > On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> > > On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> > >> If we consider ACPI unusable on ARM but we still want to start merging
> > >> patches, we should rather make the config option depend on BROKEN
> > >> (though if it is that unusable that no real platform can use it, I would
> > >> rather not merge it at all at this stage).
> > > 
> > > I agree here.
> > > 
> > > I would recommend creating a separate branch for that living outside of the
> > > mainline kernel and merging it when there are real users.
> > 
> > Real users will coming soon, we already tested this patch set on real hardware
> > (ARM64 Juno platform),
> 
> I don't consider Juno a server platform  (but it's good enough for
> development).

I would expect that Juno is a superset of what servers need. If this
ACPI patch set is sufficient to support every device present on Juno
with an ACPI firmware, what would be a strong indication that server
platforms work as well.

OTOH, if ACPI on Juno only supports half the features that the hardware
has, that doesn't tell us much about the suitability of ACPI for any
real-world system, server or not.

> > and I think ARM64 server chips and platforms will show up before 3.18
> > is released.
> 
> That's what I've heard/seen. The questions I have are (a) whether
> current ACPI patchset is enough to successfully run Linux on such
> _hardware_ platform (maybe not fully optimised, for example just WFI
> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> such platforms.
> 
> Given the answer to (a) and what other features are needed, we may or
> may not mandate (b). We were pretty clear few months ago that (b) is
> still required but at the time we were only openly talking about ACPI
> 5.0 which was lacking many features. I think we need to revisit that
> position based on how usable ACPI 5.1 for ARM (and current kernel
> implementation) is. Would you mind elaborating what an ACPI-only
> platform miss?
> 
> I would expect a new server platform designed with ACPI in mind to
> require minimal SoC specific code, so we may only see a few patches
> under drivers/ for such platforms adding ACPI-specific probing (possibly
> new drivers as well if it's a new component).

That is at least the hope, but I have no way of knowing whether it
works that way or not, other than seeing the actual patches.

It is rather annoying that we first have to wait for hardware
to become available to actually see that code, but I guess that
means that those hardware vendors no longer see ACPI as something
on their critical path, so we definitely shouldn't hurry things
until we understand the reason for the endless delay of platform
support patches.

	Arnd

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Thursday 14 August 2014 11:27:23 Catalin Marinas wrote:
> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> > On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> > > On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> > >> If we consider ACPI unusable on ARM but we still want to start merging
> > >> patches, we should rather make the config option depend on BROKEN
> > >> (though if it is that unusable that no real platform can use it, I would
> > >> rather not merge it at all at this stage).
> > > 
> > > I agree here.
> > > 
> > > I would recommend creating a separate branch for that living outside of the
> > > mainline kernel and merging it when there are real users.
> > 
> > Real users will coming soon, we already tested this patch set on real hardware
> > (ARM64 Juno platform),
> 
> I don't consider Juno a server platform  (but it's good enough for
> development).

I would expect that Juno is a superset of what servers need. If this
ACPI patch set is sufficient to support every device present on Juno
with an ACPI firmware, what would be a strong indication that server
platforms work as well.

OTOH, if ACPI on Juno only supports half the features that the hardware
has, that doesn't tell us much about the suitability of ACPI for any
real-world system, server or not.

> > and I think ARM64 server chips and platforms will show up before 3.18
> > is released.
> 
> That's what I've heard/seen. The questions I have are (a) whether
> current ACPI patchset is enough to successfully run Linux on such
> _hardware_ platform (maybe not fully optimised, for example just WFI
> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> such platforms.
> 
> Given the answer to (a) and what other features are needed, we may or
> may not mandate (b). We were pretty clear few months ago that (b) is
> still required but at the time we were only openly talking about ACPI
> 5.0 which was lacking many features. I think we need to revisit that
> position based on how usable ACPI 5.1 for ARM (and current kernel
> implementation) is. Would you mind elaborating what an ACPI-only
> platform miss?
> 
> I would expect a new server platform designed with ACPI in mind to
> require minimal SoC specific code, so we may only see a few patches
> under drivers/ for such platforms adding ACPI-specific probing (possibly
> new drivers as well if it's a new component).

That is at least the hope, but I have no way of knowing whether it
works that way or not, other than seeing the actual patches.

It is rather annoying that we first have to wait for hardware
to become available to actually see that code, but I guess that
means that those hardware vendors no longer see ACPI as something
on their critical path, so we definitely shouldn't hurry things
until we understand the reason for the endless delay of platform
support patches.

	Arnd

[PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Thursday 14 August 2014 11:27:23 Catalin Marinas wrote:
> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> > On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> > > On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> > >> If we consider ACPI unusable on ARM but we still want to start merging
> > >> patches, we should rather make the config option depend on BROKEN
> > >> (though if it is that unusable that no real platform can use it, I would
> > >> rather not merge it at all at this stage).
> > > 
> > > I agree here.
> > > 
> > > I would recommend creating a separate branch for that living outside of the
> > > mainline kernel and merging it when there are real users.
> > 
> > Real users will coming soon, we already tested this patch set on real hardware
> > (ARM64 Juno platform),
> 
> I don't consider Juno a server platform  (but it's good enough for
> development).

I would expect that Juno is a superset of what servers need. If this
ACPI patch set is sufficient to support every device present on Juno
with an ACPI firmware, what would be a strong indication that server
platforms work as well.

OTOH, if ACPI on Juno only supports half the features that the hardware
has, that doesn't tell us much about the suitability of ACPI for any
real-world system, server or not.

> > and I think ARM64 server chips and platforms will show up before 3.18
> > is released.
> 
> That's what I've heard/seen. The questions I have are (a) whether
> current ACPI patchset is enough to successfully run Linux on such
> _hardware_ platform (maybe not fully optimised, for example just WFI
> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> such platforms.
> 
> Given the answer to (a) and what other features are needed, we may or
> may not mandate (b). We were pretty clear few months ago that (b) is
> still required but at the time we were only openly talking about ACPI
> 5.0 which was lacking many features. I think we need to revisit that
> position based on how usable ACPI 5.1 for ARM (and current kernel
> implementation) is. Would you mind elaborating what an ACPI-only
> platform miss?
> 
> I would expect a new server platform designed with ACPI in mind to
> require minimal SoC specific code, so we may only see a few patches
> under drivers/ for such platforms adding ACPI-specific probing (possibly
> new drivers as well if it's a new component).

That is at least the hope, but I have no way of knowing whether it
works that way or not, other than seeing the actual patches.

It is rather annoying that we first have to wait for hardware
to become available to actually see that code, but I guess that
means that those hardware vendors no longer see ACPI as something
on their critical path, so we definitely shouldn't hurry things
until we understand the reason for the endless delay of platform
support patches.

	Arnd

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Thu, Aug 14, 2014 at 1:53 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 14 August 2014 11:27:23 Catalin Marinas wrote:
>> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
>> > On 2014-8-14 7:41, Rafael J. Wysocki wrote:
>> > > On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>> > >> If we consider ACPI unusable on ARM but we still want to start merging
>> > >> patches, we should rather make the config option depend on BROKEN
>> > >> (though if it is that unusable that no real platform can use it, I would
>> > >> rather not merge it at all at this stage).
>> > >
>> > > I agree here.
>> > >
>> > > I would recommend creating a separate branch for that living outside of the
>> > > mainline kernel and merging it when there are real users.
>> >
>> > Real users will coming soon, we already tested this patch set on real hardware
>> > (ARM64 Juno platform),
>>
>> I don't consider Juno a server platform  (but it's good enough for
>> development).
>
> I would expect that Juno is a superset of what servers need. If this
> ACPI patch set is sufficient to support every device present on Juno
> with an ACPI firmware, what would be a strong indication that server
> platforms work as well.
>
> OTOH, if ACPI on Juno only supports half the features that the hardware
> has, that doesn't tell us much about the suitability of ACPI for any
> real-world system, server or not.

Juno is lacking in several components compared to a server platform,
it doesn't have PCIe, SATA, or real ethernet. So it's in many ways
just a few cores with RAM and a few slow interfaces.

The scary parts from the ACPI 5.1 docs (the peripheral ones in
particular) are around the modelling of clocks and other things that
we thought ACPI was going to stay away from. Until we see how steep
that slope is, we're better off taking it easy with merging the
support. It could get quite messy very quickly, and we'd be stuck
supporting whatever solutions are tried in the first ACPI generations
forever if we do enable them now. That's the main reason for holding
off and being conservative (and seeing several real platforms and how
they end up modelling these things).

As I've also commented on some of the documents, I am not excited
about how the ACPI platform code is integrated: Add some ACPI
functions in an acpi-only file that exports some variables. Then, in a
shared file, create a completely separate code path that uses said
variables to do whatever it needs. I'm not crazy at all at the split
of code paths between the platforms, and I want to see it more data
driven (filling in shared structures and sharing code paths). There
are some challenges to make that happen but I also don't think there's
been a whole lot of effort to make it happen -- the ACPI developers
don't seem to like touching the DT code paths to make them fit better.
:-)

>> > and I think ARM64 server chips and platforms will show up before 3.18
>> > is released.
>>
>> That's what I've heard/seen. The questions I have are (a) whether
>> current ACPI patchset is enough to successfully run Linux on such
>> _hardware_ platform (maybe not fully optimised, for example just WFI
>> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
>> such platforms.
>>
>> Given the answer to (a) and what other features are needed, we may or
>> may not mandate (b). We were pretty clear few months ago that (b) is
>> still required but at the time we were only openly talking about ACPI
>> 5.0 which was lacking many features. I think we need to revisit that
>> position based on how usable ACPI 5.1 for ARM (and current kernel
>> implementation) is. Would you mind elaborating what an ACPI-only
>> platform miss?
>>
>> I would expect a new server platform designed with ACPI in mind to
>> require minimal SoC specific code, so we may only see a few patches
>> under drivers/ for such platforms adding ACPI-specific probing (possibly
>> new drivers as well if it's a new component).
>
> That is at least the hope, but I have no way of knowing whether it
> works that way or not, other than seeing the actual patches.
>
> It is rather annoying that we first have to wait for hardware
> to become available to actually see that code, but I guess that
> means that those hardware vendors no longer see ACPI as something
> on their critical path, so we definitely shouldn't hurry things
> until we understand the reason for the endless delay of platform
> support patches.

I've tried reaching out to several vendors but I've heard nothing back
from any of them. Very disappointing.

It is quite concerning that they are not willing to talk to the
community, but it also makes it easy to decide what kind of priority
we should put on reviewing and merging their patches when they do get
posted -- their lack of planning does not constitute an emergency on
our behalf.


-Olof

[PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Thu, Aug 14, 2014 at 1:53 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday 14 August 2014 11:27:23 Catalin Marinas wrote:
>> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
>> > On 2014-8-14 7:41, Rafael J. Wysocki wrote:
>> > > On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>> > >> If we consider ACPI unusable on ARM but we still want to start merging
>> > >> patches, we should rather make the config option depend on BROKEN
>> > >> (though if it is that unusable that no real platform can use it, I would
>> > >> rather not merge it at all at this stage).
>> > >
>> > > I agree here.
>> > >
>> > > I would recommend creating a separate branch for that living outside of the
>> > > mainline kernel and merging it when there are real users.
>> >
>> > Real users will coming soon, we already tested this patch set on real hardware
>> > (ARM64 Juno platform),
>>
>> I don't consider Juno a server platform  (but it's good enough for
>> development).
>
> I would expect that Juno is a superset of what servers need. If this
> ACPI patch set is sufficient to support every device present on Juno
> with an ACPI firmware, what would be a strong indication that server
> platforms work as well.
>
> OTOH, if ACPI on Juno only supports half the features that the hardware
> has, that doesn't tell us much about the suitability of ACPI for any
> real-world system, server or not.

Juno is lacking in several components compared to a server platform,
it doesn't have PCIe, SATA, or real ethernet. So it's in many ways
just a few cores with RAM and a few slow interfaces.

The scary parts from the ACPI 5.1 docs (the peripheral ones in
particular) are around the modelling of clocks and other things that
we thought ACPI was going to stay away from. Until we see how steep
that slope is, we're better off taking it easy with merging the
support. It could get quite messy very quickly, and we'd be stuck
supporting whatever solutions are tried in the first ACPI generations
forever if we do enable them now. That's the main reason for holding
off and being conservative (and seeing several real platforms and how
they end up modelling these things).

As I've also commented on some of the documents, I am not excited
about how the ACPI platform code is integrated: Add some ACPI
functions in an acpi-only file that exports some variables. Then, in a
shared file, create a completely separate code path that uses said
variables to do whatever it needs. I'm not crazy at all at the split
of code paths between the platforms, and I want to see it more data
driven (filling in shared structures and sharing code paths). There
are some challenges to make that happen but I also don't think there's
been a whole lot of effort to make it happen -- the ACPI developers
don't seem to like touching the DT code paths to make them fit better.
:-)

>> > and I think ARM64 server chips and platforms will show up before 3.18
>> > is released.
>>
>> That's what I've heard/seen. The questions I have are (a) whether
>> current ACPI patchset is enough to successfully run Linux on such
>> _hardware_ platform (maybe not fully optimised, for example just WFI
>> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
>> such platforms.
>>
>> Given the answer to (a) and what other features are needed, we may or
>> may not mandate (b). We were pretty clear few months ago that (b) is
>> still required but at the time we were only openly talking about ACPI
>> 5.0 which was lacking many features. I think we need to revisit that
>> position based on how usable ACPI 5.1 for ARM (and current kernel
>> implementation) is. Would you mind elaborating what an ACPI-only
>> platform miss?
>>
>> I would expect a new server platform designed with ACPI in mind to
>> require minimal SoC specific code, so we may only see a few patches
>> under drivers/ for such platforms adding ACPI-specific probing (possibly
>> new drivers as well if it's a new component).
>
> That is at least the hope, but I have no way of knowing whether it
> works that way or not, other than seeing the actual patches.
>
> It is rather annoying that we first have to wait for hardware
> to become available to actually see that code, but I guess that
> means that those hardware vendors no longer see ACPI as something
> on their critical path, so we definitely shouldn't hurry things
> until we understand the reason for the endless delay of platform
> support patches.

I've tried reaching out to several vendors but I've heard nothing back
from any of them. Very disappointing.

It is quite concerning that they are not willing to talk to the
community, but it also makes it easy to decide what kind of priority
we should put on reviewing and merging their patches when they do get
posted -- their lack of planning does not constitute an emergency on
our behalf.


-Olof

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-8-14 18:27, Catalin Marinas wrote:
> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>>>> If we consider ACPI unusable on ARM but we still want to start merging
>>>> patches, we should rather make the config option depend on BROKEN
>>>> (though if it is that unusable that no real platform can use it, I would
>>>> rather not merge it at all at this stage).
>>>
>>> I agree here.
>>>
>>> I would recommend creating a separate branch for that living outside of the
>>> mainline kernel and merging it when there are real users.
>>
>> Real users will coming soon, we already tested this patch set on real hardware
>> (ARM64 Juno platform),
> 
> I don't consider Juno a server platform ;) (but it's good enough for
> development).
> 
>> and I think ARM64 server chips and platforms will show up before 3.18
>> is released.
> 
> That's what I've heard/seen. The questions I have are (a) whether
> current ACPI patchset is enough to successfully run Linux on such
> _hardware_ platform (maybe not fully optimised, for example just WFI
> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> such platforms.

For (a), this patch set is only for ARM64 core, not including platform
specific device drivers, it will be covered by the binding of _DSD or
explicit definition of PNP ID/ACPI ID(s).

> 
> Given the answer to (a) and what other features are needed, we may or
> may not mandate (b). We were pretty clear few months ago that (b) is
> still required but at the time we were only openly talking about ACPI
> 5.0 which was lacking many features. I think we need to revisit that
> position based on how usable ACPI 5.1 for ARM (and current kernel
> implementation) is. Would you mind elaborating what an ACPI-only
> platform miss?

Do you mean something still missing? We still miss some features for
ARM in ACPI, but I think they are not critical, here is the list I can
remember:
- ITS for GICv3/4;
- SMMU support;
- CPU idle control.

For ACPI 5.1, it fixes many problems for ARM:
- weak definition for GIC, so we introduce visualization, v2m and
  part of GICv3/4 (redistributors) support.
- No support for PSCI. Fix it to support PSCI 0.2+;
- Not support for Always-on timer and SBSA-L1 watchdog.
- How to describe device properties, so _DSD is introduced for
  device probe.

> 
> I would expect a new server platform designed with ACPI in mind to
> require minimal SoC specific code, so we may only see a few patches
> under drivers/ for such platforms adding ACPI-specific probing (possibly
> new drivers as well if it's a new component).
> 
>> For this patch set, DT is the first class citizen at now:
>>
>> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
> 
> Not just off but, based on maturity, depend on EXPERT.

Ok. And don't set ACPI default off (pass acpi=on to enable it)?

> 
>> b) Even if we set CONFIG_ACPI=Y, we also can use DT as normal:
>>
>>   - Pass DT blob without (valid) ACPI tables (just as we boot the kernel now),
>>     ACPI will disabled in the very early stage and FDT will still to be
>>     unflattened, so will not break DT booting.
>>
>>   - We can pass ACPI=off to disable ACPI and use DT even if we got valid
>>     ACPI tables (in the v1 patch set);
>>
>> So it is safe for people who want to use DT, and didn't change any behavior
>> of DT booting except some extra test of if(acpi_disabled).
> 
> But should we require SoC firmware to provide both valid DT and ACPI
> tables so that the user can decide which one to select at boot-time?

No, I think only one of them should be provided on real platforms.

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-8-14 18:27, Catalin Marinas wrote:
> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>>>> If we consider ACPI unusable on ARM but we still want to start merging
>>>> patches, we should rather make the config option depend on BROKEN
>>>> (though if it is that unusable that no real platform can use it, I would
>>>> rather not merge it at all at this stage).
>>>
>>> I agree here.
>>>
>>> I would recommend creating a separate branch for that living outside of the
>>> mainline kernel and merging it when there are real users.
>>
>> Real users will coming soon, we already tested this patch set on real hardware
>> (ARM64 Juno platform),
> 
> I don't consider Juno a server platform ;) (but it's good enough for
> development).
> 
>> and I think ARM64 server chips and platforms will show up before 3.18
>> is released.
> 
> That's what I've heard/seen. The questions I have are (a) whether
> current ACPI patchset is enough to successfully run Linux on such
> _hardware_ platform (maybe not fully optimised, for example just WFI
> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> such platforms.

For (a), this patch set is only for ARM64 core, not including platform
specific device drivers, it will be covered by the binding of _DSD or
explicit definition of PNP ID/ACPI ID(s).

> 
> Given the answer to (a) and what other features are needed, we may or
> may not mandate (b). We were pretty clear few months ago that (b) is
> still required but at the time we were only openly talking about ACPI
> 5.0 which was lacking many features. I think we need to revisit that
> position based on how usable ACPI 5.1 for ARM (and current kernel
> implementation) is. Would you mind elaborating what an ACPI-only
> platform miss?

Do you mean something still missing? We still miss some features for
ARM in ACPI, but I think they are not critical, here is the list I can
remember:
- ITS for GICv3/4;
- SMMU support;
- CPU idle control.

For ACPI 5.1, it fixes many problems for ARM:
- weak definition for GIC, so we introduce visualization, v2m and
  part of GICv3/4 (redistributors) support.
- No support for PSCI. Fix it to support PSCI 0.2+;
- Not support for Always-on timer and SBSA-L1 watchdog.
- How to describe device properties, so _DSD is introduced for
  device probe.

> 
> I would expect a new server platform designed with ACPI in mind to
> require minimal SoC specific code, so we may only see a few patches
> under drivers/ for such platforms adding ACPI-specific probing (possibly
> new drivers as well if it's a new component).
> 
>> For this patch set, DT is the first class citizen at now:
>>
>> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
> 
> Not just off but, based on maturity, depend on EXPERT.

Ok. And don't set ACPI default off (pass acpi=on to enable it)?

> 
>> b) Even if we set CONFIG_ACPI=Y, we also can use DT as normal:
>>
>>   - Pass DT blob without (valid) ACPI tables (just as we boot the kernel now),
>>     ACPI will disabled in the very early stage and FDT will still to be
>>     unflattened, so will not break DT booting.
>>
>>   - We can pass ACPI=off to disable ACPI and use DT even if we got valid
>>     ACPI tables (in the v1 patch set);
>>
>> So it is safe for people who want to use DT, and didn't change any behavior
>> of DT booting except some extra test of if(acpi_disabled).
> 
> But should we require SoC firmware to provide both valid DT and ACPI
> tables so that the user can decide which one to select at boot-time?

No, I think only one of them should be provided on real platforms.

Thanks
Hanjun

[PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-8-14 18:27, Catalin Marinas wrote:
> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>>>> If we consider ACPI unusable on ARM but we still want to start merging
>>>> patches, we should rather make the config option depend on BROKEN
>>>> (though if it is that unusable that no real platform can use it, I would
>>>> rather not merge it at all at this stage).
>>>
>>> I agree here.
>>>
>>> I would recommend creating a separate branch for that living outside of the
>>> mainline kernel and merging it when there are real users.
>>
>> Real users will coming soon, we already tested this patch set on real hardware
>> (ARM64 Juno platform),
> 
> I don't consider Juno a server platform ;) (but it's good enough for
> development).
> 
>> and I think ARM64 server chips and platforms will show up before 3.18
>> is released.
> 
> That's what I've heard/seen. The questions I have are (a) whether
> current ACPI patchset is enough to successfully run Linux on such
> _hardware_ platform (maybe not fully optimised, for example just WFI
> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> such platforms.

For (a), this patch set is only for ARM64 core, not including platform
specific device drivers, it will be covered by the binding of _DSD or
explicit definition of PNP ID/ACPI ID(s).

> 
> Given the answer to (a) and what other features are needed, we may or
> may not mandate (b). We were pretty clear few months ago that (b) is
> still required but at the time we were only openly talking about ACPI
> 5.0 which was lacking many features. I think we need to revisit that
> position based on how usable ACPI 5.1 for ARM (and current kernel
> implementation) is. Would you mind elaborating what an ACPI-only
> platform miss?

Do you mean something still missing? We still miss some features for
ARM in ACPI, but I think they are not critical, here is the list I can
remember:
- ITS for GICv3/4;
- SMMU support;
- CPU idle control.

For ACPI 5.1, it fixes many problems for ARM:
- weak definition for GIC, so we introduce visualization, v2m and
  part of GICv3/4 (redistributors) support.
- No support for PSCI. Fix it to support PSCI 0.2+;
- Not support for Always-on timer and SBSA-L1 watchdog.
- How to describe device properties, so _DSD is introduced for
  device probe.

> 
> I would expect a new server platform designed with ACPI in mind to
> require minimal SoC specific code, so we may only see a few patches
> under drivers/ for such platforms adding ACPI-specific probing (possibly
> new drivers as well if it's a new component).
> 
>> For this patch set, DT is the first class citizen at now:
>>
>> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
> 
> Not just off but, based on maturity, depend on EXPERT.

Ok. And don't set ACPI default off (pass acpi=on to enable it)?

> 
>> b) Even if we set CONFIG_ACPI=Y, we also can use DT as normal:
>>
>>   - Pass DT blob without (valid) ACPI tables (just as we boot the kernel now),
>>     ACPI will disabled in the very early stage and FDT will still to be
>>     unflattened, so will not break DT booting.
>>
>>   - We can pass ACPI=off to disable ACPI and use DT even if we got valid
>>     ACPI tables (in the v1 patch set);
>>
>> So it is safe for people who want to use DT, and didn't change any behavior
>> of DT booting except some extra test of if(acpi_disabled).
> 
> But should we require SoC firmware to provide both valid DT and ACPI
> tables so that the user can decide which one to select at boot-time?

No, I think only one of them should be provided on real platforms.

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Catalin Marinas]

Hanjun,

On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
> On 2014-8-14 18:27, Catalin Marinas wrote:
> > On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> >> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> >>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> >>>> If we consider ACPI unusable on ARM but we still want to start merging
> >>>> patches, we should rather make the config option depend on BROKEN
> >>>> (though if it is that unusable that no real platform can use it, I would
> >>>> rather not merge it at all at this stage).
> >>>
> >>> I agree here.
> >>>
> >>> I would recommend creating a separate branch for that living outside of the
> >>> mainline kernel and merging it when there are real users.
> >>
> >> Real users will coming soon, we already tested this patch set on real hardware
> >> (ARM64 Juno platform),
> > 
> > I don't consider Juno a server platform ;) (but it's good enough for
> > development).
> > 
> >> and I think ARM64 server chips and platforms will show up before 3.18
> >> is released.
> > 
> > That's what I've heard/seen. The questions I have are (a) whether
> > current ACPI patchset is enough to successfully run Linux on such
> > _hardware_ platform (maybe not fully optimised, for example just WFI
> > cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> > such platforms.
> 
> For (a), this patch set is only for ARM64 core, not including platform
> specific device drivers, it will be covered by the binding of _DSD or
> explicit definition of PNP ID/ACPI ID(s).

So we go back to the discussions we had few months ago in Macau. I'm not
concerned about the core ARM and architected peripherals covered by ACPI
5.1 (as long as the current patches get positive technical review). But
I'm concerned about the additional bits needed for a real SoC like _DSD
definitions, how they get reviewed/accepted (or is it just the vendor's
problem?).

I think SBSA is too vague to guarantee a kernel image running on a
compliant platform without additional (vendor-specific) tweaks. So what
I asked for is (1) a document (guide) to define the strict set of ACPI
features and bindings needed for a real SoC and (2) proof that the
guidelines are enough for real hardware. I think we have (1) under
review with some good feedback so far. As for (2), we can probably only
discuss Juno openly. I think you could share the additional Juno patches
on this list so that reviewers can assess the suitability. If we deem
ACPI not (yet) suitable for Juno, is there other platform we could see
patches for?

> > Given the answer to (a) and what other features are needed, we may or
> > may not mandate (b). We were pretty clear few months ago that (b) is
> > still required but at the time we were only openly talking about ACPI
> > 5.0 which was lacking many features. I think we need to revisit that
> > position based on how usable ACPI 5.1 for ARM (and current kernel
> > implementation) is. Would you mind elaborating what an ACPI-only
> > platform miss?
> 
> Do you mean something still missing? We still miss some features for
> ARM in ACPI, but I think they are not critical, here is the list I can
> remember:
> - ITS for GICv3/4;
> - SMMU support;
> - CPU idle control.

I agree, these are not critical at this stage. But they only refer to
architected peripherals. Is there anything else missing for an SoC? Do
we need to define clocks?

> For ACPI 5.1, it fixes many problems for ARM:
> - weak definition for GIC, so we introduce visualization, v2m and
>   part of GICv3/4 (redistributors) support.
> - No support for PSCI. Fix it to support PSCI 0.2+;
> - Not support for Always-on timer and SBSA-L1 watchdog.

These are all good, that's why we shouldn't even talk about ACPI 5.0 in
the ARM context.

> - How to describe device properties, so _DSD is introduced for
>   device probe.

For the last bullet, is there any review process (at least like what we
have for DT bindings)? On top of such process, do we have guidelines and
example code on how the Linux support should be implemented. As Olof
mentioned, should we see how the DT and ACPI probing paths work
together? I really think we should be very clear here and not let
vendors invent their own independent methods.

> > I would expect a new server platform designed with ACPI in mind to
> > require minimal SoC specific code, so we may only see a few patches
> > under drivers/ for such platforms adding ACPI-specific probing (possibly
> > new drivers as well if it's a new component).
> > 
> >> For this patch set, DT is the first class citizen at now:
> >>
> >> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
> > 
> > Not just off but, based on maturity, depend on EXPERT.
> 
> Ok. And don't set ACPI default off (pass acpi=on to enable it)?

That's my view, just make it clear ACPI is experimental at the Kconfig
level because longer term we won't mandate SoCs to provide both DT and
ACPI tables.

> >> b) Even if we set CONFIG_ACPI=Y, we also can use DT as normal:
> >>
> >>   - Pass DT blob without (valid) ACPI tables (just as we boot the kernel now),
> >>     ACPI will disabled in the very early stage and FDT will still to be
> >>     unflattened, so will not break DT booting.
> >>
> >>   - We can pass ACPI=off to disable ACPI and use DT even if we got valid
> >>     ACPI tables (in the v1 patch set);
> >>
> >> So it is safe for people who want to use DT, and didn't change any behavior
> >> of DT booting except some extra test of if(acpi_disabled).
> > 
> > But should we require SoC firmware to provide both valid DT and ACPI
> > tables so that the user can decide which one to select at boot-time?
> 
> No, I think only one of them should be provided on real platforms.

That's what I thought. And such platforms would end up always passing
acpi=on anyway.

-- 
Catalin

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Catalin Marinas]

Hanjun,

On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
> On 2014-8-14 18:27, Catalin Marinas wrote:
> > On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> >> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> >>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> >>>> If we consider ACPI unusable on ARM but we still want to start merging
> >>>> patches, we should rather make the config option depend on BROKEN
> >>>> (though if it is that unusable that no real platform can use it, I would
> >>>> rather not merge it at all at this stage).
> >>>
> >>> I agree here.
> >>>
> >>> I would recommend creating a separate branch for that living outside of the
> >>> mainline kernel and merging it when there are real users.
> >>
> >> Real users will coming soon, we already tested this patch set on real hardware
> >> (ARM64 Juno platform),
> > 
> > I don't consider Juno a server platform ;) (but it's good enough for
> > development).
> > 
> >> and I think ARM64 server chips and platforms will show up before 3.18
> >> is released.
> > 
> > That's what I've heard/seen. The questions I have are (a) whether
> > current ACPI patchset is enough to successfully run Linux on such
> > _hardware_ platform (maybe not fully optimised, for example just WFI
> > cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> > such platforms.
> 
> For (a), this patch set is only for ARM64 core, not including platform
> specific device drivers, it will be covered by the binding of _DSD or
> explicit definition of PNP ID/ACPI ID(s).

So we go back to the discussions we had few months ago in Macau. I'm not
concerned about the core ARM and architected peripherals covered by ACPI
5.1 (as long as the current patches get positive technical review). But
I'm concerned about the additional bits needed for a real SoC like _DSD
definitions, how they get reviewed/accepted (or is it just the vendor's
problem?).

I think SBSA is too vague to guarantee a kernel image running on a
compliant platform without additional (vendor-specific) tweaks. So what
I asked for is (1) a document (guide) to define the strict set of ACPI
features and bindings needed for a real SoC and (2) proof that the
guidelines are enough for real hardware. I think we have (1) under
review with some good feedback so far. As for (2), we can probably only
discuss Juno openly. I think you could share the additional Juno patches
on this list so that reviewers can assess the suitability. If we deem
ACPI not (yet) suitable for Juno, is there other platform we could see
patches for?

> > Given the answer to (a) and what other features are needed, we may or
> > may not mandate (b). We were pretty clear few months ago that (b) is
> > still required but at the time we were only openly talking about ACPI
> > 5.0 which was lacking many features. I think we need to revisit that
> > position based on how usable ACPI 5.1 for ARM (and current kernel
> > implementation) is. Would you mind elaborating what an ACPI-only
> > platform miss?
> 
> Do you mean something still missing? We still miss some features for
> ARM in ACPI, but I think they are not critical, here is the list I can
> remember:
> - ITS for GICv3/4;
> - SMMU support;
> - CPU idle control.

I agree, these are not critical at this stage. But they only refer to
architected peripherals. Is there anything else missing for an SoC? Do
we need to define clocks?

> For ACPI 5.1, it fixes many problems for ARM:
> - weak definition for GIC, so we introduce visualization, v2m and
>   part of GICv3/4 (redistributors) support.
> - No support for PSCI. Fix it to support PSCI 0.2+;
> - Not support for Always-on timer and SBSA-L1 watchdog.

These are all good, that's why we shouldn't even talk about ACPI 5.0 in
the ARM context.

> - How to describe device properties, so _DSD is introduced for
>   device probe.

For the last bullet, is there any review process (at least like what we
have for DT bindings)? On top of such process, do we have guidelines and
example code on how the Linux support should be implemented. As Olof
mentioned, should we see how the DT and ACPI probing paths work
together? I really think we should be very clear here and not let
vendors invent their own independent methods.

> > I would expect a new server platform designed with ACPI in mind to
> > require minimal SoC specific code, so we may only see a few patches
> > under drivers/ for such platforms adding ACPI-specific probing (possibly
> > new drivers as well if it's a new component).
> > 
> >> For this patch set, DT is the first class citizen at now:
> >>
> >> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
> > 
> > Not just off but, based on maturity, depend on EXPERT.
> 
> Ok. And don't set ACPI default off (pass acpi=on to enable it)?

That's my view, just make it clear ACPI is experimental at the Kconfig
level because longer term we won't mandate SoCs to provide both DT and
ACPI tables.

> >> b) Even if we set CONFIG_ACPI=Y, we also can use DT as normal:
> >>
> >>   - Pass DT blob without (valid) ACPI tables (just as we boot the kernel now),
> >>     ACPI will disabled in the very early stage and FDT will still to be
> >>     unflattened, so will not break DT booting.
> >>
> >>   - We can pass ACPI=off to disable ACPI and use DT even if we got valid
> >>     ACPI tables (in the v1 patch set);
> >>
> >> So it is safe for people who want to use DT, and didn't change any behavior
> >> of DT booting except some extra test of if(acpi_disabled).
> > 
> > But should we require SoC firmware to provide both valid DT and ACPI
> > tables so that the user can decide which one to select at boot-time?
> 
> No, I think only one of them should be provided on real platforms.

That's what I thought. And such platforms would end up always passing
acpi=on anyway.

-- 
Catalin

[PATCH 19/19] Documentation: ACPI for ARM64

[Catalin Marinas]

Hanjun,

On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
> On 2014-8-14 18:27, Catalin Marinas wrote:
> > On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> >> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> >>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> >>>> If we consider ACPI unusable on ARM but we still want to start merging
> >>>> patches, we should rather make the config option depend on BROKEN
> >>>> (though if it is that unusable that no real platform can use it, I would
> >>>> rather not merge it at all at this stage).
> >>>
> >>> I agree here.
> >>>
> >>> I would recommend creating a separate branch for that living outside of the
> >>> mainline kernel and merging it when there are real users.
> >>
> >> Real users will coming soon, we already tested this patch set on real hardware
> >> (ARM64 Juno platform),
> > 
> > I don't consider Juno a server platform ;) (but it's good enough for
> > development).
> > 
> >> and I think ARM64 server chips and platforms will show up before 3.18
> >> is released.
> > 
> > That's what I've heard/seen. The questions I have are (a) whether
> > current ACPI patchset is enough to successfully run Linux on such
> > _hardware_ platform (maybe not fully optimised, for example just WFI
> > cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> > such platforms.
> 
> For (a), this patch set is only for ARM64 core, not including platform
> specific device drivers, it will be covered by the binding of _DSD or
> explicit definition of PNP ID/ACPI ID(s).

So we go back to the discussions we had few months ago in Macau. I'm not
concerned about the core ARM and architected peripherals covered by ACPI
5.1 (as long as the current patches get positive technical review). But
I'm concerned about the additional bits needed for a real SoC like _DSD
definitions, how they get reviewed/accepted (or is it just the vendor's
problem?).

I think SBSA is too vague to guarantee a kernel image running on a
compliant platform without additional (vendor-specific) tweaks. So what
I asked for is (1) a document (guide) to define the strict set of ACPI
features and bindings needed for a real SoC and (2) proof that the
guidelines are enough for real hardware. I think we have (1) under
review with some good feedback so far. As for (2), we can probably only
discuss Juno openly. I think you could share the additional Juno patches
on this list so that reviewers can assess the suitability. If we deem
ACPI not (yet) suitable for Juno, is there other platform we could see
patches for?

> > Given the answer to (a) and what other features are needed, we may or
> > may not mandate (b). We were pretty clear few months ago that (b) is
> > still required but at the time we were only openly talking about ACPI
> > 5.0 which was lacking many features. I think we need to revisit that
> > position based on how usable ACPI 5.1 for ARM (and current kernel
> > implementation) is. Would you mind elaborating what an ACPI-only
> > platform miss?
> 
> Do you mean something still missing? We still miss some features for
> ARM in ACPI, but I think they are not critical, here is the list I can
> remember:
> - ITS for GICv3/4;
> - SMMU support;
> - CPU idle control.

I agree, these are not critical at this stage. But they only refer to
architected peripherals. Is there anything else missing for an SoC? Do
we need to define clocks?

> For ACPI 5.1, it fixes many problems for ARM:
> - weak definition for GIC, so we introduce visualization, v2m and
>   part of GICv3/4 (redistributors) support.
> - No support for PSCI. Fix it to support PSCI 0.2+;
> - Not support for Always-on timer and SBSA-L1 watchdog.

These are all good, that's why we shouldn't even talk about ACPI 5.0 in
the ARM context.

> - How to describe device properties, so _DSD is introduced for
>   device probe.

For the last bullet, is there any review process (at least like what we
have for DT bindings)? On top of such process, do we have guidelines and
example code on how the Linux support should be implemented. As Olof
mentioned, should we see how the DT and ACPI probing paths work
together? I really think we should be very clear here and not let
vendors invent their own independent methods.

> > I would expect a new server platform designed with ACPI in mind to
> > require minimal SoC specific code, so we may only see a few patches
> > under drivers/ for such platforms adding ACPI-specific probing (possibly
> > new drivers as well if it's a new component).
> > 
> >> For this patch set, DT is the first class citizen at now:
> >>
> >> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
> > 
> > Not just off but, based on maturity, depend on EXPERT.
> 
> Ok. And don't set ACPI default off (pass acpi=on to enable it)?

That's my view, just make it clear ACPI is experimental at the Kconfig
level because longer term we won't mandate SoCs to provide both DT and
ACPI tables.

> >> b) Even if we set CONFIG_ACPI=Y, we also can use DT as normal:
> >>
> >>   - Pass DT blob without (valid) ACPI tables (just as we boot the kernel now),
> >>     ACPI will disabled in the very early stage and FDT will still to be
> >>     unflattened, so will not break DT booting.
> >>
> >>   - We can pass ACPI=off to disable ACPI and use DT even if we got valid
> >>     ACPI tables (in the v1 patch set);
> >>
> >> So it is safe for people who want to use DT, and didn't change any behavior
> >> of DT booting except some extra test of if(acpi_disabled).
> > 
> > But should we require SoC firmware to provide both valid DT and ACPI
> > tables so that the user can decide which one to select at boot-time?
> 
> No, I think only one of them should be provided on real platforms.

That's what I thought. And such platforms would end up always passing
acpi=on anyway.

-- 
Catalin

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Friday 15 August 2014, Olof Johansson wrote:
> On Thu, Aug 14, 2014 at 1:53 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 14 August 2014 11:27:23 Catalin Marinas wrote:
> >
> > I would expect that Juno is a superset of what servers need. If this
> > ACPI patch set is sufficient to support every device present on Juno
> > with an ACPI firmware, what would be a strong indication that server
> > platforms work as well.
> >
> > OTOH, if ACPI on Juno only supports half the features that the hardware
> > has, that doesn't tell us much about the suitability of ACPI for any
> > real-world system, server or not.
> 
> Juno is lacking in several components compared to a server platform,
> it doesn't have PCIe, SATA, or real ethernet. So it's in many ways
> just a few cores with RAM and a few slow interfaces.

I see. I wouldn't really expect SATA in a server, but the lack of
PCIe of course also implies that there is no SAS/NVMe/FCoE storage
either.

Some of the slow interfaces may actually be more interesting,
since PCI and anything attached to it should (at least in theory)
be fully discoverable and not need much ACPI support at all.

The parts that I'm particularly interested in are the interaction
with the BMC and embedded controller, and how the power management
for nondiscoverable devices is implemented through AML.

> The scary parts from the ACPI 5.1 docs (the peripheral ones in
> particular) are around the modelling of clocks and other things that
> we thought ACPI was going to stay away from. Until we see how steep
> that slope is, we're better off taking it easy with merging the
> support. It could get quite messy very quickly, and we'd be stuck
> supporting whatever solutions are tried in the first ACPI generations
> forever if we do enable them now. That's the main reason for holding
> off and being conservative (and seeing several real platforms and how
> they end up modelling these things).

Agreed. I think we had already concluded previously when discussing this
patch that the clock management in APCI-5.1 should not be used on ARM64,
but I think there is a problem one level deeper: The 5.0 and 5.1 versions
apparently add a lot of new features that are meant for either ARM64
servers or embedded x86 machines. These two typically have conflicting
requirements, and it would be better for the specification itself to
provide clearer statements to which parts apply in what use case rather
than us (the Linux people) making claims about what parts of the spec
are acceptable or not.

There are already two specified classes of systems, the legacy x86
and itanium machines, and the "reduced hardware" profile, which
apparently covers both of the new types of machines mentioned above.

What would be the process to get a clarification into the next version
of ACPI that makes them more distinct?

	Arnd

[PATCH 19/19] Documentation: ACPI for ARM64

[Arnd Bergmann]

On Friday 15 August 2014, Olof Johansson wrote:
> On Thu, Aug 14, 2014 at 1:53 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 14 August 2014 11:27:23 Catalin Marinas wrote:
> >
> > I would expect that Juno is a superset of what servers need. If this
> > ACPI patch set is sufficient to support every device present on Juno
> > with an ACPI firmware, what would be a strong indication that server
> > platforms work as well.
> >
> > OTOH, if ACPI on Juno only supports half the features that the hardware
> > has, that doesn't tell us much about the suitability of ACPI for any
> > real-world system, server or not.
> 
> Juno is lacking in several components compared to a server platform,
> it doesn't have PCIe, SATA, or real ethernet. So it's in many ways
> just a few cores with RAM and a few slow interfaces.

I see. I wouldn't really expect SATA in a server, but the lack of
PCIe of course also implies that there is no SAS/NVMe/FCoE storage
either.

Some of the slow interfaces may actually be more interesting,
since PCI and anything attached to it should (at least in theory)
be fully discoverable and not need much ACPI support at all.

The parts that I'm particularly interested in are the interaction
with the BMC and embedded controller, and how the power management
for nondiscoverable devices is implemented through AML.

> The scary parts from the ACPI 5.1 docs (the peripheral ones in
> particular) are around the modelling of clocks and other things that
> we thought ACPI was going to stay away from. Until we see how steep
> that slope is, we're better off taking it easy with merging the
> support. It could get quite messy very quickly, and we'd be stuck
> supporting whatever solutions are tried in the first ACPI generations
> forever if we do enable them now. That's the main reason for holding
> off and being conservative (and seeing several real platforms and how
> they end up modelling these things).

Agreed. I think we had already concluded previously when discussing this
patch that the clock management in APCI-5.1 should not be used on ARM64,
but I think there is a problem one level deeper: The 5.0 and 5.1 versions
apparently add a lot of new features that are meant for either ARM64
servers or embedded x86 machines. These two typically have conflicting
requirements, and it would be better for the specification itself to
provide clearer statements to which parts apply in what use case rather
than us (the Linux people) making claims about what parts of the spec
are acceptable or not.

There are already two specified classes of systems, the legacy x86
and itanium machines, and the "reduced hardware" profile, which
apparently covers both of the new types of machines mentioned above.

What would be the process to get a clarification into the next version
of ACPI that makes them more distinct?

	Arnd

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Len Brown]

> Additional driver specific
> +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> +_DSD (ACPI Section 6.2.5).

Re: _DSD

Yes.

Re: _DSM

No, not if it can be handled by _DSD.

cheers,
Len Brown, Intel Open Source Technology Center

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Len Brown]

> Additional driver specific
> +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> +_DSD (ACPI Section 6.2.5).

Re: _DSD

Yes.

Re: _DSM

No, not if it can be handled by _DSD.

cheers,
Len Brown, Intel Open Source Technology Center

[PATCH 19/19] Documentation: ACPI for ARM64

[Len Brown]

> Additional driver specific
> +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> +_DSD (ACPI Section 6.2.5).

Re: _DSD

Yes.

Re: _DSM

No, not if it can be handled by _DSD.

cheers,
Len Brown, Intel Open Source Technology Center

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1549 bytes --]

On Fri, Aug 15, 2014 at 09:49:44PM +0200, Arnd Bergmann wrote:

> Agreed. I think we had already concluded previously when discussing this
> patch that the clock management in APCI-5.1 should not be used on ARM64,
> but I think there is a problem one level deeper: The 5.0 and 5.1 versions
> apparently add a lot of new features that are meant for either ARM64
> servers or embedded x86 machines. These two typically have conflicting
> requirements, and it would be better for the specification itself to
> provide clearer statements to which parts apply in what use case rather
> than us (the Linux people) making claims about what parts of the spec
> are acceptable or not.

> There are already two specified classes of systems, the legacy x86
> and itanium machines, and the "reduced hardware" profile, which
> apparently covers both of the new types of machines mentioned above.

We also have legacy machines taking bits of the new stuff to contend
with.

> What would be the process to get a clarification into the next version
> of ACPI that makes them more distinct?

I agree with this, I actually had some patches come in this week which
seem to be worse than anything we've talked about and were intended just
key off DMI data instead of any form of platform data AFAICT.  The
pushback was that the Windows driver was doing this and the BIOS wasn't
about to change for us.  I'm not really convinced that waving some Linux
internal document about ARM servers at them is going to be terribly
persuasive to get them to improve future systems.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 19/19] Documentation: ACPI for ARM64

[Mark Brown]

On Fri, Aug 15, 2014 at 09:49:44PM +0200, Arnd Bergmann wrote:

> Agreed. I think we had already concluded previously when discussing this
> patch that the clock management in APCI-5.1 should not be used on ARM64,
> but I think there is a problem one level deeper: The 5.0 and 5.1 versions
> apparently add a lot of new features that are meant for either ARM64
> servers or embedded x86 machines. These two typically have conflicting
> requirements, and it would be better for the specification itself to
> provide clearer statements to which parts apply in what use case rather
> than us (the Linux people) making claims about what parts of the spec
> are acceptable or not.

> There are already two specified classes of systems, the legacy x86
> and itanium machines, and the "reduced hardware" profile, which
> apparently covers both of the new types of machines mentioned above.

We also have legacy machines taking bits of the new stuff to contend
with.

> What would be the process to get a clarification into the next version
> of ACPI that makes them more distinct?

I agree with this, I actually had some patches come in this week which
seem to be worse than anything we've talked about and were intended just
key off DMI data instead of any form of platform data AFAICT.  The
pushback was that the Windows driver was doing this and the BIOS wasn't
about to change for us.  I'm not really convinced that waving some Linux
internal document about ARM servers at them is going to be terribly
persuasive to get them to improve future systems.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140816/83150d07/attachment.sig>

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Graeme Gregory]

On Fri, Aug 15, 2014 at 06:43:10PM -0400, Len Brown wrote:
> > Additional driver specific
> > +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> > +_DSD (ACPI Section 6.2.5).
> 
> Re: _DSD
> 
> Yes.
> 
> Re: _DSM
> 
> No, not if it can be handled by _DSD.
> 
> cheers,
> Len Brown, Intel Open Source Technology Center

Thanks good point, Ill update that paragraph to indicate preference on
_DSD.

Graeme

[PATCH 19/19] Documentation: ACPI for ARM64

[Graeme Gregory]

On Fri, Aug 15, 2014 at 06:43:10PM -0400, Len Brown wrote:
> > Additional driver specific
> > +data should be passed in the appropriate _DSM (ACPI Section 9.14.1) method or
> > +_DSD (ACPI Section 6.2.5).
> 
> Re: _DSD
> 
> Yes.
> 
> Re: _DSM
> 
> No, not if it can be handled by _DSD.
> 
> cheers,
> Len Brown, Intel Open Source Technology Center

Thanks good point, Ill update that paragraph to indicate preference on
_DSD.

Graeme

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[graeme.gregory]

On Fri, Aug 15, 2014 at 09:49:44PM +0200, Arnd Bergmann wrote:
> What would be the process to get a clarification into the next version
> of ACPI that makes them more distinct?
> 
If you work for a UEFI member you can sign up to become a ASWG member on
the UEFI webpage. You can then submit at ECR (Engineering Change Request)
with the clarifications.

If you do not work for a UEFI member I guess you would have to do this
by proxy.

Graeme

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[graeme.gregory]

On Fri, Aug 15, 2014 at 09:49:44PM +0200, Arnd Bergmann wrote:
> What would be the process to get a clarification into the next version
> of ACPI that makes them more distinct?
> 
If you work for a UEFI member you can sign up to become a ASWG member on
the UEFI webpage. You can then submit at ECR (Engineering Change Request)
with the clarifications.

If you do not work for a UEFI member I guess you would have to do this
by proxy.

Graeme

[PATCH 19/19] Documentation: ACPI for ARM64

[graeme.gregory at linaro.org]

On Fri, Aug 15, 2014 at 09:49:44PM +0200, Arnd Bergmann wrote:
> What would be the process to get a clarification into the next version
> of ACPI that makes them more distinct?
> 
If you work for a UEFI member you can sign up to become a ASWG member on
the UEFI webpage. You can then submit at ECR (Engineering Change Request)
with the clarifications.

If you do not work for a UEFI member I guess you would have to do this
by proxy.

Graeme

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-8-15 18:01, Catalin Marinas wrote:
> Hanjun,

Hi Catalin,

> 
> On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
>> On 2014-8-14 18:27, Catalin Marinas wrote:
>>> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
>>>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
>>>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>>>>>> If we consider ACPI unusable on ARM but we still want to start merging
>>>>>> patches, we should rather make the config option depend on BROKEN
>>>>>> (though if it is that unusable that no real platform can use it, I would
>>>>>> rather not merge it at all at this stage).
>>>>>
>>>>> I agree here.
>>>>>
>>>>> I would recommend creating a separate branch for that living outside of the
>>>>> mainline kernel and merging it when there are real users.
>>>>
>>>> Real users will coming soon, we already tested this patch set on real hardware
>>>> (ARM64 Juno platform),
>>>
>>> I don't consider Juno a server platform ;) (but it's good enough for
>>> development).
>>>
>>>> and I think ARM64 server chips and platforms will show up before 3.18
>>>> is released.
>>>
>>> That's what I've heard/seen. The questions I have are (a) whether
>>> current ACPI patchset is enough to successfully run Linux on such
>>> _hardware_ platform (maybe not fully optimised, for example just WFI
>>> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
>>> such platforms.
>>
>> For (a), this patch set is only for ARM64 core, not including platform
>> specific device drivers, it will be covered by the binding of _DSD or
>> explicit definition of PNP ID/ACPI ID(s).
> 
> So we go back to the discussions we had few months ago in Macau. I'm not
> concerned about the core ARM and architected peripherals covered by ACPI
> 5.1 (as long as the current patches get positive technical review). But
> I'm concerned about the additional bits needed for a real SoC like _DSD
> definitions, how they get reviewed/accepted (or is it just the vendor's
> problem?).

As the _DSD patch set sent out by Intel folks, _DSD definitions are just
DT definitions. To use _DSD or not, I think it depends on OEM use cases,
we can bring up Juno without _DSD (Graeme is working on that, still need
some time to clean up the code).

> 
> I think SBSA is too vague to guarantee a kernel image running on a
> compliant platform without additional (vendor-specific) tweaks. So what
> I asked for is (1) a document (guide) to define the strict set of ACPI
> features and bindings needed for a real SoC and (2) proof that the
> guidelines are enough for real hardware. I think we have (1) under
> review with some good feedback so far. As for (2), we can probably only
> discuss Juno openly. I think you could share the additional Juno patches
> on this list so that reviewers can assess the suitability. If we deem
> ACPI not (yet) suitable for Juno, is there other platform we could see
> patches for?

Ok, we will send out all the patches for Juno in next version for review,
as mentioned above, we still need more time to clean up the code.

> 
>>> Given the answer to (a) and what other features are needed, we may or
>>> may not mandate (b). We were pretty clear few months ago that (b) is
>>> still required but at the time we were only openly talking about ACPI
>>> 5.0 which was lacking many features. I think we need to revisit that
>>> position based on how usable ACPI 5.1 for ARM (and current kernel
>>> implementation) is. Would you mind elaborating what an ACPI-only
>>> platform miss?
>>
>> Do you mean something still missing? We still miss some features for
>> ARM in ACPI, but I think they are not critical, here is the list I can
>> remember:
>> - ITS for GICv3/4;
>> - SMMU support;
>> - CPU idle control.
> 
> I agree, these are not critical at this stage. But they only refer to
> architected peripherals. Is there anything else missing for an SoC? Do
> we need to define clocks?

No, I prefer not. As we discussed in this thread before, we don't need
clock definition if we use SBSA compatible UART on Juno.

> 
>> For ACPI 5.1, it fixes many problems for ARM:
>> - weak definition for GIC, so we introduce visualization, v2m and
>>   part of GICv3/4 (redistributors) support.
>> - No support for PSCI. Fix it to support PSCI 0.2+;
>> - Not support for Always-on timer and SBSA-L1 watchdog.
> 
> These are all good, that's why we shouldn't even talk about ACPI 5.0 in
> the ARM context.
> 
>> - How to describe device properties, so _DSD is introduced for
>>   device probe.
> 
> For the last bullet, is there any review process (at least like what we
> have for DT bindings)? On top of such process, do we have guidelines and
> example code on how the Linux support should be implemented. As Olof
> mentioned, should we see how the DT and ACPI probing paths work
> together? I really think we should be very clear here and not let
> vendors invent their own independent methods.

As said above, Intel folks provided some good examples for that, and
clarified a lot of things:

https://lkml.org/lkml/2014/8/17/10

> 
>>> I would expect a new server platform designed with ACPI in mind to
>>> require minimal SoC specific code, so we may only see a few patches
>>> under drivers/ for such platforms adding ACPI-specific probing (possibly
>>> new drivers as well if it's a new component).
>>>
>>>> For this patch set, DT is the first class citizen at now:
>>>>
>>>> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
>>>
>>> Not just off but, based on maturity, depend on EXPERT.
>>
>> Ok. And don't set ACPI default off (pass acpi=on to enable it)?
> 
> That's my view, just make it clear ACPI is experimental at the Kconfig
> level because longer term we won't mandate SoCs to provide both DT and
> ACPI tables.

I agree with you that if we set ACPI default off, firmware will always
pass acpi=on if they want to use ACPI, so I think it would be better
to depend on EXPERT instead.

Olof, is it ok to you too?

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-8-15 18:01, Catalin Marinas wrote:
> Hanjun,

Hi Catalin,

> 
> On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
>> On 2014-8-14 18:27, Catalin Marinas wrote:
>>> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
>>>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
>>>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>>>>>> If we consider ACPI unusable on ARM but we still want to start merging
>>>>>> patches, we should rather make the config option depend on BROKEN
>>>>>> (though if it is that unusable that no real platform can use it, I would
>>>>>> rather not merge it at all at this stage).
>>>>>
>>>>> I agree here.
>>>>>
>>>>> I would recommend creating a separate branch for that living outside of the
>>>>> mainline kernel and merging it when there are real users.
>>>>
>>>> Real users will coming soon, we already tested this patch set on real hardware
>>>> (ARM64 Juno platform),
>>>
>>> I don't consider Juno a server platform ;) (but it's good enough for
>>> development).
>>>
>>>> and I think ARM64 server chips and platforms will show up before 3.18
>>>> is released.
>>>
>>> That's what I've heard/seen. The questions I have are (a) whether
>>> current ACPI patchset is enough to successfully run Linux on such
>>> _hardware_ platform (maybe not fully optimised, for example just WFI
>>> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
>>> such platforms.
>>
>> For (a), this patch set is only for ARM64 core, not including platform
>> specific device drivers, it will be covered by the binding of _DSD or
>> explicit definition of PNP ID/ACPI ID(s).
> 
> So we go back to the discussions we had few months ago in Macau. I'm not
> concerned about the core ARM and architected peripherals covered by ACPI
> 5.1 (as long as the current patches get positive technical review). But
> I'm concerned about the additional bits needed for a real SoC like _DSD
> definitions, how they get reviewed/accepted (or is it just the vendor's
> problem?).

As the _DSD patch set sent out by Intel folks, _DSD definitions are just
DT definitions. To use _DSD or not, I think it depends on OEM use cases,
we can bring up Juno without _DSD (Graeme is working on that, still need
some time to clean up the code).

> 
> I think SBSA is too vague to guarantee a kernel image running on a
> compliant platform without additional (vendor-specific) tweaks. So what
> I asked for is (1) a document (guide) to define the strict set of ACPI
> features and bindings needed for a real SoC and (2) proof that the
> guidelines are enough for real hardware. I think we have (1) under
> review with some good feedback so far. As for (2), we can probably only
> discuss Juno openly. I think you could share the additional Juno patches
> on this list so that reviewers can assess the suitability. If we deem
> ACPI not (yet) suitable for Juno, is there other platform we could see
> patches for?

Ok, we will send out all the patches for Juno in next version for review,
as mentioned above, we still need more time to clean up the code.

> 
>>> Given the answer to (a) and what other features are needed, we may or
>>> may not mandate (b). We were pretty clear few months ago that (b) is
>>> still required but at the time we were only openly talking about ACPI
>>> 5.0 which was lacking many features. I think we need to revisit that
>>> position based on how usable ACPI 5.1 for ARM (and current kernel
>>> implementation) is. Would you mind elaborating what an ACPI-only
>>> platform miss?
>>
>> Do you mean something still missing? We still miss some features for
>> ARM in ACPI, but I think they are not critical, here is the list I can
>> remember:
>> - ITS for GICv3/4;
>> - SMMU support;
>> - CPU idle control.
> 
> I agree, these are not critical at this stage. But they only refer to
> architected peripherals. Is there anything else missing for an SoC? Do
> we need to define clocks?

No, I prefer not. As we discussed in this thread before, we don't need
clock definition if we use SBSA compatible UART on Juno.

> 
>> For ACPI 5.1, it fixes many problems for ARM:
>> - weak definition for GIC, so we introduce visualization, v2m and
>>   part of GICv3/4 (redistributors) support.
>> - No support for PSCI. Fix it to support PSCI 0.2+;
>> - Not support for Always-on timer and SBSA-L1 watchdog.
> 
> These are all good, that's why we shouldn't even talk about ACPI 5.0 in
> the ARM context.
> 
>> - How to describe device properties, so _DSD is introduced for
>>   device probe.
> 
> For the last bullet, is there any review process (at least like what we
> have for DT bindings)? On top of such process, do we have guidelines and
> example code on how the Linux support should be implemented. As Olof
> mentioned, should we see how the DT and ACPI probing paths work
> together? I really think we should be very clear here and not let
> vendors invent their own independent methods.

As said above, Intel folks provided some good examples for that, and
clarified a lot of things:

https://lkml.org/lkml/2014/8/17/10

> 
>>> I would expect a new server platform designed with ACPI in mind to
>>> require minimal SoC specific code, so we may only see a few patches
>>> under drivers/ for such platforms adding ACPI-specific probing (possibly
>>> new drivers as well if it's a new component).
>>>
>>>> For this patch set, DT is the first class citizen at now:
>>>>
>>>> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
>>>
>>> Not just off but, based on maturity, depend on EXPERT.
>>
>> Ok. And don't set ACPI default off (pass acpi=on to enable it)?
> 
> That's my view, just make it clear ACPI is experimental at the Kconfig
> level because longer term we won't mandate SoCs to provide both DT and
> ACPI tables.

I agree with you that if we set ACPI default off, firmware will always
pass acpi=on if they want to use ACPI, so I think it would be better
to depend on EXPERT instead.

Olof, is it ok to you too?

Thanks
Hanjun

[PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-8-15 18:01, Catalin Marinas wrote:
> Hanjun,

Hi Catalin,

> 
> On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
>> On 2014-8-14 18:27, Catalin Marinas wrote:
>>> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
>>>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
>>>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>>>>>> If we consider ACPI unusable on ARM but we still want to start merging
>>>>>> patches, we should rather make the config option depend on BROKEN
>>>>>> (though if it is that unusable that no real platform can use it, I would
>>>>>> rather not merge it at all at this stage).
>>>>>
>>>>> I agree here.
>>>>>
>>>>> I would recommend creating a separate branch for that living outside of the
>>>>> mainline kernel and merging it when there are real users.
>>>>
>>>> Real users will coming soon, we already tested this patch set on real hardware
>>>> (ARM64 Juno platform),
>>>
>>> I don't consider Juno a server platform ;) (but it's good enough for
>>> development).
>>>
>>>> and I think ARM64 server chips and platforms will show up before 3.18
>>>> is released.
>>>
>>> That's what I've heard/seen. The questions I have are (a) whether
>>> current ACPI patchset is enough to successfully run Linux on such
>>> _hardware_ platform (maybe not fully optimised, for example just WFI
>>> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
>>> such platforms.
>>
>> For (a), this patch set is only for ARM64 core, not including platform
>> specific device drivers, it will be covered by the binding of _DSD or
>> explicit definition of PNP ID/ACPI ID(s).
> 
> So we go back to the discussions we had few months ago in Macau. I'm not
> concerned about the core ARM and architected peripherals covered by ACPI
> 5.1 (as long as the current patches get positive technical review). But
> I'm concerned about the additional bits needed for a real SoC like _DSD
> definitions, how they get reviewed/accepted (or is it just the vendor's
> problem?).

As the _DSD patch set sent out by Intel folks, _DSD definitions are just
DT definitions. To use _DSD or not, I think it depends on OEM use cases,
we can bring up Juno without _DSD (Graeme is working on that, still need
some time to clean up the code).

> 
> I think SBSA is too vague to guarantee a kernel image running on a
> compliant platform without additional (vendor-specific) tweaks. So what
> I asked for is (1) a document (guide) to define the strict set of ACPI
> features and bindings needed for a real SoC and (2) proof that the
> guidelines are enough for real hardware. I think we have (1) under
> review with some good feedback so far. As for (2), we can probably only
> discuss Juno openly. I think you could share the additional Juno patches
> on this list so that reviewers can assess the suitability. If we deem
> ACPI not (yet) suitable for Juno, is there other platform we could see
> patches for?

Ok, we will send out all the patches for Juno in next version for review,
as mentioned above, we still need more time to clean up the code.

> 
>>> Given the answer to (a) and what other features are needed, we may or
>>> may not mandate (b). We were pretty clear few months ago that (b) is
>>> still required but at the time we were only openly talking about ACPI
>>> 5.0 which was lacking many features. I think we need to revisit that
>>> position based on how usable ACPI 5.1 for ARM (and current kernel
>>> implementation) is. Would you mind elaborating what an ACPI-only
>>> platform miss?
>>
>> Do you mean something still missing? We still miss some features for
>> ARM in ACPI, but I think they are not critical, here is the list I can
>> remember:
>> - ITS for GICv3/4;
>> - SMMU support;
>> - CPU idle control.
> 
> I agree, these are not critical at this stage. But they only refer to
> architected peripherals. Is there anything else missing for an SoC? Do
> we need to define clocks?

No, I prefer not. As we discussed in this thread before, we don't need
clock definition if we use SBSA compatible UART on Juno.

> 
>> For ACPI 5.1, it fixes many problems for ARM:
>> - weak definition for GIC, so we introduce visualization, v2m and
>>   part of GICv3/4 (redistributors) support.
>> - No support for PSCI. Fix it to support PSCI 0.2+;
>> - Not support for Always-on timer and SBSA-L1 watchdog.
> 
> These are all good, that's why we shouldn't even talk about ACPI 5.0 in
> the ARM context.
> 
>> - How to describe device properties, so _DSD is introduced for
>>   device probe.
> 
> For the last bullet, is there any review process (at least like what we
> have for DT bindings)? On top of such process, do we have guidelines and
> example code on how the Linux support should be implemented. As Olof
> mentioned, should we see how the DT and ACPI probing paths work
> together? I really think we should be very clear here and not let
> vendors invent their own independent methods.

As said above, Intel folks provided some good examples for that, and
clarified a lot of things:

https://lkml.org/lkml/2014/8/17/10

> 
>>> I would expect a new server platform designed with ACPI in mind to
>>> require minimal SoC specific code, so we may only see a few patches
>>> under drivers/ for such platforms adding ACPI-specific probing (possibly
>>> new drivers as well if it's a new component).
>>>
>>>> For this patch set, DT is the first class citizen at now:
>>>>
>>>> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
>>>
>>> Not just off but, based on maturity, depend on EXPERT.
>>
>> Ok. And don't set ACPI default off (pass acpi=on to enable it)?
> 
> That's my view, just make it clear ACPI is experimental at the Kconfig
> level because longer term we won't mandate SoCs to provide both DT and
> ACPI tables.

I agree with you that if we set ACPI default off, firmware will always
pass acpi=on if they want to use ACPI, so I think it would be better
to depend on EXPERT instead.

Olof, is it ok to you too?

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Mon, Aug 18, 2014 at 10:29:26AM +0100, Hanjun Guo wrote:
> On 2014-8-15 18:01, Catalin Marinas wrote:
> > Hanjun,
> 
> Hi Catalin,
> 
> > 
> > On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
> >> On 2014-8-14 18:27, Catalin Marinas wrote:
> >>> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> >>>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> >>>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> >>>>>> If we consider ACPI unusable on ARM but we still want to start merging
> >>>>>> patches, we should rather make the config option depend on BROKEN
> >>>>>> (though if it is that unusable that no real platform can use it, I would
> >>>>>> rather not merge it at all at this stage).
> >>>>>
> >>>>> I agree here.
> >>>>>
> >>>>> I would recommend creating a separate branch for that living outside of the
> >>>>> mainline kernel and merging it when there are real users.
> >>>>
> >>>> Real users will coming soon, we already tested this patch set on real hardware
> >>>> (ARM64 Juno platform),
> >>>
> >>> I don't consider Juno a server platform ;) (but it's good enough for
> >>> development).
> >>>
> >>>> and I think ARM64 server chips and platforms will show up before 3.18
> >>>> is released.
> >>>
> >>> That's what I've heard/seen. The questions I have are (a) whether
> >>> current ACPI patchset is enough to successfully run Linux on such
> >>> _hardware_ platform (maybe not fully optimised, for example just WFI
> >>> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> >>> such platforms.
> >>
> >> For (a), this patch set is only for ARM64 core, not including platform
> >> specific device drivers, it will be covered by the binding of _DSD or
> >> explicit definition of PNP ID/ACPI ID(s).
> > 
> > So we go back to the discussions we had few months ago in Macau. I'm not
> > concerned about the core ARM and architected peripherals covered by ACPI
> > 5.1 (as long as the current patches get positive technical review). But
> > I'm concerned about the additional bits needed for a real SoC like _DSD
> > definitions, how they get reviewed/accepted (or is it just the vendor's
> > problem?).
> 
> As the _DSD patch set sent out by Intel folks, _DSD definitions are just
> DT definitions. To use _DSD or not, I think it depends on OEM use cases,
> we can bring up Juno without _DSD (Graeme is working on that, still need
> some time to clean up the code).

Let's not confuse matters by saying that _DSD is DT. DSD allows for
key-value pairs, and has a reference mechanism roughly equivalent to
phandles. That does not make them the same thing.

Not having any guidelines for vendors is an extremely bad idea. The DT
bindings we get a chance to review often have major issues. I do not
believe that vendors will do things sanely without good guidance and
strong incentives.

[...]

> >> For ACPI 5.1, it fixes many problems for ARM:
> >> - weak definition for GIC, so we introduce visualization, v2m and
> >>   part of GICv3/4 (redistributors) support.
> >> - No support for PSCI. Fix it to support PSCI 0.2+;
> >> - Not support for Always-on timer and SBSA-L1 watchdog.
> > 
> > These are all good, that's why we shouldn't even talk about ACPI 5.0 in
> > the ARM context.
> > 
> >> - How to describe device properties, so _DSD is introduced for
> >>   device probe.
> > 
> > For the last bullet, is there any review process (at least like what we
> > have for DT bindings)? On top of such process, do we have guidelines and
> > example code on how the Linux support should be implemented. As Olof
> > mentioned, should we see how the DT and ACPI probing paths work
> > together? I really think we should be very clear here and not let
> > vendors invent their own independent methods.
> 
> As said above, Intel folks provided some good examples for that, and
> clarified a lot of things:
> 
> https://lkml.org/lkml/2014/8/17/10

Quite frankly, the examples provided in the _DSD series are atrocious.
They constitute a trivial mapping of some existing DT bindings to ACPI
which do not appear to have gone through any sort of review w.r.t.
remaining idiomatic.

Thanks,
Mark.

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Mon, Aug 18, 2014 at 10:29:26AM +0100, Hanjun Guo wrote:
> On 2014-8-15 18:01, Catalin Marinas wrote:
> > Hanjun,
> 
> Hi Catalin,
> 
> > 
> > On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
> >> On 2014-8-14 18:27, Catalin Marinas wrote:
> >>> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> >>>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> >>>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> >>>>>> If we consider ACPI unusable on ARM but we still want to start merging
> >>>>>> patches, we should rather make the config option depend on BROKEN
> >>>>>> (though if it is that unusable that no real platform can use it, I would
> >>>>>> rather not merge it at all at this stage).
> >>>>>
> >>>>> I agree here.
> >>>>>
> >>>>> I would recommend creating a separate branch for that living outside of the
> >>>>> mainline kernel and merging it when there are real users.
> >>>>
> >>>> Real users will coming soon, we already tested this patch set on real hardware
> >>>> (ARM64 Juno platform),
> >>>
> >>> I don't consider Juno a server platform ;) (but it's good enough for
> >>> development).
> >>>
> >>>> and I think ARM64 server chips and platforms will show up before 3.18
> >>>> is released.
> >>>
> >>> That's what I've heard/seen. The questions I have are (a) whether
> >>> current ACPI patchset is enough to successfully run Linux on such
> >>> _hardware_ platform (maybe not fully optimised, for example just WFI
> >>> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> >>> such platforms.
> >>
> >> For (a), this patch set is only for ARM64 core, not including platform
> >> specific device drivers, it will be covered by the binding of _DSD or
> >> explicit definition of PNP ID/ACPI ID(s).
> > 
> > So we go back to the discussions we had few months ago in Macau. I'm not
> > concerned about the core ARM and architected peripherals covered by ACPI
> > 5.1 (as long as the current patches get positive technical review). But
> > I'm concerned about the additional bits needed for a real SoC like _DSD
> > definitions, how they get reviewed/accepted (or is it just the vendor's
> > problem?).
> 
> As the _DSD patch set sent out by Intel folks, _DSD definitions are just
> DT definitions. To use _DSD or not, I think it depends on OEM use cases,
> we can bring up Juno without _DSD (Graeme is working on that, still need
> some time to clean up the code).

Let's not confuse matters by saying that _DSD is DT. DSD allows for
key-value pairs, and has a reference mechanism roughly equivalent to
phandles. That does not make them the same thing.

Not having any guidelines for vendors is an extremely bad idea. The DT
bindings we get a chance to review often have major issues. I do not
believe that vendors will do things sanely without good guidance and
strong incentives.

[...]

> >> For ACPI 5.1, it fixes many problems for ARM:
> >> - weak definition for GIC, so we introduce visualization, v2m and
> >>   part of GICv3/4 (redistributors) support.
> >> - No support for PSCI. Fix it to support PSCI 0.2+;
> >> - Not support for Always-on timer and SBSA-L1 watchdog.
> > 
> > These are all good, that's why we shouldn't even talk about ACPI 5.0 in
> > the ARM context.
> > 
> >> - How to describe device properties, so _DSD is introduced for
> >>   device probe.
> > 
> > For the last bullet, is there any review process (at least like what we
> > have for DT bindings)? On top of such process, do we have guidelines and
> > example code on how the Linux support should be implemented. As Olof
> > mentioned, should we see how the DT and ACPI probing paths work
> > together? I really think we should be very clear here and not let
> > vendors invent their own independent methods.
> 
> As said above, Intel folks provided some good examples for that, and
> clarified a lot of things:
> 
> https://lkml.org/lkml/2014/8/17/10

Quite frankly, the examples provided in the _DSD series are atrocious.
They constitute a trivial mapping of some existing DT bindings to ACPI
which do not appear to have gone through any sort of review w.r.t.
remaining idiomatic.

Thanks,
Mark.

[PATCH 19/19] Documentation: ACPI for ARM64

[Mark Rutland]

On Mon, Aug 18, 2014 at 10:29:26AM +0100, Hanjun Guo wrote:
> On 2014-8-15 18:01, Catalin Marinas wrote:
> > Hanjun,
> 
> Hi Catalin,
> 
> > 
> > On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
> >> On 2014-8-14 18:27, Catalin Marinas wrote:
> >>> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> >>>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> >>>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> >>>>>> If we consider ACPI unusable on ARM but we still want to start merging
> >>>>>> patches, we should rather make the config option depend on BROKEN
> >>>>>> (though if it is that unusable that no real platform can use it, I would
> >>>>>> rather not merge it at all at this stage).
> >>>>>
> >>>>> I agree here.
> >>>>>
> >>>>> I would recommend creating a separate branch for that living outside of the
> >>>>> mainline kernel and merging it when there are real users.
> >>>>
> >>>> Real users will coming soon, we already tested this patch set on real hardware
> >>>> (ARM64 Juno platform),
> >>>
> >>> I don't consider Juno a server platform ;) (but it's good enough for
> >>> development).
> >>>
> >>>> and I think ARM64 server chips and platforms will show up before 3.18
> >>>> is released.
> >>>
> >>> That's what I've heard/seen. The questions I have are (a) whether
> >>> current ACPI patchset is enough to successfully run Linux on such
> >>> _hardware_ platform (maybe not fully optimised, for example just WFI
> >>> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> >>> such platforms.
> >>
> >> For (a), this patch set is only for ARM64 core, not including platform
> >> specific device drivers, it will be covered by the binding of _DSD or
> >> explicit definition of PNP ID/ACPI ID(s).
> > 
> > So we go back to the discussions we had few months ago in Macau. I'm not
> > concerned about the core ARM and architected peripherals covered by ACPI
> > 5.1 (as long as the current patches get positive technical review). But
> > I'm concerned about the additional bits needed for a real SoC like _DSD
> > definitions, how they get reviewed/accepted (or is it just the vendor's
> > problem?).
> 
> As the _DSD patch set sent out by Intel folks, _DSD definitions are just
> DT definitions. To use _DSD or not, I think it depends on OEM use cases,
> we can bring up Juno without _DSD (Graeme is working on that, still need
> some time to clean up the code).

Let's not confuse matters by saying that _DSD is DT. DSD allows for
key-value pairs, and has a reference mechanism roughly equivalent to
phandles. That does not make them the same thing.

Not having any guidelines for vendors is an extremely bad idea. The DT
bindings we get a chance to review often have major issues. I do not
believe that vendors will do things sanely without good guidance and
strong incentives.

[...]

> >> For ACPI 5.1, it fixes many problems for ARM:
> >> - weak definition for GIC, so we introduce visualization, v2m and
> >>   part of GICv3/4 (redistributors) support.
> >> - No support for PSCI. Fix it to support PSCI 0.2+;
> >> - Not support for Always-on timer and SBSA-L1 watchdog.
> > 
> > These are all good, that's why we shouldn't even talk about ACPI 5.0 in
> > the ARM context.
> > 
> >> - How to describe device properties, so _DSD is introduced for
> >>   device probe.
> > 
> > For the last bullet, is there any review process (at least like what we
> > have for DT bindings)? On top of such process, do we have guidelines and
> > example code on how the Linux support should be implemented. As Olof
> > mentioned, should we see how the DT and ACPI probing paths work
> > together? I really think we should be very clear here and not let
> > vendors invent their own independent methods.
> 
> As said above, Intel folks provided some good examples for that, and
> clarified a lot of things:
> 
> https://lkml.org/lkml/2014/8/17/10

Quite frankly, the examples provided in the _DSD series are atrocious.
They constitute a trivial mapping of some existing DT bindings to ACPI
which do not appear to have gone through any sort of review w.r.t.
remaining idiomatic.

Thanks,
Mark.

Re: [PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Grant Likely]

On Thu, 24 Jul 2014 21:00:12 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> the former signals to the OS that the hardware is PSCI compliant.
> The latter selects the appropriate conduit for PSCI calls by
> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> (SMC).
> 
> FADT table contains such information, parse FADT to get the flags
> for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
> function IDs, which means that only PSCI 0.2+ is supported in ACPI.
> 
> At the same time, only ACPI 5.1 or higher verison supports PSCI,
> and FADT Major.Minor version was introduced in ACPI 5.1, so we
> will check the version and only parse FADT table with version >= 5.1.
> 
> If firmware provides ACPI tables with ACPI version less than 5.1,
> OS will be messed up with those information and have no way to
> bring up secondery CPUs, so disable ACPI if we get an FADT table
> with version less that 5.1.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h |    2 +
>  arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
>  arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
>  arch/arm64/kernel/setup.c     |    2 +
>  4 files changed, 121 insertions(+), 28 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 44b617f..67dac90 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -18,6 +18,8 @@ extern int acpi_disabled;
>  extern int acpi_noirq;
>  extern int acpi_pci_disabled;
>  extern int acpi_strict;
> +extern int acpi_psci_present;
> +extern int acpi_psci_use_hvc;
>  
>  static inline void disable_acpi(void)
>  {
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index f5a10b5..374926f 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -11,6 +11,8 @@
>   *  published by the Free Software Foundation.
>   */
>  
> +#define pr_fmt(fmt) "ACPI: " fmt
> +
>  #include <linux/init.h>
>  #include <linux/acpi.h>
>  #include <linux/cpumask.h>
> @@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
>  int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
>  EXPORT_SYMBOL(acpi_pci_disabled);
>  
> +/* 1 to indicate PSCI is implemented */
> +int acpi_psci_present;
> +
> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> +int acpi_psci_use_hvc;
> +
>  /*
>   * __acpi_map_table() will be called before page_init(), so early_ioremap()
>   * or early_memremap() should be called here to for ACPI table mapping.
> @@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>  	early_iounmap(map, size);
>  }
>  
> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> +{
> +	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> +
> +	/*
> +	 * Revision in table header is the FADT Major version,
> +	 * and there is a minor version of FADT which was introduced
> +	 * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
> +	 * to get arm boot flags, or we will disable ACPI.
> +	 */
> +	if (table->revision < 5 || fadt->minor_version < 1) {
> +		pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
> +			table->revision, fadt->minor_version);
> +		acpi_psci_present = 0;
> +		disable_acpi();
> +		return -EINVAL;
> +	}
> +
> +	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
> +		acpi_psci_present = 1;
> +
> +	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
> +		acpi_psci_use_hvc = 1;
> +
> +	return 0;
> +}
> +
>  /*
>   * acpi_boot_table_init() called from setup_arch(), always.
>   *	1. find RSDP and get its address, and then find XSDT
> @@ -75,6 +110,21 @@ void __init acpi_boot_table_init(void)
>  	}
>  }
>  
> +int __init acpi_boot_init(void)
> +{
> +	int err = 0;
> +
> +	/* If acpi_disabled, bail out */
> +	if (acpi_disabled)
> +		return -ENODEV;
> +
> +	err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
> +	if (err)
> +		pr_err("Can't find FADT\n");
> +
> +	return err;
> +}
> +
>  static int __init parse_acpi(char *arg)
>  {
>  	if (!arg)
> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> index 9e9798f..adb25f3 100644
> --- a/arch/arm64/kernel/psci.c
> +++ b/arch/arm64/kernel/psci.c
> @@ -15,6 +15,7 @@
>  
>  #define pr_fmt(fmt) "psci: " fmt
>  
> +#include <linux/acpi.h>
>  #include <linux/init.h>
>  #include <linux/of.h>
>  #include <linux/smp.h>
> @@ -231,6 +232,33 @@ static void psci_sys_poweroff(void)
>  	invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
>  }
>  
> +static void psci_0_2_set_functions(void)
> +{
> +	pr_info("Using standard PSCI v0.2 function IDs\n");
> +	psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
> +	psci_ops.cpu_suspend = psci_cpu_suspend;
> +
> +	psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
> +	psci_ops.cpu_off = psci_cpu_off;
> +
> +	psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
> +	psci_ops.cpu_on = psci_cpu_on;
> +
> +	psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
> +	psci_ops.migrate = psci_migrate;
> +
> +	psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
> +	psci_ops.affinity_info = psci_affinity_info;
> +
> +	psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
> +		PSCI_0_2_FN_MIGRATE_INFO_TYPE;
> +	psci_ops.migrate_info_type = psci_migrate_info_type;
> +
> +	arm_pm_restart = psci_sys_reset;
> +
> +	pm_power_off = psci_sys_poweroff;
> +}
> +
>  /*
>   * PSCI Function IDs for v0.2+ are well defined so use
>   * standard values.
> @@ -264,29 +292,7 @@ static int psci_0_2_init(struct device_node *np)
>  		}
>  	}
>  
> -	pr_info("Using standard PSCI v0.2 function IDs\n");
> -	psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
> -	psci_ops.cpu_suspend = psci_cpu_suspend;
> -
> -	psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
> -	psci_ops.cpu_off = psci_cpu_off;
> -
> -	psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
> -	psci_ops.cpu_on = psci_cpu_on;
> -
> -	psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
> -	psci_ops.migrate = psci_migrate;
> -
> -	psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
> -	psci_ops.affinity_info = psci_affinity_info;
> -
> -	psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
> -		PSCI_0_2_FN_MIGRATE_INFO_TYPE;
> -	psci_ops.migrate_info_type = psci_migrate_info_type;
> -
> -	arm_pm_restart = psci_sys_reset;
> -
> -	pm_power_off = psci_sys_poweroff;
> +	psci_0_2_set_functions();
>  
>  out_put_node:
>  	of_node_put(np);
> @@ -333,6 +339,33 @@ out_put_node:
>  	return err;
>  }
>  
> +#ifdef CONFIG_ACPI
> +static int get_set_conduit_method_acpi(void)
> +{
> +	if (acpi_psci_use_hvc)
> +		invoke_psci_fn = __invoke_psci_fn_hvc;
> +	else
> +		invoke_psci_fn = __invoke_psci_fn_smc;
> +
> +	return 0;
> +}
> +
> +/* We use PSCI 0.2+ when ACPI is deployed */
> +static int psci_0_2_init_acpi(void)
> +{
> +	get_set_conduit_method_acpi();
> +
> +	psci_0_2_set_functions();
> +
> +	return 0;
> +}
> +#else
> +static inline int psci_0_2_init_acpi(void)
> +{
> +	return -ENODEV;
> +}
> +#endif
> +
>  static const struct of_device_id psci_of_match[] __initconst = {
>  	{ .compatible = "arm,psci",	.data = psci_0_1_init},
>  	{ .compatible = "arm,psci-0.2",	.data = psci_0_2_init},
> @@ -345,13 +378,19 @@ int __init psci_init(void)
>  	const struct of_device_id *matched_np;
>  	psci_initcall_t init_fn;
>  
> -	np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> +	if (acpi_disabled) {
> +		np = of_find_matching_node_and_match(NULL,
> +				psci_of_match, &matched_np);
>  
> -	if (!np)
> -		return -ENODEV;
> +		if (!np)
> +			return -ENODEV;
> +
> +		init_fn = (psci_initcall_t)matched_np->data;
> +
> +		return init_fn(np);
> +	}
>  
> -	init_fn = (psci_initcall_t)matched_np->data;
> -	return init_fn(np);
> +	return psci_0_2_init_acpi();
>  }

So, while the functionality is sound, this is kind of a stinky diff. The
ACPI path should not push the OF code into a sub branch. Make it look
like this instead (with the advantage that the diff will be simpler):

+	if (IS_ENABLED(CONFIG_ACPI) && !acpi_disabled)
+		return psci_0_2_init_acpi();

 	np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
 
 	if (!np)
 		return -ENODEV;
 
 	init_fn = (psci_initcall_t)matched_np->data;
 	return init_fn(np);

g.

Re: [PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Grant Likely]

On Thu, 24 Jul 2014 21:00:12 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> the former signals to the OS that the hardware is PSCI compliant.
> The latter selects the appropriate conduit for PSCI calls by
> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> (SMC).
> 
> FADT table contains such information, parse FADT to get the flags
> for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
> function IDs, which means that only PSCI 0.2+ is supported in ACPI.
> 
> At the same time, only ACPI 5.1 or higher verison supports PSCI,
> and FADT Major.Minor version was introduced in ACPI 5.1, so we
> will check the version and only parse FADT table with version >= 5.1.
> 
> If firmware provides ACPI tables with ACPI version less than 5.1,
> OS will be messed up with those information and have no way to
> bring up secondery CPUs, so disable ACPI if we get an FADT table
> with version less that 5.1.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h |    2 +
>  arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
>  arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
>  arch/arm64/kernel/setup.c     |    2 +
>  4 files changed, 121 insertions(+), 28 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 44b617f..67dac90 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -18,6 +18,8 @@ extern int acpi_disabled;
>  extern int acpi_noirq;
>  extern int acpi_pci_disabled;
>  extern int acpi_strict;
> +extern int acpi_psci_present;
> +extern int acpi_psci_use_hvc;
>  
>  static inline void disable_acpi(void)
>  {
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index f5a10b5..374926f 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -11,6 +11,8 @@
>   *  published by the Free Software Foundation.
>   */
>  
> +#define pr_fmt(fmt) "ACPI: " fmt
> +
>  #include <linux/init.h>
>  #include <linux/acpi.h>
>  #include <linux/cpumask.h>
> @@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
>  int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
>  EXPORT_SYMBOL(acpi_pci_disabled);
>  
> +/* 1 to indicate PSCI is implemented */
> +int acpi_psci_present;
> +
> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> +int acpi_psci_use_hvc;
> +
>  /*
>   * __acpi_map_table() will be called before page_init(), so early_ioremap()
>   * or early_memremap() should be called here to for ACPI table mapping.
> @@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>  	early_iounmap(map, size);
>  }
>  
> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> +{
> +	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> +
> +	/*
> +	 * Revision in table header is the FADT Major version,
> +	 * and there is a minor version of FADT which was introduced
> +	 * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
> +	 * to get arm boot flags, or we will disable ACPI.
> +	 */
> +	if (table->revision < 5 || fadt->minor_version < 1) {
> +		pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
> +			table->revision, fadt->minor_version);
> +		acpi_psci_present = 0;
> +		disable_acpi();
> +		return -EINVAL;
> +	}
> +
> +	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
> +		acpi_psci_present = 1;
> +
> +	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
> +		acpi_psci_use_hvc = 1;
> +
> +	return 0;
> +}
> +
>  /*
>   * acpi_boot_table_init() called from setup_arch(), always.
>   *	1. find RSDP and get its address, and then find XSDT
> @@ -75,6 +110,21 @@ void __init acpi_boot_table_init(void)
>  	}
>  }
>  
> +int __init acpi_boot_init(void)
> +{
> +	int err = 0;
> +
> +	/* If acpi_disabled, bail out */
> +	if (acpi_disabled)
> +		return -ENODEV;
> +
> +	err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
> +	if (err)
> +		pr_err("Can't find FADT\n");
> +
> +	return err;
> +}
> +
>  static int __init parse_acpi(char *arg)
>  {
>  	if (!arg)
> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> index 9e9798f..adb25f3 100644
> --- a/arch/arm64/kernel/psci.c
> +++ b/arch/arm64/kernel/psci.c
> @@ -15,6 +15,7 @@
>  
>  #define pr_fmt(fmt) "psci: " fmt
>  
> +#include <linux/acpi.h>
>  #include <linux/init.h>
>  #include <linux/of.h>
>  #include <linux/smp.h>
> @@ -231,6 +232,33 @@ static void psci_sys_poweroff(void)
>  	invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
>  }
>  
> +static void psci_0_2_set_functions(void)
> +{
> +	pr_info("Using standard PSCI v0.2 function IDs\n");
> +	psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
> +	psci_ops.cpu_suspend = psci_cpu_suspend;
> +
> +	psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
> +	psci_ops.cpu_off = psci_cpu_off;
> +
> +	psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
> +	psci_ops.cpu_on = psci_cpu_on;
> +
> +	psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
> +	psci_ops.migrate = psci_migrate;
> +
> +	psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
> +	psci_ops.affinity_info = psci_affinity_info;
> +
> +	psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
> +		PSCI_0_2_FN_MIGRATE_INFO_TYPE;
> +	psci_ops.migrate_info_type = psci_migrate_info_type;
> +
> +	arm_pm_restart = psci_sys_reset;
> +
> +	pm_power_off = psci_sys_poweroff;
> +}
> +
>  /*
>   * PSCI Function IDs for v0.2+ are well defined so use
>   * standard values.
> @@ -264,29 +292,7 @@ static int psci_0_2_init(struct device_node *np)
>  		}
>  	}
>  
> -	pr_info("Using standard PSCI v0.2 function IDs\n");
> -	psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
> -	psci_ops.cpu_suspend = psci_cpu_suspend;
> -
> -	psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
> -	psci_ops.cpu_off = psci_cpu_off;
> -
> -	psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
> -	psci_ops.cpu_on = psci_cpu_on;
> -
> -	psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
> -	psci_ops.migrate = psci_migrate;
> -
> -	psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
> -	psci_ops.affinity_info = psci_affinity_info;
> -
> -	psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
> -		PSCI_0_2_FN_MIGRATE_INFO_TYPE;
> -	psci_ops.migrate_info_type = psci_migrate_info_type;
> -
> -	arm_pm_restart = psci_sys_reset;
> -
> -	pm_power_off = psci_sys_poweroff;
> +	psci_0_2_set_functions();
>  
>  out_put_node:
>  	of_node_put(np);
> @@ -333,6 +339,33 @@ out_put_node:
>  	return err;
>  }
>  
> +#ifdef CONFIG_ACPI
> +static int get_set_conduit_method_acpi(void)
> +{
> +	if (acpi_psci_use_hvc)
> +		invoke_psci_fn = __invoke_psci_fn_hvc;
> +	else
> +		invoke_psci_fn = __invoke_psci_fn_smc;
> +
> +	return 0;
> +}
> +
> +/* We use PSCI 0.2+ when ACPI is deployed */
> +static int psci_0_2_init_acpi(void)
> +{
> +	get_set_conduit_method_acpi();
> +
> +	psci_0_2_set_functions();
> +
> +	return 0;
> +}
> +#else
> +static inline int psci_0_2_init_acpi(void)
> +{
> +	return -ENODEV;
> +}
> +#endif
> +
>  static const struct of_device_id psci_of_match[] __initconst = {
>  	{ .compatible = "arm,psci",	.data = psci_0_1_init},
>  	{ .compatible = "arm,psci-0.2",	.data = psci_0_2_init},
> @@ -345,13 +378,19 @@ int __init psci_init(void)
>  	const struct of_device_id *matched_np;
>  	psci_initcall_t init_fn;
>  
> -	np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> +	if (acpi_disabled) {
> +		np = of_find_matching_node_and_match(NULL,
> +				psci_of_match, &matched_np);
>  
> -	if (!np)
> -		return -ENODEV;
> +		if (!np)
> +			return -ENODEV;
> +
> +		init_fn = (psci_initcall_t)matched_np->data;
> +
> +		return init_fn(np);
> +	}
>  
> -	init_fn = (psci_initcall_t)matched_np->data;
> -	return init_fn(np);
> +	return psci_0_2_init_acpi();
>  }

So, while the functionality is sound, this is kind of a stinky diff. The
ACPI path should not push the OF code into a sub branch. Make it look
like this instead (with the advantage that the diff will be simpler):

+	if (IS_ENABLED(CONFIG_ACPI) && !acpi_disabled)
+		return psci_0_2_init_acpi();

 	np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
 
 	if (!np)
 		return -ENODEV;
 
 	init_fn = (psci_initcall_t)matched_np->data;
 	return init_fn(np);

g.

[PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Grant Likely]

On Thu, 24 Jul 2014 21:00:12 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> the former signals to the OS that the hardware is PSCI compliant.
> The latter selects the appropriate conduit for PSCI calls by
> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> (SMC).
> 
> FADT table contains such information, parse FADT to get the flags
> for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
> function IDs, which means that only PSCI 0.2+ is supported in ACPI.
> 
> At the same time, only ACPI 5.1 or higher verison supports PSCI,
> and FADT Major.Minor version was introduced in ACPI 5.1, so we
> will check the version and only parse FADT table with version >= 5.1.
> 
> If firmware provides ACPI tables with ACPI version less than 5.1,
> OS will be messed up with those information and have no way to
> bring up secondery CPUs, so disable ACPI if we get an FADT table
> with version less that 5.1.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> ---
>  arch/arm64/include/asm/acpi.h |    2 +
>  arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
>  arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
>  arch/arm64/kernel/setup.c     |    2 +
>  4 files changed, 121 insertions(+), 28 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index 44b617f..67dac90 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -18,6 +18,8 @@ extern int acpi_disabled;
>  extern int acpi_noirq;
>  extern int acpi_pci_disabled;
>  extern int acpi_strict;
> +extern int acpi_psci_present;
> +extern int acpi_psci_use_hvc;
>  
>  static inline void disable_acpi(void)
>  {
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index f5a10b5..374926f 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -11,6 +11,8 @@
>   *  published by the Free Software Foundation.
>   */
>  
> +#define pr_fmt(fmt) "ACPI: " fmt
> +
>  #include <linux/init.h>
>  #include <linux/acpi.h>
>  #include <linux/cpumask.h>
> @@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
>  int acpi_pci_disabled;		/* skip ACPI PCI scan and IRQ initialization */
>  EXPORT_SYMBOL(acpi_pci_disabled);
>  
> +/* 1 to indicate PSCI is implemented */
> +int acpi_psci_present;
> +
> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> +int acpi_psci_use_hvc;
> +
>  /*
>   * __acpi_map_table() will be called before page_init(), so early_ioremap()
>   * or early_memremap() should be called here to for ACPI table mapping.
> @@ -54,6 +62,33 @@ void __init __acpi_unmap_table(char *map, unsigned long size)
>  	early_iounmap(map, size);
>  }
>  
> +static int __init acpi_parse_fadt(struct acpi_table_header *table)
> +{
> +	struct acpi_table_fadt *fadt = (struct acpi_table_fadt *)table;
> +
> +	/*
> +	 * Revision in table header is the FADT Major version,
> +	 * and there is a minor version of FADT which was introduced
> +	 * by ACPI 5.1, we only deal with ACPI 5.1 or higher version
> +	 * to get arm boot flags, or we will disable ACPI.
> +	 */
> +	if (table->revision < 5 || fadt->minor_version < 1) {
> +		pr_info("FADT version is %d.%d, no PSCI support, should be 5.1 or higher\n",
> +			table->revision, fadt->minor_version);
> +		acpi_psci_present = 0;
> +		disable_acpi();
> +		return -EINVAL;
> +	}
> +
> +	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_COMPLIANT)
> +		acpi_psci_present = 1;
> +
> +	if (acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC)
> +		acpi_psci_use_hvc = 1;
> +
> +	return 0;
> +}
> +
>  /*
>   * acpi_boot_table_init() called from setup_arch(), always.
>   *	1. find RSDP and get its address, and then find XSDT
> @@ -75,6 +110,21 @@ void __init acpi_boot_table_init(void)
>  	}
>  }
>  
> +int __init acpi_boot_init(void)
> +{
> +	int err = 0;
> +
> +	/* If acpi_disabled, bail out */
> +	if (acpi_disabled)
> +		return -ENODEV;
> +
> +	err = acpi_table_parse(ACPI_SIG_FADT, acpi_parse_fadt);
> +	if (err)
> +		pr_err("Can't find FADT\n");
> +
> +	return err;
> +}
> +
>  static int __init parse_acpi(char *arg)
>  {
>  	if (!arg)
> diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
> index 9e9798f..adb25f3 100644
> --- a/arch/arm64/kernel/psci.c
> +++ b/arch/arm64/kernel/psci.c
> @@ -15,6 +15,7 @@
>  
>  #define pr_fmt(fmt) "psci: " fmt
>  
> +#include <linux/acpi.h>
>  #include <linux/init.h>
>  #include <linux/of.h>
>  #include <linux/smp.h>
> @@ -231,6 +232,33 @@ static void psci_sys_poweroff(void)
>  	invoke_psci_fn(PSCI_0_2_FN_SYSTEM_OFF, 0, 0, 0);
>  }
>  
> +static void psci_0_2_set_functions(void)
> +{
> +	pr_info("Using standard PSCI v0.2 function IDs\n");
> +	psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
> +	psci_ops.cpu_suspend = psci_cpu_suspend;
> +
> +	psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
> +	psci_ops.cpu_off = psci_cpu_off;
> +
> +	psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
> +	psci_ops.cpu_on = psci_cpu_on;
> +
> +	psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
> +	psci_ops.migrate = psci_migrate;
> +
> +	psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
> +	psci_ops.affinity_info = psci_affinity_info;
> +
> +	psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
> +		PSCI_0_2_FN_MIGRATE_INFO_TYPE;
> +	psci_ops.migrate_info_type = psci_migrate_info_type;
> +
> +	arm_pm_restart = psci_sys_reset;
> +
> +	pm_power_off = psci_sys_poweroff;
> +}
> +
>  /*
>   * PSCI Function IDs for v0.2+ are well defined so use
>   * standard values.
> @@ -264,29 +292,7 @@ static int psci_0_2_init(struct device_node *np)
>  		}
>  	}
>  
> -	pr_info("Using standard PSCI v0.2 function IDs\n");
> -	psci_function_id[PSCI_FN_CPU_SUSPEND] = PSCI_0_2_FN64_CPU_SUSPEND;
> -	psci_ops.cpu_suspend = psci_cpu_suspend;
> -
> -	psci_function_id[PSCI_FN_CPU_OFF] = PSCI_0_2_FN_CPU_OFF;
> -	psci_ops.cpu_off = psci_cpu_off;
> -
> -	psci_function_id[PSCI_FN_CPU_ON] = PSCI_0_2_FN64_CPU_ON;
> -	psci_ops.cpu_on = psci_cpu_on;
> -
> -	psci_function_id[PSCI_FN_MIGRATE] = PSCI_0_2_FN64_MIGRATE;
> -	psci_ops.migrate = psci_migrate;
> -
> -	psci_function_id[PSCI_FN_AFFINITY_INFO] = PSCI_0_2_FN64_AFFINITY_INFO;
> -	psci_ops.affinity_info = psci_affinity_info;
> -
> -	psci_function_id[PSCI_FN_MIGRATE_INFO_TYPE] =
> -		PSCI_0_2_FN_MIGRATE_INFO_TYPE;
> -	psci_ops.migrate_info_type = psci_migrate_info_type;
> -
> -	arm_pm_restart = psci_sys_reset;
> -
> -	pm_power_off = psci_sys_poweroff;
> +	psci_0_2_set_functions();
>  
>  out_put_node:
>  	of_node_put(np);
> @@ -333,6 +339,33 @@ out_put_node:
>  	return err;
>  }
>  
> +#ifdef CONFIG_ACPI
> +static int get_set_conduit_method_acpi(void)
> +{
> +	if (acpi_psci_use_hvc)
> +		invoke_psci_fn = __invoke_psci_fn_hvc;
> +	else
> +		invoke_psci_fn = __invoke_psci_fn_smc;
> +
> +	return 0;
> +}
> +
> +/* We use PSCI 0.2+ when ACPI is deployed */
> +static int psci_0_2_init_acpi(void)
> +{
> +	get_set_conduit_method_acpi();
> +
> +	psci_0_2_set_functions();
> +
> +	return 0;
> +}
> +#else
> +static inline int psci_0_2_init_acpi(void)
> +{
> +	return -ENODEV;
> +}
> +#endif
> +
>  static const struct of_device_id psci_of_match[] __initconst = {
>  	{ .compatible = "arm,psci",	.data = psci_0_1_init},
>  	{ .compatible = "arm,psci-0.2",	.data = psci_0_2_init},
> @@ -345,13 +378,19 @@ int __init psci_init(void)
>  	const struct of_device_id *matched_np;
>  	psci_initcall_t init_fn;
>  
> -	np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> +	if (acpi_disabled) {
> +		np = of_find_matching_node_and_match(NULL,
> +				psci_of_match, &matched_np);
>  
> -	if (!np)
> -		return -ENODEV;
> +		if (!np)
> +			return -ENODEV;
> +
> +		init_fn = (psci_initcall_t)matched_np->data;
> +
> +		return init_fn(np);
> +	}
>  
> -	init_fn = (psci_initcall_t)matched_np->data;
> -	return init_fn(np);
> +	return psci_0_2_init_acpi();
>  }

So, while the functionality is sound, this is kind of a stinky diff. The
ACPI path should not push the OF code into a sub branch. Make it look
like this instead (with the advantage that the diff will be simpler):

+	if (IS_ENABLED(CONFIG_ACPI) && !acpi_disabled)
+		return psci_0_2_init_acpi();

 	np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
 
 	if (!np)
 		return -ENODEV;
 
 	init_fn = (psci_initcall_t)matched_np->data;
 	return init_fn(np);

g.

Re: [PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Grant Likely]

On Thu, 31 Jul 2014 18:23:18 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> On 2014-7-31 12:22, Olof Johansson wrote:
> > Hi,
> 
> Hi Olof,
> 
> > 
> > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> >> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> >> the former signals to the OS that the hardware is PSCI compliant.
> >> The latter selects the appropriate conduit for PSCI calls by
> >> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> >> (SMC).
> >>
> >> FADT table contains such information, parse FADT to get the flags
> >> for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
> >> function IDs, which means that only PSCI 0.2+ is supported in ACPI.
> >>
> >> At the same time, only ACPI 5.1 or higher verison supports PSCI,
> >> and FADT Major.Minor version was introduced in ACPI 5.1, so we
> >> will check the version and only parse FADT table with version >= 5.1.
> >>
> >> If firmware provides ACPI tables with ACPI version less than 5.1,
> >> OS will be messed up with those information and have no way to
> >> bring up secondery CPUs, so disable ACPI if we get an FADT table
> >> with version less that 5.1.
> >>
> >> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> >> ---
> >>  arch/arm64/include/asm/acpi.h |    2 +
> >>  arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
> >>  arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
> >>  arch/arm64/kernel/setup.c     |    2 +
> >>  4 files changed, 121 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> >> index 44b617f..67dac90 100644
> >> --- a/arch/arm64/include/asm/acpi.h
> >> +++ b/arch/arm64/include/asm/acpi.h
> >> @@ -18,6 +18,8 @@ extern int acpi_disabled;
> >>  extern int acpi_noirq;
> >>  extern int acpi_pci_disabled;
> >>  extern int acpi_strict;
> >> +extern int acpi_psci_present;
> >> +extern int acpi_psci_use_hvc;
> >>
> >>  static inline void disable_acpi(void)
> >>  {
> >> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> >> index f5a10b5..374926f 100644
> >> --- a/arch/arm64/kernel/acpi.c
> >> +++ b/arch/arm64/kernel/acpi.c
> >> @@ -11,6 +11,8 @@
> >>   *  published by the Free Software Foundation.
> >>   */
> >>
> >> +#define pr_fmt(fmt) "ACPI: " fmt
> >> +
> >>  #include <linux/init.h>
> >>  #include <linux/acpi.h>
> >>  #include <linux/cpumask.h>
> >> @@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
> >>  int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
> >>  EXPORT_SYMBOL(acpi_pci_disabled);
> >>
> >> +/* 1 to indicate PSCI is implemented */
> >> +int acpi_psci_present;
> >> +
> >> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> >> +int acpi_psci_use_hvc;
> > 
> > Here's a prime example of where it would just make more sense to
> > populate DT based on what's in the ACPI info.
> > 
> > Have a acpi_parse_fadt() that, if needed, creates a /psci node in the
> > system-wide DT and populates it with the few properties needed.
> > 
> > That way, the rest of the code path in the kernel setup is identical,
> > instead of dealing with separate functions for setup, two exported
> > variables just to communicate the state, and so on. It's just extra
> > complexity for no good reason. The ACPi side code isn't even adding
> > significant complexity compared to this. We'll need to add an
> > of_add_node() property though.
> 
> Yes, this will make the code path in the kernel setup is identical, but
> I think mixture of ACPI and DT (converting ACPI into DT at run-time) is
> not a good solution, and this had been discussed last year:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/211662.html

Agreed. I don't want to get into populating DT structures with ACPI
data. I think doing so ends up increasing the conceptual complexity.

> >> -       np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> >> +       if (acpi_disabled) {
> >> +               np = of_find_matching_node_and_match(NULL,
> >> +                               psci_of_match, &matched_np);
> > 
> > Ideally this code should go away by changing the rest of it, but for
> > future cases: It'd be a lot cleaner to do this as:
> > 
> >         if (!acpi_disabled)
> >                 return psci_0_2_init_acpi();
> > 
> > ... then fall through to the current implementation instead.
> 
> I prefer this one :)

Good! :-)

g.

Re: [PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Grant Likely]

On Thu, 31 Jul 2014 18:23:18 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> On 2014-7-31 12:22, Olof Johansson wrote:
> > Hi,
> 
> Hi Olof,
> 
> > 
> > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> >> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> >> the former signals to the OS that the hardware is PSCI compliant.
> >> The latter selects the appropriate conduit for PSCI calls by
> >> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> >> (SMC).
> >>
> >> FADT table contains such information, parse FADT to get the flags
> >> for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
> >> function IDs, which means that only PSCI 0.2+ is supported in ACPI.
> >>
> >> At the same time, only ACPI 5.1 or higher verison supports PSCI,
> >> and FADT Major.Minor version was introduced in ACPI 5.1, so we
> >> will check the version and only parse FADT table with version >= 5.1.
> >>
> >> If firmware provides ACPI tables with ACPI version less than 5.1,
> >> OS will be messed up with those information and have no way to
> >> bring up secondery CPUs, so disable ACPI if we get an FADT table
> >> with version less that 5.1.
> >>
> >> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> >> ---
> >>  arch/arm64/include/asm/acpi.h |    2 +
> >>  arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
> >>  arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
> >>  arch/arm64/kernel/setup.c     |    2 +
> >>  4 files changed, 121 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> >> index 44b617f..67dac90 100644
> >> --- a/arch/arm64/include/asm/acpi.h
> >> +++ b/arch/arm64/include/asm/acpi.h
> >> @@ -18,6 +18,8 @@ extern int acpi_disabled;
> >>  extern int acpi_noirq;
> >>  extern int acpi_pci_disabled;
> >>  extern int acpi_strict;
> >> +extern int acpi_psci_present;
> >> +extern int acpi_psci_use_hvc;
> >>
> >>  static inline void disable_acpi(void)
> >>  {
> >> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> >> index f5a10b5..374926f 100644
> >> --- a/arch/arm64/kernel/acpi.c
> >> +++ b/arch/arm64/kernel/acpi.c
> >> @@ -11,6 +11,8 @@
> >>   *  published by the Free Software Foundation.
> >>   */
> >>
> >> +#define pr_fmt(fmt) "ACPI: " fmt
> >> +
> >>  #include <linux/init.h>
> >>  #include <linux/acpi.h>
> >>  #include <linux/cpumask.h>
> >> @@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
> >>  int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
> >>  EXPORT_SYMBOL(acpi_pci_disabled);
> >>
> >> +/* 1 to indicate PSCI is implemented */
> >> +int acpi_psci_present;
> >> +
> >> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> >> +int acpi_psci_use_hvc;
> > 
> > Here's a prime example of where it would just make more sense to
> > populate DT based on what's in the ACPI info.
> > 
> > Have a acpi_parse_fadt() that, if needed, creates a /psci node in the
> > system-wide DT and populates it with the few properties needed.
> > 
> > That way, the rest of the code path in the kernel setup is identical,
> > instead of dealing with separate functions for setup, two exported
> > variables just to communicate the state, and so on. It's just extra
> > complexity for no good reason. The ACPi side code isn't even adding
> > significant complexity compared to this. We'll need to add an
> > of_add_node() property though.
> 
> Yes, this will make the code path in the kernel setup is identical, but
> I think mixture of ACPI and DT (converting ACPI into DT at run-time) is
> not a good solution, and this had been discussed last year:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/211662.html

Agreed. I don't want to get into populating DT structures with ACPI
data. I think doing so ends up increasing the conceptual complexity.

> >> -       np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> >> +       if (acpi_disabled) {
> >> +               np = of_find_matching_node_and_match(NULL,
> >> +                               psci_of_match, &matched_np);
> > 
> > Ideally this code should go away by changing the rest of it, but for
> > future cases: It'd be a lot cleaner to do this as:
> > 
> >         if (!acpi_disabled)
> >                 return psci_0_2_init_acpi();
> > 
> > ... then fall through to the current implementation instead.
> 
> I prefer this one :)

Good! :-)

g.

[PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Grant Likely]

On Thu, 31 Jul 2014 18:23:18 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> On 2014-7-31 12:22, Olof Johansson wrote:
> > Hi,
> 
> Hi Olof,
> 
> > 
> > On Thu, Jul 24, 2014 at 6:00 AM, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> >> There are two flags: PSCI_COMPLIANT and PSCI_USE_HVC. When set,
> >> the former signals to the OS that the hardware is PSCI compliant.
> >> The latter selects the appropriate conduit for PSCI calls by
> >> toggling between Hypervisor Calls (HVC) and Secure Monitor Calls
> >> (SMC).
> >>
> >> FADT table contains such information, parse FADT to get the flags
> >> for PSCI init. Since ACPI 5.1 doesn't support self defined PSCI
> >> function IDs, which means that only PSCI 0.2+ is supported in ACPI.
> >>
> >> At the same time, only ACPI 5.1 or higher verison supports PSCI,
> >> and FADT Major.Minor version was introduced in ACPI 5.1, so we
> >> will check the version and only parse FADT table with version >= 5.1.
> >>
> >> If firmware provides ACPI tables with ACPI version less than 5.1,
> >> OS will be messed up with those information and have no way to
> >> bring up secondery CPUs, so disable ACPI if we get an FADT table
> >> with version less that 5.1.
> >>
> >> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> >> Signed-off-by: Graeme Gregory <graeme.gregory@linaro.org>
> >> ---
> >>  arch/arm64/include/asm/acpi.h |    2 +
> >>  arch/arm64/kernel/acpi.c      |   50 ++++++++++++++++++++++
> >>  arch/arm64/kernel/psci.c      |   95 +++++++++++++++++++++++++++++------------
> >>  arch/arm64/kernel/setup.c     |    2 +
> >>  4 files changed, 121 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> >> index 44b617f..67dac90 100644
> >> --- a/arch/arm64/include/asm/acpi.h
> >> +++ b/arch/arm64/include/asm/acpi.h
> >> @@ -18,6 +18,8 @@ extern int acpi_disabled;
> >>  extern int acpi_noirq;
> >>  extern int acpi_pci_disabled;
> >>  extern int acpi_strict;
> >> +extern int acpi_psci_present;
> >> +extern int acpi_psci_use_hvc;
> >>
> >>  static inline void disable_acpi(void)
> >>  {
> >> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> >> index f5a10b5..374926f 100644
> >> --- a/arch/arm64/kernel/acpi.c
> >> +++ b/arch/arm64/kernel/acpi.c
> >> @@ -11,6 +11,8 @@
> >>   *  published by the Free Software Foundation.
> >>   */
> >>
> >> +#define pr_fmt(fmt) "ACPI: " fmt
> >> +
> >>  #include <linux/init.h>
> >>  #include <linux/acpi.h>
> >>  #include <linux/cpumask.h>
> >> @@ -34,6 +36,12 @@ EXPORT_SYMBOL(acpi_disabled);
> >>  int acpi_pci_disabled;         /* skip ACPI PCI scan and IRQ initialization */
> >>  EXPORT_SYMBOL(acpi_pci_disabled);
> >>
> >> +/* 1 to indicate PSCI is implemented */
> >> +int acpi_psci_present;
> >> +
> >> +/* 1 to indicate HVC must be used instead of SMC as the PSCI conduit */
> >> +int acpi_psci_use_hvc;
> > 
> > Here's a prime example of where it would just make more sense to
> > populate DT based on what's in the ACPI info.
> > 
> > Have a acpi_parse_fadt() that, if needed, creates a /psci node in the
> > system-wide DT and populates it with the few properties needed.
> > 
> > That way, the rest of the code path in the kernel setup is identical,
> > instead of dealing with separate functions for setup, two exported
> > variables just to communicate the state, and so on. It's just extra
> > complexity for no good reason. The ACPi side code isn't even adding
> > significant complexity compared to this. We'll need to add an
> > of_add_node() property though.
> 
> Yes, this will make the code path in the kernel setup is identical, but
> I think mixture of ACPI and DT (converting ACPI into DT at run-time) is
> not a good solution, and this had been discussed last year:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/211662.html

Agreed. I don't want to get into populating DT structures with ACPI
data. I think doing so ends up increasing the conceptual complexity.

> >> -       np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> >> +       if (acpi_disabled) {
> >> +               np = of_find_matching_node_and_match(NULL,
> >> +                               psci_of_match, &matched_np);
> > 
> > Ideally this code should go away by changing the rest of it, but for
> > future cases: It'd be a lot cleaner to do this as:
> > 
> >         if (!acpi_disabled)
> >                 return psci_0_2_init_acpi();
> > 
> > ... then fall through to the current implementation instead.
> 
> I prefer this one :)

Good! :-)

g.

Re: [PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Grant Likely]

On Thu, 24 Jul 2014 21:00:13 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> MADT contains the information for MPIDR which is essential for
> SMP initialization, parse the GIC cpu interface structures to
> get the MPIDR value and map it to cpu_logical_map(), and add
> enabled cpu with valid MPIDR into cpu_possible_map and
> cpu_present_map.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
> +	/* If it is the first CPU, no need to check duplicate MPIDRs */
> +	if (!enabled_cpus)
> +		goto skip_mpidr_check;
> +
> +	/*
> +	 * Duplicate MPIDRs are a recipe for disaster. Scan
> +	 * all initialized entries and check for
> +	 * duplicates. If any is found just ignore the CPU.
> +	 */
> +	for_each_present_cpu(cpu) {
> +		if (cpu_logical_map(cpu) == mpidr) {
> +			pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
> +			       mpidr);
> +			return -EINVAL;
> +		}
> +	}
> +
> +skip_mpidr_check:
> +	enabled_cpus++;

So, this hunk is embarrasing. The goto is completely unnecessary and the
whole for_each_present_cpu() block can be inside an
"if (enabled_cpus) { ... }" block. A goto is just nasty.

That said, is the if even necessary? Will for_each_present_cpu() iterate
over anything if it is processing the first cpu? (I don't actually know
the answer here, I did a quick look but not enough to get an
authoritative answer).

g.

Re: [PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Grant Likely]

On Thu, 24 Jul 2014 21:00:13 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> MADT contains the information for MPIDR which is essential for
> SMP initialization, parse the GIC cpu interface structures to
> get the MPIDR value and map it to cpu_logical_map(), and add
> enabled cpu with valid MPIDR into cpu_possible_map and
> cpu_present_map.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
> +	/* If it is the first CPU, no need to check duplicate MPIDRs */
> +	if (!enabled_cpus)
> +		goto skip_mpidr_check;
> +
> +	/*
> +	 * Duplicate MPIDRs are a recipe for disaster. Scan
> +	 * all initialized entries and check for
> +	 * duplicates. If any is found just ignore the CPU.
> +	 */
> +	for_each_present_cpu(cpu) {
> +		if (cpu_logical_map(cpu) == mpidr) {
> +			pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
> +			       mpidr);
> +			return -EINVAL;
> +		}
> +	}
> +
> +skip_mpidr_check:
> +	enabled_cpus++;

So, this hunk is embarrasing. The goto is completely unnecessary and the
whole for_each_present_cpu() block can be inside an
"if (enabled_cpus) { ... }" block. A goto is just nasty.

That said, is the if even necessary? Will for_each_present_cpu() iterate
over anything if it is processing the first cpu? (I don't actually know
the answer here, I did a quick look but not enough to get an
authoritative answer).

g.

[PATCH 07/19] ARM64 / ACPI: Parse MADT to map logical cpu to MPIDR and get cpu_possible/present_map

[Grant Likely]

On Thu, 24 Jul 2014 21:00:13 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> MADT contains the information for MPIDR which is essential for
> SMP initialization, parse the GIC cpu interface structures to
> get the MPIDR value and map it to cpu_logical_map(), and add
> enabled cpu with valid MPIDR into cpu_possible_map and
> cpu_present_map.
> 
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
> Signed-off-by: Tomasz Nowicki <tomasz.nowicki@linaro.org>
> ---
> +	/* If it is the first CPU, no need to check duplicate MPIDRs */
> +	if (!enabled_cpus)
> +		goto skip_mpidr_check;
> +
> +	/*
> +	 * Duplicate MPIDRs are a recipe for disaster. Scan
> +	 * all initialized entries and check for
> +	 * duplicates. If any is found just ignore the CPU.
> +	 */
> +	for_each_present_cpu(cpu) {
> +		if (cpu_logical_map(cpu) == mpidr) {
> +			pr_err("Firmware bug, duplicate CPU MPIDR: 0x%llx in MADT\n",
> +			       mpidr);
> +			return -EINVAL;
> +		}
> +	}
> +
> +skip_mpidr_check:
> +	enabled_cpus++;

So, this hunk is embarrasing. The goto is completely unnecessary and the
whole for_each_present_cpu() block can be inside an
"if (enabled_cpus) { ... }" block. A goto is just nasty.

That said, is the if even necessary? Will for_each_present_cpu() iterate
over anything if it is processing the first cpu? (I don't actually know
the answer here, I did a quick look but not enough to get an
authoritative answer).

g.

Re: [PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Catalin Marinas]

On Wed, Aug 20, 2014 at 04:00:28PM +0100, Grant Likely wrote:
> On Thu, 24 Jul 2014 21:00:12 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > @@ -345,13 +378,19 @@ int __init psci_init(void)
> >  	const struct of_device_id *matched_np;
> >  	psci_initcall_t init_fn;
> >  
> > -	np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> > +	if (acpi_disabled) {
> > +		np = of_find_matching_node_and_match(NULL,
> > +				psci_of_match, &matched_np);
> >  
> > -	if (!np)
> > -		return -ENODEV;
> > +		if (!np)
> > +			return -ENODEV;
> > +
> > +		init_fn = (psci_initcall_t)matched_np->data;
> > +
> > +		return init_fn(np);
> > +	}
> >  
> > -	init_fn = (psci_initcall_t)matched_np->data;
> > -	return init_fn(np);
> > +	return psci_0_2_init_acpi();
> >  }
> 
> So, while the functionality is sound, this is kind of a stinky diff. The
> ACPI path should not push the OF code into a sub branch. Make it look
> like this instead (with the advantage that the diff will be simpler):
> 
> +	if (IS_ENABLED(CONFIG_ACPI) && !acpi_disabled)
> +		return psci_0_2_init_acpi();

Minor point: we should define acpi_disabled to 1 when !CONFIG_ACPI and
avoid additional IS_ENABLED(CONFIG_ACPI) checks (unless already don this
way).

-- 
Catalin

Re: [PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Catalin Marinas]

On Wed, Aug 20, 2014 at 04:00:28PM +0100, Grant Likely wrote:
> On Thu, 24 Jul 2014 21:00:12 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > @@ -345,13 +378,19 @@ int __init psci_init(void)
> >  	const struct of_device_id *matched_np;
> >  	psci_initcall_t init_fn;
> >  
> > -	np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> > +	if (acpi_disabled) {
> > +		np = of_find_matching_node_and_match(NULL,
> > +				psci_of_match, &matched_np);
> >  
> > -	if (!np)
> > -		return -ENODEV;
> > +		if (!np)
> > +			return -ENODEV;
> > +
> > +		init_fn = (psci_initcall_t)matched_np->data;
> > +
> > +		return init_fn(np);
> > +	}
> >  
> > -	init_fn = (psci_initcall_t)matched_np->data;
> > -	return init_fn(np);
> > +	return psci_0_2_init_acpi();
> >  }
> 
> So, while the functionality is sound, this is kind of a stinky diff. The
> ACPI path should not push the OF code into a sub branch. Make it look
> like this instead (with the advantage that the diff will be simpler):
> 
> +	if (IS_ENABLED(CONFIG_ACPI) && !acpi_disabled)
> +		return psci_0_2_init_acpi();

Minor point: we should define acpi_disabled to 1 when !CONFIG_ACPI and
avoid additional IS_ENABLED(CONFIG_ACPI) checks (unless already don this
way).

-- 
Catalin

[PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[Catalin Marinas]

On Wed, Aug 20, 2014 at 04:00:28PM +0100, Grant Likely wrote:
> On Thu, 24 Jul 2014 21:00:12 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > @@ -345,13 +378,19 @@ int __init psci_init(void)
> >  	const struct of_device_id *matched_np;
> >  	psci_initcall_t init_fn;
> >  
> > -	np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> > +	if (acpi_disabled) {
> > +		np = of_find_matching_node_and_match(NULL,
> > +				psci_of_match, &matched_np);
> >  
> > -	if (!np)
> > -		return -ENODEV;
> > +		if (!np)
> > +			return -ENODEV;
> > +
> > +		init_fn = (psci_initcall_t)matched_np->data;
> > +
> > +		return init_fn(np);
> > +	}
> >  
> > -	init_fn = (psci_initcall_t)matched_np->data;
> > -	return init_fn(np);
> > +	return psci_0_2_init_acpi();
> >  }
> 
> So, while the functionality is sound, this is kind of a stinky diff. The
> ACPI path should not push the OF code into a sub branch. Make it look
> like this instead (with the advantage that the diff will be simpler):
> 
> +	if (IS_ENABLED(CONFIG_ACPI) && !acpi_disabled)
> +		return psci_0_2_init_acpi();

Minor point: we should define acpi_disabled to 1 when !CONFIG_ACPI and
avoid additional IS_ENABLED(CONFIG_ACPI) checks (unless already don this
way).

-- 
Catalin

Re: [PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[graeme.gregory]

On Wed, Aug 20, 2014 at 04:29:44PM +0100, Catalin Marinas wrote:
> On Wed, Aug 20, 2014 at 04:00:28PM +0100, Grant Likely wrote:
> > On Thu, 24 Jul 2014 21:00:12 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > @@ -345,13 +378,19 @@ int __init psci_init(void)
> > >  	const struct of_device_id *matched_np;
> > >  	psci_initcall_t init_fn;
> > >  
> > > -	np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> > > +	if (acpi_disabled) {
> > > +		np = of_find_matching_node_and_match(NULL,
> > > +				psci_of_match, &matched_np);
> > >  
> > > -	if (!np)
> > > -		return -ENODEV;
> > > +		if (!np)
> > > +			return -ENODEV;
> > > +
> > > +		init_fn = (psci_initcall_t)matched_np->data;
> > > +
> > > +		return init_fn(np);
> > > +	}
> > >  
> > > -	init_fn = (psci_initcall_t)matched_np->data;
> > > -	return init_fn(np);
> > > +	return psci_0_2_init_acpi();
> > >  }
> > 
> > So, while the functionality is sound, this is kind of a stinky diff. The
> > ACPI path should not push the OF code into a sub branch. Make it look
> > like this instead (with the advantage that the diff will be simpler):
> > 
> > +	if (IS_ENABLED(CONFIG_ACPI) && !acpi_disabled)
> > +		return psci_0_2_init_acpi();
> 
> Minor point: we should define acpi_disabled to 1 when !CONFIG_ACPI and
> avoid additional IS_ENABLED(CONFIG_ACPI) checks (unless already don this
> way).
> 
This is the default behaviour already.

Graeme

Re: [PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[graeme.gregory]

On Wed, Aug 20, 2014 at 04:29:44PM +0100, Catalin Marinas wrote:
> On Wed, Aug 20, 2014 at 04:00:28PM +0100, Grant Likely wrote:
> > On Thu, 24 Jul 2014 21:00:12 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > @@ -345,13 +378,19 @@ int __init psci_init(void)
> > >  	const struct of_device_id *matched_np;
> > >  	psci_initcall_t init_fn;
> > >  
> > > -	np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> > > +	if (acpi_disabled) {
> > > +		np = of_find_matching_node_and_match(NULL,
> > > +				psci_of_match, &matched_np);
> > >  
> > > -	if (!np)
> > > -		return -ENODEV;
> > > +		if (!np)
> > > +			return -ENODEV;
> > > +
> > > +		init_fn = (psci_initcall_t)matched_np->data;
> > > +
> > > +		return init_fn(np);
> > > +	}
> > >  
> > > -	init_fn = (psci_initcall_t)matched_np->data;
> > > -	return init_fn(np);
> > > +	return psci_0_2_init_acpi();
> > >  }
> > 
> > So, while the functionality is sound, this is kind of a stinky diff. The
> > ACPI path should not push the OF code into a sub branch. Make it look
> > like this instead (with the advantage that the diff will be simpler):
> > 
> > +	if (IS_ENABLED(CONFIG_ACPI) && !acpi_disabled)
> > +		return psci_0_2_init_acpi();
> 
> Minor point: we should define acpi_disabled to 1 when !CONFIG_ACPI and
> avoid additional IS_ENABLED(CONFIG_ACPI) checks (unless already don this
> way).
> 
This is the default behaviour already.

Graeme

[PATCH 06/19] ARM64 / ACPI: Parse FADT table to get PSCI flags for PSCI init

[graeme.gregory at linaro.org]

On Wed, Aug 20, 2014 at 04:29:44PM +0100, Catalin Marinas wrote:
> On Wed, Aug 20, 2014 at 04:00:28PM +0100, Grant Likely wrote:
> > On Thu, 24 Jul 2014 21:00:12 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> > > @@ -345,13 +378,19 @@ int __init psci_init(void)
> > >  	const struct of_device_id *matched_np;
> > >  	psci_initcall_t init_fn;
> > >  
> > > -	np = of_find_matching_node_and_match(NULL, psci_of_match, &matched_np);
> > > +	if (acpi_disabled) {
> > > +		np = of_find_matching_node_and_match(NULL,
> > > +				psci_of_match, &matched_np);
> > >  
> > > -	if (!np)
> > > -		return -ENODEV;
> > > +		if (!np)
> > > +			return -ENODEV;
> > > +
> > > +		init_fn = (psci_initcall_t)matched_np->data;
> > > +
> > > +		return init_fn(np);
> > > +	}
> > >  
> > > -	init_fn = (psci_initcall_t)matched_np->data;
> > > -	return init_fn(np);
> > > +	return psci_0_2_init_acpi();
> > >  }
> > 
> > So, while the functionality is sound, this is kind of a stinky diff. The
> > ACPI path should not push the OF code into a sub branch. Make it look
> > like this instead (with the advantage that the diff will be simpler):
> > 
> > +	if (IS_ENABLED(CONFIG_ACPI) && !acpi_disabled)
> > +		return psci_0_2_init_acpi();
> 
> Minor point: we should define acpi_disabled to 1 when !CONFIG_ACPI and
> avoid additional IS_ENABLED(CONFIG_ACPI) checks (unless already don this
> way).
> 
This is the default behaviour already.

Graeme

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Grant Likely]

On Thu, 24 Jul 2014 21:00:25 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> +Clocks
> +------
> +
> +Like clocks that are part of the power resources there is no standard way
> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
> +described in DT.
> +
> +Devices affected by this include things like UARTs, SoC driven LCD displays,
> +etc.
> +
> +The firmware for example UEFI should initialise these clocks to fixed working
> +values before the kernel is executed. If a driver requires to know rates of
> +clocks set by firmware then they can be passed to kernel using _DSD.
> +
> +example :-
> +
> +Device (CLK0) {
> +	...
> +
> +	Name (_DSD, Package() {
> +		ToUUID("XXXXX"),
> +		Package() {
> +			Package(2) {"#clock-cells", 0},
> +			Package(2) {"clock-frequency", "10000"}
> +		}
> +	})
> +
> +	...
> +}
> +
> +Device (USR1) {
> +	...
> +
> +	Name (_DSD, Package() {
> +		ToUUID("XXXXX"),
> +		Package() {
> +			Package(2) {"clocks", Package() {1, ^CLK0}}},
> +		}
> +	})
> +
> +	...
> +}

Really? This looks wrong. The above example goes right back to
conceptually putting the clock tree into ACPI. I would expect the ACPI
way to expose current clock rate to an individual device driver is to
expose a clock rate method that internally knows how to return the
currently set rate.

g.

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Grant Likely]

On Thu, 24 Jul 2014 21:00:25 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> +Clocks
> +------
> +
> +Like clocks that are part of the power resources there is no standard way
> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
> +described in DT.
> +
> +Devices affected by this include things like UARTs, SoC driven LCD displays,
> +etc.
> +
> +The firmware for example UEFI should initialise these clocks to fixed working
> +values before the kernel is executed. If a driver requires to know rates of
> +clocks set by firmware then they can be passed to kernel using _DSD.
> +
> +example :-
> +
> +Device (CLK0) {
> +	...
> +
> +	Name (_DSD, Package() {
> +		ToUUID("XXXXX"),
> +		Package() {
> +			Package(2) {"#clock-cells", 0},
> +			Package(2) {"clock-frequency", "10000"}
> +		}
> +	})
> +
> +	...
> +}
> +
> +Device (USR1) {
> +	...
> +
> +	Name (_DSD, Package() {
> +		ToUUID("XXXXX"),
> +		Package() {
> +			Package(2) {"clocks", Package() {1, ^CLK0}}},
> +		}
> +	})
> +
> +	...
> +}

Really? This looks wrong. The above example goes right back to
conceptually putting the clock tree into ACPI. I would expect the ACPI
way to expose current clock rate to an individual device driver is to
expose a clock rate method that internally knows how to return the
currently set rate.

g.

[PATCH 19/19] Documentation: ACPI for ARM64

[Grant Likely]

On Thu, 24 Jul 2014 21:00:25 +0800, Hanjun Guo <hanjun.guo@linaro.org> wrote:
> +Clocks
> +------
> +
> +Like clocks that are part of the power resources there is no standard way
> +to represent a clock tree in ACPI 5.1 in a similar manner to how it is
> +described in DT.
> +
> +Devices affected by this include things like UARTs, SoC driven LCD displays,
> +etc.
> +
> +The firmware for example UEFI should initialise these clocks to fixed working
> +values before the kernel is executed. If a driver requires to know rates of
> +clocks set by firmware then they can be passed to kernel using _DSD.
> +
> +example :-
> +
> +Device (CLK0) {
> +	...
> +
> +	Name (_DSD, Package() {
> +		ToUUID("XXXXX"),
> +		Package() {
> +			Package(2) {"#clock-cells", 0},
> +			Package(2) {"clock-frequency", "10000"}
> +		}
> +	})
> +
> +	...
> +}
> +
> +Device (USR1) {
> +	...
> +
> +	Name (_DSD, Package() {
> +		ToUUID("XXXXX"),
> +		Package() {
> +			Package(2) {"clocks", Package() {1, ^CLK0}}},
> +		}
> +	})
> +
> +	...
> +}

Really? This looks wrong. The above example goes right back to
conceptually putting the clock tree into ACPI. I would expect the ACPI
way to expose current clock rate to an individual device driver is to
expose a clock rate method that internally knows how to return the
currently set rate.

g.

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Aug 18, 2014 at 05:29:26PM +0800, Hanjun Guo wrote:
> On 2014-8-15 18:01, Catalin Marinas wrote:
> > Hanjun,
> 
> Hi Catalin,
> 
> > 
> > On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
> >> On 2014-8-14 18:27, Catalin Marinas wrote:
> >>> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> >>>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> >>>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> >>>>>> If we consider ACPI unusable on ARM but we still want to start merging
> >>>>>> patches, we should rather make the config option depend on BROKEN
> >>>>>> (though if it is that unusable that no real platform can use it, I would
> >>>>>> rather not merge it at all at this stage).
> >>>>>
> >>>>> I agree here.
> >>>>>
> >>>>> I would recommend creating a separate branch for that living outside of the
> >>>>> mainline kernel and merging it when there are real users.
> >>>>
> >>>> Real users will coming soon, we already tested this patch set on real hardware
> >>>> (ARM64 Juno platform),
> >>>
> >>> I don't consider Juno a server platform ;) (but it's good enough for
> >>> development).
> >>>
> >>>> and I think ARM64 server chips and platforms will show up before 3.18
> >>>> is released.
> >>>
> >>> That's what I've heard/seen. The questions I have are (a) whether
> >>> current ACPI patchset is enough to successfully run Linux on such
> >>> _hardware_ platform (maybe not fully optimised, for example just WFI
> >>> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> >>> such platforms.
> >>
> >> For (a), this patch set is only for ARM64 core, not including platform
> >> specific device drivers, it will be covered by the binding of _DSD or
> >> explicit definition of PNP ID/ACPI ID(s).
> > 
> > So we go back to the discussions we had few months ago in Macau. I'm not
> > concerned about the core ARM and architected peripherals covered by ACPI
> > 5.1 (as long as the current patches get positive technical review). But
> > I'm concerned about the additional bits needed for a real SoC like _DSD
> > definitions, how they get reviewed/accepted (or is it just the vendor's
> > problem?).
> 
> As the _DSD patch set sent out by Intel folks, _DSD definitions are just
> DT definitions. To use _DSD or not, I think it depends on OEM use cases,
> we can bring up Juno without _DSD (Graeme is working on that, still need
> some time to clean up the code).
> 
> > 
> > I think SBSA is too vague to guarantee a kernel image running on a
> > compliant platform without additional (vendor-specific) tweaks. So what
> > I asked for is (1) a document (guide) to define the strict set of ACPI
> > features and bindings needed for a real SoC and (2) proof that the
> > guidelines are enough for real hardware. I think we have (1) under
> > review with some good feedback so far. As for (2), we can probably only
> > discuss Juno openly. I think you could share the additional Juno patches
> > on this list so that reviewers can assess the suitability. If we deem
> > ACPI not (yet) suitable for Juno, is there other platform we could see
> > patches for?
> 
> Ok, we will send out all the patches for Juno in next version for review,
> as mentioned above, we still need more time to clean up the code.
> 
> > 
> >>> Given the answer to (a) and what other features are needed, we may or
> >>> may not mandate (b). We were pretty clear few months ago that (b) is
> >>> still required but at the time we were only openly talking about ACPI
> >>> 5.0 which was lacking many features. I think we need to revisit that
> >>> position based on how usable ACPI 5.1 for ARM (and current kernel
> >>> implementation) is. Would you mind elaborating what an ACPI-only
> >>> platform miss?
> >>
> >> Do you mean something still missing? We still miss some features for
> >> ARM in ACPI, but I think they are not critical, here is the list I can
> >> remember:
> >> - ITS for GICv3/4;
> >> - SMMU support;
> >> - CPU idle control.
> > 
> > I agree, these are not critical at this stage. But they only refer to
> > architected peripherals. Is there anything else missing for an SoC? Do
> > we need to define clocks?
> 
> No, I prefer not. As we discussed in this thread before, we don't need
> clock definition if we use SBSA compatible UART on Juno.
> 
> > 
> >> For ACPI 5.1, it fixes many problems for ARM:
> >> - weak definition for GIC, so we introduce visualization, v2m and
> >>   part of GICv3/4 (redistributors) support.
> >> - No support for PSCI. Fix it to support PSCI 0.2+;
> >> - Not support for Always-on timer and SBSA-L1 watchdog.
> > 
> > These are all good, that's why we shouldn't even talk about ACPI 5.0 in
> > the ARM context.
> > 
> >> - How to describe device properties, so _DSD is introduced for
> >>   device probe.
> > 
> > For the last bullet, is there any review process (at least like what we
> > have for DT bindings)? On top of such process, do we have guidelines and
> > example code on how the Linux support should be implemented. As Olof
> > mentioned, should we see how the DT and ACPI probing paths work
> > together? I really think we should be very clear here and not let
> > vendors invent their own independent methods.
> 
> As said above, Intel folks provided some good examples for that, and
> clarified a lot of things:
> 
> https://lkml.org/lkml/2014/8/17/10
> 
> > 
> >>> I would expect a new server platform designed with ACPI in mind to
> >>> require minimal SoC specific code, so we may only see a few patches
> >>> under drivers/ for such platforms adding ACPI-specific probing (possibly
> >>> new drivers as well if it's a new component).
> >>>
> >>>> For this patch set, DT is the first class citizen at now:
> >>>>
> >>>> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
> >>>
> >>> Not just off but, based on maturity, depend on EXPERT.
> >>
> >> Ok. And don't set ACPI default off (pass acpi=on to enable it)?
> > 
> > That's my view, just make it clear ACPI is experimental at the Kconfig
> > level because longer term we won't mandate SoCs to provide both DT and
> > ACPI tables.
> 
> I agree with you that if we set ACPI default off, firmware will always
> pass acpi=on if they want to use ACPI, so I think it would be better
> to depend on EXPERT instead.
> 
> Olof, is it ok to you too?

Given that we're going through all these complex schemes to merge code
that isn't ready and keeping it off by default, the answer is really
to continue holding off merging it.

We already had agreement from earlier this year that we needed to see
several systems in the _market_ that uses ACPI before we have an idea of
how messy they will be in reality. Not eval boards, development systems
or reference designs. None of the current discussion has changed that.

There's also the concern that there are still significant portions missing
from 5.1 that won't be there until 5.2 or later. Having experimental
5.1 support for a few systems (out of tree) is likely going to result in
finding out things that don't work well and should be revised -- if we
don't merge this now then we can avoid having to keep the 5.1 backwards
compatibility forever. Compare this to how we've been regretting some
of the early-defined bindings on DT and wish we didn't have to keep
them around. Please learn from our mistakes. :-)

On the patches themselves:

It's great to see the patch sets posted, and they're looking pretty good
-- things are very much heading in the right direction. My main remaining
objection is around how it is integrated with the arch code. I don't
like seeing all the dual code paths that ACPI introduces. It's obvious
that two completely different entities have written the ACPI and the DT
portions of the kernel, and we can't really have that situation for a
brand new architecture like this.

So, I'd like to see closer integration between the two before code
goes in. More shared code path and driving the differences through data
(or possibly function pointers in places, etc), and fewer completely
separate implementations.

Until then, please keep posting patches for review -- it's useful
to see where it's going. I think it's also useful to get the generic
ACPI integration merged as it has been already (with pieces going in
over time).

If someone already needs to climb the hurdle of turning on an EXPORT
config option, then it's really not a significant additional hurdle to
merge in an external branch that includes the ACPI support (and that
branch can enable it by default!). So, I think that's the solution that
makes sense for the time being.


-Olof

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Aug 18, 2014 at 05:29:26PM +0800, Hanjun Guo wrote:
> On 2014-8-15 18:01, Catalin Marinas wrote:
> > Hanjun,
> 
> Hi Catalin,
> 
> > 
> > On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
> >> On 2014-8-14 18:27, Catalin Marinas wrote:
> >>> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> >>>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> >>>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> >>>>>> If we consider ACPI unusable on ARM but we still want to start merging
> >>>>>> patches, we should rather make the config option depend on BROKEN
> >>>>>> (though if it is that unusable that no real platform can use it, I would
> >>>>>> rather not merge it at all at this stage).
> >>>>>
> >>>>> I agree here.
> >>>>>
> >>>>> I would recommend creating a separate branch for that living outside of the
> >>>>> mainline kernel and merging it when there are real users.
> >>>>
> >>>> Real users will coming soon, we already tested this patch set on real hardware
> >>>> (ARM64 Juno platform),
> >>>
> >>> I don't consider Juno a server platform ;) (but it's good enough for
> >>> development).
> >>>
> >>>> and I think ARM64 server chips and platforms will show up before 3.18
> >>>> is released.
> >>>
> >>> That's what I've heard/seen. The questions I have are (a) whether
> >>> current ACPI patchset is enough to successfully run Linux on such
> >>> _hardware_ platform (maybe not fully optimised, for example just WFI
> >>> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> >>> such platforms.
> >>
> >> For (a), this patch set is only for ARM64 core, not including platform
> >> specific device drivers, it will be covered by the binding of _DSD or
> >> explicit definition of PNP ID/ACPI ID(s).
> > 
> > So we go back to the discussions we had few months ago in Macau. I'm not
> > concerned about the core ARM and architected peripherals covered by ACPI
> > 5.1 (as long as the current patches get positive technical review). But
> > I'm concerned about the additional bits needed for a real SoC like _DSD
> > definitions, how they get reviewed/accepted (or is it just the vendor's
> > problem?).
> 
> As the _DSD patch set sent out by Intel folks, _DSD definitions are just
> DT definitions. To use _DSD or not, I think it depends on OEM use cases,
> we can bring up Juno without _DSD (Graeme is working on that, still need
> some time to clean up the code).
> 
> > 
> > I think SBSA is too vague to guarantee a kernel image running on a
> > compliant platform without additional (vendor-specific) tweaks. So what
> > I asked for is (1) a document (guide) to define the strict set of ACPI
> > features and bindings needed for a real SoC and (2) proof that the
> > guidelines are enough for real hardware. I think we have (1) under
> > review with some good feedback so far. As for (2), we can probably only
> > discuss Juno openly. I think you could share the additional Juno patches
> > on this list so that reviewers can assess the suitability. If we deem
> > ACPI not (yet) suitable for Juno, is there other platform we could see
> > patches for?
> 
> Ok, we will send out all the patches for Juno in next version for review,
> as mentioned above, we still need more time to clean up the code.
> 
> > 
> >>> Given the answer to (a) and what other features are needed, we may or
> >>> may not mandate (b). We were pretty clear few months ago that (b) is
> >>> still required but at the time we were only openly talking about ACPI
> >>> 5.0 which was lacking many features. I think we need to revisit that
> >>> position based on how usable ACPI 5.1 for ARM (and current kernel
> >>> implementation) is. Would you mind elaborating what an ACPI-only
> >>> platform miss?
> >>
> >> Do you mean something still missing? We still miss some features for
> >> ARM in ACPI, but I think they are not critical, here is the list I can
> >> remember:
> >> - ITS for GICv3/4;
> >> - SMMU support;
> >> - CPU idle control.
> > 
> > I agree, these are not critical at this stage. But they only refer to
> > architected peripherals. Is there anything else missing for an SoC? Do
> > we need to define clocks?
> 
> No, I prefer not. As we discussed in this thread before, we don't need
> clock definition if we use SBSA compatible UART on Juno.
> 
> > 
> >> For ACPI 5.1, it fixes many problems for ARM:
> >> - weak definition for GIC, so we introduce visualization, v2m and
> >>   part of GICv3/4 (redistributors) support.
> >> - No support for PSCI. Fix it to support PSCI 0.2+;
> >> - Not support for Always-on timer and SBSA-L1 watchdog.
> > 
> > These are all good, that's why we shouldn't even talk about ACPI 5.0 in
> > the ARM context.
> > 
> >> - How to describe device properties, so _DSD is introduced for
> >>   device probe.
> > 
> > For the last bullet, is there any review process (at least like what we
> > have for DT bindings)? On top of such process, do we have guidelines and
> > example code on how the Linux support should be implemented. As Olof
> > mentioned, should we see how the DT and ACPI probing paths work
> > together? I really think we should be very clear here and not let
> > vendors invent their own independent methods.
> 
> As said above, Intel folks provided some good examples for that, and
> clarified a lot of things:
> 
> https://lkml.org/lkml/2014/8/17/10
> 
> > 
> >>> I would expect a new server platform designed with ACPI in mind to
> >>> require minimal SoC specific code, so we may only see a few patches
> >>> under drivers/ for such platforms adding ACPI-specific probing (possibly
> >>> new drivers as well if it's a new component).
> >>>
> >>>> For this patch set, DT is the first class citizen at now:
> >>>>
> >>>> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
> >>>
> >>> Not just off but, based on maturity, depend on EXPERT.
> >>
> >> Ok. And don't set ACPI default off (pass acpi=on to enable it)?
> > 
> > That's my view, just make it clear ACPI is experimental at the Kconfig
> > level because longer term we won't mandate SoCs to provide both DT and
> > ACPI tables.
> 
> I agree with you that if we set ACPI default off, firmware will always
> pass acpi=on if they want to use ACPI, so I think it would be better
> to depend on EXPERT instead.
> 
> Olof, is it ok to you too?

Given that we're going through all these complex schemes to merge code
that isn't ready and keeping it off by default, the answer is really
to continue holding off merging it.

We already had agreement from earlier this year that we needed to see
several systems in the _market_ that uses ACPI before we have an idea of
how messy they will be in reality. Not eval boards, development systems
or reference designs. None of the current discussion has changed that.

There's also the concern that there are still significant portions missing
from 5.1 that won't be there until 5.2 or later. Having experimental
5.1 support for a few systems (out of tree) is likely going to result in
finding out things that don't work well and should be revised -- if we
don't merge this now then we can avoid having to keep the 5.1 backwards
compatibility forever. Compare this to how we've been regretting some
of the early-defined bindings on DT and wish we didn't have to keep
them around. Please learn from our mistakes. :-)

On the patches themselves:

It's great to see the patch sets posted, and they're looking pretty good
-- things are very much heading in the right direction. My main remaining
objection is around how it is integrated with the arch code. I don't
like seeing all the dual code paths that ACPI introduces. It's obvious
that two completely different entities have written the ACPI and the DT
portions of the kernel, and we can't really have that situation for a
brand new architecture like this.

So, I'd like to see closer integration between the two before code
goes in. More shared code path and driving the differences through data
(or possibly function pointers in places, etc), and fewer completely
separate implementations.

Until then, please keep posting patches for review -- it's useful
to see where it's going. I think it's also useful to get the generic
ACPI integration merged as it has been already (with pieces going in
over time).

If someone already needs to climb the hurdle of turning on an EXPORT
config option, then it's really not a significant additional hurdle to
merge in an external branch that includes the ACPI support (and that
branch can enable it by default!). So, I think that's the solution that
makes sense for the time being.


-Olof

[PATCH 19/19] Documentation: ACPI for ARM64

[Olof Johansson]

On Mon, Aug 18, 2014 at 05:29:26PM +0800, Hanjun Guo wrote:
> On 2014-8-15 18:01, Catalin Marinas wrote:
> > Hanjun,
> 
> Hi Catalin,
> 
> > 
> > On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
> >> On 2014-8-14 18:27, Catalin Marinas wrote:
> >>> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
> >>>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
> >>>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
> >>>>>> If we consider ACPI unusable on ARM but we still want to start merging
> >>>>>> patches, we should rather make the config option depend on BROKEN
> >>>>>> (though if it is that unusable that no real platform can use it, I would
> >>>>>> rather not merge it at all at this stage).
> >>>>>
> >>>>> I agree here.
> >>>>>
> >>>>> I would recommend creating a separate branch for that living outside of the
> >>>>> mainline kernel and merging it when there are real users.
> >>>>
> >>>> Real users will coming soon, we already tested this patch set on real hardware
> >>>> (ARM64 Juno platform),
> >>>
> >>> I don't consider Juno a server platform ;) (but it's good enough for
> >>> development).
> >>>
> >>>> and I think ARM64 server chips and platforms will show up before 3.18
> >>>> is released.
> >>>
> >>> That's what I've heard/seen. The questions I have are (a) whether
> >>> current ACPI patchset is enough to successfully run Linux on such
> >>> _hardware_ platform (maybe not fully optimised, for example just WFI
> >>> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
> >>> such platforms.
> >>
> >> For (a), this patch set is only for ARM64 core, not including platform
> >> specific device drivers, it will be covered by the binding of _DSD or
> >> explicit definition of PNP ID/ACPI ID(s).
> > 
> > So we go back to the discussions we had few months ago in Macau. I'm not
> > concerned about the core ARM and architected peripherals covered by ACPI
> > 5.1 (as long as the current patches get positive technical review). But
> > I'm concerned about the additional bits needed for a real SoC like _DSD
> > definitions, how they get reviewed/accepted (or is it just the vendor's
> > problem?).
> 
> As the _DSD patch set sent out by Intel folks, _DSD definitions are just
> DT definitions. To use _DSD or not, I think it depends on OEM use cases,
> we can bring up Juno without _DSD (Graeme is working on that, still need
> some time to clean up the code).
> 
> > 
> > I think SBSA is too vague to guarantee a kernel image running on a
> > compliant platform without additional (vendor-specific) tweaks. So what
> > I asked for is (1) a document (guide) to define the strict set of ACPI
> > features and bindings needed for a real SoC and (2) proof that the
> > guidelines are enough for real hardware. I think we have (1) under
> > review with some good feedback so far. As for (2), we can probably only
> > discuss Juno openly. I think you could share the additional Juno patches
> > on this list so that reviewers can assess the suitability. If we deem
> > ACPI not (yet) suitable for Juno, is there other platform we could see
> > patches for?
> 
> Ok, we will send out all the patches for Juno in next version for review,
> as mentioned above, we still need more time to clean up the code.
> 
> > 
> >>> Given the answer to (a) and what other features are needed, we may or
> >>> may not mandate (b). We were pretty clear few months ago that (b) is
> >>> still required but at the time we were only openly talking about ACPI
> >>> 5.0 which was lacking many features. I think we need to revisit that
> >>> position based on how usable ACPI 5.1 for ARM (and current kernel
> >>> implementation) is. Would you mind elaborating what an ACPI-only
> >>> platform miss?
> >>
> >> Do you mean something still missing? We still miss some features for
> >> ARM in ACPI, but I think they are not critical, here is the list I can
> >> remember:
> >> - ITS for GICv3/4;
> >> - SMMU support;
> >> - CPU idle control.
> > 
> > I agree, these are not critical at this stage. But they only refer to
> > architected peripherals. Is there anything else missing for an SoC? Do
> > we need to define clocks?
> 
> No, I prefer not. As we discussed in this thread before, we don't need
> clock definition if we use SBSA compatible UART on Juno.
> 
> > 
> >> For ACPI 5.1, it fixes many problems for ARM:
> >> - weak definition for GIC, so we introduce visualization, v2m and
> >>   part of GICv3/4 (redistributors) support.
> >> - No support for PSCI. Fix it to support PSCI 0.2+;
> >> - Not support for Always-on timer and SBSA-L1 watchdog.
> > 
> > These are all good, that's why we shouldn't even talk about ACPI 5.0 in
> > the ARM context.
> > 
> >> - How to describe device properties, so _DSD is introduced for
> >>   device probe.
> > 
> > For the last bullet, is there any review process (at least like what we
> > have for DT bindings)? On top of such process, do we have guidelines and
> > example code on how the Linux support should be implemented. As Olof
> > mentioned, should we see how the DT and ACPI probing paths work
> > together? I really think we should be very clear here and not let
> > vendors invent their own independent methods.
> 
> As said above, Intel folks provided some good examples for that, and
> clarified a lot of things:
> 
> https://lkml.org/lkml/2014/8/17/10
> 
> > 
> >>> I would expect a new server platform designed with ACPI in mind to
> >>> require minimal SoC specific code, so we may only see a few patches
> >>> under drivers/ for such platforms adding ACPI-specific probing (possibly
> >>> new drivers as well if it's a new component).
> >>>
> >>>> For this patch set, DT is the first class citizen at now:
> >>>>
> >>>> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
> >>>
> >>> Not just off but, based on maturity, depend on EXPERT.
> >>
> >> Ok. And don't set ACPI default off (pass acpi=on to enable it)?
> > 
> > That's my view, just make it clear ACPI is experimental at the Kconfig
> > level because longer term we won't mandate SoCs to provide both DT and
> > ACPI tables.
> 
> I agree with you that if we set ACPI default off, firmware will always
> pass acpi=on if they want to use ACPI, so I think it would be better
> to depend on EXPERT instead.
> 
> Olof, is it ok to you too?

Given that we're going through all these complex schemes to merge code
that isn't ready and keeping it off by default, the answer is really
to continue holding off merging it.

We already had agreement from earlier this year that we needed to see
several systems in the _market_ that uses ACPI before we have an idea of
how messy they will be in reality. Not eval boards, development systems
or reference designs. None of the current discussion has changed that.

There's also the concern that there are still significant portions missing
from 5.1 that won't be there until 5.2 or later. Having experimental
5.1 support for a few systems (out of tree) is likely going to result in
finding out things that don't work well and should be revised -- if we
don't merge this now then we can avoid having to keep the 5.1 backwards
compatibility forever. Compare this to how we've been regretting some
of the early-defined bindings on DT and wish we didn't have to keep
them around. Please learn from our mistakes. :-)

On the patches themselves:

It's great to see the patch sets posted, and they're looking pretty good
-- things are very much heading in the right direction. My main remaining
objection is around how it is integrated with the arch code. I don't
like seeing all the dual code paths that ACPI introduces. It's obvious
that two completely different entities have written the ACPI and the DT
portions of the kernel, and we can't really have that situation for a
brand new architecture like this.

So, I'd like to see closer integration between the two before code
goes in. More shared code path and driving the differences through data
(or possibly function pointers in places, etc), and fewer completely
separate implementations.

Until then, please keep posting patches for review -- it's useful
to see where it's going. I think it's also useful to get the generic
ACPI integration merged as it has been already (with pieces going in
over time).

If someone already needs to climb the hurdle of turning on an EXPORT
config option, then it's really not a significant additional hurdle to
merge in an external branch that includes the ACPI support (and that
branch can enable it by default!). So, I think that's the solution that
makes sense for the time being.


-Olof

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-8-21 6:17, Olof Johansson wrote:
> On Mon, Aug 18, 2014 at 05:29:26PM +0800, Hanjun Guo wrote:
>> On 2014-8-15 18:01, Catalin Marinas wrote:
>>> Hanjun,
>>
>> Hi Catalin,
>>
>>>
>>> On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
>>>> On 2014-8-14 18:27, Catalin Marinas wrote:
>>>>> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
>>>>>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
>>>>>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>>>>>>>> If we consider ACPI unusable on ARM but we still want to start merging
>>>>>>>> patches, we should rather make the config option depend on BROKEN
>>>>>>>> (though if it is that unusable that no real platform can use it, I would
>>>>>>>> rather not merge it at all at this stage).
>>>>>>>
>>>>>>> I agree here.
>>>>>>>
>>>>>>> I would recommend creating a separate branch for that living outside of the
>>>>>>> mainline kernel and merging it when there are real users.
>>>>>>
>>>>>> Real users will coming soon, we already tested this patch set on real hardware
>>>>>> (ARM64 Juno platform),
>>>>>
>>>>> I don't consider Juno a server platform ;) (but it's good enough for
>>>>> development).
>>>>>
>>>>>> and I think ARM64 server chips and platforms will show up before 3.18
>>>>>> is released.
>>>>>
>>>>> That's what I've heard/seen. The questions I have are (a) whether
>>>>> current ACPI patchset is enough to successfully run Linux on such
>>>>> _hardware_ platform (maybe not fully optimised, for example just WFI
>>>>> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
>>>>> such platforms.
>>>>
>>>> For (a), this patch set is only for ARM64 core, not including platform
>>>> specific device drivers, it will be covered by the binding of _DSD or
>>>> explicit definition of PNP ID/ACPI ID(s).
>>>
>>> So we go back to the discussions we had few months ago in Macau. I'm not
>>> concerned about the core ARM and architected peripherals covered by ACPI
>>> 5.1 (as long as the current patches get positive technical review). But
>>> I'm concerned about the additional bits needed for a real SoC like _DSD
>>> definitions, how they get reviewed/accepted (or is it just the vendor's
>>> problem?).
>>
>> As the _DSD patch set sent out by Intel folks, _DSD definitions are just
>> DT definitions. To use _DSD or not, I think it depends on OEM use cases,
>> we can bring up Juno without _DSD (Graeme is working on that, still need
>> some time to clean up the code).
>>
>>>
>>> I think SBSA is too vague to guarantee a kernel image running on a
>>> compliant platform without additional (vendor-specific) tweaks. So what
>>> I asked for is (1) a document (guide) to define the strict set of ACPI
>>> features and bindings needed for a real SoC and (2) proof that the
>>> guidelines are enough for real hardware. I think we have (1) under
>>> review with some good feedback so far. As for (2), we can probably only
>>> discuss Juno openly. I think you could share the additional Juno patches
>>> on this list so that reviewers can assess the suitability. If we deem
>>> ACPI not (yet) suitable for Juno, is there other platform we could see
>>> patches for?
>>
>> Ok, we will send out all the patches for Juno in next version for review,
>> as mentioned above, we still need more time to clean up the code.
>>
>>>
>>>>> Given the answer to (a) and what other features are needed, we may or
>>>>> may not mandate (b). We were pretty clear few months ago that (b) is
>>>>> still required but at the time we were only openly talking about ACPI
>>>>> 5.0 which was lacking many features. I think we need to revisit that
>>>>> position based on how usable ACPI 5.1 for ARM (and current kernel
>>>>> implementation) is. Would you mind elaborating what an ACPI-only
>>>>> platform miss?
>>>>
>>>> Do you mean something still missing? We still miss some features for
>>>> ARM in ACPI, but I think they are not critical, here is the list I can
>>>> remember:
>>>> - ITS for GICv3/4;
>>>> - SMMU support;
>>>> - CPU idle control.
>>>
>>> I agree, these are not critical at this stage. But they only refer to
>>> architected peripherals. Is there anything else missing for an SoC? Do
>>> we need to define clocks?
>>
>> No, I prefer not. As we discussed in this thread before, we don't need
>> clock definition if we use SBSA compatible UART on Juno.
>>
>>>
>>>> For ACPI 5.1, it fixes many problems for ARM:
>>>> - weak definition for GIC, so we introduce visualization, v2m and
>>>>   part of GICv3/4 (redistributors) support.
>>>> - No support for PSCI. Fix it to support PSCI 0.2+;
>>>> - Not support for Always-on timer and SBSA-L1 watchdog.
>>>
>>> These are all good, that's why we shouldn't even talk about ACPI 5.0 in
>>> the ARM context.
>>>
>>>> - How to describe device properties, so _DSD is introduced for
>>>>   device probe.
>>>
>>> For the last bullet, is there any review process (at least like what we
>>> have for DT bindings)? On top of such process, do we have guidelines and
>>> example code on how the Linux support should be implemented. As Olof
>>> mentioned, should we see how the DT and ACPI probing paths work
>>> together? I really think we should be very clear here and not let
>>> vendors invent their own independent methods.
>>
>> As said above, Intel folks provided some good examples for that, and
>> clarified a lot of things:
>>
>> https://lkml.org/lkml/2014/8/17/10
>>
>>>
>>>>> I would expect a new server platform designed with ACPI in mind to
>>>>> require minimal SoC specific code, so we may only see a few patches
>>>>> under drivers/ for such platforms adding ACPI-specific probing (possibly
>>>>> new drivers as well if it's a new component).
>>>>>
>>>>>> For this patch set, DT is the first class citizen at now:
>>>>>>
>>>>>> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
>>>>>
>>>>> Not just off but, based on maturity, depend on EXPERT.
>>>>
>>>> Ok. And don't set ACPI default off (pass acpi=on to enable it)?
>>>
>>> That's my view, just make it clear ACPI is experimental at the Kconfig
>>> level because longer term we won't mandate SoCs to provide both DT and
>>> ACPI tables.
>>
>> I agree with you that if we set ACPI default off, firmware will always
>> pass acpi=on if they want to use ACPI, so I think it would be better
>> to depend on EXPERT instead.
>>
>> Olof, is it ok to you too?
> 
> Given that we're going through all these complex schemes to merge code
> that isn't ready and keeping it off by default, the answer is really
> to continue holding off merging it.
> 
> We already had agreement from earlier this year that we needed to see
> several systems in the _market_ that uses ACPI before we have an idea of
> how messy they will be in reality. Not eval boards, development systems
> or reference designs. None of the current discussion has changed that.

I think some SBSA compatible ARM64 server boards would work, such as Seattle
board, right?

> 
> There's also the concern that there are still significant portions missing
> from 5.1 that won't be there until 5.2 or later. Having experimental
> 5.1 support for a few systems (out of tree) is likely going to result in
> finding out things that don't work well and should be revised -- if we
> don't merge this now then we can avoid having to keep the 5.1 backwards
> compatibility forever. Compare this to how we've been regretting some
> of the early-defined bindings on DT and wish we didn't have to keep
> them around. Please learn from our mistakes. :-)

Yes, there are some features missing in ACPI 5.1, and I list them out
in previous email replying Catalin, as I said, they are not critical
for ARM64 for now.

> 
> On the patches themselves:
> 
> It's great to see the patch sets posted, and they're looking pretty good
> -- things are very much heading in the right direction. My main remaining
> objection is around how it is integrated with the arch code. I don't
> like seeing all the dual code paths that ACPI introduces. It's obvious
> that two completely different entities have written the ACPI and the DT
> portions of the kernel, and we can't really have that situation for a
> brand new architecture like this.
> 
> So, I'd like to see closer integration between the two before code
> goes in. More shared code path and driving the differences through data
> (or possibly function pointers in places, etc), and fewer completely
> separate implementations.

I'm working on it, I hope I can achieve that, you know, it needs
more efforts to do it :)

> 
> Until then, please keep posting patches for review -- it's useful
> to see where it's going. I think it's also useful to get the generic
> ACPI integration merged as it has been already (with pieces going in
> over time).

Sure I will :)

Thanks
Hanjun

Re: [PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-8-21 6:17, Olof Johansson wrote:
> On Mon, Aug 18, 2014 at 05:29:26PM +0800, Hanjun Guo wrote:
>> On 2014-8-15 18:01, Catalin Marinas wrote:
>>> Hanjun,
>>
>> Hi Catalin,
>>
>>>
>>> On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
>>>> On 2014-8-14 18:27, Catalin Marinas wrote:
>>>>> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
>>>>>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
>>>>>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>>>>>>>> If we consider ACPI unusable on ARM but we still want to start merging
>>>>>>>> patches, we should rather make the config option depend on BROKEN
>>>>>>>> (though if it is that unusable that no real platform can use it, I would
>>>>>>>> rather not merge it at all at this stage).
>>>>>>>
>>>>>>> I agree here.
>>>>>>>
>>>>>>> I would recommend creating a separate branch for that living outside of the
>>>>>>> mainline kernel and merging it when there are real users.
>>>>>>
>>>>>> Real users will coming soon, we already tested this patch set on real hardware
>>>>>> (ARM64 Juno platform),
>>>>>
>>>>> I don't consider Juno a server platform ;) (but it's good enough for
>>>>> development).
>>>>>
>>>>>> and I think ARM64 server chips and platforms will show up before 3.18
>>>>>> is released.
>>>>>
>>>>> That's what I've heard/seen. The questions I have are (a) whether
>>>>> current ACPI patchset is enough to successfully run Linux on such
>>>>> _hardware_ platform (maybe not fully optimised, for example just WFI
>>>>> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
>>>>> such platforms.
>>>>
>>>> For (a), this patch set is only for ARM64 core, not including platform
>>>> specific device drivers, it will be covered by the binding of _DSD or
>>>> explicit definition of PNP ID/ACPI ID(s).
>>>
>>> So we go back to the discussions we had few months ago in Macau. I'm not
>>> concerned about the core ARM and architected peripherals covered by ACPI
>>> 5.1 (as long as the current patches get positive technical review). But
>>> I'm concerned about the additional bits needed for a real SoC like _DSD
>>> definitions, how they get reviewed/accepted (or is it just the vendor's
>>> problem?).
>>
>> As the _DSD patch set sent out by Intel folks, _DSD definitions are just
>> DT definitions. To use _DSD or not, I think it depends on OEM use cases,
>> we can bring up Juno without _DSD (Graeme is working on that, still need
>> some time to clean up the code).
>>
>>>
>>> I think SBSA is too vague to guarantee a kernel image running on a
>>> compliant platform without additional (vendor-specific) tweaks. So what
>>> I asked for is (1) a document (guide) to define the strict set of ACPI
>>> features and bindings needed for a real SoC and (2) proof that the
>>> guidelines are enough for real hardware. I think we have (1) under
>>> review with some good feedback so far. As for (2), we can probably only
>>> discuss Juno openly. I think you could share the additional Juno patches
>>> on this list so that reviewers can assess the suitability. If we deem
>>> ACPI not (yet) suitable for Juno, is there other platform we could see
>>> patches for?
>>
>> Ok, we will send out all the patches for Juno in next version for review,
>> as mentioned above, we still need more time to clean up the code.
>>
>>>
>>>>> Given the answer to (a) and what other features are needed, we may or
>>>>> may not mandate (b). We were pretty clear few months ago that (b) is
>>>>> still required but at the time we were only openly talking about ACPI
>>>>> 5.0 which was lacking many features. I think we need to revisit that
>>>>> position based on how usable ACPI 5.1 for ARM (and current kernel
>>>>> implementation) is. Would you mind elaborating what an ACPI-only
>>>>> platform miss?
>>>>
>>>> Do you mean something still missing? We still miss some features for
>>>> ARM in ACPI, but I think they are not critical, here is the list I can
>>>> remember:
>>>> - ITS for GICv3/4;
>>>> - SMMU support;
>>>> - CPU idle control.
>>>
>>> I agree, these are not critical at this stage. But they only refer to
>>> architected peripherals. Is there anything else missing for an SoC? Do
>>> we need to define clocks?
>>
>> No, I prefer not. As we discussed in this thread before, we don't need
>> clock definition if we use SBSA compatible UART on Juno.
>>
>>>
>>>> For ACPI 5.1, it fixes many problems for ARM:
>>>> - weak definition for GIC, so we introduce visualization, v2m and
>>>>   part of GICv3/4 (redistributors) support.
>>>> - No support for PSCI. Fix it to support PSCI 0.2+;
>>>> - Not support for Always-on timer and SBSA-L1 watchdog.
>>>
>>> These are all good, that's why we shouldn't even talk about ACPI 5.0 in
>>> the ARM context.
>>>
>>>> - How to describe device properties, so _DSD is introduced for
>>>>   device probe.
>>>
>>> For the last bullet, is there any review process (at least like what we
>>> have for DT bindings)? On top of such process, do we have guidelines and
>>> example code on how the Linux support should be implemented. As Olof
>>> mentioned, should we see how the DT and ACPI probing paths work
>>> together? I really think we should be very clear here and not let
>>> vendors invent their own independent methods.
>>
>> As said above, Intel folks provided some good examples for that, and
>> clarified a lot of things:
>>
>> https://lkml.org/lkml/2014/8/17/10
>>
>>>
>>>>> I would expect a new server platform designed with ACPI in mind to
>>>>> require minimal SoC specific code, so we may only see a few patches
>>>>> under drivers/ for such platforms adding ACPI-specific probing (possibly
>>>>> new drivers as well if it's a new component).
>>>>>
>>>>>> For this patch set, DT is the first class citizen at now:
>>>>>>
>>>>>> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
>>>>>
>>>>> Not just off but, based on maturity, depend on EXPERT.
>>>>
>>>> Ok. And don't set ACPI default off (pass acpi=on to enable it)?
>>>
>>> That's my view, just make it clear ACPI is experimental at the Kconfig
>>> level because longer term we won't mandate SoCs to provide both DT and
>>> ACPI tables.
>>
>> I agree with you that if we set ACPI default off, firmware will always
>> pass acpi=on if they want to use ACPI, so I think it would be better
>> to depend on EXPERT instead.
>>
>> Olof, is it ok to you too?
> 
> Given that we're going through all these complex schemes to merge code
> that isn't ready and keeping it off by default, the answer is really
> to continue holding off merging it.
> 
> We already had agreement from earlier this year that we needed to see
> several systems in the _market_ that uses ACPI before we have an idea of
> how messy they will be in reality. Not eval boards, development systems
> or reference designs. None of the current discussion has changed that.

I think some SBSA compatible ARM64 server boards would work, such as Seattle
board, right?

> 
> There's also the concern that there are still significant portions missing
> from 5.1 that won't be there until 5.2 or later. Having experimental
> 5.1 support for a few systems (out of tree) is likely going to result in
> finding out things that don't work well and should be revised -- if we
> don't merge this now then we can avoid having to keep the 5.1 backwards
> compatibility forever. Compare this to how we've been regretting some
> of the early-defined bindings on DT and wish we didn't have to keep
> them around. Please learn from our mistakes. :-)

Yes, there are some features missing in ACPI 5.1, and I list them out
in previous email replying Catalin, as I said, they are not critical
for ARM64 for now.

> 
> On the patches themselves:
> 
> It's great to see the patch sets posted, and they're looking pretty good
> -- things are very much heading in the right direction. My main remaining
> objection is around how it is integrated with the arch code. I don't
> like seeing all the dual code paths that ACPI introduces. It's obvious
> that two completely different entities have written the ACPI and the DT
> portions of the kernel, and we can't really have that situation for a
> brand new architecture like this.
> 
> So, I'd like to see closer integration between the two before code
> goes in. More shared code path and driving the differences through data
> (or possibly function pointers in places, etc), and fewer completely
> separate implementations.

I'm working on it, I hope I can achieve that, you know, it needs
more efforts to do it :)

> 
> Until then, please keep posting patches for review -- it's useful
> to see where it's going. I think it's also useful to get the generic
> ACPI integration merged as it has been already (with pieces going in
> over time).

Sure I will :)

Thanks
Hanjun

[PATCH 19/19] Documentation: ACPI for ARM64

[Hanjun Guo]

On 2014-8-21 6:17, Olof Johansson wrote:
> On Mon, Aug 18, 2014 at 05:29:26PM +0800, Hanjun Guo wrote:
>> On 2014-8-15 18:01, Catalin Marinas wrote:
>>> Hanjun,
>>
>> Hi Catalin,
>>
>>>
>>> On Fri, Aug 15, 2014 at 10:09:42AM +0100, Hanjun Guo wrote:
>>>> On 2014-8-14 18:27, Catalin Marinas wrote:
>>>>> On Thu, Aug 14, 2014 at 04:21:25AM +0100, Hanjun Guo wrote:
>>>>>> On 2014-8-14 7:41, Rafael J. Wysocki wrote:
>>>>>>> On Tuesday, August 12, 2014 07:23:47 PM Catalin Marinas wrote:
>>>>>>>> If we consider ACPI unusable on ARM but we still want to start merging
>>>>>>>> patches, we should rather make the config option depend on BROKEN
>>>>>>>> (though if it is that unusable that no real platform can use it, I would
>>>>>>>> rather not merge it at all at this stage).
>>>>>>>
>>>>>>> I agree here.
>>>>>>>
>>>>>>> I would recommend creating a separate branch for that living outside of the
>>>>>>> mainline kernel and merging it when there are real users.
>>>>>>
>>>>>> Real users will coming soon, we already tested this patch set on real hardware
>>>>>> (ARM64 Juno platform),
>>>>>
>>>>> I don't consider Juno a server platform ;) (but it's good enough for
>>>>> development).
>>>>>
>>>>>> and I think ARM64 server chips and platforms will show up before 3.18
>>>>>> is released.
>>>>>
>>>>> That's what I've heard/seen. The questions I have are (a) whether
>>>>> current ACPI patchset is enough to successfully run Linux on such
>>>>> _hardware_ platform (maybe not fully optimised, for example just WFI
>>>>> cpuidle) and (b) whether we still want to mandate a DT in the kernel for
>>>>> such platforms.
>>>>
>>>> For (a), this patch set is only for ARM64 core, not including platform
>>>> specific device drivers, it will be covered by the binding of _DSD or
>>>> explicit definition of PNP ID/ACPI ID(s).
>>>
>>> So we go back to the discussions we had few months ago in Macau. I'm not
>>> concerned about the core ARM and architected peripherals covered by ACPI
>>> 5.1 (as long as the current patches get positive technical review). But
>>> I'm concerned about the additional bits needed for a real SoC like _DSD
>>> definitions, how they get reviewed/accepted (or is it just the vendor's
>>> problem?).
>>
>> As the _DSD patch set sent out by Intel folks, _DSD definitions are just
>> DT definitions. To use _DSD or not, I think it depends on OEM use cases,
>> we can bring up Juno without _DSD (Graeme is working on that, still need
>> some time to clean up the code).
>>
>>>
>>> I think SBSA is too vague to guarantee a kernel image running on a
>>> compliant platform without additional (vendor-specific) tweaks. So what
>>> I asked for is (1) a document (guide) to define the strict set of ACPI
>>> features and bindings needed for a real SoC and (2) proof that the
>>> guidelines are enough for real hardware. I think we have (1) under
>>> review with some good feedback so far. As for (2), we can probably only
>>> discuss Juno openly. I think you could share the additional Juno patches
>>> on this list so that reviewers can assess the suitability. If we deem
>>> ACPI not (yet) suitable for Juno, is there other platform we could see
>>> patches for?
>>
>> Ok, we will send out all the patches for Juno in next version for review,
>> as mentioned above, we still need more time to clean up the code.
>>
>>>
>>>>> Given the answer to (a) and what other features are needed, we may or
>>>>> may not mandate (b). We were pretty clear few months ago that (b) is
>>>>> still required but at the time we were only openly talking about ACPI
>>>>> 5.0 which was lacking many features. I think we need to revisit that
>>>>> position based on how usable ACPI 5.1 for ARM (and current kernel
>>>>> implementation) is. Would you mind elaborating what an ACPI-only
>>>>> platform miss?
>>>>
>>>> Do you mean something still missing? We still miss some features for
>>>> ARM in ACPI, but I think they are not critical, here is the list I can
>>>> remember:
>>>> - ITS for GICv3/4;
>>>> - SMMU support;
>>>> - CPU idle control.
>>>
>>> I agree, these are not critical at this stage. But they only refer to
>>> architected peripherals. Is there anything else missing for an SoC? Do
>>> we need to define clocks?
>>
>> No, I prefer not. As we discussed in this thread before, we don't need
>> clock definition if we use SBSA compatible UART on Juno.
>>
>>>
>>>> For ACPI 5.1, it fixes many problems for ARM:
>>>> - weak definition for GIC, so we introduce visualization, v2m and
>>>>   part of GICv3/4 (redistributors) support.
>>>> - No support for PSCI. Fix it to support PSCI 0.2+;
>>>> - Not support for Always-on timer and SBSA-L1 watchdog.
>>>
>>> These are all good, that's why we shouldn't even talk about ACPI 5.0 in
>>> the ARM context.
>>>
>>>> - How to describe device properties, so _DSD is introduced for
>>>>   device probe.
>>>
>>> For the last bullet, is there any review process (at least like what we
>>> have for DT bindings)? On top of such process, do we have guidelines and
>>> example code on how the Linux support should be implemented. As Olof
>>> mentioned, should we see how the DT and ACPI probing paths work
>>> together? I really think we should be very clear here and not let
>>> vendors invent their own independent methods.
>>
>> As said above, Intel folks provided some good examples for that, and
>> clarified a lot of things:
>>
>> https://lkml.org/lkml/2014/8/17/10
>>
>>>
>>>>> I would expect a new server platform designed with ACPI in mind to
>>>>> require minimal SoC specific code, so we may only see a few patches
>>>>> under drivers/ for such platforms adding ACPI-specific probing (possibly
>>>>> new drivers as well if it's a new component).
>>>>>
>>>>>> For this patch set, DT is the first class citizen at now:
>>>>>>
>>>>>> a) We can always set CONFIG_ACPI as off in Kconfig, and use DT only;
>>>>>
>>>>> Not just off but, based on maturity, depend on EXPERT.
>>>>
>>>> Ok. And don't set ACPI default off (pass acpi=on to enable it)?
>>>
>>> That's my view, just make it clear ACPI is experimental at the Kconfig
>>> level because longer term we won't mandate SoCs to provide both DT and
>>> ACPI tables.
>>
>> I agree with you that if we set ACPI default off, firmware will always
>> pass acpi=on if they want to use ACPI, so I think it would be better
>> to depend on EXPERT instead.
>>
>> Olof, is it ok to you too?
> 
> Given that we're going through all these complex schemes to merge code
> that isn't ready and keeping it off by default, the answer is really
> to continue holding off merging it.
> 
> We already had agreement from earlier this year that we needed to see
> several systems in the _market_ that uses ACPI before we have an idea of
> how messy they will be in reality. Not eval boards, development systems
> or reference designs. None of the current discussion has changed that.

I think some SBSA compatible ARM64 server boards would work, such as Seattle
board, right?

> 
> There's also the concern that there are still significant portions missing
> from 5.1 that won't be there until 5.2 or later. Having experimental
> 5.1 support for a few systems (out of tree) is likely going to result in
> finding out things that don't work well and should be revised -- if we
> don't merge this now then we can avoid having to keep the 5.1 backwards
> compatibility forever. Compare this to how we've been regretting some
> of the early-defined bindings on DT and wish we didn't have to keep
> them around. Please learn from our mistakes. :-)

Yes, there are some features missing in ACPI 5.1, and I list them out
in previous email replying Catalin, as I said, they are not critical
for ARM64 for now.

> 
> On the patches themselves:
> 
> It's great to see the patch sets posted, and they're looking pretty good
> -- things are very much heading in the right direction. My main remaining
> objection is around how it is integrated with the arch code. I don't
> like seeing all the dual code paths that ACPI introduces. It's obvious
> that two completely different entities have written the ACPI and the DT
> portions of the kernel, and we can't really have that situation for a
> brand new architecture like this.
> 
> So, I'd like to see closer integration between the two before code
> goes in. More shared code path and driving the differences through data
> (or possibly function pointers in places, etc), and fewer completely
> separate implementations.

I'm working on it, I hope I can achieve that, you know, it needs
more efforts to do it :)

> 
> Until then, please keep posting patches for review -- it's useful
> to see where it's going. I think it's also useful to get the generic
> ACPI integration merged as it has been already (with pieces going in
> over time).

Sure I will :)

Thanks
Hanjun