On Wed, Jul 18, 2012 at 10:22:01AM -0700, Ben Widawsky wrote: > On Wed, 18 Jul 2012 10:14:46 -0700 > Eric Anholt <[email protected]> wrote: > > > Ben Widawsky <[email protected]> writes: > > > > > The interface's immediate purpose is to do synchronous timestamp queries > > > as required by GL_TIMESTAMP. The GPU has a register for reading the > > > timestamp but because that would normally require root access through > > > libpciaccess, the IOCTL can provide this service instead. > > > > > > Currently the implementation whitelists only the render ring timestamp > > > register, because that is the only thing we need to expose at this time. > > > > > > v2: make size implicit based on the register offset > > > Add a generation check > > > > > diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h > > > index 8cc7083..fbe7757 100644 > > > --- a/include/drm/i915_drm.h > > > +++ b/include/drm/i915_drm.h > > > @@ -203,6 +203,7 @@ typedef struct _drm_i915_sarea { > > > #define DRM_I915_GEM_WAIT 0x2c > > > #define DRM_I915_GEM_CONTEXT_CREATE 0x2d > > > #define DRM_I915_GEM_CONTEXT_DESTROY 0x2e > > > +#define DRM_I915_REG_READ 0x30 > > > > Is 0x2f some other outstanding ioctl? > > > > I was saving it for some yet to be realized context ioctl. We can use > 0x2f, I don't care. Daniel - feel free to change it or not as you > please when/if you suck it in.
Patch queued for -next (with ioctl number 0x31, I've figure when I'll change it I might as well avoid conflicts with the set_cacheing stuff). Can you please adjust the i-g-t test and commit that one, too? Thanks, Daniel -- Daniel Vetter Mail: [email protected] Mobile: +41 (0)79 365 57 48 _______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
