All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Imre Deak <imre.deak@intel.com>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/7] drm/i915: Allocate power domain set wakerefs dynamically
Date: Wed, 02 Nov 2022 20:57:21 +0200	[thread overview]
Message-ID: <878rktchgu.fsf@intel.com> (raw)
In-Reply-To: <20221102171530.3261282-2-imre.deak@intel.com>

On Wed, 02 Nov 2022, Imre Deak <imre.deak@intel.com> wrote:
> Since the intel_display_power_domain_set struct, currently its current
> size close 1kB, can be allocated on the stack, it's better to allocate
> the per-domain wakeref pointer array - used for debugging - within the
> struct dynamically, so do this.
>
> The memory freeing is guaranteed by the fact that the acquired domain
> references tracked by struct can't be leaked either.
>
> Signed-off-by: Imre Deak <imre.deak@intel.com>
> ---
>  .../drm/i915/display/intel_display_power.c    | 61 ++++++++++++++++---
>  .../drm/i915/display/intel_display_power.h    |  2 +-
>  2 files changed, 53 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 4c1de91e56ff9..e2da91c2a9638 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -830,19 +830,58 @@ void intel_display_power_put_unchecked(struct drm_i915_private *dev_priv,
>  }
>  #endif
>  
> +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> +static intel_wakeref_t *
> +get_debug_wakerefs(struct drm_i915_private *i915,
> +		   struct intel_display_power_domain_set *power_domain_set)
> +{
> +	if (power_domain_set->wakerefs)
> +		return power_domain_set->wakerefs;
> +
> +	power_domain_set->wakerefs = kcalloc(POWER_DOMAIN_NUM,
> +					     sizeof(*power_domain_set->wakerefs),
> +					     GFP_KERNEL);
> +
> +	drm_WARN_ON_ONCE(&i915->drm, !power_domain_set->wakerefs);

The rule of thumb is not to warn or log on allocation failures.

> +
> +	return power_domain_set->wakerefs;
> +}
> +
> +static void
> +free_empty_debug_wakerefs(struct intel_display_power_domain_set *power_domain_set)
> +{
> +	if (power_domain_set->wakerefs &&
> +	    bitmap_empty(power_domain_set->mask.bits, POWER_DOMAIN_NUM))
> +		kfree(fetch_and_zero(&power_domain_set->wakerefs));

FWIW, I'm really not happy about fetch_and_zero() or its use anywhere. I
kind of get the point, but the impression of any kind of atomicity the
naming gives is totally misleading. And it's our own thing in
i915_utils.h, and not a global thing like the name suggests.

> +}
> +#else
> +static intel_wakeref_t *
> +get_debug_wakerefs(struct drm_i915_private *i915,
> +		   struct intel_display_power_domain_set *power_domain_set)
> +{
> +	return NULL;
> +}
> +
> +static void
> +free_empty_debug_wakerefs(struct intel_display_power_domain_set *power_domain_set)
> +{
> +}
> +#endif

get/free is an odd pairing of names.

