All of 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 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.