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

[Konrad Dybcio]

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?

Konrad