The slice IDs for CVPFW, CPUSS1 and CPUWHT currently overflow the 32bit
LLCC config registers, which means it is writing beyond the upper limit
of the ATTR0_CFGn and ATTR1_CFGn range of registers. But the most obvious
impact is the fact that the mentioned slices do not get configured at all,
which will result in reduced performance. Fix that by using the slice ID
values taken from the latest LLCC SC table.
Fixes: ec69dfbdc426 ("soc: qcom: llcc: Add sc8180x and sc8280xp configurations")
Cc: stable(a)vger.kernel.org # 5.19+
Signed-off-by: Abel Vesa <abel.vesa(a)linaro.org>
Tested-by: Juerg Haefliger <juerg.haefliger(a)canonical.com>
Reviewed-by: Sai Prakash Ranjan <quic_saipraka(a)quicinc.com>
Acked-by: Konrad Dybcio <konrad.dybcio(a)linaro.org>
Reviewed-by: Johan Hovold <johan+linaro(a)kernel.org>
---
The v3 is here:
https://lore.kernel.org/all/20230219165701.2557446-1-abel.vesa@linaro.org/
Changes since v3:
* explicitly mentioned in the commit message the fact that some random
registers might get written and the fact that there is an impact
on performance.
* Added Johan's R-b tag
Changes since v2:
* specifically mentioned the 3 slice IDs that are being fixed and
what is happening without this patch
* added stabke Cc line
* added Juerg's T-b tag
* added Sai's R-b tag
* added Konrad's A-b tag
Changes since v1:
* dropped the LLCC_GPU and LLCC_WRCACHE max_cap changes
* took the new values from documentatio this time rather than
downstream kernel
drivers/soc/qcom/llcc-qcom.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c
index 23ce2f78c4ed..26efe12012a0 100644
--- a/drivers/soc/qcom/llcc-qcom.c
+++ b/drivers/soc/qcom/llcc-qcom.c
@@ -191,9 +191,9 @@ static const struct llcc_slice_config sc8280xp_data[] = {
{ LLCC_CVP, 28, 512, 3, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
{ LLCC_APTCM, 30, 1024, 3, 1, 0x0, 0x1, 1, 0, 0, 1, 0, 0 },
{ LLCC_WRCACHE, 31, 1024, 1, 1, 0xfff, 0x0, 0, 0, 0, 0, 1, 0 },
- { LLCC_CVPFW, 32, 512, 1, 0, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
- { LLCC_CPUSS1, 33, 2048, 1, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
- { LLCC_CPUHWT, 36, 512, 1, 1, 0xfff, 0x0, 0, 0, 0, 0, 1, 0 },
+ { LLCC_CVPFW, 17, 512, 1, 0, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+ { LLCC_CPUSS1, 3, 2048, 1, 1, 0xfff, 0x0, 0, 0, 0, 1, 0, 0 },
+ { LLCC_CPUHWT, 5, 512, 1, 1, 0xfff, 0x0, 0, 0, 0, 0, 1, 0 },
};
static const struct llcc_slice_config sdm845_data[] = {
--
2.34.1
From: "andrew.yang" <andrew.yang(a)mediatek.com>
commit 3f98c9a62c338bbe06a215c9491e6166ea39bf82 upstream.
damon_get_folio() would always increase folio _refcount and
folio_isolate_lru() would increase folio _refcount if the folio's lru flag
is set.
If an unevictable folio isolated successfully, there will be two more
_refcount. The one from folio_isolate_lru() will be decreased in
folio_puback_lru(), but the other one from damon_get_folio() will be left
behind. This causes a pin page.
Whatever the case, the _refcount from damon_get_folio() should be
decreased.
Link: https://lkml.kernel.org/r/20230222064223.6735-1-andrew.yang@mediatek.com
Fixes: 57223ac29584 ("mm/damon/paddr: support the pageout scheme")
Signed-off-by: andrew.yang <andrew.yang(a)mediatek.com>
Reviewed-by: SeongJae Park <sj(a)kernel.org>
Cc: <stable(a)vger.kernel.org> [5.16.x]
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: SeongJae Park <sj(a)kernel.org>
---
This is a backport of the mainline patch for v6.1.y and v6.2.y.
mm/damon/paddr.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c
index e1a4315c4be6..402d30b37aba 100644
--- a/mm/damon/paddr.c
+++ b/mm/damon/paddr.c
@@ -219,12 +219,11 @@ static unsigned long damon_pa_pageout(struct damon_region *r)
put_page(page);
continue;
}
- if (PageUnevictable(page)) {
+ if (PageUnevictable(page))
putback_lru_page(page);
- } else {
+ else
list_add(&page->lru, &page_list);
- put_page(page);
- }
+ put_page(page);
}
applied = reclaim_pages(&page_list);
cond_resched();
--
2.25.1
HELLO,
AM PASCAL DONALD,A CITIZEN OF ENGLAND.I WOULD LIKE TO APPLY THROUGH
THIS MEDIUM FOR YOUR MAXIMUM COOPERATION TO SECURE AN OPPORTUNITY TO
TRANSFER A SUBSTANTIAL FUND FOR AN INVESTMENT IN YOUR COUNTRY.
I WILL BE LOOKING FORWARD TO HEAR FROM YOU URGENTLY.
PLEASE SEND EVERY REPLY TO MY DIRECT EMAIL AS STATED BELOW:
REGARDS,
MR.PASCAL DONALD.(ESQ)
dr.pascaldonald(a)outlook.com