From: Bert Karwatzki <spasswolf@web.de>
To: linux-kernel@vger.kernel.org
Cc: Douglas Anderson <dianders@chromium.org>,
linux-arm-msm@vger.kernel.org,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Luca Weiss <luca@z3ntu.xyz>
Subject: drm_bridges on fairphone-fp3 are enabled in the wrong order
Date: Wed, 05 Jul 2023 09:51:42 +0200 [thread overview]
Message-ID: <c27953274997a56f8e0522f9331e733ae92bf25b.camel@web.de> (raw)
The fairphone-fp3 has a drm_panel attached to a dsi bridge. This are added to
the bridge_chain in struct drm_encoder in the order dsi, panel. When the
drm_atomic_bridge_chain_pre_enable these get enabled in the order panel, dsi
because of the list_for_each_entry_reverse. But the drm_panel of the fairphone-
fp3 is enabled using mipi_dsi_dcs_write_buffer which only works if the dsi is
enabled before the panel.
To work around this one can revert
commit 9e15123eca7942caa8a3e1f58ec0df7d088df149
Author: Douglas Anderson <dianders@chromium.org>
Date: Tue Jan 31 14:18:25 2023 -0800
drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset
This leads to a working panel on startup. But when suspending one runs again
into a similar problem. When the bridges are disabled the dsi is disabled first
which leads to a failure in disabling the panel again because
mipi_dsi_dcs_write_buffer fails when the dsi is already switched of.
As a simple workarund for both problems I have found it works to exchange the
order of the bridge chain in drm_endcoder:
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 28b8012a21f2..990f7c68a27c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -550,6 +555,8 @@ int msm_dsi_manager_ext_bridge_init(u8 id)
if (ret < 0)
return ret;
}
+ /* swap bridges in list */
+ list_swap(&encoder->bridge_chain, encoder->bridge_chain.next);
/* The pipeline is ready, ping encoders if necessary */
msm_dsi_manager_set_split_display(id);
But this does not look like a portable solution so I wonder if there is a better
way to do this.
The linux kernel used here is a linux-next-20220630, with several out-of-tree
patches which are needed for the msm8953 gpu and the display used in the
fairphone-fp3 located here: https://github.com/spasswolf/msm8953-linux.git in
branch msm8953_iommu_rebase_v2_wlan_modem_ipa_cpufreq_display_debug.
Bert Karwatzki
next reply other threads:[~2023-07-05 7:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-05 7:51 Bert Karwatzki [this message]
2023-07-06 16:22 ` Doug Anderson
2023-07-06 22:35 ` Bert Karwatzki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c27953274997a56f8e0522f9331e733ae92bf25b.camel@web.de \
--to=spasswolf@web.de \
--cc=dianders@chromium.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luca@z3ntu.xyz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®