On Wed, Apr 03, 2013 at 12:56:11PM +0100, Chris Wilson wrote: > On Tue, Apr 02, 2013 at 06:27:00PM -0700, Ben Widawsky wrote: > > On Tue, Apr 02, 2013 at 03:45:42PM -0700, Ben Widawsky wrote: > > > From: Mika Kuoppala <mika.kuoppala at linux.intel.com> > > > > > > In preparation to do analysis of which context was > > > guilty of gpu hung, store kreffed context pointer > > > into request struct. > > > > > > This allows us to inspect contexts when gpu is reset > > > even if those contexts would already be released > > > by userspace. > > > > > > v2: track i915_hw_context pointers instead of using ctx_ids > > > (from Chris Wilson) > > > > > > v3 (Ben): Get rid of do_release() and handle refcounting more compactly. > > > (recommended by Chris) > > > > > > Signed-off-by: Mika Kuoppala <mika.kuoppala at intel.com> > > > Signed-off-by: Ben Widawsky <ben at bwidawsk.net> > > > > Now I remember why my version of reference counting was so much more > > complicated. In my case, I want to keep the last context around instead > > of the last context object. To do this we can't do a kref_put until > > we've switched to the next context (similar to how we manage the context > > object). I want to do this since the context stores the PPGTT which will > > currently be in use. I need to switch PDEs at context switch time. > > This seems feasible using requests and a callback from retire. The > alternative is something hairy like intel_overlay, hence my desire for > keeping all ring operations as a i915_gem_request. As long as the request object keeps a ref while the request is still oustanding and the ring itself keeps a ref to whatever is the currently last scheduled context, everything should work out fine. So I don't think we need to jump through any complicated hoops here. One quick bikeshed on the patch itself though: I'd like to see some static inlines for kref_get/put on contexts ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
