From: Chris Packham <judge.packham@gmail.com>
To: u-boot@lists.denx.de
Cc: "Chris Packham" <judge.packham@gmail.com>,
"Bin Meng" <bmeng.cn@gmail.com>, "Marc Zyngier" <maz@kernel.org>,
"Peng Fan" <peng.fan@nxp.com>,
"Pierre-Clément Tosi" <ptosi@google.com>,
"Simon Glass" <sjg@chromium.org>, "Ye Li" <ye.li@nxp.com>,
"Ying-Chun Liu (PaulLiu)" <paul.liu@linaro.org>,
meitao <meitaogao@asrmicro.com>
Subject: [PATCH 2/3] Revert "arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present"
Date: Fri, 27 Oct 2023 13:23:53 +1300 [thread overview]
Message-ID: <20231027002409.430285-3-judge.packham@gmail.com> (raw)
In-Reply-To: <20231027002409.430285-1-judge.packham@gmail.com>
This reverts commit 836b8d4b205d2175b57cb9ef271e638b0c116e89. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
---
arch/arm/cpu/armv8/cache_v8.c | 14 ++++----------
arch/arm/include/asm/global_data.h | 1 -
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 4c6a1b1d6c5e..4760064ee18f 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -314,7 +314,7 @@ static void map_range(u64 virt, u64 phys, u64 size, int level,
for (i = idx; size; i++) {
u64 next_size, *next_table;
- if (level >= gd->arch.first_block_level &&
+ if (level >= 1 &&
size >= map_size && !(virt & (map_size - 1))) {
if (level == 3)
table[i] = phys | attrs | PTE_TYPE_PAGE;
@@ -353,9 +353,6 @@ static void add_map(struct mm_region *map)
if (va_bits < 39)
level = 1;
- if (!gd->arch.first_block_level)
- gd->arch.first_block_level = 1;
-
if (gd->arch.has_hafdbs)
attrs |= PTE_DBM | PTE_RDONLY;
@@ -372,7 +369,7 @@ static void count_range(u64 virt, u64 size, int level, int *cntp)
for (i = idx; size; i++) {
u64 next_size;
- if (level >= gd->arch.first_block_level &&
+ if (level >= 1 &&
size >= map_size && !(virt & (map_size - 1))) {
virt += map_size;
size -= map_size;
@@ -413,13 +410,10 @@ __weak u64 get_page_table_size(void)
u64 size, mmfr1;
asm volatile("mrs %0, id_aa64mmfr1_el1" : "=r" (mmfr1));
- if ((mmfr1 & 0xf) == 2) {
+ if ((mmfr1 & 0xf) == 2)
gd->arch.has_hafdbs = true;
- gd->arch.first_block_level = 2;
- } else {
+ else
gd->arch.has_hafdbs = false;
- gd->arch.first_block_level = 1;
- }
/* Account for all page tables we would need to cover our memory map */
size = one_pt * count_ranges();
diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h
index b385bae02669..1325b0644248 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -52,7 +52,6 @@ struct arch_global_data {
#if defined(CONFIG_ARM64)
unsigned long tlb_fillptr;
unsigned long tlb_emerg;
- unsigned int first_block_level;
bool has_hafdbs;
#endif
#endif
--
2.42.0
next prev parent reply other threads:[~2023-10-27 0:25 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-27 0:23 [PATCH 0/3] Revert HAFDBS changes Chris Packham
2023-10-27 0:23 ` [PATCH 1/3] Revert "armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present" Chris Packham
2023-11-17 19:42 ` Tom Rini
2023-10-27 0:23 ` Chris Packham [this message]
2023-11-17 19:42 ` [PATCH 2/3] Revert "arm64: Use level-2 for largest block mappings " Tom Rini
2023-10-27 0:23 ` [PATCH 3/3] Revert "arm64: Use FEAT_HAFDBS to track dirty pages when available" Chris Packham
2023-11-17 19:42 ` Tom Rini
2023-10-27 9:49 ` [PATCH 0/3] Revert HAFDBS changes Pierre-Clément Tosi
2023-10-27 17:22 ` Tom Rini
2023-11-09 21:33 ` Tom Rini
2023-11-10 5:38 ` Chris Packham
2023-11-17 19:41 ` Tom Rini
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=20231027002409.430285-3-judge.packham@gmail.com \
--to=judge.packham@gmail.com \
--cc=bmeng.cn@gmail.com \
--cc=maz@kernel.org \
--cc=meitaogao@asrmicro.com \
--cc=paul.liu@linaro.org \
--cc=peng.fan@nxp.com \
--cc=ptosi@google.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
--cc=ye.li@nxp.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.