[Intel-gfx] [PATCH] drm/i915/bdw: Don't allow the FBC base to be 0
"Restriction :
The offset must be greater than 4K bytes, avoiding the first 4KB of
stolen memory."
Since it looks like we currently allocate an overlay out of stolen
before we get the compressed framebuffer, I believe this is not
currently an issue which fixes anything. We simply want to make the code
as future-proof, and as clear as possible, by match the spec.
Cc: Art Runyan
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 62ef55b..65016b0 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -107,19 +107,24 @@ static int i915_setup_compression(struct drm_device *dev,
int size)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_mm_node *compressed_fb, *uninitialized_var(compressed_llb);
+ unsigned long start = 0;
int ret;
compressed_fb = kzalloc(sizeof(*compressed_fb), GFP_KERNEL);
if (!compressed_fb)
goto err_llb;
+ if (IS_BROADWELL(dev))
+ start = 0x1000;
+
/* Try to over-allocate to reduce reallocations and fragmentation */
- ret = drm_mm_insert_node(&dev_priv->mm.stolen, compressed_fb,
-size <<= 1, 4096, DRM_MM_SEARCH_DEFAULT);
+ ret = drm_mm_insert_node_in_range(&dev_priv->mm.stolen, compressed_fb,
+ size <<= 1, 4096, start,
dev_priv->gtt.stolen_size,
+ DRM_MM_SEARCH_DEFAULT);
if (ret)
- ret = drm_mm_insert_node(&dev_priv->mm.stolen, compressed_fb,
-size >>= 1, 4096,
-DRM_MM_SEARCH_DEFAULT);
+ ret = drm_mm_insert_node_in_range(&dev_priv->mm.stolen,
compressed_fb,
+ size >>= 1, 4096, start,
dev_priv->gtt.stolen_size,
+ DRM_MM_SEARCH_DEFAULT);
if (ret)
goto err_llb;
--
1.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/bdw: Use timeout mode for RC6 on bdw
On Wed, Apr 30, 2014 at 02:14:02PM -0700, Kristen Carlson Accardi wrote: > On Thu, 01 May 2014 00:03:15 +0300 > Imre Deak wrote: > > > On Wed, 2014-04-30 at 13:41 -0700, Ben Widawsky wrote: > > > On Wed, Apr 30, 2014 at 01:34:36PM -0700, Kristen Carlson Accardi wrote: > > > > On Tue, 29 Apr 2014 22:31:49 -0700 > > > > Ben Widawsky wrote: > > > > > > > > > On Wed, Apr 09, 2014 at 11:44:06AM -0700, Tom O'Rourke wrote: > > > > > > Higher RC6 residency is observed using timeout mode > > > > > > instead of EI mode. This applies to Broadwell only. > > > > > > The difference is particularly noticeable with video > > > > > > playback. > > > > > > > > > > > > Issue: VIZ-3778 > > > > > > Change-Id: I62bb12e21caf19651034826b45cde7f73a80938d > > > > > > Signed-off-by: Tom O'Rourke > > > > > > > > > > I've merged this one to my bdw-rc6 branch, and therefore my broadwell > > > > > branch. Hopefully Kristen will see some improvement. > > > > > > > > Unfortunately, I built your bdw-rc6 branch along with the revert > > > > I need to get my panel to work, and I get zero rc6 residency. Do I > > > > have to explicitly enable it? > > > > > > I'm not actually sure. You can try it and let me know. I haven't had any > > > time to verify the rebase. We can check my hack. > > > > Note that in -nightly you also have to update sanitize_rc6_option() > > along with intel_enable_gt_powersave() and intel_disable_gt_powersave() > > since atm these keep RC6 disabled on BDW. > > > > --Imre > > > > > Yes, I reverted fb5ed3b201fe5670c9ffeec3b5f6ff044d543c9e and was able > to see some rc6 residency. With the idle workload, residency appears > to be similar to before, so no regression. Thanks. I'll squash this in where appropriate. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] libdrm_intel: Add support for userptr objects
On Wed, Feb 26, 2014 at 04:41:41PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Allow userptr objects to be created and used via libdrm_intel.
>
> At the moment tiling and mapping to GTT aperture is not supported
> due hardware limitations across different generations and uncertainty
> about its usefulness.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> include/drm/i915_drm.h| 16 +
> intel/intel_bufmgr.c | 13
> intel/intel_bufmgr.h | 5 ++
> intel/intel_bufmgr_gem.c | 154
> +-
> intel/intel_bufmgr_priv.h | 12 +++-
> 5 files changed, 198 insertions(+), 2 deletions(-)
>
> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
> index 2f4eb8c..d32ef99 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -223,6 +223,7 @@ typedef struct _drm_i915_sarea {
> #define DRM_I915_GEM_GET_CACHING 0x30
> #define DRM_I915_REG_READ0x31
> #define DRM_I915_GET_RESET_STATS 0x32
> +#define DRM_I915_GEM_USERPTR 0x34
>
> #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)
> @@ -273,6 +274,7 @@ typedef struct _drm_i915_sarea {
> #define DRM_IOCTL_I915_GEM_CONTEXT_DESTROY DRM_IOW (DRM_COMMAND_BASE +
> DRM_I915_GEM_CONTEXT_DESTROY, struct drm_i915_gem_context_destroy)
> #define DRM_IOCTL_I915_REG_READ DRM_IOWR
> (DRM_COMMAND_BASE + DRM_I915_REG_READ, struct drm_i915_reg_read)
> #define DRM_IOCTL_I915_GET_RESET_STATS DRM_IOWR
> (DRM_COMMAND_BASE + DRM_I915_GET_RESET_STATS, struct drm_i915_reset_stats)
> +#define DRM_IOCTL_I915_GEM_USERPTR DRM_IOWR(DRM_COMMAND_BASE +
> DRM_I915_GEM_USERPTR, struct drm_i915_gem_userptr)
>
> /* Allow drivers to submit batchbuffers directly to hardware, relying
> * on the security mechanisms provided by hardware.
> @@ -498,6 +500,20 @@ struct drm_i915_gem_mmap_gtt {
> __u64 offset;
> };
>
> +struct drm_i915_gem_userptr {
> + __u64 user_ptr;
> + __u64 user_size;
Adding alignment might be a safe bet.
> + __u32 flags;
> +#define I915_USERPTR_READ_ONLY 0x1
I'll eventually want something like:
#define I915_MIRRORED_GVA 0x2 /* Request the same GPU address */
> +#define I915_USERPTR_UNSYNCHRONIZED 0x8000
> + /**
> + * Returned handle for the object.
> + *
> + * Object handles are nonzero.
> + */
> + __u32 handle;
> +};
> +
> struct drm_i915_gem_set_domain {
> /** Handle for the object */
> __u32 handle;
> diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
> index 905556f..7f3d795 100644
> --- a/intel/intel_bufmgr.c
> +++ b/intel/intel_bufmgr.c
> @@ -60,6 +60,19 @@ drm_intel_bo
> *drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
> return bufmgr->bo_alloc_for_render(bufmgr, name, size, alignment);
> }
>
> +drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
> + const char *name, void *addr,
> + uint32_t tiling_mode,
> + uint32_t stride,
> + unsigned long size,
> + unsigned long flags)
> +{
> + if (bufmgr->bo_alloc_userptr)
> + return bufmgr->bo_alloc_userptr(bufmgr, name, addr, tiling_mode,
> + stride, size, flags);
> + return NULL;
> +}
> +
> drm_intel_bo *
> drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr, const char *name,
> int x, int y, int cpp, uint32_t *tiling_mode,
> diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
> index 9383c72..be83a56 100644
> --- a/intel/intel_bufmgr.h
> +++ b/intel/intel_bufmgr.h
> @@ -113,6 +113,11 @@ drm_intel_bo
> *drm_intel_bo_alloc_for_render(drm_intel_bufmgr *bufmgr,
> const char *name,
> unsigned long size,
> unsigned int alignment);
> +drm_intel_bo *drm_intel_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
> + const char *name,
> + void *addr, uint32_t tiling_mode,
> + uint32_t stride, unsigned long size,
> + unsigned long flags);
> drm_intel_bo *drm_intel_bo_alloc_tiled(drm_intel_bufmgr *bufmgr,
> const char *name,
> int x, int y, int cpp,
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index 007a6d8..7cad945 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -182,6 +182,11 @@ struct _drm_intel_bo_gem {
> void *mem_virtual;
> /** GTT virtual address for the
Re: [Intel-gfx] [PATCH] drm/i915: Hang counting is now always per-fd, so relax the ioctl for DEFAULT_CONTEXT
On Thu, May 01, 2014 at 08:18:44AM +0100, Chris Wilson wrote: > Since we only count hangs towards the owner of the fd issuing the > command, we can allow that fd to inspect its own default context without > leaking global information. We introduced per-fd accounting with > > commit 0eea67eb26000657079b7fc41079097942339452 > Author: Ben Widawsky > Date: Fri Dec 6 14:11:19 2013 -0800 > > drm/i915: Create a per file_priv default context > > Signed-off-by: Chris Wilson > Cc: Ben Widawsky > Cc: Mika Kuoppala > Cc: Kenneth Graunke Acked-by: Ben Widawsky I can bump it to a r-b if Mika doesn't > --- > drivers/gpu/drm/i915/intel_uncore.c |3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_uncore.c > b/drivers/gpu/drm/i915/intel_uncore.c > index 2adf6aa..f8f13ae 100644 > --- a/drivers/gpu/drm/i915/intel_uncore.c > +++ b/drivers/gpu/drm/i915/intel_uncore.c > @@ -930,9 +930,6 @@ int i915_get_reset_stats_ioctl(struct drm_device *dev, > if (args->flags || args->pad) > return -EINVAL; > > - if (args->ctx_id == DEFAULT_CONTEXT_ID && !capable(CAP_SYS_ADMIN)) > - return -EPERM; > - > ret = mutex_lock_interruptible(&dev->struct_mutex); > if (ret) > return ret; > -- > 1.7.9.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/71] drm/i915/chv: Add DPINVGTT registers defines for Cherryview
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of ville.syrj...@linux.intel.com
> Sent: Wednesday, April 09, 2014 11:28 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 09/71] drm/i915/chv: Add DPINVGTT registers
> defines for Cherryview
>
> From: Ville Syrjälä
>
> Due to Pipe C DPINVGTT has more bits on CHV.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index 3def0fb..98f549a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3485,6 +3485,10 @@ enum punit_power_well {
> #define PLANEC_FLIPDONE_INT_EN (1<<8)
>
> #define DPINVGTT (VLV_DISPLAY_BASE +
> 0x7002c) /* VLV only */
The VLV only comment is not true anymore, it's in CHV also. With that small
clean-up:
Reviewed-by: Rafael Barbalho
> +#define SPRITEF_INVALID_GTT_INT_EN (1<<27)
> +#define SPRITEE_INVALID_GTT_INT_EN (1<<26)
> +#define PLANEC_INVALID_GTT_INT_EN (1<<25)
> +#define CURSORC_INVALID_GTT_INT_EN (1<<24)
> #define CURSORB_INVALID_GTT_INT_EN (1<<23)
> #define CURSORA_INVALID_GTT_INT_EN (1<<22)
> #define SPRITED_INVALID_GTT_INT_EN (1<<21)
> @@ -3494,6 +3498,11 @@ enum punit_power_well {
> #define SPRITEA_INVALID_GTT_INT_EN (1<<17)
> #define PLANEA_INVALID_GTT_INT_EN (1<<16)
> #define DPINVGTT_EN_MASK 0xff
> +#define DPINVGTT_EN_MASK_CHV 0xfff
> +#define SPRITEF_INVALID_GTT_STATUS (1<<11)
> +#define SPRITEE_INVALID_GTT_STATUS (1<<10)
> +#define PLANEC_INVALID_GTT_STATUS (1<<9)
> +#define CURSORC_INVALID_GTT_STATUS (1<<8)
> #define CURSORB_INVALID_GTT_STATUS (1<<7)
> #define CURSORA_INVALID_GTT_STATUS (1<<6)
> #define SPRITED_INVALID_GTT_STATUS (1<<5)
> @@ -3503,6 +3512,7 @@ enum punit_power_well {
> #define SPRITEA_INVALID_GTT_STATUS (1<<1)
> #define PLANEA_INVALID_GTT_STATUS (1<<0)
> #define DPINVGTT_STATUS_MASK 0xff
> +#define DPINVGTT_STATUS_MASK_CHV 0xfff
>
> #define DSPARB 0x70030
> #define DSPARB_CSTART_MASK (0x7f << 7)
> --
> 1.8.3.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/71] drm/i915/chv: Add display interrupt registers bits for Cherryview
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of ville.syrj...@linux.intel.com
> Sent: Wednesday, April 09, 2014 11:28 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 08/71] drm/i915/chv: Add display interrupt
> registers bits for Cherryview
>
> From: Ville Syrjälä
>
> v2: Rebase on top of Ben's GT interrupt shuffling.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rafael Barbalho
> ---
> drivers/gpu/drm/i915/i915_reg.h | 21 -
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index 81d4b83..3def0fb 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1112,24 +1112,43 @@ enum punit_power_well {
>
> /* These are all the "old" interrupts */
> #define ILK_BSD_USER_INTERRUPT (1<<5)
> +
> +#define I915_PM_INTERRUPT(1<<31)
> +#define I915_ISP_INTERRUPT (1<<22)
> +#define I915_LPE_PIPE_B_INTERRUPT(1<<21)
> +#define I915_LPE_PIPE_A_INTERRUPT(1<<20)
> +#define I915_MIPIB_INTERRUPT (1<<19)
> +#define I915_MIPIA_INTERRUPT (1<<18)
> #define I915_PIPE_CONTROL_NOTIFY_INTERRUPT (1<<18)
> #define I915_DISPLAY_PORT_INTERRUPT (1<<17)
> +#define I915_DISPLAY_PIPE_C_HBLANK_INTERRUPT (1<<16)
> +#define I915_MASTER_ERROR_INTERRUPT (1<<15)
> #define I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT
> (1<<15)
> +#define I915_DISPLAY_PIPE_B_HBLANK_INTERRUPT (1<<14)
> #define I915_GMCH_THERMAL_SENSOR_EVENT_INTERRUPT (1<<14) /* p-
> state */
> +#define I915_DISPLAY_PIPE_A_HBLANK_INTERRUPT (1<<13)
> #define I915_HWB_OOM_INTERRUPT (1<<13)
> +#define I915_LPE_PIPE_C_INTERRUPT(1<<12)
> #define I915_SYNC_STATUS_INTERRUPT (1<<12)
> +#define I915_MISC_INTERRUPT (1<<11)
> #define I915_DISPLAY_PLANE_A_FLIP_PENDING_INTERRUPT (1<<11)
> +#define I915_DISPLAY_PIPE_C_VBLANK_INTERRUPT (1<<10)
> #define I915_DISPLAY_PLANE_B_FLIP_PENDING_INTERRUPT (1<<10)
> +#define I915_DISPLAY_PIPE_C_EVENT_INTERRUPT (1<<9)
> #define I915_OVERLAY_PLANE_FLIP_PENDING_INTERRUPT(1<<9)
> +#define I915_DISPLAY_PIPE_C_DPBM_INTERRUPT (1<<8)
> #define I915_DISPLAY_PLANE_C_FLIP_PENDING_INTERRUPT (1<<8)
> #define I915_DISPLAY_PIPE_A_VBLANK_INTERRUPT (1<<7)
> #define I915_DISPLAY_PIPE_A_EVENT_INTERRUPT (1<<6)
> #define I915_DISPLAY_PIPE_B_VBLANK_INTERRUPT (1<<5)
> #define I915_DISPLAY_PIPE_B_EVENT_INTERRUPT (1<<4)
> +#define I915_DISPLAY_PIPE_A_DPBM_INTERRUPT (1<<3)
> +#define I915_DISPLAY_PIPE_B_DPBM_INTERRUPT (1<<2)
> #define I915_DEBUG_INTERRUPT (1<<2)
> +#define I915_WINVALID_INTERRUPT (1<<1)
> #define I915_USER_INTERRUPT (1<<1)
> #define I915_ASLE_INTERRUPT (1<<0)
> -#define I915_BSD_USER_INTERRUPT (1 << 25)
> +#define I915_BSD_USER_INTERRUPT (1<<25)
>
> #define GEN6_BSD_RNCID 0x12198
>
> --
> 1.8.3.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/71] drm/i915/chv: Add DPFLIPSTAT register bits for Cherryview
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of ville.syrj...@linux.intel.com
> Sent: Wednesday, April 09, 2014 11:28 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 07/71] drm/i915/chv: Add DPFLIPSTAT register
> bits for Cherryview
>
> From: Ville Syrjälä
>
> CHV has pipe C and PSR which cause changes to DPFLIPSTAT.
>
> Signed-off-by: Ville Syrjälä
If we add the _CHV to some of the bitfield defines would you also add them to
here? These are also CHV specific.
Reviewed-by: Rafael Barbalho
> ---
> drivers/gpu/drm/i915/i915_reg.h | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index 0fb6b6f..81d4b83 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3451,12 +3451,19 @@ enum punit_power_well {
> #define SPRITED_FLIP_DONE_INT_EN (1<<26)
> #define SPRITEC_FLIP_DONE_INT_EN (1<<25)
> #define PLANEB_FLIP_DONE_INT_EN(1<<24)
> +#define PIPE_PSR_INT_EN(1<<22)
> #define PIPEA_LINE_COMPARE_INT_EN (1<<21)
> #define PIPEA_HLINE_INT_EN (1<<20)
> #define PIPEA_VBLANK_INT_EN(1<<19)
> #define SPRITEB_FLIP_DONE_INT_EN (1<<18)
> #define SPRITEA_FLIP_DONE_INT_EN (1<<17)
> #define PLANEA_FLIPDONE_INT_EN (1<<16)
> +#define PIPEC_LINE_COMPARE_INT_EN (1<<13)
> +#define PIPEC_HLINE_INT_EN (1<<12)
> +#define PIPEC_VBLANK_INT_EN(1<<11)
> +#define SPRITEF_FLIPDONE_INT_EN(1<<10)
> +#define SPRITEE_FLIPDONE_INT_EN(1<<9)
> +#define PLANEC_FLIPDONE_INT_EN (1<<8)
>
> #define DPINVGTT (VLV_DISPLAY_BASE +
> 0x7002c) /* VLV only */
> #define CURSORB_INVALID_GTT_INT_EN (1<<23)
> --
> 1.8.3.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/71] drm/i915/chv: Add PIPESTAT register bits for Cherryview
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of ville.syrj...@linux.intel.com
> Sent: Wednesday, April 09, 2014 11:28 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 06/71] drm/i915/chv: Add PIPESTAT register bits
> for Cherryview
>
> From: Ville Syrjälä
>
> FIXME: We probably want to sprinkle _CHV suffixes over these.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rafael Barbalho
> ---
> drivers/gpu/drm/i915/i915_reg.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index b6441da..0fb6b6f 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3364,6 +3364,7 @@ enum punit_power_well {
> #define SPRITE1_FLIP_DONE_INT_EN_VLV (1UL<<30)
> #define PIPE_CRC_ERROR_ENABLE (1UL<<29)
> #define PIPE_CRC_DONE_ENABLE (1UL<<28)
> +#define PERF_COUNTER2_INTERRUPT_EN (1UL<<27)
> #define PIPE_GMBUS_EVENT_ENABLE(1UL<<27)
> #define PLANE_FLIP_DONE_INT_EN_VLV (1UL<<26)
> #define PIPE_HOTPLUG_INTERRUPT_ENABLE (1UL<<26)
> @@ -3375,8 +3376,10 @@ enum punit_power_well {
> #define PIPE_ODD_FIELD_INTERRUPT_ENABLE(1UL<<21)
> #define PIPE_EVEN_FIELD_INTERRUPT_ENABLE (1UL<<20)
> #define PIPE_B_PSR_INTERRUPT_ENABLE_VLV(1UL<<19)
> +#define PERF_COUNTER_INTERRUPT_EN (1UL<<19)
> #define PIPE_HOTPLUG_TV_INTERRUPT_ENABLE (1UL<<18) /* pre-965
> */
> #define PIPE_START_VBLANK_INTERRUPT_ENABLE (1UL<<18) /* 965 or
> later */
> +#define PIPE_FRAMESTART_INTERRUPT_ENABLE (1UL<<17)
> #define PIPE_VBLANK_INTERRUPT_ENABLE (1UL<<17)
> #define PIPEA_HBLANK_INT_EN_VLV(1UL<<16)
> #define PIPE_OVERLAY_UPDATED_ENABLE(1UL<<16)
> @@ -3384,6 +3387,7 @@ enum punit_power_well {
> #define SPRITE0_FLIP_DONE_INT_STATUS_VLV (1UL<<14)
> #define PIPE_CRC_ERROR_INTERRUPT_STATUS(1UL<<13)
> #define PIPE_CRC_DONE_INTERRUPT_STATUS (1UL<<12)
> +#define PERF_COUNTER2_INTERRUPT_STATUS (1UL<<11)
> #define PIPE_GMBUS_INTERRUPT_STATUS(1UL<<11)
> #define PLANE_FLIP_DONE_INT_STATUS_VLV (1UL<<10)
> #define PIPE_HOTPLUG_INTERRUPT_STATUS (1UL<<10)
> @@ -3392,12 +3396,16 @@ enum punit_power_well {
> #define PIPE_DPST_EVENT_STATUS (1UL<<7)
> #define PIPE_LEGACY_BLC_EVENT_STATUS (1UL<<6)
> #define PIPE_A_PSR_STATUS_VLV (1UL<<6)
> +#define PIPE_LEGACY_BLC_EVENT_STATUS (1UL<<6)
> #define PIPE_ODD_FIELD_INTERRUPT_STATUS(1UL<<5)
> #define PIPE_EVEN_FIELD_INTERRUPT_STATUS (1UL<<4)
> #define PIPE_B_PSR_STATUS_VLV (1UL<<3)
> +#define PERF_COUNTER_INTERRUPT_STATUS (1UL<<3)
> #define PIPE_HOTPLUG_TV_INTERRUPT_STATUS (1UL<<2) /* pre-965
> */
> #define PIPE_START_VBLANK_INTERRUPT_STATUS (1UL<<2) /* 965 or
> later */
> +#define PIPE_FRAMESTART_INTERRUPT_STATUS (1UL<<1)
> #define PIPE_VBLANK_INTERRUPT_STATUS (1UL<<1)
> +#define PIPE_HBLANK_INT_STATUS (1UL<<0)
> #define PIPE_OVERLAY_UPDATED_STATUS(1UL<<0)
>
> #define PIPESTAT_INT_ENABLE_MASK 0x7fff
> --
> 1.8.3.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/71] drm/i915/chv: Enable aliasing PPGTT for CHV
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of ville.syrj...@linux.intel.com
> Sent: Wednesday, April 09, 2014 11:28 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 05/71] drm/i915/chv: Enable aliasing PPGTT for
> CHV
>
> From: Ville Syrjälä
>
> Enable aliasing PPGTT for CHV, but keep full PPGTT still disabled until it
> gets
> enabled for BDW.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rafael Barbalho
> ---
> drivers/gpu/drm/i915/i915_drv.h | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index f760803..4abaa9e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1831,9 +1831,10 @@ struct drm_i915_cmd_table {
> #define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)->need_gfx_hws)
>
> #define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 6)
> -#define HAS_ALIASING_PPGTT(dev) (INTEL_INFO(dev)->gen >= 6 &&
> !IS_VALLEYVIEW(dev))
> -#define HAS_PPGTT(dev) (INTEL_INFO(dev)->gen >= 7 &&
> !IS_VALLEYVIEW(dev) \
> - && !IS_BROADWELL(dev))
> +#define HAS_ALIASING_PPGTT(dev) (INTEL_INFO(dev)->gen >= 6 && \
> + (!IS_VALLEYVIEW(dev) ||
> IS_CHERRYVIEW(dev)))
> +#define HAS_PPGTT(dev) (INTEL_INFO(dev)->gen >= 7 \
> + && !IS_GEN8(dev))
> #define USES_PPGTT(dev) intel_enable_ppgtt(dev, false)
> #define USES_FULL_PPGTT(dev) intel_enable_ppgtt(dev, true)
>
> --
> 1.8.3.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/71] drm/i915/chv: PPAT setup for Cherryview
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of ville.syrj...@linux.intel.com
> Sent: Wednesday, April 09, 2014 11:28 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 03/71] drm/i915/chv: PPAT setup for Cherryview
>
> From: Ville Syrjälä
>
> Ignore the cache bits in PPAT and just set the snoop bit where appropriate.
> BDW WB is mapped to snooped access, while all other modes are mapped to
> non-snooped access.
>
> The hardware supposedly ignores everything except the snoop bit in the
> PPAT entries.
>
> Additionally the hardware actually enforces snooping for all page table
> accesses, and thus the snoop bit is ignored for PDEs.
>
> v2: Rebased on top of the bdw resume fix to reload the ppat entries.
>
> v3: Rebase on top of the i915_gem_gtt.h header extraction.
>
> Signed-off-by: Ville Syrjälä (v1)
> Acked-by: Ben Widawsky
> Signed-off-by: Daniel Vetter
> ---
Reviewed-by: Rafael Barbalho
> drivers/gpu/drm/i915/i915_gem_gtt.c | 43
> +
> drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
> 2 files changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 4467974..3e4d1f0 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -30,7 +30,8 @@
> #include "i915_trace.h"
> #include "intel_drv.h"
>
> -static void gen8_setup_private_ppat(struct drm_i915_private *dev_priv);
> +static void bdw_setup_private_ppat(struct drm_i915_private *dev_priv);
> +static void chv_setup_private_ppat(struct drm_i915_private *dev_priv);
>
> bool intel_enable_ppgtt(struct drm_device *dev, bool full) { @@ -1315,7
> +1316,11 @@ void i915_gem_restore_gtt_mappings(struct drm_device
> *dev)
>
>
> if (INTEL_INFO(dev)->gen >= 8) {
> - gen8_setup_private_ppat(dev_priv);
> + if (IS_CHERRYVIEW(dev))
> + chv_setup_private_ppat(dev_priv);
> + else
> + bdw_setup_private_ppat(dev_priv);
> +
> return;
> }
>
> @@ -1787,7 +1792,7 @@ static int ggtt_probe_common(struct drm_device
> *dev,
> /* The GGTT and PPGTT need a private PPAT setup in order to handle
> cacheability
> * bits. When using advanced contexts each context stores its own PAT, but
> * writing this data shouldn't be harmful even in those cases. */ -static
> void
> gen8_setup_private_ppat(struct drm_i915_private *dev_priv)
> +static void bdw_setup_private_ppat(struct drm_i915_private *dev_priv)
> {
> uint64_t pat;
>
> @@ -1806,6 +1811,33 @@ static void gen8_setup_private_ppat(struct
> drm_i915_private *dev_priv)
> I915_WRITE(GEN8_PRIVATE_PAT + 4, pat >> 32); }
>
> +static void chv_setup_private_ppat(struct drm_i915_private *dev_priv) {
> + uint64_t pat;
> +
> + /*
> + * Map WB on BDW to snooped on CHV.
> + *
> + * Only the snoop bit has meaning for CHV, the rest is
> + * ignored.
> + *
> + * Note that the harware enforces snooping for all page
> + * table accesses. The snoop bit is actually ignored for
> + * PDEs.
> + */
> + pat = GEN8_PPAT(0, CHV_PPAT_SNOOP) |
> + GEN8_PPAT(1, 0) |
> + GEN8_PPAT(2, 0) |
> + GEN8_PPAT(3, 0) |
> + GEN8_PPAT(4, CHV_PPAT_SNOOP) |
> + GEN8_PPAT(5, CHV_PPAT_SNOOP) |
> + GEN8_PPAT(6, CHV_PPAT_SNOOP) |
> + GEN8_PPAT(7, CHV_PPAT_SNOOP);
> +
> + I915_WRITE(GEN8_PRIVATE_PAT, pat);
> + I915_WRITE(GEN8_PRIVATE_PAT + 4, pat >> 32); }
> +
> static int gen8_gmch_probe(struct drm_device *dev,
> size_t *gtt_total,
> size_t *stolen,
> @@ -1831,7 +1863,10 @@ static int gen8_gmch_probe(struct drm_device
> *dev,
> gtt_size = gen8_get_total_gtt_size(snb_gmch_ctl);
> *gtt_total = (gtt_size / sizeof(gen8_gtt_pte_t)) << PAGE_SHIFT;
>
> - gen8_setup_private_ppat(dev_priv);
> + if (IS_CHERRYVIEW(dev))
> + chv_setup_private_ppat(dev_priv);
> + else
> + bdw_setup_private_ppat(dev_priv);
>
> ret = ggtt_probe_common(dev, gtt_size);
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index b5e8ac0..cfca023 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -95,6 +95,7 @@ typedef gen8_gtt_pte_t gen8_ppgtt_pde_t;
> #define PPAT_CACHED_INDEX_PAGE_PAT /* WB LLCeLLC */
> #define PPAT_DISPLAY_ELLC_INDEX _PAGE_PCD /* WT eLLC */
>
> +#define CHV_PPAT_SNOOP (1<<6)
> #define GEN8_PPAT_AGE(x) (x<<4)
> #define GEN8_PPAT_LLCeLLC(3<<2)
> #define GEN8_PPAT_LLCELLC(2<<2)
> --
> 1.8.3.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> htt
Re: [Intel-gfx] [PATCH 02/71] drm/i915/chv: Add IS_CHERRYVIEW() macro
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of ville.syrj...@linux.intel.com
> Sent: Wednesday, April 09, 2014 11:28 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 02/71] drm/i915/chv: Add IS_CHERRYVIEW()
> macro
>
> From: Ville Syrjälä
>
> We will treat Cherryview like Valleyview for most parts. Add a macro for
> cases when we need to tell the two apart.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Rafael Barbalho
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index 41cf429..f760803 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1788,6 +1788,7 @@ struct drm_i915_cmd_table {
>(dev)->pdev->device == 0x0106 || \
>(dev)->pdev->device == 0x010A)
> #define IS_VALLEYVIEW(dev) (INTEL_INFO(dev)->is_valleyview)
> +#define IS_CHERRYVIEW(dev) (INTEL_INFO(dev)->is_valleyview &&
> IS_GEN8(dev))
> #define IS_HASWELL(dev) (INTEL_INFO(dev)->is_haswell)
> #define IS_BROADWELL(dev)(!INTEL_INFO(dev)->is_valleyview &&
> IS_GEN8(dev))
> #define IS_MOBILE(dev) (INTEL_INFO(dev)->is_mobile)
> --
> 1.8.3.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/71] drm/i915/chv: IS_BROADWELL() should not be true for Cherryview
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of ville.syrj...@linux.intel.com
> Sent: Wednesday, April 09, 2014 11:28 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 01/71] drm/i915/chv: IS_BROADWELL() should
> not be true for Cherryview
>
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
> Reviewed-by: Jesse Barnes
Reviewed-by: Rafael Barbalho
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h index e23bb73..41cf429 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1789,7 +1789,7 @@ struct drm_i915_cmd_table {
>(dev)->pdev->device == 0x010A)
> #define IS_VALLEYVIEW(dev) (INTEL_INFO(dev)->is_valleyview)
> #define IS_HASWELL(dev) (INTEL_INFO(dev)->is_haswell)
> -#define IS_BROADWELL(dev)(INTEL_INFO(dev)->gen == 8)
> +#define IS_BROADWELL(dev)(!INTEL_INFO(dev)->is_valleyview &&
> IS_GEN8(dev))
> #define IS_MOBILE(dev) (INTEL_INFO(dev)->is_mobile)
> #define IS_HSW_EARLY_SDV(dev)(IS_HASWELL(dev) && \
>((dev)->pdev->device & 0xFF00) == 0x0C00)
> --
> 1.8.3.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Support 64b execbuf
> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Chris Wilson > Sent: Thursday, May 01, 2014 9:13 AM > To: Widawsky, Benjamin > Cc: Intel GFX > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Support 64b execbuf > > On Mon, Apr 28, 2014 at 07:29:25PM -0700, Ben Widawsky wrote: > > Previously, our code only had a 32b offset value for where the > > batchbuffer starts. With full PPGTT, and 64b canonical GPU address > > space, that is an insufficient value. The code to expand is pretty > > straight forward, and only one platform needs to do anything with the > > extra bits. > > > > Signed-off-by: Ben Widawsky > Reviewed-by: Chris Wilson -Chris Reviewed-by: Rafael Barbalho Thanks, Rafael ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix dynamic allocation of physical handles
On Fri, Apr 18, 2014 at 08:27:03AM +0100, Chris Wilson wrote: > A single object may be referenced by multiple registers fundamentally > breaking the static allotment of ids in the current design. When the > object is used the second time, the physical address of the first > assignment is relinquished and a second one granted. However, the > hardware is still reading (and possibly writing) to the old physical > address now returned to the system. Eventually hilarity will ensue, but > in the short term, it just means that cursors are broken when using more > than one pipe. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77351 > Signed-off-by: Chris Wilson > Cc: sta...@vger.kernel.org Ping ^^ -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Support 64b execbuf
On Mon, Apr 28, 2014 at 07:29:25PM -0700, Ben Widawsky wrote: > Previously, our code only had a 32b offset value for where the > batchbuffer starts. With full PPGTT, and 64b canonical GPU address > space, that is an insufficient value. The code to expand is pretty > straight forward, and only one platform needs to do anything with the > extra bits. > > Signed-off-by: Ben Widawsky Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [v2] drm/i915: Expand error state's address width to 64b
On Mon, Apr 28, 2014 at 06:43:04PM -0700, Ben Widawsky wrote: > v2: 0 pad the new 8B fields or else intel_error_decode has a hard time. > Note, regardless we need an igt update. We should decide whether to use 0001 or 0001 and be consistent. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Support 64b relocations
On Mon, Apr 28, 2014 at 05:18:28PM -0700, Ben Widawsky wrote:
> All the rest of the code to enable this is in my branch. Without my
> branch, hitting > 32b offsets is impossible. The code has always
> "supported" 64b, but it's never actually been run of tested. This change
> doesn't actually fix anything. [1] I am not sure why X won't work yet. I
> do not get hangs or obvious errors.
>
> There are 3 fixes grouped together here. First is to remove the
> hardcoded 0 for the upper dword of the relocation. The next fix is to
> use a 64b value for target_offset. The final fix is to not directly
> apply target_offset to reloc->delta. reloc->delta is part of ABI, and so
> we cannot change it. As it stands, 32b is enough to represent everything
> we're interested in representing anyway. The main problem is, we cannot
> add greater than 32b values to it directly.
>
> [1] Almost all of intel-gpu-tools is not yet ready to test 64b
> relocations. There are a few places that expect 32b values for offsets
> and these all won't work.
>
> Cc: Rafael Barbalho
> Cc: Chris Wilson
> Signed-off-by: Ben Widawsky
Seriously, we did this? I am ashamed. I was annoyed by the original
assertion that no userspace was ready in the first place, and to see
that the code was a complete farce anyway...
Reviewed-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 23 +--
> 1 file changed, 13 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 0d806fc..6ffecd2 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -262,10 +262,12 @@ static inline int use_cpu_reloc(struct
> drm_i915_gem_object *obj)
>
> static int
> relocate_entry_cpu(struct drm_i915_gem_object *obj,
> -struct drm_i915_gem_relocation_entry *reloc)
> +struct drm_i915_gem_relocation_entry *reloc,
> +uint64_t target_offset)
> {
> struct drm_device *dev = obj->base.dev;
> uint32_t page_offset = offset_in_page(reloc->offset);
> + uint64_t delta = reloc->delta + target_offset;
I would not have called the final value delta, but target_offset.
I was going to quible over the use of a local variable instead of
reloc->delta, but you successfully argued in my head that your way was
less obtuse.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Hang counting is now always per-fd, so relax the ioctl for DEFAULT_CONTEXT
Since we only count hangs towards the owner of the fd issuing the command, we can allow that fd to inspect its own default context without leaking global information. We introduced per-fd accounting with commit 0eea67eb26000657079b7fc41079097942339452 Author: Ben Widawsky Date: Fri Dec 6 14:11:19 2013 -0800 drm/i915: Create a per file_priv default context Signed-off-by: Chris Wilson Cc: Ben Widawsky Cc: Mika Kuoppala Cc: Kenneth Graunke --- drivers/gpu/drm/i915/intel_uncore.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index 2adf6aa..f8f13ae 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -930,9 +930,6 @@ int i915_get_reset_stats_ioctl(struct drm_device *dev, if (args->flags || args->pad) return -EINVAL; - if (args->ctx_id == DEFAULT_CONTEXT_ID && !capable(CAP_SYS_ADMIN)) - return -EPERM; - ret = mutex_lock_interruptible(&dev->struct_mutex); if (ret) return ret; -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
