Hi Maxime,
> static int vc4_vec_connector_get_modes(struct drm_connector *connector)
> {
> - struct drm_connector_state *state = connector->state;
> struct drm_display_mode *mode;
>
> - mode = drm_mode_duplicate(connector->dev,
> - vc4_vec_tv_modes[state->tv.legacy_mode].mode);
> + mode = drm_mode_analog_ntsc_480i(connector->dev);
> if (!mode) {
> DRM_ERROR("Failed to create a new display mode\n");
> return -ENOMEM;
> }
>
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
> drm_mode_probed_add(connector, mode);
>
> - return 1;
> + mode = drm_mode_analog_pal_576i(connector->dev);
> + if (!mode) {
> + DRM_ERROR("Failed to create a new display mode\n");
> + return -ENOMEM;
> + }
> +
> + drm_mode_probed_add(connector, mode);
> +
> + return 2;
> +}
Referencing those previous discussions:
-
https://lore.kernel.org/dri-devel/0255f7c6-0484-6456-350d-cf24f3fee...@tronnes.org/
-
https://lore.kernel.org/dri-devel/c8f8015a-75da-afa8-ca7f-b2b134cac...@gmail.com/
Unconditionally setting the 480i mode as DRM_MODE_TYPE_PREFERRED causes Xorg
(at least on current Raspberry Pi OS) to display garbage when
video=Composite1:PAL is specified on the command line, so I'm afraid this won't
do.
As I see it, there are three viable solutions for this issue:
a) Somehow query the video= command line option from this function, and set
DRM_MODE_TYPE_PREFERRED appropriately. This would break the abstraction
provided by global DRM code, but should work fine.
b) Modify drm_helper_probe_add_cmdline_mode() so that it sets
DRM_MODE_TYPE_PREFERRED in addition to DRM_MODE_TYPE_USERDEF. This seems
pretty robust, but affects the entire DRM subsystem, which may break
userspace in different ways.
- Maybe this could be mitigated by adding some additional conditions, e.g.
setting the PREFERRED flag only if no modes are already flagged as such
and/or only if the cmdline mode is a named one (~= analog TV mode)
c) Forcing userspace (Xorg / Raspberry Pi OS) to get fixed and honor the USERDEF
flag.
Either way, hardcoding 480i as PREFERRED does not seem right.
Note: this also applies to the sun4i version (patch 22/22).
> @@ -366,13 +472,16 @@ static void vc4_vec_encoder_enable(struct drm_encoder
> *encoder,
> struct drm_connector *connector = &vec->connector;
> struct drm_connector_state *conn_state =
> drm_atomic_get_new_connector_state(state, connector);
> - const struct vc4_vec_tv_mode *tv_mode =
> - &vc4_vec_tv_modes[conn_state->tv.legacy_mode];
> + const struct vc4_vec_tv_mode *tv_mode;
> int idx, ret;
>
> if (!drm_dev_enter(drm, &idx))
> return;
>
> + tv_mode = vc4_vec_tv_mode_lookup(conn_state->tv.mode);
> + if (!tv_mode)
> + goto err_dev_exit;
> +
> ret = pm_runtime_get_sync(&vec->pdev->dev);
> if (ret < 0) {
> DRM_ERROR("Failed to retain power domain: %d\n", ret);
If this (!tv_mode) condition is somehow triggered, the power management goes
somewhat crazy. vc4_vec_encoder_enable() cannot return an error, so when
vc4_vec_encoder_disable() is eventually called after a failed enable, it hangs
in pm_runtime_put() for quite a bit.
At least I think that's what's happening. Anyway, to solve this, I'd propose
this thing below:
Best regards,
Mateusz Kwiatkowski
