diff options
author | John Stultz <jstultz@google.com> | 2022-06-30 19:49:42 +0000 |
---|---|---|
committer | John Stultz <jstultz@google.com> | 2022-06-30 20:25:44 +0000 |
commit | 799e8c74c65e5d12d354a0b3f2b541f3d44273a2 (patch) | |
tree | f33e1cb8c384abe149591e487c0a3215d8bfa39b | |
parent | af862a52c15e3f6b89f55bc442dbc9b08e45c2d0 (diff) | |
download | drm_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.cpp | 13 |
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(); |