From: Daniel Vetter <daniel@ffwll.ch>
To: Ben Widawsky <ben@bwidawsk.net>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: ioctl to query a bo's cache level
Date: Thu, 22 Sep 2011 09:35:12 +0200 [thread overview]
Message-ID: <20110922073512.GC2924@phenom.ffwll.local> (raw)
In-Reply-To: <1316656031-11239-2-git-send-email-ben@bwidawsk.net>
On Wed, Sep 21, 2011 at 06:47:10PM -0700, Ben Widawsky wrote:
>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
> ---
> drivers/gpu/drm/i915/i915_dma.c | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_gem.c | 23 +++++++++++++++++++++++
> include/drm/i915_drm.h | 7 +++++++
> 4 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 8a3942c..8178cbb 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -2292,6 +2292,7 @@ struct drm_ioctl_desc i915_ioctls[] = {
> DRM_IOCTL_DEF_DRV(I915_GEM_MADVISE, i915_gem_madvise_ioctl, DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(I915_OVERLAY_PUT_IMAGE, intel_overlay_put_image, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> DRM_IOCTL_DEF_DRV(I915_OVERLAY_ATTRS, intel_overlay_attrs, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHE_TYPE, i915_gem_get_cache_type_ioctl, DRM_UNLOCKED),
> };
>
> int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7916bd9..2dfcb3d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1118,6 +1118,8 @@ int i915_gem_get_tiling(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
> int i915_gem_get_aperture_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
> +int i915_gem_get_cache_type_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv);
> void i915_gem_load(struct drm_device *dev);
> int i915_gem_init_object(struct drm_gem_object *obj);
> int __must_check i915_gem_flush_ring(struct intel_ring_buffer *ring,
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index a546a71..362da16 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3777,6 +3777,29 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
> }
>
> int
> +i915_gem_get_cache_type_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> +
> + struct drm_i915_gem_get_cache_type *args = data;
> + struct drm_i915_gem_object *obj;
> + int ret = 0;
> +
> + obj = to_intel_bo(drm_gem_object_lookup(dev, file_priv, args->handle));
> + if (&obj->base == NULL) {
> + ret = -ENOENT;
> + goto out;
> + }
> +
> + args->cache_level = obj->cache_level;
Grab struct_mutex around this, obj->cache_level might change over the
lifetime of the bo. Yeah, our locking is a mess, I know ;-)
> + drm_gem_object_unreference(&obj->base);
> +
> +out:
> + return ret;
> +}
> +
> +int
> i915_gem_idle(struct drm_device *dev)
> {
> drm_i915_private_t *dev_priv = dev->dev_private;
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index 28c0d11..a0dff8a 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -198,6 +198,7 @@ typedef struct _drm_i915_sarea {
> #define DRM_I915_OVERLAY_PUT_IMAGE 0x27
> #define DRM_I915_OVERLAY_ATTRS 0x28
> #define DRM_I915_GEM_EXECBUFFER2 0x29
> +#define DRM_I915_GEM_GET_CACHE_TYPE 0x2a
>
> #define DRM_IOCTL_I915_INIT DRM_IOW( DRM_COMMAND_BASE + DRM_I915_INIT, drm_i915_init_t)
> #define DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE + DRM_I915_FLUSH)
> @@ -239,6 +240,7 @@ typedef struct _drm_i915_sarea {
> #define DRM_IOCTL_I915_GEM_MADVISE DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_MADVISE, struct drm_i915_gem_madvise)
> #define DRM_IOCTL_I915_OVERLAY_PUT_IMAGE DRM_IOW(DRM_COMMAND_BASE + DRM_I915_OVERLAY_PUT_IMAGE, struct drm_intel_overlay_put_image)
> #define DRM_IOCTL_I915_OVERLAY_ATTRS DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_OVERLAY_ATTRS, struct drm_intel_overlay_attrs)
> +#define DRM_IOCTL_I915_GEM_GET_CACHE_TYPE DRM_IOR (DRM_COMMAND_BASE + DRM_I915_GEM_GET_CACHE_TYPE, struct drm_i915_gem_get_cache_type)
>
> /* Allow drivers to submit batchbuffers directly to hardware, relying
> * on the security mechanisms provided by hardware.
> @@ -844,4 +846,9 @@ struct drm_intel_overlay_attrs {
> __u32 gamma5;
> };
>
> +struct drm_i915_gem_get_cache_type {
> + __u32 handle;
> + __u32 cache_level;
> +};
> +
> #endif /* _I915_DRM_H_ */
> --
> 1.7.6.3
>
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2011-09-22 7:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-20 4:25 [PATCH 1/6] RFCish: write only mappings (aka non-blocking) Ben Widawsky
2011-09-20 4:25 ` [PATCH 1/6] drm/i915: object CPU flush interface Ben Widawsky
2011-09-20 4:25 ` [PATCH 2/6] drm/i915: write only object tracking Ben Widawsky
2011-09-20 4:25 ` [PATCH 3/6] drm/i915: Support write only mappings Ben Widawsky
2011-09-20 5:29 ` Keith Packard
2011-09-20 5:37 ` Ben Widawsky
2011-09-20 8:30 ` Chris Wilson
2011-09-20 4:25 ` [PATCH 4/6] intel: write only map support Ben Widawsky
2011-09-20 4:25 ` [PATCH 5/6] write-only mappings Ben Widawsky
2011-09-20 4:25 ` [PATCH 6/6] intel: use write only maps for MapRangeBuffer Ben Widawsky
2011-09-20 11:06 ` [PATCH 1/6] RFCish: write only mappings (aka non-blocking) Daniel Vetter
2011-09-20 17:17 ` Eric Anholt
2011-09-20 19:19 ` Daniel Vetter
2011-09-21 8:19 ` [PATCH] intel: non-blocking mmaps on the cheap Daniel Vetter
2011-09-21 18:11 ` Eric Anholt
2011-09-21 19:19 ` Daniel Vetter
2011-09-22 1:47 ` [PATCH cont'd] " Ben Widawsky
2011-09-22 1:47 ` [PATCH] drm/i915: ioctl to query a bo's cache level Ben Widawsky
2011-09-22 7:35 ` Daniel Vetter [this message]
2011-09-22 15:36 ` Ben Widawsky
2011-09-22 15:49 ` Chris Wilson
2011-09-22 1:47 ` [PATCH] on top of daniel Ben Widawsky
2011-09-22 7:39 ` Daniel Vetter
2011-09-22 7:33 ` [PATCH cont'd] intel: non-blocking mmaps on the cheap Daniel Vetter
2011-09-20 21:16 ` [PATCH 1/6] RFCish: write only mappings (aka non-blocking) Chris Wilson
2011-09-21 7:02 ` Daniel Vetter
2011-09-20 22:19 ` Ben Widawsky
2011-09-21 7:07 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110922073512.GC2924@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=ben@bwidawsk.net \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.