Re: [PATCH 3/4] arm64: dts: qcom: sdm845: Add missing MDSS reset

[Konrad Dybcio]

On 4/13/26 12:50 PM, David Heidelberg wrote:
> On 13/04/2026 12:28, Konrad Dybcio wrote:
>> On 4/12/26 2:41 AM, Dmitry Baryshkov wrote:
>>> On Fri, Apr 10, 2026 at 10:55:53AM +0200, Konrad Dybcio wrote:
>>>> On 4/9/26 11:24 PM, Dmitry Baryshkov wrote:
>>>>> On Thu, Apr 09, 2026 at 10:38:15PM +0200, David Heidelberg wrote:
>>>>>> On 18/02/2026 16:59, Dmitry Baryshkov wrote:
>>>>>>> On Wed, Feb 18, 2026 at 03:28:01PM +0100, Konrad Dybcio wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 18-Feb-26 12:58, Dmitry Baryshkov wrote:
>>>>>>>>> On Wed, Feb 18, 2026 at 12:24:26PM +0100, Konrad Dybcio wrote:
>>>>>>>>>> On 2/18/26 12:18 PM, David Heidelberg wrote:
>>>>>>>>>>> On 18/02/2026 11:30, Konrad Dybcio wrote:
>>>>>>>>>>>> On 2/17/26 10:20 PM, Dmitry Baryshkov wrote:
>>>>>>>>>>>>> From: David Heidelberg <david@xxxxxxx>
>>>>>>>>>>>>>
>>>>>>>>>>>>> If the OS does not support recovering the state left by the
>>>>>>>>>>>>> bootloader it needs a way to reset display hardware, so that it can
>>>>>>>>>>>>> start from a clean state. Add a reference to the relevant reset.
>>>>>>>>>>>>
>>>>>>>>>>>> This is not the relevant reset
>>>>>>>>>>>>
>>>>>>>>>>>> You want MDSS_CORE_BCR @ 0xaf0_2000
>>>>>>>>>>>
>>>>>>>>>>> Thanks, I prepared the fixes [1].
>>>>>>>>>>>
>>>>>>>>>>> I'll try to test it if it's not breaking anything for us and send as v2 of [2].
>>>>>>>>>>>
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>> [1] https://codeberg.org/sdm845/linux/commits/branch/b4/mdss-reset
>>>>>>>>>>> [2] https://patchwork.kernel.org/project/linux-arm-msm/patch/20260112-mdss-reset-v1-1-af7c572204d3@xxxxxxx/
>>>>>>>>>>
>>>>>>>>>> Please don't alter the contents of dt-bindings, it really doesn't matter
>>>>>>>>>> if on sdm845 it's reset0 or reset1, that's why we define them in the first
>>>>>>>>>> place
>>>>>>>>>
>>>>>>>>> I dpn't think that will pass. Current reset is defined as RSCC, we can't
>>>>>>>>> change that to CORE behind the scene. I'd prefer David's approach.
>>>>>>>>
>>>>>>>> Back when I replied, David had a patch that removed the current RSCC
>>>>>>>> reset definition in dt-bindings (at index 0) and re-used that index
>>>>>>>> for CORE, putting RSCC at index 1. Perhaps it's better to link to
>>>>>>>> specific commits when making comments, note to self :P
>>>>>>>
>>>>>>> Yes, I saw the commit having two resets. Anyway, as we saw, it doesn't
>>>>>>> work.
>>>>>>
>>>>>> So, finally I spent "so much effort" (read throwing it at LLM) looking at:
>>>>>>
>>>>>> arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402,
>>>>>> iova=0x9d4bb500, fsynr=0x170021, cbfrsynra=0xc88, cb=11
>>>>>> arm-smmu 15000000.iommu: FSR    = 00000402 [Format=2 TF], SID=0xc88
>>>>>> arm-smmu 15000000.iommu: FSYNR0 = 00170021 [S1CBNDX=23 PNU PLVL=1]
>>>>>
>>>>> [...]
>>>>>
>>>>>>
>>>>>> These (or very similar warnings) are around sdm845 definitely 6.19+ /
>>>>>> linux-next kernels for some time, but pretty harmless.
>>>>>>
>>>>>> LLM suggested multiple fixes, but when presenting possibility of
>>>>>> implementing mdss reset it found it as most preferable [1].
>>>>>>
>>>>>> Adding MDSS reset would most likely solve it. It's not critical, but not
>>>>>> nice to see many red lines in the dmesg.
>>>>>>
>>>>>> Is there something I could experiment with to get closer to have proper MDSS reset?
>>>>>
>>>>> I don't have a sensible solution at this point. We tried using the MDSS
>>>>> reset on several SDM845 devices, but they just reset. So... I don't have
>>>>> any possible solution.
>>>>
>>>> The older context talks about altering the existing dt-bindings values
>>>> and now we're at hardware (mis)behaving? What is the issue here?
>>>
>>> The HDK and DB845c reset if I try touching MDSS core reset.
>>
>> And David, does that also happen on your other boards?
> 
> yes, I recall OnePlus 6 or 6T going to crashdump and Pixel 3 crashing too.

I found some older version of the docs for 845.

It says that to pull the BCR, all clocks to MDSS must be off while
the reset is in progress. Maybe that could be a hint (or maybe it's
just broken on 845).

If either of you would be able to catch an actual crashdump and get the
data out of it (via qdl(rs) ramdump tools), we could see what the TZ
says the crash reason is

Konrad