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
next prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox