All of lore.kernel.org
 help / color / mirror / Atom feed
From: Imre Deak <imre.deak@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>, Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: get runtime PM reference around GEM set_caching IOCTL
Date: Wed, 18 Nov 2015 00:49:13 +0200	[thread overview]
Message-ID: <1447800553.14373.10.camel@intel.com> (raw)
In-Reply-To: <20151117223832.GA23086@nuc-i3427.alporthouse.com>

On Tue, 2015-11-17 at 22:38 +0000, Chris Wilson wrote:
> On Tue, Nov 17, 2015 at 11:16:09PM +0100, Daniel Vetter wrote:
> > On Thu, Nov 5, 2015 at 12:56 PM, Chris Wilson <chris@chris-wilson.c
> > o.uk> wrote:
> > > The tricky part is reviewing the i915_gem_release_mmap() callers
> > > to
> > > ensure that they have the right barrier. If you make
> > > i915_gem_release_mmap() assert it holds an rpm ref, and then make
> > > the
> > > i915_gem_release_all_mmaps() unlink the node directly that should
> > > do the
> > > trick.
> > 
> > I think the easier solution would be to add a mutex for the
> > fault_list. We call release_mmap from a lot of places,
> 
> We don't though. The only times we do are when we touching hw
> registers
> (or gsm):
> 
> set_tiling_ioctl - which also may unbind and so needs rpm
> fence_write - which needs rpm to write the reigsters
> vma_unbind - which needs rpm to write through the gsm
> set_caching - which needs rpm to write through the gsm
> 
> and currently by rpm itself.
> 
> I think it is certainly reasonable to use the rpm barriers for the
> faulted list. The only one where we have to actually ensure we hold
> rpm
> is the set_tiling_ioctl.

Btw, since this would be a bigger change shouldn't we first add the new
RPM wakelock asserts? That's mostly reviewed already anyway, I still
have to check the RPS work which would need the same handling as the
hang check work (Chris' idea to use rpm_try_get there).

So how about the following until that, which is the correct way in any
case imo:

 void __suspend_report_result(const char *function, void *fn, int ret)
 {
-       if (ret)
+       if (ret == -EBUSY || ret == -EAGAIN)
+               printk(KERN_DEBUG "%s(): %pF returns %d\n", function, fn, ret);
+       else if (ret)
                printk(KERN_ERR "%s(): %pF returns %d\n", function, fn, ret);
 }


--Imre

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

      reply	other threads:[~2015-11-17 22:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-04 19:25 [PATCH] drm/i915: get runtime PM reference around GEM set_caching IOCTL Imre Deak
2015-11-04 19:47 ` Paulo Zanoni
2015-11-16 13:33   ` Jani Nikula
2015-11-17 19:00   ` Daniel Vetter
2015-11-17 19:22     ` Imre Deak
2015-11-04 20:57 ` Chris Wilson
2015-11-05 11:28   ` Imre Deak
2015-11-05 11:56     ` Chris Wilson
2015-11-05 22:57       ` Imre Deak
2015-11-05 23:24         ` Imre Deak
2015-11-06  8:54         ` Chris Wilson
2015-11-09 13:09           ` Imre Deak
2015-11-09 13:25             ` Chris Wilson
2015-11-09 13:36               ` Imre Deak
2015-11-09 13:43                 ` Chris Wilson
2015-11-17 22:16       ` Daniel Vetter
2015-11-17 22:38         ` Chris Wilson
2015-11-17 22:49           ` Imre Deak [this message]

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=1447800553.14373.10.camel@intel.com \
    --to=imre.deak@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    /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.