On Tue, Feb 25, 2025 at 09:57:17PM +0800, Yongbang Shi wrote:
- Is HPD even properly delivered to userspace? What kind of compsitorOn Mon, 24 Feb 2025 at 16:03, Yongbang Shi <shiyongbang@xxxxxxxxxx> wrote:Right, I knew it. When I insmode my driver firstly (or restart display service), it will call disable, modeset and enable,
It should be userspace, who triggers the enable/disable (or it shouldOn Sat, Feb 22, 2025 at 06:35:48PM +0800, Yongbang Shi wrote:Hi Dmitry,
Why? The link training and mode programming should happen duringThanks for your asking, there are cfg/reset process when the connector 's pluging in/out.+static int hibmc_dp_hpd_event(struct drm_client_dev *client)If I understand this correctly, you are using a separate drm_client to
+{
+ 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);
+ }
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.
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.
pre_enable / enable stage (legacy or atomic).
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.I
be the in-kernel fbdev / fbcon, which interface through the generic
drm_fbdev client).
by user, but it won't call when HPD triggered .
are you using? Is .detect working properly and reporting a correct
plug-in state?