On Sat, Feb 22, 2025 at 06:35:48PM +0800, Yongbang Shi wrote:
+static int hibmc_dp_hpd_event(struct drm_client_dev *client)
+{
+ struct hibmc_dp *dp = container_of(client, struct hibmc_dp, client);
+ struct hibmc_drm_private *priv = to_hibmc_drm_private(dp->drm_dev);
+ struct drm_display_mode *mode = &priv->crtc.state->adjusted_mode;
+ int ret;
+
+ if (dp->hpd_status) {
+ hibmc_dp_hpd_cfg(&priv->dp);
+ ret = hibmc_dp_prepare(dp, mode);
+ if (ret)
+ return ret;
+
+ hibmc_dp_display_en(dp, true);
+ } else {
+ hibmc_dp_display_en(dp, false);
+ hibmc_dp_reset_link(&priv->dp);
+ }
If I understand this correctly, you are using a separate drm_client to
enable and disable the link & display. Why is it necessary? Existing
drm_clients and userspace compositors use drm framework, they should be
able to turn the display on and off as required.
Thanks for your asking, there are cfg/reset process when the connector 's pluging in/out.
We want to cfg DP registers again when the connector changes. Not only dp link training, but also cfg
the different video modes into DP registers.
Why? The link training and mode programming should happen during
pre_enable / enable stage (legacy or atomic).
Hi Dmitry,
Right, that's what I'm curious about. It won't call encoder enble/disable functions when I triggered HPD.
And I'm sure the drm_connector_helper_hpd_irq_event() is called. So I add a drm_client for it.
