Devicetree
 help / color / mirror / Atom feed
From: Roman Linev <admin@mswin.me>
To: Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>
Cc: "Barnabás Czémán" <barnabas.czeman@mainlining.org>,
	linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, "Roman Linev" <admin@mswin.me>
Subject: [PATCH] arm64: dts: qcom: sm6125-xiaomi-laurel-sprout: reserve firmware-owned DRAM
Date: Fri, 21 Aug 2026 06:25:41 +0300	[thread overview]
Message-ID: <20260821032541.1856299-1-admin@mswin.me> (raw)

sm6125.dtsi sizes reserved_mem1@46200000 at 0x2d00000 (45 MiB), so it ends
at 0x48f00000. On laurel-sprout the firmware owns 0x4900000 (73 MiB) at
that base: the downstream device tree overrides the SoC region with

	removed_region@46200000 { reg = <0 0x46200000 0 0x4900000>; };

which ends exactly at 0x4ab00000, where mainline places camera_mem. The
28 MiB between 0x48f00000 and 0x4ab00000 is therefore firmware-owned on
this board while mainline leaves it as free System RAM and hands it to the
page allocator.

On Qualcomm a "removed_region" is XPU-protected, so this is not a matter of
reading stale data: the region is not the kernel's to allocate.

The observed symptom is hard lockups under sustained buffered reads, where
page-cache pressure eventually reaches the disputed range. Before this
change the device wedged at a rate of roughly one lockup per 59 MiB of
buffered reads from the SD card, reproducibly enough to fire on demand.
With the region reserved, the same workload has run 691 GiB of buffered
reads with zero lockups.

Reserve the delta as a board-level region abutting camera_mem rather than
resizing the SoC-level reserved_mem1, since other SM6125 boards may
legitimately have a different split; sm6125-xiaomi-ginkgo, for instance,
has its own corrected reserved-memory layout.

Signed-off-by: Roman Linev <admin@mswin.me>
---
 .../boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts  | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
index 139f2b401..a6ee6ee80 100644
--- a/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
+++ b/arch/arm64/boot/dts/qcom/sm6125-xiaomi-laurel-sprout.dts
@@ -37,6 +37,20 @@ framebuffer0: framebuffer@5c000000 {
 	};
 
 	reserved-memory {
+		/*
+		 * The SoC dtsi sizes reserved_mem1 at 0x2d00000 (45 MiB), ending
+		 * at 0x48f00000. This device's firmware owns 0x4900000 (73 MiB)
+		 * there -- downstream laurel_sprout carves out
+		 * removed_region@46200000 with that size, ending exactly at
+		 * camera_mem's 0x4ab00000. The 28 MiB in between is XPU-owned
+		 * on this board and mainline currently hands it to the buddy
+		 * allocator.
+		 */
+		reserved_mem1_laurel: memory@48f00000 {
+			reg = <0x0 0x48f00000 0x0 0x1c00000>;
+			no-map;
+		};
+
 		debug_mem: debug@ffb00000 {
 			reg = <0x0 0xffb00000 0x0 0xc0000>;
 			no-map;
-- 
2.55.0


                 reply	other threads:[~2026-08-21  3:25 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20260821032541.1856299-1-admin@mswin.me \
    --to=admin@mswin.me \
    --cc=andersson@kernel.org \
    --cc=barnabas.czeman@mainlining.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    /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