On Sat, Jan 30, 2016 at 10:56:27AM +0000, Chris Wilson wrote:
> On Fri, Jan 29, 2016 at 07:19:27PM +0000, Dave Gordon wrote:
> > 1. add call to i915_gem_context_fini() to deallocate the default
> > context(s) if the call to init_rings() fails, so that we don't
> > leak the context in that situation.
> >
> > 2. remove useless code in intel_logical_ring_cleanup(), presumably
> > copypasted from legacy ringbuffer version at creation.
> >
> > Signed-off-by: Dave Gordon <david.s.gordon@xxxxxxxxx>
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 5 ++++-
> > drivers/gpu/drm/i915/intel_lrc.c | 10 ++--------
> > 2 files changed, 6 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index a928823..5a4d468 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -4986,8 +4986,11 @@ int i915_gem_init(struct drm_device *dev)
> > goto out_unlock;
> >
> > ret = dev_priv->gt.init_rings(dev);
> > - if (ret)
> > + if (ret) {
> > + i915_gem_context_fini(dev);
> > + /* XXX: anything else to be undone here? */
>
> Yes. Make this a separate patch and begin the onion unwind.
Hmm. Actually, we have to make sure that we can still modeset if this
function fails - that is anything but utter catastrophe should just
result in loss of functionality (no stolen, no GEM execution etc) but we
can still drive the displays so the user can see how bad the damage is.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
