On Mon, Nov 11, 2013 at 04:01:05PM -0800, Ian Romanick wrote: > On 11/08/2013 10:11 AM, Damien Lespiau wrote: > > On Wed, Oct 30, 2013 at 03:44:16PM +0200, Mika Kuoppala wrote: > >> This ioctl returns reset stats for specified context. > >> > >> The struct returned contains context loss counters. > >> > >> reset_count: all resets across all contexts > >> batch_active: active batches lost on resets > >> batch_pending: pending batches lost on resets > >> > >> v2: get rid of state tracking completely and deliver only counts. Idea > >> from Chris Wilson. > >> > >> v3: fix commit message > >> > >> v4: default context handled inside i915_gem_context_get_hang_stats > >> > >> v5: reset_count only for priviledged process > >> > >> v6: ctx=0 needs CAP_SYS_ADMIN for batch_* counters (Chris Wilson) > >> > >> v7: context hang stats never returns NULL > >> > >> v8: rebased on top of reworked context hang stats > >> DRM_RENDER_ALLOW for ioctl > >> > >> v9: use DEFAULT_CONTEXT_ID. Improve comments for ioctl struct members > >> > >> Signed-off-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxx> > >> Cc: Ian Romanick <idr@xxxxxxxxxxxxxxx> > >> Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > >> Cc: Daniel Vetter <daniel.vetter@xxxxxxxx> > > > > The logic there looks good to me, I was just wondering if we wanted a > > bit more padding in case we want other counters or misc stuff. > > I think the current padding should be sufficient. The other things that > could occur aren't things that we should return counts of. For those > kinds of things, we'd only want to return flags. In fact, the current > user space only uses the counts as flags anyway (is the count non-zero?). > > > Reviewed-by: Damien Lespiau <damien.lespiau@xxxxxxxxx> > > Also, > > Reviewed-by: Ian Romanick <ian.d.romanick@xxxxxxxxx> I've just pulled in this and Mika's updated prep patch into my queue. I'll freeze it down into drm-intel-next at the end of this week. Thanks for the patch and review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
