From: Jeremy Linton <jeremy.linton@arm.com>
To: Yunhui Cui <cuiyunhui@bytedance.com>,
rafael@kernel.org, lenb@kernel.org, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, paul.walmsley@sifive.com,
palmer@dabbelt.com, aou@eecs.berkeley.edu,
linux-riscv@lists.infradead.org, bhelgaas@google.com,
james.morse@arm.com, jhugo@codeaurora.org, john.garry@huawei.com,
Jonathan.Cameron@huawei.com, pierre.gondois@arm.com,
sudeep.holla@arm.com, tiantao6@huawei.com
Subject: Re: [PATCH v3 2/3] riscv: cacheinfo: initialize cacheinfo's level and type from ACPI PPTT
Date: Tue, 16 Apr 2024 15:03:52 -0500 [thread overview]
Message-ID: <9f36bedd-1a68-43a9-826d-ce56caf01c52@arm.com> (raw)
In-Reply-To: <20240416031438.7637-2-cuiyunhui@bytedance.com>
Hi,
On 4/15/24 22:14, Yunhui Cui wrote:
> Before cacheinfo can be built correctly, we need to initialize level
> and type. Since RSIC-V currently does not have a register group that
> describes cache-related attributes like ARM64, we cannot obtain them
> directly, so now we obtain cache leaves from the ACPI PPTT table
> (acpi_get_cache_info()) and set the cache type through split_levels.
>
> Suggested-by: Jeremy Linton <jeremy.linton@arm.com>
> Suggested-by: Sudeep Holla <sudeep.holla@arm.com>
> Signed-off-by: Yunhui Cui <cuiyunhui@bytedance.com>
> ---
> arch/riscv/kernel/cacheinfo.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/riscv/kernel/cacheinfo.c b/arch/riscv/kernel/cacheinfo.c
> index 30a6878287ad..dc5fb70362f1 100644
> --- a/arch/riscv/kernel/cacheinfo.c
> +++ b/arch/riscv/kernel/cacheinfo.c
> @@ -6,6 +6,7 @@
> #include <linux/cpu.h>
> #include <linux/of.h>
> #include <asm/cacheinfo.h>
> +#include <linux/acpi.h>
>
> static struct riscv_cacheinfo_ops *rv_cache_ops;
>
> @@ -78,6 +79,25 @@ int populate_cache_leaves(unsigned int cpu)
> struct device_node *prev = NULL;
> int levels = 1, level = 1;
>
> + if (!acpi_disabled) {
> + int ret, idx, fw_levels, split_levels;
> +
> + ret = acpi_get_cache_info(cpu, &fw_levels, &split_levels);
> + if (ret)
> + return ret;
> +
> + for (idx = 0; level <= this_cpu_ci->num_levels &&
> + idx < this_cpu_ci->num_leaves; idx++, level++) {
AFAIK the purpose of idx here it to assure that the number of cache
leaves is not overflowing. But right below we are utilizing two of them
at once, so this check isn't correct. OTOH, since its allocated as
levels + split_levels I don't think its actually possible for this to
cause a problem. Might be worthwhile to just hoist it before the loop
and revalidate the total leaves about to be utilized.
> + if (level <= split_levels) {
> + ci_leaf_init(this_leaf++, CACHE_TYPE_DATA, level);
> + ci_leaf_init(this_leaf++, CACHE_TYPE_INST, level);
> + } else {
> + ci_leaf_init(this_leaf++, CACHE_TYPE_UNIFIED, level);
> + }
> + }
> + return 0;
> + }
> +
> if (of_property_read_bool(np, "cache-size"))
> ci_leaf_init(this_leaf++, CACHE_TYPE_UNIFIED, level);
> if (of_property_read_bool(np, "i-cache-size"))
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-04-16 20:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-16 3:14 [PATCH v3 1/3] riscv: cacheinfo: remove the useless parameter (node) of ci_leaf_init() Yunhui Cui
2024-04-16 3:14 ` [PATCH v3 2/3] riscv: cacheinfo: initialize cacheinfo's level and type from ACPI PPTT Yunhui Cui
2024-04-16 9:39 ` Sudeep Holla
2024-04-16 20:03 ` Jeremy Linton [this message]
2024-04-17 3:15 ` [External] " yunhui cui
2024-04-17 14:00 ` Jeremy Linton
2024-04-18 2:52 ` yunhui cui
2024-04-16 3:14 ` [PATCH v3 3/3] RISC-V: Select ACPI PPTT drivers Yunhui Cui
2024-04-16 19:49 ` [PATCH v3 1/3] riscv: cacheinfo: remove the useless parameter (node) of ci_leaf_init() Jeremy Linton
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=9f36bedd-1a68-43a9-826d-ce56caf01c52@arm.com \
--to=jeremy.linton@arm.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=aou@eecs.berkeley.edu \
--cc=bhelgaas@google.com \
--cc=cuiyunhui@bytedance.com \
--cc=james.morse@arm.com \
--cc=jhugo@codeaurora.org \
--cc=john.garry@huawei.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=pierre.gondois@arm.com \
--cc=rafael@kernel.org \
--cc=sudeep.holla@arm.com \
--cc=tiantao6@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox