From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Abhinav Kumar <quic_abhinavk@quicinc.com>
Cc: dri-devel@lists.freedesktop.org,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
freedreno@lists.freedesktop.org, quic_jesszhan@quicinc.com,
quic_parellan@quicinc.com, andersson@kernel.org,
jani.nikula@linux.intel.com,
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm: remove drm_bridge_hpd_disable() from drm_bridge_connector_destroy()
Date: Tue, 19 Sep 2023 21:12:46 +0300 [thread overview]
Message-ID: <20230919181246.GA24325@pendragon.ideasonboard.com> (raw)
In-Reply-To: <20230919174813.26958-1-quic_abhinavk@quicinc.com>
Hi Abhinav,
Thank you for the patch.
On Tue, Sep 19, 2023 at 10:48:12AM -0700, Abhinav Kumar wrote:
> 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().
The change makes sense to me, but I'm a bit worried this could introduce
a regression by leaving HPD enabled in some cases.
I agree that bridges shouldn't track the HPD state, it should be tracked
by the core and the .enable_hpd() and .disable_hpd() operations should
be balanced. Their documentation, however, doesn't clearly state this,
and the documentation of the callers of these operations is also fairly
unclear.
Could you perhaps try to improve the documentation ? With that,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
for this patch.
> 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>
> ---
> drivers/gpu/drm/drm_bridge_connector.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge_connector.c b/drivers/gpu/drm/drm_bridge_connector.c
> index 1da93d5a1f61..c4dba39acfd8 100644
> --- a/drivers/gpu/drm/drm_bridge_connector.c
> +++ b/drivers/gpu/drm/drm_bridge_connector.c
> @@ -187,12 +187,6 @@ static void drm_bridge_connector_destroy(struct drm_connector *connector)
> struct drm_bridge_connector *bridge_connector =
> to_drm_bridge_connector(connector);
>
> - if (bridge_connector->bridge_hpd) {
> - struct drm_bridge *hpd = bridge_connector->bridge_hpd;
> -
> - drm_bridge_hpd_disable(hpd);
> - }
> -
> drm_connector_unregister(connector);
> drm_connector_cleanup(connector);
>
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2023-09-19 18:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-19 17:48 Abhinav Kumar
2023-09-19 18:12 ` Laurent Pinchart [this message]
2023-09-19 22:53 ` Abhinav Kumar
2023-12-04 14:16 ` Dmitry Baryshkov
-- strict thread matches above, loose matches on Subject: below --
2023-07-17 22:34 Abhinav Kumar
2023-07-18 5:55 ` Dmitry Baryshkov
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=20230919181246.GA24325@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andersson@kernel.org \
--cc=daniel@ffwll.ch \
--cc=dmitry.baryshkov@linaro.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=quic_abhinavk@quicinc.com \
--cc=quic_jesszhan@quicinc.com \
--cc=quic_parellan@quicinc.com \
--cc=tzimmermann@suse.de \
/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®