[PATCH 2/4] drm/msm/dp: remove redundant ST_DISPLAY_OFF checks in msm_dp_bridge_atomic_enable()

[Dmitry Baryshkov]

On Tue, Dec 03, 2024 at 07:24:46PM -0800, Abhinav Kumar wrote:
> 
> 
> On 12/3/2024 5:53 AM, Dmitry Baryshkov wrote:
> > On Mon, Dec 02, 2024 at 04:39:01PM -0800, Abhinav Kumar wrote:
> > > The checks in msm_dp_display_prepare() 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.
> > 
> > Can the state change between atomic_check() and atomic_commit()?
> > 
> 
> Good question.
> 
> I cannot deny that such a possibility does exist.
> 
> From what I can see in the state machine today, the only possibility I can
> think of here is if a user very quickly removes the cable as soon as they
> connect the cable like so fast that the connect was not yet processed before
> disconnect.

If the cable has electrical issues, it is possible even w/o user
intervention.

> 
> Similarly, if an irq_hpd fires after atomic_check but before
> atomic_enable(), and moreover if we hit the sink_count == 0 case in
> msm_dp_display_handle_port_status_changed() during this irq_hpd,
> 
> In both these cases, then we will transition to ST_DISCONNECT_PENDING state.
> 
> Without this change, we would have bailed out in the ST_DISCONNECT_PENDING
> case.
> 
> But other than this, I cannot atleast think of a case where a different
> state transition can happen between atomic_check() and atomic_commit()
> because for other transitions, I think we should be still okay.
> 
> But this is purely based on theoretical observation and hypothesis.
> 
> Is it better to add a check to bail out in the DISCONNECT_PENDING case?

I think so, please.

> 
> OR document this as "To-do: Need to bail out if DISCONNECT_PENDING" because
> even if I add this check, I dont know if can make sure this can be validated
> as the check could never hit.
> 
> 
> > > 
> > > 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.
> > > 
> > > To simplify the code, get rid of these checks.
> > > 
> > > Signed-off-by: Abhinav Kumar <quic_abhinavk at quicinc.com>
> > > ---
> > >   drivers/gpu/drm/msm/dp/dp_display.c | 6 ------
> > >   1 file changed, 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
> > > index 992184cc17e4..614fff09e5f2 100644
> > > --- a/drivers/gpu/drm/msm/dp/dp_display.c
> > > +++ b/drivers/gpu/drm/msm/dp/dp_display.c
> > > @@ -1513,12 +1513,6 @@ void msm_dp_bridge_atomic_enable(struct drm_bridge *drm_bridge,
> > >   		return;
> > >   	}
> > > -	state = msm_dp_display->hpd_state;
> > > -	if (state != ST_DISPLAY_OFF && state != ST_MAINLINK_READY) {
> > > -		mutex_unlock(&msm_dp_display->event_mutex);
> > > -		return;
> > > -	}
> > > -
> > >   	rc = msm_dp_display_set_mode(dp, &msm_dp_display->msm_dp_mode);
> > >   	if (rc) {
> > >   		DRM_ERROR("Failed to perform a mode set, rc=%d\n", rc);
> > > 
> > > -- 
> > > 2.34.1
> > > 
> > 

-- 
With best wishes
Dmitry