All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: <intel-gfx@lists.freedesktop.org>,
	<intel-xe@lists.freedesktop.org>, <imre.deak@intel.com>,
	<ville.syrjala@linux.intel.com>
Subject: Re: [PATCH 4/6] drm/i915/display: convert to display runtime PM interfaces
Date: Wed, 12 Mar 2025 15:57:32 -0400	[thread overview]
Message-ID: <Z9HnLPyGAtz6Z0G6@intel.com> (raw)
In-Reply-To: <87msdqfs0x.fsf@intel.com>

On Wed, Mar 12, 2025 at 12:43:42PM +0200, Jani Nikula wrote:
> On Tue, 11 Mar 2025, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
> > On Tue, Mar 11, 2025 at 02:05:38PM +0200, Jani Nikula wrote:
> >> -	wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> >> -	is_enabled = intel_display_power_well_is_enabled(display,
> >> -							 power_well_id);
> >> -	intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> >> +	with_intel_display_rpm(display)
> >> +		is_enabled = intel_display_power_well_is_enabled(display,
> >> +								 power_well_id);
> >>  
> >
> > looking this here... I really dislike the 'with_' macro...
> > I really prefer the explicit get and put, even with the ref_tracker
> > declaration.
> 
> We might consider defining our own guard classes for runtime PM and
> other things, and use scoped_guard() and guard() with them.
> 
> Something like:
> 
> DEFINE_GUARD(display_rpm, struct intel_display *, intel_display_rpm_get(_T), intel_display_rpm_put(_T))
> 
> And the above code would become:
> 
> 	scoped_guard(display_rpm, display) {
> 		// ...
> 	}
> 
> which is already gaining a lot of traction in kernel:
> 
> $ git grep scoped_guard | wc -l
> 527
> 
> It's still magic, but at least it's kernel common magic, not our own.

Indeed.
I mean, I'm still not in love with the idea of the scope_guard thing, but
at least it is a true kernel thing and getting more traction lately.

Well, in some sense we could also compare them with the for_each, since
they are "imported" concepts of python, rust and other languages right?!

For some reason I like the for_each :)

> 
> Additionally, you could use:
> 
> 	guard(display_rpm)(display);
> 
> which automatically releases the reference when going out of scope.
> 
> I'm not quite sure how to plug that into the ref_tracker, though, so
> need to give it some more thought.

yeap, one possibility is to try to slowly get rid of the ref_tracker? ;)

> 
> I sent an RFC about using guard() and scoped_guard() for HDCP mutexes
> [1] to demonstrate this with the pre-defined mutex guard class.
> 
> [1] https://lore.kernel.org/r/20250224101428.204519-1-jani.nikula@intel.com
> 
> > But well, not a blocker:
> >
> > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> 
> Thanks,
> Jani.
> 
> 
> -- 
> Jani Nikula, Intel

  reply	other threads:[~2025-03-12 19:57 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-11 12:05 [PATCH 0/6] drm/i915/display: add display specific runtime PM interface Jani Nikula
2025-03-11 12:05 ` [PATCH 1/6] drm/i915/display: add display specific runtime PM wrappers Jani Nikula
2025-03-11 20:36   ` Rodrigo Vivi
2025-03-11 12:05 ` [PATCH 2/6] drm/i915/display: conversions to with_intel_display_rpm() Jani Nikula
2025-03-11 20:36   ` Rodrigo Vivi
2025-03-11 12:05 ` [PATCH 3/6] drm/i915/display: use display runtime PM interfaces for for atomic state Jani Nikula
2025-03-11 20:39   ` Rodrigo Vivi
2025-03-11 12:05 ` [PATCH 4/6] drm/i915/display: convert to display runtime PM interfaces Jani Nikula
2025-03-11 20:43   ` Rodrigo Vivi
2025-03-12 10:43     ` Jani Nikula
2025-03-12 19:57       ` Rodrigo Vivi [this message]
2025-03-11 12:05 ` [PATCH 5/6] drm/i915/power: " Jani Nikula
2025-03-11 20:45   ` Rodrigo Vivi
2025-03-11 12:05 ` [PATCH 6/6] drm/xe/compat: remove intel_runtime_pm.h Jani Nikula
2025-03-11 20:46   ` Rodrigo Vivi
2025-03-11 14:31 ` ✓ CI.Patch_applied: success for drm/i915/display: add display specific runtime PM interface Patchwork
2025-03-11 14:32 ` ✗ CI.checkpatch: warning " Patchwork
2025-03-11 14:33 ` ✓ CI.KUnit: success " Patchwork
2025-03-11 14:49 ` ✓ CI.Build: " Patchwork
2025-03-11 14:52 ` ✓ CI.Hooks: " Patchwork
2025-03-11 14:53 ` ✗ CI.checksparse: warning " Patchwork
2025-03-11 15:15 ` ✓ Xe.CI.BAT: success " Patchwork
2025-03-11 16:32 ` ✗ Fi.CI.CHECKPATCH: warning " Patchwork
2025-03-11 16:32 ` ✗ Fi.CI.SPARSE: " Patchwork
2025-03-11 16:58 ` ✗ i915.CI.BAT: failure " Patchwork
2025-03-12  7:16 ` ✓ Xe.CI.Full: success " Patchwork
2025-03-13 11:04 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: add display specific runtime PM interface (rev2) Patchwork
2025-03-13 11:04 ` ✗ Fi.CI.SPARSE: " Patchwork
2025-03-13 11:27 ` ✓ i915.CI.BAT: success " 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=Z9HnLPyGAtz6Z0G6@intel.com \
    --to=rodrigo.vivi@intel.com \
    --cc=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --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.