On 16/01/2026 10:52, Konrad Dybcio wrote:
On 1/14/26 10:55 PM, David Heidelberg wrote:
On 14/01/2026 11:28, Konrad Dybcio wrote:
On 1/14/26 11:15 AM, David Heidelberg wrote:
On 12/01/2026 21:13, Barnabás Czémán wrote:
The device was crashing on high memory load because the reserved memory
ranges was wrongly defined. Correct the ranges for avoid the crashes.
Change the ramoops memory range to match with the values from the recovery
to be able to get the results from the device.
Fixes: 9b1a6c925c88 ("arm64: dts: qcom: sm6125: Initial support for
xiaomi-ginkgo")
Signed-off-by: Barnabás Czémán <[email protected]>
---
[...]
Hello!
I suggest one more nice to have improvement:
you could label framebuffer cont_splash_mem since you already touching the node
and testing the series.
Then in additional commit, you can replace manually defined `reg` in chosen >
framebuffer node with
memory-region = <&cont_splash_mem>;
For example you can look at sdm845-oneplus-common.dtsi
Tell me what u think
If you wanna do that, please call it framebuffer_mem, "cont_splash" is a
Qualcomm-specific name for (roughly) flicker-free bootup
I have feeling someone recommended me to stick with cont_splash_mem.
I think, since we'll be doing the mdss reset anyway in sdm845 (which I used as
an example), I can do the rename in our sdm845 too then without any harm? (no
it's not flicker-free takeover :D )
It's not flicker-free because the OS must cooperate in that process,
whereas we currently reset and re-initialize the entire display subsystem
Sure.
Previously I was thinking, that after doing proper panel driver with
proper initialization sequences etc. etc., we could have device-tree
property such as "linux,takeover-from-bootloader", where we could skip
mdss reset, panel reset and just continue from the point what bootloader
set (for devices where bootloader does the right job).
David
Konrad
--
David Heidelberg
