From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Imre Deak <imre.deak@intel.com>
Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.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: Mon, 11 Mar 2024 14:36:57 -0400 [thread overview]
Message-ID: <Ze9PSQfcOpJrHx37@intel.com> (raw)
In-Reply-To: <Ze8d+ABttapojKHq@ideak-desk.fi.intel.com>
On Mon, Mar 11, 2024 at 05:06:32PM +0200, Imre Deak wrote:
> On Fri, Mar 08, 2024 at 10:19:58AM -0500, Rodrigo Vivi wrote:
> > [...]
> > >
> > > The difference between a wakeref (aka wakelock) and a raw-wakeref is
> > > that the former is required for accessing the HW, which is asserted when
> > > reading/writing a register. A raw-wakeref is not enough for this and is
> > > only taken to prevent runtime suspending, for instance held after
> > > dropping a display power reference, until the power well is actually
> > > disabled in a delayed manner. During this time any register access is
> > > considered invalid.
> >
> > ah okay, so it is not just about the GT, but also about MMIO accesses.
> > So the ones in display looks better now. Thanks for this correction.
> >
> > >
> > > Both wakerefs and raw-wakerefs are tracked.
> >
> > Indeed. And also it is worth to say that this patch doesn't introduce
> > any change on that.
> >
> > both
> > intel_runtime_pm_get()
> > and
> > intel_runtime_pm_get_if_in_use()
> >
> > calls
> > intel_runtime_pm_acquire(rpm, true);
> > return track_intel_runtime_pm_wakeref(rpm);
> >
> > so, can we move forward with this change or do you guys see any blocker?
>
> I also think intel_runtime_pm_get_noresume() would be more logical here,
> as it's already known that rpm->usecount is non-zero,
> intel_runtime_pm_get_if_in_use() also works though. Either way:
Well, I can also go with the noresume version since my plan is to merge
this through drm-xe-next anyway along with the rest of this series.
However I will need to move this to the top of the series,
because xe's noresume is introduced later. And introduce
the xe compat layer version of the intel_runtime_pm_get_noresume()
A stand alone version of this patch with the noresume would break
drm-tip build:
../drivers/gpu/drm/i915/display/intel_display_power.c: In function ‘release_async_put_domains’:
../drivers/gpu/drm/i915/display/intel_display_power.c:649:19: error: implicit declaration of function ‘intel_runtime_pm_get_noresume’; did you mean ‘intel_runtime_pm_get_if_in_use’? [-Werror=implicit-function-declaration]
649 | wakeref = intel_runtime_pm_get_noresume(rpm);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| intel_runtime_pm_get_if_in_use
make[3]: *** [../drivers/gpu/drm/xe/Makefile:185: drivers/gpu/drm/xe/i915-display/intel_display_power.o] Error 1
>
> Acked-by: Imre Deak <imre.deak@intel.com>
Thank you.
>
> > Thanks a lot,
> > Rodrigo.
> >
> > >
> > > > One thing that crossed my mind many times already is to simply entirely
> > > > remove the runtime_pm from display and do like other drivers simply
> > > > checking for crtc connection at runtime_idle.
> > > >
> > > > But then there are places where current display code uses the rpm
> > > > in use to take different code paths, and also all the possible impact
> > > > with the dc states transitions and other cases that I always gave up
> > > > on the thought very quickly.
> > > >
> > > > But you are right, we will have to comeback and clean things up
> > > > one way or another.
> > > >
> > > > But I wish we can have at least this small change in first so I don't
> > > > get blocked by xe's lockdep annotation and I also don't have to
> > > > workaround the annotation itself.
> > > >
> > > > >
> > > > > >
> > > > > > for_each_power_domain(domain, mask) {
> > > > > > /* Clear before put, so put's sanity check is happy. */
> > > > > > --
> > > > > > 2.43.2
> > > > >
> > > > > --
> > > > > Ville Syrjälä
> > > > > Intel
next prev parent reply other threads:[~2024-03-11 18:37 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 ` [PATCH 01/10] drm/i915/display: convert inner wakeref get towards get_if_in_use Ville Syrjälä
2024-03-07 14:46 ` 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 [this message]
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=Ze9PSQfcOpJrHx37@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=matthew.auld@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.