Re: [PATCH v2] drm/msm/dp: enhance both connect and disconnect pending_timeout handle

From: Kuogee Hsieh <quic_khsieh@quicinc.com>
To: Stephen Boyd <swboyd@chromium.org>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: <robdclark@gmail.com>, <sean@poorly.run>, <vkoul@kernel.org>,
	<daniel@ffwll.ch>, <airlied@linux.ie>, <agross@kernel.org>,
	<bjorn.andersson@linaro.org>, <quic_abhinavk@quicinc.com>,
	<quic_aravindh@quicinc.com>, <quic_sbillaka@quicinc.com>,
	<freedreno@lists.freedesktop.org>,
	<dri-devel@lists.freedesktop.org>,
	<linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] drm/msm/dp: enhance both connect and disconnect pending_timeout handle
Date: Wed, 20 Apr 2022 16:57:25 -0700	[thread overview]
Message-ID: <0b92cab4-d46b-a419-43ad-0fa08c8c0e4d@quicinc.com> (raw)
In-Reply-To: <CAE-0n51F+S4a2mQoyWa-TpJcd73hstm2Sh1uO+4T_75UaWQASQ@mail.gmail.com>

On 4/20/2022 3:58 PM, Stephen Boyd wrote:
> Quoting Kuogee Hsieh (2022-04-15 17:06:48)
>> On 4/14/2022 4:34 PM, Dmitry Baryshkov wrote:
>>> I'm not sure how should the driver react if the client doesn't disable
>>> the output, but then the sink gets reattached?
>> I do not know that either.
>>
>> But it should not happen as long as framework response to uevent.
> In talking with seanpaul@ it sounds like we can update the link status
> to BAD with drm_connector_set_link_status_property() and then put it
> back to GOOD when the link is re-established. This way userspace will
> know it needs to retry the modeset. Does that help here?

To setup connection, dp driver have to enable phy and do link training 
then transfer dp controller to video ready state.

After that, dp driver signal framework to set up frame buffer 
fetching/layer mixer and start timing engine at final step to have video 
stream start transmitting to panel.

Do opposite way to tear down connection since dp driver can not reset dp 
controller and disable phy before timing engine has been stopped. 
Otherwise vsync timeout or buffer underrun/overrun may happen.

this means user space framework need to stop timing engine (stop frame 
buffer fetching/layer mixer) first and then stop video ready state of dp 
controller and then disable phy. (note, there may have something else at 
drm stack need to be teared down but i do not know details)

In this case, since framework is not response to uevent to stop timing 
engine,  dp controller still in video ready state and phy still enabled 
even dongle had been removed already.

At this point, I am not sure what dp driver should do if dongle re 
plugged back in.

Tear down dp mainlink while timing engine is still running and re setup 
dp mainlink?

However, I think this scenario most likely will not happen since if 
framework responses uevent to setup connection earlier it should be 
there to response uevent to tear down connection.