Re: [Intel-gfx] [PATCH v7 5/6] drm/i915/guc: Check the locking status of GuC WOPCM registers
Quoting Jackie Li (2018-01-19 01:29:31) > GuC WOPCM registers are write-once registers. Current driver code > accesses these registers without checking the accessibility to these > registers, this will lead unpredictable driver behaviors if these > registers were touch by other components (such as faulty BIOS code). > > This patch moves the GuC WOPCM register updating operations into > intel_guc_wopcm.c and adds checks before and after the write to GuC > WOPCM registers to make sure the driver is in a known state before > and after writing to these write-once registers. > > v6: > - Made sure module reloading won't bug the kernel while doing >locking status checking > > v7: > - Fixed patch format issues > > Cc: Michal Wajdeczko > Cc: Chris Wilson > Cc: Joonas Lahtinen > Signed-off-by: Jackie Li > --- > +static inline bool __reg_locked(struct drm_i915_private *dev_priv, > + i915_reg_t reg) > +{ > + return !!(I915_READ(reg) & GUC_WOPCM_REG_LOCKED); Why the double cast to bool? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset
Quoting Jackie Li (2018-01-19 01:29:28) > GuC related exported functions should start with "intel_guc_" > prefix and pass intel_guc as the first parameter since its guc > related. Current guc_ggtt_offset() failed to follow this code > convention. But it was not, and still does not operate on the guc. Is that changing? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 1/6] drm/i915/guc: Move GuC WOPCM related code into separate files
Quoting Jackie Li (2018-01-19 01:29:27) > intel_guc_reg.h should only include definition for GuC registers > and related register bits. GuC WOPCM related values should not > be defined in intel_guc_reg.h GuC registers does not include GuC WOPCM? The code does seem to suggest they are related ;) > This patch creates a better file structure by moving GuC WOPCM > related definitions int to a new header intel_guc_wopcm.h > and moving GuC WOPCM related functions to a new source file > intel_guc_wopcm.c Just needs one more sentence to sell this, perhaps "as future patches will increase the complexity of determining the WOPCM layout". One function per file is just crying out for LTO ;) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 2/6] drm/i915/guc: Rename guc_ggtt_offset to intel_guc_ggtt_offset
On 1/19/2018 6:59 AM, Jackie Li wrote: GuC related exported functions should start with "intel_guc_" prefix and pass intel_guc as the first parameter since its guc related. Current guc_ggtt_offset() failed to follow this code convention. This patch renames the guc_ggtt_offset to intel_guc_ggtt_offset and updates the related code to pass intel_guc pointer to this function call. so that we have a unified coding style for GuC code. Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson Cc: Joonas Lahtinen Signed-off-by: Jackie Li --- drivers/gpu/drm/i915/intel_guc.c| 12 +++- drivers/gpu/drm/i915/intel_guc.h| 10 -- drivers/gpu/drm/i915/intel_guc_ads.c| 25 + drivers/gpu/drm/i915/intel_guc_ct.c | 5 +++-- drivers/gpu/drm/i915/intel_guc_fw.c | 2 +- drivers/gpu/drm/i915/intel_guc_log.c| 2 +- drivers/gpu/drm/i915/intel_guc_submission.c | 10 +- drivers/gpu/drm/i915/intel_huc.c| 6 -- 8 files changed, 42 insertions(+), 30 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index b8b6d4a..e70885b 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -264,8 +264,10 @@ void intel_guc_init_params(struct intel_guc *guc) /* If GuC submission is enabled, set up additional parameters here */ if (USES_GUC_SUBMISSION(dev_priv)) { - u32 ads = guc_ggtt_offset(guc->ads_vma) >> PAGE_SHIFT; - u32 pgs = guc_ggtt_offset(dev_priv->guc.stage_desc_pool); + u32 ads = intel_guc_ggtt_offset(guc, + guc->ads_vma) >> PAGE_SHIFT; + u32 pgs = intel_guc_ggtt_offset(guc, + dev_priv->guc.stage_desc_pool); u32 ctx_in_16 = GUC_MAX_STAGE_DESCRIPTORS / 16; params[GUC_CTL_DEBUG] |= ads << GUC_ADS_ADDR_SHIFT; @@ -413,7 +415,7 @@ int intel_guc_suspend(struct drm_i915_private *dev_priv) data[0] = INTEL_GUC_ACTION_ENTER_S_STATE; /* any value greater than GUC_POWER_D0 */ data[1] = GUC_POWER_D1; - data[2] = guc_ggtt_offset(guc->shared_data); + data[2] = intel_guc_ggtt_offset(guc, guc->shared_data); return intel_guc_send(guc, data, ARRAY_SIZE(data)); } @@ -436,7 +438,7 @@ int intel_guc_reset_engine(struct intel_guc *guc, data[3] = 0; data[4] = 0; data[5] = guc->execbuf_client->stage_id; - data[6] = guc_ggtt_offset(guc->shared_data); + data[6] = intel_guc_ggtt_offset(guc, guc->shared_data); return intel_guc_send(guc, data, ARRAY_SIZE(data)); } @@ -458,7 +460,7 @@ int intel_guc_resume(struct drm_i915_private *dev_priv) data[0] = INTEL_GUC_ACTION_EXIT_S_STATE; data[1] = GUC_POWER_D0; - data[2] = guc_ggtt_offset(guc->shared_data); + data[2] = intel_guc_ggtt_offset(guc, guc->shared_data); return intel_guc_send(guc, data, ARRAY_SIZE(data)); } diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h index 9e0a97e..b7e2a18 100644 --- a/drivers/gpu/drm/i915/intel_guc.h +++ b/drivers/gpu/drm/i915/intel_guc.h @@ -101,13 +101,19 @@ static inline void intel_guc_notify(struct intel_guc *guc) guc->notify(guc); } -/* Should add "/**" instead of removing "/*" +/* intel_guc_ggtt_offset() - Get the GGTT offset of @vma. I feel this function is more validating the offset so "Validate and get the ggtt offset of @vma" ? + * @guc: intel guc. + * @vma: i915 graphics virtual memory area. + * * GuC does not allow any gfx GGTT address that falls into range [0, WOPCM_TOP), * which is reserved for Boot ROM, SRAM and WOPCM. Currently this top address is * 512K. In order to exclude 0-512K address space from GGTT, all gfx objects * used by GuC is pinned with PIN_OFFSET_BIAS along with size of WOPCM. + * + * Return: GGTT offset that meets the GuC gfx address requirement. */ -static inline u32 guc_ggtt_offset(struct i915_vma *vma) +static inline u32 intel_guc_ggtt_offset(struct intel_guc *guc, + struct i915_vma *vma) { u32 offset = i915_ggtt_offset(vma); This function uses GUC_GGTT_TOP that is defined in guc_reg.h and I think we can move it to guc.h similar to other WOPCM related moves in earlier patch. diff --git a/drivers/gpu/drm/i915/intel_guc_ads.c b/drivers/gpu/drm/i915/intel_guc_ads.c index ac62753..7215594 100644 --- a/drivers/gpu/drm/i915/intel_guc_ads.c +++ b/drivers/gpu/drm/i915/intel_guc_ads.c @@ -113,17 +113,6 @@ int intel_guc_ads_create(struct intel_guc *guc) blob->reg_state.white_list[engine->guc_id].count = 0; } - /* -* The GuC requires a "Golden Context" when it reinitialises -* engines after a reset. Here we use the Render ring default -* context, which must already exist and be
Re: [Intel-gfx] [PATCH 1/2] drm/i915/ppgtt: Pin page directories before allocation
Quoting Matthew Auld (2018-01-31 22:48:14) > On 31 January 2018 at 21:44, Chris Wilson wrote: > > Commit e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes") > > believed that because it did not insert its freshly allocated page > > directory into the pd tree, it was safe from the shrinker. I failed to > > heed the lesson learnt from commit dd19674bacba ("drm/i915: Remove bitmap > > tracking for used-ptes") that we need to pin all the levels in the tree > > before hitting the shrinker or else the shrinker may free an upper layer > > as we proceed to allocate the tree. Thus leaving dangling pointers > > everywhere and a GPF should we hit direct reclaim at just the wrong > > moment. > > > > Jan 24 10:32:48 eric-macbookpro kernel: CPU: 0 PID: 7374 Comm: chromium > > Tainted: P O4.14.13-1-ARCH #1 > > Jan 24 10:32:48 eric-macbookpro kernel: Hardware name: Apple Inc. > > MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B33.1706181928 > > 06/18/2017 > > Jan 24 10:32:48 eric-macbookpro kernel: task: 994f696c2c40 task.stack: > > b1a789d4c000 > > Jan 24 10:32:48 eric-macbookpro kernel: RIP: > > 0010:gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] > > Jan 24 10:32:48 eric-macbookpro kernel: RSP: 0018:b1a789d4f940 EFLAGS: > > 00010206 > > Jan 24 10:32:48 eric-macbookpro kernel: RAX: 81c1788cc4f68138 RBX: > > 994f54db8000 RCX: 994f696c2c40 > > Jan 24 10:32:48 eric-macbookpro kernel: RDX: 00023bc73003 RSI: > > 994d598b6b80 RDI: 994f54db8000 > > Jan 24 10:32:48 eric-macbookpro kernel: RBP: 994d598b6b80 R08: > > R09: > > Jan 24 10:32:48 eric-macbookpro kernel: R10: b1a789d4f550 R11: > > 994eaf3c3208 R12: 0027 > > Jan 24 10:32:48 eric-macbookpro kernel: R13: 5000 R14: > > 04e8f000 R15: 994f54dba000 > > Jan 24 10:32:48 eric-macbookpro kernel: FS: 7f585886aa00() > > GS:994faec0() knlGS: > > Jan 24 10:32:48 eric-macbookpro kernel: CS: 0010 DS: ES: CR0: > > 80050033 > > Jan 24 10:32:48 eric-macbookpro kernel: CR2: 004ac8e8 CR3: > > 0002552c8004 CR4: 003606f0 > > Jan 24 10:32:48 eric-macbookpro kernel: Call Trace: > > Jan 24 10:32:48 eric-macbookpro kernel: gen8_ppgtt_alloc_pdp+0x178/0x320 > > [i915] > > Jan 24 10:32:48 eric-macbookpro kernel: gen8_ppgtt_alloc_4lvl+0x5f/0x150 > > [i915] > > Jan 24 10:32:48 eric-macbookpro kernel: ppgtt_bind_vma+0x30/0x70 [i915] > > Jan 24 10:32:48 eric-macbookpro kernel: i915_vma_bind+0x68/0xd0 [i915] > > Jan 24 10:32:48 eric-macbookpro kernel: __i915_vma_do_pin+0x2d6/0x3a0 > > [i915] > > Jan 24 10:32:48 eric-macbookpro kernel: eb_lookup_vmas+0x7a2/0xb50 [i915] > > Jan 24 10:32:48 eric-macbookpro kernel: > > i915_gem_do_execbuffer+0x4d7/0x10e0 [i915] > > Jan 24 10:32:48 eric-macbookpro kernel: ? sock_wfree+0x34/0x60 > > Jan 24 10:32:48 eric-macbookpro kernel: ? > > unix_stream_read_generic+0x1f9/0x7e0 > > Jan 24 10:32:48 eric-macbookpro kernel: ? import_iovec+0x37/0xd0 > > Jan 24 10:32:48 eric-macbookpro kernel: ? i915_gem_execbuffer2+0x5d/0x390 > > [i915] > > Jan 24 10:32:48 eric-macbookpro kernel: i915_gem_execbuffer2+0x1b7/0x390 > > [i915] > > Jan 24 10:32:48 eric-macbookpro kernel: ? i915_gem_execbuffer+0x2d0/0x2d0 > > [i915] > > Jan 24 10:32:48 eric-macbookpro kernel: drm_ioctl_kernel+0x59/0xb0 [drm] > > Jan 24 10:32:48 eric-macbookpro kernel: drm_ioctl+0x2d5/0x370 [drm] > > Jan 24 10:32:48 eric-macbookpro kernel: ? i915_gem_execbuffer+0x2d0/0x2d0 > > [i915] > > Jan 24 10:32:48 eric-macbookpro kernel: ? __seccomp_filter+0x3b/0x260 > > Jan 24 10:32:48 eric-macbookpro kernel: do_vfs_ioctl+0xa1/0x610 > > Jan 24 10:32:48 eric-macbookpro kernel: ? syscall_trace_enter+0xdb/0x2b0 > > Jan 24 10:32:48 eric-macbookpro kernel: SyS_ioctl+0x74/0x80 > > Jan 24 10:32:48 eric-macbookpro kernel: do_syscall_64+0x55/0x110 > > Jan 24 10:32:48 eric-macbookpro kernel: entry_SYSCALL64_slow_path+0x25/0x25 > > Jan 24 10:32:48 eric-macbookpro kernel: RIP: 0033:0x7f584fa82d27 > > Jan 24 10:32:48 eric-macbookpro kernel: RSP: 002b:7ffee14a7828 EFLAGS: > > 0246 ORIG_RAX: 0010 > > Jan 24 10:32:48 eric-macbookpro kernel: RAX: ffda RBX: > > 03b0126a1030 RCX: 7f584fa82d27 > > Jan 24 10:32:48 eric-macbookpro kernel: RDX: 7ffee14a7870 RSI: > > 40406469 RDI: 0080 > > Jan 24 10:32:48 eric-macbookpro kernel: RBP: 7ffee14a7870 R08: > > 0002 R09: 0077 > > Jan 24 10:32:48 eric-macbookpro kernel: R10: 7f5839f2b780 R11: > > 0246 R12: 40406469 > > Jan 24 10:32:48 eric-macbookpro kernel: R13: 0080 R14: > > 7f5842b00040 R15: > > Jan 24 10:32:48 eric-macbookpro kernel: Code: 01 00 83 81 58 0a 00 00 01 48 > > 2b 05 13 9d fd c9 48 c1 f8 06 48 c1 e0 0c 48 8d 04 d0 48 8b 56 08 48 03 05 > > 0c 9d fd c9 48 83 ca 03 <48> 89 10
Re: [Intel-gfx] [PATCH 9/9] drm/i915/dp: Use the same aux retry interval as the core.
On Sat, Jan 27, 2018 at 02:49:23AM +, Dhinakaran Pandiyan wrote: > Keeps the wait times consistent. > > Cc: Rodrigo Vivi > Signed-off-by: Dhinakaran Pandiyan in case the other one goes through: Reviewed-by: Rodrigo Vivi ;) > --- > drivers/gpu/drm/i915/intel_dp.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 06619998b5a3..3c64b2e92575 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1145,9 +1145,11 @@ intel_dp_aux_ch(struct intel_dp *intel_dp, > continue; > > if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) { > - usleep_range(400, 500); > + usleep_range(DP_AUX_RETRY_INTERVAL, > + DP_AUX_RETRY_INTERVAL + 100); > continue; > } > + > if (status & DP_AUX_CH_CTL_DONE) > goto done; > } > -- > 2.14.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 1/6] drm/i915/guc: Move GuC WOPCM related code into separate files
Patch looks good to me. Minor updates suggested below with r-b. On 1/19/2018 6:59 AM, Jackie Li wrote: intel_guc_reg.h should only include definition for GuC registers and related register bits. GuC WOPCM related values should not be defined in intel_guc_reg.h This patch creates a better file structure by moving GuC WOPCM related definitions int to a new header intel_guc_wopcm.h typo "into" and moving GuC WOPCM related functions to a new source file intel_guc_wopcm.c Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Chris Wilson Cc: Joonas Lahtinen Signed-off-by: Jackie Li Reviewed-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/intel_guc.c | 11 drivers/gpu/drm/i915/intel_guc.h | 2 +- drivers/gpu/drm/i915/intel_guc_reg.h | 4 --- drivers/gpu/drm/i915/intel_guc_wopcm.c | 47 ++ drivers/gpu/drm/i915/intel_guc_wopcm.h | 39 drivers/gpu/drm/i915/intel_uc.c| 2 +- drivers/gpu/drm/i915/intel_uc_fw.c | 2 +- 8 files changed, 90 insertions(+), 18 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.c create mode 100644 drivers/gpu/drm/i915/intel_guc_wopcm.h diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index 3bddd8a..1dc9988 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -88,6 +88,7 @@ i915-y += intel_uc.o \ intel_guc_fw.o \ intel_guc_log.o \ intel_guc_submission.o \ + intel_guc_wopcm.o \ intel_huc.o # autogenerated null render state diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index ea30e7c..b8b6d4a 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -504,14 +504,3 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size) i915_gem_object_put(obj); return vma; } - -u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv) -{ - u32 wopcm_size = GUC_WOPCM_TOP; - - /* On BXT, the top of WOPCM is reserved for RC6 context */ - if (IS_GEN9_LP(dev_priv)) - wopcm_size -= BXT_GUC_WOPCM_RC6_RESERVED; - - return wopcm_size; -} diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h index 52856a9..9e0a97e 100644 --- a/drivers/gpu/drm/i915/intel_guc.h +++ b/drivers/gpu/drm/i915/intel_guc.h @@ -31,6 +31,7 @@ #include "intel_guc_ct.h" #include "intel_guc_log.h" #include "intel_guc_reg.h" +#include "intel_guc_wopcm.h" #include "intel_uc_fw.h" #include "i915_vma.h" @@ -130,6 +131,5 @@ int intel_guc_auth_huc(struct intel_guc *guc, u32 rsa_offset); int intel_guc_suspend(struct drm_i915_private *dev_priv); int intel_guc_resume(struct drm_i915_private *dev_priv); struct i915_vma *intel_guc_allocate_vma(struct intel_guc *guc, u32 size); -u32 intel_guc_wopcm_size(struct drm_i915_private *dev_priv); #endif diff --git a/drivers/gpu/drm/i915/intel_guc_reg.h b/drivers/gpu/drm/i915/intel_guc_reg.h index 19a9247..1f52fb8 100644 --- a/drivers/gpu/drm/i915/intel_guc_reg.h +++ b/drivers/gpu/drm/i915/intel_guc_reg.h @@ -68,7 +68,6 @@ #define DMA_GUC_WOPCM_OFFSET _MMIO(0xc340) #define HUC_LOADING_AGENT_VCR (0<<1) #define HUC_LOADING_AGENT_GUC (1<<1) -#define GUC_WOPCM_OFFSET_VALUE 0x8 /* 512KB */ #define GUC_MAX_IDLE_COUNT_MMIO(0xC3E4) #define HUC_STATUS2 _MMIO(0xD3B0) @@ -76,9 +75,6 @@ /* Defines WOPCM space available to GuC firmware */ #define GUC_WOPCM_SIZE_MMIO(0xc050) -/* GuC addresses below GUC_WOPCM_TOP don't map through the GTT */ -#define GUC_WOPCM_TOP (0x80 << 12)/* 512KB */ -#define BXT_GUC_WOPCM_RC6_RESERVED (0x10 << 12)/* 64KB */ /* GuC addresses above GUC_GGTT_TOP also don't map through the GTT */ #define GUC_GGTT_TOP 0xFEE0 diff --git a/drivers/gpu/drm/i915/intel_guc_wopcm.c b/drivers/gpu/drm/i915/intel_guc_wopcm.c new file mode 100644 index 000..87643a0 --- /dev/null +++ b/drivers/gpu/drm/i915/intel_guc_wopcm.c @@ -0,0 +1,47 @@ +/* + * Copyright © 2017 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDE
Re: [Intel-gfx] [PATCH 8/9] drm/dp: Export AUX_RETRY_INTERVAL
On Sat, Jan 27, 2018 at 02:49:22AM +, Dhinakaran Pandiyan wrote: > Drivers can use this in their retry loops too. with all this layers of retries it is good that we find some consistency somewhere is this written down on any part of eDP spec? Last time I saw there was different retries values on different cases. So I'm afraid this here would confuse instead of helping. > > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/drm_dp_helper.c | 12 +--- > include/drm/drm_dp_helper.h | 2 ++ > 2 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c > index ffe14ec3e7f2..0a7c8d6e7d8c 100644 > --- a/drivers/gpu/drm/drm_dp_helper.c > +++ b/drivers/gpu/drm/drm_dp_helper.c > @@ -169,8 +169,6 @@ int drm_dp_bw_code_to_link_rate(u8 link_bw) > } > EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate); > > -#define AUX_RETRY_INTERVAL 500 /* us */ > - > /** > * DOC: dp helpers > * > @@ -206,8 +204,8 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 > request, >*/ > for (retry = 0; retry < 32; retry++) { > if (ret != 0 && ret != -ETIMEDOUT) { > - usleep_range(AUX_RETRY_INTERVAL, > - AUX_RETRY_INTERVAL + 100); > + usleep_range(DP_AUX_RETRY_INTERVAL, > + DP_AUX_RETRY_INTERVAL + 100); > } > > ret = aux->transfer(aux, &msg); > @@ -718,7 +716,7 @@ static int drm_dp_i2c_retry_count(const struct > drm_dp_aux_msg *msg, > drm_dp_aux_reply_duration(msg); > int i2c_time_us = drm_dp_i2c_msg_duration(msg, i2c_speed_khz); > > - return DIV_ROUND_UP(i2c_time_us, aux_time_us + AUX_RETRY_INTERVAL); > + return DIV_ROUND_UP(i2c_time_us, aux_time_us + DP_AUX_RETRY_INTERVAL); > } > > /* > @@ -795,7 +793,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, > struct drm_dp_aux_msg *msg) >* For now just defer for long enough to hopefully be >* safe for all use-cases. >*/ > - usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + > 100); > + usleep_range(DP_AUX_RETRY_INTERVAL, > DP_AUX_RETRY_INTERVAL + 100); > continue; > > default: > @@ -827,7 +825,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, > struct drm_dp_aux_msg *msg) > aux->i2c_defer_count++; > if (defer_i2c < 7) > defer_i2c++; > - usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + > 100); > + usleep_range(DP_AUX_RETRY_INTERVAL, > DP_AUX_RETRY_INTERVAL + 100); > drm_dp_i2c_msg_write_status_update(msg); > > continue; > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index c239e6e24a10..2eae1aed2d26 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -61,6 +61,8 @@ > #define DP_AUX_I2C_REPLY_DEFER (0x2 << 2) > #define DP_AUX_I2C_REPLY_MASK(0x3 << 2) > > +#define DP_AUX_RETRY_INTERVAL500 /* us */ > + > /* AUX CH addresses */ > /* DPCD */ > #define DP_DPCD_REV 0x000 > -- > 2.14.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/9] drm/i915/psr: Extract PSR DPCD initialization and move it to intel_psr.c
On Wed, Jan 31, 2018 at 10:38:24AM +, David Weinehall wrote: > On Fri, Jan 26, 2018 at 06:49:17PM -0800, Dhinakaran Pandiyan wrote: > > intel_edp_init_dpcd() is cluttered with PSR specific DPCD checks and > > intel_dp.c is huge. > > Yes please! Good idea. > > > No functional change intended. > > Reviewed-by: David Weinehall Acked-by: Rodrigo Vivi > > > Cc: Rodrigo Vivi > > Signed-off-by: Dhinakaran Pandiyan > > --- > > drivers/gpu/drm/i915/intel_dp.c | 64 + > > drivers/gpu/drm/i915/intel_drv.h | 1 + > > drivers/gpu/drm/i915/intel_psr.c | 68 > > > > 3 files changed, 70 insertions(+), 63 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > b/drivers/gpu/drm/i915/intel_dp.c > > index a2e88715..2454326690fb 100644 > > --- a/drivers/gpu/drm/i915/intel_dp.c > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > @@ -3135,35 +3135,6 @@ intel_dp_get_link_status(struct intel_dp *intel_dp, > > uint8_t link_status[DP_LINK_ > > DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE; > > } > > > > -static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp) > > -{ > > - uint8_t psr_caps = 0; > > - > > - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_CAPS, &psr_caps) != 1) > > - return false; > > - return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED; > > -} > > - > > -static bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp) > > -{ > > - uint8_t dprx = 0; > > - > > - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST, > > - &dprx) != 1) > > - return false; > > - return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED; > > -} > > - > > -static bool intel_dp_get_alpm_status(struct intel_dp *intel_dp) > > -{ > > - uint8_t alpm_caps = 0; > > - > > - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_RECEIVER_ALPM_CAP, > > - &alpm_caps) != 1) > > - return false; > > - return alpm_caps & DP_ALPM_CAP; > > -} > > - > > /* These are source-specific values. */ > > uint8_t > > intel_dp_voltage_max(struct intel_dp *intel_dp) > > @@ -3714,40 +3685,7 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp) > > dev_priv->no_aux_handshake = intel_dp->dpcd[DP_MAX_DOWNSPREAD] & > > DP_NO_AUX_HANDSHAKE_LINK_TRAINING; > > > > - /* Check if the panel supports PSR */ > > - drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT, > > -intel_dp->psr_dpcd, > > -sizeof(intel_dp->psr_dpcd)); > > - if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) { > > - dev_priv->psr.sink_support = true; > > - DRM_DEBUG_KMS("Detected EDP PSR Panel.\n"); > > - } > > - > > - if (INTEL_GEN(dev_priv) >= 9 && > > - (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) { > > - uint8_t frame_sync_cap; > > - > > - dev_priv->psr.sink_support = true; > > - if (drm_dp_dpcd_readb(&intel_dp->aux, > > - DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP, > > - &frame_sync_cap) != 1) > > - frame_sync_cap = 0; > > - dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false; > > - /* PSR2 needs frame sync as well */ > > - dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync; > > - DRM_DEBUG_KMS("PSR2 %s on sink", > > - dev_priv->psr.psr2_support ? "supported" : "not > > supported"); > > - > > - if (dev_priv->psr.psr2_support) { > > - dev_priv->psr.y_cord_support = > > - intel_dp_get_y_cord_status(intel_dp); > > - dev_priv->psr.colorimetry_support = > > - intel_dp_get_colorimetry_status(intel_dp); > > - dev_priv->psr.alpm = > > - intel_dp_get_alpm_status(intel_dp); > > - } > > - > > - } > > + intel_psr_init_dpcd(intel_dp); > > > > /* > > * Read the eDP display control registers. > > diff --git a/drivers/gpu/drm/i915/intel_drv.h > > b/drivers/gpu/drm/i915/intel_drv.h > > index 3cee54bc0352..a340bc04dad8 100644 > > --- a/drivers/gpu/drm/i915/intel_drv.h > > +++ b/drivers/gpu/drm/i915/intel_drv.h > > @@ -1851,6 +1851,7 @@ bool is_hdcp_supported(struct drm_i915_private > > *dev_priv, enum port port); > > > > /* intel_psr.c */ > > #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support) > > +void intel_psr_init_dpcd(struct intel_dp *intel_dp); > > void intel_psr_enable(struct intel_dp *intel_dp, > > const struct intel_crtc_state *crtc_state); > > void intel_psr_disable(struct intel_dp *intel_dp, > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > > b/drivers/gpu/drm/i915/intel_psr.c > > index c12af1118647..a1b878449e83 100644 > > --- a/drivers/gpu/drm/i915/intel_psr.c > >
Re: [Intel-gfx] [PATCH 1/9] drm/i915/psr: Do not activate PSR on frontbuffer flush from fbdev.
On Sat, Jan 27, 2018 at 02:49:15AM +, Dhinakaran Pandiyan wrote: > There is no corresponding invalidate call before the buffer is written > to, this results in screen freezing sometime after switching to console > mode with PSR enabled. Invalidating the front buffer in the fbdev call > backs won't work either as some of them are called in atomic contexts and > {drrs, fbc, psr}_invalidate all sleep. So don't activate PSR for now. > > Cc: Rodrigo Vivi > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_psr.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > b/drivers/gpu/drm/i915/intel_psr.c > index e9feffdea899..c12af1118647 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -881,6 +881,9 @@ void intel_psr_flush(struct drm_i915_private *dev_priv, > if (!CAN_PSR(dev_priv)) > return; > > + if (origin == ORIGIN_DIRTYFB) > + return; > + I'd like Paulo to take a look here. What I'm confused now is who (what fbt bit) is actually blocking PSR to work on fbdev. And what would be the risks of other corner cases or the risk of this not getting psr re-enabled until next reboot... > mutex_lock(&dev_priv->psr.lock); > if (!dev_priv->psr.enabled) { > mutex_unlock(&dev_priv->psr.lock); > -- > 2.14.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/9] drm/i915/psr: Check for the specific AUX_FRAME_SYNC cap bit.
On Sat, Jan 27, 2018 at 02:49:18AM +, Dhinakaran Pandiyan wrote: > The cap check should be specifically for bit 0 instead of any bit. > Any "Fixes:" ? > Cc: Rodrigo Vivi > Signed-off-by: Dhinakaran Pandiyan Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_psr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > b/drivers/gpu/drm/i915/intel_psr.c > index a1b878449e83..83874bcd1142 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -107,7 +107,7 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp) > DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP, > &frame_sync_cap) != 1) > frame_sync_cap = 0; > - dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false; > + dev_priv->psr.aux_frame_sync = frame_sync_cap & > DP_AUX_FRAME_SYNC_CAP; > /* PSR2 needs frame sync as well */ > dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync; > DRM_DEBUG_KMS("PSR2 %s on sink", > -- > 2.14.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/9] drm/i915/frontbuffer: Mark frontbuffer flush and invalidate with might_sleep()
On Sat, Jan 27, 2018 at 02:49:16AM +, Dhinakaran Pandiyan wrote: > Frontbuffer flush and invalidate call psr, fbc and drrs functions that use > mutexes but they can be called in atomic contexts in the fbdev path. The > point where the spinlocks are acquired is up in the call stack that is not > entirely easy to spot, so annotate with might_sleep(). > makes sense > Cc: Rodrigo Vivi > Signed-off-by: Dhinakaran Pandiyan Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_frontbuffer.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c > b/drivers/gpu/drm/i915/intel_frontbuffer.c > index fcfc217e754e..3a8d3d06c26a 100644 > --- a/drivers/gpu/drm/i915/intel_frontbuffer.c > +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c > @@ -79,6 +79,7 @@ void __intel_fb_obj_invalidate(struct drm_i915_gem_object > *obj, > spin_unlock(&dev_priv->fb_tracking.lock); > } > > + might_sleep(); > intel_psr_invalidate(dev_priv, frontbuffer_bits); > intel_edp_drrs_invalidate(dev_priv, frontbuffer_bits); > intel_fbc_invalidate(dev_priv, frontbuffer_bits, origin); > @@ -108,6 +109,7 @@ static void intel_frontbuffer_flush(struct > drm_i915_private *dev_priv, > if (!frontbuffer_bits) > return; > > + might_sleep(); > intel_edp_drrs_flush(dev_priv, frontbuffer_bits); > intel_psr_flush(dev_priv, frontbuffer_bits, origin); > intel_fbc_flush(dev_priv, frontbuffer_bits, origin); > -- > 2.14.1 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Respect VBT max dp rate.
On Wed, 2018-01-31 at 21:22 -0800, Rodrigo Vivi wrote: > On Thu, Feb 01, 2018 at 02:53:20AM +, Pandiyan, Dhinakaran wrote: > > > > > > > > On Wed, 2018-01-31 at 13:20 -0800, Rodrigo Vivi wrote: > > > Since commit 'c4fb60b9aba9 ("drm/i915/bios: add DP max link > > > rate to VBT child device struct")' we have the new entry > > > defined for max dp rate that is in use for CNL. > > > > > > Let's start using it for all VBT 216+ and > > > also organize the cnl adjusted rates in terms of rate > > > and not array size. > > > > > > Cc: Jani Nikula > > > Cc: Ville Syrjälä > > > Signed-off-by: Rodrigo Vivi > > > --- > > > drivers/gpu/drm/i915/i915_drv.h | 1 + > > > drivers/gpu/drm/i915/intel_bios.c | 3 +++ > > > drivers/gpu/drm/i915/intel_dp.c | 37 > > > + > > > 3 files changed, 33 insertions(+), 8 deletions(-) > > > > > > > > > +static int intel_dp_adjusted_max_rate(struct intel_dp *intel_dp) > > > +{ > > > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); > > > + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev); > > > + const struct ddi_vbt_port_info *info = > > > + &dev_priv->vbt.ddi_port_info[dig_port->base.port]; > > > + > > > + if (info->dp_max_link_rate) > > > + return info->dp_max_link_rate; > > > > What if this value is higher than cnl_adjusted_max_rate() ? > > Then VBT knows something about that SKU that we don't?! *shrug* > I have very little idea of how reliable VBT's are on SDP's or if they are always updated with the correct values. Having those fall back checks based on SKU and ports, which we know are definite HW limits, I feel is safer. However, I'll leave this to you as my knowledge is fairly limited. > My understanding is that the purpose of that new VBT field is > to workaround bugs they know for certain combination and limit > the max rate even more. > > bugs like the one I had in a part here: > > https://bugs.freedesktop.org/show_bug.cgi?id=103963 > > in this case flicker was gone by limiting the max rate. > > But yeap, maybe vbt is bugged, so are you suggesting min(vbt, bspec) ? Yes. > > > > > -DK > > > > > > > + > > > + if (IS_CANNONLAKE(dev_priv)) > > > + return cnl_adjusted_max_rate(intel_dp); > > > + > > > + return INT_MAX; /* No adjusted limit */ > > > } > > > > > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] CI igt-all on drm-intel-next-fixes gem_exec_* and other gem_*
Hi guys, As we run more rounds of CI on drm-intel-next-fixes a standard gets visible there. This round of dinf started with CI_DINF_90. Specially gem_exec_* but also other gem_* tests fails randomly on gen9 platforms: https://intel-gfx-ci.01.org/tree/drm-intel-next-fixes/shards.html (last 5 columns of gen9 platforms) while it is pure clean green on drm-tip: https://intel-gfx-ci.01.org/tree/drm-tip/shards-all.html From the logs I looked it seems that it is always during hibernation and most of the times some strange page faults and also not only i915: <6>[ 36.647941] PM: Image saving progress: 70% <3>[ 36.707234] e1000e :00:1f.6 eno1: Detected Hardware Unit Hang: Do you know what could justify this difference? Is there anything we could we be missing on our side? Thanks, Rodrigo. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Respect VBT max dp rate.
On Thu, Feb 01, 2018 at 02:53:20AM +, Pandiyan, Dhinakaran wrote: > > > > On Wed, 2018-01-31 at 13:20 -0800, Rodrigo Vivi wrote: > > Since commit 'c4fb60b9aba9 ("drm/i915/bios: add DP max link > > rate to VBT child device struct")' we have the new entry > > defined for max dp rate that is in use for CNL. > > > > Let's start using it for all VBT 216+ and > > also organize the cnl adjusted rates in terms of rate > > and not array size. > > > > Cc: Jani Nikula > > Cc: Ville Syrjälä > > Signed-off-by: Rodrigo Vivi > > --- > > drivers/gpu/drm/i915/i915_drv.h | 1 + > > drivers/gpu/drm/i915/intel_bios.c | 3 +++ > > drivers/gpu/drm/i915/intel_dp.c | 37 > > + > > 3 files changed, 33 insertions(+), 8 deletions(-) > > > > > +static int intel_dp_adjusted_max_rate(struct intel_dp *intel_dp) > > +{ > > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); > > + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev); > > + const struct ddi_vbt_port_info *info = > > + &dev_priv->vbt.ddi_port_info[dig_port->base.port]; > > + > > + if (info->dp_max_link_rate) > > + return info->dp_max_link_rate; > > What if this value is higher than cnl_adjusted_max_rate() ? Then VBT knows something about that SKU that we don't?! *shrug* My understanding is that the purpose of that new VBT field is to workaround bugs they know for certain combination and limit the max rate even more. bugs like the one I had in a part here: https://bugs.freedesktop.org/show_bug.cgi?id=103963 in this case flicker was gone by limiting the max rate. But yeap, maybe vbt is bugged, so are you suggesting min(vbt, bspec) ? > > -DK > > > > + > > + if (IS_CANNONLAKE(dev_priv)) > > + return cnl_adjusted_max_rate(intel_dp); > > + > > + return INT_MAX; /* No adjusted limit */ > > } > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Respect VBT max dp rate.
On Wed, 2018-01-31 at 13:20 -0800, Rodrigo Vivi wrote: > Since commit 'c4fb60b9aba9 ("drm/i915/bios: add DP max link > rate to VBT child device struct")' we have the new entry > defined for max dp rate that is in use for CNL. > > Let's start using it for all VBT 216+ and > also organize the cnl adjusted rates in terms of rate > and not array size. > > Cc: Jani Nikula > Cc: Ville Syrjälä > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/intel_bios.c | 3 +++ > drivers/gpu/drm/i915/intel_dp.c | 37 + > 3 files changed, 33 insertions(+), 8 deletions(-) > +static int intel_dp_adjusted_max_rate(struct intel_dp *intel_dp) > +{ > + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); > + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev); > + const struct ddi_vbt_port_info *info = > + &dev_priv->vbt.ddi_port_info[dig_port->base.port]; > + > + if (info->dp_max_link_rate) > + return info->dp_max_link_rate; What if this value is higher than cnl_adjusted_max_rate() ? -DK > + > + if (IS_CANNONLAKE(dev_priv)) > + return cnl_adjusted_max_rate(intel_dp); > + > + return INT_MAX; /* No adjusted limit */ > } > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10] drm/i915/icl: Gen11 forcewake support
From: Daniele Ceraolo Spurio The main difference with previous GENs is that starting from Gen11 each VCS and VECS engine has its own power well, which only exist if the related engine exists in the HW. The fallback forcewake request workaround is only needed on gen9 according to the HSDES WA entry (1604254524), so we can go back to using the simpler fw_domains_get/put functions. BSpec: 18331 v2: fix fwtable, use array to test shadow tables, create new accessors to avoid check on every access (Tvrtko) v3 (from Paulo): Rebase. v4: - Range 09400-097FF should be FORCEWAKE_ALL (Daniele) - Use the BIT macro for forcewake domains (Daniele) - Add a comment about the range ordering (Oscar) - Updated commit message (Oscar) v5: Rebased v6: Use I915_MAX_VCS/VECS (Michal) v7: translate FORCEWAKE_ALL to available domains v8: rebase, add clarification on fallback ack in commit message. v9: fix rebase issue, change check in fw_domains_init from IS_GEN11 to GEN >= 11 v10: Generate is_genX_shadowed with a macro (Daniele) Include gen11_fw_ranges in the selftest (Michel) Cc: Michal Wajdeczko Cc: Tvrtko Ursulin Cc: Paulo Zanoni Acked-by: Michel Thierry Signed-off-by: Daniele Ceraolo Spurio Signed-off-by: Oscar Mateo Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_uncore.c | 155 -- drivers/gpu/drm/i915/intel_uncore.h | 27 - drivers/gpu/drm/i915/selftests/intel_uncore.c | 31 -- 4 files changed, 193 insertions(+), 24 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index d29e8a0e2ca3..eaca12292ffe 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -8015,9 +8015,13 @@ enum { #define VLV_GTLC_PW_RENDER_STATUS_MASK (1 << 7) #define FORCEWAKE_MT _MMIO(0xa188) /* multi-threaded */ #define FORCEWAKE_MEDIA_GEN9 _MMIO(0xa270) +#define FORCEWAKE_MEDIA_VDBOX_GEN11(n)_MMIO(0xa540 + (n) * 4) +#define FORCEWAKE_MEDIA_VEBOX_GEN11(n)_MMIO(0xa560 + (n) * 4) #define FORCEWAKE_RENDER_GEN9 _MMIO(0xa278) #define FORCEWAKE_BLITTER_GEN9_MMIO(0xa188) #define FORCEWAKE_ACK_MEDIA_GEN9 _MMIO(0x0D88) +#define FORCEWAKE_ACK_MEDIA_VDBOX_GEN11(n)_MMIO(0x0D50 + (n) * 4) +#define FORCEWAKE_ACK_MEDIA_VEBOX_GEN11(n)_MMIO(0x0D70 + (n) * 4) #define FORCEWAKE_ACK_RENDER_GEN9 _MMIO(0x0D84) #define FORCEWAKE_ACK_BLITTER_GEN9_MMIO(0x130044) #define FORCEWAKE_KERNEL BIT(0) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index 164dbb8cfa36..c1953043604b 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -37,6 +37,12 @@ static const char * const forcewake_domain_names[] = { "render", "blitter", "media", + "vdbox0", + "vdbox1", + "vdbox2", + "vdbox3", + "vebox0", + "vebox1", }; const char * @@ -773,6 +779,8 @@ void assert_forcewakes_active(struct drm_i915_private *dev_priv, /* We give fast paths for the really cool registers */ #define NEEDS_FORCE_WAKE(reg) ((reg) < 0x4) +#define GEN11_NEEDS_FORCE_WAKE(reg) \ + ((reg) < 0x4 || ((reg) >= 0x1c && (reg) < 0x1dc000)) #define __gen6_reg_read_fw_domains(offset) \ ({ \ @@ -826,6 +834,14 @@ find_fw_domain(struct drm_i915_private *dev_priv, u32 offset) if (!entry) return 0; + /* +* The list of FW domains depends on the SKU in gen11+ so we +* can't determine it statically. We use FORCEWAKE_ALL and +* translate it here to the list of available domains. +*/ + if (entry->domains == FORCEWAKE_ALL) + return dev_priv->uncore.fw_domains; + WARN(entry->domains & ~dev_priv->uncore.fw_domains, "Uninitialized forcewake domain(s) 0x%x accessed at 0x%x\n", entry->domains & ~dev_priv->uncore.fw_domains, offset); @@ -860,6 +876,14 @@ static const struct intel_forcewake_range __vlv_fw_ranges[] = { __fwd; \ }) +#define __gen11_fwtable_reg_read_fw_domains(offset) \ +({ \ + enum forcewake_domains __fwd = 0; \ + if (GEN11_NEEDS_FORCE_WAKE((offset))) \ + __fwd = find_fw_domain(dev_priv, offset); \ + __fwd; \ +}) + /* *Must* be sorted by offset! See intel_shadow_table_check(). */ static const i915_reg_t gen8_shadowed_regs[] = { RING_TAIL(RENDER_RING_BASE),/* 0x2000 (base) */ @@ -871,6 +895,20 @@ static const i915_reg_t gen8_shadowed_regs[] = { /* TODO: Other registers are not yet used */ }; +static const i915_reg_t gen11_shadowed_regs[] = { + RING_TAIL(RENDER_RING_BASE),/* 0x2000 (base) */ + GEN6_RPNSWREQ, /* 0
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/ppgtt: Pin page directories before allocation
== Series Details == Series: series starting with [1/2] drm/i915/ppgtt: Pin page directories before allocation URL : https://patchwork.freedesktop.org/series/37443/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-shrfb-pgflip-blt: fail -> PASS (shard-apl) fdo#101623 +2 Subgroup fbc-rgb101010-draw-mmap-gtt: skip -> PASS (shard-apl) Subgroup fbc-1p-primscrn-spr-indfb-draw-render: skip -> PASS (shard-apl) fdo#103167 +1 Test kms_sysfs_edid_timing: warn -> PASS (shard-apl) fdo#100047 Test kms_vblank: Subgroup crtc-id: skip -> PASS (shard-apl) Subgroup pipe-c-ts-continuation-suspend: dmesg-warn -> PASS (shard-apl) Subgroup pipe-a-query-busy: skip -> PASS (shard-apl) Subgroup pipe-b-accuracy-idle: skip -> PASS (shard-apl) Subgroup pipe-c-wait-forked-busy: skip -> PASS (shard-apl) Test kms_cursor_legacy: Subgroup cursora-vs-flipa-atomic: skip -> PASS (shard-apl) Subgroup basic-flip-after-cursor-varying-size: skip -> PASS (shard-apl) fdo#102670 Test kms_cursor_crc: Subgroup cursor-128x42-random: skip -> PASS (shard-apl) Subgroup cursor-256x256-rapid-movement: skip -> PASS (shard-apl) fdo#103326 Subgroup cursor-256x256-dpms: skip -> PASS (shard-apl) Test gem_eio: Subgroup in-flight: fail -> PASS (shard-hsw) fdo#104676 +1 Test kms_plane_multiple: Subgroup atomic-pipe-b-tiling-yf: fail -> PASS (shard-apl) Subgroup legacy-pipe-a-tiling-x: skip -> PASS (shard-apl) Test kms_flip: Subgroup basic-plain-flip: skip -> PASS (shard-apl) Test kms_draw_crc: Subgroup draw-method-xrgb-render-untiled: skip -> PASS (shard-apl) Subgroup draw-method-xrgb2101010-render-xtiled: skip -> PASS (shard-apl) Test kms_color: Subgroup pipe-a-ctm-0-75: skip -> PASS (shard-apl) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-c-frame-sequence: skip -> PASS (shard-apl) fdo#103481 Subgroup read-crc-pipe-c: skip -> PASS (shard-apl) fdo#103191 Subgroup read-crc-pipe-a: skip -> PASS (shard-apl) Test kms_busy: Subgroup extended-modeset-hang-newfb-with-reset-render-c: skip -> PASS (shard-apl) Subgroup extended-modeset-hang-oldfb-with-reset-render-c: skip -> PASS (shard-apl) fdo#103336 Test kms_plane_scaling: Subgroup pipe-c-plane-scaling: skip -> PASS (shard-apl) Test kms_rotation_crc: Subgroup primary-rotation-90-y-tiled: skip -> PASS (shard-apl) Test kms_chv_cursor_fail: Subgroup pipe-a-128x128-bottom-edge: skip -> PASS (shard-apl) Test kms_rmfb: Subgroup rmfb-ioctl: skip -> PASS (shard-apl) Test kms_ccs: Subgroup pipe-b-bad-pixel-format: skip -> PASS (shard-apl) fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#103326 https://bugs.freedesktop.org/show_bug.cgi?id=103326 fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103336 https://bugs.freedesktop.org/show_bug.cgi?id=103336 shard-apltotal:2838 pass:1749 dwarn:1 dfail:0 fail:24 skip:1064 time:12591s shard-hswtotal:2838 pass:1734 dwarn:1 dfail:0 fail:12 skip:1090 time:11981s shard-snbtotal:2838 pass:1330 dwarn:1 dfail:0 fail:10 skip:1497 time:6536s Blacklisted hosts: shard-kbltotal:2838 pass:1860 dwarn:11 dfail:0 fail:24 skip:943 time:9703s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7845/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cnl: Respect VBT max dp rate.
== Series Details == Series: drm/i915/cnl: Respect VBT max dp rate. URL : https://patchwork.freedesktop.org/series/37441/ State : success == Summary == Test kms_sysfs_edid_timing: warn -> PASS (shard-apl) fdo#100047 Test kms_flip: Subgroup modeset-vs-vblank-race-interruptible: pass -> FAIL (shard-snb) fdo#103060 +1 Subgroup basic-plain-flip: skip -> PASS (shard-apl) Subgroup wf_vblank-ts-check-interruptible: fail -> PASS (shard-apl) fdo#100368 Test gem_eio: Subgroup in-flight-suspend: pass -> FAIL (shard-hsw) fdo#104676 +1 Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-shrfb-pgflip-blt: fail -> PASS (shard-apl) fdo#101623 +2 Subgroup fbc-1p-primscrn-spr-indfb-draw-render: skip -> PASS (shard-apl) fdo#103167 +1 Subgroup fbc-rgb101010-draw-mmap-gtt: skip -> PASS (shard-apl) Test kms_plane_multiple: Subgroup atomic-pipe-b-tiling-yf: fail -> PASS (shard-apl) Subgroup legacy-pipe-a-tiling-x: skip -> PASS (shard-apl) Test perf: Subgroup enable-disable: pass -> FAIL (shard-apl) fdo#103715 Subgroup oa-exponents: fail -> PASS (shard-apl) fdo#102254 Test kms_vblank: Subgroup pipe-c-ts-continuation-suspend: dmesg-warn -> PASS (shard-apl) Subgroup pipe-a-query-busy: skip -> PASS (shard-apl) Subgroup pipe-b-accuracy-idle: skip -> PASS (shard-apl) Subgroup pipe-c-wait-forked-busy: skip -> PASS (shard-apl) Subgroup crtc-id: skip -> PASS (shard-apl) Test kms_draw_crc: Subgroup draw-method-xrgb-render-untiled: skip -> PASS (shard-apl) Subgroup draw-method-xrgb2101010-render-xtiled: skip -> PASS (shard-apl) Test kms_color: Subgroup pipe-a-ctm-0-75: skip -> PASS (shard-apl) Test kms_cursor_crc: Subgroup cursor-256x256-rapid-movement: skip -> PASS (shard-apl) fdo#103326 Subgroup cursor-256x256-dpms: skip -> PASS (shard-apl) Subgroup cursor-128x42-random: skip -> PASS (shard-apl) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-c-frame-sequence: skip -> PASS (shard-apl) fdo#103481 Subgroup read-crc-pipe-c: skip -> PASS (shard-apl) fdo#103191 Subgroup read-crc-pipe-a: skip -> PASS (shard-apl) Test kms_busy: Subgroup extended-modeset-hang-newfb-with-reset-render-c: skip -> PASS (shard-apl) Subgroup extended-modeset-hang-oldfb-with-reset-render-c: skip -> PASS (shard-apl) fdo#103336 Test kms_plane_scaling: Subgroup pipe-c-plane-scaling: skip -> PASS (shard-apl) Test kms_rotation_crc: Subgroup primary-rotation-90-y-tiled: skip -> PASS (shard-apl) Test kms_cursor_legacy: Subgroup basic-flip-after-cursor-varying-size: skip -> PASS (shard-apl) fdo#102670 Subgroup cursora-vs-flipa-atomic: skip -> PASS (shard-apl) Test kms_chv_cursor_fail: Subgroup pipe-a-128x128-bottom-edge: skip -> PASS (shard-apl) Test kms_rmfb: Subgroup rmfb-ioctl: skip -> PASS (shard-apl) Test kms_ccs: Subgroup pipe-b-bad-pixel-format: skip -> PASS (shard-apl) fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715 fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254 fdo#103326 https://bugs.freedesktop.org/show_bug.cgi?id=103326 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103336 https://bugs.freedesktop.org/show_bug.cgi?id=103336 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 shard-apltotal:2838 pass:1750 dwarn:1 dfail:0 fail:23 skip:1064 time:12621s shard-hswtotal:2838 pass:1733 dwarn:1 dfail:0 fail:13
Re: [Intel-gfx] [PATCH 1/2] drm/i915/ppgtt: Pin page directories before allocation
On 31 January 2018 at 21:44, Chris Wilson wrote: > Commit e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes") > believed that because it did not insert its freshly allocated page > directory into the pd tree, it was safe from the shrinker. I failed to > heed the lesson learnt from commit dd19674bacba ("drm/i915: Remove bitmap > tracking for used-ptes") that we need to pin all the levels in the tree > before hitting the shrinker or else the shrinker may free an upper layer > as we proceed to allocate the tree. Thus leaving dangling pointers > everywhere and a GPF should we hit direct reclaim at just the wrong > moment. > > Jan 24 10:32:48 eric-macbookpro kernel: CPU: 0 PID: 7374 Comm: chromium > Tainted: P O4.14.13-1-ARCH #1 > Jan 24 10:32:48 eric-macbookpro kernel: Hardware name: Apple Inc. > MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B33.1706181928 > 06/18/2017 > Jan 24 10:32:48 eric-macbookpro kernel: task: 994f696c2c40 task.stack: > b1a789d4c000 > Jan 24 10:32:48 eric-macbookpro kernel: RIP: > 0010:gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] > Jan 24 10:32:48 eric-macbookpro kernel: RSP: 0018:b1a789d4f940 EFLAGS: > 00010206 > Jan 24 10:32:48 eric-macbookpro kernel: RAX: 81c1788cc4f68138 RBX: > 994f54db8000 RCX: 994f696c2c40 > Jan 24 10:32:48 eric-macbookpro kernel: RDX: 00023bc73003 RSI: > 994d598b6b80 RDI: 994f54db8000 > Jan 24 10:32:48 eric-macbookpro kernel: RBP: 994d598b6b80 R08: > R09: > Jan 24 10:32:48 eric-macbookpro kernel: R10: b1a789d4f550 R11: > 994eaf3c3208 R12: 0027 > Jan 24 10:32:48 eric-macbookpro kernel: R13: 5000 R14: > 04e8f000 R15: 994f54dba000 > Jan 24 10:32:48 eric-macbookpro kernel: FS: 7f585886aa00() > GS:994faec0() knlGS: > Jan 24 10:32:48 eric-macbookpro kernel: CS: 0010 DS: ES: CR0: > 80050033 > Jan 24 10:32:48 eric-macbookpro kernel: CR2: 004ac8e8 CR3: > 0002552c8004 CR4: 003606f0 > Jan 24 10:32:48 eric-macbookpro kernel: Call Trace: > Jan 24 10:32:48 eric-macbookpro kernel: gen8_ppgtt_alloc_pdp+0x178/0x320 > [i915] > Jan 24 10:32:48 eric-macbookpro kernel: gen8_ppgtt_alloc_4lvl+0x5f/0x150 > [i915] > Jan 24 10:32:48 eric-macbookpro kernel: ppgtt_bind_vma+0x30/0x70 [i915] > Jan 24 10:32:48 eric-macbookpro kernel: i915_vma_bind+0x68/0xd0 [i915] > Jan 24 10:32:48 eric-macbookpro kernel: __i915_vma_do_pin+0x2d6/0x3a0 [i915] > Jan 24 10:32:48 eric-macbookpro kernel: eb_lookup_vmas+0x7a2/0xb50 [i915] > Jan 24 10:32:48 eric-macbookpro kernel: i915_gem_do_execbuffer+0x4d7/0x10e0 > [i915] > Jan 24 10:32:48 eric-macbookpro kernel: ? sock_wfree+0x34/0x60 > Jan 24 10:32:48 eric-macbookpro kernel: ? > unix_stream_read_generic+0x1f9/0x7e0 > Jan 24 10:32:48 eric-macbookpro kernel: ? import_iovec+0x37/0xd0 > Jan 24 10:32:48 eric-macbookpro kernel: ? i915_gem_execbuffer2+0x5d/0x390 > [i915] > Jan 24 10:32:48 eric-macbookpro kernel: i915_gem_execbuffer2+0x1b7/0x390 > [i915] > Jan 24 10:32:48 eric-macbookpro kernel: ? i915_gem_execbuffer+0x2d0/0x2d0 > [i915] > Jan 24 10:32:48 eric-macbookpro kernel: drm_ioctl_kernel+0x59/0xb0 [drm] > Jan 24 10:32:48 eric-macbookpro kernel: drm_ioctl+0x2d5/0x370 [drm] > Jan 24 10:32:48 eric-macbookpro kernel: ? i915_gem_execbuffer+0x2d0/0x2d0 > [i915] > Jan 24 10:32:48 eric-macbookpro kernel: ? __seccomp_filter+0x3b/0x260 > Jan 24 10:32:48 eric-macbookpro kernel: do_vfs_ioctl+0xa1/0x610 > Jan 24 10:32:48 eric-macbookpro kernel: ? syscall_trace_enter+0xdb/0x2b0 > Jan 24 10:32:48 eric-macbookpro kernel: SyS_ioctl+0x74/0x80 > Jan 24 10:32:48 eric-macbookpro kernel: do_syscall_64+0x55/0x110 > Jan 24 10:32:48 eric-macbookpro kernel: entry_SYSCALL64_slow_path+0x25/0x25 > Jan 24 10:32:48 eric-macbookpro kernel: RIP: 0033:0x7f584fa82d27 > Jan 24 10:32:48 eric-macbookpro kernel: RSP: 002b:7ffee14a7828 EFLAGS: > 0246 ORIG_RAX: 0010 > Jan 24 10:32:48 eric-macbookpro kernel: RAX: ffda RBX: > 03b0126a1030 RCX: 7f584fa82d27 > Jan 24 10:32:48 eric-macbookpro kernel: RDX: 7ffee14a7870 RSI: > 40406469 RDI: 0080 > Jan 24 10:32:48 eric-macbookpro kernel: RBP: 7ffee14a7870 R08: > 0002 R09: 0077 > Jan 24 10:32:48 eric-macbookpro kernel: R10: 7f5839f2b780 R11: > 0246 R12: 40406469 > Jan 24 10:32:48 eric-macbookpro kernel: R13: 0080 R14: > 7f5842b00040 R15: > Jan 24 10:32:48 eric-macbookpro kernel: Code: 01 00 83 81 58 0a 00 00 01 48 > 2b 05 13 9d fd c9 48 c1 f8 06 48 c1 e0 0c 48 8d 04 d0 48 8b 56 08 48 03 05 0c > 9d fd c9 48 83 ca 03 <48> 89 10 83 a9 58 0a 00 00 01 65 ff 0d 37 03 fb 3e 74 > 02 f3 c3 > Jan 24 10:32:48 eric-macbookpro kernel: RIP: > gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] RSP: b1a789d4f940 > > Bugzilla: https://bugs.freedesktop.org/sh
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/ppgtt: Pin page directories before allocation
== Series Details == Series: series starting with [1/2] drm/i915/ppgtt: Pin page directories before allocation URL : https://patchwork.freedesktop.org/series/37443/ State : success == Summary == Series 37443v1 series starting with [1/2] drm/i915/ppgtt: Pin page directories before allocation https://patchwork.freedesktop.org/api/1.0/series/37443/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test gem_ringfill: Subgroup basic-default-hang: dmesg-warn -> PASS (fi-pnv-d510) fdo#101600 Test kms_chamelium: Subgroup common-hpd-after-suspend: dmesg-warn -> PASS (fi-skl-6700k2) fdo#104108 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:417s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:423s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:374s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:494s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:281s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:480s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:483s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:464s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:454s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:561s fi-elk-e7500 total:224 pass:168 dwarn:9 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:278s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:507s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:388s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:397s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:410s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:460s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:411s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:455s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:496s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:452s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:498s fi-pnv-d510 total:288 pass:223 dwarn:0 dfail:0 fail:0 skip:65 time:558s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:423s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:504s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:522s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:483s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:484s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:415s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:433s fi-snb-2520m total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:392s Blacklisted hosts: fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:468s ae93f9b9acf3e9cdbb2be1b68a97c3cc6db66fad drm-tip: 2018y-01m-31d-16h-31m-38s UTC integration manifest add3c702303a drm/i915/selftests: add missing gtt shrinker test 3cdd2f49d2d9 drm/i915/ppgtt: Pin page directories before allocation == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7845/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cnl: Respect VBT max dp rate.
== Series Details == Series: drm/i915/cnl: Respect VBT max dp rate. URL : https://patchwork.freedesktop.org/series/37441/ State : success == Summary == Series 37441v1 drm/i915/cnl: Respect VBT max dp rate. https://patchwork.freedesktop.org/api/1.0/series/37441/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 Test kms_chamelium: Subgroup common-hpd-after-suspend: dmesg-warn -> PASS (fi-skl-6700k2) fdo#104108 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:418s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:425s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:372s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:488s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:282s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:481s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:486s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:471s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:463s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:566s fi-elk-e7500 total:224 pass:168 dwarn:9 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:298s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:512s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:391s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:413s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:452s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:421s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:455s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:502s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:456s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:499s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:582s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:432s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:511s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:528s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:487s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:483s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:416s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:431s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:550s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:402s Blacklisted hosts: fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:465s ae93f9b9acf3e9cdbb2be1b68a97c3cc6db66fad drm-tip: 2018y-01m-31d-16h-31m-38s UTC integration manifest bd80bbf3d0d9 drm/i915/cnl: Respect VBT max dp rate. == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7844/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/selftests: add missing gtt shrinker test
From: Matthew Auld Try to catch a bug we've seen in the wild where the shrinker purges the pd/pdp from under us while allocating our paging structures. References: https://bugs.freedesktop.org/show_bug.cgi?id=104773 Signed-off-by: Matthew Auld Cc: Chris Wilson Reviewed-by: Chris Wilson Signed-off-by: Chris Wilson Link: https://patchwork.freedesktop.org/patch/msgid/20180131191453.12676-1-matthew.a...@intel.com --- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 84 +++ 1 file changed, 84 insertions(+) diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c index bb7cf998fc65..a40a2a7514fd 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c @@ -885,6 +885,84 @@ static int shrink_hole(struct drm_i915_private *i915, return err; } +static int shrink_boom(struct drm_i915_private *i915, + struct i915_address_space *vm, + u64 hole_start, u64 hole_end, + unsigned long end_time) +{ + unsigned int sizes[] = {SZ_2M, SZ_1G}; + struct drm_i915_gem_object *purge; + struct drm_i915_gem_object *explode; + struct i915_vma *vma; + unsigned int flags = PIN_USER | PIN_OFFSET_FIXED; + int err; + int i; + + /* +* Catch the case which shrink_hole seems to miss. The setup here +* requires invoking the shrinker as we do the alloc_pt/alloc_pd, while +* ensuring that all vma assiocated with the respective pd/pdp are +* unpinned at the time. +*/ + + for (i = 0; i < ARRAY_SIZE(sizes); ++i) { + unsigned int size = sizes[i]; + + purge = fake_dma_object(i915, size); + if (IS_ERR(purge)) + return PTR_ERR(purge); + + vma = i915_vma_instance(purge, vm, NULL); + if (IS_ERR(vma)) { + err = PTR_ERR(vma); + goto err_purge; + } + + err = i915_vma_pin(vma, 0, 0, flags); + if (err) + goto err_purge; + + /* Should now be ripe for purging */ + i915_vma_unpin(vma); + + explode = fake_dma_object(i915, size); + if (IS_ERR(explode)) { + err = PTR_ERR(purge); + goto err_purge; + } + + vm->fault_attr.probability = 100; + vm->fault_attr.interval = 1; + atomic_set(&vm->fault_attr.times, -1); + + vma = i915_vma_instance(explode, vm, NULL); + if (IS_ERR(vma)) { + err = PTR_ERR(vma); + goto err_explode; + } + + err = i915_vma_pin(vma, 0, 0, flags | size); + if (err) + goto err_explode; + + i915_vma_unpin(vma); + + i915_gem_object_put(purge); + i915_gem_object_put(explode); + + memset(&vm->fault_attr, 0, sizeof(vm->fault_attr)); + } + + return 0; + +err_explode: + i915_gem_object_put(explode); +err_purge: + i915_gem_object_put(purge); + + return err; +} + static int exercise_ppgtt(struct drm_i915_private *dev_priv, int (*func)(struct drm_i915_private *i915, struct i915_address_space *vm, @@ -953,6 +1031,11 @@ static int igt_ppgtt_shrink(void *arg) return exercise_ppgtt(arg, shrink_hole); } +static int igt_ppgtt_shrink_boom(void *arg) +{ + return exercise_ppgtt(arg, shrink_boom); +} + static int sort_holes(void *priv, struct list_head *A, struct list_head *B) { struct drm_mm_node *a = list_entry(A, typeof(*a), hole_stack); @@ -1577,6 +1660,7 @@ int i915_gem_gtt_live_selftests(struct drm_i915_private *i915) SUBTEST(igt_ppgtt_pot), SUBTEST(igt_ppgtt_fill), SUBTEST(igt_ppgtt_shrink), + SUBTEST(igt_ppgtt_shrink_boom), SUBTEST(igt_ggtt_lowlevel), SUBTEST(igt_ggtt_drunk), SUBTEST(igt_ggtt_walk), -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/ppgtt: Pin page directories before allocation
Commit e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes") believed that because it did not insert its freshly allocated page directory into the pd tree, it was safe from the shrinker. I failed to heed the lesson learnt from commit dd19674bacba ("drm/i915: Remove bitmap tracking for used-ptes") that we need to pin all the levels in the tree before hitting the shrinker or else the shrinker may free an upper layer as we proceed to allocate the tree. Thus leaving dangling pointers everywhere and a GPF should we hit direct reclaim at just the wrong moment. Jan 24 10:32:48 eric-macbookpro kernel: CPU: 0 PID: 7374 Comm: chromium Tainted: P O4.14.13-1-ARCH #1 Jan 24 10:32:48 eric-macbookpro kernel: Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B33.1706181928 06/18/2017 Jan 24 10:32:48 eric-macbookpro kernel: task: 994f696c2c40 task.stack: b1a789d4c000 Jan 24 10:32:48 eric-macbookpro kernel: RIP: 0010:gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] Jan 24 10:32:48 eric-macbookpro kernel: RSP: 0018:b1a789d4f940 EFLAGS: 00010206 Jan 24 10:32:48 eric-macbookpro kernel: RAX: 81c1788cc4f68138 RBX: 994f54db8000 RCX: 994f696c2c40 Jan 24 10:32:48 eric-macbookpro kernel: RDX: 00023bc73003 RSI: 994d598b6b80 RDI: 994f54db8000 Jan 24 10:32:48 eric-macbookpro kernel: RBP: 994d598b6b80 R08: R09: Jan 24 10:32:48 eric-macbookpro kernel: R10: b1a789d4f550 R11: 994eaf3c3208 R12: 0027 Jan 24 10:32:48 eric-macbookpro kernel: R13: 5000 R14: 04e8f000 R15: 994f54dba000 Jan 24 10:32:48 eric-macbookpro kernel: FS: 7f585886aa00() GS:994faec0() knlGS: Jan 24 10:32:48 eric-macbookpro kernel: CS: 0010 DS: ES: CR0: 80050033 Jan 24 10:32:48 eric-macbookpro kernel: CR2: 004ac8e8 CR3: 0002552c8004 CR4: 003606f0 Jan 24 10:32:48 eric-macbookpro kernel: Call Trace: Jan 24 10:32:48 eric-macbookpro kernel: gen8_ppgtt_alloc_pdp+0x178/0x320 [i915] Jan 24 10:32:48 eric-macbookpro kernel: gen8_ppgtt_alloc_4lvl+0x5f/0x150 [i915] Jan 24 10:32:48 eric-macbookpro kernel: ppgtt_bind_vma+0x30/0x70 [i915] Jan 24 10:32:48 eric-macbookpro kernel: i915_vma_bind+0x68/0xd0 [i915] Jan 24 10:32:48 eric-macbookpro kernel: __i915_vma_do_pin+0x2d6/0x3a0 [i915] Jan 24 10:32:48 eric-macbookpro kernel: eb_lookup_vmas+0x7a2/0xb50 [i915] Jan 24 10:32:48 eric-macbookpro kernel: i915_gem_do_execbuffer+0x4d7/0x10e0 [i915] Jan 24 10:32:48 eric-macbookpro kernel: ? sock_wfree+0x34/0x60 Jan 24 10:32:48 eric-macbookpro kernel: ? unix_stream_read_generic+0x1f9/0x7e0 Jan 24 10:32:48 eric-macbookpro kernel: ? import_iovec+0x37/0xd0 Jan 24 10:32:48 eric-macbookpro kernel: ? i915_gem_execbuffer2+0x5d/0x390 [i915] Jan 24 10:32:48 eric-macbookpro kernel: i915_gem_execbuffer2+0x1b7/0x390 [i915] Jan 24 10:32:48 eric-macbookpro kernel: ? i915_gem_execbuffer+0x2d0/0x2d0 [i915] Jan 24 10:32:48 eric-macbookpro kernel: drm_ioctl_kernel+0x59/0xb0 [drm] Jan 24 10:32:48 eric-macbookpro kernel: drm_ioctl+0x2d5/0x370 [drm] Jan 24 10:32:48 eric-macbookpro kernel: ? i915_gem_execbuffer+0x2d0/0x2d0 [i915] Jan 24 10:32:48 eric-macbookpro kernel: ? __seccomp_filter+0x3b/0x260 Jan 24 10:32:48 eric-macbookpro kernel: do_vfs_ioctl+0xa1/0x610 Jan 24 10:32:48 eric-macbookpro kernel: ? syscall_trace_enter+0xdb/0x2b0 Jan 24 10:32:48 eric-macbookpro kernel: SyS_ioctl+0x74/0x80 Jan 24 10:32:48 eric-macbookpro kernel: do_syscall_64+0x55/0x110 Jan 24 10:32:48 eric-macbookpro kernel: entry_SYSCALL64_slow_path+0x25/0x25 Jan 24 10:32:48 eric-macbookpro kernel: RIP: 0033:0x7f584fa82d27 Jan 24 10:32:48 eric-macbookpro kernel: RSP: 002b:7ffee14a7828 EFLAGS: 0246 ORIG_RAX: 0010 Jan 24 10:32:48 eric-macbookpro kernel: RAX: ffda RBX: 03b0126a1030 RCX: 7f584fa82d27 Jan 24 10:32:48 eric-macbookpro kernel: RDX: 7ffee14a7870 RSI: 40406469 RDI: 0080 Jan 24 10:32:48 eric-macbookpro kernel: RBP: 7ffee14a7870 R08: 0002 R09: 0077 Jan 24 10:32:48 eric-macbookpro kernel: R10: 7f5839f2b780 R11: 0246 R12: 40406469 Jan 24 10:32:48 eric-macbookpro kernel: R13: 0080 R14: 7f5842b00040 R15: Jan 24 10:32:48 eric-macbookpro kernel: Code: 01 00 83 81 58 0a 00 00 01 48 2b 05 13 9d fd c9 48 c1 f8 06 48 c1 e0 0c 48 8d 04 d0 48 8b 56 08 48 03 05 0c 9d fd c9 48 83 ca 03 <48> 89 10 83 a9 58 0a 00 00 01 65 ff 0d 37 03 fb 3e 74 02 f3 c3 Jan 24 10:32:48 eric-macbookpro kernel: RIP: gen8_ppgtt_set_pde.isra.40+0x48/0x70 [i915] RSP: b1a789d4f940 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104773 Fixes: e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes") References: dd19674bacba ("drm/i915: Remove bitmap tracking for used-ptes") Testcase: igt/drv_selftest/live_gtt (igt_ppgtt_shrink_boom) S
[Intel-gfx] [PATCH] drm/i915/cnl: Respect VBT max dp rate.
Since commit 'c4fb60b9aba9 ("drm/i915/bios: add DP max link rate to VBT child device struct")' we have the new entry defined for max dp rate that is in use for CNL. Let's start using it for all VBT 216+ and also organize the cnl adjusted rates in terms of rate and not array size. Cc: Jani Nikula Cc: Ville Syrjälä Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_bios.c | 3 +++ drivers/gpu/drm/i915/intel_dp.c | 37 + 3 files changed, 33 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index c676269ed843..66dea5c9b10e 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1282,6 +1282,7 @@ struct ddi_vbt_port_info { uint8_t dp_boost_level; uint8_t hdmi_boost_level; + uint8_t dp_max_link_rate; }; enum psr_lines_to_wait { diff --git a/drivers/gpu/drm/i915/intel_bios.c b/drivers/gpu/drm/i915/intel_bios.c index cf3f8f1ba6f7..c885daf4cc8d 100644 --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -1230,6 +1230,9 @@ static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port, info->alternate_aux_channel = aux_channel; sanitize_aux_ch(dev_priv, port); + + if (bdb_version >= 216 && child->dp_max_link_rate) + info->dp_max_link_rate = child->dp_max_link_rate; } if (bdb_version >= 158) { diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 03d86ff9b805..1e34d7954355 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -220,7 +220,7 @@ intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp) return max_dotclk; } -static int cnl_adjusted_max_rate(struct intel_dp *intel_dp, int size) +static int cnl_adjusted_max_rate(struct intel_dp *intel_dp) { struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev); @@ -230,17 +230,33 @@ static int cnl_adjusted_max_rate(struct intel_dp *intel_dp, int size) /* Low voltage SKUs are limited to max of 5.4G */ if (voltage == VOLTAGE_INFO_0_85V) - return size - 2; + return 54; /* For this SKU 8.1G is supported in all ports */ if (IS_CNL_WITH_PORT_F(dev_priv)) - return size; + return 81; /* For other SKUs, max rate on ports A and B is 5.4G */ if (port == PORT_A || port == PORT_D) - return size - 2; + return 54; - return size; + return 81; +} + +static int intel_dp_adjusted_max_rate(struct intel_dp *intel_dp) +{ + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev); + const struct ddi_vbt_port_info *info = + &dev_priv->vbt.ddi_port_info[dig_port->base.port]; + + if (info->dp_max_link_rate) + return info->dp_max_link_rate; + + if (IS_CANNONLAKE(dev_priv)) + return cnl_adjusted_max_rate(intel_dp); + + return INT_MAX; /* No adjusted limit */ } static void @@ -249,7 +265,8 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp) struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev); const int *source_rates; - int size; + int i, size; + int max_rate = intel_dp_adjusted_max_rate(intel_dp); /* This should only be done once */ WARN_ON(intel_dp->source_rates || intel_dp->num_source_rates); @@ -259,7 +276,7 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp) size = ARRAY_SIZE(bxt_rates); } else if (IS_CANNONLAKE(dev_priv)) { source_rates = cnl_rates; - size = cnl_adjusted_max_rate(intel_dp, ARRAY_SIZE(cnl_rates)); + size = ARRAY_SIZE(cnl_rates); } else if (IS_GEN9_BC(dev_priv)) { source_rates = skl_rates; size = ARRAY_SIZE(skl_rates); @@ -272,8 +289,12 @@ intel_dp_set_source_rates(struct intel_dp *intel_dp) size = ARRAY_SIZE(default_rates) - 1; } + for (i = 0; i < size; i++) + if (source_rates[i] > max_rate) + break; + + intel_dp->num_source_rates = i; intel_dp->source_rates = source_rates; - intel_dp->num_source_rates = size; } static int intersect_rates(const int *source_rates, int source_len, -- 2.13.6 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: add missing gtt shrinker test
Quoting Matthew Auld (2018-01-31 19:14:53) > Try to catch a bug we've seen in the wild where the shrinker purges the > pd/pdp from under us while allocating our paging structures. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=104773 > Signed-off-by: Matthew Auld > Cc: Chris Wilson > --- > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 84 > +++ > 1 file changed, 84 insertions(+) > > diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c > b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c > index bb7cf998fc65..a40a2a7514fd 100644 > --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c > +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c > @@ -885,6 +885,84 @@ static int shrink_hole(struct drm_i915_private *i915, > return err; > } > > +static int shrink_boom(struct drm_i915_private *i915, > + struct i915_address_space *vm, > + u64 hole_start, u64 hole_end, > + unsigned long end_time) > +{ > + unsigned int sizes[] = {SZ_2M, SZ_1G}; > + struct drm_i915_gem_object *purge; > + struct drm_i915_gem_object *explode; > + struct i915_vma *vma; > + unsigned int flags = PIN_USER | PIN_OFFSET_FIXED; > + int err; > + int i; > + > + /* > +* Catch the case which shrink_hole seems to miss. The setup here > +* requires invoking the shrinker as we do the alloc_pt/alloc_pd, > while > +* ensuring that all vma assiocated with the respective pd/pdp are > +* unpinned at the time. > +*/ Question for everyone: can we see more holes in shrink_hole? > + > + for (i = 0; i < ARRAY_SIZE(sizes); ++i) { > + unsigned int size = sizes[i]; > + > + purge = fake_dma_object(i915, size); > + if (IS_ERR(purge)) > + return PTR_ERR(purge); > + > + vma = i915_vma_instance(purge, vm, NULL); > + if (IS_ERR(vma)) { > + err = PTR_ERR(vma); > + goto err_purge; > + } > + > + err = i915_vma_pin(vma, 0, 0, flags); > + if (err) > + goto err_purge; > + > + /* Should now be ripe for purging */ > + i915_vma_unpin(vma); > + > + explode = fake_dma_object(i915, size); > + if (IS_ERR(explode)) { > + err = PTR_ERR(purge); > + goto err_purge; > + } > + > + vm->fault_attr.probability = 100; > + vm->fault_attr.interval = 1; > + atomic_set(&vm->fault_attr.times, -1); > + > + vma = i915_vma_instance(explode, vm, NULL); > + if (IS_ERR(vma)) { > + err = PTR_ERR(vma); > + goto err_explode; > + } > + > + err = i915_vma_pin(vma, 0, 0, flags | size); > + if (err) > + goto err_explode; > + > + i915_vma_unpin(vma); > + > + i915_gem_object_put(purge); > + i915_gem_object_put(explode); > + > + memset(&vm->fault_attr, 0, sizeof(vm->fault_attr)); > + } > + > + return 0; > + > +err_explode: > + i915_gem_object_put(explode); > +err_purge: > + i915_gem_object_put(purge); > + > + return err; > +} As this demonstrates a shrinker bug we missed in the test intended to find all shrinker bugs, Reviewed-by: Chris Wilson Just worrying about how deep the iceberg goes. (Though more about catching tomorrow's bug as we should have this one fixed pretty shortly.) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/selftests: add missing gtt shrinker test
== Series Details == Series: drm/i915/selftests: add missing gtt shrinker test URL : https://patchwork.freedesktop.org/series/37432/ State : warning == Summary == Test perf: Subgroup oa-exponents: fail -> PASS (shard-apl) fdo#102254 Subgroup enable-disable: pass -> FAIL (shard-apl) fdo#103715 Test gem_eio: Subgroup in-flight: fail -> PASS (shard-hsw) fdo#104676 +1 Test kms_flip: Subgroup flip-vs-expired-vblank-interruptible: pass -> FAIL (shard-apl) fdo#102887 Subgroup basic-plain-flip: skip -> PASS (shard-apl) Test kms_plane_multiple: Subgroup atomic-pipe-b-tiling-yf: fail -> PASS (shard-apl) Subgroup legacy-pipe-a-tiling-x: skip -> PASS (shard-apl) Test kms_vblank: Subgroup pipe-c-ts-continuation-suspend: dmesg-warn -> PASS (shard-apl) Subgroup pipe-a-query-busy: skip -> PASS (shard-apl) Subgroup pipe-b-accuracy-idle: skip -> PASS (shard-apl) Subgroup pipe-c-wait-forked-busy: skip -> PASS (shard-apl) Subgroup crtc-id: skip -> PASS (shard-apl) Test kms_draw_crc: Subgroup draw-method-xrgb-render-untiled: skip -> PASS (shard-apl) Subgroup draw-method-xrgb2101010-render-xtiled: skip -> PASS (shard-apl) Test kms_color: Subgroup pipe-a-ctm-0-75: skip -> PASS (shard-apl) Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-render: skip -> PASS (shard-apl) fdo#103167 +1 Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt: skip -> PASS (shard-apl) fdo#101623 +2 Subgroup fbc-rgb101010-draw-mmap-gtt: skip -> PASS (shard-apl) Test kms_cursor_crc: Subgroup cursor-256x256-rapid-movement: skip -> PASS (shard-apl) fdo#103326 Subgroup cursor-256x256-dpms: skip -> PASS (shard-apl) Subgroup cursor-128x42-random: skip -> PASS (shard-apl) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-c-frame-sequence: skip -> PASS (shard-apl) fdo#103481 Subgroup read-crc-pipe-c: skip -> PASS (shard-apl) fdo#103191 Subgroup read-crc-pipe-a: skip -> PASS (shard-apl) Test kms_busy: Subgroup extended-modeset-hang-newfb-with-reset-render-c: skip -> PASS (shard-apl) Subgroup extended-modeset-hang-oldfb-with-reset-render-c: skip -> PASS (shard-apl) fdo#103336 Test kms_plane_scaling: Subgroup pipe-c-plane-scaling: skip -> PASS (shard-apl) Test kms_rotation_crc: Subgroup primary-rotation-90-y-tiled: skip -> PASS (shard-apl) Test kms_cursor_legacy: Subgroup basic-flip-after-cursor-varying-size: skip -> PASS (shard-apl) fdo#102670 Subgroup cursora-vs-flipa-atomic: skip -> PASS (shard-apl) Test kms_chv_cursor_fail: Subgroup pipe-a-128x128-bottom-edge: skip -> PASS (shard-apl) Test kms_rmfb: Subgroup rmfb-ioctl: skip -> PASS (shard-apl) Test kms_ccs: Subgroup pipe-b-bad-pixel-format: skip -> PASS (shard-apl) Test kms_sysfs_edid_timing: warn -> PASS (shard-apl) fdo#100047 Test drv_selftest: Subgroup live_gtt: pass -> DMESG-FAIL (shard-apl) fdo#103927 +1 Subgroup live_evict: pass -> SKIP (shard-apl) Subgroup live_contexts: pass -> SKIP (shard-apl) Subgroup live_hangcheck: pass -> SKIP (shard-apl) fdo#104262 +1 Subgroup live_guc: pass -> SKIP (shard-apl) fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254 fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715 fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#103326 https://bugs.freedesktop.org/show_bug.cgi?id=103326 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103336 https://bugs.freedesktop.org/show_bug.cgi?id=103336
Re: [Intel-gfx] [PATCH] drm/i915: Add option to list load failure checkpoints
Quoting Michal Wajdeczko (2018-01-31 18:23:47) > Our inject_load_failure functionality allows to insert one > failure during driver load, but it is hard to guess which > number should passed as modparam to select specific checkpoint. > > Use negative number as option to list all available failure > checkpoints without triggering any failure. Hmm, it was only intended for use with the coupled igt test. Mind expanding upon the use case you have? Could you not use that iterative search for finding the injection value you want for repeated runs? For the bisect case, do you not want to keep it iterating over all in case the value changes? How stable do you want the modparam? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/breadcrumbs: Drop request reference for the signaler thread
Quoting Chris Wilson (2018-01-31 20:40:03) > Quoting Chris Wilson (2018-01-31 17:30:46) > > Quoting Tvrtko Ursulin (2018-01-31 17:18:55) > > > > > > On 22/01/2018 15:41, Chris Wilson wrote: > > > > +static struct drm_i915_gem_request *first_signal(struct > > > > intel_breadcrumbs *b) > > > > +{ > > > > + /* > > > > + * See the big warnings for i915_gem_active_get_rcu() and > > > > similarly > > > > + * for dma_fence_get_rcu_safe() that explain the intricacies > > > > involved > > > > + * here with defeating CPU/compiler speculation and enforcing > > > > + * the required memory barriers. > > > > + */ > > > > + do { > > > > + struct drm_i915_gem_request *request; > > > > + > > > > + request = rcu_dereference(b->first_signal); > > > > + if (request) > > > > + request = i915_gem_request_get_rcu(request); > > > > + > > > > + barrier(); > > > > + > > > > + if (!request || request == > > > > rcu_access_pointer(b->first_signal)) > > > > + return rcu_pointer_handoff(request); > > > > + > > > > + i915_gem_request_put(request); > > > > + } while (1); > > > > +} > > > > + > > > > static int intel_breadcrumbs_signaler(void *arg) > > > > { > > > > struct intel_engine_cs *engine = arg; > > > > @@ -667,41 +715,21 @@ static int intel_breadcrumbs_signaler(void *arg) > > > >* a new client. > > > >*/ > > > > rcu_read_lock(); > > > > - request = rcu_dereference(b->first_signal); > > > > - if (request) > > > > - request = i915_gem_request_get_rcu(request); > > > > + request = first_signal(b); > > > > > > get_ prefix would be good to signify a get vs peek. Maybe even _rcu > > > suffix. > > > > Sold. > > Whilst you are looking at this, I should just say that first_signal() is > what we should have been doing all this time; it's really a very obscure > bug fix. And fwiw, the s/rbtree/list/ patch eliminates it. Hmm, actually no, no underlying bug here as the reference was previously carried by the signaler, and with its removal do we need to do the double dance. (It's a bad sign when I can remember having that exact conversation with myself; and forgot until too late.) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/breadcrumbs: Drop request reference for the signaler thread
Quoting Chris Wilson (2018-01-31 17:30:46) > Quoting Tvrtko Ursulin (2018-01-31 17:18:55) > > > > On 22/01/2018 15:41, Chris Wilson wrote: > > > +static struct drm_i915_gem_request *first_signal(struct > > > intel_breadcrumbs *b) > > > +{ > > > + /* > > > + * See the big warnings for i915_gem_active_get_rcu() and similarly > > > + * for dma_fence_get_rcu_safe() that explain the intricacies > > > involved > > > + * here with defeating CPU/compiler speculation and enforcing > > > + * the required memory barriers. > > > + */ > > > + do { > > > + struct drm_i915_gem_request *request; > > > + > > > + request = rcu_dereference(b->first_signal); > > > + if (request) > > > + request = i915_gem_request_get_rcu(request); > > > + > > > + barrier(); > > > + > > > + if (!request || request == > > > rcu_access_pointer(b->first_signal)) > > > + return rcu_pointer_handoff(request); > > > + > > > + i915_gem_request_put(request); > > > + } while (1); > > > +} > > > + > > > static int intel_breadcrumbs_signaler(void *arg) > > > { > > > struct intel_engine_cs *engine = arg; > > > @@ -667,41 +715,21 @@ static int intel_breadcrumbs_signaler(void *arg) > > >* a new client. > > >*/ > > > rcu_read_lock(); > > > - request = rcu_dereference(b->first_signal); > > > - if (request) > > > - request = i915_gem_request_get_rcu(request); > > > + request = first_signal(b); > > > > get_ prefix would be good to signify a get vs peek. Maybe even _rcu suffix. > > Sold. Whilst you are looking at this, I should just say that first_signal() is what we should have been doing all this time; it's really a very obscure bug fix. And fwiw, the s/rbtree/list/ patch eliminates it. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add option to list load failure checkpoints
== Series Details == Series: drm/i915: Add option to list load failure checkpoints URL : https://patchwork.freedesktop.org/series/37427/ State : failure == Summary == Test kms_flip: Subgroup wf_vblank-ts-check-interruptible: fail -> PASS (shard-apl) fdo#100368 +3 Subgroup basic-plain-flip: skip -> PASS (shard-apl) Subgroup flip-vs-panning-vs-hang: pass -> DMESG-WARN (shard-snb) fdo#103821 Test kms_plane_multiple: Subgroup legacy-pipe-c-tiling-none: pass -> FAIL (shard-apl) Subgroup legacy-pipe-a-tiling-x: skip -> PASS (shard-apl) Subgroup atomic-pipe-b-tiling-yf: fail -> PASS (shard-apl) Test kms_vblank: Subgroup pipe-c-ts-continuation-suspend: dmesg-warn -> PASS (shard-apl) Subgroup pipe-a-query-busy: skip -> PASS (shard-apl) Subgroup pipe-b-accuracy-idle: skip -> PASS (shard-apl) Subgroup pipe-c-wait-forked-busy: skip -> PASS (shard-apl) Subgroup crtc-id: skip -> PASS (shard-apl) Subgroup pipe-b-ts-continuation-dpms-suspend: pass -> DMESG-WARN (shard-snb) Test kms_draw_crc: Subgroup draw-method-xrgb-render-untiled: skip -> PASS (shard-apl) Subgroup draw-method-xrgb2101010-render-xtiled: skip -> PASS (shard-apl) Test kms_color: Subgroup pipe-a-ctm-0-75: skip -> PASS (shard-apl) Test kms_frontbuffer_tracking: Subgroup fbc-1p-primscrn-spr-indfb-draw-render: skip -> PASS (shard-apl) fdo#103167 +1 Subgroup fbc-1p-primscrn-pri-shrfb-draw-blt: skip -> PASS (shard-apl) fdo#101623 +2 Subgroup fbc-rgb101010-draw-mmap-gtt: skip -> PASS (shard-apl) Test kms_cursor_crc: Subgroup cursor-256x256-rapid-movement: skip -> PASS (shard-apl) fdo#103326 Subgroup cursor-256x256-dpms: skip -> PASS (shard-apl) Subgroup cursor-128x42-random: skip -> PASS (shard-apl) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-c-frame-sequence: skip -> PASS (shard-apl) fdo#103481 Subgroup read-crc-pipe-c: skip -> PASS (shard-apl) fdo#103191 Subgroup read-crc-pipe-a: skip -> PASS (shard-apl) Test kms_busy: Subgroup extended-modeset-hang-newfb-with-reset-render-c: skip -> PASS (shard-apl) Subgroup extended-modeset-hang-oldfb-with-reset-render-c: skip -> PASS (shard-apl) fdo#103336 Test kms_plane_scaling: Subgroup pipe-c-plane-scaling: skip -> PASS (shard-apl) Test kms_rotation_crc: Subgroup primary-rotation-90-y-tiled: skip -> PASS (shard-apl) Test kms_cursor_legacy: Subgroup basic-flip-after-cursor-varying-size: skip -> PASS (shard-apl) fdo#102670 Subgroup cursora-vs-flipa-atomic: skip -> PASS (shard-apl) Test kms_chv_cursor_fail: Subgroup pipe-a-128x128-bottom-edge: skip -> PASS (shard-apl) Test kms_rmfb: Subgroup rmfb-ioctl: skip -> PASS (shard-apl) Test kms_ccs: Subgroup pipe-b-bad-pixel-format: skip -> PASS (shard-apl) Test perf: Subgroup oa-exponents: fail -> PASS (shard-apl) fdo#102254 Test gem_eio: Subgroup in-flight-suspend: pass -> FAIL (shard-hsw) fdo#104676 Test kms_sysfs_edid_timing: warn -> PASS (shard-apl) fdo#100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103821 https://bugs.freedesktop.org/show_bug.cgi?id=103821 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#103326 https://bugs.freedesktop.org/show_bug.cgi?id=103326 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103336 https://bugs.freedesktop.org/show_bug.cgi?id=103336 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254 fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:2838 pass:1750 dwarn:1 dfail:0 fail:23 skip:1064 time:12621s shard-hswtota
Re: [Intel-gfx] [PATCH] drm/atomic: Fix memleak on ERESTARTSYS during non-blocking commits
On 2018-01-30 05:28 AM, Maarten Lankhorst wrote: > Op 29-01-18 om 16:41 schreef Leo Li: >> Updated IGT results seem sane: >> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7698/shards.html >> >> Would someone be able to apply this patch? >> > Thanks for the reminder, pushed. > Thanks, Maarten. I see it in drm-misc-next. Would someone be able to pull this into drm-misc-fixes as well, or can I just I apply this myself with the following dim commands? dim checkout drm-misc-fixes dim cherry-pick 1c6c6ebb dim push-branch Harry > ~Maarten > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: add missing gtt shrinker test
== Series Details == Series: drm/i915/selftests: add missing gtt shrinker test URL : https://patchwork.freedesktop.org/series/37432/ State : success == Summary == Series 37432v1 drm/i915/selftests: add missing gtt shrinker test https://patchwork.freedesktop.org/api/1.0/series/37432/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> FAIL (fi-elk-e7500) fdo#103989 +1 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test kms_chamelium: Subgroup common-hpd-after-suspend: dmesg-warn -> PASS (fi-skl-6700k2) fdo#104108 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:422s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:422s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:485s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:282s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:478s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:487s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:465s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:451s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:567s fi-elk-e7500 total:224 pass:167 dwarn:10 dfail:0 fail:1 skip:45 fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:277s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:509s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:387s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:396s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:410s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:452s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:411s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:457s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:498s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:451s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:500s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:579s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:430s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:509s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:529s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:489s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:482s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:416s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:430s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:522s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:394s Blacklisted hosts: fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:470s ae93f9b9acf3e9cdbb2be1b68a97c3cc6db66fad drm-tip: 2018y-01m-31d-16h-31m-38s UTC integration manifest 6939c297c5bd drm/i915/selftests: add missing gtt shrinker test == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7843/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: add missing gtt shrinker test
Try to catch a bug we've seen in the wild where the shrinker purges the pd/pdp from under us while allocating our paging structures. References: https://bugs.freedesktop.org/show_bug.cgi?id=104773 Signed-off-by: Matthew Auld Cc: Chris Wilson --- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 84 +++ 1 file changed, 84 insertions(+) diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c index bb7cf998fc65..a40a2a7514fd 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c @@ -885,6 +885,84 @@ static int shrink_hole(struct drm_i915_private *i915, return err; } +static int shrink_boom(struct drm_i915_private *i915, + struct i915_address_space *vm, + u64 hole_start, u64 hole_end, + unsigned long end_time) +{ + unsigned int sizes[] = {SZ_2M, SZ_1G}; + struct drm_i915_gem_object *purge; + struct drm_i915_gem_object *explode; + struct i915_vma *vma; + unsigned int flags = PIN_USER | PIN_OFFSET_FIXED; + int err; + int i; + + /* +* Catch the case which shrink_hole seems to miss. The setup here +* requires invoking the shrinker as we do the alloc_pt/alloc_pd, while +* ensuring that all vma assiocated with the respective pd/pdp are +* unpinned at the time. +*/ + + for (i = 0; i < ARRAY_SIZE(sizes); ++i) { + unsigned int size = sizes[i]; + + purge = fake_dma_object(i915, size); + if (IS_ERR(purge)) + return PTR_ERR(purge); + + vma = i915_vma_instance(purge, vm, NULL); + if (IS_ERR(vma)) { + err = PTR_ERR(vma); + goto err_purge; + } + + err = i915_vma_pin(vma, 0, 0, flags); + if (err) + goto err_purge; + + /* Should now be ripe for purging */ + i915_vma_unpin(vma); + + explode = fake_dma_object(i915, size); + if (IS_ERR(explode)) { + err = PTR_ERR(purge); + goto err_purge; + } + + vm->fault_attr.probability = 100; + vm->fault_attr.interval = 1; + atomic_set(&vm->fault_attr.times, -1); + + vma = i915_vma_instance(explode, vm, NULL); + if (IS_ERR(vma)) { + err = PTR_ERR(vma); + goto err_explode; + } + + err = i915_vma_pin(vma, 0, 0, flags | size); + if (err) + goto err_explode; + + i915_vma_unpin(vma); + + i915_gem_object_put(purge); + i915_gem_object_put(explode); + + memset(&vm->fault_attr, 0, sizeof(vm->fault_attr)); + } + + return 0; + +err_explode: + i915_gem_object_put(explode); +err_purge: + i915_gem_object_put(purge); + + return err; +} + static int exercise_ppgtt(struct drm_i915_private *dev_priv, int (*func)(struct drm_i915_private *i915, struct i915_address_space *vm, @@ -953,6 +1031,11 @@ static int igt_ppgtt_shrink(void *arg) return exercise_ppgtt(arg, shrink_hole); } +static int igt_ppgtt_shrink_boom(void *arg) +{ + return exercise_ppgtt(arg, shrink_boom); +} + static int sort_holes(void *priv, struct list_head *A, struct list_head *B) { struct drm_mm_node *a = list_entry(A, typeof(*a), hole_stack); @@ -1577,6 +1660,7 @@ int i915_gem_gtt_live_selftests(struct drm_i915_private *i915) SUBTEST(igt_ppgtt_pot), SUBTEST(igt_ppgtt_fill), SUBTEST(igt_ppgtt_shrink), + SUBTEST(igt_ppgtt_shrink_boom), SUBTEST(igt_ggtt_lowlevel), SUBTEST(igt_ggtt_drunk), SUBTEST(igt_ggtt_walk), -- 2.14.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add option to list load failure checkpoints
== Series Details == Series: drm/i915: Add option to list load failure checkpoints URL : https://patchwork.freedesktop.org/series/37427/ State : success == Summary == Series 37427v1 drm/i915: Add option to list load failure checkpoints https://patchwork.freedesktop.org/api/1.0/series/37427/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test kms_chamelium: Subgroup common-hpd-after-suspend: dmesg-warn -> PASS (fi-skl-6700k2) fdo#104108 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#104108 https://bugs.freedesktop.org/show_bug.cgi?id=104108 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:421s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:430s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:369s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:483s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:281s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:482s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:486s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:461s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:457s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:570s fi-elk-e7500 total:224 pass:168 dwarn:9 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:277s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:511s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:389s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:398s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:413s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:454s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:411s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:455s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:492s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:450s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:499s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:571s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:427s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:509s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:525s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:491s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:475s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:410s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:430s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:520s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:395s Blacklisted hosts: fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:465s ae93f9b9acf3e9cdbb2be1b68a97c3cc6db66fad drm-tip: 2018y-01m-31d-16h-31m-38s UTC integration manifest 879ec7a733e0 drm/i915: Add option to list load failure checkpoints == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7842/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add option to list load failure checkpoints
Our inject_load_failure functionality allows to insert one failure during driver load, but it is hard to guess which number should passed as modparam to select specific checkpoint. Use negative number as option to list all available failure checkpoints without triggering any failure. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.c| 18 +++--- drivers/gpu/drm/i915/i915_params.c | 6 -- drivers/gpu/drm/i915/i915_params.h | 2 +- 3 files changed, 16 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 1ec12ad..0992301 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -55,16 +55,21 @@ static struct drm_driver driver; -static unsigned int i915_load_fail_count; +static int i915_load_fail_count = 0; bool __i915_inject_load_failure(const char *func, int line) { - if (i915_load_fail_count >= i915_modparams.inject_load_failure) + ++i915_load_fail_count; + + if (unlikely(i915_modparams.inject_load_failure < 0)) { + DRM_NOTE("[i915] load checkpoint %d [%s:%d]\n", +i915_load_fail_count, func, line); return false; + } - if (++i915_load_fail_count == i915_modparams.inject_load_failure) { - DRM_INFO("Injecting failure at checkpoint %u [%s:%d]\n", -i915_modparams.inject_load_failure, func, line); + if (i915_modparams.inject_load_failure == i915_load_fail_count) { + DRM_INFO("Injecting failure at checkpoint %d [%s:%d]\n", +i915_load_fail_count, func, line); return true; } @@ -107,8 +112,7 @@ bool __i915_inject_load_failure(const char *func, int line) static bool i915_error_injected(struct drm_i915_private *dev_priv) { - return i915_modparams.inject_load_failure && - i915_load_fail_count == i915_modparams.inject_load_failure; + return i915_modparams.inject_load_failure >= i915_load_fail_count; } #define i915_load_error(dev_priv, fmt, ...) \ diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index 0b553a8..e5ab69c 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c @@ -167,8 +167,10 @@ struct i915_params i915_modparams __read_mostly = { i915_param_named_unsafe(enable_dp_mst, bool, 0600, "Enable multi-stream transport (MST) for new DisplayPort sinks. (default: true)"); -i915_param_named_unsafe(inject_load_failure, uint, 0400, - "Force an error after a number of failure check points (0:disabled (default), N:force failure at the Nth failure check point)"); +i915_param_named_unsafe(inject_load_failure, int, 0400, + "Force an error after a number of failure check points. " + "(-1=list check points, 0=disabled [default], " + "N=force failure at the Nth failure check point)"); i915_param_named(enable_dpcd_backlight, bool, 0600, "Enable support for DPCD backlight control (default:false)"); diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 430f5f9..6ed799f 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -54,7 +54,7 @@ param(int, mmio_debug, 0) \ param(int, edp_vswing, 0) \ param(int, reset, 2) \ - param(unsigned int, inject_load_failure, 0) \ + param(int, inject_load_failure, 0) \ /* leave bools at the end to not create holes */ \ param(bool, alpha_support, IS_ENABLED(CONFIG_DRM_I915_ALPHA_SUPPORT)) \ param(bool, enable_cmd_parser, true) \ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/pmu: Micro-optimize sampling loop
== Series Details == Series: drm/i915/pmu: Micro-optimize sampling loop URL : https://patchwork.freedesktop.org/series/37420/ State : warning == Summary == Test kms_flip: Subgroup 2x-plain-flip-fb-recreate: pass -> FAIL (shard-hsw) fdo#100368 Test kms_cursor_legacy: Subgroup flip-vs-cursor-legacy: pass -> FAIL (shard-hsw) fdo#102670 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 Test kms_atomic_interruptible: Subgroup legacy-cursor: pass -> SKIP (shard-snb) Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-mmap-cpu: pass -> SKIP (shard-snb) fdo#101623 Test drv_suspend: Subgroup sysfs-reader-hibernate: fail -> SKIP (shard-hsw) fdo#103375 Test perf_pmu: Subgroup semaphore-wait-bcs0: fail -> PASS (shard-apl) fdo#104829 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 fdo#104829 https://bugs.freedesktop.org/show_bug.cgi?id=104829 shard-apltotal:2838 pass:1748 dwarn:2 dfail:0 fail:23 skip:1064 time:12578s shard-hswtotal:2838 pass:1734 dwarn:1 dfail:0 fail:11 skip:1091 time:11946s shard-snbtotal:2838 pass:1328 dwarn:1 dfail:0 fail:10 skip:1499 time:6614s Blacklisted hosts: shard-kbltotal:2838 pass:1870 dwarn:4 dfail:0 fail:22 skip:942 time:9731s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7840/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915/uc: Add few more load failure checkpoints
== Series Details == Series: series starting with [1/5] drm/i915/uc: Add few more load failure checkpoints URL : https://patchwork.freedesktop.org/series/37425/ State : failure == Summary == Series 37425v1 series starting with [1/5] drm/i915/uc: Add few more load failure checkpoints https://patchwork.freedesktop.org/api/1.0/series/37425/revisions/1/mbox/ Test core_auth: Subgroup basic-auth: pass -> SKIP (fi-skl-gvtdvm) Test core_prop_blob: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Test debugfs_test: Subgroup read_all_entries: pass -> SKIP (fi-skl-gvtdvm) Test drv_getparams_basic: Subgroup basic-eu-total: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-subslice-total: pass -> SKIP (fi-skl-gvtdvm) Test drv_hangman: Subgroup error-state-basic: pass -> SKIP (fi-skl-gvtdvm) Test gem_basic: Subgroup bad-close: pass -> SKIP (fi-skl-gvtdvm) Subgroup create-close: pass -> SKIP (fi-skl-gvtdvm) Subgroup create-fd-close: pass -> SKIP (fi-skl-gvtdvm) Test gem_busy: Subgroup basic-busy-default: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-hang-default: pass -> SKIP (fi-skl-gvtdvm) fdo#104108 +3 Test gem_close_race: Subgroup basic-process: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-threads: pass -> SKIP (fi-skl-gvtdvm) Test gem_cpu_reloc: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Test gem_cs_tlb: Subgroup basic-default: pass -> SKIP (fi-skl-gvtdvm) Test gem_ctx_create: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-files: pass -> SKIP (fi-skl-gvtdvm) Test gem_ctx_exec: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Test gem_ctx_param: Subgroup basic: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-default: pass -> SKIP (fi-skl-gvtdvm) Test gem_ctx_switch: Subgroup basic-default: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-default-heavy: pass -> SKIP (fi-skl-gvtdvm) Test gem_exec_basic: Subgroup basic-blt: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-bsd: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-bsd1: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-bsd2: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-default: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-render: pass -> SKIP (fi-skl-gvtdvm) Subgroup basic-vebox: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-blt: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-bsd: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-bsd1: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-bsd2: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-default: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-render: pass -> SKIP (fi-skl-gvtdvm) Subgroup gtt-vebox: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-blt: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-bsd: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-bsd1: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-bsd2: pass -> SKIP (fi-skl-gvtdvm) Subgroup readonly-default: pass -> SKIP (fi-skl-gvtdvm) WARNING: Long output truncated ae93f9b9acf3e9cdbb2be1b68a97c3cc6db66fad drm-tip: 2018y-01m-31d-16h-31m-38s UTC integration manifest 8f4dbd51e218 HAX: Enable GuC for CI 2c3f53721546 drm/i915/guc: Don't try to create log runtime if there is no log 7d73ec81b603 drm/i915/guc: Use correct error code for GuC initialization failure c484a76baebc drm/i915/guc: Don't forget to free GuC error log 095bb2376c30 drm/i915/uc: Add few more load failure checkpoints == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7841/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915/guc: Don't try to create log runtime if there is no log
In case of GuC initialization failure we may continue with driver load, but we wrongly assume that GuC is fully functional. This leads to the BUG as we attempt to access non-existing log vma. [26386.121085] BUG: unable to handle kernel NULL pointer dereference at 00a0 [26386.121225] IP: guc_log_runtime_create+0x23/0xe0 [i915] [26386.121763] Call Trace: [26386.121870] guc_log_late_setup+0xfd/0x140 [i915] [26386.121969] i915_driver_load+0x7ab/0x1730 [i915] [26386.122069] i915_pci_probe+0x2d/0x90 [i915] [26386.122089] pci_device_probe+0x9c/0x120 [26386.122107] driver_probe_device+0x2a9/0x490 [26386.122126] __driver_attach+0xd9/0xe0 [26386.122143] ? driver_probe_device+0x490/0x490 [26386.122158] bus_for_each_dev+0x57/0x90 [26386.122175] bus_add_driver+0x1eb/0x260 [26386.122190] ? 0xa069a000 [26386.122206] driver_register+0x52/0xc0 [26386.10] ? 0xa069a000 [26386.122234] do_one_initcall+0x39/0x170 [26386.122252] ? kmem_cache_alloc_trace+0x1fd/0x2e0 [26386.122273] do_init_module+0x56/0x1ec [26386.122289] load_module+0x219e/0x2550 [26386.122309] ? vfs_read+0x121/0x140 [26386.122331] ? SyS_finit_module+0xa5/0xe0 [26386.122346] SyS_finit_module+0xa5/0xe0 [26386.122371] entry_SYSCALL_64_fastpath+0x22/0x8f Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Michal Winiarski Cc: Daniele Ceraolo Spurio Cc: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_guc_log.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_guc_log.c b/drivers/gpu/drm/i915/intel_guc_log.c index 3fbe93a..fdb1895 100644 --- a/drivers/gpu/drm/i915/intel_guc_log.c +++ b/drivers/gpu/drm/i915/intel_guc_log.c @@ -395,6 +395,9 @@ static int guc_log_runtime_create(struct intel_guc *guc) void *vaddr; int ret; + if (!guc->log.vma) + return -ENODEV; + lockdep_assert_held(&dev_priv->drm.struct_mutex); GEM_BUG_ON(guc_log_has_runtime(guc)); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] HAX: Enable GuC for CI
Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 5ac8882..0a63f59 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, 0) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915/guc: Use correct error code for GuC initialization failure
Since commit 6ca9a2beb5 ("drm/i915: Unwind i915_gem_init() failure") we believed that we correctly handle all errors encountered during GuC initialization, including special one that indicates request to run driver with disabled GPU submission (-EIO). Unfortunately since commit 121981fafe ("drm/i915/guc: Combine enable_guc_loading|submission modparams") we stopped using that error code to avoid unwanted fallback to execlist submission mode. In result any GuC initialization failure was treated as non-recoverable error leading to driver load abort, so we could not even read related GuC error log to investigate cause of the problem. Fix that by always returning -EIO on uC hardware related failure. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Michal Winiarski Cc: Daniele Ceraolo Spurio Cc: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_uc.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 3a13cbb..1547e16 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -432,11 +432,8 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv) * Note that there is no fallback as either user explicitly asked for * the GuC or driver default option was to run with the GuC enabled. */ - if (GEM_WARN_ON(ret == -EIO)) - ret = -EINVAL; - dev_err(dev_priv->drm.dev, "GuC initialization failed %d\n", ret); - return ret; + return -EIO; /* We want to disable GPU submission but keep KMS alive */ } void intel_uc_fini_hw(struct drm_i915_private *dev_priv) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915/guc: Don't forget to free GuC error log
We're freeing GuC error log in uc_fini_hw() that matches corresponding uc_init_hw() but we missed the point that this log object is copied on error path and in case of failure in uc_init_hw() we will leak this object as uc_fini_hw() is never called. If we free this log object as part of the late uC cleanup, where we also release other firmware objects, we can avoid this BUG: [70841.001413] BUG drm_i915_gem_object (Tainted: G U W ): Objects remaining in drm_i915_gem_object on __kmem_cache_shutdown() [70841.001436] INFO: Slab 0xc94e41af objects=21 used=1 fp=0x1d60c40a flags=0x80008100 [70841.001466] Call Trace: [70841.001471] dump_stack+0x5e/0x8e [70841.001476] slab_err+0x99/0xb0 [70841.001483] ? __slab_alloc.isra.24.constprop.29+0x62/0x70 [70841.001491] ? __kmalloc+0x1f5/0x320 [70841.001497] __kmem_cache_shutdown+0x18b/0x400 [70841.001505] shutdown_cache+0x13/0x1c0 [70841.001511] kmem_cache_destroy+0x1c2/0x240 [70841.001517] ? __mutex_unlock_slowpath+0x38/0x270 [70841.001559] i915_gem_load_cleanup+0xbc/0x130 [i915] [70841.001595] i915_driver_cleanup_early+0x11/0x60 [i915] [70841.001630] i915_driver_load+0x708/0x1720 [i915] [70841.001638] ? trace_hardirqs_on_caller+0xe2/0x1c0 [70841.001673] i915_pci_probe+0x2d/0x90 [i915] [70841.001680] pci_device_probe+0x9c/0x120 [70841.001687] driver_probe_device+0x2a9/0x490 [70841.001694] __driver_attach+0xd9/0xe0 [70841.001700] ? driver_probe_device+0x490/0x490 [70841.001705] bus_for_each_dev+0x57/0x90 [70841.001712] bus_add_driver+0x1eb/0x260 [70841.001717] ? 0xa0685000 [70841.001723] driver_register+0x52/0xc0 [70841.001728] ? 0xa0685000 [70841.001733] do_one_initcall+0x39/0x170 [70841.001739] ? rcu_read_lock_sched_held+0x6f/0x80 [70841.001746] ? kmem_cache_alloc_trace+0x27b/0x2e0 [70841.001753] do_init_module+0x56/0x1ec [70841.001759] load_module+0x219e/0x2550 [70841.001766] ? vfs_read+0x121/0x140 [70841.001774] ? SyS_finit_module+0xa5/0xe0 [70841.001779] SyS_finit_module+0xa5/0xe0 [70841.001788] entry_SYSCALL_64_fastpath+0x22/0x8f [70841.001806] INFO: Object 0xeab7ed96 @offset=6208 [70841.001850] INFO: Allocated in i915_gem_object_create.part.32+0x1f/0x260 [i915] age=38 cpu=0 pid=2708 [70841.001861] kmem_cache_alloc+0x23d/0x2d0 [70841.001897] i915_gem_object_create.part.32+0x1f/0x260 [i915] [70841.001937] intel_guc_allocate_vma+0x15/0x100 [i915] [70841.001977] intel_guc_log_create+0x34/0x1c0 [i915] [70841.002014] intel_guc_init+0x5a/0x100 [i915] [70841.002051] intel_uc_init+0x3e/0xb0 [i915] [70841.002089] i915_gem_init+0x18e/0x540 [i915] [70841.002123] i915_driver_load+0xa7a/0x1720 [i915] [70841.002159] i915_pci_probe+0x2d/0x90 [i915] [70841.002165] pci_device_probe+0x9c/0x120 [70841.002171] driver_probe_device+0x2a9/0x490 [70841.002177] __driver_attach+0xd9/0xe0 [70841.002182] bus_for_each_dev+0x57/0x90 [70841.002188] bus_add_driver+0x1eb/0x260 [70841.002193] driver_register+0x52/0xc0 [70841.002198] do_one_initcall+0x39/0x170 [70841.002462] kmem_cache_destroy drm_i915_gem_object: Slab cache still has objects [70841.002491] Call Trace: [70841.002497] dump_stack+0x5e/0x8e [70841.002503] kmem_cache_destroy+0x1e0/0x240 [70841.002509] ? __mutex_unlock_slowpath+0x38/0x270 [70841.002551] i915_gem_load_cleanup+0xbc/0x130 [i915] [70841.002586] i915_driver_cleanup_early+0x11/0x60 [i915] [70841.002621] i915_driver_load+0x708/0x1720 [i915] [70841.002629] ? trace_hardirqs_on_caller+0xe2/0x1c0 [70841.002664] i915_pci_probe+0x2d/0x90 [i915] [70841.002671] pci_device_probe+0x9c/0x120 [70841.002678] driver_probe_device+0x2a9/0x490 [70841.002684] __driver_attach+0xd9/0xe0 [70841.002690] ? driver_probe_device+0x490/0x490 [70841.002696] bus_for_each_dev+0x57/0x90 [70841.002702] bus_add_driver+0x1eb/0x260 [70841.002708] ? 0xa0685000 [70841.002713] driver_register+0x52/0xc0 [70841.002719] ? 0xa0685000 [70841.002724] do_one_initcall+0x39/0x170 [70841.002731] ? rcu_read_lock_sched_held+0x6f/0x80 [70841.002737] ? kmem_cache_alloc_trace+0x27b/0x2e0 [70841.002745] do_init_module+0x56/0x1ec [70841.002751] load_module+0x219e/0x2550 [70841.002758] ? vfs_read+0x121/0x140 [70841.002766] ? SyS_finit_module+0xa5/0xe0 [70841.002772] SyS_finit_module+0xa5/0xe0 [70841.002781] entry_SYSCALL_64_fastpath+0x22/0x8f Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Sagar Arun Kamble Cc: Michal Winiarski Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_uc.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index 2f80cab..3a13cbb 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -27,6 +27,8 @@ #include "intel_guc.h" #include "i915_drv.h" +static void guc_free_load_err_log(struct intel_guc *guc); + /* Reset GuC providing us with fresh state for both GuC and HuC. */ static int __intel_uc_reset_hw(struct drm_i915_pr
[Intel-gfx] [PATCH 1/5] drm/i915/uc: Add few more load failure checkpoints
Additional load failure checkpoints added into uC initialization sequence should help us verify correctness of error handling. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson --- drivers/gpu/drm/i915/intel_uc.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c index e3f3509..2f80cab 100644 --- a/drivers/gpu/drm/i915/intel_uc.c +++ b/drivers/gpu/drm/i915/intel_uc.c @@ -287,6 +287,9 @@ int intel_uc_init(struct drm_i915_private *dev_priv) if (!HAS_GUC(dev_priv)) return -ENODEV; + if (i915_inject_load_failure()) + return -ENODEV; + ret = intel_guc_init(guc); if (ret) return ret; @@ -330,6 +333,11 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv) if (!USES_GUC(dev_priv)) return 0; + if (i915_inject_load_failure()) { + ret = -ECANCELED; + goto err_out; + } + GEM_BUG_ON(!HAS_GUC(dev_priv)); guc_disable_communication(guc); @@ -371,6 +379,9 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv) "retry %d more time(s)\n", ret, attempts); } + if (i915_inject_load_failure()) + ret = -ECANCELED; + /* Did we succeded or run out of retries? */ if (ret) goto err_log_capture; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/breadcrumbs: Drop request reference for the signaler thread
Quoting Tvrtko Ursulin (2018-01-31 17:18:55) > > On 22/01/2018 15:41, Chris Wilson wrote: > > +static void __intel_engine_remove_signal(struct intel_engine_cs *engine, > > + struct drm_i915_gem_request *request) > > +{ > > + struct intel_breadcrumbs *b = &engine->breadcrumbs; > > + > > + lockdep_assert_held(&b->rb_lock); > > + > > + /* > > + * Wake up all other completed waiters and select the > > + * next bottom-half for the next user interrupt. > > + */ > > + __intel_engine_remove_wait(engine, &request->signaling.wait); > > + > > + /* > > + * Find the next oldest signal. Note that as we have > > + * not been holding the lock, another client may > > Which lock, request-lock? b->first_signal seems to always be updated > under the b->rb_lock, so I am not sure of the > request->signaling.wait.seqno check. > > wait.seqno is also updated without the request->lock below, so maybe you > were talking about the rb_lock after all? What it means here is that since we took b->first_signal without holding the rb_lock, by the time we get to here (and have taken the rb_lock) b->first_signal may have changed and indeed someone else may have already retired the request and canceled the signaling. Or inserted a new signal into the tree. (iirc, this comment is unmodified.) > How does wait.seqno becomes 0 outside the rb_lock? Is it due RCU > business this patch adds? Like it is retired before the signaler runs? Not outside of the rb_lock, just before we notice. > > + * have installed an even older signal than the one > > + * we just completed - so double check we are still > > + * the oldest before picking the next one. > > + */ > > + if (request->signaling.wait.seqno) { > > + if (request == rcu_access_pointer(b->first_signal)) { > > + struct rb_node *rb = > > rb_next(&request->signaling.node); > > + rcu_assign_pointer(b->first_signal, > > +rb ? to_signaler(rb) : NULL); > > + } > > + > > + rb_erase(&request->signaling.node, &b->signals); > > + request->signaling.wait.seqno = 0; > > + } > > +} > > + > > +static struct drm_i915_gem_request *first_signal(struct intel_breadcrumbs > > *b) > > +{ > > + /* > > + * See the big warnings for i915_gem_active_get_rcu() and similarly > > + * for dma_fence_get_rcu_safe() that explain the intricacies involved > > + * here with defeating CPU/compiler speculation and enforcing > > + * the required memory barriers. > > + */ > > + do { > > + struct drm_i915_gem_request *request; > > + > > + request = rcu_dereference(b->first_signal); > > + if (request) > > + request = i915_gem_request_get_rcu(request); > > + > > + barrier(); > > + > > + if (!request || request == > > rcu_access_pointer(b->first_signal)) > > + return rcu_pointer_handoff(request); > > + > > + i915_gem_request_put(request); > > + } while (1); > > +} > > + > > static int intel_breadcrumbs_signaler(void *arg) > > { > > struct intel_engine_cs *engine = arg; > > @@ -667,41 +715,21 @@ static int intel_breadcrumbs_signaler(void *arg) > >* a new client. > >*/ > > rcu_read_lock(); > > - request = rcu_dereference(b->first_signal); > > - if (request) > > - request = i915_gem_request_get_rcu(request); > > + request = first_signal(b); > > get_ prefix would be good to signify a get vs peek. Maybe even _rcu suffix. Sold. > > rcu_read_unlock(); > > if (signal_complete(request)) { > > - local_bh_disable(); > > - dma_fence_signal(&request->fence); > > - local_bh_enable(); /* kick start the tasklets */ > > - > > - spin_lock_irq(&b->rb_lock); > > - > > - /* Wake up all other completed waiters and select the > > - * next bottom-half for the next user interrupt. > > - */ > > - __intel_engine_remove_wait(engine, > > -&request->signaling.wait); > > - > > - /* Find the next oldest signal. Note that as we have > > - * not been holding the lock, another client may > > - * have installed an even older signal than the one > > - * we just completed - so double check we are still > > - * the oldest before picking the next one. > > - */ > > - if (request == rcu_access_pointer(b->first_signal)) { > > - struct rb_node *rb = > > -
Re: [Intel-gfx] [PATCH] drm/i915/breadcrumbs: Drop request reference for the signaler thread
On 22/01/2018 15:41, Chris Wilson wrote: If we remember to cancel the signaler on a request when retiring it (after we know that the request has been signaled), we do not need to carry an additional request in the signaler itself. This prevents an issue whereby the signaler threads may be delayed and hold on to thousands of request references, causing severe memory fragmentation and premature oom (most noticeable on 32b snb due to the limited GFP_KERNEL and frequent use of inter-engine fences). Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_request.c | 6 +- drivers/gpu/drm/i915/intel_breadcrumbs.c | 149 +-- 2 files changed, 85 insertions(+), 70 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c index a0f451b4a4e8..e4eca6ba0d05 100644 --- a/drivers/gpu/drm/i915/i915_gem_request.c +++ b/drivers/gpu/drm/i915/i915_gem_request.c @@ -441,7 +441,10 @@ static void i915_gem_request_retire(struct drm_i915_gem_request *request) spin_lock_irq(&request->lock); if (request->waitboost) atomic_dec(&request->i915->gt_pm.rps.num_waiters); - dma_fence_signal_locked(&request->fence); + if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &request->fence.flags)) + dma_fence_signal_locked(&request->fence); + if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, &request->fence.flags)) + intel_engine_cancel_signaling(request); spin_unlock_irq(&request->lock); i915_priotree_fini(request->i915, &request->priotree); @@ -738,6 +741,7 @@ i915_gem_request_alloc(struct intel_engine_cs *engine, /* No zalloc, must clear what we need by hand */ req->global_seqno = 0; + req->signaling.wait.seqno = 0; req->file_priv = NULL; req->batch = NULL; req->capture_list = NULL; diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c index 86acac010bb8..e3667dc1e96d 100644 --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c @@ -235,7 +235,7 @@ void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine) struct intel_wait *wait, *n; if (!b->irq_armed) - goto wakeup_signaler; + return; /* * We only disarm the irq when we are idle (all requests completed), @@ -260,14 +260,6 @@ void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine) b->waiters = RB_ROOT; spin_unlock_irq(&b->rb_lock); - - /* -* The signaling thread may be asleep holding a reference to a request, -* that had its signaling cancelled prior to being preempted. We need -* to kick the signaler, just in case, to release any such reference. -*/ -wakeup_signaler: - wake_up_process(b->signaler); } static bool use_fake_irq(const struct intel_breadcrumbs *b) @@ -644,6 +636,62 @@ static void signaler_set_rtpriority(void) sched_setscheduler_nocheck(current, SCHED_FIFO, ¶m); } +static void __intel_engine_remove_signal(struct intel_engine_cs *engine, +struct drm_i915_gem_request *request) +{ + struct intel_breadcrumbs *b = &engine->breadcrumbs; + + lockdep_assert_held(&b->rb_lock); + + /* +* Wake up all other completed waiters and select the +* next bottom-half for the next user interrupt. +*/ + __intel_engine_remove_wait(engine, &request->signaling.wait); + + /* +* Find the next oldest signal. Note that as we have +* not been holding the lock, another client may Which lock, request-lock? b->first_signal seems to always be updated under the b->rb_lock, so I am not sure of the request->signaling.wait.seqno check. wait.seqno is also updated without the request->lock below, so maybe you were talking about the rb_lock after all? How does wait.seqno becomes 0 outside the rb_lock? Is it due RCU business this patch adds? Like it is retired before the signaler runs? +* have installed an even older signal than the one +* we just completed - so double check we are still +* the oldest before picking the next one. +*/ + if (request->signaling.wait.seqno) { + if (request == rcu_access_pointer(b->first_signal)) { + struct rb_node *rb = rb_next(&request->signaling.node); + rcu_assign_pointer(b->first_signal, + rb ? to_signaler(rb) : NULL); + } + + rb_erase(&request->signaling.node, &b->signals); + request->signaling.wait.seqno = 0; + } +} + +static struct drm_i915_gem_request *first_signal(struct intel_breadcrumbs *b) +{ + /* +* See the big warnings for i915_gem_active_get_rcu() and similarly +* for
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/7] drm/i915: Don't set cursor pipe select bits on g4x+ (rev2)
== Series Details == Series: series starting with [1/7] drm/i915: Don't set cursor pipe select bits on g4x+ (rev2) URL : https://patchwork.freedesktop.org/series/37362/ State : success == Summary == Test perf_pmu: Subgroup semaphore-wait-bcs0: fail -> PASS (shard-apl) fdo#104829 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 fdo#104829 https://bugs.freedesktop.org/show_bug.cgi?id=104829 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:2838 pass:1749 dwarn:1 dfail:0 fail:23 skip:1064 time:12633s shard-hswtotal:2838 pass:1736 dwarn:1 dfail:0 fail:10 skip:1090 time:11990s shard-snbtotal:2838 pass:1330 dwarn:1 dfail:0 fail:10 skip:1497 time:6629s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7839/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: mark all device info struct with __initconst"
On 31/01/18 02:15, Rodrigo Vivi wrote: On Tue, Jan 30, 2018 at 08:44:46AM +, Jani Nikula wrote: On Mon, 29 Jan 2018, Jani Nikula wrote: On Mon, 29 Jan 2018, Lionel Landwerlin wrote: On 29/01/18 09:02, Chris Wilson wrote: Quoting Lionel Landwerlin (2018-01-29 08:33:46) This reverts commit 5b54eddd3920e9f6f1a6d972454baf350cbae77e. Conflicts: drivers/gpu/drm/i915/i915_pci.c Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104805 Fixes: 5b54eddd3920 ("drm/i915: mark all device info struct with __initconst") So it ends up in the right place. -Chris Thanks, pushed. Please *always* wait for the full IGT results before pushing. Please *always* include a self-contained reason *why* in the commit message instead of relying on Bugzilla: link only. Please run 'dim fixes ' to get the proper tags; now Cc: stable is missing. Fixes: alone doesn't cut it now that v4.15 has been released. Rodrigo, please pick this up to drm-intel-next-fixes. This particular one conflicted with the icl ones: ++<<< HEAD ++=== + #define GEN11_FEATURES \ + GEN10_FEATURES, \ + .gen = 11, \ + .ddb_size = 2048, \ + .has_csr = 0 + + static const struct intel_device_info intel_icelake_11_info = { + GEN11_FEATURES, + .platform = INTEL_ICELAKE, + .is_alpha_support = 1, + .has_resource_streamer = 0, + }; + ++>>> 5db47e37b387... Revert "drm/i915: mark all device info struct with __initconst" So I'm assuming it is just a matter to remember to fix the next confclit removing initconst from icl? Yep, sorry for the conflict. Thanks for this and all other heads up. BR, Jani. No patch needs to be merged within an hour. There's never such a rush. Please let's give more people a chance to look at the patches before they get merged. Thanks, Jani. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2] drm/i915/guc: Allow preempt-client to be NULL (rev2)
== Series Details == Series: series starting with [v2] drm/i915/guc: Allow preempt-client to be NULL (rev2) URL : https://patchwork.freedesktop.org/series/37395/ State : success == Summary == Test perf_pmu: Subgroup semaphore-wait-bcs0: fail -> PASS (shard-apl) fdo#104829 Test gem_eio: Subgroup in-flight-suspend: pass -> FAIL (shard-hsw) fdo#104676 fdo#104829 https://bugs.freedesktop.org/show_bug.cgi?id=104829 fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676 shard-apltotal:1638 pass:1017 dwarn:1 dfail:0 fail:16 skip:604 time:7460s shard-hswtotal:2838 pass:1735 dwarn:1 dfail:0 fail:11 skip:1090 time:11932s shard-snbtotal:2838 pass:1330 dwarn:1 dfail:0 fail:10 skip:1497 time:6594s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7838/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Micro-optimize sampling loop
== Series Details == Series: drm/i915/pmu: Micro-optimize sampling loop URL : https://patchwork.freedesktop.org/series/37420/ State : success == Summary == Series 37420v1 drm/i915/pmu: Micro-optimize sampling loop https://patchwork.freedesktop.org/api/1.0/series/37420/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:419s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:430s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:371s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:483s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:281s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:484s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:482s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:463s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:450s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:563s fi-elk-e7500 total:224 pass:168 dwarn:9 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:281s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:510s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:388s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:398s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:415s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:446s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:411s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:455s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:498s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:451s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:499s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:579s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:429s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:508s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:523s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:487s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:482s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:415s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:433s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:520s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:393s Blacklisted hosts: fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:468s badc0398a06018a07f6f50a1ff5a5fd8a30b9944 drm-tip: 2018y-01m-31d-12h-17m-12s UTC integration manifest ef8f136b87be drm/i915/pmu: Micro-optimize sampling loop == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7840/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915/pmu: Micro-optimize sampling loop
Quoting Tvrtko Ursulin (2018-01-31 16:02:38) > From: Tvrtko Ursulin > > By carefully chosing slightly unsynchronized values for timer frequency > and period, we can remove the multiplications from the sampling loop and > replace them with shifts only. > > Downside is that the counter read callback now has to do a divide with a > non-power-of-two, but the rationale is that sampling loop which runs at > ~200 Hz, multiplied by number of engines, is more important than less > frequent counter read-out. Furthermore, the divide in counter read-out > seems to be optimized by the compiler to some shifts and multiply. > > We can only do all this at the expense of introducing a systematic error > to the sampling counters to the amount of 0.18%. At the same time we are > increasing the sampling rate from 200 to 238 Hz which may cancel some of > this out. > > Signed-off-by: Tvrtko Ursulin > Cc: Chris Wilson > --- > Motivated by Chris' insisting to use power-of-two scale factor in the > engine queue depth PMU series. I was actually reluctant to give in there > so this is even more questionable. :) > > I have no idea if it is cheaper to run the sampling timer at 200Hz with > some multiplies, or run it at 238Hz with only shifts. I can't say I have any insight into the timer wheel or hrtimer either. Let's watch. > FWIW 0.18% systematic error at least doesn't sound like a big deal when > sampling counters are concerned. Yeah, since even pinning it down to a 5% systematic error is hard, but we'll see if this 0.18% is the straw that breaks CI back! -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] drm/i915/pmu: Micro-optimize sampling loop
From: Tvrtko Ursulin By carefully chosing slightly unsynchronized values for timer frequency and period, we can remove the multiplications from the sampling loop and replace them with shifts only. Downside is that the counter read callback now has to do a divide with a non-power-of-two, but the rationale is that sampling loop which runs at ~200 Hz, multiplied by number of engines, is more important than less frequent counter read-out. Furthermore, the divide in counter read-out seems to be optimized by the compiler to some shifts and multiply. We can only do all this at the expense of introducing a systematic error to the sampling counters to the amount of 0.18%. At the same time we are increasing the sampling rate from 200 to 238 Hz which may cancel some of this out. Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson --- Motivated by Chris' insisting to use power-of-two scale factor in the engine queue depth PMU series. I was actually reluctant to give in there so this is even more questionable. :) I have no idea if it is cheaper to run the sampling timer at 200Hz with some multiplies, or run it at 238Hz with only shifts. FWIW 0.18% systematic error at least doesn't sound like a big deal when sampling counters are concerned. --- drivers/gpu/drm/i915/i915_pmu.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c index 3e1edc26f252..af732c086b86 100644 --- a/drivers/gpu/drm/i915/i915_pmu.c +++ b/drivers/gpu/drm/i915/i915_pmu.c @@ -29,9 +29,19 @@ #include "i915_pmu.h" #include "intel_ringbuffer.h" -/* Frequency for the sampling timer for events which need it. */ -#define FREQUENCY 200 -#define PERIOD max_t(u64, 1, NSEC_PER_SEC / FREQUENCY) +/* + * Frequency for the sampling timer for events which need it. + * + * The relationship between frequency and period is: + * PERIOD(ns) = 1e9 / FREQUENCY(Hz) + * + * We set the period to a power-of-two value 0x40 for simpler computations + * inside the sampling timer, at the expense of introducting a systematic error + * of 0.18%. This is caused by frequency (using as divisor for reading out + * certain counters) being rounded to 238, while 1e9 / 0x40 = 238.418579102. + */ +#define FREQUENCY 238 +#define PERIOD 0x40 #define ENGINE_SAMPLE_MASK \ (BIT(I915_SAMPLE_BUSY) | \ -- 2.14.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] drm-misc-fixes
So I've made an error when sending this out, it includes some stuff that is already on 4.15. Sorry about that, the only one that is needs to go in is this one: Daniel Vetter (1): drm/cirrus: Load lut in crtc_commit The pull request is fine, just the generated e-mail is wrong. Thanks! 2018-01-31 Gustavo Padovan : > Hi Dave, > > This one got applied late to drm-misc-fixes, it should go to 4.16 > anyway. Please pull, Thanks. > > Gustavo > > drm-misc-fixes-2018-01-31: > - fix lut loading for cirrus > The following changes since commit a8750ddca918032d6349adbf9a4b6555e7db20da: > > Linux 4.15-rc8 (2018-01-14 15:32:30 -0800) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-01-31 > > for you to fetch changes up to 745fd50f3b044db6a3922e1718306555613164b0: > > drm/cirrus: Load lut in crtc_commit (2018-01-31 13:14:33 +0100) > > > - fix lut loading for cirrus > > > Boris Brezillon (1): > drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state() > > Daniel Vetter (1): > drm/cirrus: Load lut in crtc_commit > > Dave Airlie (2): > Merge branch 'vmwgfx-fixes-4.15' of > git://people.freedesktop.org/~thomash/linux into drm-fixes > Merge tag 'drm-misc-fixes-2018-01-17' of > git://anongit.freedesktop.org/drm/drm-misc into drm-fixes > > Eric Anholt (1): > drm/vc4: Flush the caches before the bin jobs, as well. > > Jonathan Liu (3): > drm/sun4i: hdmi: Check for unset best_parent in > sun4i_tmds_determine_rate > drm/sun4i: hdmi: Fix incorrect assignment in sun4i_tmds_determine_rate > drm/sun4i: hdmi: Add missing rate halving check in > sun4i_tmds_determine_rate > > Rob Clark (1): > drm/vmwgfx: fix memory corruption with legacy/sou connectors > > Woody Suwalski (1): > drm/vmwgfx: Fix a boot time warning > > drivers/gpu/drm/cirrus/cirrus_mode.c| 40 > + > drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 9 --- > drivers/gpu/drm/vc4/vc4_gem.c | 33 +++- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +- > drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 4 +-- > 6 files changed, 61 insertions(+), 31 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Only allocate preempt context when required
Quoting Mika Kuoppala (2018-01-31 14:38:02) > > @@ -1988,6 +1988,11 @@ static int logical_ring_init(struct intel_engine_cs > > *engine) > > engine->execlists.elsp = > > engine->i915->regs + i915_mmio_reg_offset(RING_ELSP(engine)); > > > > + engine->execlists.preempt_complete_status = ~0u; > > This is to ensure that we catch a rogue status? Atleast we will > bug on of preempting with this status as the EXECLIST_ACTIVE_PREEMPT > will be false. 0 is the value for the i915->kernel_context. ~0u is currently invalid and that looks to be the case (that at least it will never match an active context) for the near future. > > + if (engine->i915->preempt_context) > > + engine->execlists.preempt_complete_status = > > + > > upper_32_bits(engine->i915->preempt_context->engine[engine->id].lrc_desc); > > > We have not upgraded the descriptor yet, so just use preempt_context->hw_id; The upper_32_bits should be set; and I think it is important that the usage is consistent. If we change the upper_32_bits later, we should try to remember to update the preempt_complete_status. I.e. I feel it is vital to remember that the complete_status is the upper_32_bits(lrc_desc) that just happens to be hw_id due to our limited definition today. > I would also like duplicate, from i915_gem_context.c, the assertion that > hw_id needs to be <= INT_MAX but didn't find a good spot. For what purpose? When defining lrc_desc checking that hw_id fits within the field width would be sensible. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, This one got applied late to drm-misc-fixes, it should go to 4.16 anyway. Please pull, Thanks. Gustavo drm-misc-fixes-2018-01-31: - fix lut loading for cirrus The following changes since commit a8750ddca918032d6349adbf9a4b6555e7db20da: Linux 4.15-rc8 (2018-01-14 15:32:30 -0800) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-01-31 for you to fetch changes up to 745fd50f3b044db6a3922e1718306555613164b0: drm/cirrus: Load lut in crtc_commit (2018-01-31 13:14:33 +0100) - fix lut loading for cirrus Boris Brezillon (1): drm/vc4: Fix NULL pointer dereference in vc4_save_hang_state() Daniel Vetter (1): drm/cirrus: Load lut in crtc_commit Dave Airlie (2): Merge branch 'vmwgfx-fixes-4.15' of git://people.freedesktop.org/~thomash/linux into drm-fixes Merge tag 'drm-misc-fixes-2018-01-17' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Eric Anholt (1): drm/vc4: Flush the caches before the bin jobs, as well. Jonathan Liu (3): drm/sun4i: hdmi: Check for unset best_parent in sun4i_tmds_determine_rate drm/sun4i: hdmi: Fix incorrect assignment in sun4i_tmds_determine_rate drm/sun4i: hdmi: Add missing rate halving check in sun4i_tmds_determine_rate Rob Clark (1): drm/vmwgfx: fix memory corruption with legacy/sou connectors Woody Suwalski (1): drm/vmwgfx: Fix a boot time warning drivers/gpu/drm/cirrus/cirrus_mode.c| 40 + drivers/gpu/drm/sun4i/sun4i_hdmi_tmds_clk.c | 9 --- drivers/gpu/drm/vc4/vc4_gem.c | 33 +++- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +-- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 4 +-- 6 files changed, 61 insertions(+), 31 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next-fixes
Hi Dave, two fixes for the 4.16 cycle from the drm-misc-next-fixes. drm-misc-next-fixes-2018-01-31: This contains a fix to restrict what lessee can do with masters and another one when waiting for timeouts on reservation objects. The following changes since commit 341a0ffceaa44660c43d219a3b2569ebbd7d3ad1: drm: Fix PANEL_ORIENTATION_QUIRKS breaking the Kconfig DRM menuconfig (2018-01-17 10:10:18 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2018-01-31 for you to fetch changes up to 761e05a702f5d537ffcca1ba933f9f0a968aa022: drm: Check for lessee in DROP_MASTER ioctl (2018-01-31 09:27:51 +0100) This contains a fix to restrict what lessee can do with masters and another one when waiting for timeouts on reservation objects. Christian König (1): dma-buf: fix reservation_object_wait_timeout_rcu once more v2 Keith Packard (1): drm: Check for lessee in DROP_MASTER ioctl drivers/dma-buf/reservation.c | 8 +--- drivers/gpu/drm/drm_auth.c| 6 ++ 2 files changed, 11 insertions(+), 3 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Don't set cursor pipe select bits on g4x+ (rev2)
== Series Details == Series: series starting with [1/7] drm/i915: Don't set cursor pipe select bits on g4x+ (rev2) URL : https://patchwork.freedesktop.org/series/37362/ State : success == Summary == Series 37362v2 series starting with [1/7] drm/i915: Don't set cursor pipe select bits on g4x+ https://patchwork.freedesktop.org/api/1.0/series/37362/revisions/2/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> INCOMPLETE (fi-bdw-5557u) fdo#104162 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> PASS (fi-snb-2520m) fdo#103713 fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:109 pass:105 dwarn:0 dfail:0 fail:0 skip:3 fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:422s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:490s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:283s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:478s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:487s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:471s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:454s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:573s fi-elk-e7500 total:224 pass:168 dwarn:10 dfail:0 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:286s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:514s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:397s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:399s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:416s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:449s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:411s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:463s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:496s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:450s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:502s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:583s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:438s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:509s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:525s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:494s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:475s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:417s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:430s fi-snb-2520m total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:522s fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:403s Blacklisted hosts: fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:472s badc0398a06018a07f6f50a1ff5a5fd8a30b9944 drm-tip: 2018y-01m-31d-12h-17m-12s UTC integration manifest a6b40df641b0 drm/i915: s/plane/i9xx_plane/ 309c54212a22 drm/i915: Drop WaDoubleCursorLP3Latency:ivb ab266dd84d7a drm/i915: Disable trickle feed for SNB/IVB cursors 45da2273b46f drm/i915: Clean up cursor defines 8948a9152607 drm/i915: Have plane->get_hw_state() return the current pipe db3c2d0815ab drm/i915: Set the primary plane pipe select bits on gen4 45bad81fbb4c drm/i915: Don't set cursor pipe select bits on g4x+ == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7839/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915: Only allocate preempt context when required
Chris Wilson writes: > If we remove some hardcoded assumptions about the preempt context having > a fixed id, reserved from use by normal user contexts, we may only > allocate the i915_gem_context when required. Then the subsequent > decisions on using preemption reduce to having the preempt context > available. > > Signed-off-by: Chris Wilson > Cc: Michal Winiarski > Cc: Tvrtko Ursulin > Cc: Arkadiusz Hiler > Cc: Mika Kuoppala > Cc: Daniele Ceraolo Spurio > --- > drivers/gpu/drm/i915/i915_gem_context.c | 29 > > drivers/gpu/drm/i915/intel_engine_cs.c | 6 ++--- > drivers/gpu/drm/i915/intel_guc_submission.c | 24 +++- > drivers/gpu/drm/i915/intel_lrc.c | 17 +- > drivers/gpu/drm/i915/intel_ringbuffer.h | 5 > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 6 - > 6 files changed, 46 insertions(+), 41 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c > b/drivers/gpu/drm/i915/i915_gem_context.c > index 648e7536ff51..d69c8f1a4e78 100644 > --- a/drivers/gpu/drm/i915/i915_gem_context.c > +++ b/drivers/gpu/drm/i915/i915_gem_context.c > @@ -449,10 +449,14 @@ destroy_kernel_context(struct i915_gem_context **ctxp) > i915_gem_context_free(ctx); > } > > +static bool needs_preempt_context(struct drm_i915_private *i915) > +{ > + return HAS_LOGICAL_RING_PREEMPTION(i915); > +} > + > int i915_gem_contexts_init(struct drm_i915_private *dev_priv) > { > struct i915_gem_context *ctx; > - int err; > > GEM_BUG_ON(dev_priv->kernel_context); Please consider adding GEM_BUG_ON(dev_priv->preempt_context); here even tho the kernel_context should act as a master guard for init ordering errors. Even if no other than documenting that we expect a clean slate in this regard also. > > @@ -468,8 +472,7 @@ int i915_gem_contexts_init(struct drm_i915_private > *dev_priv) > ctx = i915_gem_context_create_kernel(dev_priv, I915_PRIORITY_MIN); > if (IS_ERR(ctx)) { > DRM_ERROR("Failed to create default global context\n"); > - err = PTR_ERR(ctx); > - goto err; > + return PTR_ERR(ctx); > } > /* >* For easy recognisablity, we want the kernel context to be 0 and then > @@ -479,23 +482,18 @@ int i915_gem_contexts_init(struct drm_i915_private > *dev_priv) > dev_priv->kernel_context = ctx; > > /* highest priority; preempting task */ > - ctx = i915_gem_context_create_kernel(dev_priv, INT_MAX); > - if (IS_ERR(ctx)) { > - DRM_ERROR("Failed to create default preempt context\n"); > - err = PTR_ERR(ctx); > - goto err_kernel_context; It seems this error path has been wrong all along. > + if (needs_preempt_context(dev_priv)) { > + ctx = i915_gem_context_create_kernel(dev_priv, INT_MAX); > + if (!IS_ERR(ctx)) > + dev_priv->preempt_context = ctx; > + else > + DRM_ERROR("Failed to create preempt context; disabling > preemption\n"); > } > - dev_priv->preempt_context = ctx; > > DRM_DEBUG_DRIVER("%s context support initialized\n", >dev_priv->engine[RCS]->context_size ? "logical" : >"fake"); > return 0; > - > -err_kernel_context: > - destroy_kernel_context(&dev_priv->kernel_context); > -err: > - return err; > } > > void i915_gem_contexts_lost(struct drm_i915_private *dev_priv) > @@ -521,7 +519,8 @@ void i915_gem_contexts_fini(struct drm_i915_private *i915) > { > lockdep_assert_held(&i915->drm.struct_mutex); > > - destroy_kernel_context(&i915->preempt_context); > + if (i915->preempt_context) > + destroy_kernel_context(&i915->preempt_context); > destroy_kernel_context(&i915->kernel_context); > > /* Must free all deferred contexts (via flush_workqueue) first */ > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c > b/drivers/gpu/drm/i915/intel_engine_cs.c > index 7eebfbb95e89..bf634432c9c6 100644 > --- a/drivers/gpu/drm/i915/intel_engine_cs.c > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c > @@ -631,7 +631,7 @@ int intel_engine_init_common(struct intel_engine_cs > *engine) >* Similarly the preempt context must always be available so that >* we can interrupt the engine at any time. >*/ > - if (HAS_LOGICAL_RING_PREEMPTION(engine->i915)) { > + if (engine->i915->preempt_context) { > ring = engine->context_pin(engine, > engine->i915->preempt_context); > if (IS_ERR(ring)) { > @@ -656,7 +656,7 @@ int intel_engine_init_common(struct intel_engine_cs > *engine) > err_breadcrumbs: > intel_engine_fini_breadcrumbs(engine); > err_unpin_preempt: > - if (HAS_LOGICAL_RING_PREEMPTION(engine->i915)) > + if (engine->i915->preempt_context) >
[Intel-gfx] [PATCH v2 4/7] drm/i915: Clean up cursor defines
From: Ville Syrjälä Use MCURSOR_ instead of CURSOR_ as the prefix for the non-845/865 cursor defines consistently, and move the pipe CSC enable bit next to the other non-845/865 cursor defines. v2: Take care of gvt uses as well Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/gvt/fb_decoder.c | 12 ++-- drivers/gpu/drm/i915/i915_reg.h | 22 +++--- drivers/gpu/drm/i915/intel_display.c | 16 3 files changed, 25 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/i915/gvt/fb_decoder.c b/drivers/gpu/drm/i915/gvt/fb_decoder.c index 6b50fe78dc1b..73c0c2096a62 100644 --- a/drivers/gpu/drm/i915/gvt/fb_decoder.c +++ b/drivers/gpu/drm/i915/gvt/fb_decoder.c @@ -303,16 +303,16 @@ static int cursor_mode_to_drm(int mode) int cursor_pixel_formats_index = 4; switch (mode) { - case CURSOR_MODE_128_ARGB_AX: + case MCURSOR_MODE_128_ARGB_AX: cursor_pixel_formats_index = 0; break; - case CURSOR_MODE_256_ARGB_AX: + case MCURSOR_MODE_256_ARGB_AX: cursor_pixel_formats_index = 1; break; - case CURSOR_MODE_64_ARGB_AX: + case MCURSOR_MODE_64_ARGB_AX: cursor_pixel_formats_index = 2; break; - case CURSOR_MODE_64_32B_AX: + case MCURSOR_MODE_64_32B_AX: cursor_pixel_formats_index = 3; break; @@ -345,8 +345,8 @@ int intel_vgpu_decode_cursor_plane(struct intel_vgpu *vgpu, return -ENODEV; val = vgpu_vreg_t(vgpu, CURCNTR(pipe)); - mode = val & CURSOR_MODE; - plane->enabled = (mode != CURSOR_MODE_DISABLE); + mode = val & MCURSOR_MODE; + plane->enabled = (mode != MCURSOR_MODE_DISABLE); if (!plane->enabled) return -ENODEV; diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index ebb41f279134..dbcb4de92a63 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -5891,7 +5891,6 @@ enum { #define CURSOR_GAMMA_ENABLE 0x4000 #define CURSOR_STRIDE_SHIFT 28 #define CURSOR_STRIDE(x) ((ffs(x)-9) << CURSOR_STRIDE_SHIFT) /* 256,512,1k,2k */ -#define CURSOR_PIPE_CSC_ENABLE (1<<24) #define CURSOR_FORMAT_SHIFT 24 #define CURSOR_FORMAT_MASK (0x07 << CURSOR_FORMAT_SHIFT) #define CURSOR_FORMAT_2C (0x00 << CURSOR_FORMAT_SHIFT) @@ -5900,20 +5899,21 @@ enum { #define CURSOR_FORMAT_ARGB (0x04 << CURSOR_FORMAT_SHIFT) #define CURSOR_FORMAT_XRGB (0x05 << CURSOR_FORMAT_SHIFT) /* New style CUR*CNTR flags */ -#define CURSOR_MODE 0x27 -#define CURSOR_MODE_DISABLE 0x00 -#define CURSOR_MODE_128_32B_AX 0x02 -#define CURSOR_MODE_256_32B_AX 0x03 -#define CURSOR_MODE_64_32B_AX 0x07 -#define CURSOR_MODE_128_ARGB_AX ((1 << 5) | CURSOR_MODE_128_32B_AX) -#define CURSOR_MODE_256_ARGB_AX ((1 << 5) | CURSOR_MODE_256_32B_AX) -#define CURSOR_MODE_64_ARGB_AX ((1 << 5) | CURSOR_MODE_64_32B_AX) +#define MCURSOR_MODE 0x27 +#define MCURSOR_MODE_DISABLE 0x00 +#define MCURSOR_MODE_128_32B_AX 0x02 +#define MCURSOR_MODE_256_32B_AX 0x03 +#define MCURSOR_MODE_64_32B_AX 0x07 +#define MCURSOR_MODE_128_ARGB_AX ((1 << 5) | MCURSOR_MODE_128_32B_AX) +#define MCURSOR_MODE_256_ARGB_AX ((1 << 5) | MCURSOR_MODE_256_32B_AX) +#define MCURSOR_MODE_64_ARGB_AX ((1 << 5) | MCURSOR_MODE_64_32B_AX) #define MCURSOR_PIPE_SELECT_MASK (0x3 << 28) #define MCURSOR_PIPE_SELECT_SHIFT28 #define MCURSOR_PIPE_SELECT(pipe)((pipe) << 28) #define MCURSOR_GAMMA_ENABLE (1 << 26) -#define CURSOR_ROTATE_180(1<<15) -#define CURSOR_TRICKLE_FEED_DISABLE (1 << 14) +#define MCURSOR_PIPE_CSC_ENABLE (1<<24) +#define MCURSOR_ROTATE_180 (1<<15) +#define MCURSOR_TRICKLE_FEED_DISABLE (1 << 14) #define _CURABASE 0x70084 #define _CURAPOS 0x70088 #define CURSOR_POS_MASK 0x007FF diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index feae6bd51a44..0cf02f226fd4 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -9549,20 +9549,20 @@ static u32 i9xx_cursor_ctl(const struct intel_crtc_state *crtc_state, cntl = MCURSOR_GAMMA_ENABLE; if (HAS_DDI(dev_priv)) - cntl |= CURSOR_PIPE_CSC_ENABLE; + cntl |= MCURSOR_PIPE_CSC_ENABLE; if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv)) cntl |= MCURSOR_PIPE_SELECT(crtc->pipe); switch (plane_state->base.crtc_w) { case 64: - cntl |= CURSOR_MODE_64_ARGB_AX; + cntl |= MCURSOR_MODE_64_ARGB_AX; break; case 128: - cntl |= CURSOR_MODE_128_ARGB_AX; + cntl |= MCURSOR_MODE_128_ARGB_AX; break; case 256: - cntl |= CURSOR_MODE_256_ARGB_AX; + cntl |= MCURSOR_M
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/ast: Load lut in crtc_commit
== Series Details == Series: drm/ast: Load lut in crtc_commit URL : https://patchwork.freedesktop.org/series/37398/ State : failure == Summary == Test perf_pmu: Subgroup most-busy-check-all-vecs0: incomplete -> PASS (shard-apl) Test kms_flip: Subgroup plain-flip-fb-recreate: fail -> PASS (shard-hsw) fdo#100368 Subgroup 2x-dpms-vs-vblank-race-interruptible: pass -> FAIL (shard-hsw) Subgroup modeset-vs-vblank-race: pass -> FAIL (shard-hsw) fdo#103060 Test gem_eio: Subgroup in-flight-suspend: pass -> FAIL (shard-hsw) fdo#104676 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#104676 https://bugs.freedesktop.org/show_bug.cgi?id=104676 shard-apltotal:1321 pass:823 dwarn:1 dfail:0 fail:11 skip:486 time:6183s shard-hswtotal:2838 pass:1733 dwarn:1 dfail:0 fail:13 skip:1090 time:11938s shard-snbtotal:2838 pass:1328 dwarn:1 dfail:0 fail:11 skip:1498 time:6572s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7837/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/7] drm/i915: Drop WaDoubleCursorLP3Latency:ivb
On Tue, 2018-01-30 at 22:38 +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > WaDoubleCursorLP3Latency was meant for pre-production hardware. > Drop it. > Reviewed-by: Mika Kahola > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/intel_pm.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > b/drivers/gpu/drm/i915/intel_pm.c > index 0b92ea1dbd40..8eac3895ea9a 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -2916,10 +2916,6 @@ static void intel_fixup_cur_wm_latency(struct > drm_i915_private *dev_priv, > /* ILK cursor LP0 latency is 1300 ns */ > if (IS_GEN5(dev_priv)) > wm[0] = 13; > - > - /* WaDoubleCursorLP3Latency:ivb */ > - if (IS_IVYBRIDGE(dev_priv)) > - wm[3] *= 2; > } > > int ilk_wm_max_level(const struct drm_i915_private *dev_priv) -- Mika Kahola - Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Move the scheduler feature bits into the purview of the engines
Chris Wilson writes: > Rather than having the high level ioctl interface guess the underlying > implementation details, having the implementation declare what > capabilities it exports. We define an intel_driver_caps, similar to the > intel_device_info, which instead of trying to describe the HW gives > details on what the driver itself supports. This is then populated by > the engine backend for the new scheduler capability field for use > elsewhere. > > Signed-off-by: Chris Wilson > Cc: Tomasz Lis > Cc: Joonas Lahtinen > Cc: Tvrtko Ursulin > Cc: Michal Wajdeczko > --- > drivers/gpu/drm/i915/i915_drv.c | 8 +--- > drivers/gpu/drm/i915/i915_drv.h | 2 ++ > drivers/gpu/drm/i915/i915_gem.c | 3 +++ > drivers/gpu/drm/i915/i915_gpu_error.c| 7 +-- > drivers/gpu/drm/i915/intel_device_info.c | 6 ++ > drivers/gpu/drm/i915/intel_device_info.h | 7 +++ > drivers/gpu/drm/i915/intel_lrc.c | 6 ++ > 7 files changed, 30 insertions(+), 9 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c > index 1ec12add34b2..733f71637914 100644 > --- a/drivers/gpu/drm/i915/i915_drv.c > +++ b/drivers/gpu/drm/i915/i915_drv.c > @@ -372,13 +372,7 @@ static int i915_getparam(struct drm_device *dev, void > *data, > value = i915_gem_mmap_gtt_version(); > break; > case I915_PARAM_HAS_SCHEDULER: > - value = 0; > - if (dev_priv->engine[RCS] && dev_priv->engine[RCS]->schedule) { > - value |= I915_SCHEDULER_CAP_ENABLED; > - value |= I915_SCHEDULER_CAP_PRIORITY; > - if (HAS_LOGICAL_RING_PREEMPTION(dev_priv)) > - value |= I915_SCHEDULER_CAP_PREEMPTION; > - } > + value = dev_priv->caps.scheduler; Use the shiny CAP_PRIORITY instead of rcs->schedule on the I915_CONTEXT_PARAM_PRIORITY validation? -Mika > break; > > case I915_PARAM_MMAP_VERSION: > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index 388b72cccde4..ae434c9d2b4f 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -468,6 +468,7 @@ struct i915_gpu_state { > u32 reset_count; > u32 suspend_count; > struct intel_device_info device_info; > + struct intel_driver_caps driver_caps; > struct i915_params params; > > struct i915_error_uc { > @@ -1808,6 +1809,7 @@ struct drm_i915_private { > struct kmem_cache *priorities; > > const struct intel_device_info info; > + struct intel_driver_caps caps; > > /** >* Data Stolen Memory - aka "i915 stolen memory" gives us the start and > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 062b21408698..ad7bd0dc57ee 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3223,8 +3223,11 @@ void i915_gem_set_wedged(struct drm_i915_private *i915) >* start to complete all requests. >*/ > engine->submit_request = nop_complete_submit_request; > + engine->schedule = NULL; > } > > + i915->caps.scheduler = 0; > + > /* >* Make sure no request can slip through without getting completed by >* either this call here to intel_engine_init_global_seqno, or the one > diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c > b/drivers/gpu/drm/i915/i915_gpu_error.c > index a81351d9e3a6..a92b0c0377c7 100644 > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > @@ -573,11 +573,13 @@ static void print_error_obj(struct > drm_i915_error_state_buf *m, > } > > static void err_print_capabilities(struct drm_i915_error_state_buf *m, > -const struct intel_device_info *info) > +const struct intel_device_info *info, > +const struct intel_driver_caps *caps) > { > struct drm_printer p = i915_error_printer(m); > > intel_device_info_dump_flags(info, &p); > + intel_driver_caps_print(caps, &p); > } > > static void err_print_params(struct drm_i915_error_state_buf *m, > @@ -800,7 +802,7 @@ int i915_error_state_to_str(struct > drm_i915_error_state_buf *m, > if (error->display) > intel_display_print_error_state(m, error->display); > > - err_print_capabilities(m, &error->device_info); > + err_print_capabilities(m, &error->device_info, &error->driver_caps); > err_print_params(m, &error->params); > err_print_uc(m, &error->uc); > > @@ -1731,6 +1733,7 @@ static void i915_capture_gen_state(struct > drm_i915_private *dev_priv, > memcpy(&error->device_info, > INTEL_INFO(dev_priv), > sizeof(error->device_info)); > + error->driver_caps = dev_priv->caps; > } > > static _
Re: [Intel-gfx] [PATCH igt] tools/intel_reg: Add reading and writing registers through engine
Jani Nikula writes: > On Mon, 22 Jan 2018, Mika Kuoppala wrote: >> Jani Nikula writes: >> >>> On Mon, 08 Jan 2018, Mika Kuoppala wrote: Add option to specify engine for register read/write operation. If engine is specified, use MI_LOAD_REGISTER_IMM and MI_STORE_REGISTER_IMM to write and read register using a batch targeted at that engine. >>> >>> Copy-pasting from the man page, we already have the notation: >>> >>> "Registers are defined as >>> [(PORTNAME|PORTNUM|MMIO-OFFSET):](REGNAME|REGADDR)." >>> >>> Why don't we add this as ENGINE:REGNAME or something instead of an extra >>> --engine parameter? As a "port". Sure, it's more work, but I really like >>> the current possibility of reading all types of registers at once. Now >>> you prevent dumps that would contain both mmio and batch based reads. >>> >> >> Are you ok with the latest version? As discussed in irc, there are >> problems with trying to add engines as ports, due to dynamic nature >> and also that the existing infra relies on PORTNAME being mmio >> for symbolic register dumping to work correctly. >> >> for the wart of if (reg->engine) in read/write paths >> we gain the benefits of mmio dumps with engines. > > Can't say I would've reviewed all the engine bits and pieces, but > > Acked-by: Jani Nikula Thanks for ack and review. Pushed. -Mika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Move SST DP link retraining into the ->post_hotplug() hook
On Tue, Jan 30, 2018 at 06:16:59PM -0500, Lyude Paul wrote: > On Wed, 2018-01-17 at 21:21 +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Doing link retraining from the short pulse handler is problematic since > > that might introduce deadlocks with MST sideband processing. Currently > > we don't retrain MST links from this code, but we want to change that. > > So better to move the entire thing to the hotplug work. We can utilize > > the new encoder->hotplug() hook for this. > > > > The only thing we leave in the short pulse handler is the link status > > check. That one still depends on the link parameters stored under > > intel_dp, so no locking around that but races should be mostly harmless > > as the actual retraining code will recheck the link state if we > > end up there by mistake. > > > > v2: Rebase due to ->post_hotplug() now being just ->hotplug() > > Check the connector type to figure out if we should do > > the HDMI thing or the DP think for DDI > > > > Cc: Manasi Navare > > Cc: Maarten Lankhorst > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/i915/intel_ddi.c | 10 +- > > drivers/gpu/drm/i915/intel_dp.c | 196 ++-- > > --- > > drivers/gpu/drm/i915/intel_drv.h | 2 + > > 3 files changed, 120 insertions(+), 88 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c > > b/drivers/gpu/drm/i915/intel_ddi.c > > index 25793bdc692f..5f3d58f1ae6e 100644 > > --- a/drivers/gpu/drm/i915/intel_ddi.c > > +++ b/drivers/gpu/drm/i915/intel_ddi.c > > @@ -2880,7 +2880,10 @@ static bool intel_ddi_hotplug(struct intel_encoder > > *encoder, > > drm_modeset_acquire_init(&ctx, 0); > > > > for (;;) { > > - ret = intel_hdmi_reset_link(encoder, &ctx); > > + if (connector->base.connector_type == > > DRM_MODE_CONNECTOR_HDMIA) > > + ret = intel_hdmi_reset_link(encoder, &ctx); > > + else > > + ret = intel_dp_retrain_link(encoder, &ctx); > > > > if (ret == -EDEADLK) { > > drm_modeset_backoff(&ctx); > > @@ -3007,10 +3010,7 @@ void intel_ddi_init(struct drm_i915_private > > *dev_priv, > > enum port port) > > drm_encoder_init(&dev_priv->drm, encoder, &intel_ddi_funcs, > > DRM_MODE_ENCODER_TMDS, "DDI %c", port_name(port)); > > > > - if (init_hdmi) > > - intel_encoder->hotplug = intel_ddi_hotplug; > > - else > > - intel_encoder->hotplug = intel_encoder_hotplug; > > + intel_encoder->hotplug = intel_ddi_hotplug; > > intel_encoder->compute_output_type = intel_ddi_compute_output_type; > > intel_encoder->compute_config = intel_ddi_compute_config; > > intel_encoder->enable = intel_enable_ddi; > > diff --git a/drivers/gpu/drm/i915/intel_dp.c > > b/drivers/gpu/drm/i915/intel_dp.c > > index 6bbf14410c2a..152016e09a11 100644 > > --- a/drivers/gpu/drm/i915/intel_dp.c > > +++ b/drivers/gpu/drm/i915/intel_dp.c > > @@ -4275,12 +4275,83 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp) > > return -EINVAL; > > } > > > > -static void > > -intel_dp_retrain_link(struct intel_dp *intel_dp) > > +static bool > > +intel_dp_needs_link_retrain(struct intel_dp *intel_dp) > > +{ > > + u8 link_status[DP_LINK_STATUS_SIZE]; > > + > > + if (!intel_dp_get_link_status(intel_dp, link_status)) { > > + DRM_ERROR("Failed to get link status\n"); > > + return false; > > + } > > + > > + /* > > +* Validate the cached values of intel_dp->link_rate and > > +* intel_dp->lane_count before attempting to retrain. > > +*/ > > + if (!intel_dp_link_params_valid(intel_dp, intel_dp->link_rate, > > + intel_dp->lane_count)) > > + return false; > > + > > + /* Retrain if Channel EQ or CR not ok */ > > + return !drm_dp_channel_eq_ok(link_status, intel_dp->lane_count); > > +} > > + > > +/* > > + * If display is now connected check links status, > > + * there has been known issues of link loss triggering > > + * long pulse. > > + * > > + * Some sinks (eg. ASUS PB287Q) seem to perform some > > + * weird HPD ping pong during modesets. So we can apparently > > + * end up with HPD going low during a modeset, and then > > + * going back up soon after. And once that happens we must > > + * retrain the link to get a picture. That's in case no > > + * userspace component reacted to intermittent HPD dip. > > + */ > > +int intel_dp_retrain_link(struct intel_encoder *encoder, > > + struct drm_modeset_acquire_ctx *ctx) > > { > > - struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base; > > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev); > > - struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc); > > + struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base); > > + struct intel_connector *connector = intel_dp->attached_connector; > > + struct drm_connector_state *con
Re: [Intel-gfx] [PATCH v2] drm/i915/guc: Allow preempt-client to be NULL
Chris Wilson writes: > In the next patch, we may only conditionally allocate the preempt-client > if there is a global preempt context and so we need to be prepared in > case the preempt-client itself is NULL. > > v2: Grep for more preempt_client. > > Signed-off-by: Chris Wilson > Cc: Michal Winiarski > Cc: Arkadiusz Hiler > Cc: Daniele Ceraolo Spurio > Cc: Michel Thierry > Cc: Michal Wajdeczko Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_debugfs.c | 8 +--- > drivers/gpu/drm/i915/intel_guc_submission.c | 27 +-- > drivers/gpu/drm/i915/selftests/intel_guc.c | 20 +++- > 3 files changed, 33 insertions(+), 22 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c > b/drivers/gpu/drm/i915/i915_debugfs.c > index 3849ded354e3..9e44adef30f0 100644 > --- a/drivers/gpu/drm/i915/i915_debugfs.c > +++ b/drivers/gpu/drm/i915/i915_debugfs.c > @@ -2338,7 +2338,6 @@ static int i915_guc_info(struct seq_file *m, void *data) > return -ENODEV; > > GEM_BUG_ON(!guc->execbuf_client); > - GEM_BUG_ON(!guc->preempt_client); > > seq_printf(m, "Doorbell map:\n"); > seq_printf(m, "\t%*pb\n", GUC_NUM_DOORBELLS, guc->doorbell_bitmap); > @@ -2346,8 +2345,11 @@ static int i915_guc_info(struct seq_file *m, void > *data) > > seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client); > i915_guc_client_info(m, dev_priv, guc->execbuf_client); > - seq_printf(m, "\nGuC preempt client @ %p:\n", guc->preempt_client); > - i915_guc_client_info(m, dev_priv, guc->preempt_client); > + if (guc->preempt_client) { > + seq_printf(m, "\nGuC preempt client @ %p:\n", > +guc->preempt_client); > + i915_guc_client_info(m, dev_priv, guc->preempt_client); > + } > > i915_guc_log_info(m, dev_priv); > > diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c > b/drivers/gpu/drm/i915/intel_guc_submission.c > index 1f3a8786bbdc..4ea65df05e02 100644 > --- a/drivers/gpu/drm/i915/intel_guc_submission.c > +++ b/drivers/gpu/drm/i915/intel_guc_submission.c > @@ -832,10 +832,12 @@ static int guc_clients_doorbell_init(struct intel_guc > *guc) > if (ret) > return ret; > > - ret = create_doorbell(guc->preempt_client); > - if (ret) { > - destroy_doorbell(guc->execbuf_client); > - return ret; > + if (guc->preempt_client) { > + ret = create_doorbell(guc->preempt_client); > + if (ret) { > + destroy_doorbell(guc->execbuf_client); > + return ret; > + } > } > > return 0; > @@ -848,8 +850,11 @@ static void guc_clients_doorbell_fini(struct intel_guc > *guc) >* Instead of trying (in vain) to communicate with it, let's just >* cleanup the doorbell HW and our internal state. >*/ > - __destroy_doorbell(guc->preempt_client); > - __update_doorbell_desc(guc->preempt_client, GUC_DOORBELL_INVALID); > + if (guc->preempt_client) { > + __destroy_doorbell(guc->preempt_client); > + __update_doorbell_desc(guc->preempt_client, > +GUC_DOORBELL_INVALID); > + } > __destroy_doorbell(guc->execbuf_client); > __update_doorbell_desc(guc->execbuf_client, GUC_DOORBELL_INVALID); > } > @@ -998,10 +1003,11 @@ static void guc_clients_destroy(struct intel_guc *guc) > { > struct intel_guc_client *client; > > - client = fetch_and_zero(&guc->execbuf_client); > - guc_client_free(client); > - > client = fetch_and_zero(&guc->preempt_client); > + if (client) > + guc_client_free(client); > + > + client = fetch_and_zero(&guc->execbuf_client); > guc_client_free(client); > } > > @@ -1160,7 +1166,8 @@ int intel_guc_submission_enable(struct intel_guc *guc) > GEM_BUG_ON(!guc->execbuf_client); > > guc_reset_wq(guc->execbuf_client); > - guc_reset_wq(guc->preempt_client); > + if (guc->preempt_client) > + guc_reset_wq(guc->preempt_client); > > err = intel_guc_sample_forcewake(guc); > if (err) > diff --git a/drivers/gpu/drm/i915/selftests/intel_guc.c > b/drivers/gpu/drm/i915/selftests/intel_guc.c > index 3f9016466dea..fb74e2cf8a0a 100644 > --- a/drivers/gpu/drm/i915/selftests/intel_guc.c > +++ b/drivers/gpu/drm/i915/selftests/intel_guc.c > @@ -87,7 +87,7 @@ static int validate_client(struct intel_guc_client *client, > > static bool client_doorbell_in_sync(struct intel_guc_client *client) > { > - return doorbell_ok(client->guc, client->doorbell_id); > + return !client || doorbell_ok(client->guc, client->doorbell_id); > } > > /* > @@ -137,7 +137,6 @@ static int igt_guc_clients(void *args) > goto unlock; > } > GEM_BUG_ON(!guc->execbuf_client); > - GEM_BUG_ON(!guc->preempt_client); > > err = validate
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use the correct maximum in skl_compute_plane_wm (rev3)
== Series Details == Series: drm/i915: Use the correct maximum in skl_compute_plane_wm (rev3) URL : https://patchwork.freedesktop.org/series/37342/ State : success == Summary == Test kms_flip: Subgroup modeset-vs-vblank-race-interruptible: pass -> FAIL (shard-snb) fdo#103060 Test gem_eio: Subgroup in-flight: dmesg-warn -> PASS (shard-snb) fdo#104058 Test perf: Subgroup enable-disable: pass -> FAIL (shard-apl) fdo#103715 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> SKIP (shard-snb) fdo#103375 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058 fdo#103715 https://bugs.freedesktop.org/show_bug.cgi?id=103715 fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375 shard-apltotal:1401 pass:878 dwarn:1 dfail:0 fail:12 skip:510 time:6184s shard-hswtotal:2838 pass:1736 dwarn:1 dfail:0 fail:10 skip:1090 time:12019s shard-snbtotal:2838 pass:1328 dwarn:1 dfail:0 fail:11 skip:1498 time:6653s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7835/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2] drm/i915/guc: Allow preempt-client to be NULL (rev2)
== Series Details == Series: series starting with [v2] drm/i915/guc: Allow preempt-client to be NULL (rev2) URL : https://patchwork.freedesktop.org/series/37395/ State : success == Summary == Series 37395v2 series starting with [v2] drm/i915/guc: Allow preempt-client to be NULL https://patchwork.freedesktop.org/api/1.0/series/37395/revisions/2/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:415s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:425s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:370s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:485s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:281s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:482s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:485s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:465s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:452s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:565s fi-elk-e7500 total:224 pass:168 dwarn:9 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:280s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:511s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:389s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:398s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:413s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:462s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:412s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:457s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:493s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:448s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:502s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:572s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:429s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:506s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:526s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:486s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:489s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:414s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:429s fi-snb-2520m total:245 pass:211 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:398s Blacklisted hosts: fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:469s badc0398a06018a07f6f50a1ff5a5fd8a30b9944 drm-tip: 2018y-01m-31d-12h-17m-12s UTC integration manifest b566d4c192e0 drm/i915: Only allocate preempt context when required 9d317ed56342 drm/i915: Move the scheduler feature bits into the purview of the engines c74489d84b5e drm/i915/guc: Allow preempt-client to be NULL == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7838/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] tools/intel_reg: Add reading and writing registers through engine
On Mon, 22 Jan 2018, Mika Kuoppala wrote: > Jani Nikula writes: > >> On Mon, 08 Jan 2018, Mika Kuoppala wrote: >>> Add option to specify engine for register read/write operation. >>> If engine is specified, use MI_LOAD_REGISTER_IMM and MI_STORE_REGISTER_IMM >>> to write and read register using a batch targeted at that engine. >> >> Copy-pasting from the man page, we already have the notation: >> >> "Registers are defined as >> [(PORTNAME|PORTNUM|MMIO-OFFSET):](REGNAME|REGADDR)." >> >> Why don't we add this as ENGINE:REGNAME or something instead of an extra >> --engine parameter? As a "port". Sure, it's more work, but I really like >> the current possibility of reading all types of registers at once. Now >> you prevent dumps that would contain both mmio and batch based reads. >> > > Are you ok with the latest version? As discussed in irc, there are > problems with trying to add engines as ports, due to dynamic nature > and also that the existing infra relies on PORTNAME being mmio > for symbolic register dumping to work correctly. > > for the wart of if (reg->engine) in read/write paths > we gain the benefits of mmio dumps with engines. Can't say I would've reviewed all the engine bits and pieces, but Acked-by: Jani Nikula > > -Mika > >> BR, >> Jani. >> >> >>> >>> v2: no MI_NOOP after BBE (Chris) >>> v3: use modern engine names (Chris), use global fd >>> >>> Cc: Jani Nikula >>> Cc: Chris Wilson >>> CC: Joonas Lahtinen >>> Signed-off-by: Mika Kuoppala >>> --- >>> tools/intel_reg.c | 156 >>> +- >>> 1 file changed, 154 insertions(+), 2 deletions(-) >>> >>> diff --git a/tools/intel_reg.c b/tools/intel_reg.c >>> index 00d2a4a1..7f3494ef 100644 >>> --- a/tools/intel_reg.c >>> +++ b/tools/intel_reg.c >>> @@ -33,6 +33,7 @@ >>> #include >>> >>> #include "igt.h" >>> +#include "igt_gt.h" >>> #include "intel_io.h" >>> #include "intel_chipset.h" >>> >>> @@ -73,6 +74,11 @@ struct config { >>> >>> /* register spec */ >>> char *specfile; >>> + >>> + /* engine to use for lri (write) and srm (read) */ >>> + char *engine; >>> + int fd; >>> + >>> struct reg *regs; >>> ssize_t regcount; >>> >>> @@ -236,13 +242,140 @@ static void dump_decode(struct config *config, >>> struct reg *reg, uint32_t val) >>> } >>> } >>> >>> +static const struct intel_execution_engine2 *find_engine(const char *name, >>> +bool *secure) >>> +{ >>> + const struct intel_execution_engine2 *e; >>> + >>> + if (strlen(name) < 2) >>> + goto out; >>> + >>> + if (name[0] == '-') { >>> + *secure = false; >>> + name++; >>> + } else { >>> + *secure = true; >>> + } >>> + >>> + for (e = intel_execution_engines2; e->name; e++) { >>> + if (!strcmp(e->name, name)) >>> + return e; >>> + } >>> + >>> +out: >>> + fprintf(stderr, "no such engine as '%s'\n", name); >>> + >>> + fprintf(stderr, "valid engines:"); >>> + for (e = intel_execution_engines2; e->name; e++) >>> + fprintf(stderr, " %s", e->name); >>> + >>> + fprintf(stderr, "\n"); >>> + >>> + exit(EXIT_FAILURE); >>> +} >>> + >>> +static int register_srm(struct config *config, struct reg *reg, >>> + uint32_t *val_in) >>> +{ >>> + const int gen = intel_gen(config->devid); >>> + const bool r64b = gen >= 8; >>> + const uint32_t ctx = 0; >>> + struct drm_i915_gem_exec_object2 obj[2]; >>> + struct drm_i915_gem_relocation_entry reloc[1]; >>> + struct drm_i915_gem_execbuffer2 execbuf; >>> + uint32_t *batch, *r; >>> + const struct intel_execution_engine2 *engine; >>> + bool secure; >>> + int fd, i; >>> + uint32_t val; >>> + >>> + if (config->fd == -1) { >>> + config->fd = __drm_open_driver(DRIVER_INTEL); >>> + if (config->fd == -1) { >>> + fprintf(stderr, "Error opening driver: %s", >>> + strerror(errno)); >>> + exit(EXIT_FAILURE); >>> + } >>> + } >>> + >>> + fd = config->fd; >>> + engine = find_engine(config->engine, &secure); >>> + >>> + memset(obj, 0, sizeof(obj)); >>> + obj[0].handle = gem_create(fd, 4096); >>> + obj[1].handle = gem_create(fd, 4096); >>> + obj[1].relocs_ptr = to_user_pointer(reloc); >>> + obj[1].relocation_count = 1; >>> + >>> + batch = gem_mmap__cpu(fd, obj[1].handle, 0, 4096, PROT_WRITE); >>> + gem_set_domain(fd, obj[1].handle, >>> + I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU); >>> + >>> + i = 0; >>> + if (val_in) { >>> + batch[i++] = MI_NOOP; >>> + batch[i++] = MI_NOOP; >>> + >>> + batch[i++] = MI_LOAD_REGISTER_IMM; >>> + batch[i++] = reg->addr; >>> + batch[i++] = *val_in; >>> + batch[i++] = MI_NOOP; >>> + } >>> + >>> + batch[i++] = 0x24 << 23 | (1 + r64b); /* SRM */ >>> + batch[i++] = reg->addr; >>> + reloc[
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Allow preempt-client to be NULL
Chris Wilson writes: > Quoting Mika Kuoppala (2018-01-31 11:31:09) >> Chris Wilson writes: >> >> > In the next patch, we may only conditionally allocate the preempt-client >> > if there is a global preempt context and so we need to be prepared in >> > case the preempt-client itself is NULL. >> > >> > Signed-off-by: Chris Wilson >> > Cc: Michal Winiarski >> > Cc: Arkadiusz Hiler >> > Cc: Daniele Ceraolo Spurio >> > Cc: Michel Thierry >> > Cc: Michal Wajdeczko >> > --- >> > drivers/gpu/drm/i915/intel_guc_submission.c | 27 >> > +-- >> > 1 file changed, 17 insertions(+), 10 deletions(-) >> > >> >> You need to prepare the debugfs to handle the null also. >> >> Does our simple igt/debugfs test include reading through all the nodes >> it finds? > > It does, but we don't actually end up with NULLs. Not with this patch alone but the commit message promises that we prepare for it :) -Mika ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/16] drm/i915/skl+: refactor WM calculation for NV12
Op 22-01-18 om 13:03 schreef Vidya Srinivas: > From: Mahesh Kumar > > Current code calculates DDB for planar formats in such a way that we > store DDB of plane-0 in plane 1 & vice-versa. > In order to make this clean this patch refactors WM/DDB calculation for > NV12 planar formats. > > v2: Addressed review comments by Maarten > > Reviewed-by: Maarten Lankhorst > Signed-off-by: Mahesh Kumar > Signed-off-by: Vidya Srinivas > --- > drivers/gpu/drm/i915/i915_drv.h | 4 +- > drivers/gpu/drm/i915/intel_drv.h | 1 + > drivers/gpu/drm/i915/intel_pm.c | 121 > --- > 3 files changed, 64 insertions(+), 62 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h > index d440a11..df91904 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -1433,8 +1433,8 @@ static inline bool skl_ddb_entry_equal(const struct > skl_ddb_entry *e1, > } > > struct skl_ddb_allocation { > - struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES]; /* > packed/uv */ > - struct skl_ddb_entry y_plane[I915_MAX_PIPES][I915_MAX_PLANES]; > + struct skl_ddb_entry plane[I915_MAX_PIPES][I915_MAX_PLANES]; /* > packed/y */ > + struct skl_ddb_entry uv_plane[I915_MAX_PIPES][I915_MAX_PLANES]; > }; > > struct skl_ddb_values { > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index 5391c77..fc48697 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -592,6 +592,7 @@ struct intel_pipe_wm { > struct skl_plane_wm { > struct skl_wm_level wm[8]; > struct skl_wm_level trans_wm; > + bool is_nv12; > }; > > struct skl_pipe_wm { > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index b4cb21d..bed5de0 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -4004,9 +4004,9 @@ int skl_check_pipe_max_pixel_rate(struct intel_crtc > *intel_crtc, > static unsigned int > skl_plane_relative_data_rate(const struct intel_crtc_state *cstate, >const struct drm_plane_state *pstate, > - int y) > + const int plane) > { > - struct intel_plane *plane = to_intel_plane(pstate->plane); > + struct intel_plane *intel_plane = to_intel_plane(pstate->plane); > struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate); > uint32_t data_rate; > uint32_t width = 0, height = 0; > @@ -4020,9 +4020,9 @@ skl_plane_relative_data_rate(const struct > intel_crtc_state *cstate, > fb = pstate->fb; > format = fb->format->format; > > - if (plane->id == PLANE_CURSOR) > + if (intel_plane->id == PLANE_CURSOR) > return 0; > - if (y && format != DRM_FORMAT_NV12) > + if (plane == 1 && format != DRM_FORMAT_NV12) > return 0; > > /* > @@ -4033,19 +4033,14 @@ skl_plane_relative_data_rate(const struct > intel_crtc_state *cstate, > width = drm_rect_width(&intel_pstate->base.src) >> 16; > height = drm_rect_height(&intel_pstate->base.src) >> 16; > > - /* for planar format */ > - if (format == DRM_FORMAT_NV12) { > - if (y) /* y-plane data rate */ > - data_rate = width * height * > - fb->format->cpp[0]; > - else/* uv-plane data rate */ > - data_rate = (width / 2) * (height / 2) * > - fb->format->cpp[1]; > - } else { > - /* for packed formats */ > - data_rate = width * height * fb->format->cpp[0]; > + /* UV plane does 1/2 pixel sub-sampling */ > + if (plane == 1 && format == DRM_FORMAT_NV12) { > + width /= 2; > + height /= 2; > } > > + data_rate = width * height * fb->format->cpp[plane]; > + > down_scale_amount = skl_plane_downscale_amount(cstate, intel_pstate); > > return mul_round_up_u32_fixed16(data_rate, down_scale_amount); > @@ -4058,8 +4053,8 @@ skl_plane_relative_data_rate(const struct > intel_crtc_state *cstate, > */ > static unsigned int > skl_get_total_relative_data_rate(struct intel_crtc_state *intel_cstate, > - unsigned *plane_data_rate, > - unsigned *plane_y_data_rate) > + unsigned int *plane_data_rate, > + unsigned int *uv_plane_data_rate) > { > struct drm_crtc_state *cstate = &intel_cstate->base; > struct drm_atomic_state *state = cstate->state; > @@ -4075,17 +4070,17 @@ skl_get_total_relative_data_rate(struct > intel_crtc_state *intel_cstate, > enum plane_id plane_id = to_intel_plane(plane)->id; > unsigned int rate; > > - /* packed/uv */ > + /* packed/y */ > rate = skl_plane_r
[Intel-gfx] [PATCH v2] drm/i915/guc: Allow preempt-client to be NULL
In the next patch, we may only conditionally allocate the preempt-client if there is a global preempt context and so we need to be prepared in case the preempt-client itself is NULL. v2: Grep for more preempt_client. Signed-off-by: Chris Wilson Cc: Michal Winiarski Cc: Arkadiusz Hiler Cc: Daniele Ceraolo Spurio Cc: Michel Thierry Cc: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_debugfs.c | 8 +--- drivers/gpu/drm/i915/intel_guc_submission.c | 27 +-- drivers/gpu/drm/i915/selftests/intel_guc.c | 20 +++- 3 files changed, 33 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 3849ded354e3..9e44adef30f0 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2338,7 +2338,6 @@ static int i915_guc_info(struct seq_file *m, void *data) return -ENODEV; GEM_BUG_ON(!guc->execbuf_client); - GEM_BUG_ON(!guc->preempt_client); seq_printf(m, "Doorbell map:\n"); seq_printf(m, "\t%*pb\n", GUC_NUM_DOORBELLS, guc->doorbell_bitmap); @@ -2346,8 +2345,11 @@ static int i915_guc_info(struct seq_file *m, void *data) seq_printf(m, "\nGuC execbuf client @ %p:\n", guc->execbuf_client); i915_guc_client_info(m, dev_priv, guc->execbuf_client); - seq_printf(m, "\nGuC preempt client @ %p:\n", guc->preempt_client); - i915_guc_client_info(m, dev_priv, guc->preempt_client); + if (guc->preempt_client) { + seq_printf(m, "\nGuC preempt client @ %p:\n", + guc->preempt_client); + i915_guc_client_info(m, dev_priv, guc->preempt_client); + } i915_guc_log_info(m, dev_priv); diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c b/drivers/gpu/drm/i915/intel_guc_submission.c index 1f3a8786bbdc..4ea65df05e02 100644 --- a/drivers/gpu/drm/i915/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/intel_guc_submission.c @@ -832,10 +832,12 @@ static int guc_clients_doorbell_init(struct intel_guc *guc) if (ret) return ret; - ret = create_doorbell(guc->preempt_client); - if (ret) { - destroy_doorbell(guc->execbuf_client); - return ret; + if (guc->preempt_client) { + ret = create_doorbell(guc->preempt_client); + if (ret) { + destroy_doorbell(guc->execbuf_client); + return ret; + } } return 0; @@ -848,8 +850,11 @@ static void guc_clients_doorbell_fini(struct intel_guc *guc) * Instead of trying (in vain) to communicate with it, let's just * cleanup the doorbell HW and our internal state. */ - __destroy_doorbell(guc->preempt_client); - __update_doorbell_desc(guc->preempt_client, GUC_DOORBELL_INVALID); + if (guc->preempt_client) { + __destroy_doorbell(guc->preempt_client); + __update_doorbell_desc(guc->preempt_client, + GUC_DOORBELL_INVALID); + } __destroy_doorbell(guc->execbuf_client); __update_doorbell_desc(guc->execbuf_client, GUC_DOORBELL_INVALID); } @@ -998,10 +1003,11 @@ static void guc_clients_destroy(struct intel_guc *guc) { struct intel_guc_client *client; - client = fetch_and_zero(&guc->execbuf_client); - guc_client_free(client); - client = fetch_and_zero(&guc->preempt_client); + if (client) + guc_client_free(client); + + client = fetch_and_zero(&guc->execbuf_client); guc_client_free(client); } @@ -1160,7 +1166,8 @@ int intel_guc_submission_enable(struct intel_guc *guc) GEM_BUG_ON(!guc->execbuf_client); guc_reset_wq(guc->execbuf_client); - guc_reset_wq(guc->preempt_client); + if (guc->preempt_client) + guc_reset_wq(guc->preempt_client); err = intel_guc_sample_forcewake(guc); if (err) diff --git a/drivers/gpu/drm/i915/selftests/intel_guc.c b/drivers/gpu/drm/i915/selftests/intel_guc.c index 3f9016466dea..fb74e2cf8a0a 100644 --- a/drivers/gpu/drm/i915/selftests/intel_guc.c +++ b/drivers/gpu/drm/i915/selftests/intel_guc.c @@ -87,7 +87,7 @@ static int validate_client(struct intel_guc_client *client, static bool client_doorbell_in_sync(struct intel_guc_client *client) { - return doorbell_ok(client->guc, client->doorbell_id); + return !client || doorbell_ok(client->guc, client->doorbell_id); } /* @@ -137,7 +137,6 @@ static int igt_guc_clients(void *args) goto unlock; } GEM_BUG_ON(!guc->execbuf_client); - GEM_BUG_ON(!guc->preempt_client); err = validate_client(guc->execbuf_client, GUC_CLIENT_PRIORITY_KMD_NORMAL, false); @@ -146,16 +145,18 @@ static int igt_guc_clients(void *args) goto out;
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/ast: Load lut in crtc_commit
== Series Details == Series: drm/ast: Load lut in crtc_commit URL : https://patchwork.freedesktop.org/series/37398/ State : success == Summary == Series 37398v1 drm/ast: Load lut in crtc_commit https://patchwork.freedesktop.org/api/1.0/series/37398/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-fail -> DMESG-WARN (fi-elk-e7500) fdo#103989 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 pass -> INCOMPLETE (fi-bdw-5557u) fdo#104162 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#104162 https://bugs.freedesktop.org/show_bug.cgi?id=104162 fi-bdw-5557u total:245 pass:227 dwarn:0 dfail:0 fail:0 skip:17 fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:422s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:369s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:480s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:281s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:484s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:486s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:463s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:455s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:574s fi-elk-e7500 total:224 pass:168 dwarn:10 dfail:0 fail:0 skip:45 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:281s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:508s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:387s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:395s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:408s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:458s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:410s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:460s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:496s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:452s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:503s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:580s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:426s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:508s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:523s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:487s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:495s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:415s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:427s fi-snb-2520m total:245 pass:211 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:395s Blacklisted hosts: fi-cnl-y2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:506s fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:466s a2fbc800025405dbe0dc0820eab5d0ec3d636e55 drm-tip: 2018y-01m-31d-10h-50m-08s UTC integration manifest 25e14725ff3b drm/ast: Load lut in crtc_commit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7837/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/guc: Fix return from guc_log_relay_file_create
== Series Details == Series: series starting with [1/3] drm/i915/guc: Fix return from guc_log_relay_file_create URL : https://patchwork.freedesktop.org/series/37382/ State : failure == Summary == Test kms_cursor_legacy: Subgroup 2x-long-flip-vs-cursor-legacy: fail -> PASS (shard-hsw) fdo#104873 Test kms_flip: Subgroup 2x-flip-vs-modeset-interruptible: pass -> INCOMPLETE (shard-hsw) fdo#102614 Subgroup wf_vblank-ts-check-interruptible: fail -> PASS (shard-snb) fdo#100368 Subgroup 2x-flip-vs-modeset-vs-hang: pass -> DMESG-WARN (shard-hsw) Test perf: Subgroup oa-exponents: pass -> FAIL (shard-apl) fdo#102254 Subgroup gen8-unprivileged-single-ctx-counters: pass -> FAIL (shard-apl) Test drv_selftest: Subgroup live_guc: pass -> DMESG-WARN (shard-apl) Test perf_pmu: Subgroup all-busy-check-all: pass -> FAIL (shard-apl) Test pm_rc6_residency: Subgroup rc6-accuracy: skip -> PASS (shard-snb) Test gem_exec_schedule: Subgroup smoketest-bsd: pass -> INCOMPLETE (shard-apl) fdo#102848 Subgroup smoketest-vebox: pass -> INCOMPLETE (shard-apl) Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw) fdo#99912 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254 fdo#102848 https://bugs.freedesktop.org/show_bug.cgi?id=102848 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 shard-apltotal:1040 pass:648 dwarn:2 dfail:0 fail:11 skip:377 time:5125s shard-hswtotal:2818 pass:1724 dwarn:2 dfail:0 fail:9 skip:1081 time:11559s shard-snbtotal:2838 pass:1331 dwarn:1 dfail:0 fail:10 skip:1496 time:6682s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7834/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Allow preempt-client to be NULL
Quoting Mika Kuoppala (2018-01-31 11:31:09) > Chris Wilson writes: > > > In the next patch, we may only conditionally allocate the preempt-client > > if there is a global preempt context and so we need to be prepared in > > case the preempt-client itself is NULL. > > > > Signed-off-by: Chris Wilson > > Cc: Michal Winiarski > > Cc: Arkadiusz Hiler > > Cc: Daniele Ceraolo Spurio > > Cc: Michel Thierry > > Cc: Michal Wajdeczko > > --- > > drivers/gpu/drm/i915/intel_guc_submission.c | 27 > > +-- > > 1 file changed, 17 insertions(+), 10 deletions(-) > > > > You need to prepare the debugfs to handle the null also. > > Does our simple igt/debugfs test include reading through all the nodes > it finds? It does, but we don't actually end up with NULLs. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Allow preempt-client to be NULL
Chris Wilson writes: > In the next patch, we may only conditionally allocate the preempt-client > if there is a global preempt context and so we need to be prepared in > case the preempt-client itself is NULL. > > Signed-off-by: Chris Wilson > Cc: Michal Winiarski > Cc: Arkadiusz Hiler > Cc: Daniele Ceraolo Spurio > Cc: Michel Thierry > Cc: Michal Wajdeczko > --- > drivers/gpu/drm/i915/intel_guc_submission.c | 27 +-- > 1 file changed, 17 insertions(+), 10 deletions(-) > You need to prepare the debugfs to handle the null also. Does our simple igt/debugfs test include reading through all the nodes it finds? -Mika > diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c > b/drivers/gpu/drm/i915/intel_guc_submission.c > index 1f3a8786bbdc..4ea65df05e02 100644 > --- a/drivers/gpu/drm/i915/intel_guc_submission.c > +++ b/drivers/gpu/drm/i915/intel_guc_submission.c > @@ -832,10 +832,12 @@ static int guc_clients_doorbell_init(struct intel_guc > *guc) > if (ret) > return ret; > > - ret = create_doorbell(guc->preempt_client); > - if (ret) { > - destroy_doorbell(guc->execbuf_client); > - return ret; > + if (guc->preempt_client) { > + ret = create_doorbell(guc->preempt_client); > + if (ret) { > + destroy_doorbell(guc->execbuf_client); > + return ret; > + } > } > > return 0; > @@ -848,8 +850,11 @@ static void guc_clients_doorbell_fini(struct intel_guc > *guc) >* Instead of trying (in vain) to communicate with it, let's just >* cleanup the doorbell HW and our internal state. >*/ > - __destroy_doorbell(guc->preempt_client); > - __update_doorbell_desc(guc->preempt_client, GUC_DOORBELL_INVALID); > + if (guc->preempt_client) { > + __destroy_doorbell(guc->preempt_client); > + __update_doorbell_desc(guc->preempt_client, > +GUC_DOORBELL_INVALID); > + } > __destroy_doorbell(guc->execbuf_client); > __update_doorbell_desc(guc->execbuf_client, GUC_DOORBELL_INVALID); > } > @@ -998,10 +1003,11 @@ static void guc_clients_destroy(struct intel_guc *guc) > { > struct intel_guc_client *client; > > - client = fetch_and_zero(&guc->execbuf_client); > - guc_client_free(client); > - > client = fetch_and_zero(&guc->preempt_client); > + if (client) > + guc_client_free(client); > + > + client = fetch_and_zero(&guc->execbuf_client); > guc_client_free(client); > } > > @@ -1160,7 +1166,8 @@ int intel_guc_submission_enable(struct intel_guc *guc) > GEM_BUG_ON(!guc->execbuf_client); > > guc_reset_wq(guc->execbuf_client); > - guc_reset_wq(guc->preempt_client); > + if (guc->preempt_client) > + guc_reset_wq(guc->preempt_client); > > err = intel_guc_sample_forcewake(guc); > if (err) > -- > 2.15.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt v2 1/1] tools/intel_guc_logger: Send GuC log level in new i915 expected format
i915 expects GuC log level to be specified as: 0: disabled 1: enabled (verbosity level 0 = min) 2: enabled (verbosity level 1) 3: enabled (verbosity level 2) 4: enabled (verbosity level 3 = max) Remove the earlier internal layout based logging control from guc_log_control and send new expected values. v2: log_level assert in guc_log_control, cleaner level setup (Michal) added missing copyright header. (Sagar) Signed-off-by: Sagar Arun Kamble Cc: Michal Wajdeczko Cc: Daniele Ceraolo Spurio Cc: Chris Wilson Cc: Michal Winiarski Reviewed-by: Michal Wajdeczko --- tools/intel_guc_logger.c | 41 + 1 file changed, 37 insertions(+), 4 deletions(-) diff --git a/tools/intel_guc_logger.c b/tools/intel_guc_logger.c index 031fd84..5f1de8d 100644 --- a/tools/intel_guc_logger.c +++ b/tools/intel_guc_logger.c @@ -1,3 +1,26 @@ +/* + * Copyright © 2014-2018 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + */ #include #include @@ -51,17 +74,27 @@ uint32_t test_duration, max_filesize; pthread_cond_t underflow_cond, overflow_cond; bool stop_logging, discard_oldlogs, capturing_stopped; -static void guc_log_control(bool enable_logging) +static void guc_log_control(bool enable, uint32_t log_level) { int control_fd; char data[19]; uint64_t val; int ret; + igt_assert_lte(log_level, 3); + control_fd = igt_debugfs_open(-1, CONTROL_FILE_NAME, O_WRONLY); igt_assert_f(control_fd >= 0, "couldn't open the guc log control file\n"); - val = enable_logging ? ((verbosity_level << 4) | 0x1) : 0; + /* +* i915 expects GuC log level to be specified as: +* 0: disabled +* 1: enabled (verbosity level 0 = min) +* 2: enabled (verbosity level 1) +* 3: enabled (verbosity level 2) +* 4: enabled (verbosity level 3 = max) +*/ + val = enable ? log_level + 1 : 0; ret = snprintf(data, sizeof(data), "0x%" PRIx64, val); igt_assert(ret > 2 && ret < sizeof(data)); @@ -288,7 +321,7 @@ static void init_main_thread(void) /* Enable the logging, it may not have been enabled from boot and so * the relay file also wouldn't have been created. */ - guc_log_control(true); + guc_log_control(true, verbosity_level); open_relay_file(); open_output_file(); @@ -420,7 +453,7 @@ int main(int argc, char **argv) } while (!stop_logging); /* Pause logging on the GuC side */ - guc_log_control(false); + guc_log_control(false, 0); /* Signal flusher thread to make an exit */ capturing_stopped = 1; -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Handle interrupt based logging with lack of SSE4.1, relay and other setup
On 1/31/2018 4:07 PM, Michał Winiarski wrote: On Wed, Jan 31, 2018 at 11:44:38AM +0530, Sagar Arun Kamble wrote: On some systems like skl-gvtdvm, SSE4.1 movntdqa might not be available. movntdqa is needed for efficient capture of the logs from uncached GuC log buffer. GuC init was tied with this support and other setup needed for interrupt based GuC log capture like relay channel/file support and uncached mapping support. With this patch, GuC init is now unblocked from lack of this support. SSE and relay support init/fini is now being done by new functions intel_guc_log_init|fini_runtime() which makes relay functions static. We have introduced two states "supported" and "enabled". Supported is set when we have SSE4.1 support and have relay, GuC log, WC mapping available. Enabled is set when support is present and user has requested logging through i915_modparams.guc_log_level. While at this change, fixed unwind order in intel_uc_fini_misc. Or, we could rework GuC log a bit. We could change the meaning of guc_log_level - it would only affect the "internal" GuC state (verbosity - in other words, the content of buffer used by GuC). This allows userspace to inspect the content of GuC buffer (i915_guc_log_dump), but i915 is not copying the data to the relay (we're ignoring the interrupts recieved from GuC). This means that we need to introduce alternative way of controling the relay, let's say another file called "i915_guc_log_relay". Opening this file causes the relay to be created, we can throw an error if we don't have SSE4.1 there. (well - the whole runtime is created actually, things are quite badly named today, runtime means mapping of buffer shared with GuC, relay is the buffer "shared" with userspace, functions operating on "runtime" should probably setup both of those rather than just the mapping). True. Setup spread over different stages of load made it little complicated to change and your change will help. We're also solving the problem of overflows if GuC is loaded with "guc_log_level > 0" while nobody is consuming the data from the relay. And we don't really need to handle the "runtime" at module load time at all, which simplifies things. Yes. Agree on this approach. Thanks. I'm working on a series that does all of the above. -Michał Signed-off-by: Sagar Arun Kamble Cc: Chris Wilson Cc: Michal Wajdeczko Cc: Michal Winiarski Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_guc.c | 2 +- drivers/gpu/drm/i915/intel_guc_log.c | 97 ++-- drivers/gpu/drm/i915/intel_guc_log.h | 16 +- drivers/gpu/drm/i915/intel_uc.c | 14 ++ 4 files changed, 90 insertions(+), 39 deletions(-) -- Thanks, Sagar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v2,1/3] drm/i915/guc: Allow preempt-client to be NULL
== Series Details == Series: series starting with [v2,1/3] drm/i915/guc: Allow preempt-client to be NULL URL : https://patchwork.freedesktop.org/series/37395/ State : warning == Summary == Series 37395v1 series starting with [v2,1/3] drm/i915/guc: Allow preempt-client to be NULL https://patchwork.freedesktop.org/api/1.0/series/37395/revisions/1/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 +6 Test gem_ringfill: Subgroup basic-default-hang: pass -> DMESG-WARN (fi-elk-e7500) fdo#104058 Test gem_sync: Subgroup basic-all: pass -> SKIP (fi-elk-e7500) Subgroup basic-each: pass -> SKIP (fi-elk-e7500) Subgroup basic-many-each: pass -> SKIP (fi-elk-e7500) Subgroup basic-store-all: pass -> SKIP (fi-elk-e7500) Subgroup basic-store-each: pass -> SKIP (fi-elk-e7500) Test gem_tiled_blits: Subgroup basic: pass -> SKIP (fi-elk-e7500) Test gem_tiled_fence_blits: Subgroup basic: pass -> SKIP (fi-elk-e7500) Test gem_wait: Subgroup basic-busy-all: pass -> SKIP (fi-elk-e7500) Subgroup basic-wait-all: pass -> SKIP (fi-elk-e7500) Subgroup basic-await-all: pass -> SKIP (fi-elk-e7500) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#104058 https://bugs.freedesktop.org/show_bug.cgi?id=104058 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:414s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:426s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:371s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:486s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:282s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:480s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:486s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:466s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:452s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:575s fi-elk-e7500 total:229 pass:161 dwarn:7 dfail:1 fail:0 skip:59 fi-gdg-551 total:288 pass:179 dwarn:0 dfail:0 fail:1 skip:108 time:278s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:505s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:388s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:396s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:408s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:444s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:411s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:460s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:494s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:450s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:496s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:574s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:424s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:515s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:527s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:489s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:483s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:416s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:428s fi-snb-2520m total:245 pass:211 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:392s Blacklisted hosts: fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:468s 5d84aeda7cd418fe9d81419a42d1e7a46264e209 drm-tip: 2018y-01m-31d-10h-16m-14s UTC integration manifest d7ab3f9a2164 drm/i915: Only allocate preempt context when required b7a9c5fa91e5 drm/i915: Move the scheduler feature bits into the purview of the
Re: [Intel-gfx] [PATCH] drm/i915: Flush ggtt writes through the old fenced vma before changing fences
On Tue, 2018-01-30 at 16:44 +, Chris Wilson wrote: > This is a precautionary measure as I have no evidence to suggest we've > hit a bug here (I was hoping this might explain gdg's odd behaviour, but > alas), but given that we have a function to flush the ggtt writes it > seems prudent to use it prior to changing the fence register. Due to the > intrinsic nature of the GTT often operating as an independent mmio path, > we should not just rely on the write to the fence acting as a full flush > for GTT writes. > > Signed-off-by: Chris Wilson > Cc: Joonas Lahtinen Reviewed-by: Joonas Lahtinen Regards, Joonas - Intel Finland Oy Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 - 4 Domiciled in Helsinki This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Handle interrupt based logging with lack of SSE4.1, relay and other setup
Quoting Michał Winiarski (2018-01-31 10:37:20) > On Wed, Jan 31, 2018 at 11:44:38AM +0530, Sagar Arun Kamble wrote: > > On some systems like skl-gvtdvm, SSE4.1 movntdqa might not be available. > > movntdqa is needed for efficient capture of the logs from uncached GuC > > log buffer. GuC init was tied with this support and other setup needed > > for interrupt based GuC log capture like relay channel/file support and > > uncached mapping support. With this patch, GuC init is now unblocked from > > lack of this support. > > SSE and relay support init/fini is now being done by new functions > > intel_guc_log_init|fini_runtime() which makes relay functions static. > > We have introduced two states "supported" and "enabled". Supported is set > > when we have SSE4.1 support and have relay, GuC log, WC mapping available. > > Enabled is set when support is present and user has requested logging > > through i915_modparams.guc_log_level. > > While at this change, fixed unwind order in intel_uc_fini_misc. > > Or, we could rework GuC log a bit. > We could change the meaning of guc_log_level - it would only affect the > "internal" GuC state (verbosity - in other words, the content of buffer used > by > GuC). This allows userspace to inspect the content of GuC buffer > (i915_guc_log_dump), but i915 is not copying the data to the relay (we're > ignoring the interrupts recieved from GuC). > > This means that we need to introduce alternative way of controling the relay, > let's say another file called "i915_guc_log_relay". Opening this file causes > the > relay to be created, we can throw an error if we don't have SSE4.1 there. > (well - the whole runtime is created actually, things are quite badly named > today, runtime means mapping of buffer shared with GuC, relay is the buffer > "shared" with userspace, functions operating on "runtime" should probably > setup > both of those rather than just the mapping). > > We're also solving the problem of overflows if GuC is loaded with > "guc_log_level > 0" while nobody is consuming the data from the relay. > And we don't really need to handle the "runtime" at module load time at all, > which simplifies things. > > I'm working on a series that does all of the above. I'll push the 1st patch (the -EEXISTS fix) and we can come back for the rest. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] drm/i915/dp: Remove redundant sleep after AUX transaction length check.
On Fri, Jan 26, 2018 at 06:49:20PM -0800, Dhinakaran Pandiyan wrote: > The core already takes care of the delay before retrying. The delay now > changes to (500, 600)us instead of (500 + 1000, 600 + 1500)us. Reviewed-by: David Weinehall > Cc: Rodrigo Vivi > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_dp.c | 8 > 1 file changed, 8 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 2454326690fb..97a4557053db 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1189,14 +1189,6 @@ intel_dp_aux_ch(struct intel_dp *intel_dp, > if (recv_bytes == 0 || recv_bytes > 20) { > DRM_DEBUG_KMS("Forbidden recv_bytes = %d on aux transaction\n", > recv_bytes); > - /* > - * FIXME: This patch was created on top of a series that > - * organize the retries at drm level. There EBUSY should > - * also take care for 1ms wait before retrying. > - * That aux retries re-org is still needed and after that is > - * merged we remove this sleep from here. > - */ > - usleep_range(1000, 1500); > ret = -EBUSY; > goto out; > } > -- > 2.14.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/9] drm/i915/dp: Move comment about hw timeout to the right place.
On Fri, Jan 26, 2018 at 06:49:21PM -0800, Dhinakaran Pandiyan wrote: > No functional change. > > Signed-off-by: Dhinakaran Pandiyan Reviewed-by: David Weinehall > --- > drivers/gpu/drm/i915/intel_dp.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 97a4557053db..06619998b5a3 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1136,14 +1136,14 @@ intel_dp_aux_ch(struct intel_dp *intel_dp, > DP_AUX_CH_CTL_TIME_OUT_ERROR | > DP_AUX_CH_CTL_RECEIVE_ERROR); > > - if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR) > - continue; > - > /* DP CTS 1.2 Core Rev 1.1, 4.2.1.1 & 4.2.1.2 >* 400us delay required for errors and timeouts >* Timeout errors from the HW already meet this >* requirement so skip to next iteration >*/ > + if (status & DP_AUX_CH_CTL_TIME_OUT_ERROR) > + continue; > + > if (status & DP_AUX_CH_CTL_RECEIVE_ERROR) { > usleep_range(400, 500); > continue; > -- > 2.14.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/9] drm/i915/psr: Extract PSR DPCD initialization and move it to intel_psr.c
On Fri, Jan 26, 2018 at 06:49:17PM -0800, Dhinakaran Pandiyan wrote: > intel_edp_init_dpcd() is cluttered with PSR specific DPCD checks and > intel_dp.c is huge. Yes please! Good idea. > No functional change intended. Reviewed-by: David Weinehall > Cc: Rodrigo Vivi > Signed-off-by: Dhinakaran Pandiyan > --- > drivers/gpu/drm/i915/intel_dp.c | 64 + > drivers/gpu/drm/i915/intel_drv.h | 1 + > drivers/gpu/drm/i915/intel_psr.c | 68 > > 3 files changed, 70 insertions(+), 63 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index a2e88715..2454326690fb 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -3135,35 +3135,6 @@ intel_dp_get_link_status(struct intel_dp *intel_dp, > uint8_t link_status[DP_LINK_ > DP_LINK_STATUS_SIZE) == DP_LINK_STATUS_SIZE; > } > > -static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp) > -{ > - uint8_t psr_caps = 0; > - > - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_PSR_CAPS, &psr_caps) != 1) > - return false; > - return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED; > -} > - > -static bool intel_dp_get_colorimetry_status(struct intel_dp *intel_dp) > -{ > - uint8_t dprx = 0; > - > - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST, > - &dprx) != 1) > - return false; > - return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED; > -} > - > -static bool intel_dp_get_alpm_status(struct intel_dp *intel_dp) > -{ > - uint8_t alpm_caps = 0; > - > - if (drm_dp_dpcd_readb(&intel_dp->aux, DP_RECEIVER_ALPM_CAP, > - &alpm_caps) != 1) > - return false; > - return alpm_caps & DP_ALPM_CAP; > -} > - > /* These are source-specific values. */ > uint8_t > intel_dp_voltage_max(struct intel_dp *intel_dp) > @@ -3714,40 +3685,7 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp) > dev_priv->no_aux_handshake = intel_dp->dpcd[DP_MAX_DOWNSPREAD] & > DP_NO_AUX_HANDSHAKE_LINK_TRAINING; > > - /* Check if the panel supports PSR */ > - drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT, > - intel_dp->psr_dpcd, > - sizeof(intel_dp->psr_dpcd)); > - if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) { > - dev_priv->psr.sink_support = true; > - DRM_DEBUG_KMS("Detected EDP PSR Panel.\n"); > - } > - > - if (INTEL_GEN(dev_priv) >= 9 && > - (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) { > - uint8_t frame_sync_cap; > - > - dev_priv->psr.sink_support = true; > - if (drm_dp_dpcd_readb(&intel_dp->aux, > - DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP, > - &frame_sync_cap) != 1) > - frame_sync_cap = 0; > - dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false; > - /* PSR2 needs frame sync as well */ > - dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync; > - DRM_DEBUG_KMS("PSR2 %s on sink", > - dev_priv->psr.psr2_support ? "supported" : "not > supported"); > - > - if (dev_priv->psr.psr2_support) { > - dev_priv->psr.y_cord_support = > - intel_dp_get_y_cord_status(intel_dp); > - dev_priv->psr.colorimetry_support = > - intel_dp_get_colorimetry_status(intel_dp); > - dev_priv->psr.alpm = > - intel_dp_get_alpm_status(intel_dp); > - } > - > - } > + intel_psr_init_dpcd(intel_dp); > > /* >* Read the eDP display control registers. > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index 3cee54bc0352..a340bc04dad8 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -1851,6 +1851,7 @@ bool is_hdcp_supported(struct drm_i915_private > *dev_priv, enum port port); > > /* intel_psr.c */ > #define CAN_PSR(dev_priv) (HAS_PSR(dev_priv) && dev_priv->psr.sink_support) > +void intel_psr_init_dpcd(struct intel_dp *intel_dp); > void intel_psr_enable(struct intel_dp *intel_dp, > const struct intel_crtc_state *crtc_state); > void intel_psr_disable(struct intel_dp *intel_dp, > diff --git a/drivers/gpu/drm/i915/intel_psr.c > b/drivers/gpu/drm/i915/intel_psr.c > index c12af1118647..a1b878449e83 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -56,6 +56,74 @@ > #include "intel_drv.h" > #include "i915_drv.h" > > +static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp) > +{ > + uint8_t psr_caps = 0; > + > + if (drm
Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Handle interrupt based logging with lack of SSE4.1, relay and other setup
On Wed, Jan 31, 2018 at 11:44:38AM +0530, Sagar Arun Kamble wrote: > On some systems like skl-gvtdvm, SSE4.1 movntdqa might not be available. > movntdqa is needed for efficient capture of the logs from uncached GuC > log buffer. GuC init was tied with this support and other setup needed > for interrupt based GuC log capture like relay channel/file support and > uncached mapping support. With this patch, GuC init is now unblocked from > lack of this support. > SSE and relay support init/fini is now being done by new functions > intel_guc_log_init|fini_runtime() which makes relay functions static. > We have introduced two states "supported" and "enabled". Supported is set > when we have SSE4.1 support and have relay, GuC log, WC mapping available. > Enabled is set when support is present and user has requested logging > through i915_modparams.guc_log_level. > While at this change, fixed unwind order in intel_uc_fini_misc. Or, we could rework GuC log a bit. We could change the meaning of guc_log_level - it would only affect the "internal" GuC state (verbosity - in other words, the content of buffer used by GuC). This allows userspace to inspect the content of GuC buffer (i915_guc_log_dump), but i915 is not copying the data to the relay (we're ignoring the interrupts recieved from GuC). This means that we need to introduce alternative way of controling the relay, let's say another file called "i915_guc_log_relay". Opening this file causes the relay to be created, we can throw an error if we don't have SSE4.1 there. (well - the whole runtime is created actually, things are quite badly named today, runtime means mapping of buffer shared with GuC, relay is the buffer "shared" with userspace, functions operating on "runtime" should probably setup both of those rather than just the mapping). We're also solving the problem of overflows if GuC is loaded with "guc_log_level > 0" while nobody is consuming the data from the relay. And we don't really need to handle the "runtime" at module load time at all, which simplifies things. I'm working on a series that does all of the above. -Michał > > Signed-off-by: Sagar Arun Kamble > Cc: Chris Wilson > Cc: Michal Wajdeczko > Cc: Michal Winiarski > Cc: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/intel_guc.c | 2 +- > drivers/gpu/drm/i915/intel_guc_log.c | 97 > ++-- > drivers/gpu/drm/i915/intel_guc_log.h | 16 +- > drivers/gpu/drm/i915/intel_uc.c | 14 ++ > 4 files changed, 90 insertions(+), 39 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/ast: Load lut in crtc_commit
In the past the ast driver relied upon the fbdev emulation helpers to call ->load_lut at boot-up. But since commit b8e2b0199cc377617dc238f5106352c06dcd3fa2 Author: Peter Rosin Date: Tue Jul 4 12:36:57 2017 +0200 drm/fb-helper: factor out pseudo-palette that's cleaned up and drivers are expected to boot into a consistent lut state. This patch fixes that. Fixes: b8e2b0199cc3 ("drm/fb-helper: factor out pseudo-palette") Cc: Peter Rosin Cc: Daniel Vetter Cc: # v4.14+ Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=198123 Cc: Bill Fraser Reported-and-Tested-by: Bill Fraser Tested-by: Konstantin Khlebnikov Tested-by: Paul Tobias Signed-off-by: Daniel Vetter --- drivers/gpu/drm/ast/ast_mode.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c index 9555a3542022..831b73392d82 100644 --- a/drivers/gpu/drm/ast/ast_mode.c +++ b/drivers/gpu/drm/ast/ast_mode.c @@ -644,6 +644,7 @@ static void ast_crtc_commit(struct drm_crtc *crtc) { struct ast_private *ast = crtc->dev->dev_private; ast_set_index_reg_mask(ast, AST_IO_SEQ_PORT, 0x1, 0xdf, 0); + ast_crtc_load_lut(crtc); } -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use the correct maximum in skl_compute_plane_wm (rev3)
== Series Details == Series: drm/i915: Use the correct maximum in skl_compute_plane_wm (rev3) URL : https://patchwork.freedesktop.org/series/37342/ State : success == Summary == Series 37342v3 drm/i915: Use the correct maximum in skl_compute_plane_wm https://patchwork.freedesktop.org/api/1.0/series/37342/revisions/3/mbox/ Test debugfs_test: Subgroup read_all_entries: dmesg-warn -> DMESG-FAIL (fi-elk-e7500) fdo#103989 incomplete -> PASS (fi-snb-2520m) fdo#103713 +1 fdo#103989 https://bugs.freedesktop.org/show_bug.cgi?id=103989 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:288 pass:267 dwarn:0 dfail:0 fail:0 skip:21 time:426s fi-bdw-gvtdvmtotal:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:427s fi-blb-e6850 total:288 pass:223 dwarn:1 dfail:0 fail:0 skip:64 time:372s fi-bsw-n3050 total:288 pass:242 dwarn:0 dfail:0 fail:0 skip:46 time:488s fi-bwr-2160 total:288 pass:183 dwarn:0 dfail:0 fail:0 skip:105 time:280s fi-bxt-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:483s fi-bxt-j4205 total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:486s fi-byt-j1900 total:288 pass:253 dwarn:0 dfail:0 fail:0 skip:35 time:465s fi-byt-n2820 total:288 pass:249 dwarn:0 dfail:0 fail:0 skip:39 time:453s fi-cfl-s2total:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:566s fi-elk-e7500 total:224 pass:168 dwarn:9 dfail:1 fail:0 skip:45 fi-gdg-551 total:288 pass:180 dwarn:0 dfail:0 fail:0 skip:108 time:279s fi-glk-1 total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:510s fi-hsw-4770 total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:391s fi-hsw-4770r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:398s fi-ilk-650 total:288 pass:228 dwarn:0 dfail:0 fail:0 skip:60 time:411s fi-ivb-3520m total:288 pass:259 dwarn:0 dfail:0 fail:0 skip:29 time:461s fi-ivb-3770 total:288 pass:255 dwarn:0 dfail:0 fail:0 skip:33 time:411s fi-kbl-7500u total:288 pass:263 dwarn:1 dfail:0 fail:0 skip:24 time:458s fi-kbl-7560u total:288 pass:269 dwarn:0 dfail:0 fail:0 skip:19 time:497s fi-kbl-7567u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:454s fi-kbl-r total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:499s fi-pnv-d510 total:288 pass:222 dwarn:1 dfail:0 fail:0 skip:65 time:580s fi-skl-6260u total:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:434s fi-skl-6600u total:288 pass:261 dwarn:0 dfail:0 fail:0 skip:27 time:508s fi-skl-6700hqtotal:288 pass:262 dwarn:0 dfail:0 fail:0 skip:26 time:527s fi-skl-6700k2total:288 pass:264 dwarn:0 dfail:0 fail:0 skip:24 time:484s fi-skl-6770hqtotal:288 pass:268 dwarn:0 dfail:0 fail:0 skip:20 time:486s fi-skl-guc total:288 pass:260 dwarn:0 dfail:0 fail:0 skip:28 time:416s fi-skl-gvtdvmtotal:288 pass:265 dwarn:0 dfail:0 fail:0 skip:23 time:429s fi-snb-2520m total:245 pass:211 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:288 pass:248 dwarn:0 dfail:0 fail:0 skip:40 time:397s Blacklisted hosts: fi-glk-dsi total:288 pass:258 dwarn:0 dfail:0 fail:0 skip:30 time:469s 7dc5917dc7dddff0c7f2a0361c8698030c6899fc drm-tip: 2018y-01m-31d-09h-37m-52s UTC integration manifest 2292a62dd685 drm/i915: Ignore minimum lines for level 0 in skl_compute_plane_wm == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7835/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Always run hangcheck while the GPU is busy
Quoting Mika Kuoppala (2018-01-31 09:41:35) > Chris Wilson writes: > > > Previously, we relied on only running the hangcheck while somebody was > > waiting on the GPU, in order to minimise the amount of time hangcheck > > had to run. (If nobody was watching the GPU, nobody would notice if the > > GPU wasn't responding -- eventually somebody would care and so kick > > hangcheck into action.) However, this falls apart from around commit > > 4680816be336 ("drm/i915: Wait first for submission, before waiting for > > request completion"), as not all waiters declare themselves to hangcheck > > and so we could switch off hangcheck and miss GPU hangs even when > > waiting under the struct_mutex. > > > > If we enable hangcheck from the first request submission, and let it run > > until the GPU is idle again, we forgo all the complexity involved with > > only enabling around waiters. Instead we have to be careful that we do > > not declare a GPU hang when idly waiting for the next request to be come > > ready. > > > > Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting > > for request completion" > > Signed-off-by: Chris Wilson > > Cc: Chris Wilson > > Cc: Mika Kuoppala > > Reviewed-by: Mika Kuoppala Rewrote the last paragraph to try and make it clear what I was hinting at, and so it doesn't sound like a description of what this patch is doing but the background mechanics that this patch relies upon. Thanks for the review and discussion, -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/breadcrumbs: Drop request reference for the signaler thread
Quoting Chris Wilson (2018-01-22 15:41:06) > If we remember to cancel the signaler on a request when retiring it > (after we know that the request has been signaled), we do not need to > carry an additional request in the signaler itself. This prevents an > issue whereby the signaler threads may be delayed and hold on to > thousands of request references, causing severe memory fragmentation and > premature oom (most noticeable on 32b snb due to the limited GFP_KERNEL > and frequent use of inter-engine fences). > > Signed-off-by: Chris Wilson > Cc: Tvrtko Ursulin Poke. I've been staring at this problem since December, it would be nice to get some resolution :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Handle interrupt based logging with lack of SSE4.1, relay and other setup
On 1/31/2018 3:08 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2018-01-31 06:14:38) On some systems like skl-gvtdvm, SSE4.1 movntdqa might not be available. movntdqa is needed for efficient capture of the logs from uncached GuC log buffer. GuC init was tied with this support and other setup needed for interrupt based GuC log capture like relay channel/file support and uncached mapping support. With this patch, GuC init is now unblocked from lack of this support. SSE and relay support init/fini is now being done by new functions intel_guc_log_init|fini_runtime() which makes relay functions static. We have introduced two states "supported" and "enabled". Supported is set when we have SSE4.1 support and have relay, GuC log, WC mapping available. Enabled is set when support is present and user has requested logging through i915_modparams.guc_log_level. While at this change, fixed unwind order in intel_uc_fini_misc. Downside would appear to be the loss of feedback in i915.guc_log_level when it fail? This patch decouples the guc_log_level from only interrupt based log support. We can continue to use/know guc_log_level to send the verbosity to GuC still. Have to rely only on static dumps like i915_guc_log_dump or error_uc->guc_log wherever runtime logging is off. Otherwise, looks tidy enough. -Chris -- Thanks, Sagar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Fix return from guc_log_relay_file_create
On 1/31/2018 3:06 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2018-01-31 06:14:37) guc_log_relay_file_create will return -EEXIST if we invoke relay_late_setup_files multiple times as part of i915_guc_log_control. However this is to be not cosidered as fail and need to return 0. This was mistakenly introduced in the below commit. Fix it. Fixes: 70deeaddc6e6 "drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutex" Signed-off-by: Sagar Arun Kamble Cc: Chris Wilson Cc: Michal Wajdeczko Testcase? Yes. will include. Thanks for the review. Reviewed-by: Chris Wilson -Chris -- Thanks, Sagar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915: Move the scheduler feature bits into the purview of the engines
Rather than having the high level ioctl interface guess the underlying implementation details, having the implementation declare what capabilities it exports. We define an intel_driver_caps, similar to the intel_device_info, which instead of trying to describe the HW gives details on what the driver itself supports. This is then populated by the engine backend for the new scheduler capability field for use elsewhere. Signed-off-by: Chris Wilson Cc: Tomasz Lis Cc: Joonas Lahtinen Cc: Tvrtko Ursulin Cc: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_drv.c | 8 +--- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_gem.c | 3 +++ drivers/gpu/drm/i915/i915_gpu_error.c| 7 +-- drivers/gpu/drm/i915/intel_device_info.c | 6 ++ drivers/gpu/drm/i915/intel_device_info.h | 7 +++ drivers/gpu/drm/i915/intel_lrc.c | 6 ++ 7 files changed, 30 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 1ec12add34b2..733f71637914 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -372,13 +372,7 @@ static int i915_getparam(struct drm_device *dev, void *data, value = i915_gem_mmap_gtt_version(); break; case I915_PARAM_HAS_SCHEDULER: - value = 0; - if (dev_priv->engine[RCS] && dev_priv->engine[RCS]->schedule) { - value |= I915_SCHEDULER_CAP_ENABLED; - value |= I915_SCHEDULER_CAP_PRIORITY; - if (HAS_LOGICAL_RING_PREEMPTION(dev_priv)) - value |= I915_SCHEDULER_CAP_PREEMPTION; - } + value = dev_priv->caps.scheduler; break; case I915_PARAM_MMAP_VERSION: diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 388b72cccde4..ae434c9d2b4f 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -468,6 +468,7 @@ struct i915_gpu_state { u32 reset_count; u32 suspend_count; struct intel_device_info device_info; + struct intel_driver_caps driver_caps; struct i915_params params; struct i915_error_uc { @@ -1808,6 +1809,7 @@ struct drm_i915_private { struct kmem_cache *priorities; const struct intel_device_info info; + struct intel_driver_caps caps; /** * Data Stolen Memory - aka "i915 stolen memory" gives us the start and diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 062b21408698..ad7bd0dc57ee 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3223,8 +3223,11 @@ void i915_gem_set_wedged(struct drm_i915_private *i915) * start to complete all requests. */ engine->submit_request = nop_complete_submit_request; + engine->schedule = NULL; } + i915->caps.scheduler = 0; + /* * Make sure no request can slip through without getting completed by * either this call here to intel_engine_init_global_seqno, or the one diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c index a81351d9e3a6..a92b0c0377c7 100644 --- a/drivers/gpu/drm/i915/i915_gpu_error.c +++ b/drivers/gpu/drm/i915/i915_gpu_error.c @@ -573,11 +573,13 @@ static void print_error_obj(struct drm_i915_error_state_buf *m, } static void err_print_capabilities(struct drm_i915_error_state_buf *m, - const struct intel_device_info *info) + const struct intel_device_info *info, + const struct intel_driver_caps *caps) { struct drm_printer p = i915_error_printer(m); intel_device_info_dump_flags(info, &p); + intel_driver_caps_print(caps, &p); } static void err_print_params(struct drm_i915_error_state_buf *m, @@ -800,7 +802,7 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf *m, if (error->display) intel_display_print_error_state(m, error->display); - err_print_capabilities(m, &error->device_info); + err_print_capabilities(m, &error->device_info, &error->driver_caps); err_print_params(m, &error->params); err_print_uc(m, &error->uc); @@ -1731,6 +1733,7 @@ static void i915_capture_gen_state(struct drm_i915_private *dev_priv, memcpy(&error->device_info, INTEL_INFO(dev_priv), sizeof(error->device_info)); + error->driver_caps = dev_priv->caps; } static __always_inline void dup_param(const char *type, void *x) diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c index a2c16140169f..298f8996cc54 100644 --- a/drivers/gpu/drm/i915/intel_device_info.c +++ b/drivers/gpu/drm/i915/
[Intel-gfx] [PATCH v2 3/3] drm/i915: Only allocate preempt context when required
If we remove some hardcoded assumptions about the preempt context having a fixed id, reserved from use by normal user contexts, we may only allocate the i915_gem_context when required. Then the subsequent decisions on using preemption reduce to having the preempt context available. Signed-off-by: Chris Wilson Cc: Michal Winiarski Cc: Tvrtko Ursulin Cc: Arkadiusz Hiler Cc: Mika Kuoppala Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_gem_context.c | 29 drivers/gpu/drm/i915/intel_engine_cs.c | 6 ++--- drivers/gpu/drm/i915/intel_guc_submission.c | 24 +++- drivers/gpu/drm/i915/intel_lrc.c | 17 +- drivers/gpu/drm/i915/intel_ringbuffer.h | 5 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 6 - 6 files changed, 46 insertions(+), 41 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.c b/drivers/gpu/drm/i915/i915_gem_context.c index 648e7536ff51..d69c8f1a4e78 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.c +++ b/drivers/gpu/drm/i915/i915_gem_context.c @@ -449,10 +449,14 @@ destroy_kernel_context(struct i915_gem_context **ctxp) i915_gem_context_free(ctx); } +static bool needs_preempt_context(struct drm_i915_private *i915) +{ + return HAS_LOGICAL_RING_PREEMPTION(i915); +} + int i915_gem_contexts_init(struct drm_i915_private *dev_priv) { struct i915_gem_context *ctx; - int err; GEM_BUG_ON(dev_priv->kernel_context); @@ -468,8 +472,7 @@ int i915_gem_contexts_init(struct drm_i915_private *dev_priv) ctx = i915_gem_context_create_kernel(dev_priv, I915_PRIORITY_MIN); if (IS_ERR(ctx)) { DRM_ERROR("Failed to create default global context\n"); - err = PTR_ERR(ctx); - goto err; + return PTR_ERR(ctx); } /* * For easy recognisablity, we want the kernel context to be 0 and then @@ -479,23 +482,18 @@ int i915_gem_contexts_init(struct drm_i915_private *dev_priv) dev_priv->kernel_context = ctx; /* highest priority; preempting task */ - ctx = i915_gem_context_create_kernel(dev_priv, INT_MAX); - if (IS_ERR(ctx)) { - DRM_ERROR("Failed to create default preempt context\n"); - err = PTR_ERR(ctx); - goto err_kernel_context; + if (needs_preempt_context(dev_priv)) { + ctx = i915_gem_context_create_kernel(dev_priv, INT_MAX); + if (!IS_ERR(ctx)) + dev_priv->preempt_context = ctx; + else + DRM_ERROR("Failed to create preempt context; disabling preemption\n"); } - dev_priv->preempt_context = ctx; DRM_DEBUG_DRIVER("%s context support initialized\n", dev_priv->engine[RCS]->context_size ? "logical" : "fake"); return 0; - -err_kernel_context: - destroy_kernel_context(&dev_priv->kernel_context); -err: - return err; } void i915_gem_contexts_lost(struct drm_i915_private *dev_priv) @@ -521,7 +519,8 @@ void i915_gem_contexts_fini(struct drm_i915_private *i915) { lockdep_assert_held(&i915->drm.struct_mutex); - destroy_kernel_context(&i915->preempt_context); + if (i915->preempt_context) + destroy_kernel_context(&i915->preempt_context); destroy_kernel_context(&i915->kernel_context); /* Must free all deferred contexts (via flush_workqueue) first */ diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index 7eebfbb95e89..bf634432c9c6 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -631,7 +631,7 @@ int intel_engine_init_common(struct intel_engine_cs *engine) * Similarly the preempt context must always be available so that * we can interrupt the engine at any time. */ - if (HAS_LOGICAL_RING_PREEMPTION(engine->i915)) { + if (engine->i915->preempt_context) { ring = engine->context_pin(engine, engine->i915->preempt_context); if (IS_ERR(ring)) { @@ -656,7 +656,7 @@ int intel_engine_init_common(struct intel_engine_cs *engine) err_breadcrumbs: intel_engine_fini_breadcrumbs(engine); err_unpin_preempt: - if (HAS_LOGICAL_RING_PREEMPTION(engine->i915)) + if (engine->i915->preempt_context) engine->context_unpin(engine, engine->i915->preempt_context); err_unpin_kernel: engine->context_unpin(engine, engine->i915->kernel_context); @@ -686,7 +686,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs *engine) if (engine->default_state) i915_gem_object_put(engine->default_state); - if (HAS_LOGICAL_RING_PREEMPTION(engine->i915)) + if (engine->i915->preempt_context)
[Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Allow preempt-client to be NULL
In the next patch, we may only conditionally allocate the preempt-client if there is a global preempt context and so we need to be prepared in case the preempt-client itself is NULL. Signed-off-by: Chris Wilson Cc: Michal Winiarski Cc: Arkadiusz Hiler Cc: Daniele Ceraolo Spurio Cc: Michel Thierry Cc: Michal Wajdeczko --- drivers/gpu/drm/i915/intel_guc_submission.c | 27 +-- 1 file changed, 17 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc_submission.c b/drivers/gpu/drm/i915/intel_guc_submission.c index 1f3a8786bbdc..4ea65df05e02 100644 --- a/drivers/gpu/drm/i915/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/intel_guc_submission.c @@ -832,10 +832,12 @@ static int guc_clients_doorbell_init(struct intel_guc *guc) if (ret) return ret; - ret = create_doorbell(guc->preempt_client); - if (ret) { - destroy_doorbell(guc->execbuf_client); - return ret; + if (guc->preempt_client) { + ret = create_doorbell(guc->preempt_client); + if (ret) { + destroy_doorbell(guc->execbuf_client); + return ret; + } } return 0; @@ -848,8 +850,11 @@ static void guc_clients_doorbell_fini(struct intel_guc *guc) * Instead of trying (in vain) to communicate with it, let's just * cleanup the doorbell HW and our internal state. */ - __destroy_doorbell(guc->preempt_client); - __update_doorbell_desc(guc->preempt_client, GUC_DOORBELL_INVALID); + if (guc->preempt_client) { + __destroy_doorbell(guc->preempt_client); + __update_doorbell_desc(guc->preempt_client, + GUC_DOORBELL_INVALID); + } __destroy_doorbell(guc->execbuf_client); __update_doorbell_desc(guc->execbuf_client, GUC_DOORBELL_INVALID); } @@ -998,10 +1003,11 @@ static void guc_clients_destroy(struct intel_guc *guc) { struct intel_guc_client *client; - client = fetch_and_zero(&guc->execbuf_client); - guc_client_free(client); - client = fetch_and_zero(&guc->preempt_client); + if (client) + guc_client_free(client); + + client = fetch_and_zero(&guc->execbuf_client); guc_client_free(client); } @@ -1160,7 +1166,8 @@ int intel_guc_submission_enable(struct intel_guc *guc) GEM_BUG_ON(!guc->execbuf_client); guc_reset_wq(guc->execbuf_client); - guc_reset_wq(guc->preempt_client); + if (guc->preempt_client) + guc_reset_wq(guc->preempt_client); err = intel_guc_sample_forcewake(guc); if (err) -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [(rebase for CI) PATCH] drm/i915: Ignore minimum lines for level 0 in skl_compute_plane_wm
According to bspec, result_lines > 31 is only a maximum for latency level 1 through 7. For level 0 the number of lines is ignored, so always write 0 there to prevent overflowing the 5 bits value. This is required to make NV12 work. Signed-off-by: Maarten Lankhorst Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 0b92ea1dbd40..e33368c870b1 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4554,6 +4554,10 @@ static int skl_compute_plane_wm(const struct drm_i915_private *dev_priv, } } + /* The number of lines are ignored for the level 0 watermark. */ + if (!level) + res_lines = 0; + if (res_blocks >= ddb_allocation || res_lines > 31) { *enabled = false; -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Always run hangcheck while the GPU is busy
Chris Wilson writes: > Previously, we relied on only running the hangcheck while somebody was > waiting on the GPU, in order to minimise the amount of time hangcheck > had to run. (If nobody was watching the GPU, nobody would notice if the > GPU wasn't responding -- eventually somebody would care and so kick > hangcheck into action.) However, this falls apart from around commit > 4680816be336 ("drm/i915: Wait first for submission, before waiting for > request completion"), as not all waiters declare themselves to hangcheck > and so we could switch off hangcheck and miss GPU hangs even when > waiting under the struct_mutex. > > If we enable hangcheck from the first request submission, and let it run > until the GPU is idle again, we forgo all the complexity involved with > only enabling around waiters. Instead we have to be careful that we do > not declare a GPU hang when idly waiting for the next request to be come > ready. > > Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for > request completion" > Signed-off-by: Chris Wilson > Cc: Chris Wilson > Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_gem.c | 7 +++ > drivers/gpu/drm/i915/i915_gem_request.c | 2 ++ > drivers/gpu/drm/i915/intel_breadcrumbs.c | 11 --- > drivers/gpu/drm/i915/intel_hangcheck.c | 7 +-- > 4 files changed, 6 insertions(+), 21 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 062b21408698..63308ec016a3 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3322,16 +3322,15 @@ i915_gem_retire_work_handler(struct work_struct *work) > mutex_unlock(&dev->struct_mutex); > } > > - /* Keep the retire handler running until we are finally idle. > + /* > + * Keep the retire handler running until we are finally idle. >* We do not need to do this test under locking as in the worst-case >* we queue the retire worker once too often. >*/ > - if (READ_ONCE(dev_priv->gt.awake)) { > - i915_queue_hangcheck(dev_priv); > + if (READ_ONCE(dev_priv->gt.awake)) > queue_delayed_work(dev_priv->wq, > &dev_priv->gt.retire_work, > round_jiffies_up_relative(HZ)); > - } > } > > static void shrink_caches(struct drm_i915_private *i915) > diff --git a/drivers/gpu/drm/i915/i915_gem_request.c > b/drivers/gpu/drm/i915/i915_gem_request.c > index 9b02310307fc..6cacd78cc849 100644 > --- a/drivers/gpu/drm/i915/i915_gem_request.c > +++ b/drivers/gpu/drm/i915/i915_gem_request.c > @@ -393,6 +393,8 @@ static void mark_busy(struct drm_i915_private *i915) > > intel_engines_unpark(i915); > > + i915_queue_hangcheck(i915); > + > queue_delayed_work(i915->wq, > &i915->gt.retire_work, > round_jiffies_up_relative(HZ)); > diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c > b/drivers/gpu/drm/i915/intel_breadcrumbs.c > index 86acac010bb8..62b2a20bc24e 100644 > --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c > +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c > @@ -149,17 +149,6 @@ static void intel_breadcrumbs_fake_irq(struct timer_list > *t) > return; > > mod_timer(&b->fake_irq, jiffies + 1); > - > - /* Ensure that even if the GPU hangs, we get woken up. > - * > - * However, note that if no one is waiting, we never notice > - * a gpu hang. Eventually, we will have to wait for a resource > - * held by the GPU and so trigger a hangcheck. In the most > - * pathological case, this will be upon memory starvation! To > - * prevent this, we also queue the hangcheck from the retire > - * worker. > - */ > - i915_queue_hangcheck(engine->i915); > } > > static void irq_enable(struct intel_engine_cs *engine) > diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c > b/drivers/gpu/drm/i915/intel_hangcheck.c > index 31f01d64c021..348a4f7ffb67 100644 > --- a/drivers/gpu/drm/i915/intel_hangcheck.c > +++ b/drivers/gpu/drm/i915/intel_hangcheck.c > @@ -411,7 +411,6 @@ static void i915_hangcheck_elapsed(struct work_struct > *work) > struct intel_engine_cs *engine; > enum intel_engine_id id; > unsigned int hung = 0, stuck = 0; > - int busy_count = 0; > > if (!i915_modparams.enable_hangcheck) > return; > @@ -429,7 +428,6 @@ static void i915_hangcheck_elapsed(struct work_struct > *work) > intel_uncore_arm_unclaimed_mmio_detection(dev_priv); > > for_each_engine(engine, dev_priv, id) { > - const bool busy = intel_engine_has_waiter(engine); > struct intel_engine_hangcheck hc; > > semaphore_clear_deadlocks(dev_priv); > @@ -443,16 +441,13 @@ static void i915_hangcheck_elapsed(struct work_struct > *work) >
Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Handle interrupt based logging with lack of SSE4.1, relay and other setup
Quoting Sagar Arun Kamble (2018-01-31 06:14:38) > On some systems like skl-gvtdvm, SSE4.1 movntdqa might not be available. > movntdqa is needed for efficient capture of the logs from uncached GuC > log buffer. GuC init was tied with this support and other setup needed > for interrupt based GuC log capture like relay channel/file support and > uncached mapping support. With this patch, GuC init is now unblocked from > lack of this support. > SSE and relay support init/fini is now being done by new functions > intel_guc_log_init|fini_runtime() which makes relay functions static. > We have introduced two states "supported" and "enabled". Supported is set > when we have SSE4.1 support and have relay, GuC log, WC mapping available. > Enabled is set when support is present and user has requested logging > through i915_modparams.guc_log_level. > While at this change, fixed unwind order in intel_uc_fini_misc. Downside would appear to be the loss of feedback in i915.guc_log_level when it fail? Otherwise, looks tidy enough. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Fix return from guc_log_relay_file_create
Quoting Sagar Arun Kamble (2018-01-31 06:14:37) > guc_log_relay_file_create will return -EEXIST if we invoke > relay_late_setup_files multiple times as part of i915_guc_log_control. > However this is to be not cosidered as fail and need to return 0. > This was mistakenly introduced in the below commit. Fix it. > > Fixes: 70deeaddc6e6 "drm/i915/guc: Fix lockdep due to log relay channel > handling under struct_mutex" > Signed-off-by: Sagar Arun Kamble > Cc: Chris Wilson > Cc: Michal Wajdeczko Testcase? Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] lib: Avoid rcu_barrier() for gem_quiescent_gpu()
Using DROP_FREED invokes an rcu_barrier() to ensure that all RCU protected objects are freed before it returns. rcu_barrier() is a very high latency operation (~50ms at best) which is only required under specific circumstances such as when we need a stable object count. By removing it from gem_quiescent_gpu() we can save over 10s across a BAT run. Signed-off-by: Chris Wilson --- lib/drmtest.c | 3 +-- lib/igt_debugfs.c | 14 -- lib/intel_os.c| 15 +-- 3 files changed, 18 insertions(+), 14 deletions(-) diff --git a/lib/drmtest.c b/lib/drmtest.c index fd11f5f58..40bd6fec8 100644 --- a/lib/drmtest.c +++ b/lib/drmtest.c @@ -163,8 +163,7 @@ void gem_quiescent_gpu(int fd) { igt_terminate_spin_batches(); - igt_drop_caches_set(fd, - DROP_ACTIVE | DROP_RETIRE | DROP_IDLE | DROP_FREED); + igt_drop_caches_set(fd, DROP_ACTIVE | DROP_RETIRE | DROP_IDLE); } /** diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c index 1aec079c5..6d9d27d9c 100644 --- a/lib/igt_debugfs.c +++ b/lib/igt_debugfs.c @@ -977,13 +977,15 @@ static int get_object_count(int fd) */ int igt_get_stable_obj_count(int driver) { - int obj_count; - gem_quiescent_gpu(driver); - obj_count = get_object_count(driver); - /* The test relies on the system being in the same state before and + /* +* The test relies on the system being in the same state before and * after the test so any difference in the object count is a result of -* leaks during the test. */ - return obj_count; +* leaks during the test. +* */ + igt_drop_caches_set(driver, + DROP_ACTIVE | DROP_RETIRE | DROP_IDLE | DROP_FREED); + + return get_object_count(driver); } void igt_debugfs_dump(int device, const char *filename) diff --git a/lib/intel_os.c b/lib/intel_os.c index bb2c16bf3..b5d9888d8 100644 --- a/lib/intel_os.c +++ b/lib/intel_os.c @@ -96,11 +96,6 @@ intel_get_avail_ram_mb(void) #ifdef HAVE_STRUCT_SYSINFO_TOTALRAM /* Linux */ struct sysinfo sysinf; - int fd; - - fd = drm_open_driver(DRIVER_INTEL); - intel_purge_vm_caches(fd); - close(fd); igt_assert(sysinfo(&sysinf) == 0); retval = sysinf.freeram; @@ -281,6 +276,12 @@ void intel_require_memory(uint64_t count, uint64_t size, unsigned mode) { uint64_t required, total; + if (!__intel_check_memory(count, size, mode, &required, &total)) { + int fd = drm_open_driver(DRIVER_INTEL); + intel_purge_vm_caches(fd); + close(fd); + } + igt_require_f(__intel_check_memory(count, size, mode, &required, &total), "Estimated that we need %'llu objects and %'llu MiB for the test, but only have %'llu MiB available (%s%s) and a maximum of %'llu objects\n", @@ -298,7 +299,9 @@ void intel_purge_vm_caches(int drm_fd) { int fd; - igt_drop_caches_set(drm_fd, DROP_SHRINK_ALL | DROP_IDLE | DROP_FREED); + igt_drop_caches_set(drm_fd, + DROP_ACTIVE | DROP_RETIRE | DROP_IDLE | + DROP_SHRINK_ALL | DROP_FREED); fd = open("/proc/sys/vm/drop_caches", O_WRONLY); if (fd >= 0) { -- 2.15.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Optimize drop-caches
Quoting Chris Wilson (2018-01-30 15:44:12) > @@ -4084,8 +4088,9 @@ i915_drop_caches_set(void *data, u64 val) > drain_delayed_work(&dev_priv->gt.idle_work); > > if (val & DROP_FREED) { > - synchronize_rcu(); > - i915_gem_drain_freed_objects(dev_priv); > + synchronize_rcu_expedited(); So sync_rcu is not enough to process the call_rcu. Hmm. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx