[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAO9ioeUPJm1MbqAVJfcQSTAmvY3-TmvtZ+=Js1mZ53JFYHoUhw@mail.gmail.com>
Date: Fri, 30 May 2025 19:04:30 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Jessica Zhang <jessica.zhang@....qualcomm.com>
Cc: Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
Marijn Suijten <marijn.suijten@...ainline.org>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Abhinav Kumar <quic_abhinavk@...cinc.com>,
Dmitry Baryshkov <lumag@...nel.org>, linux-arm-msm@...r.kernel.org,
dri-devel@...ts.freedesktop.org, freedreno@...ts.freedesktop.org,
Stephen Boyd <swboyd@...omium.org>,
Doug Anderson <dianders@...omium.org>, Johan Hovold <johan@...nel.org>,
Bjorn Andersson <quic_bjorande@...cinc.com>,
Abhinav Kumar <abhinav.kumar@....qualcomm.com>,
linux-kernel@...r.kernel.org, Yongxing Mou <quic_yongmou@...cinc.com>
Subject: Re: [PATCH 2/4] drm/msm/dp: Return early from atomic_enable() if ST_DISCONNECT_PENDING
On Fri, 30 May 2025 at 02:15, Jessica Zhang
<jessica.zhang@....qualcomm.com> wrote:
>
> From: Abhinav Kumar <quic_abhinavk@...cinc.com>
>
> The checks in msm_dp_bridge_atomic_enable() for making sure that we are in
> ST_DISPLAY_OFF OR ST_MAINLINK_READY seem redundant.
>
> DRM fwk shall not issue any commits if state is not ST_MAINLINK_READY as
> msm_dp's atomic_check callback returns a failure if state is not
> ST_MAINLINK_READY.
What if the state changes between atomic_check() and atomic_enable()?
There are no locks, cable unplugging is async, so it's perfectly
possible.
>
> For the ST_DISPLAY_OFF check, its mainly to guard against a scenario that
> there is an atomic_enable() without a prior atomic_disable() which once
> again should not really happen.
>
> Since it's still possible for the state machine to transition to
> ST_DISCONNECT_PENDING between atomic_check() and atomic_commit(), change
> this check to return early if hpd_state is ST_DISCONNECT_PENDING.
Can we really, please, drop the state machine? I had other plans for
the next week, but maybe I should just do it, so that by the end of
6.17 cycle we can have a merged, stable and working solution? This
topic has been lingering for months without any actual change.
>
> Signed-off-by: Abhinav Kumar <quic_abhinavk@...cinc.com>
> Signed-off-by: Jessica Zhang <jessica.zhang@....qualcomm.com>
> ---
> drivers/gpu/drm/msm/dp/dp_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
> index 1d7cda62d5fb..f2820f06f5dc 100644
> --- a/drivers/gpu/drm/msm/dp/dp_display.c
> +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> @@ -1512,7 +1512,7 @@ void msm_dp_bridge_atomic_enable(struct drm_bridge *drm_bridge,
> }
>
> hpd_state = msm_dp_display->hpd_state;
> - if (hpd_state != ST_DISPLAY_OFF && hpd_state != ST_MAINLINK_READY) {
> + if (hpd_state == ST_DISCONNECT_PENDING) {
> mutex_unlock(&msm_dp_display->event_mutex);
> return;
> }
>
> --
> 2.49.0
>
--
With best wishes
Dmitry
Powered by blists - more mailing lists