Intel-GFX Archive on 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: [Intel-gfx] [PATCH v2 03/16] drm/i915: Extract has_double_buffered_m_n()
Date: Mon, 20 Jun 2022 12:05:42 +0300	[thread overview]
Message-ID: <87h74fu2l5.fsf@intel.com> (raw)
In-Reply-To: <20220617160510.2082-4-ville.syrjala@linux.intel.com>

On Fri, 17 Jun 2022, Ville Syrjala <ville.syrjala@linux.intel.com> wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> We have a couple of places that want to make distinction between
> double buffered M/N registers vs. the split M1/N1+M2/N2 registers.
> Add a helper for that.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

Mhh. So why a function in intel_display.c instead of a macro in
i915_drv.h? Both are kind of cluttered, but at least in i915_drv.h it
would be among others.

I do think we should have a separate file for display feature check
macros, and move most if not all of the display related HAS_*() stuff
there from i915_drv.h.

So technically this does what it says on the box, and in that sense,

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

but I don't much like the example and precedence this function sets.


> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 7 ++++++-
>  drivers/gpu/drm/i915/display/intel_display.h | 1 +
>  drivers/gpu/drm/i915/display/intel_dp.c      | 3 +--
>  3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index b24784c4522d..5559688047b3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2798,6 +2798,11 @@ static int intel_crtc_compute_config(struct intel_atomic_state *state,
>  	return 0;
>  }
>  
> +bool has_double_buffered_m_n(struct drm_i915_private *i915)
> +{
> +	return DISPLAY_VER(i915) >= 9 || IS_BROADWELL(i915);
> +}
> +
>  static void
>  intel_reduce_m_n_ratio(u32 *num, u32 *den)
>  {
> @@ -5900,7 +5905,7 @@ intel_pipe_config_compare(const struct intel_crtc_state *current_config,
>  	PIPE_CONF_CHECK_I(lane_count);
>  	PIPE_CONF_CHECK_X(lane_lat_optim_mask);
>  
> -	if (DISPLAY_VER(dev_priv) >= 9 || IS_BROADWELL(dev_priv)) {
> +	if (has_double_buffered_m_n(dev_priv)) {
>  		PIPE_CONF_CHECK_M_N_ALT(dp_m_n, dp_m2_n2);
>  	} else {
>  		PIPE_CONF_CHECK_M_N(dp_m_n);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h b/drivers/gpu/drm/i915/display/intel_display.h
> index 2feb8ae5d5d4..44c88aadfc30 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -543,6 +543,7 @@ int intel_atomic_add_affected_planes(struct intel_atomic_state *state,
>  				     struct intel_crtc *crtc);
>  u8 intel_calc_active_pipes(struct intel_atomic_state *state,
>  			   u8 active_pipes);
> +bool has_double_buffered_m_n(struct drm_i915_private *i915);
>  void intel_link_compute_m_n(u16 bpp, int nlanes,
>  			    int pixel_clock, int link_clock,
>  			    struct intel_link_m_n *m_n,
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 2fac76bcf06d..75645508080a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1842,8 +1842,7 @@ intel_dp_compute_hdr_metadata_infoframe_sdp(struct intel_dp *intel_dp,
>  static bool cpu_transcoder_has_drrs(struct drm_i915_private *i915,
>  				    enum transcoder cpu_transcoder)
>  {
> -	/* M1/N1 is double buffered */
> -	if (DISPLAY_VER(i915) >= 9 || IS_BROADWELL(i915))
> +	if (has_double_buffered_m_n(i915))
>  		return true;
>  
>  	return intel_cpu_transcoder_has_m2_n2(i915, cpu_transcoder);

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-06-20  9:05 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-17 16:04 [Intel-gfx] [PATCH v2 00/16] drm/i915: Make fastset not suck and allow seamless M/N changes Ville Syrjala
2022-06-17 16:04 ` [Intel-gfx] [PATCH v2 01/16] drm/i915: Relocate intel_crtc_dotclock() Ville Syrjala
2022-06-20  9:01   ` Jani Nikula
2022-06-17 16:04 ` [Intel-gfx] [PATCH v2 02/16] drm/i915: Shuffle some PLL code around Ville Syrjala
2022-06-20  9:01   ` Jani Nikula
2022-06-17 16:04 ` [Intel-gfx] [PATCH v2 03/16] drm/i915: Extract has_double_buffered_m_n() Ville Syrjala
2022-06-20  9:05   ` Jani Nikula [this message]
2022-06-20 17:05     ` Ville Syrjälä
2022-06-17 16:04 ` [Intel-gfx] [PATCH v2 04/16] drm/i915: Do .crtc_compute_clock() earlier Ville Syrjala
2022-06-17 16:04 ` [Intel-gfx] [PATCH v2 05/16] drm/i915: Reassign DPLLs only for crtcs going throug .compute_config() Ville Syrjala
2022-06-17 16:05 ` [Intel-gfx] [PATCH v2 06/16] drm/i915: Feed the DPLL output freq back into crtc_state Ville Syrjala
2022-06-17 16:05 ` [Intel-gfx] [PATCH v2 07/16] drm/i915: Compute clocks earlier Ville Syrjala
2022-06-17 16:05 ` [Intel-gfx] [PATCH v2 08/16] drm/i915: Make M/N checks non-fuzzy Ville Syrjala
2022-06-17 16:05 ` [Intel-gfx] [PATCH v2 09/16] drm/i915: Make all clock " Ville Syrjala
2022-06-17 16:05 ` [Intel-gfx] [PATCH v2 10/16] drm/i915: Set active dpll early for icl+ Ville Syrjala
2022-06-17 16:05 ` [Intel-gfx] [PATCH v2 11/16] drm/i915: Nuke fastet state copy hacks Ville Syrjala
2022-06-17 16:05 ` [Intel-gfx] [PATCH v2 12/16] drm/i915: Skip intel_modeset_pipe_config_late() if the pipe is not enabled Ville Syrjala
2022-06-17 16:05 ` [Intel-gfx] [PATCH v2 13/16] drm/i915: Add intel_panel_highest_mode() Ville Syrjala
2022-06-17 16:05 ` [Intel-gfx] [PATCH v2 14/16] drm/i915: Allow M/N change during fastset on bdw+ Ville Syrjala
2022-06-17 16:05 ` [Intel-gfx] [PATCH v2 15/16] drm/i915: Use a fixed N value always Ville Syrjala
2022-06-17 16:05 ` [Intel-gfx] [PATCH v2 16/16] drm/i915: Round TMDS clock to nearest Ville Syrjala
2022-06-17 19:49 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Make fastset not suck and allow seamless M/N changes (rev5) Patchwork
2022-06-17 20:10 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " 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=87h74fu2l5.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