From: Rob Herring <robh@kernel.org>
To: Alireza Sanaee <alireza.sanaee@huawei.com>
Cc: devicetree@vger.kernel.org, jonathan.cameron@huawei.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linuxarm@huawei.com,
mark.rutland@arm.com, shameerali.kolothum.thodi@huawei.com,
krzk@kernel.org, dianders@chromium.org, catalin.marinas@arm.com,
suzuki.poulose@arm.com, mike.leach@linaro.org,
james.clark@linaro.org, linux-perf-users@vger.kernel.org,
coresight@lists.linaro.org, gshan@redhat.com,
ruanjinjie@huawei.com, saravanak@google.com
Subject: Re: [PATCH v3 7/7] of: of_cpu_phandle_to_id to support SMT threads
Date: Fri, 6 Jun 2025 09:18:57 -0500 [thread overview]
Message-ID: <20250606141857.GA1476878-robh@kernel.org> (raw)
In-Reply-To: <20250512080715.82-8-alireza.sanaee@huawei.com>
On Mon, May 12, 2025 at 09:07:15AM +0100, Alireza Sanaee wrote:
> Enhance the API to support SMT threads, this will allow sharing
> resources among multiple SMT threads.
>
> Enabled the sharing of resources, such as L1 Cache and clocks, between
> SMT threads. It introduces a fix that uses thread IDs to match each CPU
> thread in the register array within the cpu-node. This ensures that the
> cpu-map or any driver relying on this API is fine even when SMT threads
> share resources.
>
> Additionally, I have tested this for CPU based on the discussions in
> [1], I adopted the new cpu-map layout, where the first parameter is a
> phandle and the second is the local thread index, as shown below:
>
> core0 {
> thread0 {
> cpu = <&cpu0 0>;
> };
> thread1 {
> cpu = <&cpu0 1>;
> };
I think the thread nodes should be omitted in this case.
> };
>
> Also, there are devices such as below that are a bit different.
>
> arm_dsu@0 {
> compatible = "arm,dsu";
> cpus = <&cpu0 &cpu1 &cpu2 &cpu3>;
> }
>
> In these cases, we can also point to a CPU thread as well like the
> following:
>
> arm_dsu@0 {
> compatible = "arm,dsu";
> cpus = <&cpu0 5 &cpu1 9 &cpu2 1 &cpu3 0>;
The purpose of 'cpus' properties is to define CPU affinity. I don't
think the affinity could ever be different for threads in a core.
And cpu1 having 10 threads is nonsense.
Most cases of 'cpus' (and 'affinity') lookups and then callers of
of_cpu_node_to_id() ultimately just want to set a cpumask. So we should
provide that rather than opencoding the same loop everywhere.
> }
>
> It should be possible to know how many arguments a phandle might
> require, and this information is encoded in another variable in the dt
> called #cpu-cells in cpu node.
>
> Signed-off-by: Alireza Sanaee <alireza.sanaee@huawei.com>
>
> [1] https://lore.kernel.org/devicetree-spec/CAL_JsqK1yqRLD9B+G7UUp=D8K++mXHq0Rmv=1i6DL_jXyZwXAw@mail.gmail.com/
> ---
> drivers/of/cpu.c | 41 +++++++++++++++++++++++++++++++++--------
> 1 file changed, 33 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/of/cpu.c b/drivers/of/cpu.c
> index fba17994fc20..cf54ef47f029 100644
> --- a/drivers/of/cpu.c
> +++ b/drivers/of/cpu.c
> @@ -189,16 +189,41 @@ int of_cpu_phandle_to_id(const struct device_node *node,
> struct device_node **cpu_np,
> uint8_t cpu_idx)
> {
> + bool found = false;
> + int cpu, ret = -1, i, j;
> + uint32_t local_thread, thread_index;
> + struct device_node *np;
> + struct of_phandle_args args;
> + static const char * const phandle_names[] = { "cpus", "cpu" };
> + static const char * const cpu_cells[] = { "#cpu-cells", NULL };
> +
> if (!node)
> - return -1;
> + return ret;
>
> - *cpu_np = of_parse_phandle(node, "cpu", 0);
> - if (!*cpu_np)
> - *cpu_np = of_parse_phandle(node, "cpus", cpu_idx);
> - if (!*cpu_np)
> - return -ENODEV;
> + for (i = 0; i < ARRAY_SIZE(phandle_names); i++) {
> + for (j = 0; j < ARRAY_SIZE(cpu_cells); j++) {
> + ret = of_parse_phandle_with_args(node, phandle_names[i],
> + cpu_cells[j], cpu_idx,
> + &args);
> + if (ret >= 0)
> + goto success;
> + }
> + }
>
> - return of_cpu_node_to_id(*cpu_np);
> + if (ret < 0)
> + return ret;
> +success:
> + *cpu_np = args.np;
> + thread_index = args.args_count == 1 ? args.args[0] : 0;
> + for_each_possible_cpu(cpu) {
> + np = of_get_cpu_node(cpu, &local_thread);
> + found = (*cpu_np == np) && (local_thread == thread_index);
> + of_node_put(np);
> + if (found)
> + return cpu;
> + }
> +
> + return -ENODEV;
> }
> EXPORT_SYMBOL(of_cpu_phandle_to_id);
>
> @@ -206,7 +231,7 @@ EXPORT_SYMBOL(of_cpu_phandle_to_id);
> * of_get_cpu_state_node - Get CPU's idle state node at the given index
> *
> * @cpu_node: The device node for the CPU
> - * @index: The index in the list of the idle states
> +g* @index: The index in the list of the idle states
Oops!
> *
> * Two generic methods can be used to describe a CPU's idle states, either via
> * a flattened description through the "cpu-idle-states" binding or via the
> --
> 2.34.1
>
prev parent reply other threads:[~2025-06-06 14:21 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-12 8:07 [PATCH v3 0/7] DT: Enable sharing resources for SMT threads Alireza Sanaee
2025-05-12 8:07 ` Alireza Sanaee
2025-05-12 8:07 ` [PATCH v3 1/7] of: add infra for finding CPU id from phandle Alireza Sanaee
2025-05-12 8:07 ` Alireza Sanaee
2025-05-28 15:54 ` Jonathan Cameron
2025-05-12 8:07 ` [PATCH v3 2/7] arch_topology: update CPU map to use the new API Alireza Sanaee
2025-05-12 8:07 ` Alireza Sanaee
2025-05-12 8:07 ` [PATCH v3 3/7] coresight: cti: Use of_cpu_phandle_to_id for grabbing CPU id Alireza Sanaee
2025-05-12 8:07 ` Alireza Sanaee
2025-05-12 8:07 ` [PATCH v3 4/7] coresight: " Alireza Sanaee
2025-05-12 8:07 ` Alireza Sanaee
2025-05-12 8:07 ` [PATCH v3 5/7] perf/arm-dsu: refactor cpu id retrieval via new API of_cpu_phandle_to_id Alireza Sanaee
2025-05-12 8:07 ` Alireza Sanaee
2025-05-12 8:07 ` [PATCH v3 6/7] arm64: of: handle multiple threads in ARM cpu node Alireza Sanaee
2025-05-12 8:07 ` Alireza Sanaee
2025-05-12 8:07 ` [PATCH v3 7/7] of: of_cpu_phandle_to_id to support SMT threads Alireza Sanaee
2025-05-12 8:07 ` Alireza Sanaee
2025-06-06 14:18 ` Rob Herring [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250606141857.GA1476878-robh@kernel.org \
--to=robh@kernel.org \
--cc=alireza.sanaee@huawei.com \
--cc=catalin.marinas@arm.com \
--cc=coresight@lists.linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=dianders@chromium.org \
--cc=gshan@redhat.com \
--cc=james.clark@linaro.org \
--cc=jonathan.cameron@huawei.com \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mark.rutland@arm.com \
--cc=mike.leach@linaro.org \
--cc=ruanjinjie@huawei.com \
--cc=saravanak@google.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=suzuki.poulose@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.