> +
>  void
>  intel_display_power_get_in_set(struct drm_i915_private *i915,
>  			       struct intel_display_power_domain_set *power_domain_set,
>  			       enum intel_display_power_domain domain)
>  {
>  	intel_wakeref_t __maybe_unused wf;
> +	intel_wakeref_t *debug_wakerefs = get_debug_wakerefs(i915, power_domain_set);
>  
>  	drm_WARN_ON(&i915->drm, test_bit(domain, power_domain_set->mask.bits));
>  
>  	wf = intel_display_power_get(i915, domain);
> -#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> -	power_domain_set->wakerefs[domain] = wf;
> -#endif
> +	if (debug_wakerefs)
> +		debug_wakerefs[domain] = wf;
> +

If you abstracted setting the debug wakeref for a domain, it could
handle the allocation internally without any of the local vars etc.
here. And it would only be a single line in the entire function.

>  	set_bit(domain, power_domain_set->mask.bits);
>  }
>  
> @@ -852,6 +891,7 @@ intel_display_power_get_in_set_if_enabled(struct drm_i915_private *i915,
>  					  enum intel_display_power_domain domain)
>  {
>  	intel_wakeref_t wf;
> +	intel_wakeref_t *debug_wakerefs = get_debug_wakerefs(i915, power_domain_set);
>  
>  	drm_WARN_ON(&i915->drm, test_bit(domain, power_domain_set->mask.bits));
>  
> @@ -859,9 +899,9 @@ intel_display_power_get_in_set_if_enabled(struct drm_i915_private *i915,
>  	if (!wf)
>  		return false;
>  
> -#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> -	power_domain_set->wakerefs[domain] = wf;
> -#endif
> +	if (debug_wakerefs)
> +		debug_wakerefs[domain] = wf;
> +
>  	set_bit(domain, power_domain_set->mask.bits);
>  
>  	return true;
> @@ -873,6 +913,7 @@ intel_display_power_put_mask_in_set(struct drm_i915_private *i915,
>  				    struct intel_power_domain_mask *mask)
>  {
>  	enum intel_display_power_domain domain;
> +	intel_wakeref_t *debug_wakerefs = get_debug_wakerefs(i915, power_domain_set);
>  
>  	drm_WARN_ON(&i915->drm,
>  		    !bitmap_subset(mask->bits, power_domain_set->mask.bits, POWER_DOMAIN_NUM));
> @@ -880,12 +921,14 @@ intel_display_power_put_mask_in_set(struct drm_i915_private *i915,
>  	for_each_power_domain(domain, mask) {
>  		intel_wakeref_t __maybe_unused wf = -1;
>  
> -#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
> -		wf = fetch_and_zero(&power_domain_set->wakerefs[domain]);
> -#endif
> +		if (debug_wakerefs)
> +			wf = fetch_and_zero(&debug_wakerefs[domain]);
> +
>  		intel_display_power_put(i915, domain, wf);
>  		clear_bit(domain, power_domain_set->mask.bits);
>  	}
> +
> +	free_empty_debug_wakerefs(power_domain_set);
>  }
>  
>  static int
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h b/drivers/gpu/drm/i915/display/intel_display_power.h
> index 7136ea3f233e9..c847aab7b2f88 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> @@ -146,7 +146,7 @@ struct i915_power_domains {
>  struct intel_display_power_domain_set {
>  	struct intel_power_domain_mask mask;
>  #ifdef CONFIG_DRM_I915_DEBUG_RUNTIME_PM
> -	intel_wakeref_t wakerefs[POWER_DOMAIN_NUM];
> +	intel_wakeref_t *wakerefs;
>  #endif
>  };

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2022-11-02 18:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-02 17:15 [Intel-gfx] [PATCH 0/7] drm/i915/tgl+: Enable DC power states on all eDP ports Imre Deak
2022-11-02 17:15 ` [Intel-gfx] [PATCH 1/7] drm/i915: Allocate power domain set wakerefs dynamically Imre Deak
2022-11-02 18:57   ` Jani Nikula [this message]
2022-11-03 11:53     ` Imre Deak
2022-11-02 17:15 ` [Intel-gfx] [PATCH 2/7] drm/i915: Move the POWER_DOMAIN_AUX_IO_A definition to its logical place Imre Deak
2022-11-02 17:15 ` [Intel-gfx] [PATCH 3/7] drm/i915/tgl+: Enable display DC power states on all eDP ports Imre Deak
2022-11-02 17:35   ` Ville Syrjälä
2022-11-02 18:34     ` Imre Deak
2022-11-02 19:07       ` Ville Syrjälä
2022-11-03  8:08         ` Imre Deak
2022-11-02 17:15 ` [Intel-gfx] [PATCH 4/7] drm/i915: Add missing AUX_IO_A power domain->well mappings Imre Deak
2022-11-02 17:15 ` [Intel-gfx] [PATCH 5/7] drm/i915: Add missing DC_OFF " Imre Deak
2022-11-02 17:15 ` [Intel-gfx] [PATCH 6/7] drm/i915: Factor out function to get/put AUX_IO power for main link Imre Deak
2022-11-02 19:02   ` Jani Nikula
2022-11-03 11:54     ` Imre Deak
2022-11-02 17:15 ` [Intel-gfx] [PATCH 7/7] drm/i915/mtl+: Don't enable the AUX_IO power for non-eDP port main links Imre Deak
2022-11-02 19:32 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tgl+: Enable DC power states on all eDP ports Patchwork
2022-11-02 19:33 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-11-02 19:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-11-03  2:02 ` [Intel-gfx] ✗ Fi.CI.IGT: 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=878rktchgu.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.