diff options
author | Abhinav Kumar <quic_abhinavk@quicinc.com> | 2023-09-19 10:48:12 -0700 |
---|---|---|
committer | Dmitry Baryshkov <dmitry.baryshkov@linaro.org> | 2023-12-03 20:22:02 +0200 |
commit | f730e7adfd69d7ac859d8fe4d67e980cbad1e445 (patch) | |
tree | 3c4960736029ca95277e8be16a3d4ab0771193b5 /scripts/generate_rust_target.rs | |
parent | a5b2dcb96d6acb286459612a142371b0d74543bf (diff) |
drm: remove drm_bridge_hpd_disable() from drm_bridge_connector_destroy()
drm_bridge_hpd_enable()/drm_bridge_hpd_disable() callbacks call into
the respective driver's hpd_enable()/hpd_disable() ops. These ops control
the HPD enable/disable logic which in some cases like MSM can be a
dedicate hardware block to control the HPD.
During probe_defer cases, a connector can be initialized and then later
destroyed till the probe is retried. During connector destroy in these
cases, the hpd_disable() callback gets called without a corresponding
hpd_enable() leading to an unbalanced state potentially causing even
a crash.
This can be avoided by the respective drivers maintaining their own
state logic to ensure that a hpd_disable() without a corresponding
hpd_enable() just returns without doing anything.
However, to have a generic fix it would be better to avoid the
hpd_disable() callback from the connector destroy path and let
the hpd_enable() / hpd_disable() balance be maintained by the
corresponding drm_bridge_connector_enable_hpd() /
drm_bridge_connector_disable_hpd() APIs which should get called by
drm_kms_helper_disable_hpd().
changes in v2:
- minor change in commit text (Dmitry)
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919174813.26958-1-quic_abhinavk@quicinc.com
Diffstat (limited to 'scripts/generate_rust_target.rs')
0 files changed, 0 insertions, 0 deletions