public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: "Golani, Mitulkumar Ajitkumar" <mitulkumar.ajitkumar.golani@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Fix warning callstack for imbalance wakeref
Date: Thu, 25 Aug 2022 13:51:50 +0300	[thread overview]
Message-ID: <YwdURvTR2xakrFK0@ideak-desk.fi.intel.com> (raw)
In-Reply-To: <MWHPR11MB193572EF5A173CC9F42861DDB2709@MWHPR11MB1935.namprd11.prod.outlook.com>

On Tue, Aug 23, 2022 at 03:56:56PM +0300, Golani, Mitulkumar Ajitkumar wrote:
> > Hi Imre,
> >
> > > On Fri, Aug 12, 2022 at 10:17:24AM +0530, Mitul Golani wrote:
> > > > While executing i915_selftest, wakeref imbalance warning is seen
> > > > with i915_selftest failure.
> > > >
> > > > When device is already suspended, wakeref is acquired by
> > > > disable_rpm_wakeref_asserts and rpm ownership is transferred back to
> > > > core. During this case wakeref_count will not be zero.
> > > > Once driver is unregistered, this wakeref is released with
> > > > enable_rpm_wakeref_asserts and balancing wakeref_count acquired by
> > > > driver.
> > > >
> > > > This patch will fix the warning callstack by adding check if device
> > > > is already suspended and rpm ownership transfer is going on.
> > > >
> > > > Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_driver.c | 8 +++++++-
> > > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > > > b/drivers/gpu/drm/i915/i915_driver.c
> > > > index deb8a8b76965..6530a8680cfd 100644
> > > > --- a/drivers/gpu/drm/i915/i915_driver.c
> > > > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > > > @@ -1670,7 +1670,13 @@ static int intel_runtime_resume(struct device
> > > > *kdev)
> > > >
> > > >   drm_dbg(&dev_priv->drm, "Resuming device\n");
> > > >
> > > > - drm_WARN_ON_ONCE(&dev_priv->drm, atomic_read(&rpm-
> > > >wakeref_count));
> > > > + /*
> > > > +  * When device is already suspended, Wakeref is acquired by
> > > disable_rpm_wakeref_asserts
> > > > +  * and rpm ownership is transferred back to core. During this case
> > > wakeref_count will
> > > > +  * not be zero. Once driver is unregistered, this wakeref is
> > > > +released
> > > with
> > > > +  * enable_rpm_wakeref_asserts and balancing wakeref_count
> > > acquired by driver.
> > > > +  */
> > > > + drm_WARN_ON_ONCE(&dev_priv->drm, atomic_read(&rpm-
> > > >wakeref_count) &&
> > > > +!rpm->suspended);
> > >
> > > I can't see how disable/enable_rpm_wakeref_asserts() can lead to this
> > > WARN. They are always called in pairs both in intel_runtime_suspend()
> > > and intel_runtime_resume(), leaving rpm->wakeref_count unchanged.
> > >
> > > The root cause is probably somewhere else, incrementing
> > > rpm->wakeref_count without runtime resuming the device.
> > >
> > > The WARN() condition is corret, we shouldn't get here with a non-zero
> > > wakeref_count. rpm->suspended - set in intel_runtime_suspend() and
> > > cleared in intel_runtime_resume() - should be always false here, so
> > > the above change would just disable the WARN in all cases.
> > >
> > Yes, in case of DG2, after device is suspended, i915_driver_remove
> > is being called.  Here driver is taking wakeref with
> > disable_rpm_wakeref_asserts when device was not resumed.

