All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Ville Syrjala <ville.syrjala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Clean up HDMI deep color handling a bit
Date: Tue, 27 Aug 2019 12:30:52 +0300	[thread overview]
Message-ID: <87woez7y5v.fsf@intel.com> (raw)
In-Reply-To: <20190822180500.26608-1-ville.syrjala@linux.intel.com>

On Thu, 22 Aug 2019, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Reogranize the HDMI deep color state computation to just
> loop over possible bpc values. Avoids having to maintain
> so many variants of the clock etc.
>
> The current code also looks confused w.r.t. port_clock vs.
> bw_constrained. It would happily update port_clock for
> deep color but then not actually enable deep color due to
> bw_constrained being set. The new logic handles that case
> correctly.

Care to elaborate on that please?

Some nitpicking below.

>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 82 ++++++++++-------------
>  1 file changed, 37 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index e02f0faecf02..ed1a7afc1ffd 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2262,8 +2262,7 @@ static bool hdmi_deep_color_possible(const struct intel_crtc_state *crtc_state,
>  static bool
>  intel_hdmi_ycbcr420_config(struct drm_connector *connector,
>  			   struct intel_crtc_state *config,
> -			   int *clock_12bpc, int *clock_10bpc,
> -			   int *clock_8bpc)
> +			   int *clock)
>  {
>  	struct intel_crtc *intel_crtc = to_intel_crtc(config->base.crtc);
>  
> @@ -2273,10 +2272,7 @@ intel_hdmi_ycbcr420_config(struct drm_connector *connector,
>  	}
>  
>  	/* YCBCR420 TMDS rate requirement is half the pixel clock */
> -	config->port_clock /= 2;
> -	*clock_12bpc /= 2;
> -	*clock_10bpc /= 2;
> -	*clock_8bpc /= 2;
> +	*clock /= 2;
>  	config->output_format = INTEL_OUTPUT_FORMAT_YCBCR420;
>  
>  	/* YCBCR 420 output conversion needs a scaler */
> @@ -2302,10 +2298,7 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder,
>  	struct drm_scdc *scdc = &connector->display_info.hdmi.scdc;
>  	struct intel_digital_connector_state *intel_conn_state =
>  		to_intel_digital_connector_state(conn_state);
> -	int clock_8bpc = pipe_config->base.adjusted_mode.crtc_clock;
> -	int clock_10bpc = clock_8bpc * 5 / 4;
> -	int clock_12bpc = clock_8bpc * 3 / 2;
> -	int desired_bpp;
> +	int bpc, clock = pipe_config->base.adjusted_mode.crtc_clock;
>  	bool force_dvi = intel_conn_state->force_audio == HDMI_AUDIO_OFF_DVI;
>  
>  	if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
> @@ -2330,15 +2323,11 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder,
>  
>  	if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK) {
>  		pipe_config->pixel_multiplier = 2;
> -		clock_8bpc *= 2;
> -		clock_10bpc *= 2;
> -		clock_12bpc *= 2;
> +		clock *= 2;
>  	}
>  
>  	if (drm_mode_is_420_only(&connector->display_info, adjusted_mode)) {
> -		if (!intel_hdmi_ycbcr420_config(connector, pipe_config,
> -						&clock_12bpc, &clock_10bpc,
> -						&clock_8bpc)) {
> +		if (!intel_hdmi_ycbcr420_config(connector, pipe_config, &clock)) {
>  			DRM_ERROR("Can't support YCBCR420 output\n");
>  			return -EINVAL;
>  		}
> @@ -2355,41 +2344,44 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder,
>  				intel_conn_state->force_audio == HDMI_AUDIO_ON;
>  	}
>  
> -	/*
> -	 * Note that g4x/vlv don't support 12bpc hdmi outputs. We also need
> -	 * to check that the higher clock still fits within limits.
> -	 */
> -	if (hdmi_deep_color_possible(pipe_config, 12) &&
> -	    hdmi_port_clock_valid(intel_hdmi, clock_12bpc,
> -				  true, force_dvi) == MODE_OK) {
> -		DRM_DEBUG_KMS("picking bpc to 12 for HDMI output\n");
> -		desired_bpp = 12*3;
> -
> -		/* Need to adjust the port link by 1.5x for 12bpc. */
> -		pipe_config->port_clock = clock_12bpc;
> -	} else if (hdmi_deep_color_possible(pipe_config, 10) &&
> -		   hdmi_port_clock_valid(intel_hdmi, clock_10bpc,
> -					 true, force_dvi) == MODE_OK) {
> -		DRM_DEBUG_KMS("picking bpc to 10 for HDMI output\n");
> -		desired_bpp = 10 * 3;
> -
> -		/* Need to adjust the port link by 1.25x for 10bpc. */
> -		pipe_config->port_clock = clock_10bpc;
> -	} else {
> -		DRM_DEBUG_KMS("picking bpc to 8 for HDMI output\n");
> -		desired_bpp = 8*3;
> +	/* for 8bpc */
> +	pipe_config->port_clock = clock;
>  
> -		pipe_config->port_clock = clock_8bpc;
> -	}
> +	for (bpc = 12; bpc > 8; bpc -= 2) {

So I generally don't like loops like this. You enter the loop with 12
and 10, don't enter with 8 but assume in later code that's what you got
if not 12 or 10. And, of course, you need to initialize
pipe_config->port_clock beforehand for that case too.

Perhaps abstracting the loop to a function would help.

Now, I think this is still an improvement on the status quo, so up to
you whether to do that now or later.

> +		int port_clock;
> +
> +		if (!hdmi_deep_color_possible(pipe_config, bpc))
> +			continue;
> +
> +		/*
> +		 * Need to adjust the port link by:
> +		 *  1.5x for 12bpc
> +		 *  1.25x for 10bpc
> +		 */
> +		port_clock = clock * bpc / 8;
> +
> +		if (hdmi_port_clock_valid(intel_hdmi, port_clock,
> +					  true, force_dvi) != MODE_OK)
> +			continue;
>  
> -	if (!pipe_config->bw_constrained) {
> -		DRM_DEBUG_KMS("forcing pipe bpp to %i for HDMI\n", desired_bpp);
> -		pipe_config->pipe_bpp = desired_bpp;
> +		pipe_config->port_clock = port_clock;
> +		break;
>  	}
>  
> +	/*
> +	 * pipe_bpp could already be below 8bpc due to
> +	 * FDI bandwidth constraints. We shouldn't bump it
> +	 * back up to 8bpc in that case.
> +	 */
> +	if (pipe_config->pipe_bpp > bpc * 3)
> +		pipe_config->pipe_bpp = bpc * 3;
> +	DRM_DEBUG_KMS("picking %dbpc for HDMI output (pipe bpp: %d)\n",
                                 ^

Put a space there?

Regardless of the nitpicks,

Reviewed-by: Jani Nikula <jani.nikula@intel.com>



> +		      bpc, pipe_config->pipe_bpp);
> +
>  	if (hdmi_port_clock_valid(intel_hdmi, pipe_config->port_clock,
>  				  false, force_dvi) != MODE_OK) {
> -		DRM_DEBUG_KMS("unsupported HDMI clock, rejecting mode\n");
> +		DRM_DEBUG_KMS("unsupported HDMI clock (%d kHz), rejecting mode\n",
> +			      pipe_config->port_clock);
>  		return -EINVAL;
>  	}

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2019-08-27  9:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-22 18:05 [PATCH] drm/i915: Clean up HDMI deep color handling a bit Ville Syrjala
2019-08-23 11:20 ` ✓ Fi.CI.BAT: success for " Patchwork
2019-08-24  5:51 ` ✓ Fi.CI.IGT: " Patchwork
2019-08-27  9:30 ` Jani Nikula [this message]
2019-08-28 17:38   ` [PATCH] " Ville Syrjälä
2019-08-28 18:34 ` [PATCH v2] " Ville Syrjala
2019-09-02  7:39   ` Jani Nikula
2019-08-29 10:30 ` ✓ Fi.CI.BAT: success for drm/i915: Clean up HDMI deep color handling a bit (rev2) Patchwork
2019-08-29 20:16 ` ✓ Fi.CI.IGT: " Patchwork

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=87woez7y5v.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.