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
Konrad
