[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250504-acoustic-skink-of-greatness-1e90ac@kuoka>
Date: Sun, 4 May 2025 19:51:02 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Alireza Sanaee <alireza.sanaee@...wei.com>
Cc: devicetree@...r.kernel.org, robh@...nel.org,
jonathan.cameron@...wei.com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linuxarm@...wei.com, mark.rutland@....com,
shameerali.kolothum.thodi@...wei.com
Subject: Re: [PATCH v2 6/6] of: of_cpu_phandle_to_id to support SMT threads
On Fri, May 02, 2025 at 05:13:00PM GMT, Alireza Sanaee wrote:
> Enhance the API to support SMT threads, this will allow sharing resources among
> multiple SMT threads.
<form letter>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC (and consider --no-git-fallback argument, so you will
not CC people just because they made one commit years ago). It might
happen, that command when run on an older kernel, gives you outdated
entries. Therefore please be sure you base your patches on recent Linux
kernel.
Tools like b4 or scripts/get_maintainer.pl provide you proper list of
people, so fix your workflow. Tools might also fail if you work on some
ancient tree (don't, instead use mainline) or work on fork of kernel
(don't, instead use mainline). Just use b4 and everything should be
fine, although remember about 'b4 prep --auto-to-cc' if you added new
patches to the patchset.
</form letter>
>
> 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:
>
> In the CPU map, there are two cases that only one occurs at at time.
> 1) "cpu" = <phandle>
> 2) "cpus" = <phandle> <index>
>
> The first case addresses non-SMTs and the second case addresses SMTs
> that the variable must be cpu(s) with an index where we later look up
> the reg array with that.
>
> core0 {
> thread0 {
> cpus = <&cpu0 0>;
Not so sure, dtschema says only one item is allowed in the phandle and I
do not see here binding change.
Although this wasn't even sent to me, so I'll just ignore your patchset.
Best regards,
Krzysztof
Powered by blists - more mailing lists