> >
> > As per logs,
> > [  395.872971] i915 0000:03:00.0: [drm:intel_runtime_suspend [i915]]
> > Suspending device ...
> > [  403.553235] i915_driver_remove: START wakeref=0 [  403.553288]
> > i915_driver_remove: before unregister i915 wakeref=65537 (Wakeref Taken)
> > [  403.566086] i915 0000:03:00.0: [drm:intel_runtime_resume [i915]]
> > Resuming device (Later Resuming Device)
> >
> > Pushed new change with :
> > https://patchwork.freedesktop.org/series/107211/#rev5
> >
> Also when compared DG2 logs with ADLP working logs,
> Already 1 wakeref was taken by DMC firmware(i915/adlp_dmc_ver2_16.bin (v2.16)), in-case of DG2 looks to be missing.
> To support other targets and to prevent consecutive resuming device added following check,
> if (i915->runtime_pm.suspended && !atomic_read(&i915->runtime_pm.wakeref_count))
> 
> ADLP Logs:
> ---------------
> [   99.502434] i915_driver_probe: START wakeref=0
> [  713.979074] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/adlp_dmc_ver2_16.bin (v2.16)
> [  102.455766] i915_driver_probe: END wakeref=65538
> ...
> [  103.448570] i915_driver_remove: START wakeref=65537
> [  103.448587] i915_driver_remove: before unregister i915 wakeref=131074 -> (disable_rpm_wakeref_assert)
> [  103.585886] i915_driver_remove: END wakeref=0
> 
> DG2 Logs:
> -------------
> [ 1271.704314] i915_driver_probe: START wakeref=0
> [  383.050984] i915 0000:03:00.0: [drm] Finished loading DMC firmware i915/dg2_dmc_ver2_07.bin (v2.7)
> [ 1272.021133] i915_driver_probe: END wakeref=1
> ...
> [  395.883531] i915 0000:03:00.0: [drm:intel_runtime_suspend [i915]] Device suspended
> ...
> [ 1291.450841] i915_driver_remove: START wakeref=0
> [ 1291.450877] i915_driver_remove: before unregister i915 wakeref=65537 -> (disable_rpm_wakeref_assert)
> [ 1291.603281] i915_driver_remove: END wakeref=0

Still not sure what's going. Both i915_pci_probe() and
i915_pci_remove()->i915_driver_remove() is called with a runtime PM
reference - taken at local_pci_probe() and pci_device_remove() - and so
the device should be runtime resumed at those points.

> > > >   disable_rpm_wakeref_asserts(rpm);
> > > >
> > > >   intel_opregion_notify_adapter(dev_priv, PCI_D0);
> > > > --
> > > > 2.25.1
> > > >

  reply	other threads:[~2022-08-25 10:52 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-12  4:47 [Intel-gfx] [PATCH] drm/i915/display: Fix warning callstack for imbalance wakeref Mitul Golani
2022-08-12 12:45 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2022-08-12 19:32 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-08-16 20:03 ` Patchwork
2022-08-16 20:47 ` [Intel-gfx] ✓ Fi.CI.IGT: success " Patchwork
2022-08-17  7:15 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix warning callstack for imbalance wakeref (rev2) Patchwork
2022-08-17  9:12 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix warning callstack for imbalance wakeref (rev3) Patchwork
2022-08-17 12:12 ` [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: Fix warning callstack for imbalance wakeref (rev2) Patchwork
2022-08-17 12:49 ` [Intel-gfx] [PATCH] drm/i915/display: Fix warning callstack for imbalance wakeref Imre Deak
2022-08-23 12:39   ` Golani, Mitulkumar Ajitkumar
2022-08-23 12:56     ` Golani, Mitulkumar Ajitkumar
2022-08-25 10:51       ` Imre Deak [this message]
2022-08-29  6:45         ` Golani, Mitulkumar Ajitkumar
2022-08-29 14:46           ` Imre Deak
2022-08-29 16:59             ` Golani, Mitulkumar Ajitkumar
2022-08-17 13:24 ` [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Fix warning callstack for imbalance wakeref (rev3) Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2022-08-23  2:35 [Intel-gfx] [PATCH] drm/i915/display: Fix warning callstack for imbalance wakeref Mitul Golani
2022-08-23 11:00 ` Jani Nikula
2022-08-23  5:20 Mitul Golani
2022-08-23 14:31 ` Jani Nikula
2022-08-29  8:31 Mitul Golani
2022-08-30  8:51 Mitul Golani
2022-08-31 11:54 ` Imre Deak
2022-08-31 15:28 ` Andrzej Hajda

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=YwdURvTR2xakrFK0@ideak-desk.fi.intel.com \
    --to=imre.deak@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mitulkumar.ajitkumar.golani@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