From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH] drm/i915: add register read IOCTL Date: Thu, 12 Jul 2012 12:42:30 -0700 Message-ID: <87zk74hil5.fsf@eliezer.anholt.net> References: <1342051656-32481-1-git-send-email-ben@bwidawsk.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0652913279==" Return-path: In-Reply-To: <1342051656-32481-1-git-send-email-ben@bwidawsk.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: intel-gfx@lists.freedesktop.org Cc: Ben Widawsky List-Id: intel-gfx@lists.freedesktop.org --===============0652913279== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Ben Widawsky 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, the > IOCTL can provide this service. > > Currently the implementation whitelists only the render ring timestamp > register, because that is the only thing we need to expose at this time. Thanks. I was just writing this patch yesterday since it still hadn't landed. What I was doing was very similar, I was just not including a size, since we're going to whitelist regs and the correct size is implied by the register offset. > +int i915_reg_read_ioctl(struct drm_device *dev, > + void *data, struct drm_file *file) > +{ > + struct drm_i915_private *dev_priv = dev->dev_private; > + struct drm_i915_reg_read *reg = data; > + > + /* Whitelisted for now */ > + if (reg->offset != RING_TIMESTAMP(RENDER_RING_BASE)) > + return -ENXIO; Should this be conditional on the gen having the timestamp register? > +struct drm_i915_reg_read { > + __u64 offset; > + __u32 size; > + __u64 val; /* Return value */ > + __u32 pad; > +}; Bad padding here. On i386 you'll get a struct like: { uint64_t offset uint32_t size uint32_t implicit_pad uint64_t val uint32_t pad } --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAk//KKYACgkQHUdvYGzw6vdQGACbBxaJ4H5c+TY8GMwK13iLfE09 Z1IAn3S3I7iRkOegz3yNb9Ji/YZA/a9J =nNkz -----END PGP SIGNATURE----- --=-=-=-- --===============0652913279== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============0652913279==--