arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 + 1 file changed, 1 insertion(+)
From: David Heidelberg <david@ixit.cz>
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.
Signed-off-by: David Heidelberg <david@ixit.cz>
---
It efficiently fixes nothing for us (at least what we're aware), so I
assume the state left by bootloader is good enough
I sending this as a something "which seems right" and works for us in
sdm845-next tree.
David
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index bf2f9c04adba7..75c192eddc57c 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -4550,6 +4550,7 @@ mdss: display-subsystem@ae00000 {
reg-names = "mdss";
power-domains = <&dispcc MDSS_GDSC>;
+ resets = <&dispcc DISP_CC_MDSS_RSCC_BCR>;
clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
<&dispcc DISP_CC_MDSS_MDP_CLK>;
---
base-commit: f417b7ffcbef7d76b0d8860518f50dae0e7e5eda
change-id: 20260112-mdss-reset-06988f05af96
Best regards,
--
David Heidelberg <david@ixit.cz>
On 1/12/26 13:33, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> 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.
>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> It efficiently fixes nothing for us (at least what we're aware), so I
> assume the state left by bootloader is good enough
In fact it does even more, perhaps in your usecase you're not affected but
it permits resetting the MDSS while switching the IOMMU from bypass to translated.
In the current IOMMU implementation, there's no current way to keep the IOMMU setup
for an SID without a cut, leading to fatal IOMMU errors.
With the hypervisor enabled, some IOMMU entries are left to fallback in bypass
when switching, but in EL2 there's no fallback and the ARM SMMUv2 doesn't support
mapping _before_ attaching to a device leading to:
https://elixir.bootlin.com/linux/v6.18.4/source/drivers/iommu/iommu.c#L3046
/*
* Drivers are supposed to allow mappings to be installed in a domain
* before device attachment, but some don't. Hack around this defect by
* trying again after attaching. If this happens it means the device
* will not continuously have the IOMMU_RESV_DIRECT map.
*/
Sorry for the digression!
Neil
>
> I sending this as a something "which seems right" and works for us in
> sdm845-next tree.
>
> David
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index bf2f9c04adba7..75c192eddc57c 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -4550,6 +4550,7 @@ mdss: display-subsystem@ae00000 {
> reg-names = "mdss";
>
> power-domains = <&dispcc MDSS_GDSC>;
> + resets = <&dispcc DISP_CC_MDSS_RSCC_BCR>;
>
> clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
> <&dispcc DISP_CC_MDSS_MDP_CLK>;
>
> ---
> base-commit: f417b7ffcbef7d76b0d8860518f50dae0e7e5eda
> change-id: 20260112-mdss-reset-06988f05af96
>
> Best regards,
On 13/01/2026 10:48, Neil Armstrong wrote: > On 1/12/26 13:33, David Heidelberg via B4 Relay wrote: >> From: David Heidelberg <david@ixit.cz> >> >> 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. >> >> Signed-off-by: David Heidelberg <david@ixit.cz> >> --- >> It efficiently fixes nothing for us (at least what we're aware), so I >> assume the state left by bootloader is good enough > > In fact it does even more, perhaps in your usecase you're not affected but > it permits resetting the MDSS while switching the IOMMU from bypass to > translated. > > In the current IOMMU implementation, there's no current way to keep the > IOMMU setup > for an SID without a cut, leading to fatal IOMMU errors. > > With the hypervisor enabled, some IOMMU entries are left to fallback in > bypass > when switching, but in EL2 there's no fallback and the ARM SMMUv2 > doesn't support > mapping _before_ attaching to a device leading to: > https://elixir.bootlin.com/linux/v6.18.4/source/drivers/iommu/iommu.c#L3046 > /* > * Drivers are supposed to allow mappings to be installed in a domain > * before device attachment, but some don't. Hack around this > defect by > * trying again after attaching. If this happens it means the device > * will not continuously have the IOMMU_RESV_DIRECT map. > */ > > Sorry for the digression! > > Neil > Thank you, that's good to know! :) David [...]
On 1/12/26 1:33 PM, David Heidelberg via B4 Relay wrote: > From: David Heidelberg <david@ixit.cz> > > 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 part is reasonable > > Signed-off-by: David Heidelberg <david@ixit.cz> > --- > It efficiently fixes nothing for us (at least what we're aware), so I > assume the state left by bootloader is good enough > > I sending this as a something "which seems right" and works for us in > sdm845-next tree. This part says "I am only doing this because cargo cult".. Generally this patch looks good, because it describes a physical connection on the SoC for the OS to consume.. Konrad
Seeing the $subj, I asking myself why do I use `b4 --reflect`...
Anyway, if the patch will be good enough, feel free to strip
`needsreview!`, or I'll sent v2 ;-)
David
On 12/01/2026 13:33, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> 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.
>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> It efficiently fixes nothing for us (at least what we're aware), so I
> assume the state left by bootloader is good enough
>
> I sending this as a something "which seems right" and works for us in
> sdm845-next tree.
>
> David
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index bf2f9c04adba7..75c192eddc57c 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -4550,6 +4550,7 @@ mdss: display-subsystem@ae00000 {
> reg-names = "mdss";
>
> power-domains = <&dispcc MDSS_GDSC>;
> + resets = <&dispcc DISP_CC_MDSS_RSCC_BCR>;
>
> clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>,
> <&dispcc DISP_CC_MDSS_MDP_CLK>;
>
> ---
> base-commit: f417b7ffcbef7d76b0d8860518f50dae0e7e5eda
> change-id: 20260112-mdss-reset-06988f05af96
>
> Best regards,
--
David Heidelberg
© 2016 - 2026 Red Hat, Inc.