intel-xe.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-xe@lists.freedesktop.org, intel-gfx@lists.freexdesktop.org,
	Matthew Auld <matthew.auld@intel.com>
Subject: Re: [PATCH 01/10] drm/i915/display: convert inner wakeref get towards get_if_in_use
Date: Thu, 7 Mar 2024 02:30:46 +0200	[thread overview]
Message-ID: <ZekKtpIobqZzyvDR@intel.com> (raw)
In-Reply-To: <20240307001554.162153-1-rodrigo.vivi@intel.com>

On Wed, Mar 06, 2024 at 07:15:45PM -0500, Rodrigo Vivi wrote:
> This patch brings no functional change. Since at this point of
> the code we are already asserting a wakeref was held, it means
> that we are with runtime_pm 'in_use' and in practical terms we
> are only bumping the pm_runtime usage counter and moving on.
> 
> However, xe driver has a lockdep annotation that warned us that
> if a sync resume was actually called at this point, we could have
> a deadlock because we are inside the power_domains->lock locked
> area and the resume would call the irq_reset, which would also
> try to get the power_domains->lock.
> 
> For this reason, let's convert this call to a safer option and
> calm lockdep on.
> 
> Cc: Matthew Auld <matthew.auld@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> ---
>  drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 6fd4fa52253a..4c5168a5bbf4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -646,7 +646,7 @@ release_async_put_domains(struct i915_power_domains *power_domains,
>  	 * power well disabling.
>  	 */
>  	assert_rpm_raw_wakeref_held(rpm);
> -	wakeref = intel_runtime_pm_get(rpm);
> +	wakeref = intel_runtime_pm_get_if_in_use(rpm);

On first glance that sequence looks like complete nonsense, and
thus likely to be cleaned up by someone later.

To me _noresume() would seem like the more sensible thing to use
here. And even that might still warrant a comment to explain
why that one is used specifically.

I'm also confused by the wakeref vs. wakelock stuff in the runtime pm
code. Is that there just because not all places track the wakerefs?
Do we still have those left?

>  
>  	for_each_power_domain(domain, mask) {
>  		/* Clear before put, so put's sanity check is happy. */
> -- 
> 2.43.2

-- 
Ville Syrjälä
Intel

  parent reply	other threads:[~2024-03-07  0:30 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-07  0:15 [PATCH 01/10] drm/i915/display: convert inner wakeref get towards get_if_in_use Rodrigo Vivi
2024-03-07  0:15 ` [PATCH 02/10] drm/xe: Move lockdep protection from mem_access to xe_pm_runtime Rodrigo Vivi
2024-03-07  0:15 ` [PATCH 03/10] drm/xe: Convert GSC HDCP from mem_access to direct xe_pm_runtime calls Rodrigo Vivi
2024-03-07  0:15 ` [PATCH 04/10] drm/xe: Remove useless mem_access during probe Rodrigo Vivi
2024-03-07  0:15 ` [PATCH 05/10] drm/xe: Convert xe_gem_fault to use direct xe_pm_runtime calls Rodrigo Vivi
2024-03-07  0:15 ` [PATCH 06/10] drm/xe: Removing extra mem_access protection from runtime pm Rodrigo Vivi
2024-03-07  0:15 ` [PATCH 07/10] drm/xe: Introduce xe_pm_runtime_get_noresume for inner callers Rodrigo Vivi
2024-03-07  0:15 ` [PATCH 08/10] drm/xe: Convert mem_access_if_ongoing to direct xe_pm_runtime_get_if_active Rodrigo Vivi
2024-03-07  0:15 ` [PATCH 09/10] drm/xe: Ensure all the inner access are using the _noresume variant Rodrigo Vivi
2024-03-07  0:15 ` [PATCH 10/10] drm/xe: Kill xe_device_mem_access_{get*,put} Rodrigo Vivi
2024-04-27  1:30   ` Dixit, Ashutosh
2024-04-29 20:12     ` Vivi, Rodrigo
2024-03-07  0:30 ` Ville Syrjälä [this message]
2024-03-07 14:46   ` [PATCH 01/10] drm/i915/display: convert inner wakeref get towards get_if_in_use Rodrigo Vivi
2024-03-07 20:14     ` Imre Deak
2024-03-08 15:19       ` Rodrigo Vivi
2024-03-11 15:06         ` Imre Deak
2024-03-11 18:36           ` Rodrigo Vivi
2024-03-15 11:16     ` Ville Syrjälä
2024-03-07  1:02 ` ✓ CI.Patch_applied: success for series starting with [01/10] " Patchwork
2024-03-07  1:02 ` ✗ CI.checkpatch: warning " Patchwork
2024-03-07  1:03 ` ✓ CI.KUnit: success " Patchwork
2024-03-07  1:14 ` ✓ CI.Build: " Patchwork
2024-03-07  1:14 ` ✗ CI.Hooks: failure " Patchwork
2024-03-07  1:16 ` ✗ CI.checksparse: warning " Patchwork
2024-03-07  1:45 ` ✗ 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=ZekKtpIobqZzyvDR@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=intel-gfx@lists.freexdesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=matthew.auld@intel.com \
    --cc=rodrigo.vivi@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;
as well as URLs for NNTP newsgroup(s).