aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJohn Stultz <jstultz@google.com>2022-06-30 19:49:42 +0000
committerJohn Stultz <jstultz@google.com>2022-06-30 20:25:44 +0000
commit799e8c74c65e5d12d354a0b3f2b541f3d44273a2 (patch)
treef33e1cb8c384abe149591e487c0a3215d8bfa39b
parentaf862a52c15e3f6b89f55bc442dbc9b08e45c2d0 (diff)
downloaddrm_hwcomposer-799e8c74c65e5d12d354a0b3f2b541f3d44273a2.tar.gz
drm_hwcomposer: Workaround for screen de-activating causing db845c regression
Since commit d0494d9b8097 ("drm_hwcomposer: Fixes for display hotplug / headless mode"), which introduced an extra call to de-active the display on de-init, we've seen regressions on db845c with the VtsHalGraphicsComposerV2_3TargetTest test set. This seems to be due to an issue on db845c, where after putting the lt9611 bridge to sleep, the connection detection stops working even after the chip is reset. However, on changing the kernel driver to avoid putting the bridge to sleep so connect detection works, we start to see SIGSEGV crashes in drm_hwcomposer, due to the service expecting the hwmodule to finish registercallback during client detaching within 1 second. Exceeding this values causes VTS to crash. And msm driver introduces delay enough to exceed the limit. So this patch is a workaround to restore previous behavior to avoid the regression until we can sort out a proper fixes to db845c and drm_hwcomposer. Signed-off-by: John Stultz <jstultz@google.com> Change-Id: Iff5d3cf3f7fa2f1f2acb68a5a629677137e51188
-rw-r--r--hwc2_device/HwcDisplay.cpp13
1 files changed, 13 insertions, 0 deletions
diff --git a/hwc2_device/HwcDisplay.cpp b/hwc2_device/HwcDisplay.cpp
index 58b888e..d968ab3 100644
--- a/hwc2_device/HwcDisplay.cpp
+++ b/hwc2_device/HwcDisplay.cpp
@@ -120,9 +120,22 @@ void HwcDisplay::Deinit() {
AtomicCommitArgs a_args{};
a_args.composition = std::make_shared<DrmKmsPlan>();
GetPipe().atomic_state_manager->ExecuteAtomicCommit(a_args);
+/*
+ * TODO:
+ * Unfortunately the following causes regressions on db845c
+ * with VtsHalGraphicsComposerV2_3TargetTest due to the display
+ * never coming back. Patches to avoiding that issue on the
+ * the kernel side unfortunately causes further crashes in
+ * drm_hwcomposer, because the client detach takes longer then the
+ * 1 second max VTS expects. So for now as a workaround, lets skip
+ * deactivating the display on deinit, which matches previous
+ * behavior prior to commit d0494d9b8097
+ */
+#if 0
a_args.composition = {};
a_args.active = false;
GetPipe().atomic_state_manager->ExecuteAtomicCommit(a_args);
+#endif
vsync_worker_.Init(nullptr, [](int64_t) {});
current_plan_.reset();