Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Paulo Zanoni <przanoni@gmail.com>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	rjw@rjwysocki.net
Subject: Re: [PATCH] drm/i915: use correct runtime get/put calls at init/teardown
Date: Thu, 17 Sep 2015 14:59:18 -0700	[thread overview]
Message-ID: <55FB37B6.3070909@virtuousgeek.org> (raw)
In-Reply-To: <CA+gsUGRPRtObt433VS-jdU1q0Aan+7NC=xmwTwX8K=VX4tzJCQ@mail.gmail.com>

On 09/17/2015 02:40 PM, Paulo Zanoni wrote:
> 2015-09-17 18:23 GMT-03:00 Jesse Barnes <jbarnes@virtuousgeek.org>:
>> According to the PCI docs and Rafael, we need to be using
>> pm_runtime_put_noidle() and pm_runtime_get_noresume() in our init and
>> teardown routines, rather than using a direct enable/disable pair (and
>> we didn't even have the enable side, so never autosuspended after an
>> unload).
>>
>> This fixes one failure of the basic-pci-d3-state test on my BYT.  I'm
>> still debugging why the device never autosuspends.
>>
>> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
>> ---
>>  drivers/gpu/drm/i915/intel_runtime_pm.c | 5 ++---
>>  1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> index 85c35fd..1addb8a 100644
>> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
>> @@ -1822,7 +1822,7 @@ static void intel_runtime_pm_disable(struct drm_i915_private *dev_priv)
>>
>>         /* Make sure we're not suspended first. */
> 
> So is the comment above still valid?
> 
> As far as I remember, we explicitly wake up the hardware after unload
> because our driver is (was) not prepared to be loaded on a hardware
> that is suspended. Did you try module reloading after this change?

I'm still debugging it; in fact I think this change may be wrong.

> Also, basic-pci-d3-state should not be unloading/reloading the driver,
> so it's not clear to me how this change helps passing that test.

The BAT tests just happen to run the module reload test first.  That's how I caught this in the first place...

Jesse
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-09-17 21:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-17 21:23 [PATCH] drm/i915: use correct runtime get/put calls at init/teardown Jesse Barnes
2015-09-17 21:40 ` Paulo Zanoni
2015-09-17 21:59   ` Jesse Barnes [this message]
2015-09-18  1:01 ` Rafael J. Wysocki
2015-09-18  1:21   ` Rafael J. Wysocki
2015-09-23 21:37     ` [PATCH] drm/i915: fixup runtime PM handling v2 Jesse Barnes
2015-09-24 15:40       ` Jesse Barnes
2015-09-24 19:14         ` Rafael J. Wysocki
2015-09-28  8:21           ` Daniel Vetter

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=55FB37B6.3070909@virtuousgeek.org \
    --to=jbarnes@virtuousgeek.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=przanoni@gmail.com \
    --cc=rjw@rjwysocki.net \
    /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