public inbox for igt-dev@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jeevan B <jeevan.b@intel.com>
Cc: igt-dev@lists.freedesktop.org, ankit.k.nautiyal@intel.com
Subject: Re: [PATCH i-g-t v2] tests/kms_setmode: Add HDMI 2.0 clock limit for mode selection
Date: Tue, 31 Mar 2026 16:06:19 +0300	[thread overview]
Message-ID: <acvGy0C97UmDxLg2@intel.com> (raw)
In-Reply-To: <20260331104100.614718-1-jeevan.b@intel.com>

On Tue, Mar 31, 2026 at 04:11:00PM +0530, Jeevan B wrote:
> eDP modes with high clock rates were being forced on HDMI 2.0 displays,
> causing kernel to reject with EINVAL. Add clock validation to skip
> incompatible eDP modes and fall back to supported modes.
> 
> v2: Add HDMI 2.0 clock limit helper, drop crtc_supports_mode(),
>     and ensure per-connector compatibility to avoid invalid modes.
> 
> Signed-off-by: Jeevan B <jeevan.b@intel.com>
> ---
>  tests/kms_setmode.c | 44 ++++++++++++++++++++++++++++++++++++++++++--
>  1 file changed, 42 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/kms_setmode.c b/tests/kms_setmode.c
> index 1f2849bc2..f1c1afe45 100644
> --- a/tests/kms_setmode.c
> +++ b/tests/kms_setmode.c
> @@ -79,6 +79,9 @@
>  /* restricted pipe count */
>  #define CRTC_RESTRICT_CNT 2
>  
> +/* Clock limit for HDMI 2.0 */
> +#define HDMI_2_0_MAX_CLOCK_KHZ 600000
> +
>  static int drm_fd;
>  static drmModeRes *drm_resources;
>  static int filter_test_id;
> @@ -165,6 +168,16 @@ static bool connector_supports_mode(drmModeConnector *connector,
>  	return false;
>  }
>  
> +static bool hdmi_connector_mode_exceeds_hdmi20_limit(drmModeConnector *connector,
> +						     drmModeModeInfo *mode)
> +{
> +	if (connector->connector_type != DRM_MODE_CONNECTOR_HDMIA &&
> +	    connector->connector_type != DRM_MODE_CONNECTOR_HDMIB)
> +		return false;
> +
> +	return mode->clock > HDMI_2_0_MAX_CLOCK_KHZ;

Starting to test all kinds of random thing here does not seem
maintainable.

I think the one sensible option is to make the test skip rather
than fail if it couldn't find a common mode between the connectors
and the modeset subsequently failed.

As for the external vs. internal connector situation, the test should
probably try to find a mode on the external connector(s) that has the
same refresh rate as one of the modes on the internal connector, and
has the same resolution (or less) than the internal panel. That way
we can use pfit to upscale content on the internal panel instead of
attempting to force the external connectors to use the internal
panel's native mode.

> +}
> +
>  static bool crtc_supports_mode(struct crtc_config *crtc, drmModeModeInfo *mode)
>  {
>  	int i;
> @@ -270,8 +283,35 @@ static void get_mode_for_crtc(struct crtc_config *crtc,
>  				if (conn->modes[j].clock < mode->clock)
>  					mode = &conn->modes[j];
>  			}
> -			*mode_ret = *mode;
> -			return;
> +
> +			/* Check HDMI 2.0 clock + per-connector compatibility */
> +			{
> +				int k;
> +				bool compatible = true;
> +
> +				for (k = 0; k < crtc->connector_count; k++) {
> +					drmModeConnector *other_conn =
> +						crtc->cconfs[k].connector;
> +
> +					/* HDMI 2.0 clock constraint */
> +					if (hdmi_connector_mode_exceeds_hdmi20_limit(other_conn,
> +										     mode)) {
> +						compatible = false;
> +						break;
> +					}
> +
> +					/* Ensure connector supports the mode */
> +					if (!connector_supports_mode(other_conn, mode)) {
> +						compatible = false;
> +						break;
> +					}
> +				}
> +
> +				if (compatible) {
> +					*mode_ret = *mode;
> +					return;
> +				}
> +			}
>  		}
>  	}
>  
> -- 
> 2.43.0

-- 
Ville Syrjälä
Intel

  parent reply	other threads:[~2026-03-31 13:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-31 10:41 [PATCH i-g-t v2] tests/kms_setmode: Add HDMI 2.0 clock limit for mode selection Jeevan B
2026-03-31 11:42 ` Jani Nikula
2026-03-31 13:06 ` Ville Syrjälä [this message]
2026-03-31 13:37   ` B, Jeevan
2026-03-31 13:48     ` Jani Nikula

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acvGy0C97UmDxLg2@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=ankit.k.nautiyal@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    --cc=jeevan.b@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox