public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: Dave Gordon <david.s.gordon@intel.com>
To: ankitprasad.r.sharma@intel.com, intel-gfx@lists.freedesktop.org
Cc: akash.goel@intel.com
Subject: Re: [PATCH] drm/i915: Remove redundant get_pages call
Date: Tue, 1 Dec 2015 18:11:16 +0000	[thread overview]
Message-ID: <565DE2C4.3030005@intel.com> (raw)
In-Reply-To: <1446034116-15107-1-git-send-email-ankitprasad.r.sharma@intel.com>

On 28/10/15 12:08, ankitprasad.r.sharma@intel.com wrote:
> From: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
>
> A call to i915_gem_obj_ggtt_pin is being made after this, which again
> calls the get_pages function. Hence removing the redundant call to
> get_pages.
>
> Signed-off-by: Ankitprasad Sharma <ankitprasad.r.sharma@intel.com>
> ---
>   drivers/gpu/drm/i915/i915_guc_submission.c | 5 -----
>   1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 792d0b9..30237e2 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -649,11 +649,6 @@ static struct drm_i915_gem_object *gem_allocate_guc_obj(struct drm_device *dev,
>   	if (!obj)
>   		return NULL;
>
> -	if (i915_gem_object_get_pages(obj)) {
> -		drm_gem_object_unreference(&obj->base);
> -		return NULL;
> -	}
> -
>   	if (i915_gem_obj_ggtt_pin(obj, PAGE_SIZE,
>   			PIN_OFFSET_BIAS | GUC_WOPCM_TOP)) {
>   		drm_gem_object_unreference(&obj->base);

I suppose it is technically redundant, but it's actually quite difficult 
to verify that the call to i915_gem_obj_ggtt_pin() *will* actually take 
the path that, *six levels deeper*, includes the call to 
i915_gem_object_get_pages().

Is there any advantage to calling i915_gem_object_get_pages() later (or 
later)? Does it improve/worsen the chances of hitting a failure path? 
Handling an error from get_pages here is simple, whereas it looks like 
backing out of a failure in the middle of (six levels of) ggtt_pin might 
not be?

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

  reply	other threads:[~2015-12-01 18:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-28 12:08 [PATCH] drm/i915: Remove redundant get_pages call ankitprasad.r.sharma
2015-12-01 18:11 ` Dave Gordon [this message]
2015-12-03  7:47   ` 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=565DE2C4.3030005@intel.com \
    --to=david.s.gordon@intel.com \
    --cc=akash.goel@intel.com \
    --cc=ankitprasad.r.sharma@intel.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox