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.
