[Intel-gfx] [PATCH 1/2] drm/i915: Refactor common ringbuffer allocation code

[chris at chris-wilson.co.uk]

On Thu, Sep 03, 2015 at 02:01:51PM +0000, Zanoni, Paulo R wrote:
> Em Qui, 2015-09-03 às 13:01 +0100, Chris Wilson escreveu:
> > A small, very small, step to sharing the duplicate code between
> > execlists and legacy submission engines, starting with the ringbuffer
> > allocation code.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Arun Siluvery <arun.siluvery at linux.intel.com>
> > Cc: Mika Kuoppala <mika.kuoppala at intel.com>
> > Cc: Dave Gordon <david.s.gordon at intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_lrc.c        | 49 +++++-------------
> >  drivers/gpu/drm/i915/intel_ringbuffer.c | 89 ++++++++++++++++++++---
> > ----------
> >  drivers/gpu/drm/i915/intel_ringbuffer.h |  8 +--
> >  3 files changed, 70 insertions(+), 76 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 40cbba4ea4ba..28a712e7d2d0 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -2340,8 +2340,7 @@ void intel_lr_context_free(struct intel_context 
> > *ctx)
> >  				i915_gem_object_ggtt_unpin(ctx_obj);
> >  			}
> >  			WARN_ON(ctx->engine[ring->id].pin_count);
> > -			intel_destroy_ringbuffer_obj(ringbuf);
> > -			kfree(ringbuf);
> > +			intel_ringbuffer_free(ringbuf);
> >  			drm_gem_object_unreference(&ctx_obj->base);
> >  		}
> >  	}
> > @@ -2442,42 +2441,20 @@ int intel_lr_context_deferred_create(struct 
> > intel_context *ctx,
> >  			I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
> >  	}
> >  
> > -	ringbuf = kzalloc(sizeof(*ringbuf), GFP_KERNEL);
> > -	if (!ringbuf) {
> > -		DRM_DEBUG_DRIVER("Failed to allocate ringbuffer 
> > %s\n",
> 
> We got rid of this message, but I suppose it's not a problem, since it
> was not a loud error message.

I additionally added these to patch 2. I removed the ones in intel_lrc
that were simply repeating the error message (albeit in a more generic
fashion due to loss of information). At this level an oom squalk
followed by ENOMEM reported to userspace is fairly obvious (and
definitely not our error).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre