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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.








[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux