* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-11 23:57 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-arm-kernel
ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is
used to describe the processor and cache topology. Ideally it is
used to extend/override information provided by the hardware, but
right now ARM64 is entirely dependent on firmware provided tables.
This patch parses the table for the cache topology and CPU topology.
When we enable ACPI/PPTT for arm64 we map the package_id to the
PPTT node flagged as the physical package by the firmware.
This results in topologies that match what the remainder of the
system expects. Finally, we update the scheduler MC domain so that
it generally reflects the LLC unless the LLC is too large for the
NUMA domain (or package).
For example on juno:
[root at mammon-juno-rh topology]# lstopo-no-graphics
Package L#0
L2 L#0 (1024KB)
L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)
L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2 + PU L#2 (P#2)
L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3 + PU L#3 (P#3)
L2 L#1 (2048KB)
L1d L#4 (32KB) + L1i L#4 (48KB) + Core L#4 + PU L#4 (P#4)
L1d L#5 (32KB) + L1i L#5 (48KB) + Core L#5 + PU L#5 (P#5)
HostBridge L#0
PCIBridge
PCIBridge
PCIBridge
PCI 1095:3132
Block(Disk) L#0 "sda"
PCIBridge
PCI 1002:68f9
GPU L#1 "renderD128"
GPU L#2 "card0"
GPU L#3 "controlD64"
PCIBridge
PCI 11ab:4380
Net L#4 "enp8s0"
Git tree at:
http://linux-arm.org/git?p=linux-jlinton.git
branch: pptt_v9
v8->v9:
Add further ack/tested by's (thanks everyone)
kerneldoc, general comment and patch description tweaks.
Squash the pptt.c module (#5 & #13) back together.
remove a redundant () in an if, and rename a variable.
v7->v8:
Modify the logic used to select the MC domain (the change
shouldn't modify the sched domains on any existing machines
compared to v7, only how they are built)
Reduce the severity of some parsing messages.
Fix s390 link problem.
Further checks to deal with broken PPTT tables.
Various style tweaks, SPDX license addition, etc.
(see previous cover letters for further changes)
Jeremy Linton (12):
drivers: base: cacheinfo: move cache_setup_of_node()
drivers: base: cacheinfo: setup DT cache properties early
cacheinfo: rename of_node to fw_token
arm64/acpi: Create arch specific cpu to acpi id helper
ACPI/PPTT: Add Processor Properties Topology Table parsing
ACPI: Enable PPTT support on ARM64
drivers: base cacheinfo: Add support for ACPI based firmware tables
arm64: Add support for ACPI based firmware tables
arm64: topology: rename cluster_id
arm64: topology: enable ACPI/PPTT based CPU topology
ACPI: Add PPTT to injectable table list
arm64: topology: divorce MC scheduling domain from core_siblings
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/acpi.h | 4 +
arch/arm64/include/asm/topology.h | 6 +-
arch/arm64/kernel/cacheinfo.c | 15 +-
arch/arm64/kernel/topology.c | 107 ++++++-
arch/riscv/kernel/cacheinfo.c | 1 -
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/pptt.c | 655 ++++++++++++++++++++++++++++++++++++++
drivers/acpi/tables.c | 2 +-
drivers/base/cacheinfo.c | 157 ++++-----
include/linux/acpi.h | 4 +
include/linux/cacheinfo.h | 25 +-
13 files changed, 874 insertions(+), 107 deletions(-)
create mode 100644 drivers/acpi/pptt.c
--
2.13.6
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-11 23:57 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-riscv
ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is
used to describe the processor and cache topology. Ideally it is
used to extend/override information provided by the hardware, but
right now ARM64 is entirely dependent on firmware provided tables.
This patch parses the table for the cache topology and CPU topology.
When we enable ACPI/PPTT for arm64 we map the package_id to the
PPTT node flagged as the physical package by the firmware.
This results in topologies that match what the remainder of the
system expects. Finally, we update the scheduler MC domain so that
it generally reflects the LLC unless the LLC is too large for the
NUMA domain (or package).
For example on juno:
[root at mammon-juno-rh topology]# lstopo-no-graphics
Package L#0
L2 L#0 (1024KB)
L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)
L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2 + PU L#2 (P#2)
L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3 + PU L#3 (P#3)
L2 L#1 (2048KB)
L1d L#4 (32KB) + L1i L#4 (48KB) + Core L#4 + PU L#4 (P#4)
L1d L#5 (32KB) + L1i L#5 (48KB) + Core L#5 + PU L#5 (P#5)
HostBridge L#0
PCIBridge
PCIBridge
PCIBridge
PCI 1095:3132
Block(Disk) L#0 "sda"
PCIBridge
PCI 1002:68f9
GPU L#1 "renderD128"
GPU L#2 "card0"
GPU L#3 "controlD64"
PCIBridge
PCI 11ab:4380
Net L#4 "enp8s0"
Git tree at:
http://linux-arm.org/git?p=linux-jlinton.git
branch: pptt_v9
v8->v9:
Add further ack/tested by's (thanks everyone)
kerneldoc, general comment and patch description tweaks.
Squash the pptt.c module (#5 & #13) back together.
remove a redundant () in an if, and rename a variable.
v7->v8:
Modify the logic used to select the MC domain (the change
shouldn't modify the sched domains on any existing machines
compared to v7, only how they are built)
Reduce the severity of some parsing messages.
Fix s390 link problem.
Further checks to deal with broken PPTT tables.
Various style tweaks, SPDX license addition, etc.
(see previous cover letters for further changes)
Jeremy Linton (12):
drivers: base: cacheinfo: move cache_setup_of_node()
drivers: base: cacheinfo: setup DT cache properties early
cacheinfo: rename of_node to fw_token
arm64/acpi: Create arch specific cpu to acpi id helper
ACPI/PPTT: Add Processor Properties Topology Table parsing
ACPI: Enable PPTT support on ARM64
drivers: base cacheinfo: Add support for ACPI based firmware tables
arm64: Add support for ACPI based firmware tables
arm64: topology: rename cluster_id
arm64: topology: enable ACPI/PPTT based CPU topology
ACPI: Add PPTT to injectable table list
arm64: topology: divorce MC scheduling domain from core_siblings
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/acpi.h | 4 +
arch/arm64/include/asm/topology.h | 6 +-
arch/arm64/kernel/cacheinfo.c | 15 +-
arch/arm64/kernel/topology.c | 107 ++++++-
arch/riscv/kernel/cacheinfo.c | 1 -
drivers/acpi/Kconfig | 3 +
drivers/acpi/Makefile | 1 +
drivers/acpi/pptt.c | 655 ++++++++++++++++++++++++++++++++++++++
drivers/acpi/tables.c | 2 +-
drivers/base/cacheinfo.c | 157 ++++-----
include/linux/acpi.h | 4 +
include/linux/cacheinfo.h | 25 +-
13 files changed, 874 insertions(+), 107 deletions(-)
create mode 100644 drivers/acpi/pptt.c
--
2.13.6
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 01/12] drivers: base: cacheinfo: move cache_setup_of_node()
2018-05-11 23:57 ` Jeremy Linton
(?)
@ 2018-05-11 23:57 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-acpi
Cc: Sudeep.Holla, linux-arm-kernel, Lorenzo.Pieralisi, hanjun.guo,
rjw, Will.Deacon, Catalin.Marinas, gregkh, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel, Jeremy Linton
In preparation for the next patch, and to aid in
review of that patch, lets move cache_setup_of_node
further down in the module without any changes.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/base/cacheinfo.c | 80 ++++++++++++++++++++++++------------------------
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index edf726267282..09ccef7ddc99 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -32,46 +32,6 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu)
}
#ifdef CONFIG_OF
-static int cache_setup_of_node(unsigned int cpu)
-{
- struct device_node *np;
- struct cacheinfo *this_leaf;
- struct device *cpu_dev = get_cpu_device(cpu);
- struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
- unsigned int index = 0;
-
- /* skip if of_node is already populated */
- if (this_cpu_ci->info_list->of_node)
- return 0;
-
- if (!cpu_dev) {
- pr_err("No cpu device for CPU %d\n", cpu);
- return -ENODEV;
- }
- np = cpu_dev->of_node;
- if (!np) {
- pr_err("Failed to find cpu%d device node\n", cpu);
- return -ENOENT;
- }
-
- while (index < cache_leaves(cpu)) {
- this_leaf = this_cpu_ci->info_list + index;
- if (this_leaf->level != 1)
- np = of_find_next_cache_node(np);
- else
- np = of_node_get(np);/* cpu node itself */
- if (!np)
- break;
- this_leaf->of_node = np;
- index++;
- }
-
- if (index != cache_leaves(cpu)) /* not all OF nodes populated */
- return -ENOENT;
-
- return 0;
-}
-
static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
struct cacheinfo *sib_leaf)
{
@@ -202,6 +162,46 @@ static void cache_of_override_properties(unsigned int cpu)
cache_associativity(this_leaf);
}
}
+
+static int cache_setup_of_node(unsigned int cpu)
+{
+ struct device_node *np;
+ struct cacheinfo *this_leaf;
+ struct device *cpu_dev = get_cpu_device(cpu);
+ struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
+ unsigned int index = 0;
+
+ /* skip if of_node is already populated */
+ if (this_cpu_ci->info_list->of_node)
+ return 0;
+
+ if (!cpu_dev) {
+ pr_err("No cpu device for CPU %d\n", cpu);
+ return -ENODEV;
+ }
+ np = cpu_dev->of_node;
+ if (!np) {
+ pr_err("Failed to find cpu%d device node\n", cpu);
+ return -ENOENT;
+ }
+
+ while (index < cache_leaves(cpu)) {
+ this_leaf = this_cpu_ci->info_list + index;
+ if (this_leaf->level != 1)
+ np = of_find_next_cache_node(np);
+ else
+ np = of_node_get(np);/* cpu node itself */
+ if (!np)
+ break;
+ this_leaf->of_node = np;
+ index++;
+ }
+
+ if (index != cache_leaves(cpu)) /* not all OF nodes populated */
+ return -ENOENT;
+
+ return 0;
+}
#else
static void cache_of_override_properties(unsigned int cpu) { }
static inline int cache_setup_of_node(unsigned int cpu) { return 0; }
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 01/12] drivers: base: cacheinfo: move cache_setup_of_node()
@ 2018-05-11 23:57 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In preparation for the next patch, and to aid in
review of that patch, lets move cache_setup_of_node
further down in the module without any changes.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/base/cacheinfo.c | 80 ++++++++++++++++++++++++------------------------
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index edf726267282..09ccef7ddc99 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -32,46 +32,6 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu)
}
#ifdef CONFIG_OF
-static int cache_setup_of_node(unsigned int cpu)
-{
- struct device_node *np;
- struct cacheinfo *this_leaf;
- struct device *cpu_dev = get_cpu_device(cpu);
- struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
- unsigned int index = 0;
-
- /* skip if of_node is already populated */
- if (this_cpu_ci->info_list->of_node)
- return 0;
-
- if (!cpu_dev) {
- pr_err("No cpu device for CPU %d\n", cpu);
- return -ENODEV;
- }
- np = cpu_dev->of_node;
- if (!np) {
- pr_err("Failed to find cpu%d device node\n", cpu);
- return -ENOENT;
- }
-
- while (index < cache_leaves(cpu)) {
- this_leaf = this_cpu_ci->info_list + index;
- if (this_leaf->level != 1)
- np = of_find_next_cache_node(np);
- else
- np = of_node_get(np);/* cpu node itself */
- if (!np)
- break;
- this_leaf->of_node = np;
- index++;
- }
-
- if (index != cache_leaves(cpu)) /* not all OF nodes populated */
- return -ENOENT;
-
- return 0;
-}
-
static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
struct cacheinfo *sib_leaf)
{
@@ -202,6 +162,46 @@ static void cache_of_override_properties(unsigned int cpu)
cache_associativity(this_leaf);
}
}
+
+static int cache_setup_of_node(unsigned int cpu)
+{
+ struct device_node *np;
+ struct cacheinfo *this_leaf;
+ struct device *cpu_dev = get_cpu_device(cpu);
+ struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
+ unsigned int index = 0;
+
+ /* skip if of_node is already populated */
+ if (this_cpu_ci->info_list->of_node)
+ return 0;
+
+ if (!cpu_dev) {
+ pr_err("No cpu device for CPU %d\n", cpu);
+ return -ENODEV;
+ }
+ np = cpu_dev->of_node;
+ if (!np) {
+ pr_err("Failed to find cpu%d device node\n", cpu);
+ return -ENOENT;
+ }
+
+ while (index < cache_leaves(cpu)) {
+ this_leaf = this_cpu_ci->info_list + index;
+ if (this_leaf->level != 1)
+ np = of_find_next_cache_node(np);
+ else
+ np = of_node_get(np);/* cpu node itself */
+ if (!np)
+ break;
+ this_leaf->of_node = np;
+ index++;
+ }
+
+ if (index != cache_leaves(cpu)) /* not all OF nodes populated */
+ return -ENOENT;
+
+ return 0;
+}
#else
static void cache_of_override_properties(unsigned int cpu) { }
static inline int cache_setup_of_node(unsigned int cpu) { return 0; }
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 01/12] drivers: base: cacheinfo: move cache_setup_of_node()
@ 2018-05-11 23:57 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-riscv
In preparation for the next patch, and to aid in
review of that patch, lets move cache_setup_of_node
further down in the module without any changes.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/base/cacheinfo.c | 80 ++++++++++++++++++++++++------------------------
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index edf726267282..09ccef7ddc99 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -32,46 +32,6 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu)
}
#ifdef CONFIG_OF
-static int cache_setup_of_node(unsigned int cpu)
-{
- struct device_node *np;
- struct cacheinfo *this_leaf;
- struct device *cpu_dev = get_cpu_device(cpu);
- struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
- unsigned int index = 0;
-
- /* skip if of_node is already populated */
- if (this_cpu_ci->info_list->of_node)
- return 0;
-
- if (!cpu_dev) {
- pr_err("No cpu device for CPU %d\n", cpu);
- return -ENODEV;
- }
- np = cpu_dev->of_node;
- if (!np) {
- pr_err("Failed to find cpu%d device node\n", cpu);
- return -ENOENT;
- }
-
- while (index < cache_leaves(cpu)) {
- this_leaf = this_cpu_ci->info_list + index;
- if (this_leaf->level != 1)
- np = of_find_next_cache_node(np);
- else
- np = of_node_get(np);/* cpu node itself */
- if (!np)
- break;
- this_leaf->of_node = np;
- index++;
- }
-
- if (index != cache_leaves(cpu)) /* not all OF nodes populated */
- return -ENOENT;
-
- return 0;
-}
-
static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
struct cacheinfo *sib_leaf)
{
@@ -202,6 +162,46 @@ static void cache_of_override_properties(unsigned int cpu)
cache_associativity(this_leaf);
}
}
+
+static int cache_setup_of_node(unsigned int cpu)
+{
+ struct device_node *np;
+ struct cacheinfo *this_leaf;
+ struct device *cpu_dev = get_cpu_device(cpu);
+ struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
+ unsigned int index = 0;
+
+ /* skip if of_node is already populated */
+ if (this_cpu_ci->info_list->of_node)
+ return 0;
+
+ if (!cpu_dev) {
+ pr_err("No cpu device for CPU %d\n", cpu);
+ return -ENODEV;
+ }
+ np = cpu_dev->of_node;
+ if (!np) {
+ pr_err("Failed to find cpu%d device node\n", cpu);
+ return -ENOENT;
+ }
+
+ while (index < cache_leaves(cpu)) {
+ this_leaf = this_cpu_ci->info_list + index;
+ if (this_leaf->level != 1)
+ np = of_find_next_cache_node(np);
+ else
+ np = of_node_get(np);/* cpu node itself */
+ if (!np)
+ break;
+ this_leaf->of_node = np;
+ index++;
+ }
+
+ if (index != cache_leaves(cpu)) /* not all OF nodes populated */
+ return -ENOENT;
+
+ return 0;
+}
#else
static void cache_of_override_properties(unsigned int cpu) { }
static inline int cache_setup_of_node(unsigned int cpu) { return 0; }
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
2018-05-11 23:57 ` Jeremy Linton
(?)
(?)
@ 2018-05-11 23:57 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-acpi
Cc: Mark.Rutland, austinwc, tnowicki, Catalin.Marinas, palmer,
Will.Deacon, linux-riscv, Morten.Rasmussen, vkilari,
Lorenzo.Pieralisi, jhugo, ahs3, lenb, john.garry, wangxiongfeng2,
Dietmar.Eggemann, linux-arm-kernel, ard.biesheuvel, gregkh, rjw,
linux-kernel, Jeremy Linton, hanjun.guo, Sudeep.Holla
The original intent in cacheinfo was that an architecture
specific populate_cache_leaves() would probe the hardware
and then cache_shared_cpu_map_setup() and
cache_override_properties() would provide firmware help to
extend/expand upon what was probed. Arm64 was really
the only architecture that was working this way, and
with the removal of most of the hardware probing logic it
became clear that it was possible to simplify the logic a bit.
This patch combines the walk of the DT nodes with the
code updating the cache size/line_size and nr_sets.
cache_override_properties() (which was DT specific) is
then removed. The result is that cacheinfo.of_node is
no longer used as a temporary place to hold DT references
for future calls that update cache properties. That change
helps to clarify its one remaining use (matching
cacheinfo nodes that represent shared caches) which
will be used by the ACPI/PPTT code in the following patches.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/riscv/kernel/cacheinfo.c | 1 -
drivers/base/cacheinfo.c | 65 +++++++++++++++++++------------------------
2 files changed, 29 insertions(+), 37 deletions(-)
diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c
index 10ed2749e246..0bc86e5f8f3f 100644
--- a/arch/riscv/kernel/cacheinfo.c
+++ b/arch/riscv/kernel/cacheinfo.c
@@ -20,7 +20,6 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
struct device_node *node,
enum cache_type type, unsigned int level)
{
- this_leaf->of_node = node;
this_leaf->level = level;
this_leaf->type = type;
/* not a sector cache */
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 09ccef7ddc99..a872523e8951 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -71,7 +71,7 @@ static inline int get_cacheinfo_idx(enum cache_type type)
return type;
}
-static void cache_size(struct cacheinfo *this_leaf)
+static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
const __be32 *cache_size;
@@ -80,13 +80,14 @@ static void cache_size(struct cacheinfo *this_leaf)
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].size_prop;
- cache_size = of_get_property(this_leaf->of_node, propname, NULL);
+ cache_size = of_get_property(np, propname, NULL);
if (cache_size)
this_leaf->size = of_read_number(cache_size, 1);
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
-static void cache_get_line_size(struct cacheinfo *this_leaf)
+static void cache_get_line_size(struct cacheinfo *this_leaf,
+ struct device_node *np)
{
const __be32 *line_size;
int i, lim, ct_idx;
@@ -98,7 +99,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
const char *propname;
propname = cache_type_info[ct_idx].line_size_props[i];
- line_size = of_get_property(this_leaf->of_node, propname, NULL);
+ line_size = of_get_property(np, propname, NULL);
if (line_size)
break;
}
@@ -107,7 +108,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
this_leaf->coherency_line_size = of_read_number(line_size, 1);
}
-static void cache_nr_sets(struct cacheinfo *this_leaf)
+static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
const __be32 *nr_sets;
@@ -116,7 +117,7 @@ static void cache_nr_sets(struct cacheinfo *this_leaf)
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].nr_sets_prop;
- nr_sets = of_get_property(this_leaf->of_node, propname, NULL);
+ nr_sets = of_get_property(np, propname, NULL);
if (nr_sets)
this_leaf->number_of_sets = of_read_number(nr_sets, 1);
}
@@ -135,32 +136,27 @@ static void cache_associativity(struct cacheinfo *this_leaf)
this_leaf->ways_of_associativity = (size / nr_sets) / line_size;
}
-static bool cache_node_is_unified(struct cacheinfo *this_leaf)
+static bool cache_node_is_unified(struct cacheinfo *this_leaf,
+ struct device_node *np)
{
- return of_property_read_bool(this_leaf->of_node, "cache-unified");
+ return of_property_read_bool(np, "cache-unified");
}
-static void cache_of_override_properties(unsigned int cpu)
+static void cache_of_set_props(struct cacheinfo *this_leaf,
+ struct device_node *np)
{
- int index;
- struct cacheinfo *this_leaf;
- struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
-
- for (index = 0; index < cache_leaves(cpu); index++) {
- this_leaf = this_cpu_ci->info_list + index;
- /*
- * init_cache_level must setup the cache level correctly
- * overriding the architecturally specified levels, so
- * if type is NONE at this stage, it should be unified
- */
- if (this_leaf->type == CACHE_TYPE_NOCACHE &&
- cache_node_is_unified(this_leaf))
- this_leaf->type = CACHE_TYPE_UNIFIED;
- cache_size(this_leaf);
- cache_get_line_size(this_leaf);
- cache_nr_sets(this_leaf);
- cache_associativity(this_leaf);
- }
+ /*
+ * init_cache_level must setup the cache level correctly
+ * overriding the architecturally specified levels, so
+ * if type is NONE at this stage, it should be unified
+ */
+ if (this_leaf->type == CACHE_TYPE_NOCACHE &&
+ cache_node_is_unified(this_leaf, np))
+ this_leaf->type = CACHE_TYPE_UNIFIED;
+ cache_size(this_leaf, np);
+ cache_get_line_size(this_leaf, np);
+ cache_nr_sets(this_leaf, np);
+ cache_associativity(this_leaf);
}
static int cache_setup_of_node(unsigned int cpu)
@@ -193,6 +189,7 @@ static int cache_setup_of_node(unsigned int cpu)
np = of_node_get(np);/* cpu node itself */
if (!np)
break;
+ cache_of_set_props(this_leaf, np);
this_leaf->of_node = np;
index++;
}
@@ -203,7 +200,6 @@ static int cache_setup_of_node(unsigned int cpu)
return 0;
}
#else
-static void cache_of_override_properties(unsigned int cpu) { }
static inline int cache_setup_of_node(unsigned int cpu) { return 0; }
static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
struct cacheinfo *sib_leaf)
@@ -286,12 +282,6 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
}
}
-static void cache_override_properties(unsigned int cpu)
-{
- if (of_have_populated_dt())
- return cache_of_override_properties(cpu);
-}
-
static void free_cache_attributes(unsigned int cpu)
{
if (!per_cpu_cacheinfo(cpu))
@@ -325,6 +315,10 @@ static int detect_cache_attributes(unsigned int cpu)
if (per_cpu_cacheinfo(cpu) == NULL)
return -ENOMEM;
+ /*
+ * populate_cache_leaves() may completely setup the cache leaves and
+ * shared_cpu_map or it may leave it partially setup.
+ */
ret = populate_cache_leaves(cpu);
if (ret)
goto free_ci;
@@ -338,7 +332,6 @@ static int detect_cache_attributes(unsigned int cpu)
goto free_ci;
}
- cache_override_properties(cpu);
return 0;
free_ci:
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-11 23:57 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-arm-kernel
The original intent in cacheinfo was that an architecture
specific populate_cache_leaves() would probe the hardware
and then cache_shared_cpu_map_setup() and
cache_override_properties() would provide firmware help to
extend/expand upon what was probed. Arm64 was really
the only architecture that was working this way, and
with the removal of most of the hardware probing logic it
became clear that it was possible to simplify the logic a bit.
This patch combines the walk of the DT nodes with the
code updating the cache size/line_size and nr_sets.
cache_override_properties() (which was DT specific) is
then removed. The result is that cacheinfo.of_node is
no longer used as a temporary place to hold DT references
for future calls that update cache properties. That change
helps to clarify its one remaining use (matching
cacheinfo nodes that represent shared caches) which
will be used by the ACPI/PPTT code in the following patches.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/riscv/kernel/cacheinfo.c | 1 -
drivers/base/cacheinfo.c | 65 +++++++++++++++++++------------------------
2 files changed, 29 insertions(+), 37 deletions(-)
diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c
index 10ed2749e246..0bc86e5f8f3f 100644
--- a/arch/riscv/kernel/cacheinfo.c
+++ b/arch/riscv/kernel/cacheinfo.c
@@ -20,7 +20,6 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
struct device_node *node,
enum cache_type type, unsigned int level)
{
- this_leaf->of_node = node;
this_leaf->level = level;
this_leaf->type = type;
/* not a sector cache */
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 09ccef7ddc99..a872523e8951 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -71,7 +71,7 @@ static inline int get_cacheinfo_idx(enum cache_type type)
return type;
}
-static void cache_size(struct cacheinfo *this_leaf)
+static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
const __be32 *cache_size;
@@ -80,13 +80,14 @@ static void cache_size(struct cacheinfo *this_leaf)
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].size_prop;
- cache_size = of_get_property(this_leaf->of_node, propname, NULL);
+ cache_size = of_get_property(np, propname, NULL);
if (cache_size)
this_leaf->size = of_read_number(cache_size, 1);
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
-static void cache_get_line_size(struct cacheinfo *this_leaf)
+static void cache_get_line_size(struct cacheinfo *this_leaf,
+ struct device_node *np)
{
const __be32 *line_size;
int i, lim, ct_idx;
@@ -98,7 +99,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
const char *propname;
propname = cache_type_info[ct_idx].line_size_props[i];
- line_size = of_get_property(this_leaf->of_node, propname, NULL);
+ line_size = of_get_property(np, propname, NULL);
if (line_size)
break;
}
@@ -107,7 +108,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
this_leaf->coherency_line_size = of_read_number(line_size, 1);
}
-static void cache_nr_sets(struct cacheinfo *this_leaf)
+static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
const __be32 *nr_sets;
@@ -116,7 +117,7 @@ static void cache_nr_sets(struct cacheinfo *this_leaf)
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].nr_sets_prop;
- nr_sets = of_get_property(this_leaf->of_node, propname, NULL);
+ nr_sets = of_get_property(np, propname, NULL);
if (nr_sets)
this_leaf->number_of_sets = of_read_number(nr_sets, 1);
}
@@ -135,32 +136,27 @@ static void cache_associativity(struct cacheinfo *this_leaf)
this_leaf->ways_of_associativity = (size / nr_sets) / line_size;
}
-static bool cache_node_is_unified(struct cacheinfo *this_leaf)
+static bool cache_node_is_unified(struct cacheinfo *this_leaf,
+ struct device_node *np)
{
- return of_property_read_bool(this_leaf->of_node, "cache-unified");
+ return of_property_read_bool(np, "cache-unified");
}
-static void cache_of_override_properties(unsigned int cpu)
+static void cache_of_set_props(struct cacheinfo *this_leaf,
+ struct device_node *np)
{
- int index;
- struct cacheinfo *this_leaf;
- struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
-
- for (index = 0; index < cache_leaves(cpu); index++) {
- this_leaf = this_cpu_ci->info_list + index;
- /*
- * init_cache_level must setup the cache level correctly
- * overriding the architecturally specified levels, so
- * if type is NONE at this stage, it should be unified
- */
- if (this_leaf->type == CACHE_TYPE_NOCACHE &&
- cache_node_is_unified(this_leaf))
- this_leaf->type = CACHE_TYPE_UNIFIED;
- cache_size(this_leaf);
- cache_get_line_size(this_leaf);
- cache_nr_sets(this_leaf);
- cache_associativity(this_leaf);
- }
+ /*
+ * init_cache_level must setup the cache level correctly
+ * overriding the architecturally specified levels, so
+ * if type is NONE at this stage, it should be unified
+ */
+ if (this_leaf->type == CACHE_TYPE_NOCACHE &&
+ cache_node_is_unified(this_leaf, np))
+ this_leaf->type = CACHE_TYPE_UNIFIED;
+ cache_size(this_leaf, np);
+ cache_get_line_size(this_leaf, np);
+ cache_nr_sets(this_leaf, np);
+ cache_associativity(this_leaf);
}
static int cache_setup_of_node(unsigned int cpu)
@@ -193,6 +189,7 @@ static int cache_setup_of_node(unsigned int cpu)
np = of_node_get(np);/* cpu node itself */
if (!np)
break;
+ cache_of_set_props(this_leaf, np);
this_leaf->of_node = np;
index++;
}
@@ -203,7 +200,6 @@ static int cache_setup_of_node(unsigned int cpu)
return 0;
}
#else
-static void cache_of_override_properties(unsigned int cpu) { }
static inline int cache_setup_of_node(unsigned int cpu) { return 0; }
static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
struct cacheinfo *sib_leaf)
@@ -286,12 +282,6 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
}
}
-static void cache_override_properties(unsigned int cpu)
-{
- if (of_have_populated_dt())
- return cache_of_override_properties(cpu);
-}
-
static void free_cache_attributes(unsigned int cpu)
{
if (!per_cpu_cacheinfo(cpu))
@@ -325,6 +315,10 @@ static int detect_cache_attributes(unsigned int cpu)
if (per_cpu_cacheinfo(cpu) == NULL)
return -ENOMEM;
+ /*
+ * populate_cache_leaves() may completely setup the cache leaves and
+ * shared_cpu_map or it may leave it partially setup.
+ */
ret = populate_cache_leaves(cpu);
if (ret)
goto free_ci;
@@ -338,7 +332,6 @@ static int detect_cache_attributes(unsigned int cpu)
goto free_ci;
}
- cache_override_properties(cpu);
return 0;
free_ci:
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-11 23:57 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-riscv
The original intent in cacheinfo was that an architecture
specific populate_cache_leaves() would probe the hardware
and then cache_shared_cpu_map_setup() and
cache_override_properties() would provide firmware help to
extend/expand upon what was probed. Arm64 was really
the only architecture that was working this way, and
with the removal of most of the hardware probing logic it
became clear that it was possible to simplify the logic a bit.
This patch combines the walk of the DT nodes with the
code updating the cache size/line_size and nr_sets.
cache_override_properties() (which was DT specific) is
then removed. The result is that cacheinfo.of_node is
no longer used as a temporary place to hold DT references
for future calls that update cache properties. That change
helps to clarify its one remaining use (matching
cacheinfo nodes that represent shared caches) which
will be used by the ACPI/PPTT code in the following patches.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/riscv/kernel/cacheinfo.c | 1 -
drivers/base/cacheinfo.c | 65 +++++++++++++++++++------------------------
2 files changed, 29 insertions(+), 37 deletions(-)
diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c
index 10ed2749e246..0bc86e5f8f3f 100644
--- a/arch/riscv/kernel/cacheinfo.c
+++ b/arch/riscv/kernel/cacheinfo.c
@@ -20,7 +20,6 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
struct device_node *node,
enum cache_type type, unsigned int level)
{
- this_leaf->of_node = node;
this_leaf->level = level;
this_leaf->type = type;
/* not a sector cache */
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 09ccef7ddc99..a872523e8951 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -71,7 +71,7 @@ static inline int get_cacheinfo_idx(enum cache_type type)
return type;
}
-static void cache_size(struct cacheinfo *this_leaf)
+static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
const __be32 *cache_size;
@@ -80,13 +80,14 @@ static void cache_size(struct cacheinfo *this_leaf)
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].size_prop;
- cache_size = of_get_property(this_leaf->of_node, propname, NULL);
+ cache_size = of_get_property(np, propname, NULL);
if (cache_size)
this_leaf->size = of_read_number(cache_size, 1);
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
-static void cache_get_line_size(struct cacheinfo *this_leaf)
+static void cache_get_line_size(struct cacheinfo *this_leaf,
+ struct device_node *np)
{
const __be32 *line_size;
int i, lim, ct_idx;
@@ -98,7 +99,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
const char *propname;
propname = cache_type_info[ct_idx].line_size_props[i];
- line_size = of_get_property(this_leaf->of_node, propname, NULL);
+ line_size = of_get_property(np, propname, NULL);
if (line_size)
break;
}
@@ -107,7 +108,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
this_leaf->coherency_line_size = of_read_number(line_size, 1);
}
-static void cache_nr_sets(struct cacheinfo *this_leaf)
+static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
const __be32 *nr_sets;
@@ -116,7 +117,7 @@ static void cache_nr_sets(struct cacheinfo *this_leaf)
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].nr_sets_prop;
- nr_sets = of_get_property(this_leaf->of_node, propname, NULL);
+ nr_sets = of_get_property(np, propname, NULL);
if (nr_sets)
this_leaf->number_of_sets = of_read_number(nr_sets, 1);
}
@@ -135,32 +136,27 @@ static void cache_associativity(struct cacheinfo *this_leaf)
this_leaf->ways_of_associativity = (size / nr_sets) / line_size;
}
-static bool cache_node_is_unified(struct cacheinfo *this_leaf)
+static bool cache_node_is_unified(struct cacheinfo *this_leaf,
+ struct device_node *np)
{
- return of_property_read_bool(this_leaf->of_node, "cache-unified");
+ return of_property_read_bool(np, "cache-unified");
}
-static void cache_of_override_properties(unsigned int cpu)
+static void cache_of_set_props(struct cacheinfo *this_leaf,
+ struct device_node *np)
{
- int index;
- struct cacheinfo *this_leaf;
- struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
-
- for (index = 0; index < cache_leaves(cpu); index++) {
- this_leaf = this_cpu_ci->info_list + index;
- /*
- * init_cache_level must setup the cache level correctly
- * overriding the architecturally specified levels, so
- * if type is NONE at this stage, it should be unified
- */
- if (this_leaf->type == CACHE_TYPE_NOCACHE &&
- cache_node_is_unified(this_leaf))
- this_leaf->type = CACHE_TYPE_UNIFIED;
- cache_size(this_leaf);
- cache_get_line_size(this_leaf);
- cache_nr_sets(this_leaf);
- cache_associativity(this_leaf);
- }
+ /*
+ * init_cache_level must setup the cache level correctly
+ * overriding the architecturally specified levels, so
+ * if type is NONE at this stage, it should be unified
+ */
+ if (this_leaf->type == CACHE_TYPE_NOCACHE &&
+ cache_node_is_unified(this_leaf, np))
+ this_leaf->type = CACHE_TYPE_UNIFIED;
+ cache_size(this_leaf, np);
+ cache_get_line_size(this_leaf, np);
+ cache_nr_sets(this_leaf, np);
+ cache_associativity(this_leaf);
}
static int cache_setup_of_node(unsigned int cpu)
@@ -193,6 +189,7 @@ static int cache_setup_of_node(unsigned int cpu)
np = of_node_get(np);/* cpu node itself */
if (!np)
break;
+ cache_of_set_props(this_leaf, np);
this_leaf->of_node = np;
index++;
}
@@ -203,7 +200,6 @@ static int cache_setup_of_node(unsigned int cpu)
return 0;
}
#else
-static void cache_of_override_properties(unsigned int cpu) { }
static inline int cache_setup_of_node(unsigned int cpu) { return 0; }
static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
struct cacheinfo *sib_leaf)
@@ -286,12 +282,6 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
}
}
-static void cache_override_properties(unsigned int cpu)
-{
- if (of_have_populated_dt())
- return cache_of_override_properties(cpu);
-}
-
static void free_cache_attributes(unsigned int cpu)
{
if (!per_cpu_cacheinfo(cpu))
@@ -325,6 +315,10 @@ static int detect_cache_attributes(unsigned int cpu)
if (per_cpu_cacheinfo(cpu) == NULL)
return -ENOMEM;
+ /*
+ * populate_cache_leaves() may completely setup the cache leaves and
+ * shared_cpu_map or it may leave it partially setup.
+ */
ret = populate_cache_leaves(cpu);
if (ret)
goto free_ci;
@@ -338,7 +332,6 @@ static int detect_cache_attributes(unsigned int cpu)
goto free_ci;
}
- cache_override_properties(cpu);
return 0;
free_ci:
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-11 23:57 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-acpi
Cc: Sudeep.Holla, linux-arm-kernel, Lorenzo.Pieralisi, hanjun.guo,
rjw, Will.Deacon, Catalin.Marinas, gregkh, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel, Jeremy Linton
The original intent in cacheinfo was that an architecture
specific populate_cache_leaves() would probe the hardware
and then cache_shared_cpu_map_setup() and
cache_override_properties() would provide firmware help to
extend/expand upon what was probed. Arm64 was really
the only architecture that was working this way, and
with the removal of most of the hardware probing logic it
became clear that it was possible to simplify the logic a bit.
This patch combines the walk of the DT nodes with the
code updating the cache size/line_size and nr_sets.
cache_override_properties() (which was DT specific) is
then removed. The result is that cacheinfo.of_node is
no longer used as a temporary place to hold DT references
for future calls that update cache properties. That change
helps to clarify its one remaining use (matching
cacheinfo nodes that represent shared caches) which
will be used by the ACPI/PPTT code in the following patches.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/riscv/kernel/cacheinfo.c | 1 -
drivers/base/cacheinfo.c | 65 +++++++++++++++++++------------------------
2 files changed, 29 insertions(+), 37 deletions(-)
diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c
index 10ed2749e246..0bc86e5f8f3f 100644
--- a/arch/riscv/kernel/cacheinfo.c
+++ b/arch/riscv/kernel/cacheinfo.c
@@ -20,7 +20,6 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
struct device_node *node,
enum cache_type type, unsigned int level)
{
- this_leaf->of_node = node;
this_leaf->level = level;
this_leaf->type = type;
/* not a sector cache */
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 09ccef7ddc99..a872523e8951 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -71,7 +71,7 @@ static inline int get_cacheinfo_idx(enum cache_type type)
return type;
}
-static void cache_size(struct cacheinfo *this_leaf)
+static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
const __be32 *cache_size;
@@ -80,13 +80,14 @@ static void cache_size(struct cacheinfo *this_leaf)
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].size_prop;
- cache_size = of_get_property(this_leaf->of_node, propname, NULL);
+ cache_size = of_get_property(np, propname, NULL);
if (cache_size)
this_leaf->size = of_read_number(cache_size, 1);
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
-static void cache_get_line_size(struct cacheinfo *this_leaf)
+static void cache_get_line_size(struct cacheinfo *this_leaf,
+ struct device_node *np)
{
const __be32 *line_size;
int i, lim, ct_idx;
@@ -98,7 +99,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
const char *propname;
propname = cache_type_info[ct_idx].line_size_props[i];
- line_size = of_get_property(this_leaf->of_node, propname, NULL);
+ line_size = of_get_property(np, propname, NULL);
if (line_size)
break;
}
@@ -107,7 +108,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
this_leaf->coherency_line_size = of_read_number(line_size, 1);
}
-static void cache_nr_sets(struct cacheinfo *this_leaf)
+static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
const __be32 *nr_sets;
@@ -116,7 +117,7 @@ static void cache_nr_sets(struct cacheinfo *this_leaf)
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].nr_sets_prop;
- nr_sets = of_get_property(this_leaf->of_node, propname, NULL);
+ nr_sets = of_get_property(np, propname, NULL);
if (nr_sets)
this_leaf->number_of_sets = of_read_number(nr_sets, 1);
}
@@ -135,32 +136,27 @@ static void cache_associativity(struct cacheinfo *this_leaf)
this_leaf->ways_of_associativity = (size / nr_sets) / line_size;
}
-static bool cache_node_is_unified(struct cacheinfo *this_leaf)
+static bool cache_node_is_unified(struct cacheinfo *this_leaf,
+ struct device_node *np)
{
- return of_property_read_bool(this_leaf->of_node, "cache-unified");
+ return of_property_read_bool(np, "cache-unified");
}
-static void cache_of_override_properties(unsigned int cpu)
+static void cache_of_set_props(struct cacheinfo *this_leaf,
+ struct device_node *np)
{
- int index;
- struct cacheinfo *this_leaf;
- struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
-
- for (index = 0; index < cache_leaves(cpu); index++) {
- this_leaf = this_cpu_ci->info_list + index;
- /*
- * init_cache_level must setup the cache level correctly
- * overriding the architecturally specified levels, so
- * if type is NONE at this stage, it should be unified
- */
- if (this_leaf->type == CACHE_TYPE_NOCACHE &&
- cache_node_is_unified(this_leaf))
- this_leaf->type = CACHE_TYPE_UNIFIED;
- cache_size(this_leaf);
- cache_get_line_size(this_leaf);
- cache_nr_sets(this_leaf);
- cache_associativity(this_leaf);
- }
+ /*
+ * init_cache_level must setup the cache level correctly
+ * overriding the architecturally specified levels, so
+ * if type is NONE at this stage, it should be unified
+ */
+ if (this_leaf->type == CACHE_TYPE_NOCACHE &&
+ cache_node_is_unified(this_leaf, np))
+ this_leaf->type = CACHE_TYPE_UNIFIED;
+ cache_size(this_leaf, np);
+ cache_get_line_size(this_leaf, np);
+ cache_nr_sets(this_leaf, np);
+ cache_associativity(this_leaf);
}
static int cache_setup_of_node(unsigned int cpu)
@@ -193,6 +189,7 @@ static int cache_setup_of_node(unsigned int cpu)
np = of_node_get(np);/* cpu node itself */
if (!np)
break;
+ cache_of_set_props(this_leaf, np);
this_leaf->of_node = np;
index++;
}
@@ -203,7 +200,6 @@ static int cache_setup_of_node(unsigned int cpu)
return 0;
}
#else
-static void cache_of_override_properties(unsigned int cpu) { }
static inline int cache_setup_of_node(unsigned int cpu) { return 0; }
static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
struct cacheinfo *sib_leaf)
@@ -286,12 +282,6 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
}
}
-static void cache_override_properties(unsigned int cpu)
-{
- if (of_have_populated_dt())
- return cache_of_override_properties(cpu);
-}
-
static void free_cache_attributes(unsigned int cpu)
{
if (!per_cpu_cacheinfo(cpu))
@@ -325,6 +315,10 @@ static int detect_cache_attributes(unsigned int cpu)
if (per_cpu_cacheinfo(cpu) == NULL)
return -ENOMEM;
+ /*
+ * populate_cache_leaves() may completely setup the cache leaves and
+ * shared_cpu_map or it may leave it partially setup.
+ */
ret = populate_cache_leaves(cpu);
if (ret)
goto free_ci;
@@ -338,7 +332,6 @@ static int detect_cache_attributes(unsigned int cpu)
goto free_ci;
}
- cache_override_properties(cpu);
return 0;
free_ci:
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
2018-05-11 23:57 ` Jeremy Linton
(?)
@ 2018-05-15 17:15 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-15 17:15 UTC (permalink / raw)
To: linux-acpi
Cc: Sudeep.Holla, linux-arm-kernel, Lorenzo.Pieralisi, hanjun.guo,
rjw, Will.Deacon, Catalin.Marinas, gregkh, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel
Hi Greg,
Have you had a chance to look at the cachinfo parts of this patch?
Comments?
Thanks,
On 05/11/2018 06:57 PM, Jeremy Linton wrote:
> The original intent in cacheinfo was that an architecture
> specific populate_cache_leaves() would probe the hardware
> and then cache_shared_cpu_map_setup() and
> cache_override_properties() would provide firmware help to
> extend/expand upon what was probed. Arm64 was really
> the only architecture that was working this way, and
> with the removal of most of the hardware probing logic it
> became clear that it was possible to simplify the logic a bit.
>
> This patch combines the walk of the DT nodes with the
> code updating the cache size/line_size and nr_sets.
> cache_override_properties() (which was DT specific) is
> then removed. The result is that cacheinfo.of_node is
> no longer used as a temporary place to hold DT references
> for future calls that update cache properties. That change
> helps to clarify its one remaining use (matching
> cacheinfo nodes that represent shared caches) which
> will be used by the ACPI/PPTT code in the following patches.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/riscv/kernel/cacheinfo.c | 1 -
> drivers/base/cacheinfo.c | 65 +++++++++++++++++++------------------------
> 2 files changed, 29 insertions(+), 37 deletions(-)
>
> diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c
> index 10ed2749e246..0bc86e5f8f3f 100644
> --- a/arch/riscv/kernel/cacheinfo.c
> +++ b/arch/riscv/kernel/cacheinfo.c
> @@ -20,7 +20,6 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
> struct device_node *node,
> enum cache_type type, unsigned int level)
> {
> - this_leaf->of_node = node;
> this_leaf->level = level;
> this_leaf->type = type;
> /* not a sector cache */
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index 09ccef7ddc99..a872523e8951 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -71,7 +71,7 @@ static inline int get_cacheinfo_idx(enum cache_type type)
> return type;
> }
>
> -static void cache_size(struct cacheinfo *this_leaf)
> +static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> const __be32 *cache_size;
> @@ -80,13 +80,14 @@ static void cache_size(struct cacheinfo *this_leaf)
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].size_prop;
>
> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
> + cache_size = of_get_property(np, propname, NULL);
> if (cache_size)
> this_leaf->size = of_read_number(cache_size, 1);
> }
>
> /* not cache_line_size() because that's a macro in include/linux/cache.h */
> -static void cache_get_line_size(struct cacheinfo *this_leaf)
> +static void cache_get_line_size(struct cacheinfo *this_leaf,
> + struct device_node *np)
> {
> const __be32 *line_size;
> int i, lim, ct_idx;
> @@ -98,7 +99,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
> const char *propname;
>
> propname = cache_type_info[ct_idx].line_size_props[i];
> - line_size = of_get_property(this_leaf->of_node, propname, NULL);
> + line_size = of_get_property(np, propname, NULL);
> if (line_size)
> break;
> }
> @@ -107,7 +108,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
> this_leaf->coherency_line_size = of_read_number(line_size, 1);
> }
>
> -static void cache_nr_sets(struct cacheinfo *this_leaf)
> +static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> const __be32 *nr_sets;
> @@ -116,7 +117,7 @@ static void cache_nr_sets(struct cacheinfo *this_leaf)
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].nr_sets_prop;
>
> - nr_sets = of_get_property(this_leaf->of_node, propname, NULL);
> + nr_sets = of_get_property(np, propname, NULL);
> if (nr_sets)
> this_leaf->number_of_sets = of_read_number(nr_sets, 1);
> }
> @@ -135,32 +136,27 @@ static void cache_associativity(struct cacheinfo *this_leaf)
> this_leaf->ways_of_associativity = (size / nr_sets) / line_size;
> }
>
> -static bool cache_node_is_unified(struct cacheinfo *this_leaf)
> +static bool cache_node_is_unified(struct cacheinfo *this_leaf,
> + struct device_node *np)
> {
> - return of_property_read_bool(this_leaf->of_node, "cache-unified");
> + return of_property_read_bool(np, "cache-unified");
> }
>
> -static void cache_of_override_properties(unsigned int cpu)
> +static void cache_of_set_props(struct cacheinfo *this_leaf,
> + struct device_node *np)
> {
> - int index;
> - struct cacheinfo *this_leaf;
> - struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
> -
> - for (index = 0; index < cache_leaves(cpu); index++) {
> - this_leaf = this_cpu_ci->info_list + index;
> - /*
> - * init_cache_level must setup the cache level correctly
> - * overriding the architecturally specified levels, so
> - * if type is NONE at this stage, it should be unified
> - */
> - if (this_leaf->type == CACHE_TYPE_NOCACHE &&
> - cache_node_is_unified(this_leaf))
> - this_leaf->type = CACHE_TYPE_UNIFIED;
> - cache_size(this_leaf);
> - cache_get_line_size(this_leaf);
> - cache_nr_sets(this_leaf);
> - cache_associativity(this_leaf);
> - }
> + /*
> + * init_cache_level must setup the cache level correctly
> + * overriding the architecturally specified levels, so
> + * if type is NONE at this stage, it should be unified
> + */
> + if (this_leaf->type == CACHE_TYPE_NOCACHE &&
> + cache_node_is_unified(this_leaf, np))
> + this_leaf->type = CACHE_TYPE_UNIFIED;
> + cache_size(this_leaf, np);
> + cache_get_line_size(this_leaf, np);
> + cache_nr_sets(this_leaf, np);
> + cache_associativity(this_leaf);
> }
>
> static int cache_setup_of_node(unsigned int cpu)
> @@ -193,6 +189,7 @@ static int cache_setup_of_node(unsigned int cpu)
> np = of_node_get(np);/* cpu node itself */
> if (!np)
> break;
> + cache_of_set_props(this_leaf, np);
> this_leaf->of_node = np;
> index++;
> }
> @@ -203,7 +200,6 @@ static int cache_setup_of_node(unsigned int cpu)
> return 0;
> }
> #else
> -static void cache_of_override_properties(unsigned int cpu) { }
> static inline int cache_setup_of_node(unsigned int cpu) { return 0; }
> static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
> struct cacheinfo *sib_leaf)
> @@ -286,12 +282,6 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
> }
> }
>
> -static void cache_override_properties(unsigned int cpu)
> -{
> - if (of_have_populated_dt())
> - return cache_of_override_properties(cpu);
> -}
> -
> static void free_cache_attributes(unsigned int cpu)
> {
> if (!per_cpu_cacheinfo(cpu))
> @@ -325,6 +315,10 @@ static int detect_cache_attributes(unsigned int cpu)
> if (per_cpu_cacheinfo(cpu) == NULL)
> return -ENOMEM;
>
> + /*
> + * populate_cache_leaves() may completely setup the cache leaves and
> + * shared_cpu_map or it may leave it partially setup.
> + */
> ret = populate_cache_leaves(cpu);
> if (ret)
> goto free_ci;
> @@ -338,7 +332,6 @@ static int detect_cache_attributes(unsigned int cpu)
> goto free_ci;
> }
>
> - cache_override_properties(cpu);
> return 0;
>
> free_ci:
>
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-15 17:15 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-15 17:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Greg,
Have you had a chance to look at the cachinfo parts of this patch?
Comments?
Thanks,
On 05/11/2018 06:57 PM, Jeremy Linton wrote:
> The original intent in cacheinfo was that an architecture
> specific populate_cache_leaves() would probe the hardware
> and then cache_shared_cpu_map_setup() and
> cache_override_properties() would provide firmware help to
> extend/expand upon what was probed. Arm64 was really
> the only architecture that was working this way, and
> with the removal of most of the hardware probing logic it
> became clear that it was possible to simplify the logic a bit.
>
> This patch combines the walk of the DT nodes with the
> code updating the cache size/line_size and nr_sets.
> cache_override_properties() (which was DT specific) is
> then removed. The result is that cacheinfo.of_node is
> no longer used as a temporary place to hold DT references
> for future calls that update cache properties. That change
> helps to clarify its one remaining use (matching
> cacheinfo nodes that represent shared caches) which
> will be used by the ACPI/PPTT code in the following patches.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/riscv/kernel/cacheinfo.c | 1 -
> drivers/base/cacheinfo.c | 65 +++++++++++++++++++------------------------
> 2 files changed, 29 insertions(+), 37 deletions(-)
>
> diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c
> index 10ed2749e246..0bc86e5f8f3f 100644
> --- a/arch/riscv/kernel/cacheinfo.c
> +++ b/arch/riscv/kernel/cacheinfo.c
> @@ -20,7 +20,6 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
> struct device_node *node,
> enum cache_type type, unsigned int level)
> {
> - this_leaf->of_node = node;
> this_leaf->level = level;
> this_leaf->type = type;
> /* not a sector cache */
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index 09ccef7ddc99..a872523e8951 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -71,7 +71,7 @@ static inline int get_cacheinfo_idx(enum cache_type type)
> return type;
> }
>
> -static void cache_size(struct cacheinfo *this_leaf)
> +static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> const __be32 *cache_size;
> @@ -80,13 +80,14 @@ static void cache_size(struct cacheinfo *this_leaf)
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].size_prop;
>
> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
> + cache_size = of_get_property(np, propname, NULL);
> if (cache_size)
> this_leaf->size = of_read_number(cache_size, 1);
> }
>
> /* not cache_line_size() because that's a macro in include/linux/cache.h */
> -static void cache_get_line_size(struct cacheinfo *this_leaf)
> +static void cache_get_line_size(struct cacheinfo *this_leaf,
> + struct device_node *np)
> {
> const __be32 *line_size;
> int i, lim, ct_idx;
> @@ -98,7 +99,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
> const char *propname;
>
> propname = cache_type_info[ct_idx].line_size_props[i];
> - line_size = of_get_property(this_leaf->of_node, propname, NULL);
> + line_size = of_get_property(np, propname, NULL);
> if (line_size)
> break;
> }
> @@ -107,7 +108,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
> this_leaf->coherency_line_size = of_read_number(line_size, 1);
> }
>
> -static void cache_nr_sets(struct cacheinfo *this_leaf)
> +static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> const __be32 *nr_sets;
> @@ -116,7 +117,7 @@ static void cache_nr_sets(struct cacheinfo *this_leaf)
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].nr_sets_prop;
>
> - nr_sets = of_get_property(this_leaf->of_node, propname, NULL);
> + nr_sets = of_get_property(np, propname, NULL);
> if (nr_sets)
> this_leaf->number_of_sets = of_read_number(nr_sets, 1);
> }
> @@ -135,32 +136,27 @@ static void cache_associativity(struct cacheinfo *this_leaf)
> this_leaf->ways_of_associativity = (size / nr_sets) / line_size;
> }
>
> -static bool cache_node_is_unified(struct cacheinfo *this_leaf)
> +static bool cache_node_is_unified(struct cacheinfo *this_leaf,
> + struct device_node *np)
> {
> - return of_property_read_bool(this_leaf->of_node, "cache-unified");
> + return of_property_read_bool(np, "cache-unified");
> }
>
> -static void cache_of_override_properties(unsigned int cpu)
> +static void cache_of_set_props(struct cacheinfo *this_leaf,
> + struct device_node *np)
> {
> - int index;
> - struct cacheinfo *this_leaf;
> - struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
> -
> - for (index = 0; index < cache_leaves(cpu); index++) {
> - this_leaf = this_cpu_ci->info_list + index;
> - /*
> - * init_cache_level must setup the cache level correctly
> - * overriding the architecturally specified levels, so
> - * if type is NONE at this stage, it should be unified
> - */
> - if (this_leaf->type == CACHE_TYPE_NOCACHE &&
> - cache_node_is_unified(this_leaf))
> - this_leaf->type = CACHE_TYPE_UNIFIED;
> - cache_size(this_leaf);
> - cache_get_line_size(this_leaf);
> - cache_nr_sets(this_leaf);
> - cache_associativity(this_leaf);
> - }
> + /*
> + * init_cache_level must setup the cache level correctly
> + * overriding the architecturally specified levels, so
> + * if type is NONE at this stage, it should be unified
> + */
> + if (this_leaf->type == CACHE_TYPE_NOCACHE &&
> + cache_node_is_unified(this_leaf, np))
> + this_leaf->type = CACHE_TYPE_UNIFIED;
> + cache_size(this_leaf, np);
> + cache_get_line_size(this_leaf, np);
> + cache_nr_sets(this_leaf, np);
> + cache_associativity(this_leaf);
> }
>
> static int cache_setup_of_node(unsigned int cpu)
> @@ -193,6 +189,7 @@ static int cache_setup_of_node(unsigned int cpu)
> np = of_node_get(np);/* cpu node itself */
> if (!np)
> break;
> + cache_of_set_props(this_leaf, np);
> this_leaf->of_node = np;
> index++;
> }
> @@ -203,7 +200,6 @@ static int cache_setup_of_node(unsigned int cpu)
> return 0;
> }
> #else
> -static void cache_of_override_properties(unsigned int cpu) { }
> static inline int cache_setup_of_node(unsigned int cpu) { return 0; }
> static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
> struct cacheinfo *sib_leaf)
> @@ -286,12 +282,6 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
> }
> }
>
> -static void cache_override_properties(unsigned int cpu)
> -{
> - if (of_have_populated_dt())
> - return cache_of_override_properties(cpu);
> -}
> -
> static void free_cache_attributes(unsigned int cpu)
> {
> if (!per_cpu_cacheinfo(cpu))
> @@ -325,6 +315,10 @@ static int detect_cache_attributes(unsigned int cpu)
> if (per_cpu_cacheinfo(cpu) == NULL)
> return -ENOMEM;
>
> + /*
> + * populate_cache_leaves() may completely setup the cache leaves and
> + * shared_cpu_map or it may leave it partially setup.
> + */
> ret = populate_cache_leaves(cpu);
> if (ret)
> goto free_ci;
> @@ -338,7 +332,6 @@ static int detect_cache_attributes(unsigned int cpu)
> goto free_ci;
> }
>
> - cache_override_properties(cpu);
> return 0;
>
> free_ci:
>
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-15 17:15 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-15 17:15 UTC (permalink / raw)
To: linux-riscv
Hi Greg,
Have you had a chance to look at the cachinfo parts of this patch?
Comments?
Thanks,
On 05/11/2018 06:57 PM, Jeremy Linton wrote:
> The original intent in cacheinfo was that an architecture
> specific populate_cache_leaves() would probe the hardware
> and then cache_shared_cpu_map_setup() and
> cache_override_properties() would provide firmware help to
> extend/expand upon what was probed. Arm64 was really
> the only architecture that was working this way, and
> with the removal of most of the hardware probing logic it
> became clear that it was possible to simplify the logic a bit.
>
> This patch combines the walk of the DT nodes with the
> code updating the cache size/line_size and nr_sets.
> cache_override_properties() (which was DT specific) is
> then removed. The result is that cacheinfo.of_node is
> no longer used as a temporary place to hold DT references
> for future calls that update cache properties. That change
> helps to clarify its one remaining use (matching
> cacheinfo nodes that represent shared caches) which
> will be used by the ACPI/PPTT code in the following patches.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/riscv/kernel/cacheinfo.c | 1 -
> drivers/base/cacheinfo.c | 65 +++++++++++++++++++------------------------
> 2 files changed, 29 insertions(+), 37 deletions(-)
>
> diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c
> index 10ed2749e246..0bc86e5f8f3f 100644
> --- a/arch/riscv/kernel/cacheinfo.c
> +++ b/arch/riscv/kernel/cacheinfo.c
> @@ -20,7 +20,6 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
> struct device_node *node,
> enum cache_type type, unsigned int level)
> {
> - this_leaf->of_node = node;
> this_leaf->level = level;
> this_leaf->type = type;
> /* not a sector cache */
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index 09ccef7ddc99..a872523e8951 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -71,7 +71,7 @@ static inline int get_cacheinfo_idx(enum cache_type type)
> return type;
> }
>
> -static void cache_size(struct cacheinfo *this_leaf)
> +static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> const __be32 *cache_size;
> @@ -80,13 +80,14 @@ static void cache_size(struct cacheinfo *this_leaf)
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].size_prop;
>
> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
> + cache_size = of_get_property(np, propname, NULL);
> if (cache_size)
> this_leaf->size = of_read_number(cache_size, 1);
> }
>
> /* not cache_line_size() because that's a macro in include/linux/cache.h */
> -static void cache_get_line_size(struct cacheinfo *this_leaf)
> +static void cache_get_line_size(struct cacheinfo *this_leaf,
> + struct device_node *np)
> {
> const __be32 *line_size;
> int i, lim, ct_idx;
> @@ -98,7 +99,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
> const char *propname;
>
> propname = cache_type_info[ct_idx].line_size_props[i];
> - line_size = of_get_property(this_leaf->of_node, propname, NULL);
> + line_size = of_get_property(np, propname, NULL);
> if (line_size)
> break;
> }
> @@ -107,7 +108,7 @@ static void cache_get_line_size(struct cacheinfo *this_leaf)
> this_leaf->coherency_line_size = of_read_number(line_size, 1);
> }
>
> -static void cache_nr_sets(struct cacheinfo *this_leaf)
> +static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> const __be32 *nr_sets;
> @@ -116,7 +117,7 @@ static void cache_nr_sets(struct cacheinfo *this_leaf)
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].nr_sets_prop;
>
> - nr_sets = of_get_property(this_leaf->of_node, propname, NULL);
> + nr_sets = of_get_property(np, propname, NULL);
> if (nr_sets)
> this_leaf->number_of_sets = of_read_number(nr_sets, 1);
> }
> @@ -135,32 +136,27 @@ static void cache_associativity(struct cacheinfo *this_leaf)
> this_leaf->ways_of_associativity = (size / nr_sets) / line_size;
> }
>
> -static bool cache_node_is_unified(struct cacheinfo *this_leaf)
> +static bool cache_node_is_unified(struct cacheinfo *this_leaf,
> + struct device_node *np)
> {
> - return of_property_read_bool(this_leaf->of_node, "cache-unified");
> + return of_property_read_bool(np, "cache-unified");
> }
>
> -static void cache_of_override_properties(unsigned int cpu)
> +static void cache_of_set_props(struct cacheinfo *this_leaf,
> + struct device_node *np)
> {
> - int index;
> - struct cacheinfo *this_leaf;
> - struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
> -
> - for (index = 0; index < cache_leaves(cpu); index++) {
> - this_leaf = this_cpu_ci->info_list + index;
> - /*
> - * init_cache_level must setup the cache level correctly
> - * overriding the architecturally specified levels, so
> - * if type is NONE at this stage, it should be unified
> - */
> - if (this_leaf->type == CACHE_TYPE_NOCACHE &&
> - cache_node_is_unified(this_leaf))
> - this_leaf->type = CACHE_TYPE_UNIFIED;
> - cache_size(this_leaf);
> - cache_get_line_size(this_leaf);
> - cache_nr_sets(this_leaf);
> - cache_associativity(this_leaf);
> - }
> + /*
> + * init_cache_level must setup the cache level correctly
> + * overriding the architecturally specified levels, so
> + * if type is NONE at this stage, it should be unified
> + */
> + if (this_leaf->type == CACHE_TYPE_NOCACHE &&
> + cache_node_is_unified(this_leaf, np))
> + this_leaf->type = CACHE_TYPE_UNIFIED;
> + cache_size(this_leaf, np);
> + cache_get_line_size(this_leaf, np);
> + cache_nr_sets(this_leaf, np);
> + cache_associativity(this_leaf);
> }
>
> static int cache_setup_of_node(unsigned int cpu)
> @@ -193,6 +189,7 @@ static int cache_setup_of_node(unsigned int cpu)
> np = of_node_get(np);/* cpu node itself */
> if (!np)
> break;
> + cache_of_set_props(this_leaf, np);
> this_leaf->of_node = np;
> index++;
> }
> @@ -203,7 +200,6 @@ static int cache_setup_of_node(unsigned int cpu)
> return 0;
> }
> #else
> -static void cache_of_override_properties(unsigned int cpu) { }
> static inline int cache_setup_of_node(unsigned int cpu) { return 0; }
> static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
> struct cacheinfo *sib_leaf)
> @@ -286,12 +282,6 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
> }
> }
>
> -static void cache_override_properties(unsigned int cpu)
> -{
> - if (of_have_populated_dt())
> - return cache_of_override_properties(cpu);
> -}
> -
> static void free_cache_attributes(unsigned int cpu)
> {
> if (!per_cpu_cacheinfo(cpu))
> @@ -325,6 +315,10 @@ static int detect_cache_attributes(unsigned int cpu)
> if (per_cpu_cacheinfo(cpu) == NULL)
> return -ENOMEM;
>
> + /*
> + * populate_cache_leaves() may completely setup the cache leaves and
> + * shared_cpu_map or it may leave it partially setup.
> + */
> ret = populate_cache_leaves(cpu);
> if (ret)
> goto free_ci;
> @@ -338,7 +332,6 @@ static int detect_cache_attributes(unsigned int cpu)
> goto free_ci;
> }
>
> - cache_override_properties(cpu);
> return 0;
>
> free_ci:
>
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
2018-05-15 17:15 ` Jeremy Linton
(?)
(?)
@ 2018-05-15 19:32 ` Andy Shevchenko
-1 siblings, 0 replies; 185+ messages in thread
From: Andy Shevchenko @ 2018-05-15 19:32 UTC (permalink / raw)
To: Jeremy Linton
Cc: ACPI Devel Maling List, Sudeep Holla, linux-arm Mailing List,
Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, Xiongfeng Wang, vkilari,
Al Stone, Dietmar.Eggemann, Morten.Rasmussen, Palmer Dabbelt,
Len Brown, John Garry
On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>> + cache_size = of_get_property(np, propname, NULL);
>> if (cache_size)
>> this_leaf->size = of_read_number(cache_size, 1);
Can't you switch to of_read_property_uXX() variant here?
>> - line_size = of_get_property(this_leaf->of_node, propname,
>> NULL);
>> + line_size = of_get_property(np, propname, NULL);
Ditto.
>> - nr_sets = of_get_property(this_leaf->of_node, propname, NULL);
>> + nr_sets = of_get_property(np, propname, NULL);
>> if (nr_sets)
>> this_leaf->number_of_sets = of_read_number(nr_sets, 1);
Ditto.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-15 19:32 ` Andy Shevchenko
0 siblings, 0 replies; 185+ messages in thread
From: Andy Shevchenko @ 2018-05-15 19:32 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>> + cache_size = of_get_property(np, propname, NULL);
>> if (cache_size)
>> this_leaf->size = of_read_number(cache_size, 1);
Can't you switch to of_read_property_uXX() variant here?
>> - line_size = of_get_property(this_leaf->of_node, propname,
>> NULL);
>> + line_size = of_get_property(np, propname, NULL);
Ditto.
>> - nr_sets = of_get_property(this_leaf->of_node, propname, NULL);
>> + nr_sets = of_get_property(np, propname, NULL);
>> if (nr_sets)
>> this_leaf->number_of_sets = of_read_number(nr_sets, 1);
Ditto.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-15 19:32 ` Andy Shevchenko
0 siblings, 0 replies; 185+ messages in thread
From: Andy Shevchenko @ 2018-05-15 19:32 UTC (permalink / raw)
To: linux-riscv
On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>> + cache_size = of_get_property(np, propname, NULL);
>> if (cache_size)
>> this_leaf->size = of_read_number(cache_size, 1);
Can't you switch to of_read_property_uXX() variant here?
>> - line_size = of_get_property(this_leaf->of_node, propname,
>> NULL);
>> + line_size = of_get_property(np, propname, NULL);
Ditto.
>> - nr_sets = of_get_property(this_leaf->of_node, propname, NULL);
>> + nr_sets = of_get_property(np, propname, NULL);
>> if (nr_sets)
>> this_leaf->number_of_sets = of_read_number(nr_sets, 1);
Ditto.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-15 19:32 ` Andy Shevchenko
0 siblings, 0 replies; 185+ messages in thread
From: Andy Shevchenko @ 2018-05-15 19:32 UTC (permalink / raw)
To: Jeremy Linton
Cc: ACPI Devel Maling List, Sudeep Holla, linux-arm Mailing List,
Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, Xiongfeng Wang, vkilari,
Al Stone, Dietmar.Eggemann, Morten.Rasmussen, Palmer Dabbelt,
Len Brown, John Garry, austinwc, tnowicki, jhugo, Ard Biesheuvel
On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>> + cache_size = of_get_property(np, propname, NULL);
>> if (cache_size)
>> this_leaf->size = of_read_number(cache_size, 1);
Can't you switch to of_read_property_uXX() variant here?
>> - line_size = of_get_property(this_leaf->of_node, propname,
>> NULL);
>> + line_size = of_get_property(np, propname, NULL);
Ditto.
>> - nr_sets = of_get_property(this_leaf->of_node, propname, NULL);
>> + nr_sets = of_get_property(np, propname, NULL);
>> if (nr_sets)
>> this_leaf->number_of_sets = of_read_number(nr_sets, 1);
Ditto.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
2018-05-15 19:32 ` Andy Shevchenko
(?)
(?)
@ 2018-05-16 10:56 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-16 10:56 UTC (permalink / raw)
To: Andy Shevchenko, Jeremy Linton
Cc: Sudeep Holla, ACPI Devel Maling List, linux-arm Mailing List,
Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, Xiongfeng Wang, vkilari,
Al Stone, Dietmar.Eggemann, Morten.Rasmussen, Palmer Dabbelt,
Len Brown, John Garry
Hi Andy,
On 15/05/18 20:32, Andy Shevchenko wrote:
> On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>
>>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>>> + cache_size = of_get_property(np, propname, NULL);
>>> if (cache_size)
>>> this_leaf->size = of_read_number(cache_size, 1);
>
> Can't you switch to of_read_property_uXX() variant here?
>
This patch is just changing the first argument to the calls. So if we
need to change, it has to be separate patch.
Now, we can use of_property_read_u64() but is there any particular
reason you mention that ? One reason I can see is that we can avoid
making explicit of_get_property call. Just wanted to the motive before I
can write the patch.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-16 10:56 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-16 10:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi Andy,
On 15/05/18 20:32, Andy Shevchenko wrote:
> On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>
>>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>>> + cache_size = of_get_property(np, propname, NULL);
>>> if (cache_size)
>>> this_leaf->size = of_read_number(cache_size, 1);
>
> Can't you switch to of_read_property_uXX() variant here?
>
This patch is just changing the first argument to the calls. So if we
need to change, it has to be separate patch.
Now, we can use of_property_read_u64() but is there any particular
reason you mention that ? One reason I can see is that we can avoid
making explicit of_get_property call. Just wanted to the motive before I
can write the patch.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-16 10:56 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-16 10:56 UTC (permalink / raw)
To: linux-riscv
Hi Andy,
On 15/05/18 20:32, Andy Shevchenko wrote:
> On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>
>>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>>> + cache_size = of_get_property(np, propname, NULL);
>>> if (cache_size)
>>> this_leaf->size = of_read_number(cache_size, 1);
>
> Can't you switch to of_read_property_uXX() variant here?
>
This patch is just changing the first argument to the calls. So if we
need to change, it has to be separate patch.
Now, we can use of_property_read_u64() but is there any particular
reason you mention that ? One reason I can see is that we can avoid
making explicit of_get_property call. Just wanted to the motive before I
can write the patch.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-16 10:56 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-16 10:56 UTC (permalink / raw)
To: Andy Shevchenko, Jeremy Linton
Cc: Sudeep Holla, ACPI Devel Maling List, linux-arm Mailing List,
Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, Xiongfeng Wang, vkilari,
Al Stone, Dietmar.Eggemann, Morten.Rasmussen, Palmer Dabbelt,
Len Brown, John Garry, austinwc, tnowicki, jhugo, Ard Biesheuvel
Hi Andy,
On 15/05/18 20:32, Andy Shevchenko wrote:
> On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>
>>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>>> + cache_size = of_get_property(np, propname, NULL);
>>> if (cache_size)
>>> this_leaf->size = of_read_number(cache_size, 1);
>
> Can't you switch to of_read_property_uXX() variant here?
>
This patch is just changing the first argument to the calls. So if we
need to change, it has to be separate patch.
Now, we can use of_property_read_u64() but is there any particular
reason you mention that ? One reason I can see is that we can avoid
making explicit of_get_property call. Just wanted to the motive before I
can write the patch.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
2018-05-16 10:56 ` Sudeep Holla
(?)
(?)
@ 2018-05-17 15:47 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-17 15:47 UTC (permalink / raw)
To: Andy Shevchenko, Jeremy Linton
Cc: Sudeep Holla, ACPI Devel Maling List, linux-arm Mailing List,
Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, Xiongfeng Wang, vkilari,
Al Stone, Dietmar.Eggemann, Morten.Rasmussen, Palmer Dabbelt,
Len Brown, John Garry
On 16/05/18 11:56, Sudeep Holla wrote:
> Hi Andy,
>
> On 15/05/18 20:32, Andy Shevchenko wrote:
>> On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>>> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>>
>>>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>>>> + cache_size = of_get_property(np, propname, NULL);
>>>> if (cache_size)
>>>> this_leaf->size = of_read_number(cache_size, 1);
>>
>> Can't you switch to of_read_property_uXX() variant here?
>>
>
> This patch is just changing the first argument to the calls. So if we
> need to change, it has to be separate patch.
>
> Now, we can use of_property_read_u64() but is there any particular
> reason you mention that ? One reason I can see is that we can avoid
> making explicit of_get_property call. Just wanted to the motive before I
> can write the patch.
>
Is below patch does what you were looking for ?
Regards,
Sudeep
--
>From 71f1c10ddb5915a92fa74d38a4e2406d0ab27845 Mon Sep 17 00:00:00 2001
From: Sudeep Holla <sudeep.holla@arm.com>
Date: Wed, 16 May 2018 13:45:53 +0100
Subject: [PATCH] drivers: base: cacheinfo: use OF property_read_u64 instead of
get_property,read_number
of_property_read_u64 searches for a property in a device node and read
a 64-bit value from it. Instead of using of_get_property to get the
property and then read 64-bit value using of_read_number, we can make
use of of_property_read_u64.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/base/cacheinfo.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 2880e2ab01f5..56715014f07b 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -74,22 +74,21 @@ static inline int get_cacheinfo_idx(enum cache_type type)
static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *cache_size;
+ u64 cache_size;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].size_prop;
- cache_size = of_get_property(np, propname, NULL);
- if (cache_size)
- this_leaf->size = of_read_number(cache_size, 1);
+ if (!of_property_read_u64(np, propname, &cache_size))
+ this_leaf->size = cache_size;
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
static void cache_get_line_size(struct cacheinfo *this_leaf,
struct device_node *np)
{
- const __be32 *line_size;
+ u64 line_size;
int i, lim, ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
@@ -99,27 +98,26 @@ static void cache_get_line_size(struct cacheinfo *this_leaf,
const char *propname;
propname = cache_type_info[ct_idx].line_size_props[i];
- line_size = of_get_property(np, propname, NULL);
- if (line_size)
+ line_size = of_property_read_u64(np, propname, &line_size);
+ if (line_size) {
+ this_leaf->coherency_line_size = line_size;
break;
+ }
}
- if (line_size)
- this_leaf->coherency_line_size = of_read_number(line_size, 1);
}
static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *nr_sets;
+ u64 nr_sets;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].nr_sets_prop;
- nr_sets = of_get_property(np, propname, NULL);
- if (nr_sets)
- this_leaf->number_of_sets = of_read_number(nr_sets, 1);
+ if (!of_property_read_u64(np, propname, &nr_sets))
+ this_leaf->number_of_sets = nr_sets;
}
static void cache_associativity(struct cacheinfo *this_leaf)
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-17 15:47 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-17 15:47 UTC (permalink / raw)
To: linux-arm-kernel
On 16/05/18 11:56, Sudeep Holla wrote:
> Hi Andy,
>
> On 15/05/18 20:32, Andy Shevchenko wrote:
>> On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>>> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>>
>>>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>>>> + cache_size = of_get_property(np, propname, NULL);
>>>> if (cache_size)
>>>> this_leaf->size = of_read_number(cache_size, 1);
>>
>> Can't you switch to of_read_property_uXX() variant here?
>>
>
> This patch is just changing the first argument to the calls. So if we
> need to change, it has to be separate patch.
>
> Now, we can use of_property_read_u64() but is there any particular
> reason you mention that ? One reason I can see is that we can avoid
> making explicit of_get_property call. Just wanted to the motive before I
> can write the patch.
>
Is below patch does what you were looking for ?
Regards,
Sudeep
--
>From 71f1c10ddb5915a92fa74d38a4e2406d0ab27845 Mon Sep 17 00:00:00 2001
From: Sudeep Holla <sudeep.holla@arm.com>
Date: Wed, 16 May 2018 13:45:53 +0100
Subject: [PATCH] drivers: base: cacheinfo: use OF property_read_u64 instead of
get_property,read_number
of_property_read_u64 searches for a property in a device node and read
a 64-bit value from it. Instead of using of_get_property to get the
property and then read 64-bit value using of_read_number, we can make
use of of_property_read_u64.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/base/cacheinfo.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 2880e2ab01f5..56715014f07b 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -74,22 +74,21 @@ static inline int get_cacheinfo_idx(enum cache_type type)
static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *cache_size;
+ u64 cache_size;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].size_prop;
- cache_size = of_get_property(np, propname, NULL);
- if (cache_size)
- this_leaf->size = of_read_number(cache_size, 1);
+ if (!of_property_read_u64(np, propname, &cache_size))
+ this_leaf->size = cache_size;
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
static void cache_get_line_size(struct cacheinfo *this_leaf,
struct device_node *np)
{
- const __be32 *line_size;
+ u64 line_size;
int i, lim, ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
@@ -99,27 +98,26 @@ static void cache_get_line_size(struct cacheinfo *this_leaf,
const char *propname;
propname = cache_type_info[ct_idx].line_size_props[i];
- line_size = of_get_property(np, propname, NULL);
- if (line_size)
+ line_size = of_property_read_u64(np, propname, &line_size);
+ if (line_size) {
+ this_leaf->coherency_line_size = line_size;
break;
+ }
}
- if (line_size)
- this_leaf->coherency_line_size = of_read_number(line_size, 1);
}
static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *nr_sets;
+ u64 nr_sets;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].nr_sets_prop;
- nr_sets = of_get_property(np, propname, NULL);
- if (nr_sets)
- this_leaf->number_of_sets = of_read_number(nr_sets, 1);
+ if (!of_property_read_u64(np, propname, &nr_sets))
+ this_leaf->number_of_sets = nr_sets;
}
static void cache_associativity(struct cacheinfo *this_leaf)
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-17 15:47 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-17 15:47 UTC (permalink / raw)
To: linux-riscv
On 16/05/18 11:56, Sudeep Holla wrote:
> Hi Andy,
>
> On 15/05/18 20:32, Andy Shevchenko wrote:
>> On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>>> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>>
>>>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>>>> + cache_size = of_get_property(np, propname, NULL);
>>>> if (cache_size)
>>>> this_leaf->size = of_read_number(cache_size, 1);
>>
>> Can't you switch to of_read_property_uXX() variant here?
>>
>
> This patch is just changing the first argument to the calls. So if we
> need to change, it has to be separate patch.
>
> Now, we can use of_property_read_u64() but is there any particular
> reason you mention that ? One reason I can see is that we can avoid
> making explicit of_get_property call. Just wanted to the motive before I
> can write the patch.
>
Is below patch does what you were looking for ?
Regards,
Sudeep
--
>From 71f1c10ddb5915a92fa74d38a4e2406d0ab27845 Mon Sep 17 00:00:00 2001
From: Sudeep Holla <sudeep.holla@arm.com>
Date: Wed, 16 May 2018 13:45:53 +0100
Subject: [PATCH] drivers: base: cacheinfo: use OF property_read_u64 instead of
get_property,read_number
of_property_read_u64 searches for a property in a device node and read
a 64-bit value from it. Instead of using of_get_property to get the
property and then read 64-bit value using of_read_number, we can make
use of of_property_read_u64.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/base/cacheinfo.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 2880e2ab01f5..56715014f07b 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -74,22 +74,21 @@ static inline int get_cacheinfo_idx(enum cache_type type)
static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *cache_size;
+ u64 cache_size;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].size_prop;
- cache_size = of_get_property(np, propname, NULL);
- if (cache_size)
- this_leaf->size = of_read_number(cache_size, 1);
+ if (!of_property_read_u64(np, propname, &cache_size))
+ this_leaf->size = cache_size;
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
static void cache_get_line_size(struct cacheinfo *this_leaf,
struct device_node *np)
{
- const __be32 *line_size;
+ u64 line_size;
int i, lim, ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
@@ -99,27 +98,26 @@ static void cache_get_line_size(struct cacheinfo *this_leaf,
const char *propname;
propname = cache_type_info[ct_idx].line_size_props[i];
- line_size = of_get_property(np, propname, NULL);
- if (line_size)
+ line_size = of_property_read_u64(np, propname, &line_size);
+ if (line_size) {
+ this_leaf->coherency_line_size = line_size;
break;
+ }
}
- if (line_size)
- this_leaf->coherency_line_size = of_read_number(line_size, 1);
}
static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *nr_sets;
+ u64 nr_sets;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].nr_sets_prop;
- nr_sets = of_get_property(np, propname, NULL);
- if (nr_sets)
- this_leaf->number_of_sets = of_read_number(nr_sets, 1);
+ if (!of_property_read_u64(np, propname, &nr_sets))
+ this_leaf->number_of_sets = nr_sets;
}
static void cache_associativity(struct cacheinfo *this_leaf)
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-17 15:47 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-17 15:47 UTC (permalink / raw)
To: Andy Shevchenko, Jeremy Linton
Cc: Sudeep Holla, ACPI Devel Maling List, linux-arm Mailing List,
Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, Xiongfeng Wang, vkilari,
Al Stone, Dietmar.Eggemann, Morten.Rasmussen, Palmer Dabbelt,
Len Brown, John Garry, austinwc, tnowicki, jhugo, Ard Biesheuvel
On 16/05/18 11:56, Sudeep Holla wrote:
> Hi Andy,
>
> On 15/05/18 20:32, Andy Shevchenko wrote:
>> On Tue, May 15, 2018 at 8:15 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>>> On 05/11/2018 06:57 PM, Jeremy Linton wrote:
>>
>>>> - cache_size = of_get_property(this_leaf->of_node, propname, NULL);
>>>> + cache_size = of_get_property(np, propname, NULL);
>>>> if (cache_size)
>>>> this_leaf->size = of_read_number(cache_size, 1);
>>
>> Can't you switch to of_read_property_uXX() variant here?
>>
>
> This patch is just changing the first argument to the calls. So if we
> need to change, it has to be separate patch.
>
> Now, we can use of_property_read_u64() but is there any particular
> reason you mention that ? One reason I can see is that we can avoid
> making explicit of_get_property call. Just wanted to the motive before I
> can write the patch.
>
Is below patch does what you were looking for ?
Regards,
Sudeep
--
>From 71f1c10ddb5915a92fa74d38a4e2406d0ab27845 Mon Sep 17 00:00:00 2001
From: Sudeep Holla <sudeep.holla@arm.com>
Date: Wed, 16 May 2018 13:45:53 +0100
Subject: [PATCH] drivers: base: cacheinfo: use OF property_read_u64 instead of
get_property,read_number
of_property_read_u64 searches for a property in a device node and read
a 64-bit value from it. Instead of using of_get_property to get the
property and then read 64-bit value using of_read_number, we can make
use of of_property_read_u64.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/base/cacheinfo.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 2880e2ab01f5..56715014f07b 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -74,22 +74,21 @@ static inline int get_cacheinfo_idx(enum cache_type type)
static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *cache_size;
+ u64 cache_size;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].size_prop;
- cache_size = of_get_property(np, propname, NULL);
- if (cache_size)
- this_leaf->size = of_read_number(cache_size, 1);
+ if (!of_property_read_u64(np, propname, &cache_size))
+ this_leaf->size = cache_size;
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
static void cache_get_line_size(struct cacheinfo *this_leaf,
struct device_node *np)
{
- const __be32 *line_size;
+ u64 line_size;
int i, lim, ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
@@ -99,27 +98,26 @@ static void cache_get_line_size(struct cacheinfo *this_leaf,
const char *propname;
propname = cache_type_info[ct_idx].line_size_props[i];
- line_size = of_get_property(np, propname, NULL);
- if (line_size)
+ line_size = of_property_read_u64(np, propname, &line_size);
+ if (line_size) {
+ this_leaf->coherency_line_size = line_size;
break;
+ }
}
- if (line_size)
- this_leaf->coherency_line_size = of_read_number(line_size, 1);
}
static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *nr_sets;
+ u64 nr_sets;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].nr_sets_prop;
- nr_sets = of_get_property(np, propname, NULL);
- if (nr_sets)
- this_leaf->number_of_sets = of_read_number(nr_sets, 1);
+ if (!of_property_read_u64(np, propname, &nr_sets))
+ this_leaf->number_of_sets = nr_sets;
}
static void cache_associativity(struct cacheinfo *this_leaf)
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
2018-05-17 15:47 ` Sudeep Holla
(?)
(?)
@ 2018-05-18 21:50 ` Andy Shevchenko
-1 siblings, 0 replies; 185+ messages in thread
From: Andy Shevchenko @ 2018-05-18 21:50 UTC (permalink / raw)
To: Sudeep Holla
Cc: Jeremy Linton, ACPI Devel Maling List, linux-arm Mailing List,
Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, Xiongfeng Wang, vkilari,
Al Stone, Dietmar.Eggemann, Morten.Rasmussen, Palmer Dabbelt,
Len Brown
On Thu, May 17, 2018 at 6:47 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Is below patch does what you were looking for ?
Somewhat.
See below for some minors.
> of_property_read_u64 searches for a property in a device node and read
> a 64-bit value from it. Instead of using of_get_property to get the
> property and then read 64-bit value using of_read_number, we can make
> use of of_property_read_u64.
Suggested-by?
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> - cache_size = of_get_property(np, propname, NULL);
> - if (cache_size)
> - this_leaf->size = of_read_number(cache_size, 1);
> + if (!of_property_read_u64(np, propname, &cache_size))
> + this_leaf->size = cache_size;
I suppose it's something like this
ret = of_property_...(..., &this_leaf->VAR);
if (ret)
warning / set default / etc
> propname = cache_type_info[ct_idx].line_size_props[i];
> - line_size = of_get_property(np, propname, NULL);
> - if (line_size)
> + line_size = of_property_read_u64(np, propname, &line_size);
> + if (line_size) {
ret = ...
if (ret) {
> + this_leaf->coherency_line_size = line_size;
> break;
> + }
> + if (!of_property_read_u64(np, propname, &nr_sets))
> + this_leaf->number_of_sets = nr_sets;
As in first case.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-18 21:50 ` Andy Shevchenko
0 siblings, 0 replies; 185+ messages in thread
From: Andy Shevchenko @ 2018-05-18 21:50 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, May 17, 2018 at 6:47 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Is below patch does what you were looking for ?
Somewhat.
See below for some minors.
> of_property_read_u64 searches for a property in a device node and read
> a 64-bit value from it. Instead of using of_get_property to get the
> property and then read 64-bit value using of_read_number, we can make
> use of of_property_read_u64.
Suggested-by?
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> - cache_size = of_get_property(np, propname, NULL);
> - if (cache_size)
> - this_leaf->size = of_read_number(cache_size, 1);
> + if (!of_property_read_u64(np, propname, &cache_size))
> + this_leaf->size = cache_size;
I suppose it's something like this
ret = of_property_...(..., &this_leaf->VAR);
if (ret)
warning / set default / etc
> propname = cache_type_info[ct_idx].line_size_props[i];
> - line_size = of_get_property(np, propname, NULL);
> - if (line_size)
> + line_size = of_property_read_u64(np, propname, &line_size);
> + if (line_size) {
ret = ...
if (ret) {
> + this_leaf->coherency_line_size = line_size;
> break;
> + }
> + if (!of_property_read_u64(np, propname, &nr_sets))
> + this_leaf->number_of_sets = nr_sets;
As in first case.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-18 21:50 ` Andy Shevchenko
0 siblings, 0 replies; 185+ messages in thread
From: Andy Shevchenko @ 2018-05-18 21:50 UTC (permalink / raw)
To: linux-riscv
On Thu, May 17, 2018 at 6:47 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Is below patch does what you were looking for ?
Somewhat.
See below for some minors.
> of_property_read_u64 searches for a property in a device node and read
> a 64-bit value from it. Instead of using of_get_property to get the
> property and then read 64-bit value using of_read_number, we can make
> use of of_property_read_u64.
Suggested-by?
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> - cache_size = of_get_property(np, propname, NULL);
> - if (cache_size)
> - this_leaf->size = of_read_number(cache_size, 1);
> + if (!of_property_read_u64(np, propname, &cache_size))
> + this_leaf->size = cache_size;
I suppose it's something like this
ret = of_property_...(..., &this_leaf->VAR);
if (ret)
warning / set default / etc
> propname = cache_type_info[ct_idx].line_size_props[i];
> - line_size = of_get_property(np, propname, NULL);
> - if (line_size)
> + line_size = of_property_read_u64(np, propname, &line_size);
> + if (line_size) {
ret = ...
if (ret) {
> + this_leaf->coherency_line_size = line_size;
> break;
> + }
> + if (!of_property_read_u64(np, propname, &nr_sets))
> + this_leaf->number_of_sets = nr_sets;
As in first case.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-18 21:50 ` Andy Shevchenko
0 siblings, 0 replies; 185+ messages in thread
From: Andy Shevchenko @ 2018-05-18 21:50 UTC (permalink / raw)
To: Sudeep Holla
Cc: Jeremy Linton, ACPI Devel Maling List, linux-arm Mailing List,
Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, Xiongfeng Wang, vkilari,
Al Stone, Dietmar.Eggemann, Morten.Rasmussen, Palmer Dabbelt,
Len Brown, John Garry, austinwc, tnowicki, jhugo, Ard Biesheuvel
On Thu, May 17, 2018 at 6:47 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> Is below patch does what you were looking for ?
Somewhat.
See below for some minors.
> of_property_read_u64 searches for a property in a device node and read
> a 64-bit value from it. Instead of using of_get_property to get the
> property and then read 64-bit value using of_read_number, we can make
> use of of_property_read_u64.
Suggested-by?
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> - cache_size = of_get_property(np, propname, NULL);
> - if (cache_size)
> - this_leaf->size = of_read_number(cache_size, 1);
> + if (!of_property_read_u64(np, propname, &cache_size))
> + this_leaf->size = cache_size;
I suppose it's something like this
ret = of_property_...(..., &this_leaf->VAR);
if (ret)
warning / set default / etc
> propname = cache_type_info[ct_idx].line_size_props[i];
> - line_size = of_get_property(np, propname, NULL);
> - if (line_size)
> + line_size = of_property_read_u64(np, propname, &line_size);
> + if (line_size) {
ret = ...
if (ret) {
> + this_leaf->coherency_line_size = line_size;
> break;
> + }
> + if (!of_property_read_u64(np, propname, &nr_sets))
> + this_leaf->number_of_sets = nr_sets;
As in first case.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
2018-05-18 21:50 ` Andy Shevchenko
(?)
(?)
@ 2018-05-21 9:27 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-21 9:27 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sudeep Holla, Jeremy Linton, ACPI Devel Maling List,
linux-arm Mailing List, Lorenzo Pieralisi, Hanjun Guo,
Rafael J. Wysocki, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Linux Kernel Mailing List,
linux-riscv, Xiongfeng Wang, vkilari, Al Stone, Dietmar.Eggemann,
Morten.Rasmussen, Palmer Dabbelt, Len
On 18/05/18 22:50, Andy Shevchenko wrote:
> On Thu, May 17, 2018 at 6:47 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>> Is below patch does what you were looking for ?
>
> Somewhat.
> See below for some minors.
>
Thanks
>> of_property_read_u64 searches for a property in a device node and read
>> a 64-bit value from it. Instead of using of_get_property to get the
>> property and then read 64-bit value using of_read_number, we can make
>> use of of_property_read_u64.
>
> Suggested-by?
>
Yes indeed, added it locally after I sent out this patch. Will send out
a proper patch soon.
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>
>
>> - cache_size = of_get_property(np, propname, NULL);
>> - if (cache_size)
>> - this_leaf->size = of_read_number(cache_size, 1);
>> + if (!of_property_read_u64(np, propname, &cache_size))
>> + this_leaf->size = cache_size;
>
> I suppose it's something like this
>
> ret = of_property_...(..., &this_leaf->VAR);
> if (ret)
> warning / set default / etc
OK, I do prefer this but once I was told not to use structure elements
directly like that, but should be harmless in this particular case, will
do so.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-21 9:27 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-21 9:27 UTC (permalink / raw)
To: linux-arm-kernel
On 18/05/18 22:50, Andy Shevchenko wrote:
> On Thu, May 17, 2018 at 6:47 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>> Is below patch does what you were looking for ?
>
> Somewhat.
> See below for some minors.
>
Thanks
>> of_property_read_u64 searches for a property in a device node and read
>> a 64-bit value from it. Instead of using of_get_property to get the
>> property and then read 64-bit value using of_read_number, we can make
>> use of of_property_read_u64.
>
> Suggested-by?
>
Yes indeed, added it locally after I sent out this patch. Will send out
a proper patch soon.
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>
>
>> - cache_size = of_get_property(np, propname, NULL);
>> - if (cache_size)
>> - this_leaf->size = of_read_number(cache_size, 1);
>> + if (!of_property_read_u64(np, propname, &cache_size))
>> + this_leaf->size = cache_size;
>
> I suppose it's something like this
>
> ret = of_property_...(..., &this_leaf->VAR);
> if (ret)
> warning / set default / etc
OK, I do prefer this but once I was told not to use structure elements
directly like that, but should be harmless in this particular case, will
do so.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-21 9:27 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-21 9:27 UTC (permalink / raw)
To: linux-riscv
On 18/05/18 22:50, Andy Shevchenko wrote:
> On Thu, May 17, 2018 at 6:47 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>> Is below patch does what you were looking for ?
>
> Somewhat.
> See below for some minors.
>
Thanks
>> of_property_read_u64 searches for a property in a device node and read
>> a 64-bit value from it. Instead of using of_get_property to get the
>> property and then read 64-bit value using of_read_number, we can make
>> use of of_property_read_u64.
>
> Suggested-by?
>
Yes indeed, added it locally after I sent out this patch. Will send out
a proper patch soon.
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>
>
>> - cache_size = of_get_property(np, propname, NULL);
>> - if (cache_size)
>> - this_leaf->size = of_read_number(cache_size, 1);
>> + if (!of_property_read_u64(np, propname, &cache_size))
>> + this_leaf->size = cache_size;
>
> I suppose it's something like this
>
> ret = of_property_...(..., &this_leaf->VAR);
> if (ret)
> warning / set default / etc
OK, I do prefer this but once I was told not to use structure elements
directly like that, but should be harmless in this particular case, will
do so.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-21 9:27 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-21 9:27 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sudeep Holla, Jeremy Linton, ACPI Devel Maling List,
linux-arm Mailing List, Lorenzo Pieralisi, Hanjun Guo,
Rafael J. Wysocki, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Linux Kernel Mailing List,
linux-riscv, Xiongfeng Wang, vkilari, Al Stone, Dietmar.Eggemann,
Morten.Rasmussen, Palmer Dabbelt, Len Brown, John Garry,
austinwc, tnowicki, jhugo, Ard Biesheuvel
On 18/05/18 22:50, Andy Shevchenko wrote:
> On Thu, May 17, 2018 at 6:47 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>> Is below patch does what you were looking for ?
>
> Somewhat.
> See below for some minors.
>
Thanks
>> of_property_read_u64 searches for a property in a device node and read
>> a 64-bit value from it. Instead of using of_get_property to get the
>> property and then read 64-bit value using of_read_number, we can make
>> use of of_property_read_u64.
>
> Suggested-by?
>
Yes indeed, added it locally after I sent out this patch. Will send out
a proper patch soon.
>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>
>
>> - cache_size = of_get_property(np, propname, NULL);
>> - if (cache_size)
>> - this_leaf->size = of_read_number(cache_size, 1);
>> + if (!of_property_read_u64(np, propname, &cache_size))
>> + this_leaf->size = cache_size;
>
> I suppose it's something like this
>
> ret = of_property_...(..., &this_leaf->VAR);
> if (ret)
> warning / set default / etc
OK, I do prefer this but once I was told not to use structure elements
directly like that, but should be harmless in this particular case, will
do so.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
2018-05-21 9:27 ` Sudeep Holla
(?)
(?)
@ 2018-05-21 10:15 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-21 10:15 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sudeep Holla, Jeremy Linton, ACPI Devel Maling List,
linux-arm Mailing List, Lorenzo Pieralisi, Hanjun Guo,
Rafael J. Wysocki, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Linux Kernel Mailing List,
linux-riscv, Xiongfeng Wang, vkilari, Al Stone, Dietmar.Eggemann,
Morten.Rasmussen, Palmer Dabbelt, Len
On 21/05/18 10:27, Sudeep Holla wrote:
>
>
> On 18/05/18 22:50, Andy Shevchenko wrote:
>> On Thu, May 17, 2018 at 6:47 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>> Is below patch does what you were looking for ?
>>
>> Somewhat.
>> See below for some minors.
>>
>
> Thanks
>
>>> of_property_read_u64 searches for a property in a device node and read
>>> a 64-bit value from it. Instead of using of_get_property to get the
>>> property and then read 64-bit value using of_read_number, we can make
>>> use of of_property_read_u64.
>>
>> Suggested-by?
>>
>
> Yes indeed, added it locally after I sent out this patch. Will send out
> a proper patch soon.
>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>
>>
>>> - cache_size = of_get_property(np, propname, NULL);
>>> - if (cache_size)
>>> - this_leaf->size = of_read_number(cache_size, 1);
>>> + if (!of_property_read_u64(np, propname, &cache_size))
>>> + this_leaf->size = cache_size;
>>
>> I suppose it's something like this
>>
>> ret = of_property_...(..., &this_leaf->VAR);
>> if (ret)
>> warning / set default / etc
>
> OK, I do prefer this but once I was told not to use structure elements
> directly like that, but should be harmless in this particular case, will
> do so.
>
I spoke too early, I need to retain local u64 variable otherwise we get
incompatible pointer type(expected 'u64 *' but argument is of type
‘unsigned int *’) error with Werror=incompatible-pointer-types.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-21 10:15 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-21 10:15 UTC (permalink / raw)
To: linux-arm-kernel
On 21/05/18 10:27, Sudeep Holla wrote:
>
>
> On 18/05/18 22:50, Andy Shevchenko wrote:
>> On Thu, May 17, 2018 at 6:47 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>> Is below patch does what you were looking for ?
>>
>> Somewhat.
>> See below for some minors.
>>
>
> Thanks
>
>>> of_property_read_u64 searches for a property in a device node and read
>>> a 64-bit value from it. Instead of using of_get_property to get the
>>> property and then read 64-bit value using of_read_number, we can make
>>> use of of_property_read_u64.
>>
>> Suggested-by?
>>
>
> Yes indeed, added it locally after I sent out this patch. Will send out
> a proper patch soon.
>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>
>>
>>> - cache_size = of_get_property(np, propname, NULL);
>>> - if (cache_size)
>>> - this_leaf->size = of_read_number(cache_size, 1);
>>> + if (!of_property_read_u64(np, propname, &cache_size))
>>> + this_leaf->size = cache_size;
>>
>> I suppose it's something like this
>>
>> ret = of_property_...(..., &this_leaf->VAR);
>> if (ret)
>> warning / set default / etc
>
> OK, I do prefer this but once I was told not to use structure elements
> directly like that, but should be harmless in this particular case, will
> do so.
>
I spoke too early, I need to retain local u64 variable otherwise we get
incompatible pointer type(expected 'u64 *' but argument is of type
?unsigned int *?) error with Werror=incompatible-pointer-types.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-21 10:15 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-21 10:15 UTC (permalink / raw)
To: linux-riscv
On 21/05/18 10:27, Sudeep Holla wrote:
>
>
> On 18/05/18 22:50, Andy Shevchenko wrote:
>> On Thu, May 17, 2018 at 6:47 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>> Is below patch does what you were looking for ?
>>
>> Somewhat.
>> See below for some minors.
>>
>
> Thanks
>
>>> of_property_read_u64 searches for a property in a device node and read
>>> a 64-bit value from it. Instead of using of_get_property to get the
>>> property and then read 64-bit value using of_read_number, we can make
>>> use of of_property_read_u64.
>>
>> Suggested-by?
>>
>
> Yes indeed, added it locally after I sent out this patch. Will send out
> a proper patch soon.
>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>
>>
>>> - cache_size = of_get_property(np, propname, NULL);
>>> - if (cache_size)
>>> - this_leaf->size = of_read_number(cache_size, 1);
>>> + if (!of_property_read_u64(np, propname, &cache_size))
>>> + this_leaf->size = cache_size;
>>
>> I suppose it's something like this
>>
>> ret = of_property_...(..., &this_leaf->VAR);
>> if (ret)
>> warning / set default / etc
>
> OK, I do prefer this but once I was told not to use structure elements
> directly like that, but should be harmless in this particular case, will
> do so.
>
I spoke too early, I need to retain local u64 variable otherwise we get
incompatible pointer type(expected 'u64 *' but argument is of type
?unsigned int *?) error with Werror=incompatible-pointer-types.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-21 10:15 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-21 10:15 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sudeep Holla, Jeremy Linton, ACPI Devel Maling List,
linux-arm Mailing List, Lorenzo Pieralisi, Hanjun Guo,
Rafael J. Wysocki, Will Deacon, Catalin Marinas,
Greg Kroah-Hartman, Mark Rutland, Linux Kernel Mailing List,
linux-riscv, Xiongfeng Wang, vkilari, Al Stone, Dietmar.Eggemann,
Morten.Rasmussen, Palmer Dabbelt, Len Brown, John Garry,
austinwc, tnowicki, jhugo, Ard Biesheuvel
On 21/05/18 10:27, Sudeep Holla wrote:
>
>
> On 18/05/18 22:50, Andy Shevchenko wrote:
>> On Thu, May 17, 2018 at 6:47 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>
>>> Is below patch does what you were looking for ?
>>
>> Somewhat.
>> See below for some minors.
>>
>
> Thanks
>
>>> of_property_read_u64 searches for a property in a device node and read
>>> a 64-bit value from it. Instead of using of_get_property to get the
>>> property and then read 64-bit value using of_read_number, we can make
>>> use of of_property_read_u64.
>>
>> Suggested-by?
>>
>
> Yes indeed, added it locally after I sent out this patch. Will send out
> a proper patch soon.
>
>>> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
>>
>>
>>> - cache_size = of_get_property(np, propname, NULL);
>>> - if (cache_size)
>>> - this_leaf->size = of_read_number(cache_size, 1);
>>> + if (!of_property_read_u64(np, propname, &cache_size))
>>> + this_leaf->size = cache_size;
>>
>> I suppose it's something like this
>>
>> ret = of_property_...(..., &this_leaf->VAR);
>> if (ret)
>> warning / set default / etc
>
> OK, I do prefer this but once I was told not to use structure elements
> directly like that, but should be harmless in this particular case, will
> do so.
>
I spoke too early, I need to retain local u64 variable otherwise we get
incompatible pointer type(expected 'u64 *' but argument is of type
‘unsigned int *’) error with Werror=incompatible-pointer-types.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH] drivers: base: cacheinfo: use OF property_read_u64 instead of get_property,read_number
2018-05-15 19:32 ` Andy Shevchenko
@ 2018-05-21 10:32 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-21 10:32 UTC (permalink / raw)
To: linux-kernel, Andy Shevchenko, linux-acpi, linux-arm-kernel
Cc: Sudeep Holla, Jeremy Linton, Catalin Marinas, Lorenzo Pieralisi,
Greg Kroah-Hartman
of_property_read_u64 searches for a property in a device node and read
a 64-bit value from it. Instead of using of_get_property to get the
property and then read 64-bit value using of_read_number, we can
simplify it by using of_property_read_u64.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/base/cacheinfo.c | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 2880e2ab01f5..6704563a9339 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -74,52 +74,50 @@ static inline int get_cacheinfo_idx(enum cache_type type)
static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *cache_size;
+ u64 cache_size;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].size_prop;
- cache_size = of_get_property(np, propname, NULL);
- if (cache_size)
- this_leaf->size = of_read_number(cache_size, 1);
+ if (!of_property_read_u64(np, propname, &cache_size))
+ this_leaf->size = cache_size;
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
static void cache_get_line_size(struct cacheinfo *this_leaf,
struct device_node *np)
{
- const __be32 *line_size;
int i, lim, ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
lim = ARRAY_SIZE(cache_type_info[ct_idx].line_size_props);
for (i = 0; i < lim; i++) {
+ int ret;
+ u64 line_size;
const char *propname;
propname = cache_type_info[ct_idx].line_size_props[i];
- line_size = of_get_property(np, propname, NULL);
- if (line_size)
+ ret = of_property_read_u64(np, propname, &line_size);
+ if (!ret) {
+ this_leaf->coherency_line_size = line_size;
break;
+ }
}
-
- if (line_size)
- this_leaf->coherency_line_size = of_read_number(line_size, 1);
}
static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *nr_sets;
+ u64 nr_sets;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].nr_sets_prop;
- nr_sets = of_get_property(np, propname, NULL);
- if (nr_sets)
- this_leaf->number_of_sets = of_read_number(nr_sets, 1);
+ if (!of_property_read_u64(np, propname, &nr_sets))
+ this_leaf->number_of_sets = nr_sets;
}
static void cache_associativity(struct cacheinfo *this_leaf)
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH] drivers: base: cacheinfo: use OF property_read_u64 instead of get_property, read_number
@ 2018-05-21 10:32 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-21 10:32 UTC (permalink / raw)
To: linux-arm-kernel
of_property_read_u64 searches for a property in a device node and read
a 64-bit value from it. Instead of using of_get_property to get the
property and then read 64-bit value using of_read_number, we can
simplify it by using of_property_read_u64.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/base/cacheinfo.c | 26 ++++++++++++--------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 2880e2ab01f5..6704563a9339 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -74,52 +74,50 @@ static inline int get_cacheinfo_idx(enum cache_type type)
static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *cache_size;
+ u64 cache_size;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].size_prop;
- cache_size = of_get_property(np, propname, NULL);
- if (cache_size)
- this_leaf->size = of_read_number(cache_size, 1);
+ if (!of_property_read_u64(np, propname, &cache_size))
+ this_leaf->size = cache_size;
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
static void cache_get_line_size(struct cacheinfo *this_leaf,
struct device_node *np)
{
- const __be32 *line_size;
int i, lim, ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
lim = ARRAY_SIZE(cache_type_info[ct_idx].line_size_props);
for (i = 0; i < lim; i++) {
+ int ret;
+ u64 line_size;
const char *propname;
propname = cache_type_info[ct_idx].line_size_props[i];
- line_size = of_get_property(np, propname, NULL);
- if (line_size)
+ ret = of_property_read_u64(np, propname, &line_size);
+ if (!ret) {
+ this_leaf->coherency_line_size = line_size;
break;
+ }
}
-
- if (line_size)
- this_leaf->coherency_line_size = of_read_number(line_size, 1);
}
static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *nr_sets;
+ u64 nr_sets;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].nr_sets_prop;
- nr_sets = of_get_property(np, propname, NULL);
- if (nr_sets)
- this_leaf->number_of_sets = of_read_number(nr_sets, 1);
+ if (!of_property_read_u64(np, propname, &nr_sets))
+ this_leaf->number_of_sets = nr_sets;
}
static void cache_associativity(struct cacheinfo *this_leaf)
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number
2018-05-21 10:32 ` [PATCH] drivers: base: cacheinfo: use OF property_read_u64 instead of get_property, read_number Sudeep Holla
@ 2018-05-21 12:53 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-21 12:53 UTC (permalink / raw)
To: linux-kernel, Andy Shevchenko, linux-acpi, linux-arm-kernel
Cc: Sudeep Holla, Jeremy Linton, Catalin Marinas, Lorenzo Pieralisi,
Greg Kroah-Hartman
of_property_read_u32 searches for a property in a device node and read
a 32-bit value from it. Instead of using of_get_property to get the
property and then read 32-bit value using of_read_number, we can
simplify it by using of_property_read_u32.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/base/cacheinfo.c | 24 ++++++++++--------------
1 file changed, 10 insertions(+), 14 deletions(-)
Hi Andy,
Ignore my comment on compile errors error with Werror=incompatible-pointer-types
I was so hung up on _u64 version and didn't realise that we were using 32-bit
with of_read_number originally.
Regards,
Sudeep
v1->v2:
- Replaced use of of_property_read_u64 with of_property_read_u32
- Also removed the local variables as Andy initially suggested
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 2880e2ab01f5..5d5b5988e88b 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -74,52 +74,48 @@ static inline int get_cacheinfo_idx(enum cache_type type)
static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *cache_size;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].size_prop;
- cache_size = of_get_property(np, propname, NULL);
- if (cache_size)
- this_leaf->size = of_read_number(cache_size, 1);
+ if (of_property_read_u32(np, propname, &this_leaf->size))
+ this_leaf->size = 0;
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
static void cache_get_line_size(struct cacheinfo *this_leaf,
struct device_node *np)
{
- const __be32 *line_size;
int i, lim, ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
lim = ARRAY_SIZE(cache_type_info[ct_idx].line_size_props);
for (i = 0; i < lim; i++) {
+ int ret;
+ u32 line_size;
const char *propname;
propname = cache_type_info[ct_idx].line_size_props[i];
- line_size = of_get_property(np, propname, NULL);
- if (line_size)
+ ret = of_property_read_u32(np, propname, &line_size);
+ if (!ret) {
+ this_leaf->coherency_line_size = line_size;
break;
+ }
}
-
- if (line_size)
- this_leaf->coherency_line_size = of_read_number(line_size, 1);
}
static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *nr_sets;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].nr_sets_prop;
- nr_sets = of_get_property(np, propname, NULL);
- if (nr_sets)
- this_leaf->number_of_sets = of_read_number(nr_sets, 1);
+ if (of_property_read_u32(np, propname, &this_leaf->number_of_sets))
+ this_leaf->number_of_sets = 0;
}
static void cache_associativity(struct cacheinfo *this_leaf)
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property, read_number
@ 2018-05-21 12:53 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-21 12:53 UTC (permalink / raw)
To: linux-arm-kernel
of_property_read_u32 searches for a property in a device node and read
a 32-bit value from it. Instead of using of_get_property to get the
property and then read 32-bit value using of_read_number, we can
simplify it by using of_property_read_u32.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/base/cacheinfo.c | 24 ++++++++++--------------
1 file changed, 10 insertions(+), 14 deletions(-)
Hi Andy,
Ignore my comment on compile errors error with Werror=incompatible-pointer-types
I was so hung up on _u64 version and didn't realise that we were using 32-bit
with of_read_number originally.
Regards,
Sudeep
v1->v2:
- Replaced use of of_property_read_u64 with of_property_read_u32
- Also removed the local variables as Andy initially suggested
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 2880e2ab01f5..5d5b5988e88b 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -74,52 +74,48 @@ static inline int get_cacheinfo_idx(enum cache_type type)
static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *cache_size;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].size_prop;
- cache_size = of_get_property(np, propname, NULL);
- if (cache_size)
- this_leaf->size = of_read_number(cache_size, 1);
+ if (of_property_read_u32(np, propname, &this_leaf->size))
+ this_leaf->size = 0;
}
/* not cache_line_size() because that's a macro in include/linux/cache.h */
static void cache_get_line_size(struct cacheinfo *this_leaf,
struct device_node *np)
{
- const __be32 *line_size;
int i, lim, ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
lim = ARRAY_SIZE(cache_type_info[ct_idx].line_size_props);
for (i = 0; i < lim; i++) {
+ int ret;
+ u32 line_size;
const char *propname;
propname = cache_type_info[ct_idx].line_size_props[i];
- line_size = of_get_property(np, propname, NULL);
- if (line_size)
+ ret = of_property_read_u32(np, propname, &line_size);
+ if (!ret) {
+ this_leaf->coherency_line_size = line_size;
break;
+ }
}
-
- if (line_size)
- this_leaf->coherency_line_size = of_read_number(line_size, 1);
}
static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
{
const char *propname;
- const __be32 *nr_sets;
int ct_idx;
ct_idx = get_cacheinfo_idx(this_leaf->type);
propname = cache_type_info[ct_idx].nr_sets_prop;
- nr_sets = of_get_property(np, propname, NULL);
- if (nr_sets)
- this_leaf->number_of_sets = of_read_number(nr_sets, 1);
+ if (of_property_read_u32(np, propname, &this_leaf->number_of_sets))
+ this_leaf->number_of_sets = 0;
}
static void cache_associativity(struct cacheinfo *this_leaf)
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread* Re: [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number
2018-05-21 12:53 ` [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property, read_number Sudeep Holla
@ 2018-06-05 16:21 ` Andy Shevchenko
-1 siblings, 0 replies; 185+ messages in thread
From: Andy Shevchenko @ 2018-06-05 16:21 UTC (permalink / raw)
To: Sudeep Holla
Cc: Linux Kernel Mailing List, ACPI Devel Maling List,
linux-arm Mailing List, Jeremy Linton, Catalin Marinas,
Lorenzo Pieralisi, Greg Kroah-Hartman
On Mon, May 21, 2018 at 3:53 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> of_property_read_u32 searches for a property in a device node and read
> a 32-bit value from it. Instead of using of_get_property to get the
> property and then read 32-bit value using of_read_number, we can
> simplify it by using of_property_read_u32.
>
LGTM.
Thanks!
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/base/cacheinfo.c | 24 ++++++++++--------------
> 1 file changed, 10 insertions(+), 14 deletions(-)
>
> Hi Andy,
>
> Ignore my comment on compile errors error with Werror=incompatible-pointer-types
> I was so hung up on _u64 version and didn't realise that we were using 32-bit
> with of_read_number originally.
>
> Regards,
> Sudeep
>
> v1->v2:
> - Replaced use of of_property_read_u64 with of_property_read_u32
> - Also removed the local variables as Andy initially suggested
>
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index 2880e2ab01f5..5d5b5988e88b 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -74,52 +74,48 @@ static inline int get_cacheinfo_idx(enum cache_type type)
> static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> - const __be32 *cache_size;
> int ct_idx;
>
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].size_prop;
>
> - cache_size = of_get_property(np, propname, NULL);
> - if (cache_size)
> - this_leaf->size = of_read_number(cache_size, 1);
> + if (of_property_read_u32(np, propname, &this_leaf->size))
> + this_leaf->size = 0;
> }
>
> /* not cache_line_size() because that's a macro in include/linux/cache.h */
> static void cache_get_line_size(struct cacheinfo *this_leaf,
> struct device_node *np)
> {
> - const __be32 *line_size;
> int i, lim, ct_idx;
>
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> lim = ARRAY_SIZE(cache_type_info[ct_idx].line_size_props);
>
> for (i = 0; i < lim; i++) {
> + int ret;
> + u32 line_size;
> const char *propname;
>
> propname = cache_type_info[ct_idx].line_size_props[i];
> - line_size = of_get_property(np, propname, NULL);
> - if (line_size)
> + ret = of_property_read_u32(np, propname, &line_size);
> + if (!ret) {
> + this_leaf->coherency_line_size = line_size;
> break;
> + }
> }
> -
> - if (line_size)
> - this_leaf->coherency_line_size = of_read_number(line_size, 1);
> }
>
> static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> - const __be32 *nr_sets;
> int ct_idx;
>
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].nr_sets_prop;
>
> - nr_sets = of_get_property(np, propname, NULL);
> - if (nr_sets)
> - this_leaf->number_of_sets = of_read_number(nr_sets, 1);
> + if (of_property_read_u32(np, propname, &this_leaf->number_of_sets))
> + this_leaf->number_of_sets = 0;
> }
>
> static void cache_associativity(struct cacheinfo *this_leaf)
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number
@ 2018-06-05 16:21 ` Andy Shevchenko
0 siblings, 0 replies; 185+ messages in thread
From: Andy Shevchenko @ 2018-06-05 16:21 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, May 21, 2018 at 3:53 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> of_property_read_u32 searches for a property in a device node and read
> a 32-bit value from it. Instead of using of_get_property to get the
> property and then read 32-bit value using of_read_number, we can
> simplify it by using of_property_read_u32.
>
LGTM.
Thanks!
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/base/cacheinfo.c | 24 ++++++++++--------------
> 1 file changed, 10 insertions(+), 14 deletions(-)
>
> Hi Andy,
>
> Ignore my comment on compile errors error with Werror=incompatible-pointer-types
> I was so hung up on _u64 version and didn't realise that we were using 32-bit
> with of_read_number originally.
>
> Regards,
> Sudeep
>
> v1->v2:
> - Replaced use of of_property_read_u64 with of_property_read_u32
> - Also removed the local variables as Andy initially suggested
>
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index 2880e2ab01f5..5d5b5988e88b 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -74,52 +74,48 @@ static inline int get_cacheinfo_idx(enum cache_type type)
> static void cache_size(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> - const __be32 *cache_size;
> int ct_idx;
>
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].size_prop;
>
> - cache_size = of_get_property(np, propname, NULL);
> - if (cache_size)
> - this_leaf->size = of_read_number(cache_size, 1);
> + if (of_property_read_u32(np, propname, &this_leaf->size))
> + this_leaf->size = 0;
> }
>
> /* not cache_line_size() because that's a macro in include/linux/cache.h */
> static void cache_get_line_size(struct cacheinfo *this_leaf,
> struct device_node *np)
> {
> - const __be32 *line_size;
> int i, lim, ct_idx;
>
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> lim = ARRAY_SIZE(cache_type_info[ct_idx].line_size_props);
>
> for (i = 0; i < lim; i++) {
> + int ret;
> + u32 line_size;
> const char *propname;
>
> propname = cache_type_info[ct_idx].line_size_props[i];
> - line_size = of_get_property(np, propname, NULL);
> - if (line_size)
> + ret = of_property_read_u32(np, propname, &line_size);
> + if (!ret) {
> + this_leaf->coherency_line_size = line_size;
> break;
> + }
> }
> -
> - if (line_size)
> - this_leaf->coherency_line_size = of_read_number(line_size, 1);
> }
>
> static void cache_nr_sets(struct cacheinfo *this_leaf, struct device_node *np)
> {
> const char *propname;
> - const __be32 *nr_sets;
> int ct_idx;
>
> ct_idx = get_cacheinfo_idx(this_leaf->type);
> propname = cache_type_info[ct_idx].nr_sets_prop;
>
> - nr_sets = of_get_property(np, propname, NULL);
> - if (nr_sets)
> - this_leaf->number_of_sets = of_read_number(nr_sets, 1);
> + if (of_property_read_u32(np, propname, &this_leaf->number_of_sets))
> + this_leaf->number_of_sets = 0;
> }
>
> static void cache_associativity(struct cacheinfo *this_leaf)
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number
2018-06-05 16:21 ` Andy Shevchenko
@ 2018-06-05 16:26 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-06-05 16:26 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Sudeep Holla, Linux Kernel Mailing List, ACPI Devel Maling List,
linux-arm Mailing List, Jeremy Linton, Catalin Marinas,
Lorenzo Pieralisi, Greg Kroah-Hartman
On 05/06/18 17:21, Andy Shevchenko wrote:
> On Mon, May 21, 2018 at 3:53 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> of_property_read_u32 searches for a property in a device node and read
>> a 32-bit value from it. Instead of using of_get_property to get the
>> property and then read 32-bit value using of_read_number, we can
>> simplify it by using of_property_read_u32.
>>
>
> LGTM.
> Thanks!
>
Thanks, can I take is Ack ?
Anyways it's too late for v4.18, will repost after the merge window for
v4.19 with your Ack if you agree.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number
@ 2018-06-05 16:26 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-06-05 16:26 UTC (permalink / raw)
To: linux-arm-kernel
On 05/06/18 17:21, Andy Shevchenko wrote:
> On Mon, May 21, 2018 at 3:53 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> of_property_read_u32 searches for a property in a device node and read
>> a 32-bit value from it. Instead of using of_get_property to get the
>> property and then read 32-bit value using of_read_number, we can
>> simplify it by using of_property_read_u32.
>>
>
> LGTM.
> Thanks!
>
Thanks, can I take is Ack ?
Anyways it's too late for v4.18, will repost after the merge window for
v4.19 with your Ack if you agree.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number
2018-06-05 16:26 ` Sudeep Holla
@ 2018-06-05 16:34 ` Andy Shevchenko
-1 siblings, 0 replies; 185+ messages in thread
From: Andy Shevchenko @ 2018-06-05 16:34 UTC (permalink / raw)
To: Sudeep Holla
Cc: Linux Kernel Mailing List, ACPI Devel Maling List,
linux-arm Mailing List, Jeremy Linton, Catalin Marinas,
Lorenzo Pieralisi, Greg Kroah-Hartman
On Tue, Jun 5, 2018 at 7:26 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 05/06/18 17:21, Andy Shevchenko wrote:
>> On Mon, May 21, 2018 at 3:53 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> of_property_read_u32 searches for a property in a device node and read
>>> a 32-bit value from it. Instead of using of_get_property to get the
>>> property and then read 32-bit value using of_read_number, we can
>>> simplify it by using of_property_read_u32.
>>>
>>
>> LGTM.
>> Thanks!
>>
>
> Thanks, can I take is Ack ?
>
> Anyways it's too late for v4.18, will repost after the merge window for
> v4.19 with your Ack if you agree.
You can consider like this, though it makes a little change here since
I'm not a maintainer of the code.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v2] drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number
@ 2018-06-05 16:34 ` Andy Shevchenko
0 siblings, 0 replies; 185+ messages in thread
From: Andy Shevchenko @ 2018-06-05 16:34 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, Jun 5, 2018 at 7:26 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 05/06/18 17:21, Andy Shevchenko wrote:
>> On Mon, May 21, 2018 at 3:53 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> of_property_read_u32 searches for a property in a device node and read
>>> a 32-bit value from it. Instead of using of_get_property to get the
>>> property and then read 32-bit value using of_read_number, we can
>>> simplify it by using of_property_read_u32.
>>>
>>
>> LGTM.
>> Thanks!
>>
>
> Thanks, can I take is Ack ?
>
> Anyways it's too late for v4.18, will repost after the merge window for
> v4.19 with your Ack if you agree.
You can consider like this, though it makes a little change here since
I'm not a maintainer of the code.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
2018-05-15 17:15 ` Jeremy Linton
(?)
@ 2018-05-17 6:54 ` Greg KH
-1 siblings, 0 replies; 185+ messages in thread
From: Greg KH @ 2018-05-17 6:54 UTC (permalink / raw)
To: Jeremy Linton
Cc: linux-acpi, Sudeep.Holla, linux-arm-kernel, Lorenzo.Pieralisi,
hanjun.guo, rjw, Will.Deacon, Catalin.Marinas, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel
On Tue, May 15, 2018 at 12:15:08PM -0500, Jeremy Linton wrote:
> Hi Greg,
>
> Have you had a chance to look at the cachinfo parts of this patch?
Nope :)
I didn't write that, and while it is dumped in the driver core section
of the kernel, I know nothing about it. If you get an ack from Sundeep
for this, which you did, that's fine with me, merge away!
thanks,
greg k-h
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-17 6:54 ` Greg KH
0 siblings, 0 replies; 185+ messages in thread
From: Greg KH @ 2018-05-17 6:54 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2018 at 12:15:08PM -0500, Jeremy Linton wrote:
> Hi Greg,
>
> Have you had a chance to look at the cachinfo parts of this patch?
Nope :)
I didn't write that, and while it is dumped in the driver core section
of the kernel, I know nothing about it. If you get an ack from Sundeep
for this, which you did, that's fine with me, merge away!
thanks,
greg k-h
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-17 6:54 ` Greg KH
0 siblings, 0 replies; 185+ messages in thread
From: Greg KH @ 2018-05-17 6:54 UTC (permalink / raw)
To: linux-riscv
On Tue, May 15, 2018 at 12:15:08PM -0500, Jeremy Linton wrote:
> Hi Greg,
>
> Have you had a chance to look at the cachinfo parts of this patch?
Nope :)
I didn't write that, and while it is dumped in the driver core section
of the kernel, I know nothing about it. If you get an ack from Sundeep
for this, which you did, that's fine with me, merge away!
thanks,
greg k-h
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
2018-05-17 6:54 ` Greg KH
(?)
@ 2018-05-17 9:08 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-17 9:08 UTC (permalink / raw)
To: Greg KH, Jeremy Linton, Catalin.Marinas
Cc: Sudeep Holla, linux-acpi, linux-arm-kernel, Lorenzo.Pieralisi,
hanjun.guo, rjw, Will.Deacon, Mark.Rutland, linux-kernel,
linux-riscv, wangxiongfeng2, vkilari, ahs3, Dietmar.Eggemann,
Morten.Rasmussen, palmer, lenb, john.garry, austinwc, tnowicki,
jhugo, ard.biesheuvel
Hi Greg,
On 17/05/18 07:54, Greg KH wrote:
> On Tue, May 15, 2018 at 12:15:08PM -0500, Jeremy Linton wrote:
>> Hi Greg,
>>
>> Have you had a chance to look at the cachinfo parts of this patch?
>
> Nope :)
>
> I didn't write that, and while it is dumped in the driver core section
> of the kernel, I know nothing about it.
Sorry for that, I didn't find any better place at that time(neither
now), so I did put it there following topology :)
> If you get an ack from Sudeep for this, which you did, that's fine
> with me, merge away!
>
Thanks, we plan to take it via ARM64, hence we needed your official
say(ACK) for that.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-17 9:08 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-17 9:08 UTC (permalink / raw)
To: linux-arm-kernel
Hi Greg,
On 17/05/18 07:54, Greg KH wrote:
> On Tue, May 15, 2018 at 12:15:08PM -0500, Jeremy Linton wrote:
>> Hi Greg,
>>
>> Have you had a chance to look at the cachinfo parts of this patch?
>
> Nope :)
>
> I didn't write that, and while it is dumped in the driver core section
> of the kernel, I know nothing about it.
Sorry for that, I didn't find any better place at that time(neither
now), so I did put it there following topology :)
> If you get an ack from Sudeep for this, which you did, that's fine
> with me, merge away!
>
Thanks, we plan to take it via ARM64, hence we needed your official
say(ACK) for that.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-17 9:08 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-17 9:08 UTC (permalink / raw)
To: linux-riscv
Hi Greg,
On 17/05/18 07:54, Greg KH wrote:
> On Tue, May 15, 2018 at 12:15:08PM -0500, Jeremy Linton wrote:
>> Hi Greg,
>>
>> Have you had a chance to look at the cachinfo parts of this patch?
>
> Nope :)
>
> I didn't write that, and while it is dumped in the driver core section
> of the kernel, I know nothing about it.
Sorry for that, I didn't find any better place at that time(neither
now), so I did put it there following topology :)
> If you get an ack from Sudeep for this, which you did, that's fine
> with me, merge away!
>
Thanks, we plan to take it via ARM64, hence we needed your official
say(ACK) for that.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
2018-05-17 9:08 ` Sudeep Holla
(?)
@ 2018-05-17 9:35 ` Greg KH
-1 siblings, 0 replies; 185+ messages in thread
From: Greg KH @ 2018-05-17 9:35 UTC (permalink / raw)
To: Sudeep Holla
Cc: Jeremy Linton, Catalin.Marinas, linux-acpi, linux-arm-kernel,
Lorenzo.Pieralisi, hanjun.guo, rjw, Will.Deacon, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel
On Thu, May 17, 2018 at 10:08:25AM +0100, Sudeep Holla wrote:
> Hi Greg,
>
> On 17/05/18 07:54, Greg KH wrote:
> > On Tue, May 15, 2018 at 12:15:08PM -0500, Jeremy Linton wrote:
> >> Hi Greg,
> >>
> >> Have you had a chance to look at the cachinfo parts of this patch?
> >
> > Nope :)
> >
> > I didn't write that, and while it is dumped in the driver core section
> > of the kernel, I know nothing about it.
>
> Sorry for that, I didn't find any better place at that time(neither
> now), so I did put it there following topology :)
>
> > If you get an ack from Sudeep for this, which you did, that's fine
> > with me, merge away!
> >
>
> Thanks, we plan to take it via ARM64, hence we needed your official
> say(ACK) for that.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-17 9:35 ` Greg KH
0 siblings, 0 replies; 185+ messages in thread
From: Greg KH @ 2018-05-17 9:35 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, May 17, 2018 at 10:08:25AM +0100, Sudeep Holla wrote:
> Hi Greg,
>
> On 17/05/18 07:54, Greg KH wrote:
> > On Tue, May 15, 2018 at 12:15:08PM -0500, Jeremy Linton wrote:
> >> Hi Greg,
> >>
> >> Have you had a chance to look at the cachinfo parts of this patch?
> >
> > Nope :)
> >
> > I didn't write that, and while it is dumped in the driver core section
> > of the kernel, I know nothing about it.
>
> Sorry for that, I didn't find any better place at that time(neither
> now), so I did put it there following topology :)
>
> > If you get an ack from Sudeep for this, which you did, that's fine
> > with me, merge away!
> >
>
> Thanks, we plan to take it via ARM64, hence we needed your official
> say(ACK) for that.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 02/12] drivers: base: cacheinfo: setup DT cache properties early
@ 2018-05-17 9:35 ` Greg KH
0 siblings, 0 replies; 185+ messages in thread
From: Greg KH @ 2018-05-17 9:35 UTC (permalink / raw)
To: linux-riscv
On Thu, May 17, 2018 at 10:08:25AM +0100, Sudeep Holla wrote:
> Hi Greg,
>
> On 17/05/18 07:54, Greg KH wrote:
> > On Tue, May 15, 2018 at 12:15:08PM -0500, Jeremy Linton wrote:
> >> Hi Greg,
> >>
> >> Have you had a chance to look at the cachinfo parts of this patch?
> >
> > Nope :)
> >
> > I didn't write that, and while it is dumped in the driver core section
> > of the kernel, I know nothing about it.
>
> Sorry for that, I didn't find any better place at that time(neither
> now), so I did put it there following topology :)
>
> > If you get an ack from Sudeep for this, which you did, that's fine
> > with me, merge away!
> >
>
> Thanks, we plan to take it via ARM64, hence we needed your official
> say(ACK) for that.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 03/12] cacheinfo: rename of_node to fw_token
2018-05-11 23:57 ` Jeremy Linton
(?)
@ 2018-05-11 23:57 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-acpi
Cc: Sudeep.Holla, linux-arm-kernel, Lorenzo.Pieralisi, hanjun.guo,
rjw, Will.Deacon, Catalin.Marinas, gregkh, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel, Jeremy Linton
Rename and change the type of of_node to indicate
it is a generic pointer which is generally only used
for comparison purposes. In a later patch we will put
an ACPI/PPTT token pointer in fw_token so that
the code which builds the shared cpu masks can be reused.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/base/cacheinfo.c | 16 +++++++++-------
include/linux/cacheinfo.h | 8 +++-----
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index a872523e8951..597aacb233fc 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -35,7 +35,7 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu)
static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
struct cacheinfo *sib_leaf)
{
- return sib_leaf->of_node == this_leaf->of_node;
+ return sib_leaf->fw_token == this_leaf->fw_token;
}
/* OF properties to query for a given cache type */
@@ -167,9 +167,10 @@ static int cache_setup_of_node(unsigned int cpu)
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
unsigned int index = 0;
- /* skip if of_node is already populated */
- if (this_cpu_ci->info_list->of_node)
+ /* skip if fw_token is already populated */
+ if (this_cpu_ci->info_list->fw_token) {
return 0;
+ }
if (!cpu_dev) {
pr_err("No cpu device for CPU %d\n", cpu);
@@ -190,7 +191,7 @@ static int cache_setup_of_node(unsigned int cpu)
if (!np)
break;
cache_of_set_props(this_leaf, np);
- this_leaf->of_node = np;
+ this_leaf->fw_token = np;
index++;
}
@@ -278,7 +279,7 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
cpumask_clear_cpu(cpu, &sib_leaf->shared_cpu_map);
cpumask_clear_cpu(sibling, &this_leaf->shared_cpu_map);
}
- of_node_put(this_leaf->of_node);
+ of_node_put(this_leaf->fw_token);
}
}
@@ -323,8 +324,9 @@ static int detect_cache_attributes(unsigned int cpu)
if (ret)
goto free_ci;
/*
- * For systems using DT for cache hierarchy, of_node and shared_cpu_map
- * will be set up here only if they are not populated already
+ * For systems using DT for cache hierarchy, fw_token
+ * and shared_cpu_map will be set up here only if they are
+ * not populated already
*/
ret = cache_shared_cpu_map_setup(cpu);
if (ret) {
diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
index 3d9805297cda..0c6f658054d2 100644
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@ -34,9 +34,8 @@ enum cache_type {
* @shared_cpu_map: logical cpumask representing all the cpus sharing
* this cache node
* @attributes: bitfield representing various cache attributes
- * @of_node: if devicetree is used, this represents either the cpu node in
- * case there's no explicit cache node or the cache node itself in the
- * device tree
+ * @fw_token: Unique value used to determine if different cacheinfo
+ * structures represent a single hardware cache instance.
* @disable_sysfs: indicates whether this node is visible to the user via
* sysfs or not
* @priv: pointer to any private data structure specific to particular
@@ -65,8 +64,7 @@ struct cacheinfo {
#define CACHE_ALLOCATE_POLICY_MASK \
(CACHE_READ_ALLOCATE | CACHE_WRITE_ALLOCATE)
#define CACHE_ID BIT(4)
-
- struct device_node *of_node;
+ void *fw_token;
bool disable_sysfs;
void *priv;
};
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 03/12] cacheinfo: rename of_node to fw_token
@ 2018-05-11 23:57 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-arm-kernel
Rename and change the type of of_node to indicate
it is a generic pointer which is generally only used
for comparison purposes. In a later patch we will put
an ACPI/PPTT token pointer in fw_token so that
the code which builds the shared cpu masks can be reused.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/base/cacheinfo.c | 16 +++++++++-------
include/linux/cacheinfo.h | 8 +++-----
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index a872523e8951..597aacb233fc 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -35,7 +35,7 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu)
static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
struct cacheinfo *sib_leaf)
{
- return sib_leaf->of_node == this_leaf->of_node;
+ return sib_leaf->fw_token == this_leaf->fw_token;
}
/* OF properties to query for a given cache type */
@@ -167,9 +167,10 @@ static int cache_setup_of_node(unsigned int cpu)
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
unsigned int index = 0;
- /* skip if of_node is already populated */
- if (this_cpu_ci->info_list->of_node)
+ /* skip if fw_token is already populated */
+ if (this_cpu_ci->info_list->fw_token) {
return 0;
+ }
if (!cpu_dev) {
pr_err("No cpu device for CPU %d\n", cpu);
@@ -190,7 +191,7 @@ static int cache_setup_of_node(unsigned int cpu)
if (!np)
break;
cache_of_set_props(this_leaf, np);
- this_leaf->of_node = np;
+ this_leaf->fw_token = np;
index++;
}
@@ -278,7 +279,7 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
cpumask_clear_cpu(cpu, &sib_leaf->shared_cpu_map);
cpumask_clear_cpu(sibling, &this_leaf->shared_cpu_map);
}
- of_node_put(this_leaf->of_node);
+ of_node_put(this_leaf->fw_token);
}
}
@@ -323,8 +324,9 @@ static int detect_cache_attributes(unsigned int cpu)
if (ret)
goto free_ci;
/*
- * For systems using DT for cache hierarchy, of_node and shared_cpu_map
- * will be set up here only if they are not populated already
+ * For systems using DT for cache hierarchy, fw_token
+ * and shared_cpu_map will be set up here only if they are
+ * not populated already
*/
ret = cache_shared_cpu_map_setup(cpu);
if (ret) {
diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
index 3d9805297cda..0c6f658054d2 100644
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@ -34,9 +34,8 @@ enum cache_type {
* @shared_cpu_map: logical cpumask representing all the cpus sharing
* this cache node
* @attributes: bitfield representing various cache attributes
- * @of_node: if devicetree is used, this represents either the cpu node in
- * case there's no explicit cache node or the cache node itself in the
- * device tree
+ * @fw_token: Unique value used to determine if different cacheinfo
+ * structures represent a single hardware cache instance.
* @disable_sysfs: indicates whether this node is visible to the user via
* sysfs or not
* @priv: pointer to any private data structure specific to particular
@@ -65,8 +64,7 @@ struct cacheinfo {
#define CACHE_ALLOCATE_POLICY_MASK \
(CACHE_READ_ALLOCATE | CACHE_WRITE_ALLOCATE)
#define CACHE_ID BIT(4)
-
- struct device_node *of_node;
+ void *fw_token;
bool disable_sysfs;
void *priv;
};
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 03/12] cacheinfo: rename of_node to fw_token
@ 2018-05-11 23:57 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-riscv
Rename and change the type of of_node to indicate
it is a generic pointer which is generally only used
for comparison purposes. In a later patch we will put
an ACPI/PPTT token pointer in fw_token so that
the code which builds the shared cpu masks can be reused.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/base/cacheinfo.c | 16 +++++++++-------
include/linux/cacheinfo.h | 8 +++-----
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index a872523e8951..597aacb233fc 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -35,7 +35,7 @@ struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu)
static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
struct cacheinfo *sib_leaf)
{
- return sib_leaf->of_node == this_leaf->of_node;
+ return sib_leaf->fw_token == this_leaf->fw_token;
}
/* OF properties to query for a given cache type */
@@ -167,9 +167,10 @@ static int cache_setup_of_node(unsigned int cpu)
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
unsigned int index = 0;
- /* skip if of_node is already populated */
- if (this_cpu_ci->info_list->of_node)
+ /* skip if fw_token is already populated */
+ if (this_cpu_ci->info_list->fw_token) {
return 0;
+ }
if (!cpu_dev) {
pr_err("No cpu device for CPU %d\n", cpu);
@@ -190,7 +191,7 @@ static int cache_setup_of_node(unsigned int cpu)
if (!np)
break;
cache_of_set_props(this_leaf, np);
- this_leaf->of_node = np;
+ this_leaf->fw_token = np;
index++;
}
@@ -278,7 +279,7 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
cpumask_clear_cpu(cpu, &sib_leaf->shared_cpu_map);
cpumask_clear_cpu(sibling, &this_leaf->shared_cpu_map);
}
- of_node_put(this_leaf->of_node);
+ of_node_put(this_leaf->fw_token);
}
}
@@ -323,8 +324,9 @@ static int detect_cache_attributes(unsigned int cpu)
if (ret)
goto free_ci;
/*
- * For systems using DT for cache hierarchy, of_node and shared_cpu_map
- * will be set up here only if they are not populated already
+ * For systems using DT for cache hierarchy, fw_token
+ * and shared_cpu_map will be set up here only if they are
+ * not populated already
*/
ret = cache_shared_cpu_map_setup(cpu);
if (ret) {
diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
index 3d9805297cda..0c6f658054d2 100644
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@ -34,9 +34,8 @@ enum cache_type {
* @shared_cpu_map: logical cpumask representing all the cpus sharing
* this cache node
* @attributes: bitfield representing various cache attributes
- * @of_node: if devicetree is used, this represents either the cpu node in
- * case there's no explicit cache node or the cache node itself in the
- * device tree
+ * @fw_token: Unique value used to determine if different cacheinfo
+ * structures represent a single hardware cache instance.
* @disable_sysfs: indicates whether this node is visible to the user via
* sysfs or not
* @priv: pointer to any private data structure specific to particular
@@ -65,8 +64,7 @@ struct cacheinfo {
#define CACHE_ALLOCATE_POLICY_MASK \
(CACHE_READ_ALLOCATE | CACHE_WRITE_ALLOCATE)
#define CACHE_ID BIT(4)
-
- struct device_node *of_node;
+ void *fw_token;
bool disable_sysfs;
void *priv;
};
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH v9 04/12] arm64/acpi: Create arch specific cpu to acpi id helper
2018-05-11 23:57 ` Jeremy Linton
(?)
@ 2018-05-11 23:57 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-acpi
Cc: Sudeep.Holla, linux-arm-kernel, Lorenzo.Pieralisi, hanjun.guo,
rjw, Will.Deacon, Catalin.Marinas, gregkh, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel, Jeremy Linton
Its helpful to be able to lookup the acpi_processor_id associated
with a logical cpu. Provide an arm64 helper to do this.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/include/asm/acpi.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 32f465a80e4e..0db62a4cbce2 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -86,6 +86,10 @@ static inline bool acpi_has_cpu_in_madt(void)
}
struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu);
+static inline u32 get_acpi_id_for_cpu(unsigned int cpu)
+{
+ return acpi_cpu_get_madt_gicc(cpu)->uid;
+}
static inline void arch_fix_phys_package_id(int num, u32 slot) { }
void __init acpi_init_cpus(void);
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 04/12] arm64/acpi: Create arch specific cpu to acpi id helper
@ 2018-05-11 23:57 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-arm-kernel
Its helpful to be able to lookup the acpi_processor_id associated
with a logical cpu. Provide an arm64 helper to do this.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/include/asm/acpi.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 32f465a80e4e..0db62a4cbce2 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -86,6 +86,10 @@ static inline bool acpi_has_cpu_in_madt(void)
}
struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu);
+static inline u32 get_acpi_id_for_cpu(unsigned int cpu)
+{
+ return acpi_cpu_get_madt_gicc(cpu)->uid;
+}
static inline void arch_fix_phys_package_id(int num, u32 slot) { }
void __init acpi_init_cpus(void);
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 04/12] arm64/acpi: Create arch specific cpu to acpi id helper
@ 2018-05-11 23:57 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:57 UTC (permalink / raw)
To: linux-riscv
Its helpful to be able to lookup the acpi_processor_id associated
with a logical cpu. Provide an arm64 helper to do this.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/include/asm/acpi.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 32f465a80e4e..0db62a4cbce2 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -86,6 +86,10 @@ static inline bool acpi_has_cpu_in_madt(void)
}
struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu);
+static inline u32 get_acpi_id_for_cpu(unsigned int cpu)
+{
+ return acpi_cpu_get_madt_gicc(cpu)->uid;
+}
static inline void arch_fix_phys_package_id(int num, u32 slot) { }
void __init acpi_init_cpus(void);
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* Re: [PATCH v9 04/12] arm64/acpi: Create arch specific cpu to acpi id helper
2018-05-11 23:57 ` Jeremy Linton
(?)
@ 2018-05-14 14:41 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-14 14:41 UTC (permalink / raw)
To: Jeremy Linton, linux-acpi
Cc: Sudeep Holla, linux-arm-kernel, Lorenzo.Pieralisi, hanjun.guo,
rjw, Will.Deacon, Catalin.Marinas, gregkh, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel
On 12/05/18 00:57, Jeremy Linton wrote:
> Its helpful to be able to lookup the acpi_processor_id associated
> with a logical cpu. Provide an arm64 helper to do this.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 04/12] arm64/acpi: Create arch specific cpu to acpi id helper
@ 2018-05-14 14:41 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-14 14:41 UTC (permalink / raw)
To: linux-arm-kernel
On 12/05/18 00:57, Jeremy Linton wrote:
> Its helpful to be able to lookup the acpi_processor_id associated
> with a logical cpu. Provide an arm64 helper to do this.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 04/12] arm64/acpi: Create arch specific cpu to acpi id helper
@ 2018-05-14 14:41 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-14 14:41 UTC (permalink / raw)
To: linux-riscv
On 12/05/18 00:57, Jeremy Linton wrote:
> Its helpful to be able to lookup the acpi_processor_id associated
> with a logical cpu. Provide an arm64 helper to do this.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
2018-05-11 23:57 ` Jeremy Linton
(?)
@ 2018-05-11 23:58 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-acpi
Cc: Sudeep.Holla, linux-arm-kernel, Lorenzo.Pieralisi, hanjun.guo,
rjw, Will.Deacon, Catalin.Marinas, gregkh, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel, Jeremy Linton
ACPI 6.2 adds a new table, which describes how processing units
are related to each other in tree like fashion. Caches are
also sprinkled throughout the tree and describe the properties
of the caches in relation to other caches and processing units.
Add the code to parse the cache hierarchy and report the total
number of levels of cache for a given core using
acpi_find_last_cache_level() as well as fill out the individual
cores cache information with cache_setup_acpi() once the
cpu_cacheinfo structure has been populated by the arch specific
code.
An additional patch later in the set adds the ability to report
peers in the topology using find_acpi_cpu_topology()
to report a unique ID for each processing unit at a given level
in the tree. These unique id's can then be used to match related
processing units which exist as threads, within a given
package, etc.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/acpi/pptt.c | 655 +++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/acpi.h | 4 +
2 files changed, 659 insertions(+)
create mode 100644 drivers/acpi/pptt.c
diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
new file mode 100644
index 000000000000..e5ea1974d1e3
--- /dev/null
+++ b/drivers/acpi/pptt.c
@@ -0,0 +1,655 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * pptt.c - parsing of Processor Properties Topology Table (PPTT)
+ *
+ * Copyright (C) 2018, ARM
+ *
+ * This file implements parsing of the Processor Properties Topology Table
+ * which is optionally used to describe the processor and cache topology.
+ * Due to the relative pointers used throughout the table, this doesn't
+ * leverage the existing subtable parsing in the kernel.
+ *
+ * The PPTT structure is an inverted tree, with each node potentially
+ * holding one or two inverted tree data structures describing
+ * the caches available at that level. Each cache structure optionally
+ * contains properties describing the cache at a given level which can be
+ * used to override hardware probed values.
+ */
+#define pr_fmt(fmt) "ACPI PPTT: " fmt
+
+#include <linux/acpi.h>
+#include <linux/cacheinfo.h>
+#include <acpi/processor.h>
+
+static struct acpi_subtable_header *fetch_pptt_subtable(struct acpi_table_header *table_hdr,
+ u32 pptt_ref)
+{
+ struct acpi_subtable_header *entry;
+
+ /* there isn't a subtable at reference 0 */
+ if (pptt_ref < sizeof(struct acpi_subtable_header))
+ return NULL;
+
+ if (pptt_ref + sizeof(struct acpi_subtable_header) > table_hdr->length)
+ return NULL;
+
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, pptt_ref);
+
+ if (entry->length == 0)
+ return NULL;
+
+ if (pptt_ref + entry->length > table_hdr->length)
+ return NULL;
+
+ return entry;
+}
+
+static struct acpi_pptt_processor *fetch_pptt_node(struct acpi_table_header *table_hdr,
+ u32 pptt_ref)
+{
+ return (struct acpi_pptt_processor *)fetch_pptt_subtable(table_hdr, pptt_ref);
+}
+
+static struct acpi_pptt_cache *fetch_pptt_cache(struct acpi_table_header *table_hdr,
+ u32 pptt_ref)
+{
+ return (struct acpi_pptt_cache *)fetch_pptt_subtable(table_hdr, pptt_ref);
+}
+
+static struct acpi_subtable_header *acpi_get_pptt_resource(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *node,
+ int resource)
+{
+ u32 *ref;
+
+ if (resource >= node->number_of_priv_resources)
+ return NULL;
+
+ ref = ACPI_ADD_PTR(u32, node, sizeof(struct acpi_pptt_processor));
+ ref += resource;
+
+ return fetch_pptt_subtable(table_hdr, *ref);
+}
+
+static inline bool acpi_pptt_match_type(int table_type, int type)
+{
+ return ((table_type & ACPI_PPTT_MASK_CACHE_TYPE) == type ||
+ table_type & ACPI_PPTT_CACHE_TYPE_UNIFIED & type);
+}
+
+/**
+ * acpi_pptt_walk_cache() - Attempt to find the requested acpi_pptt_cache
+ * @table_hdr: Pointer to the head of the PPTT table
+ * @local_level: passed res reflects this cache level
+ * @res: cache resource in the PPTT we want to walk
+ * @found: returns a pointer to the requested level if found
+ * @level: the requested cache level
+ * @type: the requested cache type
+ *
+ * Attempt to find a given cache level, while counting the max number
+ * of cache levels for the cache node.
+ *
+ * Given a pptt resource, verify that it is a cache node, then walk
+ * down each level of caches, counting how many levels are found
+ * as well as checking the cache type (icache, dcache, unified). If a
+ * level & type match, then we set found, and continue the search.
+ * Once the entire cache branch has been walked return its max
+ * depth.
+ *
+ * Return: The cache structure and the level we terminated with.
+ */
+static int acpi_pptt_walk_cache(struct acpi_table_header *table_hdr,
+ int local_level,
+ struct acpi_subtable_header *res,
+ struct acpi_pptt_cache **found,
+ int level, int type)
+{
+ struct acpi_pptt_cache *cache;
+
+ if (res->type != ACPI_PPTT_TYPE_CACHE)
+ return 0;
+
+ cache = (struct acpi_pptt_cache *) res;
+ while (cache) {
+ local_level++;
+
+ if (local_level == level &&
+ cache->flags & ACPI_PPTT_CACHE_TYPE_VALID &&
+ acpi_pptt_match_type(cache->attributes, type)) {
+ if (*found != NULL && cache != *found)
+ pr_warn("Found duplicate cache level/type unable to determine uniqueness\n");
+
+ pr_debug("Found cache @ level %d\n", level);
+ *found = cache;
+ /*
+ * continue looking at this node's resource list
+ * to verify that we don't find a duplicate
+ * cache node.
+ */
+ }
+ cache = fetch_pptt_cache(table_hdr, cache->next_level_of_cache);
+ }
+ return local_level;
+}
+
+static struct acpi_pptt_cache *acpi_find_cache_level(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *cpu_node,
+ int *starting_level, int level,
+ int type)
+{
+ struct acpi_subtable_header *res;
+ int number_of_levels = *starting_level;
+ int resource = 0;
+ struct acpi_pptt_cache *ret = NULL;
+ int local_level;
+
+ /* walk down from processor node */
+ while ((res = acpi_get_pptt_resource(table_hdr, cpu_node, resource))) {
+ resource++;
+
+ local_level = acpi_pptt_walk_cache(table_hdr, *starting_level,
+ res, &ret, level, type);
+ /*
+ * we are looking for the max depth. Since its potentially
+ * possible for a given node to have resources with differing
+ * depths verify that the depth we have found is the largest.
+ */
+ if (number_of_levels < local_level)
+ number_of_levels = local_level;
+ }
+ if (number_of_levels > *starting_level)
+ *starting_level = number_of_levels;
+
+ return ret;
+}
+
+/**
+ * acpi_count_levels() - Given a PPTT table, and a cpu node, count the caches
+ * @table_hdr: Pointer to the head of the PPTT table
+ * @cpu_node: processor node we wish to count caches for
+ *
+ * Given a processor node containing a processing unit, walk into it and count
+ * how many levels exist solely for it, and then walk up each level until we hit
+ * the root node (ignore the package level because it may be possible to have
+ * caches that exist across packages). Count the number of cache levels that
+ * exist at each level on the way up.
+ *
+ * Return: Total number of levels found.
+ */
+static int acpi_count_levels(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *cpu_node)
+{
+ int total_levels = 0;
+
+ do {
+ acpi_find_cache_level(table_hdr, cpu_node, &total_levels, 0, 0);
+ cpu_node = fetch_pptt_node(table_hdr, cpu_node->parent);
+ } while (cpu_node);
+
+ return total_levels;
+}
+
+/**
+ * acpi_pptt_leaf_node() - Given a processor node, determine if its a leaf
+ * @table_hdr: Pointer to the head of the PPTT table
+ * @node: passed node is checked to see if its a leaf
+ *
+ * Determine if the *node parameter is a leaf node by iterating the
+ * PPTT table, looking for nodes which reference it.
+ *
+ * Return: 0 if we find a node referencing the passed node (or table error),
+ * or 1 if we don't.
+ */
+static int acpi_pptt_leaf_node(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *node)
+{
+ struct acpi_subtable_header *entry;
+ unsigned long table_end;
+ u32 node_entry;
+ struct acpi_pptt_processor *cpu_node;
+ u32 proc_sz;
+
+ table_end = (unsigned long)table_hdr + table_hdr->length;
+ node_entry = ACPI_PTR_DIFF(node, table_hdr);
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr,
+ sizeof(struct acpi_table_pptt));
+ proc_sz = sizeof(struct acpi_pptt_processor *);
+
+ while ((unsigned long)entry + proc_sz < table_end) {
+ cpu_node = (struct acpi_pptt_processor *)entry;
+ if (entry->type == ACPI_PPTT_TYPE_PROCESSOR &&
+ cpu_node->parent == node_entry)
+ return 0;
+ if (entry->length == 0)
+ return 0;
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, entry,
+ entry->length);
+
+ }
+ return 1;
+}
+
+/**
+ * acpi_find_processor_node() - Given a PPTT table find the requested processor
+ * @table_hdr: Pointer to the head of the PPTT table
+ * @acpi_cpu_id: cpu we are searching for
+ *
+ * Find the subtable entry describing the provided processor.
+ * This is done by iterating the PPTT table looking for processor nodes
+ * which have an acpi_processor_id that matches the acpi_cpu_id parameter
+ * passed into the function. If we find a node that matches this criteria
+ * we verify that its a leaf node in the topology rather than depending
+ * on the valid flag, which doesn't need to be set for leaf nodes.
+ *
+ * Return: NULL, or the processors acpi_pptt_processor*
+ */
+static struct acpi_pptt_processor *acpi_find_processor_node(struct acpi_table_header *table_hdr,
+ u32 acpi_cpu_id)
+{
+ struct acpi_subtable_header *entry;
+ unsigned long table_end;
+ struct acpi_pptt_processor *cpu_node;
+ u32 proc_sz;
+
+ table_end = (unsigned long)table_hdr + table_hdr->length;
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr,
+ sizeof(struct acpi_table_pptt));
+ proc_sz = sizeof(struct acpi_pptt_processor *);
+
+ /* find the processor structure associated with this cpuid */
+ while ((unsigned long)entry + proc_sz < table_end) {
+ cpu_node = (struct acpi_pptt_processor *)entry;
+
+ if (entry->length == 0) {
+ pr_warn("Invalid zero length subtable\n");
+ break;
+ }
+ if (entry->type == ACPI_PPTT_TYPE_PROCESSOR &&
+ acpi_cpu_id == cpu_node->acpi_processor_id &&
+ acpi_pptt_leaf_node(table_hdr, cpu_node)) {
+ return (struct acpi_pptt_processor *)entry;
+ }
+
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, entry,
+ entry->length);
+ }
+
+ return NULL;
+}
+
+static int acpi_find_cache_levels(struct acpi_table_header *table_hdr,
+ u32 acpi_cpu_id)
+{
+ int number_of_levels = 0;
+ struct acpi_pptt_processor *cpu;
+
+ cpu = acpi_find_processor_node(table_hdr, acpi_cpu_id);
+ if (cpu)
+ number_of_levels = acpi_count_levels(table_hdr, cpu);
+
+ return number_of_levels;
+}
+
+static u8 acpi_cache_type(enum cache_type type)
+{
+ switch (type) {
+ case CACHE_TYPE_DATA:
+ pr_debug("Looking for data cache\n");
+ return ACPI_PPTT_CACHE_TYPE_DATA;
+ case CACHE_TYPE_INST:
+ pr_debug("Looking for instruction cache\n");
+ return ACPI_PPTT_CACHE_TYPE_INSTR;
+ default:
+ case CACHE_TYPE_UNIFIED:
+ pr_debug("Looking for unified cache\n");
+ /*
+ * It is important that ACPI_PPTT_CACHE_TYPE_UNIFIED
+ * contains the bit pattern that will match both
+ * ACPI unified bit patterns because we use it later
+ * to match both cases.
+ */
+ return ACPI_PPTT_CACHE_TYPE_UNIFIED;
+ }
+}
+
+static struct acpi_pptt_cache *acpi_find_cache_node(struct acpi_table_header *table_hdr,
+ u32 acpi_cpu_id,
+ enum cache_type type,
+ unsigned int level,
+ struct acpi_pptt_processor **node)
+{
+ int total_levels = 0;
+ struct acpi_pptt_cache *found = NULL;
+ struct acpi_pptt_processor *cpu_node;
+ u8 acpi_type = acpi_cache_type(type);
+
+ pr_debug("Looking for CPU %d's level %d cache type %d\n",
+ acpi_cpu_id, level, acpi_type);
+
+ cpu_node = acpi_find_processor_node(table_hdr, acpi_cpu_id);
+
+ while (cpu_node && !found) {
+ found = acpi_find_cache_level(table_hdr, cpu_node,
+ &total_levels, level, acpi_type);
+ *node = cpu_node;
+ cpu_node = fetch_pptt_node(table_hdr, cpu_node->parent);
+ }
+
+ return found;
+}
+
+/* total number of attributes checked by the properties code */
+#define PPTT_CHECKED_ATTRIBUTES 4
+
+/**
+ * update_cache_properties() - Update cacheinfo for the given processor
+ * @this_leaf: Kernel cache info structure being updated
+ * @found_cache: The PPTT node describing this cache instance
+ * @cpu_node: A unique reference to describe this cache instance
+ *
+ * The ACPI spec implies that the fields in the cache structures are used to
+ * extend and correct the information probed from the hardware. Lets only
+ * set fields that we determine are VALID.
+ *
+ * Return: nothing. Side effect of updating the global cacheinfo
+ */
+static void update_cache_properties(struct cacheinfo *this_leaf,
+ struct acpi_pptt_cache *found_cache,
+ struct acpi_pptt_processor *cpu_node)
+{
+ int valid_flags = 0;
+
+ this_leaf->fw_token = cpu_node;
+ if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) {
+ this_leaf->size = found_cache->size;
+ valid_flags++;
+ }
+ if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) {
+ this_leaf->coherency_line_size = found_cache->line_size;
+ valid_flags++;
+ }
+ if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) {
+ this_leaf->number_of_sets = found_cache->number_of_sets;
+ valid_flags++;
+ }
+ if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) {
+ this_leaf->ways_of_associativity = found_cache->associativity;
+ valid_flags++;
+ }
+ if (found_cache->flags & ACPI_PPTT_WRITE_POLICY_VALID) {
+ switch (found_cache->attributes & ACPI_PPTT_MASK_WRITE_POLICY) {
+ case ACPI_PPTT_CACHE_POLICY_WT:
+ this_leaf->attributes = CACHE_WRITE_THROUGH;
+ break;
+ case ACPI_PPTT_CACHE_POLICY_WB:
+ this_leaf->attributes = CACHE_WRITE_BACK;
+ break;
+ }
+ }
+ if (found_cache->flags & ACPI_PPTT_ALLOCATION_TYPE_VALID) {
+ switch (found_cache->attributes & ACPI_PPTT_MASK_ALLOCATION_TYPE) {
+ case ACPI_PPTT_CACHE_READ_ALLOCATE:
+ this_leaf->attributes |= CACHE_READ_ALLOCATE;
+ break;
+ case ACPI_PPTT_CACHE_WRITE_ALLOCATE:
+ this_leaf->attributes |= CACHE_WRITE_ALLOCATE;
+ break;
+ case ACPI_PPTT_CACHE_RW_ALLOCATE:
+ case ACPI_PPTT_CACHE_RW_ALLOCATE_ALT:
+ this_leaf->attributes |=
+ CACHE_READ_ALLOCATE | CACHE_WRITE_ALLOCATE;
+ break;
+ }
+ }
+ /*
+ * If the above flags are valid, and the cache type is NOCACHE
+ * update the cache type as well.
+ */
+ if (this_leaf->type == CACHE_TYPE_NOCACHE &&
+ valid_flags == PPTT_CHECKED_ATTRIBUTES)
+ this_leaf->type = CACHE_TYPE_UNIFIED;
+}
+
+static void cache_setup_acpi_cpu(struct acpi_table_header *table,
+ unsigned int cpu)
+{
+ struct acpi_pptt_cache *found_cache;
+ struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
+ u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ struct cacheinfo *this_leaf;
+ unsigned int index = 0;
+ struct acpi_pptt_processor *cpu_node = NULL;
+
+ while (index < get_cpu_cacheinfo(cpu)->num_leaves) {
+ this_leaf = this_cpu_ci->info_list + index;
+ found_cache = acpi_find_cache_node(table, acpi_cpu_id,
+ this_leaf->type,
+ this_leaf->level,
+ &cpu_node);
+ pr_debug("found = %p %p\n", found_cache, cpu_node);
+ if (found_cache)
+ update_cache_properties(this_leaf,
+ found_cache,
+ cpu_node);
+
+ index++;
+ }
+}
+
+/* Passing level values greater than this will result in search termination */
+#define PPTT_ABORT_PACKAGE 0xFF
+
+static struct acpi_pptt_processor *acpi_find_processor_package_id(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *cpu,
+ int level, int flag)
+{
+ struct acpi_pptt_processor *prev_node;
+
+ while (cpu && level) {
+ if (cpu->flags & flag)
+ break;
+ pr_debug("level %d\n", level);
+ prev_node = fetch_pptt_node(table_hdr, cpu->parent);
+ if (prev_node == NULL)
+ break;
+ cpu = prev_node;
+ level--;
+ }
+ return cpu;
+}
+
+/**
+ * topology_get_acpi_cpu_tag() - Find a unique topology value for a feature
+ * @table: Pointer to the head of the PPTT table
+ * @cpu: Kernel logical cpu number
+ * @level: A level that terminates the search
+ * @flag: A flag which terminates the search
+ *
+ * Get a unique value given a cpu, and a topology level, that can be
+ * matched to determine which cpus share common topological features
+ * at that level.
+ *
+ * Return: Unique value, or -ENOENT if unable to locate cpu
+ */
+static int topology_get_acpi_cpu_tag(struct acpi_table_header *table,
+ unsigned int cpu, int level, int flag)
+{
+ struct acpi_pptt_processor *cpu_node;
+ u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+
+ cpu_node = acpi_find_processor_node(table, acpi_cpu_id);
+ if (cpu_node) {
+ cpu_node = acpi_find_processor_package_id(table, cpu_node,
+ level, flag);
+ /* Only the first level has a guaranteed id */
+ if (level == 0)
+ return cpu_node->acpi_processor_id;
+ return ACPI_PTR_DIFF(cpu_node, table);
+ }
+ pr_warn_once("PPTT table found, but unable to locate core %d (%d)\n",
+ cpu, acpi_cpu_id);
+ return -ENOENT;
+}
+
+static int find_acpi_cpu_topology_tag(unsigned int cpu, int level, int flag)
+{
+ struct acpi_table_header *table;
+ acpi_status status;
+ int retval;
+
+ status = acpi_get_table(ACPI_SIG_PPTT, 0, &table);
+ if (ACPI_FAILURE(status)) {
+ pr_warn_once("No PPTT table found, cpu topology may be inaccurate\n");
+ return -ENOENT;
+ }
+ retval = topology_get_acpi_cpu_tag(table, cpu, level, flag);
+ pr_debug("Topology Setup ACPI cpu %d, level %d ret = %d\n",
+ cpu, level, retval);
+ acpi_put_table(table);
+
+ return retval;
+}
+
+/**
+ * acpi_find_last_cache_level() - Determines the number of cache levels for a PE
+ * @cpu: Kernel logical cpu number
+ *
+ * Given a logical cpu number, returns the number of levels of cache represented
+ * in the PPTT. Errors caused by lack of a PPTT table, or otherwise, return 0
+ * indicating we didn't find any cache levels.
+ *
+ * Return: Cache levels visible to this core.
+ */
+int acpi_find_last_cache_level(unsigned int cpu)
+{
+ u32 acpi_cpu_id;
+ struct acpi_table_header *table;
+ int number_of_levels = 0;
+ acpi_status status;
+
+ pr_debug("Cache Setup find last level cpu=%d\n", cpu);
+
+ acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ status = acpi_get_table(ACPI_SIG_PPTT, 0, &table);
+ if (ACPI_FAILURE(status)) {
+ pr_warn_once("No PPTT table found, cache topology may be inaccurate\n");
+ } else {
+ number_of_levels = acpi_find_cache_levels(table, acpi_cpu_id);
+ acpi_put_table(table);
+ }
+ pr_debug("Cache Setup find last level level=%d\n", number_of_levels);
+
+ return number_of_levels;
+}
+
+/**
+ * cache_setup_acpi() - Override CPU cache topology with data from the PPTT
+ * @cpu: Kernel logical cpu number
+ *
+ * Updates the global cache info provided by cpu_get_cacheinfo()
+ * when there are valid properties in the acpi_pptt_cache nodes. A
+ * successful parse may not result in any updates if none of the
+ * cache levels have any valid flags set. Futher, a unique value is
+ * associated with each known CPU cache entry. This unique value
+ * can be used to determine whether caches are shared between cpus.
+ *
+ * Return: -ENOENT on failure to find table, or 0 on success
+ */
+int cache_setup_acpi(unsigned int cpu)
+{
+ struct acpi_table_header *table;
+ acpi_status status;
+
+ pr_debug("Cache Setup ACPI cpu %d\n", cpu);
+
+ status = acpi_get_table(ACPI_SIG_PPTT, 0, &table);
+ if (ACPI_FAILURE(status)) {
+ pr_warn_once("No PPTT table found, cache topology may be inaccurate\n");
+ return -ENOENT;
+ }
+
+ cache_setup_acpi_cpu(table, cpu);
+ acpi_put_table(table);
+
+ return status;
+}
+
+/**
+ * find_acpi_cpu_topology() - Determine a unique topology value for a given cpu
+ * @cpu: Kernel logical cpu number
+ * @level: The topological level for which we would like a unique ID
+ *
+ * Determine a topology unique ID for each thread/core/cluster/mc_grouping
+ * /socket/etc. This ID can then be used to group peers, which will have
+ * matching ids.
+ *
+ * The search terminates when either the requested level is found or
+ * we reach a root node. Levels beyond the termination point will return the
+ * same unique ID. The unique id for level 0 is the acpi processor id. All
+ * other levels beyond this use a generated value to uniquely identify
+ * a topological feature.
+ *
+ * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found.
+ * Otherwise returns a value which represents a unique topological feature.
+ */
+int find_acpi_cpu_topology(unsigned int cpu, int level)
+{
+ return find_acpi_cpu_topology_tag(cpu, level, 0);
+}
+
+/**
+ * find_acpi_cpu_cache_topology() - Determine a unique cache topology value
+ * @cpu: Kernel logical cpu number
+ * @level: The cache level for which we would like a unique ID
+ *
+ * Determine a unique ID for each unified cache in the system
+ *
+ * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found.
+ * Otherwise returns a value which represents a unique topological feature.
+ */
+int find_acpi_cpu_cache_topology(unsigned int cpu, int level)
+{
+ struct acpi_table_header *table;
+ struct acpi_pptt_cache *found_cache;
+ acpi_status status;
+ u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ struct acpi_pptt_processor *cpu_node = NULL;
+ int ret = -1;
+
+ status = acpi_get_table(ACPI_SIG_PPTT, 0, &table);
+ if (ACPI_FAILURE(status)) {
+ pr_warn_once("No PPTT table found, topology may be inaccurate\n");
+ return -ENOENT;
+ }
+
+ found_cache = acpi_find_cache_node(table, acpi_cpu_id,
+ CACHE_TYPE_UNIFIED,
+ level,
+ &cpu_node);
+ if (found_cache)
+ ret = ACPI_PTR_DIFF(cpu_node, table);
+
+ acpi_put_table(table);
+
+ return ret;
+}
+
+
+/**
+ * find_acpi_cpu_topology_package() - Determine a unique cpu package value
+ * @cpu: Kernel logical cpu number
+ *
+ * Determine a topology unique package ID for the given cpu.
+ * This ID can then be used to group peers, which will have matching ids.
+ *
+ * The search terminates when either a level is found with the PHYSICAL_PACKAGE
+ * flag set or we reach a root node.
+ *
+ * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found.
+ * Otherwise returns a value which represents the package for this cpu.
+ */
+int find_acpi_cpu_topology_package(unsigned int cpu)
+{
+ return find_acpi_cpu_topology_tag(cpu, PPTT_ABORT_PACKAGE,
+ ACPI_PPTT_PHYSICAL_PACKAGE);
+}
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 15bfb15c2fa5..032e12a2fdc2 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1297,4 +1297,8 @@ static inline int lpit_read_residency_count_address(u64 *address)
}
#endif
+int find_acpi_cpu_topology(unsigned int cpu, int level);
+int find_acpi_cpu_topology_package(unsigned int cpu);
+int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
+
#endif /*_LINUX_ACPI_H*/
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-arm-kernel
ACPI 6.2 adds a new table, which describes how processing units
are related to each other in tree like fashion. Caches are
also sprinkled throughout the tree and describe the properties
of the caches in relation to other caches and processing units.
Add the code to parse the cache hierarchy and report the total
number of levels of cache for a given core using
acpi_find_last_cache_level() as well as fill out the individual
cores cache information with cache_setup_acpi() once the
cpu_cacheinfo structure has been populated by the arch specific
code.
An additional patch later in the set adds the ability to report
peers in the topology using find_acpi_cpu_topology()
to report a unique ID for each processing unit at a given level
in the tree. These unique id's can then be used to match related
processing units which exist as threads, within a given
package, etc.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/acpi/pptt.c | 655 +++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/acpi.h | 4 +
2 files changed, 659 insertions(+)
create mode 100644 drivers/acpi/pptt.c
diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
new file mode 100644
index 000000000000..e5ea1974d1e3
--- /dev/null
+++ b/drivers/acpi/pptt.c
@@ -0,0 +1,655 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * pptt.c - parsing of Processor Properties Topology Table (PPTT)
+ *
+ * Copyright (C) 2018, ARM
+ *
+ * This file implements parsing of the Processor Properties Topology Table
+ * which is optionally used to describe the processor and cache topology.
+ * Due to the relative pointers used throughout the table, this doesn't
+ * leverage the existing subtable parsing in the kernel.
+ *
+ * The PPTT structure is an inverted tree, with each node potentially
+ * holding one or two inverted tree data structures describing
+ * the caches available at that level. Each cache structure optionally
+ * contains properties describing the cache at a given level which can be
+ * used to override hardware probed values.
+ */
+#define pr_fmt(fmt) "ACPI PPTT: " fmt
+
+#include <linux/acpi.h>
+#include <linux/cacheinfo.h>
+#include <acpi/processor.h>
+
+static struct acpi_subtable_header *fetch_pptt_subtable(struct acpi_table_header *table_hdr,
+ u32 pptt_ref)
+{
+ struct acpi_subtable_header *entry;
+
+ /* there isn't a subtable at reference 0 */
+ if (pptt_ref < sizeof(struct acpi_subtable_header))
+ return NULL;
+
+ if (pptt_ref + sizeof(struct acpi_subtable_header) > table_hdr->length)
+ return NULL;
+
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, pptt_ref);
+
+ if (entry->length == 0)
+ return NULL;
+
+ if (pptt_ref + entry->length > table_hdr->length)
+ return NULL;
+
+ return entry;
+}
+
+static struct acpi_pptt_processor *fetch_pptt_node(struct acpi_table_header *table_hdr,
+ u32 pptt_ref)
+{
+ return (struct acpi_pptt_processor *)fetch_pptt_subtable(table_hdr, pptt_ref);
+}
+
+static struct acpi_pptt_cache *fetch_pptt_cache(struct acpi_table_header *table_hdr,
+ u32 pptt_ref)
+{
+ return (struct acpi_pptt_cache *)fetch_pptt_subtable(table_hdr, pptt_ref);
+}
+
+static struct acpi_subtable_header *acpi_get_pptt_resource(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *node,
+ int resource)
+{
+ u32 *ref;
+
+ if (resource >= node->number_of_priv_resources)
+ return NULL;
+
+ ref = ACPI_ADD_PTR(u32, node, sizeof(struct acpi_pptt_processor));
+ ref += resource;
+
+ return fetch_pptt_subtable(table_hdr, *ref);
+}
+
+static inline bool acpi_pptt_match_type(int table_type, int type)
+{
+ return ((table_type & ACPI_PPTT_MASK_CACHE_TYPE) == type ||
+ table_type & ACPI_PPTT_CACHE_TYPE_UNIFIED & type);
+}
+
+/**
+ * acpi_pptt_walk_cache() - Attempt to find the requested acpi_pptt_cache
+ * @table_hdr: Pointer to the head of the PPTT table
+ * @local_level: passed res reflects this cache level
+ * @res: cache resource in the PPTT we want to walk
+ * @found: returns a pointer to the requested level if found
+ * @level: the requested cache level
+ * @type: the requested cache type
+ *
+ * Attempt to find a given cache level, while counting the max number
+ * of cache levels for the cache node.
+ *
+ * Given a pptt resource, verify that it is a cache node, then walk
+ * down each level of caches, counting how many levels are found
+ * as well as checking the cache type (icache, dcache, unified). If a
+ * level & type match, then we set found, and continue the search.
+ * Once the entire cache branch has been walked return its max
+ * depth.
+ *
+ * Return: The cache structure and the level we terminated with.
+ */
+static int acpi_pptt_walk_cache(struct acpi_table_header *table_hdr,
+ int local_level,
+ struct acpi_subtable_header *res,
+ struct acpi_pptt_cache **found,
+ int level, int type)
+{
+ struct acpi_pptt_cache *cache;
+
+ if (res->type != ACPI_PPTT_TYPE_CACHE)
+ return 0;
+
+ cache = (struct acpi_pptt_cache *) res;
+ while (cache) {
+ local_level++;
+
+ if (local_level == level &&
+ cache->flags & ACPI_PPTT_CACHE_TYPE_VALID &&
+ acpi_pptt_match_type(cache->attributes, type)) {
+ if (*found != NULL && cache != *found)
+ pr_warn("Found duplicate cache level/type unable to determine uniqueness\n");
+
+ pr_debug("Found cache @ level %d\n", level);
+ *found = cache;
+ /*
+ * continue looking at this node's resource list
+ * to verify that we don't find a duplicate
+ * cache node.
+ */
+ }
+ cache = fetch_pptt_cache(table_hdr, cache->next_level_of_cache);
+ }
+ return local_level;
+}
+
+static struct acpi_pptt_cache *acpi_find_cache_level(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *cpu_node,
+ int *starting_level, int level,
+ int type)
+{
+ struct acpi_subtable_header *res;
+ int number_of_levels = *starting_level;
+ int resource = 0;
+ struct acpi_pptt_cache *ret = NULL;
+ int local_level;
+
+ /* walk down from processor node */
+ while ((res = acpi_get_pptt_resource(table_hdr, cpu_node, resource))) {
+ resource++;
+
+ local_level = acpi_pptt_walk_cache(table_hdr, *starting_level,
+ res, &ret, level, type);
+ /*
+ * we are looking for the max depth. Since its potentially
+ * possible for a given node to have resources with differing
+ * depths verify that the depth we have found is the largest.
+ */
+ if (number_of_levels < local_level)
+ number_of_levels = local_level;
+ }
+ if (number_of_levels > *starting_level)
+ *starting_level = number_of_levels;
+
+ return ret;
+}
+
+/**
+ * acpi_count_levels() - Given a PPTT table, and a cpu node, count the caches
+ * @table_hdr: Pointer to the head of the PPTT table
+ * @cpu_node: processor node we wish to count caches for
+ *
+ * Given a processor node containing a processing unit, walk into it and count
+ * how many levels exist solely for it, and then walk up each level until we hit
+ * the root node (ignore the package level because it may be possible to have
+ * caches that exist across packages). Count the number of cache levels that
+ * exist at each level on the way up.
+ *
+ * Return: Total number of levels found.
+ */
+static int acpi_count_levels(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *cpu_node)
+{
+ int total_levels = 0;
+
+ do {
+ acpi_find_cache_level(table_hdr, cpu_node, &total_levels, 0, 0);
+ cpu_node = fetch_pptt_node(table_hdr, cpu_node->parent);
+ } while (cpu_node);
+
+ return total_levels;
+}
+
+/**
+ * acpi_pptt_leaf_node() - Given a processor node, determine if its a leaf
+ * @table_hdr: Pointer to the head of the PPTT table
+ * @node: passed node is checked to see if its a leaf
+ *
+ * Determine if the *node parameter is a leaf node by iterating the
+ * PPTT table, looking for nodes which reference it.
+ *
+ * Return: 0 if we find a node referencing the passed node (or table error),
+ * or 1 if we don't.
+ */
+static int acpi_pptt_leaf_node(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *node)
+{
+ struct acpi_subtable_header *entry;
+ unsigned long table_end;
+ u32 node_entry;
+ struct acpi_pptt_processor *cpu_node;
+ u32 proc_sz;
+
+ table_end = (unsigned long)table_hdr + table_hdr->length;
+ node_entry = ACPI_PTR_DIFF(node, table_hdr);
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr,
+ sizeof(struct acpi_table_pptt));
+ proc_sz = sizeof(struct acpi_pptt_processor *);
+
+ while ((unsigned long)entry + proc_sz < table_end) {
+ cpu_node = (struct acpi_pptt_processor *)entry;
+ if (entry->type == ACPI_PPTT_TYPE_PROCESSOR &&
+ cpu_node->parent == node_entry)
+ return 0;
+ if (entry->length == 0)
+ return 0;
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, entry,
+ entry->length);
+
+ }
+ return 1;
+}
+
+/**
+ * acpi_find_processor_node() - Given a PPTT table find the requested processor
+ * @table_hdr: Pointer to the head of the PPTT table
+ * @acpi_cpu_id: cpu we are searching for
+ *
+ * Find the subtable entry describing the provided processor.
+ * This is done by iterating the PPTT table looking for processor nodes
+ * which have an acpi_processor_id that matches the acpi_cpu_id parameter
+ * passed into the function. If we find a node that matches this criteria
+ * we verify that its a leaf node in the topology rather than depending
+ * on the valid flag, which doesn't need to be set for leaf nodes.
+ *
+ * Return: NULL, or the processors acpi_pptt_processor*
+ */
+static struct acpi_pptt_processor *acpi_find_processor_node(struct acpi_table_header *table_hdr,
+ u32 acpi_cpu_id)
+{
+ struct acpi_subtable_header *entry;
+ unsigned long table_end;
+ struct acpi_pptt_processor *cpu_node;
+ u32 proc_sz;
+
+ table_end = (unsigned long)table_hdr + table_hdr->length;
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr,
+ sizeof(struct acpi_table_pptt));
+ proc_sz = sizeof(struct acpi_pptt_processor *);
+
+ /* find the processor structure associated with this cpuid */
+ while ((unsigned long)entry + proc_sz < table_end) {
+ cpu_node = (struct acpi_pptt_processor *)entry;
+
+ if (entry->length == 0) {
+ pr_warn("Invalid zero length subtable\n");
+ break;
+ }
+ if (entry->type == ACPI_PPTT_TYPE_PROCESSOR &&
+ acpi_cpu_id == cpu_node->acpi_processor_id &&
+ acpi_pptt_leaf_node(table_hdr, cpu_node)) {
+ return (struct acpi_pptt_processor *)entry;
+ }
+
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, entry,
+ entry->length);
+ }
+
+ return NULL;
+}
+
+static int acpi_find_cache_levels(struct acpi_table_header *table_hdr,
+ u32 acpi_cpu_id)
+{
+ int number_of_levels = 0;
+ struct acpi_pptt_processor *cpu;
+
+ cpu = acpi_find_processor_node(table_hdr, acpi_cpu_id);
+ if (cpu)
+ number_of_levels = acpi_count_levels(table_hdr, cpu);
+
+ return number_of_levels;
+}
+
+static u8 acpi_cache_type(enum cache_type type)
+{
+ switch (type) {
+ case CACHE_TYPE_DATA:
+ pr_debug("Looking for data cache\n");
+ return ACPI_PPTT_CACHE_TYPE_DATA;
+ case CACHE_TYPE_INST:
+ pr_debug("Looking for instruction cache\n");
+ return ACPI_PPTT_CACHE_TYPE_INSTR;
+ default:
+ case CACHE_TYPE_UNIFIED:
+ pr_debug("Looking for unified cache\n");
+ /*
+ * It is important that ACPI_PPTT_CACHE_TYPE_UNIFIED
+ * contains the bit pattern that will match both
+ * ACPI unified bit patterns because we use it later
+ * to match both cases.
+ */
+ return ACPI_PPTT_CACHE_TYPE_UNIFIED;
+ }
+}
+
+static struct acpi_pptt_cache *acpi_find_cache_node(struct acpi_table_header *table_hdr,
+ u32 acpi_cpu_id,
+ enum cache_type type,
+ unsigned int level,
+ struct acpi_pptt_processor **node)
+{
+ int total_levels = 0;
+ struct acpi_pptt_cache *found = NULL;
+ struct acpi_pptt_processor *cpu_node;
+ u8 acpi_type = acpi_cache_type(type);
+
+ pr_debug("Looking for CPU %d's level %d cache type %d\n",
+ acpi_cpu_id, level, acpi_type);
+
+ cpu_node = acpi_find_processor_node(table_hdr, acpi_cpu_id);
+
+ while (cpu_node && !found) {
+ found = acpi_find_cache_level(table_hdr, cpu_node,
+ &total_levels, level, acpi_type);
+ *node = cpu_node;
+ cpu_node = fetch_pptt_node(table_hdr, cpu_node->parent);
+ }
+
+ return found;
+}
+
+/* total number of attributes checked by the properties code */
+#define PPTT_CHECKED_ATTRIBUTES 4
+
+/**
+ * update_cache_properties() - Update cacheinfo for the given processor
+ * @this_leaf: Kernel cache info structure being updated
+ * @found_cache: The PPTT node describing this cache instance
+ * @cpu_node: A unique reference to describe this cache instance
+ *
+ * The ACPI spec implies that the fields in the cache structures are used to
+ * extend and correct the information probed from the hardware. Lets only
+ * set fields that we determine are VALID.
+ *
+ * Return: nothing. Side effect of updating the global cacheinfo
+ */
+static void update_cache_properties(struct cacheinfo *this_leaf,
+ struct acpi_pptt_cache *found_cache,
+ struct acpi_pptt_processor *cpu_node)
+{
+ int valid_flags = 0;
+
+ this_leaf->fw_token = cpu_node;
+ if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) {
+ this_leaf->size = found_cache->size;
+ valid_flags++;
+ }
+ if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) {
+ this_leaf->coherency_line_size = found_cache->line_size;
+ valid_flags++;
+ }
+ if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) {
+ this_leaf->number_of_sets = found_cache->number_of_sets;
+ valid_flags++;
+ }
+ if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) {
+ this_leaf->ways_of_associativity = found_cache->associativity;
+ valid_flags++;
+ }
+ if (found_cache->flags & ACPI_PPTT_WRITE_POLICY_VALID) {
+ switch (found_cache->attributes & ACPI_PPTT_MASK_WRITE_POLICY) {
+ case ACPI_PPTT_CACHE_POLICY_WT:
+ this_leaf->attributes = CACHE_WRITE_THROUGH;
+ break;
+ case ACPI_PPTT_CACHE_POLICY_WB:
+ this_leaf->attributes = CACHE_WRITE_BACK;
+ break;
+ }
+ }
+ if (found_cache->flags & ACPI_PPTT_ALLOCATION_TYPE_VALID) {
+ switch (found_cache->attributes & ACPI_PPTT_MASK_ALLOCATION_TYPE) {
+ case ACPI_PPTT_CACHE_READ_ALLOCATE:
+ this_leaf->attributes |= CACHE_READ_ALLOCATE;
+ break;
+ case ACPI_PPTT_CACHE_WRITE_ALLOCATE:
+ this_leaf->attributes |= CACHE_WRITE_ALLOCATE;
+ break;
+ case ACPI_PPTT_CACHE_RW_ALLOCATE:
+ case ACPI_PPTT_CACHE_RW_ALLOCATE_ALT:
+ this_leaf->attributes |=
+ CACHE_READ_ALLOCATE | CACHE_WRITE_ALLOCATE;
+ break;
+ }
+ }
+ /*
+ * If the above flags are valid, and the cache type is NOCACHE
+ * update the cache type as well.
+ */
+ if (this_leaf->type == CACHE_TYPE_NOCACHE &&
+ valid_flags == PPTT_CHECKED_ATTRIBUTES)
+ this_leaf->type = CACHE_TYPE_UNIFIED;
+}
+
+static void cache_setup_acpi_cpu(struct acpi_table_header *table,
+ unsigned int cpu)
+{
+ struct acpi_pptt_cache *found_cache;
+ struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
+ u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ struct cacheinfo *this_leaf;
+ unsigned int index = 0;
+ struct acpi_pptt_processor *cpu_node = NULL;
+
+ while (index < get_cpu_cacheinfo(cpu)->num_leaves) {
+ this_leaf = this_cpu_ci->info_list + index;
+ found_cache = acpi_find_cache_node(table, acpi_cpu_id,
+ this_leaf->type,
+ this_leaf->level,
+ &cpu_node);
+ pr_debug("found = %p %p\n", found_cache, cpu_node);
+ if (found_cache)
+ update_cache_properties(this_leaf,
+ found_cache,
+ cpu_node);
+
+ index++;
+ }
+}
+
+/* Passing level values greater than this will result in search termination */
+#define PPTT_ABORT_PACKAGE 0xFF
+
+static struct acpi_pptt_processor *acpi_find_processor_package_id(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *cpu,
+ int level, int flag)
+{
+ struct acpi_pptt_processor *prev_node;
+
+ while (cpu && level) {
+ if (cpu->flags & flag)
+ break;
+ pr_debug("level %d\n", level);
+ prev_node = fetch_pptt_node(table_hdr, cpu->parent);
+ if (prev_node == NULL)
+ break;
+ cpu = prev_node;
+ level--;
+ }
+ return cpu;
+}
+
+/**
+ * topology_get_acpi_cpu_tag() - Find a unique topology value for a feature
+ * @table: Pointer to the head of the PPTT table
+ * @cpu: Kernel logical cpu number
+ * @level: A level that terminates the search
+ * @flag: A flag which terminates the search
+ *
+ * Get a unique value given a cpu, and a topology level, that can be
+ * matched to determine which cpus share common topological features
+ * at that level.
+ *
+ * Return: Unique value, or -ENOENT if unable to locate cpu
+ */
+static int topology_get_acpi_cpu_tag(struct acpi_table_header *table,
+ unsigned int cpu, int level, int flag)
+{
+ struct acpi_pptt_processor *cpu_node;
+ u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+
+ cpu_node = acpi_find_processor_node(table, acpi_cpu_id);
+ if (cpu_node) {
+ cpu_node = acpi_find_processor_package_id(table, cpu_node,
+ level, flag);
+ /* Only the first level has a guaranteed id */
+ if (level == 0)
+ return cpu_node->acpi_processor_id;
+ return ACPI_PTR_DIFF(cpu_node, table);
+ }
+ pr_warn_once("PPTT table found, but unable to locate core %d (%d)\n",
+ cpu, acpi_cpu_id);
+ return -ENOENT;
+}
+
+static int find_acpi_cpu_topology_tag(unsigned int cpu, int level, int flag)
+{
+ struct acpi_table_header *table;
+ acpi_status status;
+ int retval;
+
+ status = acpi_get_table(ACPI_SIG_PPTT, 0, &table);
+ if (ACPI_FAILURE(status)) {
+ pr_warn_once("No PPTT table found, cpu topology may be inaccurate\n");
+ return -ENOENT;
+ }
+ retval = topology_get_acpi_cpu_tag(table, cpu, level, flag);
+ pr_debug("Topology Setup ACPI cpu %d, level %d ret = %d\n",
+ cpu, level, retval);
+ acpi_put_table(table);
+
+ return retval;
+}
+
+/**
+ * acpi_find_last_cache_level() - Determines the number of cache levels for a PE
+ * @cpu: Kernel logical cpu number
+ *
+ * Given a logical cpu number, returns the number of levels of cache represented
+ * in the PPTT. Errors caused by lack of a PPTT table, or otherwise, return 0
+ * indicating we didn't find any cache levels.
+ *
+ * Return: Cache levels visible to this core.
+ */
+int acpi_find_last_cache_level(unsigned int cpu)
+{
+ u32 acpi_cpu_id;
+ struct acpi_table_header *table;
+ int number_of_levels = 0;
+ acpi_status status;
+
+ pr_debug("Cache Setup find last level cpu=%d\n", cpu);
+
+ acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ status = acpi_get_table(ACPI_SIG_PPTT, 0, &table);
+ if (ACPI_FAILURE(status)) {
+ pr_warn_once("No PPTT table found, cache topology may be inaccurate\n");
+ } else {
+ number_of_levels = acpi_find_cache_levels(table, acpi_cpu_id);
+ acpi_put_table(table);
+ }
+ pr_debug("Cache Setup find last level level=%d\n", number_of_levels);
+
+ return number_of_levels;
+}
+
+/**
+ * cache_setup_acpi() - Override CPU cache topology with data from the PPTT
+ * @cpu: Kernel logical cpu number
+ *
+ * Updates the global cache info provided by cpu_get_cacheinfo()
+ * when there are valid properties in the acpi_pptt_cache nodes. A
+ * successful parse may not result in any updates if none of the
+ * cache levels have any valid flags set. Futher, a unique value is
+ * associated with each known CPU cache entry. This unique value
+ * can be used to determine whether caches are shared between cpus.
+ *
+ * Return: -ENOENT on failure to find table, or 0 on success
+ */
+int cache_setup_acpi(unsigned int cpu)
+{
+ struct acpi_table_header *table;
+ acpi_status status;
+
+ pr_debug("Cache Setup ACPI cpu %d\n", cpu);
+
+ status = acpi_get_table(ACPI_SIG_PPTT, 0, &table);
+ if (ACPI_FAILURE(status)) {
+ pr_warn_once("No PPTT table found, cache topology may be inaccurate\n");
+ return -ENOENT;
+ }
+
+ cache_setup_acpi_cpu(table, cpu);
+ acpi_put_table(table);
+
+ return status;
+}
+
+/**
+ * find_acpi_cpu_topology() - Determine a unique topology value for a given cpu
+ * @cpu: Kernel logical cpu number
+ * @level: The topological level for which we would like a unique ID
+ *
+ * Determine a topology unique ID for each thread/core/cluster/mc_grouping
+ * /socket/etc. This ID can then be used to group peers, which will have
+ * matching ids.
+ *
+ * The search terminates when either the requested level is found or
+ * we reach a root node. Levels beyond the termination point will return the
+ * same unique ID. The unique id for level 0 is the acpi processor id. All
+ * other levels beyond this use a generated value to uniquely identify
+ * a topological feature.
+ *
+ * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found.
+ * Otherwise returns a value which represents a unique topological feature.
+ */
+int find_acpi_cpu_topology(unsigned int cpu, int level)
+{
+ return find_acpi_cpu_topology_tag(cpu, level, 0);
+}
+
+/**
+ * find_acpi_cpu_cache_topology() - Determine a unique cache topology value
+ * @cpu: Kernel logical cpu number
+ * @level: The cache level for which we would like a unique ID
+ *
+ * Determine a unique ID for each unified cache in the system
+ *
+ * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found.
+ * Otherwise returns a value which represents a unique topological feature.
+ */
+int find_acpi_cpu_cache_topology(unsigned int cpu, int level)
+{
+ struct acpi_table_header *table;
+ struct acpi_pptt_cache *found_cache;
+ acpi_status status;
+ u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ struct acpi_pptt_processor *cpu_node = NULL;
+ int ret = -1;
+
+ status = acpi_get_table(ACPI_SIG_PPTT, 0, &table);
+ if (ACPI_FAILURE(status)) {
+ pr_warn_once("No PPTT table found, topology may be inaccurate\n");
+ return -ENOENT;
+ }
+
+ found_cache = acpi_find_cache_node(table, acpi_cpu_id,
+ CACHE_TYPE_UNIFIED,
+ level,
+ &cpu_node);
+ if (found_cache)
+ ret = ACPI_PTR_DIFF(cpu_node, table);
+
+ acpi_put_table(table);
+
+ return ret;
+}
+
+
+/**
+ * find_acpi_cpu_topology_package() - Determine a unique cpu package value
+ * @cpu: Kernel logical cpu number
+ *
+ * Determine a topology unique package ID for the given cpu.
+ * This ID can then be used to group peers, which will have matching ids.
+ *
+ * The search terminates when either a level is found with the PHYSICAL_PACKAGE
+ * flag set or we reach a root node.
+ *
+ * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found.
+ * Otherwise returns a value which represents the package for this cpu.
+ */
+int find_acpi_cpu_topology_package(unsigned int cpu)
+{
+ return find_acpi_cpu_topology_tag(cpu, PPTT_ABORT_PACKAGE,
+ ACPI_PPTT_PHYSICAL_PACKAGE);
+}
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 15bfb15c2fa5..032e12a2fdc2 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1297,4 +1297,8 @@ static inline int lpit_read_residency_count_address(u64 *address)
}
#endif
+int find_acpi_cpu_topology(unsigned int cpu, int level);
+int find_acpi_cpu_topology_package(unsigned int cpu);
+int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
+
#endif /*_LINUX_ACPI_H*/
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-riscv
ACPI 6.2 adds a new table, which describes how processing units
are related to each other in tree like fashion. Caches are
also sprinkled throughout the tree and describe the properties
of the caches in relation to other caches and processing units.
Add the code to parse the cache hierarchy and report the total
number of levels of cache for a given core using
acpi_find_last_cache_level() as well as fill out the individual
cores cache information with cache_setup_acpi() once the
cpu_cacheinfo structure has been populated by the arch specific
code.
An additional patch later in the set adds the ability to report
peers in the topology using find_acpi_cpu_topology()
to report a unique ID for each processing unit at a given level
in the tree. These unique id's can then be used to match related
processing units which exist as threads, within a given
package, etc.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/acpi/pptt.c | 655 +++++++++++++++++++++++++++++++++++++++++++++++++++
include/linux/acpi.h | 4 +
2 files changed, 659 insertions(+)
create mode 100644 drivers/acpi/pptt.c
diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
new file mode 100644
index 000000000000..e5ea1974d1e3
--- /dev/null
+++ b/drivers/acpi/pptt.c
@@ -0,0 +1,655 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * pptt.c - parsing of Processor Properties Topology Table (PPTT)
+ *
+ * Copyright (C) 2018, ARM
+ *
+ * This file implements parsing of the Processor Properties Topology Table
+ * which is optionally used to describe the processor and cache topology.
+ * Due to the relative pointers used throughout the table, this doesn't
+ * leverage the existing subtable parsing in the kernel.
+ *
+ * The PPTT structure is an inverted tree, with each node potentially
+ * holding one or two inverted tree data structures describing
+ * the caches available at that level. Each cache structure optionally
+ * contains properties describing the cache at a given level which can be
+ * used to override hardware probed values.
+ */
+#define pr_fmt(fmt) "ACPI PPTT: " fmt
+
+#include <linux/acpi.h>
+#include <linux/cacheinfo.h>
+#include <acpi/processor.h>
+
+static struct acpi_subtable_header *fetch_pptt_subtable(struct acpi_table_header *table_hdr,
+ u32 pptt_ref)
+{
+ struct acpi_subtable_header *entry;
+
+ /* there isn't a subtable at reference 0 */
+ if (pptt_ref < sizeof(struct acpi_subtable_header))
+ return NULL;
+
+ if (pptt_ref + sizeof(struct acpi_subtable_header) > table_hdr->length)
+ return NULL;
+
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, pptt_ref);
+
+ if (entry->length == 0)
+ return NULL;
+
+ if (pptt_ref + entry->length > table_hdr->length)
+ return NULL;
+
+ return entry;
+}
+
+static struct acpi_pptt_processor *fetch_pptt_node(struct acpi_table_header *table_hdr,
+ u32 pptt_ref)
+{
+ return (struct acpi_pptt_processor *)fetch_pptt_subtable(table_hdr, pptt_ref);
+}
+
+static struct acpi_pptt_cache *fetch_pptt_cache(struct acpi_table_header *table_hdr,
+ u32 pptt_ref)
+{
+ return (struct acpi_pptt_cache *)fetch_pptt_subtable(table_hdr, pptt_ref);
+}
+
+static struct acpi_subtable_header *acpi_get_pptt_resource(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *node,
+ int resource)
+{
+ u32 *ref;
+
+ if (resource >= node->number_of_priv_resources)
+ return NULL;
+
+ ref = ACPI_ADD_PTR(u32, node, sizeof(struct acpi_pptt_processor));
+ ref += resource;
+
+ return fetch_pptt_subtable(table_hdr, *ref);
+}
+
+static inline bool acpi_pptt_match_type(int table_type, int type)
+{
+ return ((table_type & ACPI_PPTT_MASK_CACHE_TYPE) == type ||
+ table_type & ACPI_PPTT_CACHE_TYPE_UNIFIED & type);
+}
+
+/**
+ * acpi_pptt_walk_cache() - Attempt to find the requested acpi_pptt_cache
+ * @table_hdr: Pointer to the head of the PPTT table
+ * @local_level: passed res reflects this cache level
+ * @res: cache resource in the PPTT we want to walk
+ * @found: returns a pointer to the requested level if found
+ * @level: the requested cache level
+ * @type: the requested cache type
+ *
+ * Attempt to find a given cache level, while counting the max number
+ * of cache levels for the cache node.
+ *
+ * Given a pptt resource, verify that it is a cache node, then walk
+ * down each level of caches, counting how many levels are found
+ * as well as checking the cache type (icache, dcache, unified). If a
+ * level & type match, then we set found, and continue the search.
+ * Once the entire cache branch has been walked return its max
+ * depth.
+ *
+ * Return: The cache structure and the level we terminated with.
+ */
+static int acpi_pptt_walk_cache(struct acpi_table_header *table_hdr,
+ int local_level,
+ struct acpi_subtable_header *res,
+ struct acpi_pptt_cache **found,
+ int level, int type)
+{
+ struct acpi_pptt_cache *cache;
+
+ if (res->type != ACPI_PPTT_TYPE_CACHE)
+ return 0;
+
+ cache = (struct acpi_pptt_cache *) res;
+ while (cache) {
+ local_level++;
+
+ if (local_level == level &&
+ cache->flags & ACPI_PPTT_CACHE_TYPE_VALID &&
+ acpi_pptt_match_type(cache->attributes, type)) {
+ if (*found != NULL && cache != *found)
+ pr_warn("Found duplicate cache level/type unable to determine uniqueness\n");
+
+ pr_debug("Found cache @ level %d\n", level);
+ *found = cache;
+ /*
+ * continue looking at this node's resource list
+ * to verify that we don't find a duplicate
+ * cache node.
+ */
+ }
+ cache = fetch_pptt_cache(table_hdr, cache->next_level_of_cache);
+ }
+ return local_level;
+}
+
+static struct acpi_pptt_cache *acpi_find_cache_level(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *cpu_node,
+ int *starting_level, int level,
+ int type)
+{
+ struct acpi_subtable_header *res;
+ int number_of_levels = *starting_level;
+ int resource = 0;
+ struct acpi_pptt_cache *ret = NULL;
+ int local_level;
+
+ /* walk down from processor node */
+ while ((res = acpi_get_pptt_resource(table_hdr, cpu_node, resource))) {
+ resource++;
+
+ local_level = acpi_pptt_walk_cache(table_hdr, *starting_level,
+ res, &ret, level, type);
+ /*
+ * we are looking for the max depth. Since its potentially
+ * possible for a given node to have resources with differing
+ * depths verify that the depth we have found is the largest.
+ */
+ if (number_of_levels < local_level)
+ number_of_levels = local_level;
+ }
+ if (number_of_levels > *starting_level)
+ *starting_level = number_of_levels;
+
+ return ret;
+}
+
+/**
+ * acpi_count_levels() - Given a PPTT table, and a cpu node, count the caches
+ * @table_hdr: Pointer to the head of the PPTT table
+ * @cpu_node: processor node we wish to count caches for
+ *
+ * Given a processor node containing a processing unit, walk into it and count
+ * how many levels exist solely for it, and then walk up each level until we hit
+ * the root node (ignore the package level because it may be possible to have
+ * caches that exist across packages). Count the number of cache levels that
+ * exist at each level on the way up.
+ *
+ * Return: Total number of levels found.
+ */
+static int acpi_count_levels(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *cpu_node)
+{
+ int total_levels = 0;
+
+ do {
+ acpi_find_cache_level(table_hdr, cpu_node, &total_levels, 0, 0);
+ cpu_node = fetch_pptt_node(table_hdr, cpu_node->parent);
+ } while (cpu_node);
+
+ return total_levels;
+}
+
+/**
+ * acpi_pptt_leaf_node() - Given a processor node, determine if its a leaf
+ * @table_hdr: Pointer to the head of the PPTT table
+ * @node: passed node is checked to see if its a leaf
+ *
+ * Determine if the *node parameter is a leaf node by iterating the
+ * PPTT table, looking for nodes which reference it.
+ *
+ * Return: 0 if we find a node referencing the passed node (or table error),
+ * or 1 if we don't.
+ */
+static int acpi_pptt_leaf_node(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *node)
+{
+ struct acpi_subtable_header *entry;
+ unsigned long table_end;
+ u32 node_entry;
+ struct acpi_pptt_processor *cpu_node;
+ u32 proc_sz;
+
+ table_end = (unsigned long)table_hdr + table_hdr->length;
+ node_entry = ACPI_PTR_DIFF(node, table_hdr);
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr,
+ sizeof(struct acpi_table_pptt));
+ proc_sz = sizeof(struct acpi_pptt_processor *);
+
+ while ((unsigned long)entry + proc_sz < table_end) {
+ cpu_node = (struct acpi_pptt_processor *)entry;
+ if (entry->type == ACPI_PPTT_TYPE_PROCESSOR &&
+ cpu_node->parent == node_entry)
+ return 0;
+ if (entry->length == 0)
+ return 0;
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, entry,
+ entry->length);
+
+ }
+ return 1;
+}
+
+/**
+ * acpi_find_processor_node() - Given a PPTT table find the requested processor
+ * @table_hdr: Pointer to the head of the PPTT table
+ * @acpi_cpu_id: cpu we are searching for
+ *
+ * Find the subtable entry describing the provided processor.
+ * This is done by iterating the PPTT table looking for processor nodes
+ * which have an acpi_processor_id that matches the acpi_cpu_id parameter
+ * passed into the function. If we find a node that matches this criteria
+ * we verify that its a leaf node in the topology rather than depending
+ * on the valid flag, which doesn't need to be set for leaf nodes.
+ *
+ * Return: NULL, or the processors acpi_pptt_processor*
+ */
+static struct acpi_pptt_processor *acpi_find_processor_node(struct acpi_table_header *table_hdr,
+ u32 acpi_cpu_id)
+{
+ struct acpi_subtable_header *entry;
+ unsigned long table_end;
+ struct acpi_pptt_processor *cpu_node;
+ u32 proc_sz;
+
+ table_end = (unsigned long)table_hdr + table_hdr->length;
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr,
+ sizeof(struct acpi_table_pptt));
+ proc_sz = sizeof(struct acpi_pptt_processor *);
+
+ /* find the processor structure associated with this cpuid */
+ while ((unsigned long)entry + proc_sz < table_end) {
+ cpu_node = (struct acpi_pptt_processor *)entry;
+
+ if (entry->length == 0) {
+ pr_warn("Invalid zero length subtable\n");
+ break;
+ }
+ if (entry->type == ACPI_PPTT_TYPE_PROCESSOR &&
+ acpi_cpu_id == cpu_node->acpi_processor_id &&
+ acpi_pptt_leaf_node(table_hdr, cpu_node)) {
+ return (struct acpi_pptt_processor *)entry;
+ }
+
+ entry = ACPI_ADD_PTR(struct acpi_subtable_header, entry,
+ entry->length);
+ }
+
+ return NULL;
+}
+
+static int acpi_find_cache_levels(struct acpi_table_header *table_hdr,
+ u32 acpi_cpu_id)
+{
+ int number_of_levels = 0;
+ struct acpi_pptt_processor *cpu;
+
+ cpu = acpi_find_processor_node(table_hdr, acpi_cpu_id);
+ if (cpu)
+ number_of_levels = acpi_count_levels(table_hdr, cpu);
+
+ return number_of_levels;
+}
+
+static u8 acpi_cache_type(enum cache_type type)
+{
+ switch (type) {
+ case CACHE_TYPE_DATA:
+ pr_debug("Looking for data cache\n");
+ return ACPI_PPTT_CACHE_TYPE_DATA;
+ case CACHE_TYPE_INST:
+ pr_debug("Looking for instruction cache\n");
+ return ACPI_PPTT_CACHE_TYPE_INSTR;
+ default:
+ case CACHE_TYPE_UNIFIED:
+ pr_debug("Looking for unified cache\n");
+ /*
+ * It is important that ACPI_PPTT_CACHE_TYPE_UNIFIED
+ * contains the bit pattern that will match both
+ * ACPI unified bit patterns because we use it later
+ * to match both cases.
+ */
+ return ACPI_PPTT_CACHE_TYPE_UNIFIED;
+ }
+}
+
+static struct acpi_pptt_cache *acpi_find_cache_node(struct acpi_table_header *table_hdr,
+ u32 acpi_cpu_id,
+ enum cache_type type,
+ unsigned int level,
+ struct acpi_pptt_processor **node)
+{
+ int total_levels = 0;
+ struct acpi_pptt_cache *found = NULL;
+ struct acpi_pptt_processor *cpu_node;
+ u8 acpi_type = acpi_cache_type(type);
+
+ pr_debug("Looking for CPU %d's level %d cache type %d\n",
+ acpi_cpu_id, level, acpi_type);
+
+ cpu_node = acpi_find_processor_node(table_hdr, acpi_cpu_id);
+
+ while (cpu_node && !found) {
+ found = acpi_find_cache_level(table_hdr, cpu_node,
+ &total_levels, level, acpi_type);
+ *node = cpu_node;
+ cpu_node = fetch_pptt_node(table_hdr, cpu_node->parent);
+ }
+
+ return found;
+}
+
+/* total number of attributes checked by the properties code */
+#define PPTT_CHECKED_ATTRIBUTES 4
+
+/**
+ * update_cache_properties() - Update cacheinfo for the given processor
+ * @this_leaf: Kernel cache info structure being updated
+ * @found_cache: The PPTT node describing this cache instance
+ * @cpu_node: A unique reference to describe this cache instance
+ *
+ * The ACPI spec implies that the fields in the cache structures are used to
+ * extend and correct the information probed from the hardware. Lets only
+ * set fields that we determine are VALID.
+ *
+ * Return: nothing. Side effect of updating the global cacheinfo
+ */
+static void update_cache_properties(struct cacheinfo *this_leaf,
+ struct acpi_pptt_cache *found_cache,
+ struct acpi_pptt_processor *cpu_node)
+{
+ int valid_flags = 0;
+
+ this_leaf->fw_token = cpu_node;
+ if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) {
+ this_leaf->size = found_cache->size;
+ valid_flags++;
+ }
+ if (found_cache->flags & ACPI_PPTT_LINE_SIZE_VALID) {
+ this_leaf->coherency_line_size = found_cache->line_size;
+ valid_flags++;
+ }
+ if (found_cache->flags & ACPI_PPTT_NUMBER_OF_SETS_VALID) {
+ this_leaf->number_of_sets = found_cache->number_of_sets;
+ valid_flags++;
+ }
+ if (found_cache->flags & ACPI_PPTT_ASSOCIATIVITY_VALID) {
+ this_leaf->ways_of_associativity = found_cache->associativity;
+ valid_flags++;
+ }
+ if (found_cache->flags & ACPI_PPTT_WRITE_POLICY_VALID) {
+ switch (found_cache->attributes & ACPI_PPTT_MASK_WRITE_POLICY) {
+ case ACPI_PPTT_CACHE_POLICY_WT:
+ this_leaf->attributes = CACHE_WRITE_THROUGH;
+ break;
+ case ACPI_PPTT_CACHE_POLICY_WB:
+ this_leaf->attributes = CACHE_WRITE_BACK;
+ break;
+ }
+ }
+ if (found_cache->flags & ACPI_PPTT_ALLOCATION_TYPE_VALID) {
+ switch (found_cache->attributes & ACPI_PPTT_MASK_ALLOCATION_TYPE) {
+ case ACPI_PPTT_CACHE_READ_ALLOCATE:
+ this_leaf->attributes |= CACHE_READ_ALLOCATE;
+ break;
+ case ACPI_PPTT_CACHE_WRITE_ALLOCATE:
+ this_leaf->attributes |= CACHE_WRITE_ALLOCATE;
+ break;
+ case ACPI_PPTT_CACHE_RW_ALLOCATE:
+ case ACPI_PPTT_CACHE_RW_ALLOCATE_ALT:
+ this_leaf->attributes |=
+ CACHE_READ_ALLOCATE | CACHE_WRITE_ALLOCATE;
+ break;
+ }
+ }
+ /*
+ * If the above flags are valid, and the cache type is NOCACHE
+ * update the cache type as well.
+ */
+ if (this_leaf->type == CACHE_TYPE_NOCACHE &&
+ valid_flags == PPTT_CHECKED_ATTRIBUTES)
+ this_leaf->type = CACHE_TYPE_UNIFIED;
+}
+
+static void cache_setup_acpi_cpu(struct acpi_table_header *table,
+ unsigned int cpu)
+{
+ struct acpi_pptt_cache *found_cache;
+ struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
+ u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ struct cacheinfo *this_leaf;
+ unsigned int index = 0;
+ struct acpi_pptt_processor *cpu_node = NULL;
+
+ while (index < get_cpu_cacheinfo(cpu)->num_leaves) {
+ this_leaf = this_cpu_ci->info_list + index;
+ found_cache = acpi_find_cache_node(table, acpi_cpu_id,
+ this_leaf->type,
+ this_leaf->level,
+ &cpu_node);
+ pr_debug("found = %p %p\n", found_cache, cpu_node);
+ if (found_cache)
+ update_cache_properties(this_leaf,
+ found_cache,
+ cpu_node);
+
+ index++;
+ }
+}
+
+/* Passing level values greater than this will result in search termination */
+#define PPTT_ABORT_PACKAGE 0xFF
+
+static struct acpi_pptt_processor *acpi_find_processor_package_id(struct acpi_table_header *table_hdr,
+ struct acpi_pptt_processor *cpu,
+ int level, int flag)
+{
+ struct acpi_pptt_processor *prev_node;
+
+ while (cpu && level) {
+ if (cpu->flags & flag)
+ break;
+ pr_debug("level %d\n", level);
+ prev_node = fetch_pptt_node(table_hdr, cpu->parent);
+ if (prev_node == NULL)
+ break;
+ cpu = prev_node;
+ level--;
+ }
+ return cpu;
+}
+
+/**
+ * topology_get_acpi_cpu_tag() - Find a unique topology value for a feature
+ * @table: Pointer to the head of the PPTT table
+ * @cpu: Kernel logical cpu number
+ * @level: A level that terminates the search
+ * @flag: A flag which terminates the search
+ *
+ * Get a unique value given a cpu, and a topology level, that can be
+ * matched to determine which cpus share common topological features
+ * at that level.
+ *
+ * Return: Unique value, or -ENOENT if unable to locate cpu
+ */
+static int topology_get_acpi_cpu_tag(struct acpi_table_header *table,
+ unsigned int cpu, int level, int flag)
+{
+ struct acpi_pptt_processor *cpu_node;
+ u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+
+ cpu_node = acpi_find_processor_node(table, acpi_cpu_id);
+ if (cpu_node) {
+ cpu_node = acpi_find_processor_package_id(table, cpu_node,
+ level, flag);
+ /* Only the first level has a guaranteed id */
+ if (level == 0)
+ return cpu_node->acpi_processor_id;
+ return ACPI_PTR_DIFF(cpu_node, table);
+ }
+ pr_warn_once("PPTT table found, but unable to locate core %d (%d)\n",
+ cpu, acpi_cpu_id);
+ return -ENOENT;
+}
+
+static int find_acpi_cpu_topology_tag(unsigned int cpu, int level, int flag)
+{
+ struct acpi_table_header *table;
+ acpi_status status;
+ int retval;
+
+ status = acpi_get_table(ACPI_SIG_PPTT, 0, &table);
+ if (ACPI_FAILURE(status)) {
+ pr_warn_once("No PPTT table found, cpu topology may be inaccurate\n");
+ return -ENOENT;
+ }
+ retval = topology_get_acpi_cpu_tag(table, cpu, level, flag);
+ pr_debug("Topology Setup ACPI cpu %d, level %d ret = %d\n",
+ cpu, level, retval);
+ acpi_put_table(table);
+
+ return retval;
+}
+
+/**
+ * acpi_find_last_cache_level() - Determines the number of cache levels for a PE
+ * @cpu: Kernel logical cpu number
+ *
+ * Given a logical cpu number, returns the number of levels of cache represented
+ * in the PPTT. Errors caused by lack of a PPTT table, or otherwise, return 0
+ * indicating we didn't find any cache levels.
+ *
+ * Return: Cache levels visible to this core.
+ */
+int acpi_find_last_cache_level(unsigned int cpu)
+{
+ u32 acpi_cpu_id;
+ struct acpi_table_header *table;
+ int number_of_levels = 0;
+ acpi_status status;
+
+ pr_debug("Cache Setup find last level cpu=%d\n", cpu);
+
+ acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ status = acpi_get_table(ACPI_SIG_PPTT, 0, &table);
+ if (ACPI_FAILURE(status)) {
+ pr_warn_once("No PPTT table found, cache topology may be inaccurate\n");
+ } else {
+ number_of_levels = acpi_find_cache_levels(table, acpi_cpu_id);
+ acpi_put_table(table);
+ }
+ pr_debug("Cache Setup find last level level=%d\n", number_of_levels);
+
+ return number_of_levels;
+}
+
+/**
+ * cache_setup_acpi() - Override CPU cache topology with data from the PPTT
+ * @cpu: Kernel logical cpu number
+ *
+ * Updates the global cache info provided by cpu_get_cacheinfo()
+ * when there are valid properties in the acpi_pptt_cache nodes. A
+ * successful parse may not result in any updates if none of the
+ * cache levels have any valid flags set. Futher, a unique value is
+ * associated with each known CPU cache entry. This unique value
+ * can be used to determine whether caches are shared between cpus.
+ *
+ * Return: -ENOENT on failure to find table, or 0 on success
+ */
+int cache_setup_acpi(unsigned int cpu)
+{
+ struct acpi_table_header *table;
+ acpi_status status;
+
+ pr_debug("Cache Setup ACPI cpu %d\n", cpu);
+
+ status = acpi_get_table(ACPI_SIG_PPTT, 0, &table);
+ if (ACPI_FAILURE(status)) {
+ pr_warn_once("No PPTT table found, cache topology may be inaccurate\n");
+ return -ENOENT;
+ }
+
+ cache_setup_acpi_cpu(table, cpu);
+ acpi_put_table(table);
+
+ return status;
+}
+
+/**
+ * find_acpi_cpu_topology() - Determine a unique topology value for a given cpu
+ * @cpu: Kernel logical cpu number
+ * @level: The topological level for which we would like a unique ID
+ *
+ * Determine a topology unique ID for each thread/core/cluster/mc_grouping
+ * /socket/etc. This ID can then be used to group peers, which will have
+ * matching ids.
+ *
+ * The search terminates when either the requested level is found or
+ * we reach a root node. Levels beyond the termination point will return the
+ * same unique ID. The unique id for level 0 is the acpi processor id. All
+ * other levels beyond this use a generated value to uniquely identify
+ * a topological feature.
+ *
+ * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found.
+ * Otherwise returns a value which represents a unique topological feature.
+ */
+int find_acpi_cpu_topology(unsigned int cpu, int level)
+{
+ return find_acpi_cpu_topology_tag(cpu, level, 0);
+}
+
+/**
+ * find_acpi_cpu_cache_topology() - Determine a unique cache topology value
+ * @cpu: Kernel logical cpu number
+ * @level: The cache level for which we would like a unique ID
+ *
+ * Determine a unique ID for each unified cache in the system
+ *
+ * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found.
+ * Otherwise returns a value which represents a unique topological feature.
+ */
+int find_acpi_cpu_cache_topology(unsigned int cpu, int level)
+{
+ struct acpi_table_header *table;
+ struct acpi_pptt_cache *found_cache;
+ acpi_status status;
+ u32 acpi_cpu_id = get_acpi_id_for_cpu(cpu);
+ struct acpi_pptt_processor *cpu_node = NULL;
+ int ret = -1;
+
+ status = acpi_get_table(ACPI_SIG_PPTT, 0, &table);
+ if (ACPI_FAILURE(status)) {
+ pr_warn_once("No PPTT table found, topology may be inaccurate\n");
+ return -ENOENT;
+ }
+
+ found_cache = acpi_find_cache_node(table, acpi_cpu_id,
+ CACHE_TYPE_UNIFIED,
+ level,
+ &cpu_node);
+ if (found_cache)
+ ret = ACPI_PTR_DIFF(cpu_node, table);
+
+ acpi_put_table(table);
+
+ return ret;
+}
+
+
+/**
+ * find_acpi_cpu_topology_package() - Determine a unique cpu package value
+ * @cpu: Kernel logical cpu number
+ *
+ * Determine a topology unique package ID for the given cpu.
+ * This ID can then be used to group peers, which will have matching ids.
+ *
+ * The search terminates when either a level is found with the PHYSICAL_PACKAGE
+ * flag set or we reach a root node.
+ *
+ * Return: -ENOENT if the PPTT doesn't exist, or the cpu cannot be found.
+ * Otherwise returns a value which represents the package for this cpu.
+ */
+int find_acpi_cpu_topology_package(unsigned int cpu)
+{
+ return find_acpi_cpu_topology_tag(cpu, PPTT_ABORT_PACKAGE,
+ ACPI_PPTT_PHYSICAL_PACKAGE);
+}
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 15bfb15c2fa5..032e12a2fdc2 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1297,4 +1297,8 @@ static inline int lpit_read_residency_count_address(u64 *address)
}
#endif
+int find_acpi_cpu_topology(unsigned int cpu, int level);
+int find_acpi_cpu_topology_package(unsigned int cpu);
+int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
+
#endif /*_LINUX_ACPI_H*/
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* Re: [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
2018-05-11 23:58 ` Jeremy Linton
(?)
(?)
@ 2018-05-12 10:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 185+ messages in thread
From: Rafael J. Wysocki @ 2018-05-12 10:09 UTC (permalink / raw)
To: Jeremy Linton
Cc: ACPI Devel Maling List, Sudeep Holla, Linux ARM,
Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, wangxiongfeng2, vkilari,
Al Stone, Dietmar Eggemann, Morten Rasmussen, palmer, Len Brown,
John Garry
On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> ACPI 6.2 adds a new table, which describes how processing units
> are related to each other in tree like fashion. Caches are
> also sprinkled throughout the tree and describe the properties
> of the caches in relation to other caches and processing units.
>
> Add the code to parse the cache hierarchy and report the total
> number of levels of cache for a given core using
> acpi_find_last_cache_level() as well as fill out the individual
> cores cache information with cache_setup_acpi() once the
> cpu_cacheinfo structure has been populated by the arch specific
> code.
>
> An additional patch later in the set adds the ability to report
> peers in the topology using find_acpi_cpu_topology()
> to report a unique ID for each processing unit at a given level
> in the tree. These unique id's can then be used to match related
> processing units which exist as threads, within a given
> package, etc.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> drivers/acpi/pptt.c | 655 +++++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/acpi.h | 4 +
> 2 files changed, 659 insertions(+)
> create mode 100644 drivers/acpi/pptt.c
>
> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
> new file mode 100644
> index 000000000000..e5ea1974d1e3
> --- /dev/null
> +++ b/drivers/acpi/pptt.c
> @@ -0,0 +1,655 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * pptt.c - parsing of Processor Properties Topology Table (PPTT)
> + *
> + * Copyright (C) 2018, ARM
> + *
> + * This file implements parsing of the Processor Properties Topology Table
> + * which is optionally used to describe the processor and cache topology.
> + * Due to the relative pointers used throughout the table, this doesn't
> + * leverage the existing subtable parsing in the kernel.
> + *
> + * The PPTT structure is an inverted tree, with each node potentially
> + * holding one or two inverted tree data structures describing
> + * the caches available at that level. Each cache structure optionally
> + * contains properties describing the cache at a given level which can be
> + * used to override hardware probed values.
> + */
> +#define pr_fmt(fmt) "ACPI PPTT: " fmt
> +
> +#include <linux/acpi.h>
> +#include <linux/cacheinfo.h>
> +#include <acpi/processor.h>
> +
> +static struct acpi_subtable_header *fetch_pptt_subtable(struct acpi_table_header *table_hdr,
> + u32 pptt_ref)
> +{
> + struct acpi_subtable_header *entry;
> +
> + /* there isn't a subtable at reference 0 */
> + if (pptt_ref < sizeof(struct acpi_subtable_header))
> + return NULL;
> +
> + if (pptt_ref + sizeof(struct acpi_subtable_header) > table_hdr->length)
> + return NULL;
> +
> + entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, pptt_ref);
> +
> + if (entry->length == 0)
> + return NULL;
> +
> + if (pptt_ref + entry->length > table_hdr->length)
> + return NULL;
> +
> + return entry;
> +}
> +
> +static struct acpi_pptt_processor *fetch_pptt_node(struct acpi_table_header *table_hdr,
> + u32 pptt_ref)
> +{
> + return (struct acpi_pptt_processor *)fetch_pptt_subtable(table_hdr, pptt_ref);
> +}
> +
> +static struct acpi_pptt_cache *fetch_pptt_cache(struct acpi_table_header *table_hdr,
> + u32 pptt_ref)
> +{
> + return (struct acpi_pptt_cache *)fetch_pptt_subtable(table_hdr, pptt_ref);
I don't think you really need the explicit type cast here and above,
but that's very minor.
> +}
Please feel free to add
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
to the patch and route it through the arch tree as needed.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
@ 2018-05-12 10:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 185+ messages in thread
From: Rafael J. Wysocki @ 2018-05-12 10:09 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> ACPI 6.2 adds a new table, which describes how processing units
> are related to each other in tree like fashion. Caches are
> also sprinkled throughout the tree and describe the properties
> of the caches in relation to other caches and processing units.
>
> Add the code to parse the cache hierarchy and report the total
> number of levels of cache for a given core using
> acpi_find_last_cache_level() as well as fill out the individual
> cores cache information with cache_setup_acpi() once the
> cpu_cacheinfo structure has been populated by the arch specific
> code.
>
> An additional patch later in the set adds the ability to report
> peers in the topology using find_acpi_cpu_topology()
> to report a unique ID for each processing unit at a given level
> in the tree. These unique id's can then be used to match related
> processing units which exist as threads, within a given
> package, etc.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> drivers/acpi/pptt.c | 655 +++++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/acpi.h | 4 +
> 2 files changed, 659 insertions(+)
> create mode 100644 drivers/acpi/pptt.c
>
> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
> new file mode 100644
> index 000000000000..e5ea1974d1e3
> --- /dev/null
> +++ b/drivers/acpi/pptt.c
> @@ -0,0 +1,655 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * pptt.c - parsing of Processor Properties Topology Table (PPTT)
> + *
> + * Copyright (C) 2018, ARM
> + *
> + * This file implements parsing of the Processor Properties Topology Table
> + * which is optionally used to describe the processor and cache topology.
> + * Due to the relative pointers used throughout the table, this doesn't
> + * leverage the existing subtable parsing in the kernel.
> + *
> + * The PPTT structure is an inverted tree, with each node potentially
> + * holding one or two inverted tree data structures describing
> + * the caches available at that level. Each cache structure optionally
> + * contains properties describing the cache at a given level which can be
> + * used to override hardware probed values.
> + */
> +#define pr_fmt(fmt) "ACPI PPTT: " fmt
> +
> +#include <linux/acpi.h>
> +#include <linux/cacheinfo.h>
> +#include <acpi/processor.h>
> +
> +static struct acpi_subtable_header *fetch_pptt_subtable(struct acpi_table_header *table_hdr,
> + u32 pptt_ref)
> +{
> + struct acpi_subtable_header *entry;
> +
> + /* there isn't a subtable at reference 0 */
> + if (pptt_ref < sizeof(struct acpi_subtable_header))
> + return NULL;
> +
> + if (pptt_ref + sizeof(struct acpi_subtable_header) > table_hdr->length)
> + return NULL;
> +
> + entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, pptt_ref);
> +
> + if (entry->length == 0)
> + return NULL;
> +
> + if (pptt_ref + entry->length > table_hdr->length)
> + return NULL;
> +
> + return entry;
> +}
> +
> +static struct acpi_pptt_processor *fetch_pptt_node(struct acpi_table_header *table_hdr,
> + u32 pptt_ref)
> +{
> + return (struct acpi_pptt_processor *)fetch_pptt_subtable(table_hdr, pptt_ref);
> +}
> +
> +static struct acpi_pptt_cache *fetch_pptt_cache(struct acpi_table_header *table_hdr,
> + u32 pptt_ref)
> +{
> + return (struct acpi_pptt_cache *)fetch_pptt_subtable(table_hdr, pptt_ref);
I don't think you really need the explicit type cast here and above,
but that's very minor.
> +}
Please feel free to add
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
to the patch and route it through the arch tree as needed.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
@ 2018-05-12 10:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 185+ messages in thread
From: Rafael J. Wysocki @ 2018-05-12 10:09 UTC (permalink / raw)
To: linux-riscv
On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> ACPI 6.2 adds a new table, which describes how processing units
> are related to each other in tree like fashion. Caches are
> also sprinkled throughout the tree and describe the properties
> of the caches in relation to other caches and processing units.
>
> Add the code to parse the cache hierarchy and report the total
> number of levels of cache for a given core using
> acpi_find_last_cache_level() as well as fill out the individual
> cores cache information with cache_setup_acpi() once the
> cpu_cacheinfo structure has been populated by the arch specific
> code.
>
> An additional patch later in the set adds the ability to report
> peers in the topology using find_acpi_cpu_topology()
> to report a unique ID for each processing unit at a given level
> in the tree. These unique id's can then be used to match related
> processing units which exist as threads, within a given
> package, etc.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> drivers/acpi/pptt.c | 655 +++++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/acpi.h | 4 +
> 2 files changed, 659 insertions(+)
> create mode 100644 drivers/acpi/pptt.c
>
> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
> new file mode 100644
> index 000000000000..e5ea1974d1e3
> --- /dev/null
> +++ b/drivers/acpi/pptt.c
> @@ -0,0 +1,655 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * pptt.c - parsing of Processor Properties Topology Table (PPTT)
> + *
> + * Copyright (C) 2018, ARM
> + *
> + * This file implements parsing of the Processor Properties Topology Table
> + * which is optionally used to describe the processor and cache topology.
> + * Due to the relative pointers used throughout the table, this doesn't
> + * leverage the existing subtable parsing in the kernel.
> + *
> + * The PPTT structure is an inverted tree, with each node potentially
> + * holding one or two inverted tree data structures describing
> + * the caches available at that level. Each cache structure optionally
> + * contains properties describing the cache at a given level which can be
> + * used to override hardware probed values.
> + */
> +#define pr_fmt(fmt) "ACPI PPTT: " fmt
> +
> +#include <linux/acpi.h>
> +#include <linux/cacheinfo.h>
> +#include <acpi/processor.h>
> +
> +static struct acpi_subtable_header *fetch_pptt_subtable(struct acpi_table_header *table_hdr,
> + u32 pptt_ref)
> +{
> + struct acpi_subtable_header *entry;
> +
> + /* there isn't a subtable at reference 0 */
> + if (pptt_ref < sizeof(struct acpi_subtable_header))
> + return NULL;
> +
> + if (pptt_ref + sizeof(struct acpi_subtable_header) > table_hdr->length)
> + return NULL;
> +
> + entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, pptt_ref);
> +
> + if (entry->length == 0)
> + return NULL;
> +
> + if (pptt_ref + entry->length > table_hdr->length)
> + return NULL;
> +
> + return entry;
> +}
> +
> +static struct acpi_pptt_processor *fetch_pptt_node(struct acpi_table_header *table_hdr,
> + u32 pptt_ref)
> +{
> + return (struct acpi_pptt_processor *)fetch_pptt_subtable(table_hdr, pptt_ref);
> +}
> +
> +static struct acpi_pptt_cache *fetch_pptt_cache(struct acpi_table_header *table_hdr,
> + u32 pptt_ref)
> +{
> + return (struct acpi_pptt_cache *)fetch_pptt_subtable(table_hdr, pptt_ref);
I don't think you really need the explicit type cast here and above,
but that's very minor.
> +}
Please feel free to add
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
to the patch and route it through the arch tree as needed.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
@ 2018-05-12 10:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 185+ messages in thread
From: Rafael J. Wysocki @ 2018-05-12 10:09 UTC (permalink / raw)
To: Jeremy Linton
Cc: ACPI Devel Maling List, Sudeep Holla, Linux ARM,
Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, wangxiongfeng2, vkilari,
Al Stone, Dietmar Eggemann, Morten Rasmussen, palmer, Len Brown,
John Garry, austinwc, tnowicki, jhugo, Ard Biesheuvel
On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> ACPI 6.2 adds a new table, which describes how processing units
> are related to each other in tree like fashion. Caches are
> also sprinkled throughout the tree and describe the properties
> of the caches in relation to other caches and processing units.
>
> Add the code to parse the cache hierarchy and report the total
> number of levels of cache for a given core using
> acpi_find_last_cache_level() as well as fill out the individual
> cores cache information with cache_setup_acpi() once the
> cpu_cacheinfo structure has been populated by the arch specific
> code.
>
> An additional patch later in the set adds the ability to report
> peers in the topology using find_acpi_cpu_topology()
> to report a unique ID for each processing unit at a given level
> in the tree. These unique id's can then be used to match related
> processing units which exist as threads, within a given
> package, etc.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> drivers/acpi/pptt.c | 655 +++++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/acpi.h | 4 +
> 2 files changed, 659 insertions(+)
> create mode 100644 drivers/acpi/pptt.c
>
> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
> new file mode 100644
> index 000000000000..e5ea1974d1e3
> --- /dev/null
> +++ b/drivers/acpi/pptt.c
> @@ -0,0 +1,655 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * pptt.c - parsing of Processor Properties Topology Table (PPTT)
> + *
> + * Copyright (C) 2018, ARM
> + *
> + * This file implements parsing of the Processor Properties Topology Table
> + * which is optionally used to describe the processor and cache topology.
> + * Due to the relative pointers used throughout the table, this doesn't
> + * leverage the existing subtable parsing in the kernel.
> + *
> + * The PPTT structure is an inverted tree, with each node potentially
> + * holding one or two inverted tree data structures describing
> + * the caches available at that level. Each cache structure optionally
> + * contains properties describing the cache at a given level which can be
> + * used to override hardware probed values.
> + */
> +#define pr_fmt(fmt) "ACPI PPTT: " fmt
> +
> +#include <linux/acpi.h>
> +#include <linux/cacheinfo.h>
> +#include <acpi/processor.h>
> +
> +static struct acpi_subtable_header *fetch_pptt_subtable(struct acpi_table_header *table_hdr,
> + u32 pptt_ref)
> +{
> + struct acpi_subtable_header *entry;
> +
> + /* there isn't a subtable at reference 0 */
> + if (pptt_ref < sizeof(struct acpi_subtable_header))
> + return NULL;
> +
> + if (pptt_ref + sizeof(struct acpi_subtable_header) > table_hdr->length)
> + return NULL;
> +
> + entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, pptt_ref);
> +
> + if (entry->length == 0)
> + return NULL;
> +
> + if (pptt_ref + entry->length > table_hdr->length)
> + return NULL;
> +
> + return entry;
> +}
> +
> +static struct acpi_pptt_processor *fetch_pptt_node(struct acpi_table_header *table_hdr,
> + u32 pptt_ref)
> +{
> + return (struct acpi_pptt_processor *)fetch_pptt_subtable(table_hdr, pptt_ref);
> +}
> +
> +static struct acpi_pptt_cache *fetch_pptt_cache(struct acpi_table_header *table_hdr,
> + u32 pptt_ref)
> +{
> + return (struct acpi_pptt_cache *)fetch_pptt_subtable(table_hdr, pptt_ref);
I don't think you really need the explicit type cast here and above,
but that's very minor.
> +}
Please feel free to add
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
to the patch and route it through the arch tree as needed.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
2018-05-12 10:09 ` Rafael J. Wysocki
(?)
(?)
@ 2018-05-15 21:42 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-15 21:42 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: ACPI Devel Maling List, Sudeep Holla, Linux ARM,
Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, wangxiongfeng2, vkilari,
Al Stone, Dietmar Eggemann, Morten Rasmussen, palmer, Len Brown,
John Garry
Hi,
On 05/12/2018 05:09 AM, Rafael J. Wysocki wrote:
> On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>> ACPI 6.2 adds a new table, which describes how processing units
>> are related to each other in tree like fashion. Caches are
>> also sprinkled throughout the tree and describe the properties
>> of the caches in relation to other caches and processing units.
>>
>> Add the code to parse the cache hierarchy and report the total
>> number of levels of cache for a given core using
>> acpi_find_last_cache_level() as well as fill out the individual
>> cores cache information with cache_setup_acpi() once the
>> cpu_cacheinfo structure has been populated by the arch specific
>> code.
>>
>> An additional patch later in the set adds the ability to report
>> peers in the topology using find_acpi_cpu_topology()
>> to report a unique ID for each processing unit at a given level
>> in the tree. These unique id's can then be used to match related
>> processing units which exist as threads, within a given
>> package, etc.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
>> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
>> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
>> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
>> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> drivers/acpi/pptt.c | 655 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/acpi.h | 4 +
>> 2 files changed, 659 insertions(+)
>> create mode 100644 drivers/acpi/pptt.c
>>
>> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
>> new file mode 100644
>> index 000000000000..e5ea1974d1e3
>> --- /dev/null
>> +++ b/drivers/acpi/pptt.c
>> @@ -0,0 +1,655 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * pptt.c - parsing of Processor Properties Topology Table (PPTT)
>> + *
>> + * Copyright (C) 2018, ARM
>> + *
>> + * This file implements parsing of the Processor Properties Topology Table
>> + * which is optionally used to describe the processor and cache topology.
>> + * Due to the relative pointers used throughout the table, this doesn't
>> + * leverage the existing subtable parsing in the kernel.
>> + *
>> + * The PPTT structure is an inverted tree, with each node potentially
>> + * holding one or two inverted tree data structures describing
>> + * the caches available at that level. Each cache structure optionally
>> + * contains properties describing the cache at a given level which can be
>> + * used to override hardware probed values.
>> + */
>> +#define pr_fmt(fmt) "ACPI PPTT: " fmt
>> +
>> +#include <linux/acpi.h>
>> +#include <linux/cacheinfo.h>
>> +#include <acpi/processor.h>
>> +
>> +static struct acpi_subtable_header *fetch_pptt_subtable(struct acpi_table_header *table_hdr,
>> + u32 pptt_ref)
>> +{
>> + struct acpi_subtable_header *entry;
>> +
>> + /* there isn't a subtable at reference 0 */
>> + if (pptt_ref < sizeof(struct acpi_subtable_header))
>> + return NULL;
>> +
>> + if (pptt_ref + sizeof(struct acpi_subtable_header) > table_hdr->length)
>> + return NULL;
>> +
>> + entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, pptt_ref);
>> +
>> + if (entry->length == 0)
>> + return NULL;
>> +
>> + if (pptt_ref + entry->length > table_hdr->length)
>> + return NULL;
>> +
>> + return entry;
>> +}
>> +
>> +static struct acpi_pptt_processor *fetch_pptt_node(struct acpi_table_header *table_hdr,
>> + u32 pptt_ref)
>> +{
>> + return (struct acpi_pptt_processor *)fetch_pptt_subtable(table_hdr, pptt_ref);
>> +}
>> +
>> +static struct acpi_pptt_cache *fetch_pptt_cache(struct acpi_table_header *table_hdr,
>> + u32 pptt_ref)
>> +{
>> + return (struct acpi_pptt_cache *)fetch_pptt_subtable(table_hdr, pptt_ref);
>
> I don't think you really need the explicit type cast here and above,
> but that's very minor.
>
>> +}
>
> Please feel free to add
>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> to the patch and route it through the arch tree as needed.
Thanks for looking at this (and the ack of course)!
As an FYI, the in my build without the type cast, the
-Werror=incompatible-pointer-types (sourced from the root Makefile)
triggers an error.
thanks again.
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
@ 2018-05-15 21:42 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-15 21:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On 05/12/2018 05:09 AM, Rafael J. Wysocki wrote:
> On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>> ACPI 6.2 adds a new table, which describes how processing units
>> are related to each other in tree like fashion. Caches are
>> also sprinkled throughout the tree and describe the properties
>> of the caches in relation to other caches and processing units.
>>
>> Add the code to parse the cache hierarchy and report the total
>> number of levels of cache for a given core using
>> acpi_find_last_cache_level() as well as fill out the individual
>> cores cache information with cache_setup_acpi() once the
>> cpu_cacheinfo structure has been populated by the arch specific
>> code.
>>
>> An additional patch later in the set adds the ability to report
>> peers in the topology using find_acpi_cpu_topology()
>> to report a unique ID for each processing unit at a given level
>> in the tree. These unique id's can then be used to match related
>> processing units which exist as threads, within a given
>> package, etc.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
>> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
>> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
>> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
>> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> drivers/acpi/pptt.c | 655 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/acpi.h | 4 +
>> 2 files changed, 659 insertions(+)
>> create mode 100644 drivers/acpi/pptt.c
>>
>> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
>> new file mode 100644
>> index 000000000000..e5ea1974d1e3
>> --- /dev/null
>> +++ b/drivers/acpi/pptt.c
>> @@ -0,0 +1,655 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * pptt.c - parsing of Processor Properties Topology Table (PPTT)
>> + *
>> + * Copyright (C) 2018, ARM
>> + *
>> + * This file implements parsing of the Processor Properties Topology Table
>> + * which is optionally used to describe the processor and cache topology.
>> + * Due to the relative pointers used throughout the table, this doesn't
>> + * leverage the existing subtable parsing in the kernel.
>> + *
>> + * The PPTT structure is an inverted tree, with each node potentially
>> + * holding one or two inverted tree data structures describing
>> + * the caches available at that level. Each cache structure optionally
>> + * contains properties describing the cache at a given level which can be
>> + * used to override hardware probed values.
>> + */
>> +#define pr_fmt(fmt) "ACPI PPTT: " fmt
>> +
>> +#include <linux/acpi.h>
>> +#include <linux/cacheinfo.h>
>> +#include <acpi/processor.h>
>> +
>> +static struct acpi_subtable_header *fetch_pptt_subtable(struct acpi_table_header *table_hdr,
>> + u32 pptt_ref)
>> +{
>> + struct acpi_subtable_header *entry;
>> +
>> + /* there isn't a subtable at reference 0 */
>> + if (pptt_ref < sizeof(struct acpi_subtable_header))
>> + return NULL;
>> +
>> + if (pptt_ref + sizeof(struct acpi_subtable_header) > table_hdr->length)
>> + return NULL;
>> +
>> + entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, pptt_ref);
>> +
>> + if (entry->length == 0)
>> + return NULL;
>> +
>> + if (pptt_ref + entry->length > table_hdr->length)
>> + return NULL;
>> +
>> + return entry;
>> +}
>> +
>> +static struct acpi_pptt_processor *fetch_pptt_node(struct acpi_table_header *table_hdr,
>> + u32 pptt_ref)
>> +{
>> + return (struct acpi_pptt_processor *)fetch_pptt_subtable(table_hdr, pptt_ref);
>> +}
>> +
>> +static struct acpi_pptt_cache *fetch_pptt_cache(struct acpi_table_header *table_hdr,
>> + u32 pptt_ref)
>> +{
>> + return (struct acpi_pptt_cache *)fetch_pptt_subtable(table_hdr, pptt_ref);
>
> I don't think you really need the explicit type cast here and above,
> but that's very minor.
>
>> +}
>
> Please feel free to add
>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> to the patch and route it through the arch tree as needed.
Thanks for looking at this (and the ack of course)!
As an FYI, the in my build without the type cast, the
-Werror=incompatible-pointer-types (sourced from the root Makefile)
triggers an error.
thanks again.
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
@ 2018-05-15 21:42 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-15 21:42 UTC (permalink / raw)
To: linux-riscv
Hi,
On 05/12/2018 05:09 AM, Rafael J. Wysocki wrote:
> On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>> ACPI 6.2 adds a new table, which describes how processing units
>> are related to each other in tree like fashion. Caches are
>> also sprinkled throughout the tree and describe the properties
>> of the caches in relation to other caches and processing units.
>>
>> Add the code to parse the cache hierarchy and report the total
>> number of levels of cache for a given core using
>> acpi_find_last_cache_level() as well as fill out the individual
>> cores cache information with cache_setup_acpi() once the
>> cpu_cacheinfo structure has been populated by the arch specific
>> code.
>>
>> An additional patch later in the set adds the ability to report
>> peers in the topology using find_acpi_cpu_topology()
>> to report a unique ID for each processing unit at a given level
>> in the tree. These unique id's can then be used to match related
>> processing units which exist as threads, within a given
>> package, etc.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
>> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
>> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
>> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
>> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> drivers/acpi/pptt.c | 655 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/acpi.h | 4 +
>> 2 files changed, 659 insertions(+)
>> create mode 100644 drivers/acpi/pptt.c
>>
>> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
>> new file mode 100644
>> index 000000000000..e5ea1974d1e3
>> --- /dev/null
>> +++ b/drivers/acpi/pptt.c
>> @@ -0,0 +1,655 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * pptt.c - parsing of Processor Properties Topology Table (PPTT)
>> + *
>> + * Copyright (C) 2018, ARM
>> + *
>> + * This file implements parsing of the Processor Properties Topology Table
>> + * which is optionally used to describe the processor and cache topology.
>> + * Due to the relative pointers used throughout the table, this doesn't
>> + * leverage the existing subtable parsing in the kernel.
>> + *
>> + * The PPTT structure is an inverted tree, with each node potentially
>> + * holding one or two inverted tree data structures describing
>> + * the caches available at that level. Each cache structure optionally
>> + * contains properties describing the cache at a given level which can be
>> + * used to override hardware probed values.
>> + */
>> +#define pr_fmt(fmt) "ACPI PPTT: " fmt
>> +
>> +#include <linux/acpi.h>
>> +#include <linux/cacheinfo.h>
>> +#include <acpi/processor.h>
>> +
>> +static struct acpi_subtable_header *fetch_pptt_subtable(struct acpi_table_header *table_hdr,
>> + u32 pptt_ref)
>> +{
>> + struct acpi_subtable_header *entry;
>> +
>> + /* there isn't a subtable at reference 0 */
>> + if (pptt_ref < sizeof(struct acpi_subtable_header))
>> + return NULL;
>> +
>> + if (pptt_ref + sizeof(struct acpi_subtable_header) > table_hdr->length)
>> + return NULL;
>> +
>> + entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, pptt_ref);
>> +
>> + if (entry->length == 0)
>> + return NULL;
>> +
>> + if (pptt_ref + entry->length > table_hdr->length)
>> + return NULL;
>> +
>> + return entry;
>> +}
>> +
>> +static struct acpi_pptt_processor *fetch_pptt_node(struct acpi_table_header *table_hdr,
>> + u32 pptt_ref)
>> +{
>> + return (struct acpi_pptt_processor *)fetch_pptt_subtable(table_hdr, pptt_ref);
>> +}
>> +
>> +static struct acpi_pptt_cache *fetch_pptt_cache(struct acpi_table_header *table_hdr,
>> + u32 pptt_ref)
>> +{
>> + return (struct acpi_pptt_cache *)fetch_pptt_subtable(table_hdr, pptt_ref);
>
> I don't think you really need the explicit type cast here and above,
> but that's very minor.
>
>> +}
>
> Please feel free to add
>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> to the patch and route it through the arch tree as needed.
Thanks for looking at this (and the ack of course)!
As an FYI, the in my build without the type cast, the
-Werror=incompatible-pointer-types (sourced from the root Makefile)
triggers an error.
thanks again.
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
@ 2018-05-15 21:42 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-15 21:42 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: ACPI Devel Maling List, Sudeep Holla, Linux ARM,
Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, wangxiongfeng2, vkilari,
Al Stone, Dietmar Eggemann, Morten Rasmussen, palmer, Len Brown,
John Garry, austinwc, tnowicki, jhugo, Ard Biesheuvel
Hi,
On 05/12/2018 05:09 AM, Rafael J. Wysocki wrote:
> On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com> wrote:
>> ACPI 6.2 adds a new table, which describes how processing units
>> are related to each other in tree like fashion. Caches are
>> also sprinkled throughout the tree and describe the properties
>> of the caches in relation to other caches and processing units.
>>
>> Add the code to parse the cache hierarchy and report the total
>> number of levels of cache for a given core using
>> acpi_find_last_cache_level() as well as fill out the individual
>> cores cache information with cache_setup_acpi() once the
>> cpu_cacheinfo structure has been populated by the arch specific
>> code.
>>
>> An additional patch later in the set adds the ability to report
>> peers in the topology using find_acpi_cpu_topology()
>> to report a unique ID for each processing unit at a given level
>> in the tree. These unique id's can then be used to match related
>> processing units which exist as threads, within a given
>> package, etc.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
>> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
>> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
>> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
>> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> drivers/acpi/pptt.c | 655 +++++++++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/acpi.h | 4 +
>> 2 files changed, 659 insertions(+)
>> create mode 100644 drivers/acpi/pptt.c
>>
>> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
>> new file mode 100644
>> index 000000000000..e5ea1974d1e3
>> --- /dev/null
>> +++ b/drivers/acpi/pptt.c
>> @@ -0,0 +1,655 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * pptt.c - parsing of Processor Properties Topology Table (PPTT)
>> + *
>> + * Copyright (C) 2018, ARM
>> + *
>> + * This file implements parsing of the Processor Properties Topology Table
>> + * which is optionally used to describe the processor and cache topology.
>> + * Due to the relative pointers used throughout the table, this doesn't
>> + * leverage the existing subtable parsing in the kernel.
>> + *
>> + * The PPTT structure is an inverted tree, with each node potentially
>> + * holding one or two inverted tree data structures describing
>> + * the caches available at that level. Each cache structure optionally
>> + * contains properties describing the cache at a given level which can be
>> + * used to override hardware probed values.
>> + */
>> +#define pr_fmt(fmt) "ACPI PPTT: " fmt
>> +
>> +#include <linux/acpi.h>
>> +#include <linux/cacheinfo.h>
>> +#include <acpi/processor.h>
>> +
>> +static struct acpi_subtable_header *fetch_pptt_subtable(struct acpi_table_header *table_hdr,
>> + u32 pptt_ref)
>> +{
>> + struct acpi_subtable_header *entry;
>> +
>> + /* there isn't a subtable at reference 0 */
>> + if (pptt_ref < sizeof(struct acpi_subtable_header))
>> + return NULL;
>> +
>> + if (pptt_ref + sizeof(struct acpi_subtable_header) > table_hdr->length)
>> + return NULL;
>> +
>> + entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr, pptt_ref);
>> +
>> + if (entry->length == 0)
>> + return NULL;
>> +
>> + if (pptt_ref + entry->length > table_hdr->length)
>> + return NULL;
>> +
>> + return entry;
>> +}
>> +
>> +static struct acpi_pptt_processor *fetch_pptt_node(struct acpi_table_header *table_hdr,
>> + u32 pptt_ref)
>> +{
>> + return (struct acpi_pptt_processor *)fetch_pptt_subtable(table_hdr, pptt_ref);
>> +}
>> +
>> +static struct acpi_pptt_cache *fetch_pptt_cache(struct acpi_table_header *table_hdr,
>> + u32 pptt_ref)
>> +{
>> + return (struct acpi_pptt_cache *)fetch_pptt_subtable(table_hdr, pptt_ref);
>
> I don't think you really need the explicit type cast here and above,
> but that's very minor.
>
>> +}
>
> Please feel free to add
>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> to the patch and route it through the arch tree as needed.
Thanks for looking at this (and the ack of course)!
As an FYI, the in my build without the type cast, the
-Werror=incompatible-pointer-types (sourced from the root Makefile)
triggers an error.
thanks again.
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
2018-05-15 21:42 ` Jeremy Linton
(?)
(?)
@ 2018-05-16 8:24 ` Rafael J. Wysocki
-1 siblings, 0 replies; 185+ messages in thread
From: Rafael J. Wysocki @ 2018-05-16 8:24 UTC (permalink / raw)
To: Jeremy Linton
Cc: Rafael J. Wysocki, ACPI Devel Maling List, Sudeep Holla,
Linux ARM, Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki,
Will Deacon, Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, wangxiongfeng2, vkilari,
Al Stone, Dietmar Eggemann, Morten Rasmussen, palmer, Len Brown
On Tue, May 15, 2018 at 11:42 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> Hi,
>
>
> On 05/12/2018 05:09 AM, Rafael J. Wysocki wrote:
>>
>> On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com>
>> wrote:
>>>
[cut]
>>
>>
>> I don't think you really need the explicit type cast here and above,
>> but that's very minor.
>>
>>> +}
>>
>>
>> Please feel free to add
>>
>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>> to the patch and route it through the arch tree as needed.
>
>
> Thanks for looking at this (and the ack of course)!
>
> As an FYI, the in my build without the type cast, the
> -Werror=incompatible-pointer-types (sourced from the root Makefile) triggers
> an error.
Fair enough.
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
@ 2018-05-16 8:24 ` Rafael J. Wysocki
0 siblings, 0 replies; 185+ messages in thread
From: Rafael J. Wysocki @ 2018-05-16 8:24 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 15, 2018 at 11:42 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> Hi,
>
>
> On 05/12/2018 05:09 AM, Rafael J. Wysocki wrote:
>>
>> On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com>
>> wrote:
>>>
[cut]
>>
>>
>> I don't think you really need the explicit type cast here and above,
>> but that's very minor.
>>
>>> +}
>>
>>
>> Please feel free to add
>>
>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>> to the patch and route it through the arch tree as needed.
>
>
> Thanks for looking at this (and the ack of course)!
>
> As an FYI, the in my build without the type cast, the
> -Werror=incompatible-pointer-types (sourced from the root Makefile) triggers
> an error.
Fair enough.
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
@ 2018-05-16 8:24 ` Rafael J. Wysocki
0 siblings, 0 replies; 185+ messages in thread
From: Rafael J. Wysocki @ 2018-05-16 8:24 UTC (permalink / raw)
To: linux-riscv
On Tue, May 15, 2018 at 11:42 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> Hi,
>
>
> On 05/12/2018 05:09 AM, Rafael J. Wysocki wrote:
>>
>> On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com>
>> wrote:
>>>
[cut]
>>
>>
>> I don't think you really need the explicit type cast here and above,
>> but that's very minor.
>>
>>> +}
>>
>>
>> Please feel free to add
>>
>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>> to the patch and route it through the arch tree as needed.
>
>
> Thanks for looking at this (and the ack of course)!
>
> As an FYI, the in my build without the type cast, the
> -Werror=incompatible-pointer-types (sourced from the root Makefile) triggers
> an error.
Fair enough.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing
@ 2018-05-16 8:24 ` Rafael J. Wysocki
0 siblings, 0 replies; 185+ messages in thread
From: Rafael J. Wysocki @ 2018-05-16 8:24 UTC (permalink / raw)
To: Jeremy Linton
Cc: Rafael J. Wysocki, ACPI Devel Maling List, Sudeep Holla,
Linux ARM, Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki,
Will Deacon, Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, wangxiongfeng2, vkilari,
Al Stone, Dietmar Eggemann, Morten Rasmussen, palmer, Len Brown,
John Garry, austinwc, tnowicki, jhugo, Ard Biesheuvel
On Tue, May 15, 2018 at 11:42 PM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> Hi,
>
>
> On 05/12/2018 05:09 AM, Rafael J. Wysocki wrote:
>>
>> On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com>
>> wrote:
>>>
[cut]
>>
>>
>> I don't think you really need the explicit type cast here and above,
>> but that's very minor.
>>
>>> +}
>>
>>
>> Please feel free to add
>>
>> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>> to the patch and route it through the arch tree as needed.
>
>
> Thanks for looking at this (and the ack of course)!
>
> As an FYI, the in my build without the type cast, the
> -Werror=incompatible-pointer-types (sourced from the root Makefile) triggers
> an error.
Fair enough.
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 06/12] ACPI: Enable PPTT support on ARM64
2018-05-11 23:57 ` Jeremy Linton
(?)
@ 2018-05-11 23:58 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-acpi
Cc: Sudeep.Holla, linux-arm-kernel, Lorenzo.Pieralisi, hanjun.guo,
rjw, Will.Deacon, Catalin.Marinas, gregkh, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel, Jeremy Linton
Now that we have a PPTT parser, in preparation for its use
on arm64, lets build it.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/Kconfig | 1 +
drivers/acpi/Kconfig | 3 +++
drivers/acpi/Makefile | 1 +
3 files changed, 5 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index eb2cf4938f6d..cff33d9eff0c 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -7,6 +7,7 @@ config ARM64
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ACPI_MCFG if ACPI
select ACPI_SPCR_TABLE if ACPI
+ select ACPI_PPTT if ACPI
select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 516d7b36d6fb..b533eeb6139d 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -547,6 +547,9 @@ config ACPI_CONFIGFS
if ARM64
source "drivers/acpi/arm64/Kconfig"
+
+config ACPI_PPTT
+ bool
endif
config TPS68470_PMIC_OPREGION
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 48e202752754..6d59aa109a91 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_ACPI_BGRT) += bgrt.o
obj-$(CONFIG_ACPI_CPPC_LIB) += cppc_acpi.o
obj-$(CONFIG_ACPI_SPCR_TABLE) += spcr.o
obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
+obj-$(CONFIG_ACPI_PPTT) += pptt.o
# processor has its own "processor." module_param namespace
processor-y := processor_driver.o
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH v9 06/12] ACPI: Enable PPTT support on ARM64
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-arm-kernel
Now that we have a PPTT parser, in preparation for its use
on arm64, lets build it.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/Kconfig | 1 +
drivers/acpi/Kconfig | 3 +++
drivers/acpi/Makefile | 1 +
3 files changed, 5 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index eb2cf4938f6d..cff33d9eff0c 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -7,6 +7,7 @@ config ARM64
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ACPI_MCFG if ACPI
select ACPI_SPCR_TABLE if ACPI
+ select ACPI_PPTT if ACPI
select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 516d7b36d6fb..b533eeb6139d 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -547,6 +547,9 @@ config ACPI_CONFIGFS
if ARM64
source "drivers/acpi/arm64/Kconfig"
+
+config ACPI_PPTT
+ bool
endif
config TPS68470_PMIC_OPREGION
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 48e202752754..6d59aa109a91 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_ACPI_BGRT) += bgrt.o
obj-$(CONFIG_ACPI_CPPC_LIB) += cppc_acpi.o
obj-$(CONFIG_ACPI_SPCR_TABLE) += spcr.o
obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
+obj-$(CONFIG_ACPI_PPTT) += pptt.o
# processor has its own "processor." module_param namespace
processor-y := processor_driver.o
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH v9 06/12] ACPI: Enable PPTT support on ARM64
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-riscv
Now that we have a PPTT parser, in preparation for its use
on arm64, lets build it.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/Kconfig | 1 +
drivers/acpi/Kconfig | 3 +++
drivers/acpi/Makefile | 1 +
3 files changed, 5 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index eb2cf4938f6d..cff33d9eff0c 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -7,6 +7,7 @@ config ARM64
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ACPI_MCFG if ACPI
select ACPI_SPCR_TABLE if ACPI
+ select ACPI_PPTT if ACPI
select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 516d7b36d6fb..b533eeb6139d 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -547,6 +547,9 @@ config ACPI_CONFIGFS
if ARM64
source "drivers/acpi/arm64/Kconfig"
+
+config ACPI_PPTT
+ bool
endif
config TPS68470_PMIC_OPREGION
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 48e202752754..6d59aa109a91 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_ACPI_BGRT) += bgrt.o
obj-$(CONFIG_ACPI_CPPC_LIB) += cppc_acpi.o
obj-$(CONFIG_ACPI_SPCR_TABLE) += spcr.o
obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
+obj-$(CONFIG_ACPI_PPTT) += pptt.o
# processor has its own "processor." module_param namespace
processor-y := processor_driver.o
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH v9 07/12] drivers: base cacheinfo: Add support for ACPI based firmware tables
2018-05-11 23:57 ` Jeremy Linton
(?)
@ 2018-05-11 23:58 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-acpi
Cc: Sudeep.Holla, linux-arm-kernel, Lorenzo.Pieralisi, hanjun.guo,
rjw, Will.Deacon, Catalin.Marinas, gregkh, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel, Jeremy Linton
Call ACPI cache parsing routines from base cacheinfo code if ACPI
is enabled. Also stub out cache_setup_acpi and acpi_find_last_cache_level
so that individual architectures can enable ACPI topology parsing.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/base/cacheinfo.c | 14 ++++++++++----
include/linux/cacheinfo.h | 17 +++++++++++++++++
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 597aacb233fc..2880e2ab01f5 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -206,7 +206,7 @@ static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
struct cacheinfo *sib_leaf)
{
/*
- * For non-DT systems, assume unique level 1 cache, system-wide
+ * For non-DT/ACPI systems, assume unique level 1 caches, system-wide
* shared caches for all other levels. This will be used only if
* arch specific code has not populated shared_cpu_map
*/
@@ -214,6 +214,11 @@ static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
}
#endif
+int __weak cache_setup_acpi(unsigned int cpu)
+{
+ return -ENOTSUPP;
+}
+
static int cache_shared_cpu_map_setup(unsigned int cpu)
{
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
@@ -227,8 +232,8 @@ static int cache_shared_cpu_map_setup(unsigned int cpu)
if (of_have_populated_dt())
ret = cache_setup_of_node(cpu);
else if (!acpi_disabled)
- /* No cache property/hierarchy support yet in ACPI */
- ret = -ENOTSUPP;
+ ret = cache_setup_acpi(cpu);
+
if (ret)
return ret;
@@ -279,7 +284,8 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
cpumask_clear_cpu(cpu, &sib_leaf->shared_cpu_map);
cpumask_clear_cpu(sibling, &this_leaf->shared_cpu_map);
}
- of_node_put(this_leaf->fw_token);
+ if (of_have_populated_dt())
+ of_node_put(this_leaf->fw_token);
}
}
diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
index 0c6f658054d2..89397e30e269 100644
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@ -97,6 +97,23 @@ int func(unsigned int cpu) \
struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu);
int init_cache_level(unsigned int cpu);
int populate_cache_leaves(unsigned int cpu);
+int cache_setup_acpi(unsigned int cpu);
+#ifndef CONFIG_ACPI
+/*
+ * acpi_find_last_cache_level is only called on ACPI enabled
+ * platforms using the PPTT for topology. This means that if
+ * the platform supports other firmware configuration methods
+ * we need to stub out the call when ACPI is disabled.
+ * ACPI enabled platforms not using PPTT won't be making calls
+ * to this function so we need not worry about them.
+ */
+static inline int acpi_find_last_cache_level(unsigned int cpu)
+{
+ return 0;
+}
+#else
+int acpi_find_last_cache_level(unsigned int cpu);
+#endif
const struct attribute_group *cache_get_priv_group(struct cacheinfo *this_leaf);
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 07/12] drivers: base cacheinfo: Add support for ACPI based firmware tables
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-arm-kernel
Call ACPI cache parsing routines from base cacheinfo code if ACPI
is enabled. Also stub out cache_setup_acpi and acpi_find_last_cache_level
so that individual architectures can enable ACPI topology parsing.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/base/cacheinfo.c | 14 ++++++++++----
include/linux/cacheinfo.h | 17 +++++++++++++++++
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 597aacb233fc..2880e2ab01f5 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -206,7 +206,7 @@ static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
struct cacheinfo *sib_leaf)
{
/*
- * For non-DT systems, assume unique level 1 cache, system-wide
+ * For non-DT/ACPI systems, assume unique level 1 caches, system-wide
* shared caches for all other levels. This will be used only if
* arch specific code has not populated shared_cpu_map
*/
@@ -214,6 +214,11 @@ static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
}
#endif
+int __weak cache_setup_acpi(unsigned int cpu)
+{
+ return -ENOTSUPP;
+}
+
static int cache_shared_cpu_map_setup(unsigned int cpu)
{
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
@@ -227,8 +232,8 @@ static int cache_shared_cpu_map_setup(unsigned int cpu)
if (of_have_populated_dt())
ret = cache_setup_of_node(cpu);
else if (!acpi_disabled)
- /* No cache property/hierarchy support yet in ACPI */
- ret = -ENOTSUPP;
+ ret = cache_setup_acpi(cpu);
+
if (ret)
return ret;
@@ -279,7 +284,8 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
cpumask_clear_cpu(cpu, &sib_leaf->shared_cpu_map);
cpumask_clear_cpu(sibling, &this_leaf->shared_cpu_map);
}
- of_node_put(this_leaf->fw_token);
+ if (of_have_populated_dt())
+ of_node_put(this_leaf->fw_token);
}
}
diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
index 0c6f658054d2..89397e30e269 100644
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@ -97,6 +97,23 @@ int func(unsigned int cpu) \
struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu);
int init_cache_level(unsigned int cpu);
int populate_cache_leaves(unsigned int cpu);
+int cache_setup_acpi(unsigned int cpu);
+#ifndef CONFIG_ACPI
+/*
+ * acpi_find_last_cache_level is only called on ACPI enabled
+ * platforms using the PPTT for topology. This means that if
+ * the platform supports other firmware configuration methods
+ * we need to stub out the call when ACPI is disabled.
+ * ACPI enabled platforms not using PPTT won't be making calls
+ * to this function so we need not worry about them.
+ */
+static inline int acpi_find_last_cache_level(unsigned int cpu)
+{
+ return 0;
+}
+#else
+int acpi_find_last_cache_level(unsigned int cpu);
+#endif
const struct attribute_group *cache_get_priv_group(struct cacheinfo *this_leaf);
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 07/12] drivers: base cacheinfo: Add support for ACPI based firmware tables
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-riscv
Call ACPI cache parsing routines from base cacheinfo code if ACPI
is enabled. Also stub out cache_setup_acpi and acpi_find_last_cache_level
so that individual architectures can enable ACPI topology parsing.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/base/cacheinfo.c | 14 ++++++++++----
include/linux/cacheinfo.h | 17 +++++++++++++++++
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 597aacb233fc..2880e2ab01f5 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -206,7 +206,7 @@ static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
struct cacheinfo *sib_leaf)
{
/*
- * For non-DT systems, assume unique level 1 cache, system-wide
+ * For non-DT/ACPI systems, assume unique level 1 caches, system-wide
* shared caches for all other levels. This will be used only if
* arch specific code has not populated shared_cpu_map
*/
@@ -214,6 +214,11 @@ static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
}
#endif
+int __weak cache_setup_acpi(unsigned int cpu)
+{
+ return -ENOTSUPP;
+}
+
static int cache_shared_cpu_map_setup(unsigned int cpu)
{
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
@@ -227,8 +232,8 @@ static int cache_shared_cpu_map_setup(unsigned int cpu)
if (of_have_populated_dt())
ret = cache_setup_of_node(cpu);
else if (!acpi_disabled)
- /* No cache property/hierarchy support yet in ACPI */
- ret = -ENOTSUPP;
+ ret = cache_setup_acpi(cpu);
+
if (ret)
return ret;
@@ -279,7 +284,8 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
cpumask_clear_cpu(cpu, &sib_leaf->shared_cpu_map);
cpumask_clear_cpu(sibling, &this_leaf->shared_cpu_map);
}
- of_node_put(this_leaf->fw_token);
+ if (of_have_populated_dt())
+ of_node_put(this_leaf->fw_token);
}
}
diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
index 0c6f658054d2..89397e30e269 100644
--- a/include/linux/cacheinfo.h
+++ b/include/linux/cacheinfo.h
@@ -97,6 +97,23 @@ int func(unsigned int cpu) \
struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu);
int init_cache_level(unsigned int cpu);
int populate_cache_leaves(unsigned int cpu);
+int cache_setup_acpi(unsigned int cpu);
+#ifndef CONFIG_ACPI
+/*
+ * acpi_find_last_cache_level is only called on ACPI enabled
+ * platforms using the PPTT for topology. This means that if
+ * the platform supports other firmware configuration methods
+ * we need to stub out the call when ACPI is disabled.
+ * ACPI enabled platforms not using PPTT won't be making calls
+ * to this function so we need not worry about them.
+ */
+static inline int acpi_find_last_cache_level(unsigned int cpu)
+{
+ return 0;
+}
+#else
+int acpi_find_last_cache_level(unsigned int cpu);
+#endif
const struct attribute_group *cache_get_priv_group(struct cacheinfo *this_leaf);
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH v9 08/12] arm64: Add support for ACPI based firmware tables
2018-05-11 23:57 ` Jeremy Linton
(?)
@ 2018-05-11 23:58 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-acpi
Cc: Sudeep.Holla, linux-arm-kernel, Lorenzo.Pieralisi, hanjun.guo,
rjw, Will.Deacon, Catalin.Marinas, gregkh, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel, Jeremy Linton
The /sys cache entries should support ACPI/PPTT generated cache
topology information. For arm64, if ACPI is enabled, determine
the max number of cache levels and populate them using the PPTT
table if one is available.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/kernel/cacheinfo.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
index 380f2e2fbed5..0bf0a835122f 100644
--- a/arch/arm64/kernel/cacheinfo.c
+++ b/arch/arm64/kernel/cacheinfo.c
@@ -17,6 +17,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi.h>
#include <linux/cacheinfo.h>
#include <linux/of.h>
@@ -46,7 +47,7 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
static int __init_cache_level(unsigned int cpu)
{
- unsigned int ctype, level, leaves, of_level;
+ unsigned int ctype, level, leaves, fw_level;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
for (level = 1, leaves = 0; level <= MAX_CACHE_LEVEL; level++) {
@@ -59,15 +60,19 @@ static int __init_cache_level(unsigned int cpu)
leaves += (ctype == CACHE_TYPE_SEPARATE) ? 2 : 1;
}
- of_level = of_find_last_cache_level(cpu);
- if (level < of_level) {
+ if (acpi_disabled)
+ fw_level = of_find_last_cache_level(cpu);
+ else
+ fw_level = acpi_find_last_cache_level(cpu);
+
+ if (level < fw_level) {
/*
* some external caches not specified in CLIDR_EL1
* the information may be available in the device tree
* only unified external caches are considered here
*/
- leaves += (of_level - level);
- level = of_level;
+ leaves += (fw_level - level);
+ level = fw_level;
}
this_cpu_ci->num_levels = level;
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 08/12] arm64: Add support for ACPI based firmware tables
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-arm-kernel
The /sys cache entries should support ACPI/PPTT generated cache
topology information. For arm64, if ACPI is enabled, determine
the max number of cache levels and populate them using the PPTT
table if one is available.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/kernel/cacheinfo.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
index 380f2e2fbed5..0bf0a835122f 100644
--- a/arch/arm64/kernel/cacheinfo.c
+++ b/arch/arm64/kernel/cacheinfo.c
@@ -17,6 +17,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi.h>
#include <linux/cacheinfo.h>
#include <linux/of.h>
@@ -46,7 +47,7 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
static int __init_cache_level(unsigned int cpu)
{
- unsigned int ctype, level, leaves, of_level;
+ unsigned int ctype, level, leaves, fw_level;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
for (level = 1, leaves = 0; level <= MAX_CACHE_LEVEL; level++) {
@@ -59,15 +60,19 @@ static int __init_cache_level(unsigned int cpu)
leaves += (ctype == CACHE_TYPE_SEPARATE) ? 2 : 1;
}
- of_level = of_find_last_cache_level(cpu);
- if (level < of_level) {
+ if (acpi_disabled)
+ fw_level = of_find_last_cache_level(cpu);
+ else
+ fw_level = acpi_find_last_cache_level(cpu);
+
+ if (level < fw_level) {
/*
* some external caches not specified in CLIDR_EL1
* the information may be available in the device tree
* only unified external caches are considered here
*/
- leaves += (of_level - level);
- level = of_level;
+ leaves += (fw_level - level);
+ level = fw_level;
}
this_cpu_ci->num_levels = level;
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 08/12] arm64: Add support for ACPI based firmware tables
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-riscv
The /sys cache entries should support ACPI/PPTT generated cache
topology information. For arm64, if ACPI is enabled, determine
the max number of cache levels and populate them using the PPTT
table if one is available.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/kernel/cacheinfo.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
index 380f2e2fbed5..0bf0a835122f 100644
--- a/arch/arm64/kernel/cacheinfo.c
+++ b/arch/arm64/kernel/cacheinfo.c
@@ -17,6 +17,7 @@
* along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
+#include <linux/acpi.h>
#include <linux/cacheinfo.h>
#include <linux/of.h>
@@ -46,7 +47,7 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
static int __init_cache_level(unsigned int cpu)
{
- unsigned int ctype, level, leaves, of_level;
+ unsigned int ctype, level, leaves, fw_level;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
for (level = 1, leaves = 0; level <= MAX_CACHE_LEVEL; level++) {
@@ -59,15 +60,19 @@ static int __init_cache_level(unsigned int cpu)
leaves += (ctype == CACHE_TYPE_SEPARATE) ? 2 : 1;
}
- of_level = of_find_last_cache_level(cpu);
- if (level < of_level) {
+ if (acpi_disabled)
+ fw_level = of_find_last_cache_level(cpu);
+ else
+ fw_level = acpi_find_last_cache_level(cpu);
+
+ if (level < fw_level) {
/*
* some external caches not specified in CLIDR_EL1
* the information may be available in the device tree
* only unified external caches are considered here
*/
- leaves += (of_level - level);
- level = of_level;
+ leaves += (fw_level - level);
+ level = fw_level;
}
this_cpu_ci->num_levels = level;
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH v9 09/12] arm64: topology: rename cluster_id
2018-05-11 23:57 ` Jeremy Linton
(?)
@ 2018-05-11 23:58 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-acpi
Cc: Sudeep.Holla, linux-arm-kernel, Lorenzo.Pieralisi, hanjun.guo,
rjw, Will.Deacon, Catalin.Marinas, gregkh, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel, Jeremy Linton
The cluster concept isn't architecturally defined for arm64.
Lets match the name of the arm64 topology field to the kernel macro
that uses it.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Morten Rasmussen <morten.rasmussen@arm.com>
---
arch/arm64/include/asm/topology.h | 4 ++--
arch/arm64/kernel/topology.c | 26 +++++++++++++-------------
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index c4f2d50491eb..6b10459e6905 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -7,14 +7,14 @@
struct cpu_topology {
int thread_id;
int core_id;
- int cluster_id;
+ int package_id;
cpumask_t thread_sibling;
cpumask_t core_sibling;
};
extern struct cpu_topology cpu_topology[NR_CPUS];
-#define topology_physical_package_id(cpu) (cpu_topology[cpu].cluster_id)
+#define topology_physical_package_id(cpu) (cpu_topology[cpu].package_id)
#define topology_core_id(cpu) (cpu_topology[cpu].core_id)
#define topology_core_cpumask(cpu) (&cpu_topology[cpu].core_sibling)
#define topology_sibling_cpumask(cpu) (&cpu_topology[cpu].thread_sibling)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 21868530018e..dc18b1e53194 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -47,7 +47,7 @@ static int __init get_cpu_for_node(struct device_node *node)
return cpu;
}
-static int __init parse_core(struct device_node *core, int cluster_id,
+static int __init parse_core(struct device_node *core, int package_id,
int core_id)
{
char name[10];
@@ -63,7 +63,7 @@ static int __init parse_core(struct device_node *core, int cluster_id,
leaf = false;
cpu = get_cpu_for_node(t);
if (cpu >= 0) {
- cpu_topology[cpu].cluster_id = cluster_id;
+ cpu_topology[cpu].package_id = package_id;
cpu_topology[cpu].core_id = core_id;
cpu_topology[cpu].thread_id = i;
} else {
@@ -85,7 +85,7 @@ static int __init parse_core(struct device_node *core, int cluster_id,
return -EINVAL;
}
- cpu_topology[cpu].cluster_id = cluster_id;
+ cpu_topology[cpu].package_id = package_id;
cpu_topology[cpu].core_id = core_id;
} else if (leaf) {
pr_err("%pOF: Can't get CPU for leaf core\n", core);
@@ -101,7 +101,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth)
bool leaf = true;
bool has_cores = false;
struct device_node *c;
- static int cluster_id __initdata;
+ static int package_id __initdata;
int core_id = 0;
int i, ret;
@@ -140,7 +140,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth)
}
if (leaf) {
- ret = parse_core(c, cluster_id, core_id++);
+ ret = parse_core(c, package_id, core_id++);
} else {
pr_err("%pOF: Non-leaf cluster with core %s\n",
cluster, name);
@@ -158,7 +158,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth)
pr_warn("%pOF: empty cluster\n", cluster);
if (leaf)
- cluster_id++;
+ package_id++;
return 0;
}
@@ -194,7 +194,7 @@ static int __init parse_dt_topology(void)
* only mark cores described in the DT as possible.
*/
for_each_possible_cpu(cpu)
- if (cpu_topology[cpu].cluster_id == -1)
+ if (cpu_topology[cpu].package_id == -1)
ret = -EINVAL;
out_map:
@@ -224,7 +224,7 @@ static void update_siblings_masks(unsigned int cpuid)
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
- if (cpuid_topo->cluster_id != cpu_topo->cluster_id)
+ if (cpuid_topo->package_id != cpu_topo->package_id)
continue;
cpumask_set_cpu(cpuid, &cpu_topo->core_sibling);
@@ -245,7 +245,7 @@ void store_cpu_topology(unsigned int cpuid)
struct cpu_topology *cpuid_topo = &cpu_topology[cpuid];
u64 mpidr;
- if (cpuid_topo->cluster_id != -1)
+ if (cpuid_topo->package_id != -1)
goto topology_populated;
mpidr = read_cpuid_mpidr();
@@ -259,19 +259,19 @@ void store_cpu_topology(unsigned int cpuid)
/* Multiprocessor system : Multi-threads per core */
cpuid_topo->thread_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
- cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL(mpidr, 2) |
+ cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 2) |
MPIDR_AFFINITY_LEVEL(mpidr, 3) << 8;
} else {
/* Multiprocessor system : Single-thread per core */
cpuid_topo->thread_id = -1;
cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
- cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL(mpidr, 1) |
+ cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 1) |
MPIDR_AFFINITY_LEVEL(mpidr, 2) << 8 |
MPIDR_AFFINITY_LEVEL(mpidr, 3) << 16;
}
pr_debug("CPU%u: cluster %d core %d thread %d mpidr %#016llx\n",
- cpuid, cpuid_topo->cluster_id, cpuid_topo->core_id,
+ cpuid, cpuid_topo->package_id, cpuid_topo->core_id,
cpuid_topo->thread_id, mpidr);
topology_populated:
@@ -287,7 +287,7 @@ static void __init reset_cpu_topology(void)
cpu_topo->thread_id = -1;
cpu_topo->core_id = 0;
- cpu_topo->cluster_id = -1;
+ cpu_topo->package_id = -1;
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 09/12] arm64: topology: rename cluster_id
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-arm-kernel
The cluster concept isn't architecturally defined for arm64.
Lets match the name of the arm64 topology field to the kernel macro
that uses it.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Morten Rasmussen <morten.rasmussen@arm.com>
---
arch/arm64/include/asm/topology.h | 4 ++--
arch/arm64/kernel/topology.c | 26 +++++++++++++-------------
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index c4f2d50491eb..6b10459e6905 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -7,14 +7,14 @@
struct cpu_topology {
int thread_id;
int core_id;
- int cluster_id;
+ int package_id;
cpumask_t thread_sibling;
cpumask_t core_sibling;
};
extern struct cpu_topology cpu_topology[NR_CPUS];
-#define topology_physical_package_id(cpu) (cpu_topology[cpu].cluster_id)
+#define topology_physical_package_id(cpu) (cpu_topology[cpu].package_id)
#define topology_core_id(cpu) (cpu_topology[cpu].core_id)
#define topology_core_cpumask(cpu) (&cpu_topology[cpu].core_sibling)
#define topology_sibling_cpumask(cpu) (&cpu_topology[cpu].thread_sibling)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 21868530018e..dc18b1e53194 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -47,7 +47,7 @@ static int __init get_cpu_for_node(struct device_node *node)
return cpu;
}
-static int __init parse_core(struct device_node *core, int cluster_id,
+static int __init parse_core(struct device_node *core, int package_id,
int core_id)
{
char name[10];
@@ -63,7 +63,7 @@ static int __init parse_core(struct device_node *core, int cluster_id,
leaf = false;
cpu = get_cpu_for_node(t);
if (cpu >= 0) {
- cpu_topology[cpu].cluster_id = cluster_id;
+ cpu_topology[cpu].package_id = package_id;
cpu_topology[cpu].core_id = core_id;
cpu_topology[cpu].thread_id = i;
} else {
@@ -85,7 +85,7 @@ static int __init parse_core(struct device_node *core, int cluster_id,
return -EINVAL;
}
- cpu_topology[cpu].cluster_id = cluster_id;
+ cpu_topology[cpu].package_id = package_id;
cpu_topology[cpu].core_id = core_id;
} else if (leaf) {
pr_err("%pOF: Can't get CPU for leaf core\n", core);
@@ -101,7 +101,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth)
bool leaf = true;
bool has_cores = false;
struct device_node *c;
- static int cluster_id __initdata;
+ static int package_id __initdata;
int core_id = 0;
int i, ret;
@@ -140,7 +140,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth)
}
if (leaf) {
- ret = parse_core(c, cluster_id, core_id++);
+ ret = parse_core(c, package_id, core_id++);
} else {
pr_err("%pOF: Non-leaf cluster with core %s\n",
cluster, name);
@@ -158,7 +158,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth)
pr_warn("%pOF: empty cluster\n", cluster);
if (leaf)
- cluster_id++;
+ package_id++;
return 0;
}
@@ -194,7 +194,7 @@ static int __init parse_dt_topology(void)
* only mark cores described in the DT as possible.
*/
for_each_possible_cpu(cpu)
- if (cpu_topology[cpu].cluster_id == -1)
+ if (cpu_topology[cpu].package_id == -1)
ret = -EINVAL;
out_map:
@@ -224,7 +224,7 @@ static void update_siblings_masks(unsigned int cpuid)
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
- if (cpuid_topo->cluster_id != cpu_topo->cluster_id)
+ if (cpuid_topo->package_id != cpu_topo->package_id)
continue;
cpumask_set_cpu(cpuid, &cpu_topo->core_sibling);
@@ -245,7 +245,7 @@ void store_cpu_topology(unsigned int cpuid)
struct cpu_topology *cpuid_topo = &cpu_topology[cpuid];
u64 mpidr;
- if (cpuid_topo->cluster_id != -1)
+ if (cpuid_topo->package_id != -1)
goto topology_populated;
mpidr = read_cpuid_mpidr();
@@ -259,19 +259,19 @@ void store_cpu_topology(unsigned int cpuid)
/* Multiprocessor system : Multi-threads per core */
cpuid_topo->thread_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
- cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL(mpidr, 2) |
+ cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 2) |
MPIDR_AFFINITY_LEVEL(mpidr, 3) << 8;
} else {
/* Multiprocessor system : Single-thread per core */
cpuid_topo->thread_id = -1;
cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
- cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL(mpidr, 1) |
+ cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 1) |
MPIDR_AFFINITY_LEVEL(mpidr, 2) << 8 |
MPIDR_AFFINITY_LEVEL(mpidr, 3) << 16;
}
pr_debug("CPU%u: cluster %d core %d thread %d mpidr %#016llx\n",
- cpuid, cpuid_topo->cluster_id, cpuid_topo->core_id,
+ cpuid, cpuid_topo->package_id, cpuid_topo->core_id,
cpuid_topo->thread_id, mpidr);
topology_populated:
@@ -287,7 +287,7 @@ static void __init reset_cpu_topology(void)
cpu_topo->thread_id = -1;
cpu_topo->core_id = 0;
- cpu_topo->cluster_id = -1;
+ cpu_topo->package_id = -1;
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 09/12] arm64: topology: rename cluster_id
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-riscv
The cluster concept isn't architecturally defined for arm64.
Lets match the name of the arm64 topology field to the kernel macro
that uses it.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Morten Rasmussen <morten.rasmussen@arm.com>
---
arch/arm64/include/asm/topology.h | 4 ++--
arch/arm64/kernel/topology.c | 26 +++++++++++++-------------
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index c4f2d50491eb..6b10459e6905 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -7,14 +7,14 @@
struct cpu_topology {
int thread_id;
int core_id;
- int cluster_id;
+ int package_id;
cpumask_t thread_sibling;
cpumask_t core_sibling;
};
extern struct cpu_topology cpu_topology[NR_CPUS];
-#define topology_physical_package_id(cpu) (cpu_topology[cpu].cluster_id)
+#define topology_physical_package_id(cpu) (cpu_topology[cpu].package_id)
#define topology_core_id(cpu) (cpu_topology[cpu].core_id)
#define topology_core_cpumask(cpu) (&cpu_topology[cpu].core_sibling)
#define topology_sibling_cpumask(cpu) (&cpu_topology[cpu].thread_sibling)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 21868530018e..dc18b1e53194 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -47,7 +47,7 @@ static int __init get_cpu_for_node(struct device_node *node)
return cpu;
}
-static int __init parse_core(struct device_node *core, int cluster_id,
+static int __init parse_core(struct device_node *core, int package_id,
int core_id)
{
char name[10];
@@ -63,7 +63,7 @@ static int __init parse_core(struct device_node *core, int cluster_id,
leaf = false;
cpu = get_cpu_for_node(t);
if (cpu >= 0) {
- cpu_topology[cpu].cluster_id = cluster_id;
+ cpu_topology[cpu].package_id = package_id;
cpu_topology[cpu].core_id = core_id;
cpu_topology[cpu].thread_id = i;
} else {
@@ -85,7 +85,7 @@ static int __init parse_core(struct device_node *core, int cluster_id,
return -EINVAL;
}
- cpu_topology[cpu].cluster_id = cluster_id;
+ cpu_topology[cpu].package_id = package_id;
cpu_topology[cpu].core_id = core_id;
} else if (leaf) {
pr_err("%pOF: Can't get CPU for leaf core\n", core);
@@ -101,7 +101,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth)
bool leaf = true;
bool has_cores = false;
struct device_node *c;
- static int cluster_id __initdata;
+ static int package_id __initdata;
int core_id = 0;
int i, ret;
@@ -140,7 +140,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth)
}
if (leaf) {
- ret = parse_core(c, cluster_id, core_id++);
+ ret = parse_core(c, package_id, core_id++);
} else {
pr_err("%pOF: Non-leaf cluster with core %s\n",
cluster, name);
@@ -158,7 +158,7 @@ static int __init parse_cluster(struct device_node *cluster, int depth)
pr_warn("%pOF: empty cluster\n", cluster);
if (leaf)
- cluster_id++;
+ package_id++;
return 0;
}
@@ -194,7 +194,7 @@ static int __init parse_dt_topology(void)
* only mark cores described in the DT as possible.
*/
for_each_possible_cpu(cpu)
- if (cpu_topology[cpu].cluster_id == -1)
+ if (cpu_topology[cpu].package_id == -1)
ret = -EINVAL;
out_map:
@@ -224,7 +224,7 @@ static void update_siblings_masks(unsigned int cpuid)
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
- if (cpuid_topo->cluster_id != cpu_topo->cluster_id)
+ if (cpuid_topo->package_id != cpu_topo->package_id)
continue;
cpumask_set_cpu(cpuid, &cpu_topo->core_sibling);
@@ -245,7 +245,7 @@ void store_cpu_topology(unsigned int cpuid)
struct cpu_topology *cpuid_topo = &cpu_topology[cpuid];
u64 mpidr;
- if (cpuid_topo->cluster_id != -1)
+ if (cpuid_topo->package_id != -1)
goto topology_populated;
mpidr = read_cpuid_mpidr();
@@ -259,19 +259,19 @@ void store_cpu_topology(unsigned int cpuid)
/* Multiprocessor system : Multi-threads per core */
cpuid_topo->thread_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 1);
- cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL(mpidr, 2) |
+ cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 2) |
MPIDR_AFFINITY_LEVEL(mpidr, 3) << 8;
} else {
/* Multiprocessor system : Single-thread per core */
cpuid_topo->thread_id = -1;
cpuid_topo->core_id = MPIDR_AFFINITY_LEVEL(mpidr, 0);
- cpuid_topo->cluster_id = MPIDR_AFFINITY_LEVEL(mpidr, 1) |
+ cpuid_topo->package_id = MPIDR_AFFINITY_LEVEL(mpidr, 1) |
MPIDR_AFFINITY_LEVEL(mpidr, 2) << 8 |
MPIDR_AFFINITY_LEVEL(mpidr, 3) << 16;
}
pr_debug("CPU%u: cluster %d core %d thread %d mpidr %#016llx\n",
- cpuid, cpuid_topo->cluster_id, cpuid_topo->core_id,
+ cpuid, cpuid_topo->package_id, cpuid_topo->core_id,
cpuid_topo->thread_id, mpidr);
topology_populated:
@@ -287,7 +287,7 @@ static void __init reset_cpu_topology(void)
cpu_topo->thread_id = -1;
cpu_topo->core_id = 0;
- cpu_topo->cluster_id = -1;
+ cpu_topo->package_id = -1;
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH v9 10/12] arm64: topology: enable ACPI/PPTT based CPU topology
2018-05-11 23:57 ` Jeremy Linton
(?)
@ 2018-05-11 23:58 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-acpi
Cc: Sudeep.Holla, linux-arm-kernel, Lorenzo.Pieralisi, hanjun.guo,
rjw, Will.Deacon, Catalin.Marinas, gregkh, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel, Jeremy Linton
Propagate the topology information from the PPTT tree to the
cpu_topology array. We can get the thread id and core_id by assuming
certain levels of the PPTT tree correspond to those concepts.
The package_id is flagged in the tree and can be found by calling
find_acpi_cpu_topology_package() which terminates
its search when it finds an ACPI node flagged as the physical
package. If the tree doesn't contain enough levels to represent
all of the requested levels then the root node will be returned
for all subsequent levels.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Morten Rasmussen <morten.rasmussen@arm.com>
---
arch/arm64/kernel/topology.c | 45 +++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index dc18b1e53194..047d98e68502 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -11,6 +11,7 @@
* for more details.
*/
+#include <linux/acpi.h>
#include <linux/arch_topology.h>
#include <linux/cpu.h>
#include <linux/cpumask.h>
@@ -22,6 +23,7 @@
#include <linux/sched.h>
#include <linux/sched/topology.h>
#include <linux/slab.h>
+#include <linux/smp.h>
#include <linux/string.h>
#include <asm/cpu.h>
@@ -296,6 +298,45 @@ static void __init reset_cpu_topology(void)
}
}
+#ifdef CONFIG_ACPI
+/*
+ * Propagate the topology information of the processor_topology_node tree to the
+ * cpu_topology array.
+ */
+static int __init parse_acpi_topology(void)
+{
+ bool is_threaded;
+ int cpu, topology_id;
+
+ is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
+
+ for_each_possible_cpu(cpu) {
+ topology_id = find_acpi_cpu_topology(cpu, 0);
+ if (topology_id < 0)
+ return topology_id;
+
+ if (is_threaded) {
+ cpu_topology[cpu].thread_id = topology_id;
+ topology_id = find_acpi_cpu_topology(cpu, 1);
+ cpu_topology[cpu].core_id = topology_id;
+ } else {
+ cpu_topology[cpu].thread_id = -1;
+ cpu_topology[cpu].core_id = topology_id;
+ }
+ topology_id = find_acpi_cpu_topology_package(cpu);
+ cpu_topology[cpu].package_id = topology_id;
+ }
+
+ return 0;
+}
+
+#else
+static inline int __init parse_acpi_topology(void)
+{
+ return -EINVAL;
+}
+#endif
+
void __init init_cpu_topology(void)
{
reset_cpu_topology();
@@ -304,6 +345,8 @@ void __init init_cpu_topology(void)
* Discard anything that was parsed if we hit an error so we
* don't use partial information.
*/
- if (of_have_populated_dt() && parse_dt_topology())
+ if (!acpi_disabled && parse_acpi_topology())
+ reset_cpu_topology();
+ else if (of_have_populated_dt() && parse_dt_topology())
reset_cpu_topology();
}
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 10/12] arm64: topology: enable ACPI/PPTT based CPU topology
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-arm-kernel
Propagate the topology information from the PPTT tree to the
cpu_topology array. We can get the thread id and core_id by assuming
certain levels of the PPTT tree correspond to those concepts.
The package_id is flagged in the tree and can be found by calling
find_acpi_cpu_topology_package() which terminates
its search when it finds an ACPI node flagged as the physical
package. If the tree doesn't contain enough levels to represent
all of the requested levels then the root node will be returned
for all subsequent levels.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Morten Rasmussen <morten.rasmussen@arm.com>
---
arch/arm64/kernel/topology.c | 45 +++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index dc18b1e53194..047d98e68502 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -11,6 +11,7 @@
* for more details.
*/
+#include <linux/acpi.h>
#include <linux/arch_topology.h>
#include <linux/cpu.h>
#include <linux/cpumask.h>
@@ -22,6 +23,7 @@
#include <linux/sched.h>
#include <linux/sched/topology.h>
#include <linux/slab.h>
+#include <linux/smp.h>
#include <linux/string.h>
#include <asm/cpu.h>
@@ -296,6 +298,45 @@ static void __init reset_cpu_topology(void)
}
}
+#ifdef CONFIG_ACPI
+/*
+ * Propagate the topology information of the processor_topology_node tree to the
+ * cpu_topology array.
+ */
+static int __init parse_acpi_topology(void)
+{
+ bool is_threaded;
+ int cpu, topology_id;
+
+ is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
+
+ for_each_possible_cpu(cpu) {
+ topology_id = find_acpi_cpu_topology(cpu, 0);
+ if (topology_id < 0)
+ return topology_id;
+
+ if (is_threaded) {
+ cpu_topology[cpu].thread_id = topology_id;
+ topology_id = find_acpi_cpu_topology(cpu, 1);
+ cpu_topology[cpu].core_id = topology_id;
+ } else {
+ cpu_topology[cpu].thread_id = -1;
+ cpu_topology[cpu].core_id = topology_id;
+ }
+ topology_id = find_acpi_cpu_topology_package(cpu);
+ cpu_topology[cpu].package_id = topology_id;
+ }
+
+ return 0;
+}
+
+#else
+static inline int __init parse_acpi_topology(void)
+{
+ return -EINVAL;
+}
+#endif
+
void __init init_cpu_topology(void)
{
reset_cpu_topology();
@@ -304,6 +345,8 @@ void __init init_cpu_topology(void)
* Discard anything that was parsed if we hit an error so we
* don't use partial information.
*/
- if (of_have_populated_dt() && parse_dt_topology())
+ if (!acpi_disabled && parse_acpi_topology())
+ reset_cpu_topology();
+ else if (of_have_populated_dt() && parse_dt_topology())
reset_cpu_topology();
}
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 10/12] arm64: topology: enable ACPI/PPTT based CPU topology
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-riscv
Propagate the topology information from the PPTT tree to the
cpu_topology array. We can get the thread id and core_id by assuming
certain levels of the PPTT tree correspond to those concepts.
The package_id is flagged in the tree and can be found by calling
find_acpi_cpu_topology_package() which terminates
its search when it finds an ACPI node flagged as the physical
package. If the tree doesn't contain enough levels to represent
all of the requested levels then the root node will be returned
for all subsequent levels.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Morten Rasmussen <morten.rasmussen@arm.com>
---
arch/arm64/kernel/topology.c | 45 +++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 44 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index dc18b1e53194..047d98e68502 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -11,6 +11,7 @@
* for more details.
*/
+#include <linux/acpi.h>
#include <linux/arch_topology.h>
#include <linux/cpu.h>
#include <linux/cpumask.h>
@@ -22,6 +23,7 @@
#include <linux/sched.h>
#include <linux/sched/topology.h>
#include <linux/slab.h>
+#include <linux/smp.h>
#include <linux/string.h>
#include <asm/cpu.h>
@@ -296,6 +298,45 @@ static void __init reset_cpu_topology(void)
}
}
+#ifdef CONFIG_ACPI
+/*
+ * Propagate the topology information of the processor_topology_node tree to the
+ * cpu_topology array.
+ */
+static int __init parse_acpi_topology(void)
+{
+ bool is_threaded;
+ int cpu, topology_id;
+
+ is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
+
+ for_each_possible_cpu(cpu) {
+ topology_id = find_acpi_cpu_topology(cpu, 0);
+ if (topology_id < 0)
+ return topology_id;
+
+ if (is_threaded) {
+ cpu_topology[cpu].thread_id = topology_id;
+ topology_id = find_acpi_cpu_topology(cpu, 1);
+ cpu_topology[cpu].core_id = topology_id;
+ } else {
+ cpu_topology[cpu].thread_id = -1;
+ cpu_topology[cpu].core_id = topology_id;
+ }
+ topology_id = find_acpi_cpu_topology_package(cpu);
+ cpu_topology[cpu].package_id = topology_id;
+ }
+
+ return 0;
+}
+
+#else
+static inline int __init parse_acpi_topology(void)
+{
+ return -EINVAL;
+}
+#endif
+
void __init init_cpu_topology(void)
{
reset_cpu_topology();
@@ -304,6 +345,8 @@ void __init init_cpu_topology(void)
* Discard anything that was parsed if we hit an error so we
* don't use partial information.
*/
- if (of_have_populated_dt() && parse_dt_topology())
+ if (!acpi_disabled && parse_acpi_topology())
+ reset_cpu_topology();
+ else if (of_have_populated_dt() && parse_dt_topology())
reset_cpu_topology();
}
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH v9 11/12] ACPI: Add PPTT to injectable table list
2018-05-11 23:57 ` Jeremy Linton
(?)
@ 2018-05-11 23:58 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-acpi
Cc: Sudeep.Holla, linux-arm-kernel, Lorenzo.Pieralisi, hanjun.guo,
rjw, Will.Deacon, Catalin.Marinas, gregkh, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel, Jeremy Linton,
Geoffrey Blake
Add ACPI_SIG_PPTT to the table so initrd's can override the
system topology.
Signed-off-by: Geoffrey Blake <geoffrey.blake@arm.com>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/acpi/tables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 849c4fb19b03..30d93bf7c6a2 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -457,7 +457,7 @@ static const char * const table_sigs[] = {
ACPI_SIG_UEFI, ACPI_SIG_WAET, ACPI_SIG_WDAT, ACPI_SIG_WDDT,
ACPI_SIG_WDRT, ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_PSDT,
ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, ACPI_SIG_IORT,
- ACPI_SIG_NFIT, ACPI_SIG_HMAT, NULL };
+ ACPI_SIG_NFIT, ACPI_SIG_HMAT, ACPI_SIG_PPTT, NULL };
#define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 11/12] ACPI: Add PPTT to injectable table list
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-arm-kernel
Add ACPI_SIG_PPTT to the table so initrd's can override the
system topology.
Signed-off-by: Geoffrey Blake <geoffrey.blake@arm.com>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/acpi/tables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 849c4fb19b03..30d93bf7c6a2 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -457,7 +457,7 @@ static const char * const table_sigs[] = {
ACPI_SIG_UEFI, ACPI_SIG_WAET, ACPI_SIG_WDAT, ACPI_SIG_WDDT,
ACPI_SIG_WDRT, ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_PSDT,
ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, ACPI_SIG_IORT,
- ACPI_SIG_NFIT, ACPI_SIG_HMAT, NULL };
+ ACPI_SIG_NFIT, ACPI_SIG_HMAT, ACPI_SIG_PPTT, NULL };
#define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 11/12] ACPI: Add PPTT to injectable table list
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-riscv
Add ACPI_SIG_PPTT to the table so initrd's can override the
system topology.
Signed-off-by: Geoffrey Blake <geoffrey.blake@arm.com>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/acpi/tables.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 849c4fb19b03..30d93bf7c6a2 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -457,7 +457,7 @@ static const char * const table_sigs[] = {
ACPI_SIG_UEFI, ACPI_SIG_WAET, ACPI_SIG_WDAT, ACPI_SIG_WDDT,
ACPI_SIG_WDRT, ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_PSDT,
ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, ACPI_SIG_IORT,
- ACPI_SIG_NFIT, ACPI_SIG_HMAT, NULL };
+ ACPI_SIG_NFIT, ACPI_SIG_HMAT, ACPI_SIG_PPTT, NULL };
#define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* Re: [PATCH v9 11/12] ACPI: Add PPTT to injectable table list
2018-05-11 23:58 ` Jeremy Linton
(?)
(?)
@ 2018-05-12 10:10 ` Rafael J. Wysocki
-1 siblings, 0 replies; 185+ messages in thread
From: Rafael J. Wysocki @ 2018-05-12 10:10 UTC (permalink / raw)
To: Jeremy Linton
Cc: ACPI Devel Maling List, Sudeep Holla, Linux ARM,
Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, wangxiongfeng2, vkilari,
Al Stone, Dietmar Eggemann, Morten Rasmussen, palmer, Len Brown,
John Garry
On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> Add ACPI_SIG_PPTT to the table so initrd's can override the
> system topology.
>
> Signed-off-by: Geoffrey Blake <geoffrey.blake@arm.com>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
I'm assuming that this will be routed along with the rest of the series, so
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/acpi/tables.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index 849c4fb19b03..30d93bf7c6a2 100644
> --- a/drivers/acpi/tables.c
> +++ b/drivers/acpi/tables.c
> @@ -457,7 +457,7 @@ static const char * const table_sigs[] = {
> ACPI_SIG_UEFI, ACPI_SIG_WAET, ACPI_SIG_WDAT, ACPI_SIG_WDDT,
> ACPI_SIG_WDRT, ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_PSDT,
> ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, ACPI_SIG_IORT,
> - ACPI_SIG_NFIT, ACPI_SIG_HMAT, NULL };
> + ACPI_SIG_NFIT, ACPI_SIG_HMAT, ACPI_SIG_PPTT, NULL };
>
> #define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
>
> --
> 2.13.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 11/12] ACPI: Add PPTT to injectable table list
@ 2018-05-12 10:10 ` Rafael J. Wysocki
0 siblings, 0 replies; 185+ messages in thread
From: Rafael J. Wysocki @ 2018-05-12 10:10 UTC (permalink / raw)
To: linux-arm-kernel
On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> Add ACPI_SIG_PPTT to the table so initrd's can override the
> system topology.
>
> Signed-off-by: Geoffrey Blake <geoffrey.blake@arm.com>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
I'm assuming that this will be routed along with the rest of the series, so
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/acpi/tables.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index 849c4fb19b03..30d93bf7c6a2 100644
> --- a/drivers/acpi/tables.c
> +++ b/drivers/acpi/tables.c
> @@ -457,7 +457,7 @@ static const char * const table_sigs[] = {
> ACPI_SIG_UEFI, ACPI_SIG_WAET, ACPI_SIG_WDAT, ACPI_SIG_WDDT,
> ACPI_SIG_WDRT, ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_PSDT,
> ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, ACPI_SIG_IORT,
> - ACPI_SIG_NFIT, ACPI_SIG_HMAT, NULL };
> + ACPI_SIG_NFIT, ACPI_SIG_HMAT, ACPI_SIG_PPTT, NULL };
>
> #define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
>
> --
> 2.13.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 11/12] ACPI: Add PPTT to injectable table list
@ 2018-05-12 10:10 ` Rafael J. Wysocki
0 siblings, 0 replies; 185+ messages in thread
From: Rafael J. Wysocki @ 2018-05-12 10:10 UTC (permalink / raw)
To: linux-riscv
On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> Add ACPI_SIG_PPTT to the table so initrd's can override the
> system topology.
>
> Signed-off-by: Geoffrey Blake <geoffrey.blake@arm.com>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
I'm assuming that this will be routed along with the rest of the series, so
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/acpi/tables.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index 849c4fb19b03..30d93bf7c6a2 100644
> --- a/drivers/acpi/tables.c
> +++ b/drivers/acpi/tables.c
> @@ -457,7 +457,7 @@ static const char * const table_sigs[] = {
> ACPI_SIG_UEFI, ACPI_SIG_WAET, ACPI_SIG_WDAT, ACPI_SIG_WDDT,
> ACPI_SIG_WDRT, ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_PSDT,
> ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, ACPI_SIG_IORT,
> - ACPI_SIG_NFIT, ACPI_SIG_HMAT, NULL };
> + ACPI_SIG_NFIT, ACPI_SIG_HMAT, ACPI_SIG_PPTT, NULL };
>
> #define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
>
> --
> 2.13.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 11/12] ACPI: Add PPTT to injectable table list
@ 2018-05-12 10:10 ` Rafael J. Wysocki
0 siblings, 0 replies; 185+ messages in thread
From: Rafael J. Wysocki @ 2018-05-12 10:10 UTC (permalink / raw)
To: Jeremy Linton
Cc: ACPI Devel Maling List, Sudeep Holla, Linux ARM,
Lorenzo Pieralisi, Hanjun Guo, Rafael J. Wysocki, Will Deacon,
Catalin Marinas, Greg Kroah-Hartman, Mark Rutland,
Linux Kernel Mailing List, linux-riscv, wangxiongfeng2, vkilari,
Al Stone, Dietmar Eggemann, Morten Rasmussen, palmer, Len Brown,
John Garry, austinwc, tnowicki, jhugo, Ard Biesheuvel,
Geoffrey Blake
On Sat, May 12, 2018 at 1:58 AM, Jeremy Linton <jeremy.linton@arm.com> wrote:
> Add ACPI_SIG_PPTT to the table so initrd's can override the
> system topology.
>
> Signed-off-by: Geoffrey Blake <geoffrey.blake@arm.com>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
> Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
I'm assuming that this will be routed along with the rest of the series, so
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> drivers/acpi/tables.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
> index 849c4fb19b03..30d93bf7c6a2 100644
> --- a/drivers/acpi/tables.c
> +++ b/drivers/acpi/tables.c
> @@ -457,7 +457,7 @@ static const char * const table_sigs[] = {
> ACPI_SIG_UEFI, ACPI_SIG_WAET, ACPI_SIG_WDAT, ACPI_SIG_WDDT,
> ACPI_SIG_WDRT, ACPI_SIG_DSDT, ACPI_SIG_FADT, ACPI_SIG_PSDT,
> ACPI_SIG_RSDT, ACPI_SIG_XSDT, ACPI_SIG_SSDT, ACPI_SIG_IORT,
> - ACPI_SIG_NFIT, ACPI_SIG_HMAT, NULL };
> + ACPI_SIG_NFIT, ACPI_SIG_HMAT, ACPI_SIG_PPTT, NULL };
>
> #define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
>
> --
> 2.13.6
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 12/12] arm64: topology: divorce MC scheduling domain from core_siblings
2018-05-11 23:57 ` Jeremy Linton
(?)
@ 2018-05-11 23:58 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-acpi
Cc: Sudeep.Holla, linux-arm-kernel, Lorenzo.Pieralisi, hanjun.guo,
rjw, Will.Deacon, Catalin.Marinas, gregkh, Mark.Rutland,
linux-kernel, linux-riscv, wangxiongfeng2, vkilari, ahs3,
Dietmar.Eggemann, Morten.Rasmussen, palmer, lenb, john.garry,
austinwc, tnowicki, jhugo, ard.biesheuvel, Jeremy Linton
Now that we have an accurate view of the physical topology
we need to represent it correctly to the scheduler. Generally MC
should equal the LLC in the system, but there are a number of
special cases that need to be dealt with.
In the case of NUMA in socket, we need to assure that the sched
domain we build for the MC layer isn't larger than the DIE above it.
Similarly for LLC's that might exist in cross socket interconnect or
directory hardware we need to assure that MC is shrunk to the socket
or NUMA node.
This patch builds a sibling mask for the LLC, and then picks the
smallest of LLC, socket siblings, or NUMA node siblings, which
gives us the behavior described above. This is ever so slightly
different than the similar alternative where we look for a cache
layer less than or equal to the socket/NUMA siblings.
The logic to pick the MC layer affects all arm64 machines, but
only changes the behavior for DT/MPIDR systems if the NUMA domain
is smaller than the core siblings (generally set to the cluster).
Potentially this fixes a possible bug in DT systems, but really
it only affects ACPI systems where the core siblings is correctly
set to the socket siblings. Thus all currently available ACPI
systems should have MC equal to LLC, including the NUMA in socket
machines where the LLC is partitioned between the NUMA nodes.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Morten Rasmussen <morten.rasmussen@arm.com>
---
arch/arm64/include/asm/topology.h | 2 ++
arch/arm64/kernel/topology.c | 36 +++++++++++++++++++++++++++++++++++-
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index 6b10459e6905..df48212f767b 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -8,8 +8,10 @@ struct cpu_topology {
int thread_id;
int core_id;
int package_id;
+ int llc_id;
cpumask_t thread_sibling;
cpumask_t core_sibling;
+ cpumask_t llc_siblings;
};
extern struct cpu_topology cpu_topology[NR_CPUS];
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 047d98e68502..7415c166281f 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -13,6 +13,7 @@
#include <linux/acpi.h>
#include <linux/arch_topology.h>
+#include <linux/cacheinfo.h>
#include <linux/cpu.h>
#include <linux/cpumask.h>
#include <linux/init.h>
@@ -214,7 +215,19 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- return &cpu_topology[cpu].core_sibling;
+ const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
+
+ /* Find the smaller of NUMA, core or LLC siblings */
+ if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
+ /* not numa in package, lets use the package siblings */
+ core_mask = &cpu_topology[cpu].core_sibling;
+ }
+ if (cpu_topology[cpu].llc_id != -1) {
+ if (cpumask_subset(&cpu_topology[cpu].llc_siblings, core_mask))
+ core_mask = &cpu_topology[cpu].llc_siblings;
+ }
+
+ return core_mask;
}
static void update_siblings_masks(unsigned int cpuid)
@@ -226,6 +239,9 @@ static void update_siblings_masks(unsigned int cpuid)
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
+ if (cpuid_topo->llc_id == cpu_topo->llc_id)
+ cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
+
if (cpuid_topo->package_id != cpu_topo->package_id)
continue;
@@ -291,6 +307,10 @@ static void __init reset_cpu_topology(void)
cpu_topo->core_id = 0;
cpu_topo->package_id = -1;
+ cpu_topo->llc_id = -1;
+ cpumask_clear(&cpu_topo->llc_siblings);
+ cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
+
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
@@ -311,6 +331,8 @@ static int __init parse_acpi_topology(void)
is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
for_each_possible_cpu(cpu) {
+ int i, cache_id;
+
topology_id = find_acpi_cpu_topology(cpu, 0);
if (topology_id < 0)
return topology_id;
@@ -325,6 +347,18 @@ static int __init parse_acpi_topology(void)
}
topology_id = find_acpi_cpu_topology_package(cpu);
cpu_topology[cpu].package_id = topology_id;
+
+ i = acpi_find_last_cache_level(cpu);
+
+ if (i > 0) {
+ /*
+ * this is the only part of cpu_topology that has
+ * a direct relationship with the cache topology
+ */
+ cache_id = find_acpi_cpu_cache_topology(cpu, i);
+ if (cache_id > 0)
+ cpu_topology[cpu].llc_id = cache_id;
+ }
}
return 0;
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 12/12] arm64: topology: divorce MC scheduling domain from core_siblings
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-arm-kernel
Now that we have an accurate view of the physical topology
we need to represent it correctly to the scheduler. Generally MC
should equal the LLC in the system, but there are a number of
special cases that need to be dealt with.
In the case of NUMA in socket, we need to assure that the sched
domain we build for the MC layer isn't larger than the DIE above it.
Similarly for LLC's that might exist in cross socket interconnect or
directory hardware we need to assure that MC is shrunk to the socket
or NUMA node.
This patch builds a sibling mask for the LLC, and then picks the
smallest of LLC, socket siblings, or NUMA node siblings, which
gives us the behavior described above. This is ever so slightly
different than the similar alternative where we look for a cache
layer less than or equal to the socket/NUMA siblings.
The logic to pick the MC layer affects all arm64 machines, but
only changes the behavior for DT/MPIDR systems if the NUMA domain
is smaller than the core siblings (generally set to the cluster).
Potentially this fixes a possible bug in DT systems, but really
it only affects ACPI systems where the core siblings is correctly
set to the socket siblings. Thus all currently available ACPI
systems should have MC equal to LLC, including the NUMA in socket
machines where the LLC is partitioned between the NUMA nodes.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Morten Rasmussen <morten.rasmussen@arm.com>
---
arch/arm64/include/asm/topology.h | 2 ++
arch/arm64/kernel/topology.c | 36 +++++++++++++++++++++++++++++++++++-
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index 6b10459e6905..df48212f767b 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -8,8 +8,10 @@ struct cpu_topology {
int thread_id;
int core_id;
int package_id;
+ int llc_id;
cpumask_t thread_sibling;
cpumask_t core_sibling;
+ cpumask_t llc_siblings;
};
extern struct cpu_topology cpu_topology[NR_CPUS];
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 047d98e68502..7415c166281f 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -13,6 +13,7 @@
#include <linux/acpi.h>
#include <linux/arch_topology.h>
+#include <linux/cacheinfo.h>
#include <linux/cpu.h>
#include <linux/cpumask.h>
#include <linux/init.h>
@@ -214,7 +215,19 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- return &cpu_topology[cpu].core_sibling;
+ const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
+
+ /* Find the smaller of NUMA, core or LLC siblings */
+ if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
+ /* not numa in package, lets use the package siblings */
+ core_mask = &cpu_topology[cpu].core_sibling;
+ }
+ if (cpu_topology[cpu].llc_id != -1) {
+ if (cpumask_subset(&cpu_topology[cpu].llc_siblings, core_mask))
+ core_mask = &cpu_topology[cpu].llc_siblings;
+ }
+
+ return core_mask;
}
static void update_siblings_masks(unsigned int cpuid)
@@ -226,6 +239,9 @@ static void update_siblings_masks(unsigned int cpuid)
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
+ if (cpuid_topo->llc_id == cpu_topo->llc_id)
+ cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
+
if (cpuid_topo->package_id != cpu_topo->package_id)
continue;
@@ -291,6 +307,10 @@ static void __init reset_cpu_topology(void)
cpu_topo->core_id = 0;
cpu_topo->package_id = -1;
+ cpu_topo->llc_id = -1;
+ cpumask_clear(&cpu_topo->llc_siblings);
+ cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
+
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
@@ -311,6 +331,8 @@ static int __init parse_acpi_topology(void)
is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
for_each_possible_cpu(cpu) {
+ int i, cache_id;
+
topology_id = find_acpi_cpu_topology(cpu, 0);
if (topology_id < 0)
return topology_id;
@@ -325,6 +347,18 @@ static int __init parse_acpi_topology(void)
}
topology_id = find_acpi_cpu_topology_package(cpu);
cpu_topology[cpu].package_id = topology_id;
+
+ i = acpi_find_last_cache_level(cpu);
+
+ if (i > 0) {
+ /*
+ * this is the only part of cpu_topology that has
+ * a direct relationship with the cache topology
+ */
+ cache_id = find_acpi_cpu_cache_topology(cpu, i);
+ if (cache_id > 0)
+ cpu_topology[cpu].llc_id = cache_id;
+ }
}
return 0;
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 12/12] arm64: topology: divorce MC scheduling domain from core_siblings
@ 2018-05-11 23:58 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-11 23:58 UTC (permalink / raw)
To: linux-riscv
Now that we have an accurate view of the physical topology
we need to represent it correctly to the scheduler. Generally MC
should equal the LLC in the system, but there are a number of
special cases that need to be dealt with.
In the case of NUMA in socket, we need to assure that the sched
domain we build for the MC layer isn't larger than the DIE above it.
Similarly for LLC's that might exist in cross socket interconnect or
directory hardware we need to assure that MC is shrunk to the socket
or NUMA node.
This patch builds a sibling mask for the LLC, and then picks the
smallest of LLC, socket siblings, or NUMA node siblings, which
gives us the behavior described above. This is ever so slightly
different than the similar alternative where we look for a cache
layer less than or equal to the socket/NUMA siblings.
The logic to pick the MC layer affects all arm64 machines, but
only changes the behavior for DT/MPIDR systems if the NUMA domain
is smaller than the core siblings (generally set to the cluster).
Potentially this fixes a possible bug in DT systems, but really
it only affects ACPI systems where the core siblings is correctly
set to the socket siblings. Thus all currently available ACPI
systems should have MC equal to LLC, including the NUMA in socket
machines where the LLC is partitioned between the NUMA nodes.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Vijaya Kumar K <vkilari@codeaurora.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Tested-by: Tomasz Nowicki <Tomasz.Nowicki@cavium.com>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Morten Rasmussen <morten.rasmussen@arm.com>
---
arch/arm64/include/asm/topology.h | 2 ++
arch/arm64/kernel/topology.c | 36 +++++++++++++++++++++++++++++++++++-
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index 6b10459e6905..df48212f767b 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -8,8 +8,10 @@ struct cpu_topology {
int thread_id;
int core_id;
int package_id;
+ int llc_id;
cpumask_t thread_sibling;
cpumask_t core_sibling;
+ cpumask_t llc_siblings;
};
extern struct cpu_topology cpu_topology[NR_CPUS];
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 047d98e68502..7415c166281f 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -13,6 +13,7 @@
#include <linux/acpi.h>
#include <linux/arch_topology.h>
+#include <linux/cacheinfo.h>
#include <linux/cpu.h>
#include <linux/cpumask.h>
#include <linux/init.h>
@@ -214,7 +215,19 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- return &cpu_topology[cpu].core_sibling;
+ const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
+
+ /* Find the smaller of NUMA, core or LLC siblings */
+ if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
+ /* not numa in package, lets use the package siblings */
+ core_mask = &cpu_topology[cpu].core_sibling;
+ }
+ if (cpu_topology[cpu].llc_id != -1) {
+ if (cpumask_subset(&cpu_topology[cpu].llc_siblings, core_mask))
+ core_mask = &cpu_topology[cpu].llc_siblings;
+ }
+
+ return core_mask;
}
static void update_siblings_masks(unsigned int cpuid)
@@ -226,6 +239,9 @@ static void update_siblings_masks(unsigned int cpuid)
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
+ if (cpuid_topo->llc_id == cpu_topo->llc_id)
+ cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
+
if (cpuid_topo->package_id != cpu_topo->package_id)
continue;
@@ -291,6 +307,10 @@ static void __init reset_cpu_topology(void)
cpu_topo->core_id = 0;
cpu_topo->package_id = -1;
+ cpu_topo->llc_id = -1;
+ cpumask_clear(&cpu_topo->llc_siblings);
+ cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
+
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
@@ -311,6 +331,8 @@ static int __init parse_acpi_topology(void)
is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
for_each_possible_cpu(cpu) {
+ int i, cache_id;
+
topology_id = find_acpi_cpu_topology(cpu, 0);
if (topology_id < 0)
return topology_id;
@@ -325,6 +347,18 @@ static int __init parse_acpi_topology(void)
}
topology_id = find_acpi_cpu_topology_package(cpu);
cpu_topology[cpu].package_id = topology_id;
+
+ i = acpi_find_last_cache_level(cpu);
+
+ if (i > 0) {
+ /*
+ * this is the only part of cpu_topology that has
+ * a direct relationship with the cache topology
+ */
+ cache_id = find_acpi_cpu_cache_topology(cpu, i);
+ if (cache_id > 0)
+ cpu_topology[cpu].llc_id = cache_id;
+ }
}
return 0;
--
2.13.6
^ permalink raw reply related [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-11 23:57 ` Jeremy Linton
(?)
@ 2018-05-17 17:05 ` Catalin Marinas
-1 siblings, 0 replies; 185+ messages in thread
From: Catalin Marinas @ 2018-05-17 17:05 UTC (permalink / raw)
To: Jeremy Linton
Cc: linux-acpi, Mark.Rutland, austinwc, tnowicki, palmer,
Will.Deacon, linux-riscv, Morten.Rasmussen, vkilari,
Lorenzo.Pieralisi, jhugo, ahs3, lenb, john.garry, wangxiongfeng2,
Dietmar.Eggemann, linux-arm-kernel, ard.biesheuvel, gregkh, rjw,
linux-kernel, hanjun.guo, Sudeep.Holla
On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
> Jeremy Linton (12):
> drivers: base: cacheinfo: move cache_setup_of_node()
> drivers: base: cacheinfo: setup DT cache properties early
> cacheinfo: rename of_node to fw_token
> arm64/acpi: Create arch specific cpu to acpi id helper
> ACPI/PPTT: Add Processor Properties Topology Table parsing
> ACPI: Enable PPTT support on ARM64
> drivers: base cacheinfo: Add support for ACPI based firmware tables
> arm64: Add support for ACPI based firmware tables
> arm64: topology: rename cluster_id
> arm64: topology: enable ACPI/PPTT based CPU topology
> ACPI: Add PPTT to injectable table list
> arm64: topology: divorce MC scheduling domain from core_siblings
Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
can add it separately).
Thanks.
--
Catalin
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-17 17:05 ` Catalin Marinas
0 siblings, 0 replies; 185+ messages in thread
From: Catalin Marinas @ 2018-05-17 17:05 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
> Jeremy Linton (12):
> drivers: base: cacheinfo: move cache_setup_of_node()
> drivers: base: cacheinfo: setup DT cache properties early
> cacheinfo: rename of_node to fw_token
> arm64/acpi: Create arch specific cpu to acpi id helper
> ACPI/PPTT: Add Processor Properties Topology Table parsing
> ACPI: Enable PPTT support on ARM64
> drivers: base cacheinfo: Add support for ACPI based firmware tables
> arm64: Add support for ACPI based firmware tables
> arm64: topology: rename cluster_id
> arm64: topology: enable ACPI/PPTT based CPU topology
> ACPI: Add PPTT to injectable table list
> arm64: topology: divorce MC scheduling domain from core_siblings
Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
can add it separately).
Thanks.
--
Catalin
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-17 17:05 ` Catalin Marinas
0 siblings, 0 replies; 185+ messages in thread
From: Catalin Marinas @ 2018-05-17 17:05 UTC (permalink / raw)
To: linux-riscv
On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
> Jeremy Linton (12):
> drivers: base: cacheinfo: move cache_setup_of_node()
> drivers: base: cacheinfo: setup DT cache properties early
> cacheinfo: rename of_node to fw_token
> arm64/acpi: Create arch specific cpu to acpi id helper
> ACPI/PPTT: Add Processor Properties Topology Table parsing
> ACPI: Enable PPTT support on ARM64
> drivers: base cacheinfo: Add support for ACPI based firmware tables
> arm64: Add support for ACPI based firmware tables
> arm64: topology: rename cluster_id
> arm64: topology: enable ACPI/PPTT based CPU topology
> ACPI: Add PPTT to injectable table list
> arm64: topology: divorce MC scheduling domain from core_siblings
Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
can add it separately).
Thanks.
--
Catalin
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-17 17:05 ` Catalin Marinas
(?)
(?)
@ 2018-05-29 10:48 ` Geert Uytterhoeven
-1 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 10:48 UTC (permalink / raw)
To: Catalin Marinas, Jeremy Linton
Cc: ACPI Devel Maling List, Mark Rutland, austinwc, tnowicki,
Palmer Dabbelt, Will Deacon, linux-riscv, Morten.Rasmussen,
vkilari, Lorenzo Pieralisi, jhugo, Al Stone, Len Brown,
John Garry, wangxiongfeng2, Dietmar Eggemann, Linux ARM,
Ard Biesheuvel, Greg KH, Rafael J. Wysocki,
Linux Kernel Mailing List, Hanju
Hi Catalin, Jeremy,
On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>> Jeremy Linton (12):
>> drivers: base: cacheinfo: move cache_setup_of_node()
>> drivers: base: cacheinfo: setup DT cache properties early
>> cacheinfo: rename of_node to fw_token
>> arm64/acpi: Create arch specific cpu to acpi id helper
>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>> ACPI: Enable PPTT support on ARM64
>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>> arm64: Add support for ACPI based firmware tables
>> arm64: topology: rename cluster_id
>> arm64: topology: enable ACPI/PPTT based CPU topology
>> ACPI: Add PPTT to injectable table list
>> arm64: topology: divorce MC scheduling domain from core_siblings
>
> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
> can add it separately).
This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
scheduling domain from core_siblings") in arm64/for-next/core, causing
system suspend on big.LITTLE systems to hang after shutting down the first
CPU:
$ echo mem > /sys/power/state
PM: suspend entry (deep)
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Disabling non-boot CPUs ...
CPU1: shutdown
psci: CPU1 killed.
For me, it fails on the following big.LITTLE systems:
R-Car H3 ES2.0 (4xCA57 + 4xCA53)
R-Car M3-W (2xCA57 + 4xCA53)
System supend still works fine on systems with big cores only:
R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
R-Car M3-N (2xCA57)
Reverting this commit fixes the issue for me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 10:48 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 10:48 UTC (permalink / raw)
To: linux-arm-kernel
Hi Catalin, Jeremy,
On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>> Jeremy Linton (12):
>> drivers: base: cacheinfo: move cache_setup_of_node()
>> drivers: base: cacheinfo: setup DT cache properties early
>> cacheinfo: rename of_node to fw_token
>> arm64/acpi: Create arch specific cpu to acpi id helper
>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>> ACPI: Enable PPTT support on ARM64
>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>> arm64: Add support for ACPI based firmware tables
>> arm64: topology: rename cluster_id
>> arm64: topology: enable ACPI/PPTT based CPU topology
>> ACPI: Add PPTT to injectable table list
>> arm64: topology: divorce MC scheduling domain from core_siblings
>
> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
> can add it separately).
This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
scheduling domain from core_siblings") in arm64/for-next/core, causing
system suspend on big.LITTLE systems to hang after shutting down the first
CPU:
$ echo mem > /sys/power/state
PM: suspend entry (deep)
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Disabling non-boot CPUs ...
CPU1: shutdown
psci: CPU1 killed.
For me, it fails on the following big.LITTLE systems:
R-Car H3 ES2.0 (4xCA57 + 4xCA53)
R-Car M3-W (2xCA57 + 4xCA53)
System supend still works fine on systems with big cores only:
R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
R-Car M3-N (2xCA57)
Reverting this commit fixes the issue for me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 10:48 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 10:48 UTC (permalink / raw)
To: linux-riscv
Hi Catalin, Jeremy,
On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>> Jeremy Linton (12):
>> drivers: base: cacheinfo: move cache_setup_of_node()
>> drivers: base: cacheinfo: setup DT cache properties early
>> cacheinfo: rename of_node to fw_token
>> arm64/acpi: Create arch specific cpu to acpi id helper
>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>> ACPI: Enable PPTT support on ARM64
>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>> arm64: Add support for ACPI based firmware tables
>> arm64: topology: rename cluster_id
>> arm64: topology: enable ACPI/PPTT based CPU topology
>> ACPI: Add PPTT to injectable table list
>> arm64: topology: divorce MC scheduling domain from core_siblings
>
> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
> can add it separately).
This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
scheduling domain from core_siblings") in arm64/for-next/core, causing
system suspend on big.LITTLE systems to hang after shutting down the first
CPU:
$ echo mem > /sys/power/state
PM: suspend entry (deep)
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Disabling non-boot CPUs ...
CPU1: shutdown
psci: CPU1 killed.
For me, it fails on the following big.LITTLE systems:
R-Car H3 ES2.0 (4xCA57 + 4xCA53)
R-Car M3-W (2xCA57 + 4xCA53)
System supend still works fine on systems with big cores only:
R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
R-Car M3-N (2xCA57)
Reverting this commit fixes the issue for me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 10:48 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 10:48 UTC (permalink / raw)
To: Catalin Marinas, Jeremy Linton
Cc: ACPI Devel Maling List, Mark Rutland, austinwc, tnowicki,
Palmer Dabbelt, Will Deacon, linux-riscv, Morten.Rasmussen,
vkilari, Lorenzo Pieralisi, jhugo, Al Stone, Len Brown,
John Garry, wangxiongfeng2, Dietmar Eggemann, Linux ARM,
Ard Biesheuvel, Greg KH, Rafael J. Wysocki,
Linux Kernel Mailing List, Hanjun Guo, Sudeep Holla,
Linux-Renesas
Hi Catalin, Jeremy,
On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
<catalin.marinas@arm.com> wrote:
> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>> Jeremy Linton (12):
>> drivers: base: cacheinfo: move cache_setup_of_node()
>> drivers: base: cacheinfo: setup DT cache properties early
>> cacheinfo: rename of_node to fw_token
>> arm64/acpi: Create arch specific cpu to acpi id helper
>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>> ACPI: Enable PPTT support on ARM64
>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>> arm64: Add support for ACPI based firmware tables
>> arm64: topology: rename cluster_id
>> arm64: topology: enable ACPI/PPTT based CPU topology
>> ACPI: Add PPTT to injectable table list
>> arm64: topology: divorce MC scheduling domain from core_siblings
>
> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
> can add it separately).
This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
scheduling domain from core_siblings") in arm64/for-next/core, causing
system suspend on big.LITTLE systems to hang after shutting down the first
CPU:
$ echo mem > /sys/power/state
PM: suspend entry (deep)
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.001 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
Disabling non-boot CPUs ...
CPU1: shutdown
psci: CPU1 killed.
For me, it fails on the following big.LITTLE systems:
R-Car H3 ES2.0 (4xCA57 + 4xCA53)
R-Car M3-W (2xCA57 + 4xCA53)
System supend still works fine on systems with big cores only:
R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
R-Car M3-N (2xCA57)
Reverting this commit fixes the issue for me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 10:48 ` Geert Uytterhoeven
(?)
(?)
@ 2018-05-29 11:14 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-29 11:14 UTC (permalink / raw)
To: Geert Uytterhoeven, Catalin Marinas, Jeremy Linton
Cc: Sudeep Holla, ACPI Devel Maling List, Mark Rutland, austinwc,
tnowicki, Palmer Dabbelt, Will Deacon, linux-riscv,
Morten.Rasmussen, vkilari, Lorenzo Pieralisi, jhugo, Al Stone,
Len Brown, John Garry, wangxiongfeng2, Dietmar Eggemann,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki
On 29/05/18 11:48, Geert Uytterhoeven wrote:
> Hi Catalin, Jeremy,
>
> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>> Jeremy Linton (12):
>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>> drivers: base: cacheinfo: setup DT cache properties early
>>> cacheinfo: rename of_node to fw_token
>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>> ACPI: Enable PPTT support on ARM64
>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>> arm64: Add support for ACPI based firmware tables
>>> arm64: topology: rename cluster_id
>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>> ACPI: Add PPTT to injectable table list
>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>
>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
>> can add it separately).
>
> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
> scheduling domain from core_siblings") in arm64/for-next/core, causing
> system suspend on big.LITTLE systems to hang after shutting down the first
> CPU:
>
> $ echo mem > /sys/power/state
> PM: suspend entry (deep)
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.001 seconds) done.
> OOM killer disabled.
> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> Disabling non-boot CPUs ...
> CPU1: shutdown
> psci: CPU1 killed.
>
Is it OK to assume the suspend failed just after shutting down one CPU
or it's failing during resume ? It depends on whether you had console
disabled or not.
> For me, it fails on the following big.LITTLE systems:
>
> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
> R-Car M3-W (2xCA57 + 4xCA53)
>
Interesting, is it PSCI based system suspend ?
> System supend still works fine on systems with big cores only:
>
> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> R-Car M3-N (2xCA57)
>
> Reverting this commit fixes the issue for me.
>
I can't find anything that relates to system suspend in these patches
unless they are messing with something during CPU hot plug-in back
during resume.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 11:14 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-29 11:14 UTC (permalink / raw)
To: linux-arm-kernel
On 29/05/18 11:48, Geert Uytterhoeven wrote:
> Hi Catalin, Jeremy,
>
> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>> Jeremy Linton (12):
>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>> drivers: base: cacheinfo: setup DT cache properties early
>>> cacheinfo: rename of_node to fw_token
>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>> ACPI: Enable PPTT support on ARM64
>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>> arm64: Add support for ACPI based firmware tables
>>> arm64: topology: rename cluster_id
>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>> ACPI: Add PPTT to injectable table list
>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>
>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
>> can add it separately).
>
> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
> scheduling domain from core_siblings") in arm64/for-next/core, causing
> system suspend on big.LITTLE systems to hang after shutting down the first
> CPU:
>
> $ echo mem > /sys/power/state
> PM: suspend entry (deep)
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.001 seconds) done.
> OOM killer disabled.
> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> Disabling non-boot CPUs ...
> CPU1: shutdown
> psci: CPU1 killed.
>
Is it OK to assume the suspend failed just after shutting down one CPU
or it's failing during resume ? It depends on whether you had console
disabled or not.
> For me, it fails on the following big.LITTLE systems:
>
> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
> R-Car M3-W (2xCA57 + 4xCA53)
>
Interesting, is it PSCI based system suspend ?
> System supend still works fine on systems with big cores only:
>
> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> R-Car M3-N (2xCA57)
>
> Reverting this commit fixes the issue for me.
>
I can't find anything that relates to system suspend in these patches
unless they are messing with something during CPU hot plug-in back
during resume.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 11:14 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-29 11:14 UTC (permalink / raw)
To: linux-riscv
On 29/05/18 11:48, Geert Uytterhoeven wrote:
> Hi Catalin, Jeremy,
>
> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>> Jeremy Linton (12):
>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>> drivers: base: cacheinfo: setup DT cache properties early
>>> cacheinfo: rename of_node to fw_token
>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>> ACPI: Enable PPTT support on ARM64
>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>> arm64: Add support for ACPI based firmware tables
>>> arm64: topology: rename cluster_id
>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>> ACPI: Add PPTT to injectable table list
>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>
>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
>> can add it separately).
>
> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
> scheduling domain from core_siblings") in arm64/for-next/core, causing
> system suspend on big.LITTLE systems to hang after shutting down the first
> CPU:
>
> $ echo mem > /sys/power/state
> PM: suspend entry (deep)
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.001 seconds) done.
> OOM killer disabled.
> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> Disabling non-boot CPUs ...
> CPU1: shutdown
> psci: CPU1 killed.
>
Is it OK to assume the suspend failed just after shutting down one CPU
or it's failing during resume ? It depends on whether you had console
disabled or not.
> For me, it fails on the following big.LITTLE systems:
>
> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
> R-Car M3-W (2xCA57 + 4xCA53)
>
Interesting, is it PSCI based system suspend ?
> System supend still works fine on systems with big cores only:
>
> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> R-Car M3-N (2xCA57)
>
> Reverting this commit fixes the issue for me.
>
I can't find anything that relates to system suspend in these patches
unless they are messing with something during CPU hot plug-in back
during resume.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 11:14 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-29 11:14 UTC (permalink / raw)
To: Geert Uytterhoeven, Catalin Marinas, Jeremy Linton
Cc: Sudeep Holla, ACPI Devel Maling List, Mark Rutland, austinwc,
tnowicki, Palmer Dabbelt, Will Deacon, linux-riscv,
Morten.Rasmussen, vkilari, Lorenzo Pieralisi, jhugo, Al Stone,
Len Brown, John Garry, wangxiongfeng2, Dietmar Eggemann,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki,
Linux Kernel Mailing List, Hanjun Guo, Linux-Renesas
On 29/05/18 11:48, Geert Uytterhoeven wrote:
> Hi Catalin, Jeremy,
>
> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>> Jeremy Linton (12):
>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>> drivers: base: cacheinfo: setup DT cache properties early
>>> cacheinfo: rename of_node to fw_token
>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>> ACPI: Enable PPTT support on ARM64
>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>> arm64: Add support for ACPI based firmware tables
>>> arm64: topology: rename cluster_id
>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>> ACPI: Add PPTT to injectable table list
>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>
>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
>> can add it separately).
>
> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
> scheduling domain from core_siblings") in arm64/for-next/core, causing
> system suspend on big.LITTLE systems to hang after shutting down the first
> CPU:
>
> $ echo mem > /sys/power/state
> PM: suspend entry (deep)
> PM: Syncing filesystems ... done.
> Freezing user space processes ... (elapsed 0.001 seconds) done.
> OOM killer disabled.
> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> Disabling non-boot CPUs ...
> CPU1: shutdown
> psci: CPU1 killed.
>
Is it OK to assume the suspend failed just after shutting down one CPU
or it's failing during resume ? It depends on whether you had console
disabled or not.
> For me, it fails on the following big.LITTLE systems:
>
> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
> R-Car M3-W (2xCA57 + 4xCA53)
>
Interesting, is it PSCI based system suspend ?
> System supend still works fine on systems with big cores only:
>
> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> R-Car M3-N (2xCA57)
>
> Reverting this commit fixes the issue for me.
>
I can't find anything that relates to system suspend in these patches
unless they are messing with something during CPU hot plug-in back
during resume.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 11:14 ` Sudeep Holla
(?)
(?)
@ 2018-05-29 11:56 ` Geert Uytterhoeven
-1 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 11:56 UTC (permalink / raw)
To: Sudeep Holla
Cc: Catalin Marinas, Jeremy Linton, ACPI Devel Maling List,
Mark Rutland, austinwc, tnowicki, Palmer Dabbelt, Will Deacon,
linux-riscv, Morten.Rasmussen, vkilari, Lorenzo Pieralisi, jhugo,
Al Stone, Len Brown, John Garry, wangxiongfeng2,
Dietmar Eggemann, Linux ARM, Ard Biesheuvel, Greg KH
Hi Sudeep,
On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>> Jeremy Linton (12):
>>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>>> drivers: base: cacheinfo: setup DT cache properties early
>>>> cacheinfo: rename of_node to fw_token
>>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>>> ACPI: Enable PPTT support on ARM64
>>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>>> arm64: Add support for ACPI based firmware tables
>>>> arm64: topology: rename cluster_id
>>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>>> ACPI: Add PPTT to injectable table list
>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>
>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
>>> can add it separately).
>>
>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>> system suspend on big.LITTLE systems to hang after shutting down the first
>> CPU:
>>
>> $ echo mem > /sys/power/state
>> PM: suspend entry (deep)
>> PM: Syncing filesystems ... done.
>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>> OOM killer disabled.
>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>> Disabling non-boot CPUs ...
>> CPU1: shutdown
>> psci: CPU1 killed.
>>
>
> Is it OK to assume the suspend failed just after shutting down one CPU
> or it's failing during resume ? It depends on whether you had console
> disabled or not.
I have no-console-suspend enabled.
It's failing during suspend, the next lines should be:
CPU2: shutdown
psci: CPU2 killed.
...
>> For me, it fails on the following big.LITTLE systems:
>>
>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>> R-Car M3-W (2xCA57 + 4xCA53)
>>
>
> Interesting, is it PSCI based system suspend ?
Yes it is.
Suspend-to-idle, which doesn't offline CPUs, still works.
>> System supend still works fine on systems with big cores only:
>>
>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>> R-Car M3-N (2xCA57)
>>
>> Reverting this commit fixes the issue for me.
>
> I can't find anything that relates to system suspend in these patches
> unless they are messing with something during CPU hot plug-in back
> during resume.
It's only the last patch that introduces the breakage.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 11:56 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 11:56 UTC (permalink / raw)
To: linux-arm-kernel
Hi Sudeep,
On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>> Jeremy Linton (12):
>>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>>> drivers: base: cacheinfo: setup DT cache properties early
>>>> cacheinfo: rename of_node to fw_token
>>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>>> ACPI: Enable PPTT support on ARM64
>>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>>> arm64: Add support for ACPI based firmware tables
>>>> arm64: topology: rename cluster_id
>>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>>> ACPI: Add PPTT to injectable table list
>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>
>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
>>> can add it separately).
>>
>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>> system suspend on big.LITTLE systems to hang after shutting down the first
>> CPU:
>>
>> $ echo mem > /sys/power/state
>> PM: suspend entry (deep)
>> PM: Syncing filesystems ... done.
>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>> OOM killer disabled.
>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>> Disabling non-boot CPUs ...
>> CPU1: shutdown
>> psci: CPU1 killed.
>>
>
> Is it OK to assume the suspend failed just after shutting down one CPU
> or it's failing during resume ? It depends on whether you had console
> disabled or not.
I have no-console-suspend enabled.
It's failing during suspend, the next lines should be:
CPU2: shutdown
psci: CPU2 killed.
...
>> For me, it fails on the following big.LITTLE systems:
>>
>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>> R-Car M3-W (2xCA57 + 4xCA53)
>>
>
> Interesting, is it PSCI based system suspend ?
Yes it is.
Suspend-to-idle, which doesn't offline CPUs, still works.
>> System supend still works fine on systems with big cores only:
>>
>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>> R-Car M3-N (2xCA57)
>>
>> Reverting this commit fixes the issue for me.
>
> I can't find anything that relates to system suspend in these patches
> unless they are messing with something during CPU hot plug-in back
> during resume.
It's only the last patch that introduces the breakage.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 11:56 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 11:56 UTC (permalink / raw)
To: linux-riscv
Hi Sudeep,
On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>> Jeremy Linton (12):
>>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>>> drivers: base: cacheinfo: setup DT cache properties early
>>>> cacheinfo: rename of_node to fw_token
>>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>>> ACPI: Enable PPTT support on ARM64
>>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>>> arm64: Add support for ACPI based firmware tables
>>>> arm64: topology: rename cluster_id
>>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>>> ACPI: Add PPTT to injectable table list
>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>
>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
>>> can add it separately).
>>
>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>> system suspend on big.LITTLE systems to hang after shutting down the first
>> CPU:
>>
>> $ echo mem > /sys/power/state
>> PM: suspend entry (deep)
>> PM: Syncing filesystems ... done.
>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>> OOM killer disabled.
>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>> Disabling non-boot CPUs ...
>> CPU1: shutdown
>> psci: CPU1 killed.
>>
>
> Is it OK to assume the suspend failed just after shutting down one CPU
> or it's failing during resume ? It depends on whether you had console
> disabled or not.
I have no-console-suspend enabled.
It's failing during suspend, the next lines should be:
CPU2: shutdown
psci: CPU2 killed.
...
>> For me, it fails on the following big.LITTLE systems:
>>
>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>> R-Car M3-W (2xCA57 + 4xCA53)
>>
>
> Interesting, is it PSCI based system suspend ?
Yes it is.
Suspend-to-idle, which doesn't offline CPUs, still works.
>> System supend still works fine on systems with big cores only:
>>
>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>> R-Car M3-N (2xCA57)
>>
>> Reverting this commit fixes the issue for me.
>
> I can't find anything that relates to system suspend in these patches
> unless they are messing with something during CPU hot plug-in back
> during resume.
It's only the last patch that introduces the breakage.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 11:56 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 11:56 UTC (permalink / raw)
To: Sudeep Holla
Cc: Catalin Marinas, Jeremy Linton, ACPI Devel Maling List,
Mark Rutland, austinwc, tnowicki, Palmer Dabbelt, Will Deacon,
linux-riscv, Morten.Rasmussen, vkilari, Lorenzo Pieralisi, jhugo,
Al Stone, Len Brown, John Garry, wangxiongfeng2,
Dietmar Eggemann, Linux ARM, Ard Biesheuvel, Greg KH,
Rafael J. Wysocki, Linux Kernel Mailing List, Hanjun Guo,
Linux-Renesas
Hi Sudeep,
On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>> <catalin.marinas@arm.com> wrote:
>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>> Jeremy Linton (12):
>>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>>> drivers: base: cacheinfo: setup DT cache properties early
>>>> cacheinfo: rename of_node to fw_token
>>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>>> ACPI: Enable PPTT support on ARM64
>>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>>> arm64: Add support for ACPI based firmware tables
>>>> arm64: topology: rename cluster_id
>>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>>> ACPI: Add PPTT to injectable table list
>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>
>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
>>> can add it separately).
>>
>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>> system suspend on big.LITTLE systems to hang after shutting down the first
>> CPU:
>>
>> $ echo mem > /sys/power/state
>> PM: suspend entry (deep)
>> PM: Syncing filesystems ... done.
>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>> OOM killer disabled.
>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>> Disabling non-boot CPUs ...
>> CPU1: shutdown
>> psci: CPU1 killed.
>>
>
> Is it OK to assume the suspend failed just after shutting down one CPU
> or it's failing during resume ? It depends on whether you had console
> disabled or not.
I have no-console-suspend enabled.
It's failing during suspend, the next lines should be:
CPU2: shutdown
psci: CPU2 killed.
...
>> For me, it fails on the following big.LITTLE systems:
>>
>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>> R-Car M3-W (2xCA57 + 4xCA53)
>>
>
> Interesting, is it PSCI based system suspend ?
Yes it is.
Suspend-to-idle, which doesn't offline CPUs, still works.
>> System supend still works fine on systems with big cores only:
>>
>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>> R-Car M3-N (2xCA57)
>>
>> Reverting this commit fixes the issue for me.
>
> I can't find anything that relates to system suspend in these patches
> unless they are messing with something during CPU hot plug-in back
> during resume.
It's only the last patch that introduces the breakage.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 11:56 ` Geert Uytterhoeven
(?)
(?)
@ 2018-05-29 13:18 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-29 13:18 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sudeep Holla, Catalin Marinas, Jeremy Linton,
ACPI Devel Maling List, Mark Rutland, austinwc, tnowicki,
Palmer Dabbelt, Will Deacon, linux-riscv, Morten.Rasmussen,
vkilari, Lorenzo Pieralisi, jhugo, Al Stone, Len Brown,
John Garry, wangxiongfeng2, Dietmar Eggemann, Linux ARM,
Ard Biesheuvel, Greg KH
On 29/05/18 12:56, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>> <catalin.marinas@arm.com> wrote:
>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>> Jeremy Linton (12):
>>>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>>>> drivers: base: cacheinfo: setup DT cache properties early
>>>>> cacheinfo: rename of_node to fw_token
>>>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>>>> ACPI: Enable PPTT support on ARM64
>>>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>>>> arm64: Add support for ACPI based firmware tables
>>>>> arm64: topology: rename cluster_id
>>>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>>>> ACPI: Add PPTT to injectable table list
>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>
>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
>>>> can add it separately).
>>>
>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>> CPU:
>>>
>>> $ echo mem > /sys/power/state
>>> PM: suspend entry (deep)
>>> PM: Syncing filesystems ... done.
>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>> OOM killer disabled.
>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>> Disabling non-boot CPUs ...
>>> CPU1: shutdown
>>> psci: CPU1 killed.
>>>
>>
>> Is it OK to assume the suspend failed just after shutting down one CPU
>> or it's failing during resume ? It depends on whether you had console
>> disabled or not.
>
> I have no-console-suspend enabled.
> It's failing during suspend, the next lines should be:
>
> CPU2: shutdown
> psci: CPU2 killed.
> ...
>
OK, I was hoping to be something during resume as this patch has nothing
executed during suspend. Do you see any change in topology before and
after this patch applied. I am interested in the output of:
$ grep "" /sys/devices/system/cpu/cpu*/topology/*
>>> For me, it fails on the following big.LITTLE systems:
>>>
>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>
>>
>> Interesting, is it PSCI based system suspend ?
>
> Yes it is.
>
> Suspend-to-idle, which doesn't offline CPUs, still works.
>
>From DT, I guess this platform doesn't have any idle states.
Does this use genpd power domains ? I see power-domains in the DT, so
asking to get more info. Do you have any out of tree patches especially
if they are depending on some topology cpumasks ?
>>> System supend still works fine on systems with big cores only:
>>>
>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>> R-Car M3-N (2xCA57)
>>>
>>> Reverting this commit fixes the issue for me.
>>
>> I can't find anything that relates to system suspend in these patches
>> unless they are messing with something during CPU hot plug-in back
>> during resume.
>
> It's only the last patch that introduces the breakage.
>
As specified in the commit log, it won't change any behavior for DT
systems if it's non-NUMA or single node system. So I am still wondering
what could trigger this regression.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 13:18 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-29 13:18 UTC (permalink / raw)
To: linux-arm-kernel
On 29/05/18 12:56, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>> <catalin.marinas@arm.com> wrote:
>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>> Jeremy Linton (12):
>>>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>>>> drivers: base: cacheinfo: setup DT cache properties early
>>>>> cacheinfo: rename of_node to fw_token
>>>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>>>> ACPI: Enable PPTT support on ARM64
>>>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>>>> arm64: Add support for ACPI based firmware tables
>>>>> arm64: topology: rename cluster_id
>>>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>>>> ACPI: Add PPTT to injectable table list
>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>
>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
>>>> can add it separately).
>>>
>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>> CPU:
>>>
>>> $ echo mem > /sys/power/state
>>> PM: suspend entry (deep)
>>> PM: Syncing filesystems ... done.
>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>> OOM killer disabled.
>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>> Disabling non-boot CPUs ...
>>> CPU1: shutdown
>>> psci: CPU1 killed.
>>>
>>
>> Is it OK to assume the suspend failed just after shutting down one CPU
>> or it's failing during resume ? It depends on whether you had console
>> disabled or not.
>
> I have no-console-suspend enabled.
> It's failing during suspend, the next lines should be:
>
> CPU2: shutdown
> psci: CPU2 killed.
> ...
>
OK, I was hoping to be something during resume as this patch has nothing
executed during suspend. Do you see any change in topology before and
after this patch applied. I am interested in the output of:
$ grep "" /sys/devices/system/cpu/cpu*/topology/*
>>> For me, it fails on the following big.LITTLE systems:
>>>
>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>
>>
>> Interesting, is it PSCI based system suspend ?
>
> Yes it is.
>
> Suspend-to-idle, which doesn't offline CPUs, still works.
>
>From DT, I guess this platform doesn't have any idle states.
Does this use genpd power domains ? I see power-domains in the DT, so
asking to get more info. Do you have any out of tree patches especially
if they are depending on some topology cpumasks ?
>>> System supend still works fine on systems with big cores only:
>>>
>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>> R-Car M3-N (2xCA57)
>>>
>>> Reverting this commit fixes the issue for me.
>>
>> I can't find anything that relates to system suspend in these patches
>> unless they are messing with something during CPU hot plug-in back
>> during resume.
>
> It's only the last patch that introduces the breakage.
>
As specified in the commit log, it won't change any behavior for DT
systems if it's non-NUMA or single node system. So I am still wondering
what could trigger this regression.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 13:18 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-29 13:18 UTC (permalink / raw)
To: linux-riscv
On 29/05/18 12:56, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>> <catalin.marinas@arm.com> wrote:
>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>> Jeremy Linton (12):
>>>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>>>> drivers: base: cacheinfo: setup DT cache properties early
>>>>> cacheinfo: rename of_node to fw_token
>>>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>>>> ACPI: Enable PPTT support on ARM64
>>>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>>>> arm64: Add support for ACPI based firmware tables
>>>>> arm64: topology: rename cluster_id
>>>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>>>> ACPI: Add PPTT to injectable table list
>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>
>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
>>>> can add it separately).
>>>
>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>> CPU:
>>>
>>> $ echo mem > /sys/power/state
>>> PM: suspend entry (deep)
>>> PM: Syncing filesystems ... done.
>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>> OOM killer disabled.
>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>> Disabling non-boot CPUs ...
>>> CPU1: shutdown
>>> psci: CPU1 killed.
>>>
>>
>> Is it OK to assume the suspend failed just after shutting down one CPU
>> or it's failing during resume ? It depends on whether you had console
>> disabled or not.
>
> I have no-console-suspend enabled.
> It's failing during suspend, the next lines should be:
>
> CPU2: shutdown
> psci: CPU2 killed.
> ...
>
OK, I was hoping to be something during resume as this patch has nothing
executed during suspend. Do you see any change in topology before and
after this patch applied. I am interested in the output of:
$ grep "" /sys/devices/system/cpu/cpu*/topology/*
>>> For me, it fails on the following big.LITTLE systems:
>>>
>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>
>>
>> Interesting, is it PSCI based system suspend ?
>
> Yes it is.
>
> Suspend-to-idle, which doesn't offline CPUs, still works.
>
>From DT, I guess this platform doesn't have any idle states.
Does this use genpd power domains ? I see power-domains in the DT, so
asking to get more info. Do you have any out of tree patches especially
if they are depending on some topology cpumasks ?
>>> System supend still works fine on systems with big cores only:
>>>
>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>> R-Car M3-N (2xCA57)
>>>
>>> Reverting this commit fixes the issue for me.
>>
>> I can't find anything that relates to system suspend in these patches
>> unless they are messing with something during CPU hot plug-in back
>> during resume.
>
> It's only the last patch that introduces the breakage.
>
As specified in the commit log, it won't change any behavior for DT
systems if it's non-NUMA or single node system. So I am still wondering
what could trigger this regression.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 13:18 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-29 13:18 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sudeep Holla, Catalin Marinas, Jeremy Linton,
ACPI Devel Maling List, Mark Rutland, austinwc, tnowicki,
Palmer Dabbelt, Will Deacon, linux-riscv, Morten.Rasmussen,
vkilari, Lorenzo Pieralisi, jhugo, Al Stone, Len Brown,
John Garry, wangxiongfeng2, Dietmar Eggemann, Linux ARM,
Ard Biesheuvel, Greg KH, Rafael J. Wysocki,
Linux Kernel Mailing List, Hanjun Guo, Linux-Renesas
On 29/05/18 12:56, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>> <catalin.marinas@arm.com> wrote:
>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>> Jeremy Linton (12):
>>>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>>>> drivers: base: cacheinfo: setup DT cache properties early
>>>>> cacheinfo: rename of_node to fw_token
>>>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>>>> ACPI: Enable PPTT support on ARM64
>>>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>>>> arm64: Add support for ACPI based firmware tables
>>>>> arm64: topology: rename cluster_id
>>>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>>>> ACPI: Add PPTT to injectable table list
>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>
>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
>>>> can add it separately).
>>>
>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>> CPU:
>>>
>>> $ echo mem > /sys/power/state
>>> PM: suspend entry (deep)
>>> PM: Syncing filesystems ... done.
>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>> OOM killer disabled.
>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>> Disabling non-boot CPUs ...
>>> CPU1: shutdown
>>> psci: CPU1 killed.
>>>
>>
>> Is it OK to assume the suspend failed just after shutting down one CPU
>> or it's failing during resume ? It depends on whether you had console
>> disabled or not.
>
> I have no-console-suspend enabled.
> It's failing during suspend, the next lines should be:
>
> CPU2: shutdown
> psci: CPU2 killed.
> ...
>
OK, I was hoping to be something during resume as this patch has nothing
executed during suspend. Do you see any change in topology before and
after this patch applied. I am interested in the output of:
$ grep "" /sys/devices/system/cpu/cpu*/topology/*
>>> For me, it fails on the following big.LITTLE systems:
>>>
>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>
>>
>> Interesting, is it PSCI based system suspend ?
>
> Yes it is.
>
> Suspend-to-idle, which doesn't offline CPUs, still works.
>
>From DT, I guess this platform doesn't have any idle states.
Does this use genpd power domains ? I see power-domains in the DT, so
asking to get more info. Do you have any out of tree patches especially
if they are depending on some topology cpumasks ?
>>> System supend still works fine on systems with big cores only:
>>>
>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>> R-Car M3-N (2xCA57)
>>>
>>> Reverting this commit fixes the issue for me.
>>
>> I can't find anything that relates to system suspend in these patches
>> unless they are messing with something during CPU hot plug-in back
>> during resume.
>
> It's only the last patch that introduces the breakage.
>
As specified in the commit log, it won't change any behavior for DT
systems if it's non-NUMA or single node system. So I am still wondering
what could trigger this regression.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 13:18 ` Sudeep Holla
(?)
(?)
@ 2018-05-29 15:08 ` Will Deacon
-1 siblings, 0 replies; 185+ messages in thread
From: Will Deacon @ 2018-05-29 15:08 UTC (permalink / raw)
To: Sudeep Holla
Cc: Geert Uytterhoeven, Catalin Marinas, Jeremy Linton,
ACPI Devel Maling List, Mark Rutland, austinwc, tnowicki,
Palmer Dabbelt, linux-riscv, Morten.Rasmussen, vkilari,
Lorenzo Pieralisi, jhugo, Al Stone, Len Brown, John Garry,
wangxiongfeng2, Dietmar Eggemann, Linux ARM, Ard Biesheuvel,
Greg KH, Rafael
On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >>> System supend still works fine on systems with big cores only:
> >>>
> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> >>> R-Car M3-N (2xCA57)
> >>>
> >>> Reverting this commit fixes the issue for me.
> >>
> >> I can't find anything that relates to system suspend in these patches
> >> unless they are messing with something during CPU hot plug-in back
> >> during resume.
> >
> > It's only the last patch that introduces the breakage.
> >
>
> As specified in the commit log, it won't change any behavior for DT
> systems if it's non-NUMA or single node system. So I am still wondering
> what could trigger this regression.
I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
to the scheduler, although I can't see how this would happen.
Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
do you see anything shouting in dmesg?
Will
--->8
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index dad128ba98bf..e3de033339b4 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -58,7 +58,7 @@ EXPORT_SYMBOL(node_to_cpumask_map);
*/
const struct cpumask *cpumask_of_node(int node)
{
- if (WARN_ON(node >= nr_node_ids))
+ if (WARN_ON((unsigned)node >= nr_node_ids))
return cpu_none_mask;
if (WARN_ON(node_to_cpumask_map[node] == NULL))
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 15:08 ` Will Deacon
0 siblings, 0 replies; 185+ messages in thread
From: Will Deacon @ 2018-05-29 15:08 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >>> System supend still works fine on systems with big cores only:
> >>>
> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> >>> R-Car M3-N (2xCA57)
> >>>
> >>> Reverting this commit fixes the issue for me.
> >>
> >> I can't find anything that relates to system suspend in these patches
> >> unless they are messing with something during CPU hot plug-in back
> >> during resume.
> >
> > It's only the last patch that introduces the breakage.
> >
>
> As specified in the commit log, it won't change any behavior for DT
> systems if it's non-NUMA or single node system. So I am still wondering
> what could trigger this regression.
I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
to the scheduler, although I can't see how this would happen.
Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
do you see anything shouting in dmesg?
Will
--->8
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index dad128ba98bf..e3de033339b4 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -58,7 +58,7 @@ EXPORT_SYMBOL(node_to_cpumask_map);
*/
const struct cpumask *cpumask_of_node(int node)
{
- if (WARN_ON(node >= nr_node_ids))
+ if (WARN_ON((unsigned)node >= nr_node_ids))
return cpu_none_mask;
if (WARN_ON(node_to_cpumask_map[node] == NULL))
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 15:08 ` Will Deacon
0 siblings, 0 replies; 185+ messages in thread
From: Will Deacon @ 2018-05-29 15:08 UTC (permalink / raw)
To: linux-riscv
On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >>> System supend still works fine on systems with big cores only:
> >>>
> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> >>> R-Car M3-N (2xCA57)
> >>>
> >>> Reverting this commit fixes the issue for me.
> >>
> >> I can't find anything that relates to system suspend in these patches
> >> unless they are messing with something during CPU hot plug-in back
> >> during resume.
> >
> > It's only the last patch that introduces the breakage.
> >
>
> As specified in the commit log, it won't change any behavior for DT
> systems if it's non-NUMA or single node system. So I am still wondering
> what could trigger this regression.
I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
to the scheduler, although I can't see how this would happen.
Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
do you see anything shouting in dmesg?
Will
--->8
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index dad128ba98bf..e3de033339b4 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -58,7 +58,7 @@ EXPORT_SYMBOL(node_to_cpumask_map);
*/
const struct cpumask *cpumask_of_node(int node)
{
- if (WARN_ON(node >= nr_node_ids))
+ if (WARN_ON((unsigned)node >= nr_node_ids))
return cpu_none_mask;
if (WARN_ON(node_to_cpumask_map[node] == NULL))
^ permalink raw reply related [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 15:08 ` Will Deacon
0 siblings, 0 replies; 185+ messages in thread
From: Will Deacon @ 2018-05-29 15:08 UTC (permalink / raw)
To: Sudeep Holla
Cc: Geert Uytterhoeven, Catalin Marinas, Jeremy Linton,
ACPI Devel Maling List, Mark Rutland, austinwc, tnowicki,
Palmer Dabbelt, linux-riscv, Morten.Rasmussen, vkilari,
Lorenzo Pieralisi, jhugo, Al Stone, Len Brown, John Garry,
wangxiongfeng2, Dietmar Eggemann, Linux ARM, Ard Biesheuvel,
Greg KH, Rafael J. Wysocki, Linux Kernel Mailing List,
Hanjun Guo, Linux-Renesas
On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >>> System supend still works fine on systems with big cores only:
> >>>
> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> >>> R-Car M3-N (2xCA57)
> >>>
> >>> Reverting this commit fixes the issue for me.
> >>
> >> I can't find anything that relates to system suspend in these patches
> >> unless they are messing with something during CPU hot plug-in back
> >> during resume.
> >
> > It's only the last patch that introduces the breakage.
> >
>
> As specified in the commit log, it won't change any behavior for DT
> systems if it's non-NUMA or single node system. So I am still wondering
> what could trigger this regression.
I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
to the scheduler, although I can't see how this would happen.
Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
do you see anything shouting in dmesg?
Will
--->8
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index dad128ba98bf..e3de033339b4 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -58,7 +58,7 @@ EXPORT_SYMBOL(node_to_cpumask_map);
*/
const struct cpumask *cpumask_of_node(int node)
{
- if (WARN_ON(node >= nr_node_ids))
+ if (WARN_ON((unsigned)node >= nr_node_ids))
return cpu_none_mask;
if (WARN_ON(node_to_cpumask_map[node] == NULL))
^ permalink raw reply related [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 15:08 ` Will Deacon
(?)
(?)
@ 2018-05-29 15:51 ` Geert Uytterhoeven
-1 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 15:51 UTC (permalink / raw)
To: Will Deacon
Cc: Sudeep Holla, Catalin Marinas, Jeremy Linton,
ACPI Devel Maling List, Mark Rutland, austinwc, tnowicki,
Palmer Dabbelt, linux-riscv, Morten.Rasmussen, vkilari,
Lorenzo Pieralisi, jhugo, Al Stone, Len Brown, John Garry,
wangxiongfeng2, Dietmar Eggemann, Linux ARM, Ard Biesheuvel,
Greg KH, Rafael
Hi Will,
On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>> >>> System supend still works fine on systems with big cores only:
>> >>>
>> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>> >>> R-Car M3-N (2xCA57)
>> >>>
>> >>> Reverting this commit fixes the issue for me.
>> >>
>> >> I can't find anything that relates to system suspend in these patches
>> >> unless they are messing with something during CPU hot plug-in back
>> >> during resume.
>> >
>> > It's only the last patch that introduces the breakage.
>> >
>>
>> As specified in the commit log, it won't change any behavior for DT
>> systems if it's non-NUMA or single node system. So I am still wondering
>> what could trigger this regression.
>
> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
> to the scheduler, although I can't see how this would happen.
>
> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
> do you see anything shouting in dmesg?
Thanks, but unfortunately it doesn't help.
I added some debug code to print cpumask, but so far I don't see anything
suspicious.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 15:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 15:51 UTC (permalink / raw)
To: linux-arm-kernel
Hi Will,
On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>> >>> System supend still works fine on systems with big cores only:
>> >>>
>> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>> >>> R-Car M3-N (2xCA57)
>> >>>
>> >>> Reverting this commit fixes the issue for me.
>> >>
>> >> I can't find anything that relates to system suspend in these patches
>> >> unless they are messing with something during CPU hot plug-in back
>> >> during resume.
>> >
>> > It's only the last patch that introduces the breakage.
>> >
>>
>> As specified in the commit log, it won't change any behavior for DT
>> systems if it's non-NUMA or single node system. So I am still wondering
>> what could trigger this regression.
>
> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
> to the scheduler, although I can't see how this would happen.
>
> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
> do you see anything shouting in dmesg?
Thanks, but unfortunately it doesn't help.
I added some debug code to print cpumask, but so far I don't see anything
suspicious.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 15:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 15:51 UTC (permalink / raw)
To: linux-riscv
Hi Will,
On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>> >>> System supend still works fine on systems with big cores only:
>> >>>
>> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>> >>> R-Car M3-N (2xCA57)
>> >>>
>> >>> Reverting this commit fixes the issue for me.
>> >>
>> >> I can't find anything that relates to system suspend in these patches
>> >> unless they are messing with something during CPU hot plug-in back
>> >> during resume.
>> >
>> > It's only the last patch that introduces the breakage.
>> >
>>
>> As specified in the commit log, it won't change any behavior for DT
>> systems if it's non-NUMA or single node system. So I am still wondering
>> what could trigger this regression.
>
> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
> to the scheduler, although I can't see how this would happen.
>
> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
> do you see anything shouting in dmesg?
Thanks, but unfortunately it doesn't help.
I added some debug code to print cpumask, but so far I don't see anything
suspicious.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 15:51 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 15:51 UTC (permalink / raw)
To: Will Deacon
Cc: Sudeep Holla, Catalin Marinas, Jeremy Linton,
ACPI Devel Maling List, Mark Rutland, austinwc, tnowicki,
Palmer Dabbelt, linux-riscv, Morten.Rasmussen, vkilari,
Lorenzo Pieralisi, jhugo, Al Stone, Len Brown, John Garry,
wangxiongfeng2, Dietmar Eggemann, Linux ARM, Ard Biesheuvel,
Greg KH, Rafael J. Wysocki, Linux Kernel Mailing List,
Hanjun Guo, Linux-Renesas
Hi Will,
On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>> >>> System supend still works fine on systems with big cores only:
>> >>>
>> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>> >>> R-Car M3-N (2xCA57)
>> >>>
>> >>> Reverting this commit fixes the issue for me.
>> >>
>> >> I can't find anything that relates to system suspend in these patches
>> >> unless they are messing with something during CPU hot plug-in back
>> >> during resume.
>> >
>> > It's only the last patch that introduces the breakage.
>> >
>>
>> As specified in the commit log, it won't change any behavior for DT
>> systems if it's non-NUMA or single node system. So I am still wondering
>> what could trigger this regression.
>
> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
> to the scheduler, although I can't see how this would happen.
>
> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
> do you see anything shouting in dmesg?
Thanks, but unfortunately it doesn't help.
I added some debug code to print cpumask, but so far I don't see anything
suspicious.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 15:51 ` Geert Uytterhoeven
(?)
(?)
@ 2018-05-29 17:08 ` Robin Murphy
-1 siblings, 0 replies; 185+ messages in thread
From: Robin Murphy @ 2018-05-29 17:08 UTC (permalink / raw)
To: Geert Uytterhoeven, Will Deacon
Cc: Mark Rutland, austinwc, tnowicki, Catalin Marinas,
Palmer Dabbelt, linux-riscv, wangxiongfeng2, vkilari,
Lorenzo Pieralisi, jhugo, Morten.Rasmussen,
ACPI Devel Maling List, Len Brown, John Garry, Al Stone,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki,
Linux Kernel Mailing List, Jeremy Linton
On 29/05/18 16:51, Geert Uytterhoeven wrote:
> Hi Will,
>
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>> System supend still works fine on systems with big cores only:
>>>>>>
>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>> R-Car M3-N (2xCA57)
>>>>>>
>>>>>> Reverting this commit fixes the issue for me.
>>>>>
>>>>> I can't find anything that relates to system suspend in these patches
>>>>> unless they are messing with something during CPU hot plug-in back
>>>>> during resume.
>>>>
>>>> It's only the last patch that introduces the breakage.
>>>>
>>>
>>> As specified in the commit log, it won't change any behavior for DT
>>> systems if it's non-NUMA or single node system. So I am still wondering
>>> what could trigger this regression.
>>
>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>> to the scheduler, although I can't see how this would happen.
>>
>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>> do you see anything shouting in dmesg?
>
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.
Do you have CONFIG_NUMA enabled? On a hunch I've managed to reproduce
what looks like the same thing on a Juno board with NUMA=n; going in
with external debug it seems to be stuck in the loop in
init_sched_groups_capacity(), with an approximate stack trace of:
init_sched_groups_capacity()
partition_sched_domains()
cpuset_cpu_active()
sched_cpu_activate()
cpuhp_invoke_callback()
cpuhp_thread_fn()
My hunch is based on the fact that it looks like we can, under the right
circumstances, end up with default_topology picking up cpu_online_mask
as a sibling mask via cpu_coregroup_mask(), and given the great
coincidence that that's going to change when hotplugging out CPUs on
suspend, things might not react too well to that. Things also look to go
utterly haywire once into a full-blown systemd userspace with cpuidle,
but I haven't got a clear picture of that yet.
Robin.
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 17:08 ` Robin Murphy
0 siblings, 0 replies; 185+ messages in thread
From: Robin Murphy @ 2018-05-29 17:08 UTC (permalink / raw)
To: linux-arm-kernel
On 29/05/18 16:51, Geert Uytterhoeven wrote:
> Hi Will,
>
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>> System supend still works fine on systems with big cores only:
>>>>>>
>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>> R-Car M3-N (2xCA57)
>>>>>>
>>>>>> Reverting this commit fixes the issue for me.
>>>>>
>>>>> I can't find anything that relates to system suspend in these patches
>>>>> unless they are messing with something during CPU hot plug-in back
>>>>> during resume.
>>>>
>>>> It's only the last patch that introduces the breakage.
>>>>
>>>
>>> As specified in the commit log, it won't change any behavior for DT
>>> systems if it's non-NUMA or single node system. So I am still wondering
>>> what could trigger this regression.
>>
>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>> to the scheduler, although I can't see how this would happen.
>>
>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>> do you see anything shouting in dmesg?
>
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.
Do you have CONFIG_NUMA enabled? On a hunch I've managed to reproduce
what looks like the same thing on a Juno board with NUMA=n; going in
with external debug it seems to be stuck in the loop in
init_sched_groups_capacity(), with an approximate stack trace of:
init_sched_groups_capacity()
partition_sched_domains()
cpuset_cpu_active()
sched_cpu_activate()
cpuhp_invoke_callback()
cpuhp_thread_fn()
My hunch is based on the fact that it looks like we can, under the right
circumstances, end up with default_topology picking up cpu_online_mask
as a sibling mask via cpu_coregroup_mask(), and given the great
coincidence that that's going to change when hotplugging out CPUs on
suspend, things might not react too well to that. Things also look to go
utterly haywire once into a full-blown systemd userspace with cpuidle,
but I haven't got a clear picture of that yet.
Robin.
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 17:08 ` Robin Murphy
0 siblings, 0 replies; 185+ messages in thread
From: Robin Murphy @ 2018-05-29 17:08 UTC (permalink / raw)
To: linux-riscv
On 29/05/18 16:51, Geert Uytterhoeven wrote:
> Hi Will,
>
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>> System supend still works fine on systems with big cores only:
>>>>>>
>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>> R-Car M3-N (2xCA57)
>>>>>>
>>>>>> Reverting this commit fixes the issue for me.
>>>>>
>>>>> I can't find anything that relates to system suspend in these patches
>>>>> unless they are messing with something during CPU hot plug-in back
>>>>> during resume.
>>>>
>>>> It's only the last patch that introduces the breakage.
>>>>
>>>
>>> As specified in the commit log, it won't change any behavior for DT
>>> systems if it's non-NUMA or single node system. So I am still wondering
>>> what could trigger this regression.
>>
>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>> to the scheduler, although I can't see how this would happen.
>>
>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>> do you see anything shouting in dmesg?
>
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.
Do you have CONFIG_NUMA enabled? On a hunch I've managed to reproduce
what looks like the same thing on a Juno board with NUMA=n; going in
with external debug it seems to be stuck in the loop in
init_sched_groups_capacity(), with an approximate stack trace of:
init_sched_groups_capacity()
partition_sched_domains()
cpuset_cpu_active()
sched_cpu_activate()
cpuhp_invoke_callback()
cpuhp_thread_fn()
My hunch is based on the fact that it looks like we can, under the right
circumstances, end up with default_topology picking up cpu_online_mask
as a sibling mask via cpu_coregroup_mask(), and given the great
coincidence that that's going to change when hotplugging out CPUs on
suspend, things might not react too well to that. Things also look to go
utterly haywire once into a full-blown systemd userspace with cpuidle,
but I haven't got a clear picture of that yet.
Robin.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 17:08 ` Robin Murphy
0 siblings, 0 replies; 185+ messages in thread
From: Robin Murphy @ 2018-05-29 17:08 UTC (permalink / raw)
To: Geert Uytterhoeven, Will Deacon
Cc: Mark Rutland, austinwc, tnowicki, Catalin Marinas,
Palmer Dabbelt, linux-riscv, wangxiongfeng2, vkilari,
Lorenzo Pieralisi, jhugo, Morten.Rasmussen,
ACPI Devel Maling List, Len Brown, John Garry, Al Stone,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki,
Linux Kernel Mailing List, Jeremy Linton, Linux-Renesas,
Hanjun Guo, Sudeep Holla, Dietmar Eggemann
On 29/05/18 16:51, Geert Uytterhoeven wrote:
> Hi Will,
>
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>> System supend still works fine on systems with big cores only:
>>>>>>
>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>> R-Car M3-N (2xCA57)
>>>>>>
>>>>>> Reverting this commit fixes the issue for me.
>>>>>
>>>>> I can't find anything that relates to system suspend in these patches
>>>>> unless they are messing with something during CPU hot plug-in back
>>>>> during resume.
>>>>
>>>> It's only the last patch that introduces the breakage.
>>>>
>>>
>>> As specified in the commit log, it won't change any behavior for DT
>>> systems if it's non-NUMA or single node system. So I am still wondering
>>> what could trigger this regression.
>>
>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>> to the scheduler, although I can't see how this would happen.
>>
>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>> do you see anything shouting in dmesg?
>
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.
Do you have CONFIG_NUMA enabled? On a hunch I've managed to reproduce
what looks like the same thing on a Juno board with NUMA=n; going in
with external debug it seems to be stuck in the loop in
init_sched_groups_capacity(), with an approximate stack trace of:
init_sched_groups_capacity()
partition_sched_domains()
cpuset_cpu_active()
sched_cpu_activate()
cpuhp_invoke_callback()
cpuhp_thread_fn()
My hunch is based on the fact that it looks like we can, under the right
circumstances, end up with default_topology picking up cpu_online_mask
as a sibling mask via cpu_coregroup_mask(), and given the great
coincidence that that's going to change when hotplugging out CPUs on
suspend, things might not react too well to that. Things also look to go
utterly haywire once into a full-blown systemd userspace with cpuidle,
but I haven't got a clear picture of that yet.
Robin.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 17:08 ` Robin Murphy
(?)
(?)
@ 2018-05-29 17:18 ` Geert Uytterhoeven
-1 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 17:18 UTC (permalink / raw)
To: Robin Murphy
Cc: Will Deacon, Mark Rutland, austinwc, tnowicki, Catalin Marinas,
Palmer Dabbelt, linux-riscv, wangxiongfeng2, vkilari,
Lorenzo Pieralisi, jhugo, Morten.Rasmussen,
ACPI Devel Maling List, Len Brown, John Garry, Al Stone,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki,
Linux Kernel Mailing List
Hi Robin,
On Tue, May 29, 2018 at 7:08 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 29/05/18 16:51, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com>
>>>>> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA
>>> configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff
>>> below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> Do you have CONFIG_NUMA enabled? On a hunch I've managed to reproduce what
> looks like the same thing on a Juno board with NUMA=n; going in with
> external debug it seems to be stuck in the loop in
> init_sched_groups_capacity(), with an approximate stack trace of:
CONFIG_NUMA is not set.
I'm basically using renesas_defconfig from
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git/log/?h=topic/renesas-defconfig
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 17:18 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 17:18 UTC (permalink / raw)
To: linux-arm-kernel
Hi Robin,
On Tue, May 29, 2018 at 7:08 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 29/05/18 16:51, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com>
>>>>> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA
>>> configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff
>>> below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> Do you have CONFIG_NUMA enabled? On a hunch I've managed to reproduce what
> looks like the same thing on a Juno board with NUMA=n; going in with
> external debug it seems to be stuck in the loop in
> init_sched_groups_capacity(), with an approximate stack trace of:
CONFIG_NUMA is not set.
I'm basically using renesas_defconfig from
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git/log/?h=topic/renesas-defconfig
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 17:18 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 17:18 UTC (permalink / raw)
To: linux-riscv
Hi Robin,
On Tue, May 29, 2018 at 7:08 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 29/05/18 16:51, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com>
>>>>> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA
>>> configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff
>>> below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> Do you have CONFIG_NUMA enabled? On a hunch I've managed to reproduce what
> looks like the same thing on a Juno board with NUMA=n; going in with
> external debug it seems to be stuck in the loop in
> init_sched_groups_capacity(), with an approximate stack trace of:
CONFIG_NUMA is not set.
I'm basically using renesas_defconfig from
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git/log/?h=topic/renesas-defconfig
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 17:18 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 17:18 UTC (permalink / raw)
To: Robin Murphy
Cc: Will Deacon, Mark Rutland, austinwc, tnowicki, Catalin Marinas,
Palmer Dabbelt, linux-riscv, wangxiongfeng2, vkilari,
Lorenzo Pieralisi, jhugo, Morten.Rasmussen,
ACPI Devel Maling List, Len Brown, John Garry, Al Stone,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki,
Linux Kernel Mailing List, Jeremy Linton, Linux-Renesas,
Hanjun Guo, Sudeep Holla, Dietmar Eggemann
Hi Robin,
On Tue, May 29, 2018 at 7:08 PM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 29/05/18 16:51, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com>
>>>>> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA
>>> configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff
>>> below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> Do you have CONFIG_NUMA enabled? On a hunch I've managed to reproduce what
> looks like the same thing on a Juno board with NUMA=n; going in with
> external debug it seems to be stuck in the loop in
> init_sched_groups_capacity(), with an approximate stack trace of:
CONFIG_NUMA is not set.
I'm basically using renesas_defconfig from
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git/log/?h=topic/renesas-defconfig
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 17:08 ` Robin Murphy
(?)
(?)
@ 2018-05-29 17:31 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-29 17:31 UTC (permalink / raw)
To: Robin Murphy, Geert Uytterhoeven, Will Deacon
Cc: Sudeep Holla, Mark Rutland, austinwc, tnowicki, Catalin Marinas,
Palmer Dabbelt, linux-riscv, wangxiongfeng2, vkilari,
Lorenzo Pieralisi, jhugo, Morten.Rasmussen,
ACPI Devel Maling List, Len Brown, John Garry, Al Stone,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki,
Linux Kernel Mailing List
On 29/05/18 18:08, Robin Murphy wrote:
> On 29/05/18 16:51, Geert Uytterhoeven wrote:
>> Hi Will,
>>
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla
>>>>> <sudeep.holla@arm.com> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>>
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA
>>> configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff
>>> below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> Do you have CONFIG_NUMA enabled? On a hunch I've managed to reproduce
> what looks like the same thing on a Juno board with NUMA=n; going in
> with external debug it seems to be stuck in the loop in
> init_sched_groups_capacity(), with an approximate stack trace of:
>
>
> init_sched_groups_capacity()
> partition_sched_domains()
> cpuset_cpu_active()
> sched_cpu_activate()
> cpuhp_invoke_callback()
> cpuhp_thread_fn()
>
> My hunch is based on the fact that it looks like we can, under the right
> circumstances, end up with default_topology picking up cpu_online_mask
> as a sibling mask via cpu_coregroup_mask(), and given the great
> coincidence that that's going to change when hotplugging out CPUs on
> suspend, things might not react too well to that. Things also look to go
> utterly haywire once into a full-blown systemd userspace with cpuidle,
> but I haven't got a clear picture of that yet.
>
Yes, I too observed the same. I was able to suspend resume if I have
cpuidle disabled.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 17:31 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-29 17:31 UTC (permalink / raw)
To: linux-arm-kernel
On 29/05/18 18:08, Robin Murphy wrote:
> On 29/05/18 16:51, Geert Uytterhoeven wrote:
>> Hi Will,
>>
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla
>>>>> <sudeep.holla@arm.com> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> ???? R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> ???? R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>>
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA
>>> configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff
>>> below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> Do you have CONFIG_NUMA enabled? On a hunch I've managed to reproduce
> what looks like the same thing on a Juno board with NUMA=n; going in
> with external debug it seems to be stuck in the loop in
> init_sched_groups_capacity(), with an approximate stack trace of:
>
>
> init_sched_groups_capacity()
> partition_sched_domains()
> cpuset_cpu_active()
> sched_cpu_activate()
> cpuhp_invoke_callback()
> cpuhp_thread_fn()
>
> My hunch is based on the fact that it looks like we can, under the right
> circumstances, end up with default_topology picking up cpu_online_mask
> as a sibling mask via cpu_coregroup_mask(), and given the great
> coincidence that that's going to change when hotplugging out CPUs on
> suspend, things might not react too well to that. Things also look to go
> utterly haywire once into a full-blown systemd userspace with cpuidle,
> but I haven't got a clear picture of that yet.
>
Yes, I too observed the same. I was able to suspend resume if I have
cpuidle disabled.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 17:31 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-29 17:31 UTC (permalink / raw)
To: linux-riscv
On 29/05/18 18:08, Robin Murphy wrote:
> On 29/05/18 16:51, Geert Uytterhoeven wrote:
>> Hi Will,
>>
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla
>>>>> <sudeep.holla@arm.com> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> ???? R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> ???? R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>>
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA
>>> configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff
>>> below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> Do you have CONFIG_NUMA enabled? On a hunch I've managed to reproduce
> what looks like the same thing on a Juno board with NUMA=n; going in
> with external debug it seems to be stuck in the loop in
> init_sched_groups_capacity(), with an approximate stack trace of:
>
>
> init_sched_groups_capacity()
> partition_sched_domains()
> cpuset_cpu_active()
> sched_cpu_activate()
> cpuhp_invoke_callback()
> cpuhp_thread_fn()
>
> My hunch is based on the fact that it looks like we can, under the right
> circumstances, end up with default_topology picking up cpu_online_mask
> as a sibling mask via cpu_coregroup_mask(), and given the great
> coincidence that that's going to change when hotplugging out CPUs on
> suspend, things might not react too well to that. Things also look to go
> utterly haywire once into a full-blown systemd userspace with cpuidle,
> but I haven't got a clear picture of that yet.
>
Yes, I too observed the same. I was able to suspend resume if I have
cpuidle disabled.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 17:31 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-29 17:31 UTC (permalink / raw)
To: Robin Murphy, Geert Uytterhoeven, Will Deacon
Cc: Sudeep Holla, Mark Rutland, austinwc, tnowicki, Catalin Marinas,
Palmer Dabbelt, linux-riscv, wangxiongfeng2, vkilari,
Lorenzo Pieralisi, jhugo, Morten.Rasmussen,
ACPI Devel Maling List, Len Brown, John Garry, Al Stone,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki,
Linux Kernel Mailing List, Jeremy Linton, Linux-Renesas,
Hanjun Guo, Dietmar Eggemann
On 29/05/18 18:08, Robin Murphy wrote:
> On 29/05/18 16:51, Geert Uytterhoeven wrote:
>> Hi Will,
>>
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla
>>>>> <sudeep.holla@arm.com> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>>
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA
>>> configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff
>>> below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> Do you have CONFIG_NUMA enabled? On a hunch I've managed to reproduce
> what looks like the same thing on a Juno board with NUMA=n; going in
> with external debug it seems to be stuck in the loop in
> init_sched_groups_capacity(), with an approximate stack trace of:
>
>
> init_sched_groups_capacity()
> partition_sched_domains()
> cpuset_cpu_active()
> sched_cpu_activate()
> cpuhp_invoke_callback()
> cpuhp_thread_fn()
>
> My hunch is based on the fact that it looks like we can, under the right
> circumstances, end up with default_topology picking up cpu_online_mask
> as a sibling mask via cpu_coregroup_mask(), and given the great
> coincidence that that's going to change when hotplugging out CPUs on
> suspend, things might not react too well to that. Things also look to go
> utterly haywire once into a full-blown systemd userspace with cpuidle,
> but I haven't got a clear picture of that yet.
>
Yes, I too observed the same. I was able to suspend resume if I have
cpuidle disabled.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 15:51 ` Geert Uytterhoeven
(?)
(?)
@ 2018-05-29 20:16 ` Will Deacon
-1 siblings, 0 replies; 185+ messages in thread
From: Will Deacon @ 2018-05-29 20:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sudeep Holla, Catalin Marinas, Jeremy Linton,
ACPI Devel Maling List, Mark Rutland, austinwc, tnowicki,
Palmer Dabbelt, linux-riscv, Morten.Rasmussen, vkilari,
Lorenzo Pieralisi, jhugo, Al Stone, Len Brown, John Garry,
wangxiongfeng2, Dietmar Eggemann, Linux ARM, Ard Biesheuvel,
Greg KH, Rafael
Hi Geert,
On Tue, May 29, 2018 at 05:51:29PM +0200, Geert Uytterhoeven wrote:
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
> >> On 29/05/18 12:56, Geert Uytterhoeven wrote:
> >> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >> >>> System supend still works fine on systems with big cores only:
> >> >>>
> >> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> >> >>> R-Car M3-N (2xCA57)
> >> >>>
> >> >>> Reverting this commit fixes the issue for me.
> >> >>
> >> >> I can't find anything that relates to system suspend in these patches
> >> >> unless they are messing with something during CPU hot plug-in back
> >> >> during resume.
> >> >
> >> > It's only the last patch that introduces the breakage.
> >> >
> >>
> >> As specified in the commit log, it won't change any behavior for DT
> >> systems if it's non-NUMA or single node system. So I am still wondering
> >> what could trigger this regression.
> >
> > I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
> > to the scheduler, although I can't see how this would happen.
> >
> > Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
> > do you see anything shouting in dmesg?
>
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.
Damn, sorry for wasting your time. For the record, Catalin's been seeing
boot failures under KVM on a non-big/LITTLE machine that bisect reliably
to this patch, but we've also not been able to explain them. Worse, adding
so much as a printk makes the problem disappear.
Will
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 20:16 ` Will Deacon
0 siblings, 0 replies; 185+ messages in thread
From: Will Deacon @ 2018-05-29 20:16 UTC (permalink / raw)
To: linux-arm-kernel
Hi Geert,
On Tue, May 29, 2018 at 05:51:29PM +0200, Geert Uytterhoeven wrote:
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
> >> On 29/05/18 12:56, Geert Uytterhoeven wrote:
> >> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >> >>> System supend still works fine on systems with big cores only:
> >> >>>
> >> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> >> >>> R-Car M3-N (2xCA57)
> >> >>>
> >> >>> Reverting this commit fixes the issue for me.
> >> >>
> >> >> I can't find anything that relates to system suspend in these patches
> >> >> unless they are messing with something during CPU hot plug-in back
> >> >> during resume.
> >> >
> >> > It's only the last patch that introduces the breakage.
> >> >
> >>
> >> As specified in the commit log, it won't change any behavior for DT
> >> systems if it's non-NUMA or single node system. So I am still wondering
> >> what could trigger this regression.
> >
> > I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
> > to the scheduler, although I can't see how this would happen.
> >
> > Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
> > do you see anything shouting in dmesg?
>
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.
Damn, sorry for wasting your time. For the record, Catalin's been seeing
boot failures under KVM on a non-big/LITTLE machine that bisect reliably
to this patch, but we've also not been able to explain them. Worse, adding
so much as a printk makes the problem disappear.
Will
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 20:16 ` Will Deacon
0 siblings, 0 replies; 185+ messages in thread
From: Will Deacon @ 2018-05-29 20:16 UTC (permalink / raw)
To: linux-riscv
Hi Geert,
On Tue, May 29, 2018 at 05:51:29PM +0200, Geert Uytterhoeven wrote:
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
> >> On 29/05/18 12:56, Geert Uytterhoeven wrote:
> >> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >> >>> System supend still works fine on systems with big cores only:
> >> >>>
> >> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> >> >>> R-Car M3-N (2xCA57)
> >> >>>
> >> >>> Reverting this commit fixes the issue for me.
> >> >>
> >> >> I can't find anything that relates to system suspend in these patches
> >> >> unless they are messing with something during CPU hot plug-in back
> >> >> during resume.
> >> >
> >> > It's only the last patch that introduces the breakage.
> >> >
> >>
> >> As specified in the commit log, it won't change any behavior for DT
> >> systems if it's non-NUMA or single node system. So I am still wondering
> >> what could trigger this regression.
> >
> > I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
> > to the scheduler, although I can't see how this would happen.
> >
> > Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
> > do you see anything shouting in dmesg?
>
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.
Damn, sorry for wasting your time. For the record, Catalin's been seeing
boot failures under KVM on a non-big/LITTLE machine that bisect reliably
to this patch, but we've also not been able to explain them. Worse, adding
so much as a printk makes the problem disappear.
Will
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 20:16 ` Will Deacon
0 siblings, 0 replies; 185+ messages in thread
From: Will Deacon @ 2018-05-29 20:16 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sudeep Holla, Catalin Marinas, Jeremy Linton,
ACPI Devel Maling List, Mark Rutland, austinwc, tnowicki,
Palmer Dabbelt, linux-riscv, Morten.Rasmussen, vkilari,
Lorenzo Pieralisi, jhugo, Al Stone, Len Brown, John Garry,
wangxiongfeng2, Dietmar Eggemann, Linux ARM, Ard Biesheuvel,
Greg KH, Rafael J. Wysocki, Linux Kernel Mailing List,
Hanjun Guo, Linux-Renesas
Hi Geert,
On Tue, May 29, 2018 at 05:51:29PM +0200, Geert Uytterhoeven wrote:
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
> >> On 29/05/18 12:56, Geert Uytterhoeven wrote:
> >> > On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >> >> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >> >>> System supend still works fine on systems with big cores only:
> >> >>>
> >> >>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
> >> >>> R-Car M3-N (2xCA57)
> >> >>>
> >> >>> Reverting this commit fixes the issue for me.
> >> >>
> >> >> I can't find anything that relates to system suspend in these patches
> >> >> unless they are messing with something during CPU hot plug-in back
> >> >> during resume.
> >> >
> >> > It's only the last patch that introduces the breakage.
> >> >
> >>
> >> As specified in the commit log, it won't change any behavior for DT
> >> systems if it's non-NUMA or single node system. So I am still wondering
> >> what could trigger this regression.
> >
> > I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
> > to the scheduler, although I can't see how this would happen.
> >
> > Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
> > do you see anything shouting in dmesg?
>
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.
Damn, sorry for wasting your time. For the record, Catalin's been seeing
boot failures under KVM on a non-big/LITTLE machine that bisect reliably
to this patch, but we've also not been able to explain them. Worse, adding
so much as a printk makes the problem disappear.
Will
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 20:16 ` Will Deacon
(?)
(?)
@ 2018-05-29 20:48 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-29 20:48 UTC (permalink / raw)
To: Will Deacon, Geert Uytterhoeven
Cc: Sudeep Holla, Catalin Marinas, ACPI Devel Maling List,
Mark Rutland, austinwc, tnowicki, Palmer Dabbelt, linux-riscv,
Morten.Rasmussen, vkilari, Lorenzo Pieralisi, jhugo, Al Stone,
Len Brown, John Garry, wangxiongfeng2, Dietmar Eggemann,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki
On 05/29/2018 03:16 PM, Will Deacon wrote:
> Hi Geert,
>
> On Tue, May 29, 2018 at 05:51:29PM +0200, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>>
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> Damn, sorry for wasting your time. For the record, Catalin's been seeing
> boot failures under KVM on a non-big/LITTLE machine that bisect reliably
> to this patch, but we've also not been able to explain them. Worse, adding
> so much as a printk makes the problem disappear.
I was about to post a patch to remove the numa check if CONFIG_NUMA
disabled. But that seems pointless if the its happening with numa
enabled. So assuming, its the removal of the core from the numa mask
which is causing problems. It looks like numa_clear_node() might cause
similar problems when numa is enabled. In my case the problem I see is
NULL dereference in __bitmap_intersect called from select_task_rq_fair.
That said, I only see the problem when CONFIG_NUMA isn't set.
So, I've also got another work around which caches the numa node to the
cpu_topology and then only builds it when store_cpu_topology() is
called. That should stabilize the numa mask, and assure that the bit
maps are correct when the scheduler requests them.
Do you guys want that patch, or are we looking for a deeper root cause?
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 20:48 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-29 20:48 UTC (permalink / raw)
To: linux-arm-kernel
On 05/29/2018 03:16 PM, Will Deacon wrote:
> Hi Geert,
>
> On Tue, May 29, 2018 at 05:51:29PM +0200, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>>
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> Damn, sorry for wasting your time. For the record, Catalin's been seeing
> boot failures under KVM on a non-big/LITTLE machine that bisect reliably
> to this patch, but we've also not been able to explain them. Worse, adding
> so much as a printk makes the problem disappear.
I was about to post a patch to remove the numa check if CONFIG_NUMA
disabled. But that seems pointless if the its happening with numa
enabled. So assuming, its the removal of the core from the numa mask
which is causing problems. It looks like numa_clear_node() might cause
similar problems when numa is enabled. In my case the problem I see is
NULL dereference in __bitmap_intersect called from select_task_rq_fair.
That said, I only see the problem when CONFIG_NUMA isn't set.
So, I've also got another work around which caches the numa node to the
cpu_topology and then only builds it when store_cpu_topology() is
called. That should stabilize the numa mask, and assure that the bit
maps are correct when the scheduler requests them.
Do you guys want that patch, or are we looking for a deeper root cause?
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 20:48 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-29 20:48 UTC (permalink / raw)
To: linux-riscv
On 05/29/2018 03:16 PM, Will Deacon wrote:
> Hi Geert,
>
> On Tue, May 29, 2018 at 05:51:29PM +0200, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>>
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> Damn, sorry for wasting your time. For the record, Catalin's been seeing
> boot failures under KVM on a non-big/LITTLE machine that bisect reliably
> to this patch, but we've also not been able to explain them. Worse, adding
> so much as a printk makes the problem disappear.
I was about to post a patch to remove the numa check if CONFIG_NUMA
disabled. But that seems pointless if the its happening with numa
enabled. So assuming, its the removal of the core from the numa mask
which is causing problems. It looks like numa_clear_node() might cause
similar problems when numa is enabled. In my case the problem I see is
NULL dereference in __bitmap_intersect called from select_task_rq_fair.
That said, I only see the problem when CONFIG_NUMA isn't set.
So, I've also got another work around which caches the numa node to the
cpu_topology and then only builds it when store_cpu_topology() is
called. That should stabilize the numa mask, and assure that the bit
maps are correct when the scheduler requests them.
Do you guys want that patch, or are we looking for a deeper root cause?
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 20:48 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-29 20:48 UTC (permalink / raw)
To: Will Deacon, Geert Uytterhoeven
Cc: Sudeep Holla, Catalin Marinas, ACPI Devel Maling List,
Mark Rutland, austinwc, tnowicki, Palmer Dabbelt, linux-riscv,
Morten.Rasmussen, vkilari, Lorenzo Pieralisi, jhugo, Al Stone,
Len Brown, John Garry, wangxiongfeng2, Dietmar Eggemann,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki,
Linux Kernel Mailing List, Hanjun Guo, Linux-Renesas
On 05/29/2018 03:16 PM, Will Deacon wrote:
> Hi Geert,
>
> On Tue, May 29, 2018 at 05:51:29PM +0200, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>>
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> Damn, sorry for wasting your time. For the record, Catalin's been seeing
> boot failures under KVM on a non-big/LITTLE machine that bisect reliably
> to this patch, but we've also not been able to explain them. Worse, adding
> so much as a printk makes the problem disappear.
I was about to post a patch to remove the numa check if CONFIG_NUMA
disabled. But that seems pointless if the its happening with numa
enabled. So assuming, its the removal of the core from the numa mask
which is causing problems. It looks like numa_clear_node() might cause
similar problems when numa is enabled. In my case the problem I see is
NULL dereference in __bitmap_intersect called from select_task_rq_fair.
That said, I only see the problem when CONFIG_NUMA isn't set.
So, I've also got another work around which caches the numa node to the
cpu_topology and then only builds it when store_cpu_topology() is
called. That should stabilize the numa mask, and assure that the bit
maps are correct when the scheduler requests them.
Do you guys want that patch, or are we looking for a deeper root cause?
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 15:51 ` Geert Uytterhoeven
(?)
(?)
@ 2018-05-29 21:52 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-29 21:52 UTC (permalink / raw)
To: Geert Uytterhoeven, Will Deacon
Cc: Sudeep Holla, Catalin Marinas, ACPI Devel Maling List,
Mark Rutland, austinwc, tnowicki, Palmer Dabbelt, linux-riscv,
Morten.Rasmussen, vkilari, Lorenzo Pieralisi, jhugo, Al Stone,
Len Brown, John Garry, wangxiongfeng2, Dietmar Eggemann,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki
Hi,
On 05/29/2018 10:51 AM, Geert Uytterhoeven wrote:
> Hi Will,
>
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>> System supend still works fine on systems with big cores only:
>>>>>>
>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>> R-Car M3-N (2xCA57)
>>>>>>
>>>>>> Reverting this commit fixes the issue for me.
>>>>>
>>>>> I can't find anything that relates to system suspend in these patches
>>>>> unless they are messing with something during CPU hot plug-in back
>>>>> during resume.
>>>>
>>>> It's only the last patch that introduces the breakage.
>>>>
>>>
>>> As specified in the commit log, it won't change any behavior for DT
>>> systems if it's non-NUMA or single node system. So I am still wondering
>>> what could trigger this regression.
>>
>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>> to the scheduler, although I can't see how this would happen.
>>
>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>> do you see anything shouting in dmesg?
>
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.
I suspect most of the problem is related to the node mask changing at
unexpected times (particularly cores being removed from the mask). Once
I understand that more, there may be a simpler patch.
OTOH, I've been testing with this, and with it, I can't seem to
duplicate the problem with CONFIG_NUMA disabled I found.
diff --git a/arch/arm64/include/asm/topology.h
b/arch/arm64/include/asm/topology.h
index df48212f767b..7450ef5ed733 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -12,6 +12,7 @@ struct cpu_topology {
cpumask_t thread_sibling;
cpumask_t core_sibling;
cpumask_t llc_siblings;
+ cpumask_t node_siblings; /* maintain a stable node sibling list */
};
extern struct cpu_topology cpu_topology[NR_CPUS];
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index f3e2e3aec0b0..f4eb80852d78 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -677,8 +677,9 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
init_cpu_topology();
this_cpu = smp_processor_id();
- store_cpu_topology(this_cpu);
numa_store_cpu_info(this_cpu);
+ store_cpu_topology(this_cpu);
+
/*
* If UP is mandated by "nosmp" (which implies "maxcpus=0"),
don't set
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7415c166281f..6819c764537d 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -215,7 +215,7 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
+ const cpumask_t *core_mask = &cpu_topology[cpu].node_siblings;
/* Find the smaller of NUMA, core or LLC siblings */
if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
@@ -233,12 +233,16 @@ const struct cpumask *cpu_coregroup_mask(int cpu)
static void update_siblings_masks(unsigned int cpuid)
{
struct cpu_topology *cpu_topo, *cpuid_topo = &cpu_topology[cpuid];
+ int node = cpu_to_node(cpuid);
int cpu;
/* update core and thread sibling masks */
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
+ if (cpu_to_node(cpu) == node)
+ cpumask_set_cpu(cpu, &cpu_topo->node_siblings);
+
if (cpuid_topo->llc_id == cpu_topo->llc_id)
cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
@@ -311,6 +315,9 @@ static void __init reset_cpu_topology(void)
cpumask_clear(&cpu_topo->llc_siblings);
cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
+ cpumask_clear(&cpu_topo->node_siblings);
+ cpumask_set_cpu(cpu, &cpu_topo->node_siblings);
+
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
--
2.14.3
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 21:52 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-29 21:52 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On 05/29/2018 10:51 AM, Geert Uytterhoeven wrote:
> Hi Will,
>
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>> System supend still works fine on systems with big cores only:
>>>>>>
>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>> R-Car M3-N (2xCA57)
>>>>>>
>>>>>> Reverting this commit fixes the issue for me.
>>>>>
>>>>> I can't find anything that relates to system suspend in these patches
>>>>> unless they are messing with something during CPU hot plug-in back
>>>>> during resume.
>>>>
>>>> It's only the last patch that introduces the breakage.
>>>>
>>>
>>> As specified in the commit log, it won't change any behavior for DT
>>> systems if it's non-NUMA or single node system. So I am still wondering
>>> what could trigger this regression.
>>
>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>> to the scheduler, although I can't see how this would happen.
>>
>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>> do you see anything shouting in dmesg?
>
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.
I suspect most of the problem is related to the node mask changing at
unexpected times (particularly cores being removed from the mask). Once
I understand that more, there may be a simpler patch.
OTOH, I've been testing with this, and with it, I can't seem to
duplicate the problem with CONFIG_NUMA disabled I found.
diff --git a/arch/arm64/include/asm/topology.h
b/arch/arm64/include/asm/topology.h
index df48212f767b..7450ef5ed733 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -12,6 +12,7 @@ struct cpu_topology {
cpumask_t thread_sibling;
cpumask_t core_sibling;
cpumask_t llc_siblings;
+ cpumask_t node_siblings; /* maintain a stable node sibling list */
};
extern struct cpu_topology cpu_topology[NR_CPUS];
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index f3e2e3aec0b0..f4eb80852d78 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -677,8 +677,9 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
init_cpu_topology();
this_cpu = smp_processor_id();
- store_cpu_topology(this_cpu);
numa_store_cpu_info(this_cpu);
+ store_cpu_topology(this_cpu);
+
/*
* If UP is mandated by "nosmp" (which implies "maxcpus=0"),
don't set
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7415c166281f..6819c764537d 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -215,7 +215,7 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
+ const cpumask_t *core_mask = &cpu_topology[cpu].node_siblings;
/* Find the smaller of NUMA, core or LLC siblings */
if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
@@ -233,12 +233,16 @@ const struct cpumask *cpu_coregroup_mask(int cpu)
static void update_siblings_masks(unsigned int cpuid)
{
struct cpu_topology *cpu_topo, *cpuid_topo = &cpu_topology[cpuid];
+ int node = cpu_to_node(cpuid);
int cpu;
/* update core and thread sibling masks */
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
+ if (cpu_to_node(cpu) == node)
+ cpumask_set_cpu(cpu, &cpu_topo->node_siblings);
+
if (cpuid_topo->llc_id == cpu_topo->llc_id)
cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
@@ -311,6 +315,9 @@ static void __init reset_cpu_topology(void)
cpumask_clear(&cpu_topo->llc_siblings);
cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
+ cpumask_clear(&cpu_topo->node_siblings);
+ cpumask_set_cpu(cpu, &cpu_topo->node_siblings);
+
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
--
2.14.3
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 21:52 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-29 21:52 UTC (permalink / raw)
To: linux-riscv
Hi,
On 05/29/2018 10:51 AM, Geert Uytterhoeven wrote:
> Hi Will,
>
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>> System supend still works fine on systems with big cores only:
>>>>>>
>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>> R-Car M3-N (2xCA57)
>>>>>>
>>>>>> Reverting this commit fixes the issue for me.
>>>>>
>>>>> I can't find anything that relates to system suspend in these patches
>>>>> unless they are messing with something during CPU hot plug-in back
>>>>> during resume.
>>>>
>>>> It's only the last patch that introduces the breakage.
>>>>
>>>
>>> As specified in the commit log, it won't change any behavior for DT
>>> systems if it's non-NUMA or single node system. So I am still wondering
>>> what could trigger this regression.
>>
>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>> to the scheduler, although I can't see how this would happen.
>>
>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>> do you see anything shouting in dmesg?
>
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.
I suspect most of the problem is related to the node mask changing at
unexpected times (particularly cores being removed from the mask). Once
I understand that more, there may be a simpler patch.
OTOH, I've been testing with this, and with it, I can't seem to
duplicate the problem with CONFIG_NUMA disabled I found.
diff --git a/arch/arm64/include/asm/topology.h
b/arch/arm64/include/asm/topology.h
index df48212f767b..7450ef5ed733 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -12,6 +12,7 @@ struct cpu_topology {
cpumask_t thread_sibling;
cpumask_t core_sibling;
cpumask_t llc_siblings;
+ cpumask_t node_siblings; /* maintain a stable node sibling list */
};
extern struct cpu_topology cpu_topology[NR_CPUS];
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index f3e2e3aec0b0..f4eb80852d78 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -677,8 +677,9 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
init_cpu_topology();
this_cpu = smp_processor_id();
- store_cpu_topology(this_cpu);
numa_store_cpu_info(this_cpu);
+ store_cpu_topology(this_cpu);
+
/*
* If UP is mandated by "nosmp" (which implies "maxcpus=0"),
don't set
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7415c166281f..6819c764537d 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -215,7 +215,7 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
+ const cpumask_t *core_mask = &cpu_topology[cpu].node_siblings;
/* Find the smaller of NUMA, core or LLC siblings */
if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
@@ -233,12 +233,16 @@ const struct cpumask *cpu_coregroup_mask(int cpu)
static void update_siblings_masks(unsigned int cpuid)
{
struct cpu_topology *cpu_topo, *cpuid_topo = &cpu_topology[cpuid];
+ int node = cpu_to_node(cpuid);
int cpu;
/* update core and thread sibling masks */
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
+ if (cpu_to_node(cpu) == node)
+ cpumask_set_cpu(cpu, &cpu_topo->node_siblings);
+
if (cpuid_topo->llc_id == cpu_topo->llc_id)
cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
@@ -311,6 +315,9 @@ static void __init reset_cpu_topology(void)
cpumask_clear(&cpu_topo->llc_siblings);
cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
+ cpumask_clear(&cpu_topo->node_siblings);
+ cpumask_set_cpu(cpu, &cpu_topo->node_siblings);
+
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
--
2.14.3
^ permalink raw reply related [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 21:52 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-29 21:52 UTC (permalink / raw)
To: Geert Uytterhoeven, Will Deacon
Cc: Sudeep Holla, Catalin Marinas, ACPI Devel Maling List,
Mark Rutland, austinwc, tnowicki, Palmer Dabbelt, linux-riscv,
Morten.Rasmussen, vkilari, Lorenzo Pieralisi, jhugo, Al Stone,
Len Brown, John Garry, wangxiongfeng2, Dietmar Eggemann,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki,
Linux Kernel Mailing List, Hanjun Guo, Linux-Renesas
Hi,
On 05/29/2018 10:51 AM, Geert Uytterhoeven wrote:
> Hi Will,
>
> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>> System supend still works fine on systems with big cores only:
>>>>>>
>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>> R-Car M3-N (2xCA57)
>>>>>>
>>>>>> Reverting this commit fixes the issue for me.
>>>>>
>>>>> I can't find anything that relates to system suspend in these patches
>>>>> unless they are messing with something during CPU hot plug-in back
>>>>> during resume.
>>>>
>>>> It's only the last patch that introduces the breakage.
>>>>
>>>
>>> As specified in the commit log, it won't change any behavior for DT
>>> systems if it's non-NUMA or single node system. So I am still wondering
>>> what could trigger this regression.
>>
>> I wonder if we're somehow giving an uninitialised/invalid NUMA configuration
>> to the scheduler, although I can't see how this would happen.
>>
>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff below
>> do you see anything shouting in dmesg?
>
> Thanks, but unfortunately it doesn't help.
> I added some debug code to print cpumask, but so far I don't see anything
> suspicious.
I suspect most of the problem is related to the node mask changing at
unexpected times (particularly cores being removed from the mask). Once
I understand that more, there may be a simpler patch.
OTOH, I've been testing with this, and with it, I can't seem to
duplicate the problem with CONFIG_NUMA disabled I found.
diff --git a/arch/arm64/include/asm/topology.h
b/arch/arm64/include/asm/topology.h
index df48212f767b..7450ef5ed733 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -12,6 +12,7 @@ struct cpu_topology {
cpumask_t thread_sibling;
cpumask_t core_sibling;
cpumask_t llc_siblings;
+ cpumask_t node_siblings; /* maintain a stable node sibling list */
};
extern struct cpu_topology cpu_topology[NR_CPUS];
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index f3e2e3aec0b0..f4eb80852d78 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -677,8 +677,9 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
init_cpu_topology();
this_cpu = smp_processor_id();
- store_cpu_topology(this_cpu);
numa_store_cpu_info(this_cpu);
+ store_cpu_topology(this_cpu);
+
/*
* If UP is mandated by "nosmp" (which implies "maxcpus=0"),
don't set
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7415c166281f..6819c764537d 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -215,7 +215,7 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
+ const cpumask_t *core_mask = &cpu_topology[cpu].node_siblings;
/* Find the smaller of NUMA, core or LLC siblings */
if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
@@ -233,12 +233,16 @@ const struct cpumask *cpu_coregroup_mask(int cpu)
static void update_siblings_masks(unsigned int cpuid)
{
struct cpu_topology *cpu_topo, *cpuid_topo = &cpu_topology[cpuid];
+ int node = cpu_to_node(cpuid);
int cpu;
/* update core and thread sibling masks */
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
+ if (cpu_to_node(cpu) == node)
+ cpumask_set_cpu(cpu, &cpu_topo->node_siblings);
+
if (cpuid_topo->llc_id == cpu_topo->llc_id)
cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
@@ -311,6 +315,9 @@ static void __init reset_cpu_topology(void)
cpumask_clear(&cpu_topo->llc_siblings);
cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
+ cpumask_clear(&cpu_topo->node_siblings);
+ cpumask_set_cpu(cpu, &cpu_topo->node_siblings);
+
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
--
2.14.3
^ permalink raw reply related [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 21:52 ` Jeremy Linton
(?)
(?)
@ 2018-05-30 13:24 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-30 13:24 UTC (permalink / raw)
To: Jeremy Linton, Geert Uytterhoeven, Will Deacon
Cc: Sudeep Holla, Catalin Marinas, ACPI Devel Maling List,
Mark Rutland, austinwc, tnowicki, Palmer Dabbelt, linux-riscv,
Morten.Rasmussen, vkilari, Lorenzo Pieralisi, jhugo, Al Stone,
Len Brown, John Garry, wangxiongfeng2, Dietmar Eggemann,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki
On 29/05/18 22:52, Jeremy Linton wrote:
> Hi,
>
> On 05/29/2018 10:51 AM, Geert Uytterhoeven wrote:
>> Hi Will,
>>
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla
>>>>> <sudeep.holla@arm.com> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>>
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA
>>> configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff
>>> below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> I suspect most of the problem is related to the node mask changing at
> unexpected times (particularly cores being removed from the mask). Once
> I understand that more, there may be a simpler patch.
>
> OTOH, I've been testing with this, and with it, I can't seem to
> duplicate the problem with CONFIG_NUMA disabled I found.
>
I am also giving it a run on my Juno(defconfig - CONFIG_NUMA) and CPU
hotplug tests are fine with this change.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-30 13:24 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-30 13:24 UTC (permalink / raw)
To: linux-arm-kernel
On 29/05/18 22:52, Jeremy Linton wrote:
> Hi,
>
> On 05/29/2018 10:51 AM, Geert Uytterhoeven wrote:
>> Hi Will,
>>
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla
>>>>> <sudeep.holla@arm.com> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> ???? R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> ???? R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>>
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA
>>> configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff
>>> below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> I suspect most of the problem is related to the node mask changing at
> unexpected times (particularly cores being removed from the mask). Once
> I understand that more, there may be a simpler patch.
>
> OTOH, I've been testing with this, and with it, I can't seem to
> duplicate the problem with CONFIG_NUMA disabled I found.
>
I am also giving it a run on my Juno(defconfig - CONFIG_NUMA) and CPU
hotplug tests are fine with this change.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-30 13:24 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-30 13:24 UTC (permalink / raw)
To: linux-riscv
On 29/05/18 22:52, Jeremy Linton wrote:
> Hi,
>
> On 05/29/2018 10:51 AM, Geert Uytterhoeven wrote:
>> Hi Will,
>>
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla
>>>>> <sudeep.holla@arm.com> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> ???? R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> ???? R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>>
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA
>>> configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff
>>> below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> I suspect most of the problem is related to the node mask changing at
> unexpected times (particularly cores being removed from the mask). Once
> I understand that more, there may be a simpler patch.
>
> OTOH, I've been testing with this, and with it, I can't seem to
> duplicate the problem with CONFIG_NUMA disabled I found.
>
I am also giving it a run on my Juno(defconfig - CONFIG_NUMA) and CPU
hotplug tests are fine with this change.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-30 13:24 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-05-30 13:24 UTC (permalink / raw)
To: Jeremy Linton, Geert Uytterhoeven, Will Deacon
Cc: Sudeep Holla, Catalin Marinas, ACPI Devel Maling List,
Mark Rutland, austinwc, tnowicki, Palmer Dabbelt, linux-riscv,
Morten.Rasmussen, vkilari, Lorenzo Pieralisi, jhugo, Al Stone,
Len Brown, John Garry, wangxiongfeng2, Dietmar Eggemann,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki,
Linux Kernel Mailing List, Hanjun Guo, Linux-Renesas
On 29/05/18 22:52, Jeremy Linton wrote:
> Hi,
>
> On 05/29/2018 10:51 AM, Geert Uytterhoeven wrote:
>> Hi Will,
>>
>> On Tue, May 29, 2018 at 5:08 PM, Will Deacon <will.deacon@arm.com> wrote:
>>> On Tue, May 29, 2018 at 02:18:40PM +0100, Sudeep Holla wrote:
>>>> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>>>>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla
>>>>> <sudeep.holla@arm.com> wrote:
>>>>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>>>>> System supend still works fine on systems with big cores only:
>>>>>>>
>>>>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>>>>> R-Car M3-N (2xCA57)
>>>>>>>
>>>>>>> Reverting this commit fixes the issue for me.
>>>>>>
>>>>>> I can't find anything that relates to system suspend in these patches
>>>>>> unless they are messing with something during CPU hot plug-in back
>>>>>> during resume.
>>>>>
>>>>> It's only the last patch that introduces the breakage.
>>>>>
>>>>
>>>> As specified in the commit log, it won't change any behavior for DT
>>>> systems if it's non-NUMA or single node system. So I am still wondering
>>>> what could trigger this regression.
>>>
>>> I wonder if we're somehow giving an uninitialised/invalid NUMA
>>> configuration
>>> to the scheduler, although I can't see how this would happen.
>>>
>>> Geert -- if you enable CONFIG_DEBUG_PER_CPU_MAPS=y and apply the diff
>>> below
>>> do you see anything shouting in dmesg?
>>
>> Thanks, but unfortunately it doesn't help.
>> I added some debug code to print cpumask, but so far I don't see anything
>> suspicious.
>
> I suspect most of the problem is related to the node mask changing at
> unexpected times (particularly cores being removed from the mask). Once
> I understand that more, there may be a simpler patch.
>
> OTOH, I've been testing with this, and with it, I can't seem to
> duplicate the problem with CONFIG_NUMA disabled I found.
>
I am also giving it a run on my Juno(defconfig - CONFIG_NUMA) and CPU
hotplug tests are fine with this change.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 13:18 ` Sudeep Holla
(?)
(?)
@ 2018-05-29 15:23 ` Jeremy Linton
-1 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-29 15:23 UTC (permalink / raw)
To: Sudeep Holla, Geert Uytterhoeven
Cc: Catalin Marinas, ACPI Devel Maling List, Mark Rutland, austinwc,
tnowicki, Palmer Dabbelt, Will Deacon, linux-riscv,
Morten.Rasmussen, vkilari, Lorenzo Pieralisi, jhugo, Al Stone,
Len Brown, John Garry, wangxiongfeng2, Dietmar Eggemann,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki
Hi,
On 05/29/2018 08:18 AM, Sudeep Holla wrote:
>
>
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> Hi Sudeep,
>>
>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>>> <catalin.marinas@arm.com> wrote:
>>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>>> Jeremy Linton (12):
>>>>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>>>>> drivers: base: cacheinfo: setup DT cache properties early
>>>>>> cacheinfo: rename of_node to fw_token
>>>>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>>>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>>>>> ACPI: Enable PPTT support on ARM64
>>>>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>>>>> arm64: Add support for ACPI based firmware tables
>>>>>> arm64: topology: rename cluster_id
>>>>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>>>>> ACPI: Add PPTT to injectable table list
>>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>>
>>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
>>>>> can add it separately).
>>>>
>>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>>> CPU:
>>>>
>>>> $ echo mem > /sys/power/state
>>>> PM: suspend entry (deep)
>>>> PM: Syncing filesystems ... done.
>>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>>> OOM killer disabled.
>>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>>> Disabling non-boot CPUs ...
>>>> CPU1: shutdown
>>>> psci: CPU1 killed.
>>>>
>>>
>>> Is it OK to assume the suspend failed just after shutting down one CPU
>>> or it's failing during resume ? It depends on whether you had console
>>> disabled or not.
>>
>> I have no-console-suspend enabled.
>> It's failing during suspend, the next lines should be:
>>
>> CPU2: shutdown
>> psci: CPU2 killed.
>> ...
>>
>
> OK, I was hoping to be something during resume as this patch has nothing
> executed during suspend. Do you see any change in topology before and
> after this patch applied. I am interested in the output of:
>
> $ grep "" /sys/devices/system/cpu/cpu*/topology/*
>
>>>> For me, it fails on the following big.LITTLE systems:
>>>>
>>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>>
>>>
>>> Interesting, is it PSCI based system suspend ?
>>
>> Yes it is.
>>
>> Suspend-to-idle, which doesn't offline CPUs, still works.
>>
>
> From DT, I guess this platform doesn't have any idle states.
> Does this use genpd power domains ? I see power-domains in the DT, so
> asking to get more info. Do you have any out of tree patches especially
> if they are depending on some topology cpumasks ?
>
>>>> System supend still works fine on systems with big cores only:
>>>>
>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>> R-Car M3-N (2xCA57)
>>>>
>>>> Reverting this commit fixes the issue for me.
>>>
>>> I can't find anything that relates to system suspend in these patches
>>> unless they are messing with something during CPU hot plug-in back
>>> during resume.
>>
>> It's only the last patch that introduces the breakage.
>>
>
> As specified in the commit log, it won't change any behavior for DT
> systems if it's non-NUMA or single node system. So I am still wondering
> what could trigger this regression.
>
So, presumably the problem is that the numa mask is smaller than the
normal core_siblings...
I would verify that that there is a behavior change with something like
/proc/schedstat | cut -d ' ' -f-2
There might be something odd happening with whether you have CONFIG_NUMA
set (looking at that right now).
So, a couple quick todo's, see if the schedstat domains are changing
with/without the last patch, and also see if they are changing if you
enable/disable NUMA.
Why any of that matters for suspend isn't clear at the moment.
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 15:23 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-29 15:23 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
On 05/29/2018 08:18 AM, Sudeep Holla wrote:
>
>
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> Hi Sudeep,
>>
>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>>> <catalin.marinas@arm.com> wrote:
>>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>>> Jeremy Linton (12):
>>>>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>>>>> drivers: base: cacheinfo: setup DT cache properties early
>>>>>> cacheinfo: rename of_node to fw_token
>>>>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>>>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>>>>> ACPI: Enable PPTT support on ARM64
>>>>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>>>>> arm64: Add support for ACPI based firmware tables
>>>>>> arm64: topology: rename cluster_id
>>>>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>>>>> ACPI: Add PPTT to injectable table list
>>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>>
>>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
>>>>> can add it separately).
>>>>
>>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>>> CPU:
>>>>
>>>> $ echo mem > /sys/power/state
>>>> PM: suspend entry (deep)
>>>> PM: Syncing filesystems ... done.
>>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>>> OOM killer disabled.
>>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>>> Disabling non-boot CPUs ...
>>>> CPU1: shutdown
>>>> psci: CPU1 killed.
>>>>
>>>
>>> Is it OK to assume the suspend failed just after shutting down one CPU
>>> or it's failing during resume ? It depends on whether you had console
>>> disabled or not.
>>
>> I have no-console-suspend enabled.
>> It's failing during suspend, the next lines should be:
>>
>> CPU2: shutdown
>> psci: CPU2 killed.
>> ...
>>
>
> OK, I was hoping to be something during resume as this patch has nothing
> executed during suspend. Do you see any change in topology before and
> after this patch applied. I am interested in the output of:
>
> $ grep "" /sys/devices/system/cpu/cpu*/topology/*
>
>>>> For me, it fails on the following big.LITTLE systems:
>>>>
>>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>>
>>>
>>> Interesting, is it PSCI based system suspend ?
>>
>> Yes it is.
>>
>> Suspend-to-idle, which doesn't offline CPUs, still works.
>>
>
> From DT, I guess this platform doesn't have any idle states.
> Does this use genpd power domains ? I see power-domains in the DT, so
> asking to get more info. Do you have any out of tree patches especially
> if they are depending on some topology cpumasks ?
>
>>>> System supend still works fine on systems with big cores only:
>>>>
>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>> R-Car M3-N (2xCA57)
>>>>
>>>> Reverting this commit fixes the issue for me.
>>>
>>> I can't find anything that relates to system suspend in these patches
>>> unless they are messing with something during CPU hot plug-in back
>>> during resume.
>>
>> It's only the last patch that introduces the breakage.
>>
>
> As specified in the commit log, it won't change any behavior for DT
> systems if it's non-NUMA or single node system. So I am still wondering
> what could trigger this regression.
>
So, presumably the problem is that the numa mask is smaller than the
normal core_siblings...
I would verify that that there is a behavior change with something like
/proc/schedstat | cut -d ' ' -f-2
There might be something odd happening with whether you have CONFIG_NUMA
set (looking at that right now).
So, a couple quick todo's, see if the schedstat domains are changing
with/without the last patch, and also see if they are changing if you
enable/disable NUMA.
Why any of that matters for suspend isn't clear at the moment.
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 15:23 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-29 15:23 UTC (permalink / raw)
To: linux-riscv
Hi,
On 05/29/2018 08:18 AM, Sudeep Holla wrote:
>
>
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> Hi Sudeep,
>>
>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>>> <catalin.marinas@arm.com> wrote:
>>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>>> Jeremy Linton (12):
>>>>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>>>>> drivers: base: cacheinfo: setup DT cache properties early
>>>>>> cacheinfo: rename of_node to fw_token
>>>>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>>>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>>>>> ACPI: Enable PPTT support on ARM64
>>>>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>>>>> arm64: Add support for ACPI based firmware tables
>>>>>> arm64: topology: rename cluster_id
>>>>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>>>>> ACPI: Add PPTT to injectable table list
>>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>>
>>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
>>>>> can add it separately).
>>>>
>>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>>> CPU:
>>>>
>>>> $ echo mem > /sys/power/state
>>>> PM: suspend entry (deep)
>>>> PM: Syncing filesystems ... done.
>>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>>> OOM killer disabled.
>>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>>> Disabling non-boot CPUs ...
>>>> CPU1: shutdown
>>>> psci: CPU1 killed.
>>>>
>>>
>>> Is it OK to assume the suspend failed just after shutting down one CPU
>>> or it's failing during resume ? It depends on whether you had console
>>> disabled or not.
>>
>> I have no-console-suspend enabled.
>> It's failing during suspend, the next lines should be:
>>
>> CPU2: shutdown
>> psci: CPU2 killed.
>> ...
>>
>
> OK, I was hoping to be something during resume as this patch has nothing
> executed during suspend. Do you see any change in topology before and
> after this patch applied. I am interested in the output of:
>
> $ grep "" /sys/devices/system/cpu/cpu*/topology/*
>
>>>> For me, it fails on the following big.LITTLE systems:
>>>>
>>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>>
>>>
>>> Interesting, is it PSCI based system suspend ?
>>
>> Yes it is.
>>
>> Suspend-to-idle, which doesn't offline CPUs, still works.
>>
>
> From DT, I guess this platform doesn't have any idle states.
> Does this use genpd power domains ? I see power-domains in the DT, so
> asking to get more info. Do you have any out of tree patches especially
> if they are depending on some topology cpumasks ?
>
>>>> System supend still works fine on systems with big cores only:
>>>>
>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>> R-Car M3-N (2xCA57)
>>>>
>>>> Reverting this commit fixes the issue for me.
>>>
>>> I can't find anything that relates to system suspend in these patches
>>> unless they are messing with something during CPU hot plug-in back
>>> during resume.
>>
>> It's only the last patch that introduces the breakage.
>>
>
> As specified in the commit log, it won't change any behavior for DT
> systems if it's non-NUMA or single node system. So I am still wondering
> what could trigger this regression.
>
So, presumably the problem is that the numa mask is smaller than the
normal core_siblings...
I would verify that that there is a behavior change with something like
/proc/schedstat | cut -d ' ' -f-2
There might be something odd happening with whether you have CONFIG_NUMA
set (looking at that right now).
So, a couple quick todo's, see if the schedstat domains are changing
with/without the last patch, and also see if they are changing if you
enable/disable NUMA.
Why any of that matters for suspend isn't clear at the moment.
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 15:23 ` Jeremy Linton
0 siblings, 0 replies; 185+ messages in thread
From: Jeremy Linton @ 2018-05-29 15:23 UTC (permalink / raw)
To: Sudeep Holla, Geert Uytterhoeven
Cc: Catalin Marinas, ACPI Devel Maling List, Mark Rutland, austinwc,
tnowicki, Palmer Dabbelt, Will Deacon, linux-riscv,
Morten.Rasmussen, vkilari, Lorenzo Pieralisi, jhugo, Al Stone,
Len Brown, John Garry, wangxiongfeng2, Dietmar Eggemann,
Linux ARM, Ard Biesheuvel, Greg KH, Rafael J. Wysocki,
Linux Kernel Mailing List, Hanjun Guo, Linux-Renesas
Hi,
On 05/29/2018 08:18 AM, Sudeep Holla wrote:
>
>
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> Hi Sudeep,
>>
>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>>> <catalin.marinas@arm.com> wrote:
>>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>>> Jeremy Linton (12):
>>>>>> drivers: base: cacheinfo: move cache_setup_of_node()
>>>>>> drivers: base: cacheinfo: setup DT cache properties early
>>>>>> cacheinfo: rename of_node to fw_token
>>>>>> arm64/acpi: Create arch specific cpu to acpi id helper
>>>>>> ACPI/PPTT: Add Processor Properties Topology Table parsing
>>>>>> ACPI: Enable PPTT support on ARM64
>>>>>> drivers: base cacheinfo: Add support for ACPI based firmware tables
>>>>>> arm64: Add support for ACPI based firmware tables
>>>>>> arm64: topology: rename cluster_id
>>>>>> arm64: topology: enable ACPI/PPTT based CPU topology
>>>>>> ACPI: Add PPTT to injectable table list
>>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>>
>>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
>>>>> can add it separately).
>>>>
>>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>>> CPU:
>>>>
>>>> $ echo mem > /sys/power/state
>>>> PM: suspend entry (deep)
>>>> PM: Syncing filesystems ... done.
>>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>>> OOM killer disabled.
>>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>>> Disabling non-boot CPUs ...
>>>> CPU1: shutdown
>>>> psci: CPU1 killed.
>>>>
>>>
>>> Is it OK to assume the suspend failed just after shutting down one CPU
>>> or it's failing during resume ? It depends on whether you had console
>>> disabled or not.
>>
>> I have no-console-suspend enabled.
>> It's failing during suspend, the next lines should be:
>>
>> CPU2: shutdown
>> psci: CPU2 killed.
>> ...
>>
>
> OK, I was hoping to be something during resume as this patch has nothing
> executed during suspend. Do you see any change in topology before and
> after this patch applied. I am interested in the output of:
>
> $ grep "" /sys/devices/system/cpu/cpu*/topology/*
>
>>>> For me, it fails on the following big.LITTLE systems:
>>>>
>>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>>
>>>
>>> Interesting, is it PSCI based system suspend ?
>>
>> Yes it is.
>>
>> Suspend-to-idle, which doesn't offline CPUs, still works.
>>
>
> From DT, I guess this platform doesn't have any idle states.
> Does this use genpd power domains ? I see power-domains in the DT, so
> asking to get more info. Do you have any out of tree patches especially
> if they are depending on some topology cpumasks ?
>
>>>> System supend still works fine on systems with big cores only:
>>>>
>>>> R-Car H3 ES1.0 (4xCA57 (4xCA53 disabled in firmware))
>>>> R-Car M3-N (2xCA57)
>>>>
>>>> Reverting this commit fixes the issue for me.
>>>
>>> I can't find anything that relates to system suspend in these patches
>>> unless they are messing with something during CPU hot plug-in back
>>> during resume.
>>
>> It's only the last patch that introduces the breakage.
>>
>
> As specified in the commit log, it won't change any behavior for DT
> systems if it's non-NUMA or single node system. So I am still wondering
> what could trigger this regression.
>
So, presumably the problem is that the numa mask is smaller than the
normal core_siblings...
I would verify that that there is a behavior change with something like
/proc/schedstat | cut -d ' ' -f-2
There might be something odd happening with whether you have CONFIG_NUMA
set (looking at that right now).
So, a couple quick todo's, see if the schedstat domains are changing
with/without the last patch, and also see if they are changing if you
enable/disable NUMA.
Why any of that matters for suspend isn't clear at the moment.
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 13:18 ` Sudeep Holla
(?)
(?)
@ 2018-05-29 15:50 ` Geert Uytterhoeven
-1 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 15:50 UTC (permalink / raw)
To: Sudeep Holla
Cc: Catalin Marinas, Jeremy Linton, ACPI Devel Maling List,
Mark Rutland, austinwc, tnowicki, Palmer Dabbelt, Will Deacon,
linux-riscv, Morten.Rasmussen, vkilari, Lorenzo Pieralisi, jhugo,
Al Stone, Len Brown, John Garry, wangxiongfeng2,
Dietmar Eggemann, Linux ARM, Ard Biesheuvel, Greg KH
Hi Sudeep,
On Tue, May 29, 2018 at 3:18 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>>> <catalin.marinas@arm.com> wrote:
>>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>>> Jeremy Linton (12):
>>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>>
>>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
>>>>> can add it separately).
>>>>
>>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>>> CPU:
>>>>
>>>> $ echo mem > /sys/power/state
>>>> PM: suspend entry (deep)
>>>> PM: Syncing filesystems ... done.
>>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>>> OOM killer disabled.
>>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>>> Disabling non-boot CPUs ...
>>>> CPU1: shutdown
>>>> psci: CPU1 killed.
>>>
>>> Is it OK to assume the suspend failed just after shutting down one CPU
>>> or it's failing during resume ? It depends on whether you had console
>>> disabled or not.
>>
>> I have no-console-suspend enabled.
>> It's failing during suspend, the next lines should be:
>>
>> CPU2: shutdown
>> psci: CPU2 killed.
>> ...
>
> OK, I was hoping to be something during resume as this patch has nothing
> executed during suspend. Do you see any change in topology before and
> after this patch applied. I am interested in the output of:
>
> $ grep "" /sys/devices/system/cpu/cpu*/topology/*
/sys/devices/system/cpu/cpu0/topology/core_id:0
/sys/devices/system/cpu/cpu0/topology/core_siblings:0f
/sys/devices/system/cpu/cpu0/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu0/topology/physical_package_id:0
/sys/devices/system/cpu/cpu0/topology/thread_siblings:01
/sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0
/sys/devices/system/cpu/cpu1/topology/core_id:1
/sys/devices/system/cpu/cpu1/topology/core_siblings:0f
/sys/devices/system/cpu/cpu1/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu1/topology/physical_package_id:0
/sys/devices/system/cpu/cpu1/topology/thread_siblings:02
/sys/devices/system/cpu/cpu1/topology/thread_siblings_list:1
/sys/devices/system/cpu/cpu2/topology/core_id:2
/sys/devices/system/cpu/cpu2/topology/core_siblings:0f
/sys/devices/system/cpu/cpu2/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu2/topology/physical_package_id:0
/sys/devices/system/cpu/cpu2/topology/thread_siblings:04
/sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2
/sys/devices/system/cpu/cpu3/topology/core_id:3
/sys/devices/system/cpu/cpu3/topology/core_siblings:0f
/sys/devices/system/cpu/cpu3/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu3/topology/physical_package_id:0
/sys/devices/system/cpu/cpu3/topology/thread_siblings:08
/sys/devices/system/cpu/cpu3/topology/thread_siblings_list:3
/sys/devices/system/cpu/cpu4/topology/core_id:0
/sys/devices/system/cpu/cpu4/topology/core_siblings:f0
/sys/devices/system/cpu/cpu4/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu4/topology/physical_package_id:1
/sys/devices/system/cpu/cpu4/topology/thread_siblings:10
/sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
/sys/devices/system/cpu/cpu5/topology/core_id:1
/sys/devices/system/cpu/cpu5/topology/core_siblings:f0
/sys/devices/system/cpu/cpu5/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu5/topology/physical_package_id:1
/sys/devices/system/cpu/cpu5/topology/thread_siblings:20
/sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
/sys/devices/system/cpu/cpu6/topology/core_id:2
/sys/devices/system/cpu/cpu6/topology/core_siblings:f0
/sys/devices/system/cpu/cpu6/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu6/topology/physical_package_id:1
/sys/devices/system/cpu/cpu6/topology/thread_siblings:40
/sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
/sys/devices/system/cpu/cpu7/topology/core_id:3
/sys/devices/system/cpu/cpu7/topology/core_siblings:f0
/sys/devices/system/cpu/cpu7/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu7/topology/physical_package_id:1
/sys/devices/system/cpu/cpu7/topology/thread_siblings:80
/sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
No change before/after (both match my view of the hardware).
>
>>>> For me, it fails on the following big.LITTLE systems:
>>>>
>>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>>
>>>
>>> Interesting, is it PSCI based system suspend ?
>>
>> Yes it is.
>
> From DT, I guess this platform doesn't have any idle states.
> Does this use genpd power domains ? I see power-domains in the DT, so
> asking to get more info. Do you have any out of tree patches especially
> if they are depending on some topology cpumasks ?
No out-of-tree patches.
I'm testing plain 37c3ec2d810f87ea vs. 37c3ec2d810f87ea^.
There are power-domains in DT, but they're not managed by the new
fancy CPU power domain code.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 15:50 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 15:50 UTC (permalink / raw)
To: linux-arm-kernel
Hi Sudeep,
On Tue, May 29, 2018 at 3:18 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>>> <catalin.marinas@arm.com> wrote:
>>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>>> Jeremy Linton (12):
>>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>>
>>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
>>>>> can add it separately).
>>>>
>>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>>> CPU:
>>>>
>>>> $ echo mem > /sys/power/state
>>>> PM: suspend entry (deep)
>>>> PM: Syncing filesystems ... done.
>>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>>> OOM killer disabled.
>>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>>> Disabling non-boot CPUs ...
>>>> CPU1: shutdown
>>>> psci: CPU1 killed.
>>>
>>> Is it OK to assume the suspend failed just after shutting down one CPU
>>> or it's failing during resume ? It depends on whether you had console
>>> disabled or not.
>>
>> I have no-console-suspend enabled.
>> It's failing during suspend, the next lines should be:
>>
>> CPU2: shutdown
>> psci: CPU2 killed.
>> ...
>
> OK, I was hoping to be something during resume as this patch has nothing
> executed during suspend. Do you see any change in topology before and
> after this patch applied. I am interested in the output of:
>
> $ grep "" /sys/devices/system/cpu/cpu*/topology/*
/sys/devices/system/cpu/cpu0/topology/core_id:0
/sys/devices/system/cpu/cpu0/topology/core_siblings:0f
/sys/devices/system/cpu/cpu0/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu0/topology/physical_package_id:0
/sys/devices/system/cpu/cpu0/topology/thread_siblings:01
/sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0
/sys/devices/system/cpu/cpu1/topology/core_id:1
/sys/devices/system/cpu/cpu1/topology/core_siblings:0f
/sys/devices/system/cpu/cpu1/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu1/topology/physical_package_id:0
/sys/devices/system/cpu/cpu1/topology/thread_siblings:02
/sys/devices/system/cpu/cpu1/topology/thread_siblings_list:1
/sys/devices/system/cpu/cpu2/topology/core_id:2
/sys/devices/system/cpu/cpu2/topology/core_siblings:0f
/sys/devices/system/cpu/cpu2/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu2/topology/physical_package_id:0
/sys/devices/system/cpu/cpu2/topology/thread_siblings:04
/sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2
/sys/devices/system/cpu/cpu3/topology/core_id:3
/sys/devices/system/cpu/cpu3/topology/core_siblings:0f
/sys/devices/system/cpu/cpu3/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu3/topology/physical_package_id:0
/sys/devices/system/cpu/cpu3/topology/thread_siblings:08
/sys/devices/system/cpu/cpu3/topology/thread_siblings_list:3
/sys/devices/system/cpu/cpu4/topology/core_id:0
/sys/devices/system/cpu/cpu4/topology/core_siblings:f0
/sys/devices/system/cpu/cpu4/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu4/topology/physical_package_id:1
/sys/devices/system/cpu/cpu4/topology/thread_siblings:10
/sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
/sys/devices/system/cpu/cpu5/topology/core_id:1
/sys/devices/system/cpu/cpu5/topology/core_siblings:f0
/sys/devices/system/cpu/cpu5/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu5/topology/physical_package_id:1
/sys/devices/system/cpu/cpu5/topology/thread_siblings:20
/sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
/sys/devices/system/cpu/cpu6/topology/core_id:2
/sys/devices/system/cpu/cpu6/topology/core_siblings:f0
/sys/devices/system/cpu/cpu6/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu6/topology/physical_package_id:1
/sys/devices/system/cpu/cpu6/topology/thread_siblings:40
/sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
/sys/devices/system/cpu/cpu7/topology/core_id:3
/sys/devices/system/cpu/cpu7/topology/core_siblings:f0
/sys/devices/system/cpu/cpu7/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu7/topology/physical_package_id:1
/sys/devices/system/cpu/cpu7/topology/thread_siblings:80
/sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
No change before/after (both match my view of the hardware).
>
>>>> For me, it fails on the following big.LITTLE systems:
>>>>
>>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>>
>>>
>>> Interesting, is it PSCI based system suspend ?
>>
>> Yes it is.
>
> From DT, I guess this platform doesn't have any idle states.
> Does this use genpd power domains ? I see power-domains in the DT, so
> asking to get more info. Do you have any out of tree patches especially
> if they are depending on some topology cpumasks ?
No out-of-tree patches.
I'm testing plain 37c3ec2d810f87ea vs. 37c3ec2d810f87ea^.
There are power-domains in DT, but they're not managed by the new
fancy CPU power domain code.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 15:50 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 15:50 UTC (permalink / raw)
To: linux-riscv
Hi Sudeep,
On Tue, May 29, 2018 at 3:18 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>>> <catalin.marinas@arm.com> wrote:
>>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>>> Jeremy Linton (12):
>>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>>
>>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
>>>>> can add it separately).
>>>>
>>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>>> CPU:
>>>>
>>>> $ echo mem > /sys/power/state
>>>> PM: suspend entry (deep)
>>>> PM: Syncing filesystems ... done.
>>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>>> OOM killer disabled.
>>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>>> Disabling non-boot CPUs ...
>>>> CPU1: shutdown
>>>> psci: CPU1 killed.
>>>
>>> Is it OK to assume the suspend failed just after shutting down one CPU
>>> or it's failing during resume ? It depends on whether you had console
>>> disabled or not.
>>
>> I have no-console-suspend enabled.
>> It's failing during suspend, the next lines should be:
>>
>> CPU2: shutdown
>> psci: CPU2 killed.
>> ...
>
> OK, I was hoping to be something during resume as this patch has nothing
> executed during suspend. Do you see any change in topology before and
> after this patch applied. I am interested in the output of:
>
> $ grep "" /sys/devices/system/cpu/cpu*/topology/*
/sys/devices/system/cpu/cpu0/topology/core_id:0
/sys/devices/system/cpu/cpu0/topology/core_siblings:0f
/sys/devices/system/cpu/cpu0/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu0/topology/physical_package_id:0
/sys/devices/system/cpu/cpu0/topology/thread_siblings:01
/sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0
/sys/devices/system/cpu/cpu1/topology/core_id:1
/sys/devices/system/cpu/cpu1/topology/core_siblings:0f
/sys/devices/system/cpu/cpu1/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu1/topology/physical_package_id:0
/sys/devices/system/cpu/cpu1/topology/thread_siblings:02
/sys/devices/system/cpu/cpu1/topology/thread_siblings_list:1
/sys/devices/system/cpu/cpu2/topology/core_id:2
/sys/devices/system/cpu/cpu2/topology/core_siblings:0f
/sys/devices/system/cpu/cpu2/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu2/topology/physical_package_id:0
/sys/devices/system/cpu/cpu2/topology/thread_siblings:04
/sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2
/sys/devices/system/cpu/cpu3/topology/core_id:3
/sys/devices/system/cpu/cpu3/topology/core_siblings:0f
/sys/devices/system/cpu/cpu3/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu3/topology/physical_package_id:0
/sys/devices/system/cpu/cpu3/topology/thread_siblings:08
/sys/devices/system/cpu/cpu3/topology/thread_siblings_list:3
/sys/devices/system/cpu/cpu4/topology/core_id:0
/sys/devices/system/cpu/cpu4/topology/core_siblings:f0
/sys/devices/system/cpu/cpu4/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu4/topology/physical_package_id:1
/sys/devices/system/cpu/cpu4/topology/thread_siblings:10
/sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
/sys/devices/system/cpu/cpu5/topology/core_id:1
/sys/devices/system/cpu/cpu5/topology/core_siblings:f0
/sys/devices/system/cpu/cpu5/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu5/topology/physical_package_id:1
/sys/devices/system/cpu/cpu5/topology/thread_siblings:20
/sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
/sys/devices/system/cpu/cpu6/topology/core_id:2
/sys/devices/system/cpu/cpu6/topology/core_siblings:f0
/sys/devices/system/cpu/cpu6/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu6/topology/physical_package_id:1
/sys/devices/system/cpu/cpu6/topology/thread_siblings:40
/sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
/sys/devices/system/cpu/cpu7/topology/core_id:3
/sys/devices/system/cpu/cpu7/topology/core_siblings:f0
/sys/devices/system/cpu/cpu7/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu7/topology/physical_package_id:1
/sys/devices/system/cpu/cpu7/topology/thread_siblings:80
/sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
No change before/after (both match my view of the hardware).
>
>>>> For me, it fails on the following big.LITTLE systems:
>>>>
>>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>>
>>>
>>> Interesting, is it PSCI based system suspend ?
>>
>> Yes it is.
>
> From DT, I guess this platform doesn't have any idle states.
> Does this use genpd power domains ? I see power-domains in the DT, so
> asking to get more info. Do you have any out of tree patches especially
> if they are depending on some topology cpumasks ?
No out-of-tree patches.
I'm testing plain 37c3ec2d810f87ea vs. 37c3ec2d810f87ea^.
There are power-domains in DT, but they're not managed by the new
fancy CPU power domain code.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-29 15:50 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-05-29 15:50 UTC (permalink / raw)
To: Sudeep Holla
Cc: Catalin Marinas, Jeremy Linton, ACPI Devel Maling List,
Mark Rutland, austinwc, tnowicki, Palmer Dabbelt, Will Deacon,
linux-riscv, Morten.Rasmussen, vkilari, Lorenzo Pieralisi, jhugo,
Al Stone, Len Brown, John Garry, wangxiongfeng2,
Dietmar Eggemann, Linux ARM, Ard Biesheuvel, Greg KH,
Rafael J. Wysocki, Linux Kernel Mailing List, Hanjun Guo,
Linux-Renesas
Hi Sudeep,
On Tue, May 29, 2018 at 3:18 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 29/05/18 12:56, Geert Uytterhoeven wrote:
>> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
>>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
>>>> <catalin.marinas@arm.com> wrote:
>>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
>>>>>> Jeremy Linton (12):
>>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
>>>>>
>>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
>>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
>>>>> can add it separately).
>>>>
>>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
>>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
>>>> system suspend on big.LITTLE systems to hang after shutting down the first
>>>> CPU:
>>>>
>>>> $ echo mem > /sys/power/state
>>>> PM: suspend entry (deep)
>>>> PM: Syncing filesystems ... done.
>>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
>>>> OOM killer disabled.
>>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
>>>> Disabling non-boot CPUs ...
>>>> CPU1: shutdown
>>>> psci: CPU1 killed.
>>>
>>> Is it OK to assume the suspend failed just after shutting down one CPU
>>> or it's failing during resume ? It depends on whether you had console
>>> disabled or not.
>>
>> I have no-console-suspend enabled.
>> It's failing during suspend, the next lines should be:
>>
>> CPU2: shutdown
>> psci: CPU2 killed.
>> ...
>
> OK, I was hoping to be something during resume as this patch has nothing
> executed during suspend. Do you see any change in topology before and
> after this patch applied. I am interested in the output of:
>
> $ grep "" /sys/devices/system/cpu/cpu*/topology/*
/sys/devices/system/cpu/cpu0/topology/core_id:0
/sys/devices/system/cpu/cpu0/topology/core_siblings:0f
/sys/devices/system/cpu/cpu0/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu0/topology/physical_package_id:0
/sys/devices/system/cpu/cpu0/topology/thread_siblings:01
/sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0
/sys/devices/system/cpu/cpu1/topology/core_id:1
/sys/devices/system/cpu/cpu1/topology/core_siblings:0f
/sys/devices/system/cpu/cpu1/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu1/topology/physical_package_id:0
/sys/devices/system/cpu/cpu1/topology/thread_siblings:02
/sys/devices/system/cpu/cpu1/topology/thread_siblings_list:1
/sys/devices/system/cpu/cpu2/topology/core_id:2
/sys/devices/system/cpu/cpu2/topology/core_siblings:0f
/sys/devices/system/cpu/cpu2/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu2/topology/physical_package_id:0
/sys/devices/system/cpu/cpu2/topology/thread_siblings:04
/sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2
/sys/devices/system/cpu/cpu3/topology/core_id:3
/sys/devices/system/cpu/cpu3/topology/core_siblings:0f
/sys/devices/system/cpu/cpu3/topology/core_siblings_list:0-3
/sys/devices/system/cpu/cpu3/topology/physical_package_id:0
/sys/devices/system/cpu/cpu3/topology/thread_siblings:08
/sys/devices/system/cpu/cpu3/topology/thread_siblings_list:3
/sys/devices/system/cpu/cpu4/topology/core_id:0
/sys/devices/system/cpu/cpu4/topology/core_siblings:f0
/sys/devices/system/cpu/cpu4/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu4/topology/physical_package_id:1
/sys/devices/system/cpu/cpu4/topology/thread_siblings:10
/sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
/sys/devices/system/cpu/cpu5/topology/core_id:1
/sys/devices/system/cpu/cpu5/topology/core_siblings:f0
/sys/devices/system/cpu/cpu5/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu5/topology/physical_package_id:1
/sys/devices/system/cpu/cpu5/topology/thread_siblings:20
/sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
/sys/devices/system/cpu/cpu6/topology/core_id:2
/sys/devices/system/cpu/cpu6/topology/core_siblings:f0
/sys/devices/system/cpu/cpu6/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu6/topology/physical_package_id:1
/sys/devices/system/cpu/cpu6/topology/thread_siblings:40
/sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
/sys/devices/system/cpu/cpu7/topology/core_id:3
/sys/devices/system/cpu/cpu7/topology/core_siblings:f0
/sys/devices/system/cpu/cpu7/topology/core_siblings_list:4-7
/sys/devices/system/cpu/cpu7/topology/physical_package_id:1
/sys/devices/system/cpu/cpu7/topology/thread_siblings:80
/sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
No change before/after (both match my view of the hardware).
>
>>>> For me, it fails on the following big.LITTLE systems:
>>>>
>>>> R-Car H3 ES2.0 (4xCA57 + 4xCA53)
>>>> R-Car M3-W (2xCA57 + 4xCA53)
>>>>
>>>
>>> Interesting, is it PSCI based system suspend ?
>>
>> Yes it is.
>
> From DT, I guess this platform doesn't have any idle states.
> Does this use genpd power domains ? I see power-domains in the DT, so
> asking to get more info. Do you have any out of tree patches especially
> if they are depending on some topology cpumasks ?
No out-of-tree patches.
I'm testing plain 37c3ec2d810f87ea vs. 37c3ec2d810f87ea^.
There are power-domains in DT, but they're not managed by the new
fancy CPU power domain code.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-29 15:50 ` Geert Uytterhoeven
(?)
(?)
@ 2018-05-30 8:52 ` Morten Rasmussen
-1 siblings, 0 replies; 185+ messages in thread
From: Morten Rasmussen @ 2018-05-30 8:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sudeep Holla, Catalin Marinas, Jeremy Linton,
ACPI Devel Maling List, Mark Rutland, austinwc, tnowicki,
Palmer Dabbelt, Will Deacon, linux-riscv, vkilari,
Lorenzo Pieralisi, jhugo, Al Stone, Len Brown, John Garry,
wangxiongfeng2, Dietmar Eggemann, Linux ARM, Ard Biesheuvel,
Greg KH, Rafael
On Tue, May 29, 2018 at 05:50:47PM +0200, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Tue, May 29, 2018 at 3:18 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > On 29/05/18 12:56, Geert Uytterhoeven wrote:
> >> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
> >>>> <catalin.marinas@arm.com> wrote:
> >>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
> >>>>>> Jeremy Linton (12):
> >>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
> >>>>>
> >>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
> >>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
> >>>>> can add it separately).
> >>>>
> >>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
> >>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
> >>>> system suspend on big.LITTLE systems to hang after shutting down the first
> >>>> CPU:
> >>>>
> >>>> $ echo mem > /sys/power/state
> >>>> PM: suspend entry (deep)
> >>>> PM: Syncing filesystems ... done.
> >>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
> >>>> OOM killer disabled.
> >>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> >>>> Disabling non-boot CPUs ...
> >>>> CPU1: shutdown
> >>>> psci: CPU1 killed.
> >>>
> >>> Is it OK to assume the suspend failed just after shutting down one CPU
> >>> or it's failing during resume ? It depends on whether you had console
> >>> disabled or not.
> >>
> >> I have no-console-suspend enabled.
> >> It's failing during suspend, the next lines should be:
> >>
> >> CPU2: shutdown
> >> psci: CPU2 killed.
> >> ...
> >
> > OK, I was hoping to be something during resume as this patch has nothing
> > executed during suspend. Do you see any change in topology before and
> > after this patch applied. I am interested in the output of:
> >
> > $ grep "" /sys/devices/system/cpu/cpu*/topology/*
>
> /sys/devices/system/cpu/cpu0/topology/core_id:0
> /sys/devices/system/cpu/cpu0/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu0/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu0/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu0/topology/thread_siblings:01
> /sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0
> /sys/devices/system/cpu/cpu1/topology/core_id:1
> /sys/devices/system/cpu/cpu1/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu1/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu1/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu1/topology/thread_siblings:02
> /sys/devices/system/cpu/cpu1/topology/thread_siblings_list:1
> /sys/devices/system/cpu/cpu2/topology/core_id:2
> /sys/devices/system/cpu/cpu2/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu2/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu2/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu2/topology/thread_siblings:04
> /sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2
> /sys/devices/system/cpu/cpu3/topology/core_id:3
> /sys/devices/system/cpu/cpu3/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu3/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu3/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu3/topology/thread_siblings:08
> /sys/devices/system/cpu/cpu3/topology/thread_siblings_list:3
> /sys/devices/system/cpu/cpu4/topology/core_id:0
> /sys/devices/system/cpu/cpu4/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu4/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu4/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu4/topology/thread_siblings:10
> /sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
> /sys/devices/system/cpu/cpu5/topology/core_id:1
> /sys/devices/system/cpu/cpu5/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu5/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu5/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu5/topology/thread_siblings:20
> /sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
> /sys/devices/system/cpu/cpu6/topology/core_id:2
> /sys/devices/system/cpu/cpu6/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu6/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu6/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu6/topology/thread_siblings:40
> /sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
> /sys/devices/system/cpu/cpu7/topology/core_id:3
> /sys/devices/system/cpu/cpu7/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu7/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu7/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu7/topology/thread_siblings:80
> /sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
>
> No change before/after (both match my view of the hardware).
There shouldn't be any change in the reported topology with this patch
as that the topology_* functions are not touched by the patch.
The patch should only affect the topology used by the scheduler which
isn't necessarily the same as the user-space visible one.
Morten
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-30 8:52 ` Morten Rasmussen
0 siblings, 0 replies; 185+ messages in thread
From: Morten Rasmussen @ 2018-05-30 8:52 UTC (permalink / raw)
To: linux-arm-kernel
On Tue, May 29, 2018 at 05:50:47PM +0200, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Tue, May 29, 2018 at 3:18 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > On 29/05/18 12:56, Geert Uytterhoeven wrote:
> >> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
> >>>> <catalin.marinas@arm.com> wrote:
> >>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
> >>>>>> Jeremy Linton (12):
> >>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
> >>>>>
> >>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
> >>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
> >>>>> can add it separately).
> >>>>
> >>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
> >>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
> >>>> system suspend on big.LITTLE systems to hang after shutting down the first
> >>>> CPU:
> >>>>
> >>>> $ echo mem > /sys/power/state
> >>>> PM: suspend entry (deep)
> >>>> PM: Syncing filesystems ... done.
> >>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
> >>>> OOM killer disabled.
> >>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> >>>> Disabling non-boot CPUs ...
> >>>> CPU1: shutdown
> >>>> psci: CPU1 killed.
> >>>
> >>> Is it OK to assume the suspend failed just after shutting down one CPU
> >>> or it's failing during resume ? It depends on whether you had console
> >>> disabled or not.
> >>
> >> I have no-console-suspend enabled.
> >> It's failing during suspend, the next lines should be:
> >>
> >> CPU2: shutdown
> >> psci: CPU2 killed.
> >> ...
> >
> > OK, I was hoping to be something during resume as this patch has nothing
> > executed during suspend. Do you see any change in topology before and
> > after this patch applied. I am interested in the output of:
> >
> > $ grep "" /sys/devices/system/cpu/cpu*/topology/*
>
> /sys/devices/system/cpu/cpu0/topology/core_id:0
> /sys/devices/system/cpu/cpu0/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu0/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu0/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu0/topology/thread_siblings:01
> /sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0
> /sys/devices/system/cpu/cpu1/topology/core_id:1
> /sys/devices/system/cpu/cpu1/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu1/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu1/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu1/topology/thread_siblings:02
> /sys/devices/system/cpu/cpu1/topology/thread_siblings_list:1
> /sys/devices/system/cpu/cpu2/topology/core_id:2
> /sys/devices/system/cpu/cpu2/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu2/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu2/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu2/topology/thread_siblings:04
> /sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2
> /sys/devices/system/cpu/cpu3/topology/core_id:3
> /sys/devices/system/cpu/cpu3/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu3/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu3/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu3/topology/thread_siblings:08
> /sys/devices/system/cpu/cpu3/topology/thread_siblings_list:3
> /sys/devices/system/cpu/cpu4/topology/core_id:0
> /sys/devices/system/cpu/cpu4/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu4/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu4/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu4/topology/thread_siblings:10
> /sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
> /sys/devices/system/cpu/cpu5/topology/core_id:1
> /sys/devices/system/cpu/cpu5/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu5/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu5/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu5/topology/thread_siblings:20
> /sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
> /sys/devices/system/cpu/cpu6/topology/core_id:2
> /sys/devices/system/cpu/cpu6/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu6/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu6/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu6/topology/thread_siblings:40
> /sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
> /sys/devices/system/cpu/cpu7/topology/core_id:3
> /sys/devices/system/cpu/cpu7/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu7/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu7/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu7/topology/thread_siblings:80
> /sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
>
> No change before/after (both match my view of the hardware).
There shouldn't be any change in the reported topology with this patch
as that the topology_* functions are not touched by the patch.
The patch should only affect the topology used by the scheduler which
isn't necessarily the same as the user-space visible one.
Morten
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-30 8:52 ` Morten Rasmussen
0 siblings, 0 replies; 185+ messages in thread
From: Morten Rasmussen @ 2018-05-30 8:52 UTC (permalink / raw)
To: linux-riscv
On Tue, May 29, 2018 at 05:50:47PM +0200, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Tue, May 29, 2018 at 3:18 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > On 29/05/18 12:56, Geert Uytterhoeven wrote:
> >> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
> >>>> <catalin.marinas@arm.com> wrote:
> >>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
> >>>>>> Jeremy Linton (12):
> >>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
> >>>>>
> >>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
> >>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
> >>>>> can add it separately).
> >>>>
> >>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
> >>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
> >>>> system suspend on big.LITTLE systems to hang after shutting down the first
> >>>> CPU:
> >>>>
> >>>> $ echo mem > /sys/power/state
> >>>> PM: suspend entry (deep)
> >>>> PM: Syncing filesystems ... done.
> >>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
> >>>> OOM killer disabled.
> >>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> >>>> Disabling non-boot CPUs ...
> >>>> CPU1: shutdown
> >>>> psci: CPU1 killed.
> >>>
> >>> Is it OK to assume the suspend failed just after shutting down one CPU
> >>> or it's failing during resume ? It depends on whether you had console
> >>> disabled or not.
> >>
> >> I have no-console-suspend enabled.
> >> It's failing during suspend, the next lines should be:
> >>
> >> CPU2: shutdown
> >> psci: CPU2 killed.
> >> ...
> >
> > OK, I was hoping to be something during resume as this patch has nothing
> > executed during suspend. Do you see any change in topology before and
> > after this patch applied. I am interested in the output of:
> >
> > $ grep "" /sys/devices/system/cpu/cpu*/topology/*
>
> /sys/devices/system/cpu/cpu0/topology/core_id:0
> /sys/devices/system/cpu/cpu0/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu0/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu0/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu0/topology/thread_siblings:01
> /sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0
> /sys/devices/system/cpu/cpu1/topology/core_id:1
> /sys/devices/system/cpu/cpu1/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu1/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu1/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu1/topology/thread_siblings:02
> /sys/devices/system/cpu/cpu1/topology/thread_siblings_list:1
> /sys/devices/system/cpu/cpu2/topology/core_id:2
> /sys/devices/system/cpu/cpu2/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu2/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu2/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu2/topology/thread_siblings:04
> /sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2
> /sys/devices/system/cpu/cpu3/topology/core_id:3
> /sys/devices/system/cpu/cpu3/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu3/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu3/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu3/topology/thread_siblings:08
> /sys/devices/system/cpu/cpu3/topology/thread_siblings_list:3
> /sys/devices/system/cpu/cpu4/topology/core_id:0
> /sys/devices/system/cpu/cpu4/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu4/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu4/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu4/topology/thread_siblings:10
> /sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
> /sys/devices/system/cpu/cpu5/topology/core_id:1
> /sys/devices/system/cpu/cpu5/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu5/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu5/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu5/topology/thread_siblings:20
> /sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
> /sys/devices/system/cpu/cpu6/topology/core_id:2
> /sys/devices/system/cpu/cpu6/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu6/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu6/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu6/topology/thread_siblings:40
> /sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
> /sys/devices/system/cpu/cpu7/topology/core_id:3
> /sys/devices/system/cpu/cpu7/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu7/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu7/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu7/topology/thread_siblings:80
> /sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
>
> No change before/after (both match my view of the hardware).
There shouldn't be any change in the reported topology with this patch
as that the topology_* functions are not touched by the patch.
The patch should only affect the topology used by the scheduler which
isn't necessarily the same as the user-space visible one.
Morten
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-05-30 8:52 ` Morten Rasmussen
0 siblings, 0 replies; 185+ messages in thread
From: Morten Rasmussen @ 2018-05-30 8:52 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sudeep Holla, Catalin Marinas, Jeremy Linton,
ACPI Devel Maling List, Mark Rutland, austinwc, tnowicki,
Palmer Dabbelt, Will Deacon, linux-riscv, vkilari,
Lorenzo Pieralisi, jhugo, Al Stone, Len Brown, John Garry,
wangxiongfeng2, Dietmar Eggemann, Linux ARM, Ard Biesheuvel,
Greg KH, Rafael J. Wysocki, Linux Kernel Mailing List,
Hanjun Guo, Linux-Renesas
On Tue, May 29, 2018 at 05:50:47PM +0200, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Tue, May 29, 2018 at 3:18 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> > On 29/05/18 12:56, Geert Uytterhoeven wrote:
> >> On Tue, May 29, 2018 at 1:14 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> >>> On 29/05/18 11:48, Geert Uytterhoeven wrote:
> >>>> On Thu, May 17, 2018 at 7:05 PM, Catalin Marinas
> >>>> <catalin.marinas@arm.com> wrote:
> >>>>> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
> >>>>>> Jeremy Linton (12):
> >>>>>> arm64: topology: divorce MC scheduling domain from core_siblings
> >>>>>
> >>>>> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
> >>>>> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
> >>>>> can add it separately).
> >>>>
> >>>> This is now commit 37c3ec2d810f87ea ("arm64: topology: divorce MC
> >>>> scheduling domain from core_siblings") in arm64/for-next/core, causing
> >>>> system suspend on big.LITTLE systems to hang after shutting down the first
> >>>> CPU:
> >>>>
> >>>> $ echo mem > /sys/power/state
> >>>> PM: suspend entry (deep)
> >>>> PM: Syncing filesystems ... done.
> >>>> Freezing user space processes ... (elapsed 0.001 seconds) done.
> >>>> OOM killer disabled.
> >>>> Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
> >>>> Disabling non-boot CPUs ...
> >>>> CPU1: shutdown
> >>>> psci: CPU1 killed.
> >>>
> >>> Is it OK to assume the suspend failed just after shutting down one CPU
> >>> or it's failing during resume ? It depends on whether you had console
> >>> disabled or not.
> >>
> >> I have no-console-suspend enabled.
> >> It's failing during suspend, the next lines should be:
> >>
> >> CPU2: shutdown
> >> psci: CPU2 killed.
> >> ...
> >
> > OK, I was hoping to be something during resume as this patch has nothing
> > executed during suspend. Do you see any change in topology before and
> > after this patch applied. I am interested in the output of:
> >
> > $ grep "" /sys/devices/system/cpu/cpu*/topology/*
>
> /sys/devices/system/cpu/cpu0/topology/core_id:0
> /sys/devices/system/cpu/cpu0/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu0/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu0/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu0/topology/thread_siblings:01
> /sys/devices/system/cpu/cpu0/topology/thread_siblings_list:0
> /sys/devices/system/cpu/cpu1/topology/core_id:1
> /sys/devices/system/cpu/cpu1/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu1/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu1/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu1/topology/thread_siblings:02
> /sys/devices/system/cpu/cpu1/topology/thread_siblings_list:1
> /sys/devices/system/cpu/cpu2/topology/core_id:2
> /sys/devices/system/cpu/cpu2/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu2/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu2/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu2/topology/thread_siblings:04
> /sys/devices/system/cpu/cpu2/topology/thread_siblings_list:2
> /sys/devices/system/cpu/cpu3/topology/core_id:3
> /sys/devices/system/cpu/cpu3/topology/core_siblings:0f
> /sys/devices/system/cpu/cpu3/topology/core_siblings_list:0-3
> /sys/devices/system/cpu/cpu3/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu3/topology/thread_siblings:08
> /sys/devices/system/cpu/cpu3/topology/thread_siblings_list:3
> /sys/devices/system/cpu/cpu4/topology/core_id:0
> /sys/devices/system/cpu/cpu4/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu4/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu4/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu4/topology/thread_siblings:10
> /sys/devices/system/cpu/cpu4/topology/thread_siblings_list:4
> /sys/devices/system/cpu/cpu5/topology/core_id:1
> /sys/devices/system/cpu/cpu5/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu5/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu5/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu5/topology/thread_siblings:20
> /sys/devices/system/cpu/cpu5/topology/thread_siblings_list:5
> /sys/devices/system/cpu/cpu6/topology/core_id:2
> /sys/devices/system/cpu/cpu6/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu6/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu6/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu6/topology/thread_siblings:40
> /sys/devices/system/cpu/cpu6/topology/thread_siblings_list:6
> /sys/devices/system/cpu/cpu7/topology/core_id:3
> /sys/devices/system/cpu/cpu7/topology/core_siblings:f0
> /sys/devices/system/cpu/cpu7/topology/core_siblings_list:4-7
> /sys/devices/system/cpu/cpu7/topology/physical_package_id:1
> /sys/devices/system/cpu/cpu7/topology/thread_siblings:80
> /sys/devices/system/cpu/cpu7/topology/thread_siblings_list:7
>
> No change before/after (both match my view of the hardware).
There shouldn't be any change in the reported topology with this patch
as that the topology_* functions are not touched by the patch.
The patch should only affect the topology used by the scheduler which
isn't necessarily the same as the user-space visible one.
Morten
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 1/3] Revert "arm64: topology: divorce MC scheduling domain from core_siblings"
2018-05-29 10:48 ` Geert Uytterhoeven
@ 2018-06-05 13:55 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-06-05 13:55 UTC (permalink / raw)
To: linux-acpi, Rafael J . Wysocki, Catalin Marinas, Jeremy Linton
Cc: Sudeep Holla, linux-arm-kernel, linux-kernel, Hanjun Guo,
Geert Uytterhoeven, Will Deacon
This reverts commit 37c3ec2d810f87eac73822f76b30391a83bded19.
Currently on ARM64 platforms, we don't update the CPU topology masks
on each hotplug operation. However, the updates to cpu_coregroup_mask
done as part of ACPI PPTT support, in particular the commit being
reverted makes use of cpumask_of_node which returns the cpu_oneline_mask
instead of core_sibling as core_sibling masks are not updated for CPU
hotplug operations and the comparision to find NUMA in package or LLC
siblings fails.
The original commit is technically correct and since it depends on the
not yet supported feature, let's revert this for now. We can put it back
once we have the support for CPU topology masks update on hotplug merged.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/include/asm/topology.h | 2 --
arch/arm64/kernel/topology.c | 36 +-----------------------------------
2 files changed, 1 insertion(+), 37 deletions(-)
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index df48212f767b..6b10459e6905 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -8,10 +8,8 @@ struct cpu_topology {
int thread_id;
int core_id;
int package_id;
- int llc_id;
cpumask_t thread_sibling;
cpumask_t core_sibling;
- cpumask_t llc_siblings;
};
extern struct cpu_topology cpu_topology[NR_CPUS];
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7415c166281f..047d98e68502 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -13,7 +13,6 @@
#include <linux/acpi.h>
#include <linux/arch_topology.h>
-#include <linux/cacheinfo.h>
#include <linux/cpu.h>
#include <linux/cpumask.h>
#include <linux/init.h>
@@ -215,19 +214,7 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
-
- /* Find the smaller of NUMA, core or LLC siblings */
- if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
- /* not numa in package, lets use the package siblings */
- core_mask = &cpu_topology[cpu].core_sibling;
- }
- if (cpu_topology[cpu].llc_id != -1) {
- if (cpumask_subset(&cpu_topology[cpu].llc_siblings, core_mask))
- core_mask = &cpu_topology[cpu].llc_siblings;
- }
-
- return core_mask;
+ return &cpu_topology[cpu].core_sibling;
}
static void update_siblings_masks(unsigned int cpuid)
@@ -239,9 +226,6 @@ static void update_siblings_masks(unsigned int cpuid)
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
- if (cpuid_topo->llc_id == cpu_topo->llc_id)
- cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
-
if (cpuid_topo->package_id != cpu_topo->package_id)
continue;
@@ -307,10 +291,6 @@ static void __init reset_cpu_topology(void)
cpu_topo->core_id = 0;
cpu_topo->package_id = -1;
- cpu_topo->llc_id = -1;
- cpumask_clear(&cpu_topo->llc_siblings);
- cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
-
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
@@ -331,8 +311,6 @@ static int __init parse_acpi_topology(void)
is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
for_each_possible_cpu(cpu) {
- int i, cache_id;
-
topology_id = find_acpi_cpu_topology(cpu, 0);
if (topology_id < 0)
return topology_id;
@@ -347,18 +325,6 @@ static int __init parse_acpi_topology(void)
}
topology_id = find_acpi_cpu_topology_package(cpu);
cpu_topology[cpu].package_id = topology_id;
-
- i = acpi_find_last_cache_level(cpu);
-
- if (i > 0) {
- /*
- * this is the only part of cpu_topology that has
- * a direct relationship with the cache topology
- */
- cache_id = find_acpi_cpu_cache_topology(cpu, i);
- if (cache_id > 0)
- cpu_topology[cpu].llc_id = cache_id;
- }
}
return 0;
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH 1/3] Revert "arm64: topology: divorce MC scheduling domain from core_siblings"
@ 2018-06-05 13:55 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-06-05 13:55 UTC (permalink / raw)
To: linux-arm-kernel
This reverts commit 37c3ec2d810f87eac73822f76b30391a83bded19.
Currently on ARM64 platforms, we don't update the CPU topology masks
on each hotplug operation. However, the updates to cpu_coregroup_mask
done as part of ACPI PPTT support, in particular the commit being
reverted makes use of cpumask_of_node which returns the cpu_oneline_mask
instead of core_sibling as core_sibling masks are not updated for CPU
hotplug operations and the comparision to find NUMA in package or LLC
siblings fails.
The original commit is technically correct and since it depends on the
not yet supported feature, let's revert this for now. We can put it back
once we have the support for CPU topology masks update on hotplug merged.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/include/asm/topology.h | 2 --
arch/arm64/kernel/topology.c | 36 +-----------------------------------
2 files changed, 1 insertion(+), 37 deletions(-)
diff --git a/arch/arm64/include/asm/topology.h b/arch/arm64/include/asm/topology.h
index df48212f767b..6b10459e6905 100644
--- a/arch/arm64/include/asm/topology.h
+++ b/arch/arm64/include/asm/topology.h
@@ -8,10 +8,8 @@ struct cpu_topology {
int thread_id;
int core_id;
int package_id;
- int llc_id;
cpumask_t thread_sibling;
cpumask_t core_sibling;
- cpumask_t llc_siblings;
};
extern struct cpu_topology cpu_topology[NR_CPUS];
diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 7415c166281f..047d98e68502 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -13,7 +13,6 @@
#include <linux/acpi.h>
#include <linux/arch_topology.h>
-#include <linux/cacheinfo.h>
#include <linux/cpu.h>
#include <linux/cpumask.h>
#include <linux/init.h>
@@ -215,19 +214,7 @@ EXPORT_SYMBOL_GPL(cpu_topology);
const struct cpumask *cpu_coregroup_mask(int cpu)
{
- const cpumask_t *core_mask = cpumask_of_node(cpu_to_node(cpu));
-
- /* Find the smaller of NUMA, core or LLC siblings */
- if (cpumask_subset(&cpu_topology[cpu].core_sibling, core_mask)) {
- /* not numa in package, lets use the package siblings */
- core_mask = &cpu_topology[cpu].core_sibling;
- }
- if (cpu_topology[cpu].llc_id != -1) {
- if (cpumask_subset(&cpu_topology[cpu].llc_siblings, core_mask))
- core_mask = &cpu_topology[cpu].llc_siblings;
- }
-
- return core_mask;
+ return &cpu_topology[cpu].core_sibling;
}
static void update_siblings_masks(unsigned int cpuid)
@@ -239,9 +226,6 @@ static void update_siblings_masks(unsigned int cpuid)
for_each_possible_cpu(cpu) {
cpu_topo = &cpu_topology[cpu];
- if (cpuid_topo->llc_id == cpu_topo->llc_id)
- cpumask_set_cpu(cpu, &cpuid_topo->llc_siblings);
-
if (cpuid_topo->package_id != cpu_topo->package_id)
continue;
@@ -307,10 +291,6 @@ static void __init reset_cpu_topology(void)
cpu_topo->core_id = 0;
cpu_topo->package_id = -1;
- cpu_topo->llc_id = -1;
- cpumask_clear(&cpu_topo->llc_siblings);
- cpumask_set_cpu(cpu, &cpu_topo->llc_siblings);
-
cpumask_clear(&cpu_topo->core_sibling);
cpumask_set_cpu(cpu, &cpu_topo->core_sibling);
cpumask_clear(&cpu_topo->thread_sibling);
@@ -331,8 +311,6 @@ static int __init parse_acpi_topology(void)
is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
for_each_possible_cpu(cpu) {
- int i, cache_id;
-
topology_id = find_acpi_cpu_topology(cpu, 0);
if (topology_id < 0)
return topology_id;
@@ -347,18 +325,6 @@ static int __init parse_acpi_topology(void)
}
topology_id = find_acpi_cpu_topology_package(cpu);
cpu_topology[cpu].package_id = topology_id;
-
- i = acpi_find_last_cache_level(cpu);
-
- if (i > 0) {
- /*
- * this is the only part of cpu_topology that has
- * a direct relationship with the cache topology
- */
- cache_id = find_acpi_cpu_cache_topology(cpu, i);
- if (cache_id > 0)
- cpu_topology[cpu].llc_id = cache_id;
- }
}
return 0;
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled
2018-06-05 13:55 ` Sudeep Holla
@ 2018-06-05 13:55 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-06-05 13:55 UTC (permalink / raw)
To: linux-acpi, Rafael J . Wysocki, Catalin Marinas, Jeremy Linton
Cc: Sudeep Holla, linux-arm-kernel, linux-kernel, Hanjun Guo,
Geert Uytterhoeven
Though CONFIG_ACPI_PPTT is selected by platforms and nor user visible,
it may be useful to support the build with CONFIG_ACPI_PPTT disabled.
This patch adds the missing dummy/boiler plate implementation to fix
the build.
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
include/linux/acpi.h | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
Hi Rafael,
If you are fine with this, can you provide Ack, so that we route this
through ARM64 tree where most of the ACPI PPTT support is present.
Regards,
Sudeep
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 8f2cdb0eca71..0fa28265d095 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1299,8 +1299,28 @@ static inline int lpit_read_residency_count_address(u64 *address)
}
#endif
+#ifdef CONFIG_ACPI_PPTT
int find_acpi_cpu_topology(unsigned int cpu, int level);
int find_acpi_cpu_topology_package(unsigned int cpu);
int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
+int acpi_find_last_cache_level(unsigned int cpu);
+#else
+static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
+{
+ return -EINVAL;
+}
+static inline int find_acpi_cpu_topology_package(unsigned int cpu)
+{
+ return -EINVAL;
+}
+static inline int find_acpi_cpu_cache_topology(unsigned int cpu, int level)
+{
+ return -EINVAL;
+}
+static inline int acpi_find_last_cache_level(unsigned int cpu)
+{
+ return -EINVAL;
+}
+#endif
#endif /*_LINUX_ACPI_H*/
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread* [PATCH 2/3] ACPI / PPTT: fix build when CONFIG_ACPI_PPTT is not enabled
@ 2018-06-05 13:55 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-06-05 13:55 UTC (permalink / raw)
To: linux-arm-kernel
Though CONFIG_ACPI_PPTT is selected by platforms and nor user visible,
it may be useful to support the build with CONFIG_ACPI_PPTT disabled.
This patch adds the missing dummy/boiler plate implementation to fix
the build.
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
include/linux/acpi.h | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
Hi Rafael,
If you are fine with this, can you provide Ack, so that we route this
through ARM64 tree where most of the ACPI PPTT support is present.
Regards,
Sudeep
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 8f2cdb0eca71..0fa28265d095 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -1299,8 +1299,28 @@ static inline int lpit_read_residency_count_address(u64 *address)
}
#endif
+#ifdef CONFIG_ACPI_PPTT
int find_acpi_cpu_topology(unsigned int cpu, int level);
int find_acpi_cpu_topology_package(unsigned int cpu);
int find_acpi_cpu_cache_topology(unsigned int cpu, int level);
+int acpi_find_last_cache_level(unsigned int cpu);
+#else
+static inline int find_acpi_cpu_topology(unsigned int cpu, int level)
+{
+ return -EINVAL;
+}
+static inline int find_acpi_cpu_topology_package(unsigned int cpu)
+{
+ return -EINVAL;
+}
+static inline int find_acpi_cpu_cache_topology(unsigned int cpu, int level)
+{
+ return -EINVAL;
+}
+static inline int acpi_find_last_cache_level(unsigned int cpu)
+{
+ return -EINVAL;
+}
+#endif
#endif /*_LINUX_ACPI_H*/
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 3/3] arm64: disable ACPI PPTT support temporarily
2018-06-05 13:55 ` Sudeep Holla
@ 2018-06-05 13:55 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-06-05 13:55 UTC (permalink / raw)
To: linux-acpi, Rafael J . Wysocki, Catalin Marinas, Jeremy Linton
Cc: Sudeep Holla, linux-arm-kernel, linux-kernel, Hanjun Guo,
Geert Uytterhoeven, Will Deacon
Currently, ARM64 doesn't support updating the CPU topology masks on
CPU hotplug operations. ACPI PPTT support rely on that missing feature
which is technically not incorrect. Instead of reverting all the PPTT
support, let's keep it simple and disable ACPI PPTT support on ARM64
for time-being until the topology updates are added for CPU hotplug
operations.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9fd4a8ccce07..98a5c78a80f9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -7,7 +7,6 @@ config ARM64
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ACPI_MCFG if ACPI
select ACPI_SPCR_TABLE if ACPI
- select ACPI_PPTT if ACPI
select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread
* [PATCH 3/3] arm64: disable ACPI PPTT support temporarily
@ 2018-06-05 13:55 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-06-05 13:55 UTC (permalink / raw)
To: linux-arm-kernel
Currently, ARM64 doesn't support updating the CPU topology masks on
CPU hotplug operations. ACPI PPTT support rely on that missing feature
which is technically not incorrect. Instead of reverting all the PPTT
support, let's keep it simple and disable ACPI PPTT support on ARM64
for time-being until the topology updates are added for CPU hotplug
operations.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9fd4a8ccce07..98a5c78a80f9 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -7,7 +7,6 @@ config ARM64
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
select ACPI_MCFG if ACPI
select ACPI_SPCR_TABLE if ACPI
- select ACPI_PPTT if ACPI
select ARCH_CLOCKSOURCE_DATA
select ARCH_HAS_DEBUG_VIRTUAL
select ARCH_HAS_DEVMEM_IS_ALLOWED
--
2.7.4
^ permalink raw reply related [flat|nested] 185+ messages in thread
* Re: [PATCH 1/3] Revert "arm64: topology: divorce MC scheduling domain from core_siblings"
2018-06-05 13:55 ` Sudeep Holla
@ 2018-06-05 14:09 ` Geert Uytterhoeven
-1 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-06-05 14:09 UTC (permalink / raw)
To: Sudeep Holla
Cc: ACPI Devel Maling List, Rafael J . Wysocki, Catalin Marinas,
Jeremy Linton, Linux ARM, Linux Kernel Mailing List, Hanjun Guo,
Will Deacon
Hi Sudeep,
On Tue, Jun 5, 2018 at 3:55 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> This reverts commit 37c3ec2d810f87eac73822f76b30391a83bded19.
>
> Currently on ARM64 platforms, we don't update the CPU topology masks
> on each hotplug operation. However, the updates to cpu_coregroup_mask
I would add
"leading to e.g. a system hang during system suspend."
to avoid people thinking this is purely a small bookkeeping issue without any
percussions.
> done as part of ACPI PPTT support, in particular the commit being
> reverted makes use of cpumask_of_node which returns the cpu_oneline_mask
> instead of core_sibling as core_sibling masks are not updated for CPU
> hotplug operations and the comparision to find NUMA in package or LLC
> siblings fails.
>
> The original commit is technically correct and since it depends on the
> not yet supported feature, let's revert this for now. We can put it back
> once we have the support for CPU topology masks update on hotplug merged.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* [PATCH 1/3] Revert "arm64: topology: divorce MC scheduling domain from core_siblings"
@ 2018-06-05 14:09 ` Geert Uytterhoeven
0 siblings, 0 replies; 185+ messages in thread
From: Geert Uytterhoeven @ 2018-06-05 14:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi Sudeep,
On Tue, Jun 5, 2018 at 3:55 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
> This reverts commit 37c3ec2d810f87eac73822f76b30391a83bded19.
>
> Currently on ARM64 platforms, we don't update the CPU topology masks
> on each hotplug operation. However, the updates to cpu_coregroup_mask
I would add
"leading to e.g. a system hang during system suspend."
to avoid people thinking this is purely a small bookkeeping issue without any
percussions.
> done as part of ACPI PPTT support, in particular the commit being
> reverted makes use of cpumask_of_node which returns the cpu_oneline_mask
> instead of core_sibling as core_sibling masks are not updated for CPU
> hotplug operations and the comparision to find NUMA in package or LLC
> siblings fails.
>
> The original commit is technically correct and since it depends on the
> not yet supported feature, let's revert this for now. We can put it back
> once we have the support for CPU topology masks update on hotplug merged.
>
> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 185+ messages in thread* Re: [PATCH 1/3] Revert "arm64: topology: divorce MC scheduling domain from core_siblings"
2018-06-05 14:09 ` Geert Uytterhoeven
@ 2018-06-05 14:12 ` Sudeep Holla
-1 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-06-05 14:12 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Sudeep Holla, ACPI Devel Maling List, Rafael J . Wysocki,
Catalin Marinas, Jeremy Linton, Linux ARM,
Linux Kernel Mailing List, Hanjun Guo, Will Deacon
On 05/06/18 15:09, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Tue, Jun 5, 2018 at 3:55 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> This reverts commit 37c3ec2d810f87eac73822f76b30391a83bded19.
>>
>> Currently on ARM64 platforms, we don't update the CPU topology masks
>> on each hotplug operation. However, the updates to cpu_coregroup_mask
>
> I would add
>
> "leading to e.g. a system hang during system suspend."
>
> to avoid people thinking this is purely a small bookkeeping issue without any
> percussions.
>
Sure, thanks. Sorry for missing that.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH 1/3] Revert "arm64: topology: divorce MC scheduling domain from core_siblings"
@ 2018-06-05 14:12 ` Sudeep Holla
0 siblings, 0 replies; 185+ messages in thread
From: Sudeep Holla @ 2018-06-05 14:12 UTC (permalink / raw)
To: linux-arm-kernel
On 05/06/18 15:09, Geert Uytterhoeven wrote:
> Hi Sudeep,
>
> On Tue, Jun 5, 2018 at 3:55 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>> This reverts commit 37c3ec2d810f87eac73822f76b30391a83bded19.
>>
>> Currently on ARM64 platforms, we don't update the CPU topology masks
>> on each hotplug operation. However, the updates to cpu_coregroup_mask
>
> I would add
>
> "leading to e.g. a system hang during system suspend."
>
> to avoid people thinking this is purely a small bookkeeping issue without any
> percussions.
>
Sure, thanks. Sorry for missing that.
--
Regards,
Sudeep
^ permalink raw reply [flat|nested] 185+ messages in thread
* Re: [PATCH v9 00/12] Support PPTT for ARM64
2018-05-17 17:05 ` Catalin Marinas
(?)
@ 2018-06-04 15:12 ` Catalin Marinas
-1 siblings, 0 replies; 185+ messages in thread
From: Catalin Marinas @ 2018-06-04 15:12 UTC (permalink / raw)
To: Jeremy Linton
Cc: Mark.Rutland, austinwc, tnowicki, palmer, Will.Deacon,
linux-riscv, wangxiongfeng2, vkilari, Lorenzo.Pieralisi, jhugo,
Morten.Rasmussen, linux-acpi, lenb, john.garry, ahs3,
linux-arm-kernel, ard.biesheuvel, gregkh, rjw, linux-kernel,
hanjun.guo, Sudeep.Holla, Dietmar.Eggemann
On Thu, May 17, 2018 at 06:05:24PM +0100, Catalin Marinas wrote:
> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
> > Jeremy Linton (12):
> > drivers: base: cacheinfo: move cache_setup_of_node()
> > drivers: base: cacheinfo: setup DT cache properties early
> > cacheinfo: rename of_node to fw_token
> > arm64/acpi: Create arch specific cpu to acpi id helper
> > ACPI/PPTT: Add Processor Properties Topology Table parsing
> > ACPI: Enable PPTT support on ARM64
> > drivers: base cacheinfo: Add support for ACPI based firmware tables
> > arm64: Add support for ACPI based firmware tables
> > arm64: topology: rename cluster_id
> > arm64: topology: enable ACPI/PPTT based CPU topology
> > ACPI: Add PPTT to injectable table list
> > arm64: topology: divorce MC scheduling domain from core_siblings
>
> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
> patch - http://lkml.kernel.org/r/20180517154701.GA20281@e107155-lin; I
> can add it separately).
I'm going to revert patch 12 in this series (arm64: topology: divorce MC
scheduling domain from core_siblings) until the problem is understood
and a fix proposed and tested. It's likely that the PPTT for arm64 will
only be fully enabled in 4.19.
--
Catalin
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-06-04 15:12 ` Catalin Marinas
0 siblings, 0 replies; 185+ messages in thread
From: Catalin Marinas @ 2018-06-04 15:12 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, May 17, 2018 at 06:05:24PM +0100, Catalin Marinas wrote:
> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
> > Jeremy Linton (12):
> > drivers: base: cacheinfo: move cache_setup_of_node()
> > drivers: base: cacheinfo: setup DT cache properties early
> > cacheinfo: rename of_node to fw_token
> > arm64/acpi: Create arch specific cpu to acpi id helper
> > ACPI/PPTT: Add Processor Properties Topology Table parsing
> > ACPI: Enable PPTT support on ARM64
> > drivers: base cacheinfo: Add support for ACPI based firmware tables
> > arm64: Add support for ACPI based firmware tables
> > arm64: topology: rename cluster_id
> > arm64: topology: enable ACPI/PPTT based CPU topology
> > ACPI: Add PPTT to injectable table list
> > arm64: topology: divorce MC scheduling domain from core_siblings
>
> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
> can add it separately).
I'm going to revert patch 12 in this series (arm64: topology: divorce MC
scheduling domain from core_siblings) until the problem is understood
and a fix proposed and tested. It's likely that the PPTT for arm64 will
only be fully enabled in 4.19.
--
Catalin
^ permalink raw reply [flat|nested] 185+ messages in thread
* [PATCH v9 00/12] Support PPTT for ARM64
@ 2018-06-04 15:12 ` Catalin Marinas
0 siblings, 0 replies; 185+ messages in thread
From: Catalin Marinas @ 2018-06-04 15:12 UTC (permalink / raw)
To: linux-riscv
On Thu, May 17, 2018 at 06:05:24PM +0100, Catalin Marinas wrote:
> On Fri, May 11, 2018 at 06:57:55PM -0500, Jeremy Linton wrote:
> > Jeremy Linton (12):
> > drivers: base: cacheinfo: move cache_setup_of_node()
> > drivers: base: cacheinfo: setup DT cache properties early
> > cacheinfo: rename of_node to fw_token
> > arm64/acpi: Create arch specific cpu to acpi id helper
> > ACPI/PPTT: Add Processor Properties Topology Table parsing
> > ACPI: Enable PPTT support on ARM64
> > drivers: base cacheinfo: Add support for ACPI based firmware tables
> > arm64: Add support for ACPI based firmware tables
> > arm64: topology: rename cluster_id
> > arm64: topology: enable ACPI/PPTT based CPU topology
> > ACPI: Add PPTT to injectable table list
> > arm64: topology: divorce MC scheduling domain from core_siblings
>
> Queued for 4.18 (without Sudeep's latest property_read_u64 cacheinfo
> patch - http://lkml.kernel.org/r/20180517154701.GA20281 at e107155-lin; I
> can add it separately).
I'm going to revert patch 12 in this series (arm64: topology: divorce MC
scheduling domain from core_siblings) until the problem is understood
and a fix proposed and tested. It's likely that the PPTT for arm64 will
only be fully enabled in 4.19.
--
Catalin
^ permalink raw reply [flat|nested] 185+ messages in thread