All of lore.kernel.org
 help / color / mirror / Atom feed
From: kbuild test robot <lkp@intel.com>
To: kbuild-all@lists.01.org
Subject: [drm-intel:drm-intel-next-queued 5/5] drivers/gpu/drm/i915/gt/intel_lrc.c:2335:16: error: unused variable 'regs'
Date: Thu, 13 Feb 2020 13:00:55 +0800	[thread overview]
Message-ID: <202002131327.2Lo5hM6f%lkp@intel.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 7966 bytes --]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   c616d2387aeeb987f03eee848f04ffdc248c7aae
commit: c616d2387aeeb987f03eee848f04ffdc248c7aae [5/5] drm/i915/gt: Expand bad CS completion event debug
config: i386-randconfig-h003-20200213 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-4) 7.5.0
reproduce:
        git checkout c616d2387aeeb987f03eee848f04ffdc248c7aae
        # save the attached .config to linux build tree
        make ARCH=i386 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'process_csb':
>> drivers/gpu/drm/i915/gt/intel_lrc.c:2335:16: error: unused variable 'regs' [-Werror=unused-variable]
        const u32 *regs = rq->context->lrc_reg_state;
                   ^~~~
   cc1: all warnings being treated as errors

vim +/regs +2335 drivers/gpu/drm/i915/gt/intel_lrc.c

  2222	
  2223	static void process_csb(struct intel_engine_cs *engine)
  2224	{
  2225		struct intel_engine_execlists * const execlists = &engine->execlists;
  2226		const u32 * const buf = execlists->csb_status;
  2227		const u8 num_entries = execlists->csb_size;
  2228		u8 head, tail;
  2229	
  2230		/*
  2231		 * As we modify our execlists state tracking we require exclusive
  2232		 * access. Either we are inside the tasklet, or the tasklet is disabled
  2233		 * and we assume that is only inside the reset paths and so serialised.
  2234		 */
  2235		GEM_BUG_ON(!tasklet_is_locked(&execlists->tasklet) &&
  2236			   !reset_in_progress(execlists));
  2237		GEM_BUG_ON(!intel_engine_in_execlists_submission_mode(engine));
  2238	
  2239		/*
  2240		 * Note that csb_write, csb_status may be either in HWSP or mmio.
  2241		 * When reading from the csb_write mmio register, we have to be
  2242		 * careful to only use the GEN8_CSB_WRITE_PTR portion, which is
  2243		 * the low 4bits. As it happens we know the next 4bits are always
  2244		 * zero and so we can simply masked off the low u8 of the register
  2245		 * and treat it identically to reading from the HWSP (without having
  2246		 * to use explicit shifting and masking, and probably bifurcating
  2247		 * the code to handle the legacy mmio read).
  2248		 */
  2249		head = execlists->csb_head;
  2250		tail = READ_ONCE(*execlists->csb_write);
  2251		if (unlikely(head == tail))
  2252			return;
  2253	
  2254		/*
  2255		 * Hopefully paired with a wmb() in HW!
  2256		 *
  2257		 * We must complete the read of the write pointer before any reads
  2258		 * from the CSB, so that we do not see stale values. Without an rmb
  2259		 * (lfence) the HW may speculatively perform the CSB[] reads *before*
  2260		 * we perform the READ_ONCE(*csb_write).
  2261		 */
  2262		rmb();
  2263	
  2264		ENGINE_TRACE(engine, "cs-irq head=%d, tail=%d\n", head, tail);
  2265		do {
  2266			bool promote;
  2267	
  2268			if (++head == num_entries)
  2269				head = 0;
  2270	
  2271			/*
  2272			 * We are flying near dragons again.
  2273			 *
  2274			 * We hold a reference to the request in execlist_port[]
  2275			 * but no more than that. We are operating in softirq
  2276			 * context and so cannot hold any mutex or sleep. That
  2277			 * prevents us stopping the requests we are processing
  2278			 * in port[] from being retired simultaneously (the
  2279			 * breadcrumb will be complete before we see the
  2280			 * context-switch). As we only hold the reference to the
  2281			 * request, any pointer chasing underneath the request
  2282			 * is subject to a potential use-after-free. Thus we
  2283			 * store all of the bookkeeping within port[] as
  2284			 * required, and avoid using unguarded pointers beneath
  2285			 * request itself. The same applies to the atomic
  2286			 * status notifier.
  2287			 */
  2288	
  2289			ENGINE_TRACE(engine, "csb[%d]: status=0x%08x:0x%08x\n",
  2290				     head, buf[2 * head + 0], buf[2 * head + 1]);
  2291	
  2292			if (INTEL_GEN(engine->i915) >= 12)
  2293				promote = gen12_csb_parse(execlists, buf + 2 * head);
  2294			else
  2295				promote = gen8_csb_parse(execlists, buf + 2 * head);
  2296			if (promote) {
  2297				struct i915_request * const *old = execlists->active;
  2298	
  2299				GEM_BUG_ON(!assert_pending_valid(execlists, "promote"));
  2300	
  2301				ring_set_paused(engine, 0);
  2302	
  2303				/* Point active to the new ELSP; prevent overwriting */
  2304				WRITE_ONCE(execlists->active, execlists->pending);
  2305	
  2306				/* cancel old inflight, prepare for switch */
  2307				trace_ports(execlists, "preempted", old);
  2308				while (*old)
  2309					execlists_schedule_out(*old++);
  2310	
  2311				/* switch pending to inflight */
  2312				WRITE_ONCE(execlists->active,
  2313					   memcpy(execlists->inflight,
  2314						  execlists->pending,
  2315						  execlists_num_ports(execlists) *
  2316						  sizeof(*execlists->pending)));
  2317	
  2318				WRITE_ONCE(execlists->pending[0], NULL);
  2319			} else {
  2320				GEM_BUG_ON(!*execlists->active);
  2321	
  2322				/* port0 completed, advanced to port1 */
  2323				trace_ports(execlists, "completed", execlists->active);
  2324	
  2325				/*
  2326				 * We rely on the hardware being strongly
  2327				 * ordered, that the breadcrumb write is
  2328				 * coherent (visible from the CPU) before the
  2329				 * user interrupt and CSB is processed.
  2330				 */
  2331				if (GEM_SHOW_DEBUG() &&
  2332				    !i915_request_completed(*execlists->active) &&
  2333				    !reset_in_progress(execlists)) {
  2334					struct i915_request *rq = *execlists->active;
> 2335					const u32 *regs = rq->context->lrc_reg_state;
  2336	
  2337					ENGINE_TRACE(engine,
  2338						     "ring:{start:0x%08x, head:%04x, tail:%04x, ctl:%08x, mode:%08x}\n",
  2339						     ENGINE_READ(engine, RING_START),
  2340						     ENGINE_READ(engine, RING_HEAD) & HEAD_ADDR,
  2341						     ENGINE_READ(engine, RING_TAIL) & TAIL_ADDR,
  2342						     ENGINE_READ(engine, RING_CTL),
  2343						     ENGINE_READ(engine, RING_MI_MODE));
  2344					ENGINE_TRACE(engine,
  2345						     "rq:{start:%08x, head:%04x, tail:%04x, seqno:%llx:%d, hwsp:%d}, ",
  2346						     i915_ggtt_offset(rq->ring->vma),
  2347						     rq->head, rq->tail,
  2348						     rq->fence.context,
  2349						     lower_32_bits(rq->fence.seqno),
  2350						     hwsp_seqno(rq));
  2351					ENGINE_TRACE(engine,
  2352						     "ctx:{start:%08x, head:%04x, tail:%04x}, ",
  2353						     regs[CTX_RING_START],
  2354						     regs[CTX_RING_HEAD],
  2355						     regs[CTX_RING_TAIL]);
  2356	
  2357					GEM_BUG_ON("context completed before request");
  2358				}
  2359	
  2360				execlists_schedule_out(*execlists->active++);
  2361	
  2362				GEM_BUG_ON(execlists->active - execlists->inflight >
  2363					   execlists_num_ports(execlists));
  2364			}
  2365		} while (head != tail);
  2366	
  2367		execlists->csb_head = head;
  2368		set_timeslice(engine);
  2369	
  2370		/*
  2371		 * Gen11 has proven to fail wrt global observation point between
  2372		 * entry and tail update, failing on the ordering and thus
  2373		 * we see an old entry in the context status buffer.
  2374		 *
  2375		 * Forcibly evict out entries for the next gpu csb update,
  2376		 * to increase the odds that we get a fresh entries with non
  2377		 * working hardware. The cost for doing so comes out mostly with
  2378		 * the wash as hardware, working or not, will need to do the
  2379		 * invalidation before.
  2380		 */
  2381		invalidate_csb_entries(&buf[0], &buf[num_entries - 1]);
  2382	}
  2383	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 32775 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: kbuild test robot <lkp@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>,
	intel-gfx@lists.freedesktop.org, kbuild-all@lists.01.org,
	dri-devel@lists.freedesktop.org
Subject: [drm-intel:drm-intel-next-queued 5/5] drivers/gpu/drm/i915/gt/intel_lrc.c:2335:16: error: unused variable 'regs'
Date: Thu, 13 Feb 2020 13:00:55 +0800	[thread overview]
Message-ID: <202002131327.2Lo5hM6f%lkp@intel.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 7775 bytes --]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   c616d2387aeeb987f03eee848f04ffdc248c7aae
commit: c616d2387aeeb987f03eee848f04ffdc248c7aae [5/5] drm/i915/gt: Expand bad CS completion event debug
config: i386-randconfig-h003-20200213 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-4) 7.5.0
reproduce:
        git checkout c616d2387aeeb987f03eee848f04ffdc248c7aae
        # save the attached .config to linux build tree
        make ARCH=i386 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'process_csb':
>> drivers/gpu/drm/i915/gt/intel_lrc.c:2335:16: error: unused variable 'regs' [-Werror=unused-variable]
        const u32 *regs = rq->context->lrc_reg_state;
                   ^~~~
   cc1: all warnings being treated as errors

vim +/regs +2335 drivers/gpu/drm/i915/gt/intel_lrc.c

  2222	
  2223	static void process_csb(struct intel_engine_cs *engine)
  2224	{
  2225		struct intel_engine_execlists * const execlists = &engine->execlists;
  2226		const u32 * const buf = execlists->csb_status;
  2227		const u8 num_entries = execlists->csb_size;
  2228		u8 head, tail;
  2229	
  2230		/*
  2231		 * As we modify our execlists state tracking we require exclusive
  2232		 * access. Either we are inside the tasklet, or the tasklet is disabled
  2233		 * and we assume that is only inside the reset paths and so serialised.
  2234		 */
  2235		GEM_BUG_ON(!tasklet_is_locked(&execlists->tasklet) &&
  2236			   !reset_in_progress(execlists));
  2237		GEM_BUG_ON(!intel_engine_in_execlists_submission_mode(engine));
  2238	
  2239		/*
  2240		 * Note that csb_write, csb_status may be either in HWSP or mmio.
  2241		 * When reading from the csb_write mmio register, we have to be
  2242		 * careful to only use the GEN8_CSB_WRITE_PTR portion, which is
  2243		 * the low 4bits. As it happens we know the next 4bits are always
  2244		 * zero and so we can simply masked off the low u8 of the register
  2245		 * and treat it identically to reading from the HWSP (without having
  2246		 * to use explicit shifting and masking, and probably bifurcating
  2247		 * the code to handle the legacy mmio read).
  2248		 */
  2249		head = execlists->csb_head;
  2250		tail = READ_ONCE(*execlists->csb_write);
  2251		if (unlikely(head == tail))
  2252			return;
  2253	
  2254		/*
  2255		 * Hopefully paired with a wmb() in HW!
  2256		 *
  2257		 * We must complete the read of the write pointer before any reads
  2258		 * from the CSB, so that we do not see stale values. Without an rmb
  2259		 * (lfence) the HW may speculatively perform the CSB[] reads *before*
  2260		 * we perform the READ_ONCE(*csb_write).
  2261		 */
  2262		rmb();
  2263	
  2264		ENGINE_TRACE(engine, "cs-irq head=%d, tail=%d\n", head, tail);
  2265		do {
  2266			bool promote;
  2267	
  2268			if (++head == num_entries)
  2269				head = 0;
  2270	
  2271			/*
  2272			 * We are flying near dragons again.
  2273			 *
  2274			 * We hold a reference to the request in execlist_port[]
  2275			 * but no more than that. We are operating in softirq
  2276			 * context and so cannot hold any mutex or sleep. That
  2277			 * prevents us stopping the requests we are processing
  2278			 * in port[] from being retired simultaneously (the
  2279			 * breadcrumb will be complete before we see the
  2280			 * context-switch). As we only hold the reference to the
  2281			 * request, any pointer chasing underneath the request
  2282			 * is subject to a potential use-after-free. Thus we
  2283			 * store all of the bookkeeping within port[] as
  2284			 * required, and avoid using unguarded pointers beneath
  2285			 * request itself. The same applies to the atomic
  2286			 * status notifier.
  2287			 */
  2288	
  2289			ENGINE_TRACE(engine, "csb[%d]: status=0x%08x:0x%08x\n",
  2290				     head, buf[2 * head + 0], buf[2 * head + 1]);
  2291	
  2292			if (INTEL_GEN(engine->i915) >= 12)
  2293				promote = gen12_csb_parse(execlists, buf + 2 * head);
  2294			else
  2295				promote = gen8_csb_parse(execlists, buf + 2 * head);
  2296			if (promote) {
  2297				struct i915_request * const *old = execlists->active;
  2298	
  2299				GEM_BUG_ON(!assert_pending_valid(execlists, "promote"));
  2300	
  2301				ring_set_paused(engine, 0);
  2302	
  2303				/* Point active to the new ELSP; prevent overwriting */
  2304				WRITE_ONCE(execlists->active, execlists->pending);
  2305	
  2306				/* cancel old inflight, prepare for switch */
  2307				trace_ports(execlists, "preempted", old);
  2308				while (*old)
  2309					execlists_schedule_out(*old++);
  2310	
  2311				/* switch pending to inflight */
  2312				WRITE_ONCE(execlists->active,
  2313					   memcpy(execlists->inflight,
  2314						  execlists->pending,
  2315						  execlists_num_ports(execlists) *
  2316						  sizeof(*execlists->pending)));
  2317	
  2318				WRITE_ONCE(execlists->pending[0], NULL);
  2319			} else {
  2320				GEM_BUG_ON(!*execlists->active);
  2321	
  2322				/* port0 completed, advanced to port1 */
  2323				trace_ports(execlists, "completed", execlists->active);
  2324	
  2325				/*
  2326				 * We rely on the hardware being strongly
  2327				 * ordered, that the breadcrumb write is
  2328				 * coherent (visible from the CPU) before the
  2329				 * user interrupt and CSB is processed.
  2330				 */
  2331				if (GEM_SHOW_DEBUG() &&
  2332				    !i915_request_completed(*execlists->active) &&
  2333				    !reset_in_progress(execlists)) {
  2334					struct i915_request *rq = *execlists->active;
> 2335					const u32 *regs = rq->context->lrc_reg_state;
  2336	
  2337					ENGINE_TRACE(engine,
  2338						     "ring:{start:0x%08x, head:%04x, tail:%04x, ctl:%08x, mode:%08x}\n",
  2339						     ENGINE_READ(engine, RING_START),
  2340						     ENGINE_READ(engine, RING_HEAD) & HEAD_ADDR,
  2341						     ENGINE_READ(engine, RING_TAIL) & TAIL_ADDR,
  2342						     ENGINE_READ(engine, RING_CTL),
  2343						     ENGINE_READ(engine, RING_MI_MODE));
  2344					ENGINE_TRACE(engine,
  2345						     "rq:{start:%08x, head:%04x, tail:%04x, seqno:%llx:%d, hwsp:%d}, ",
  2346						     i915_ggtt_offset(rq->ring->vma),
  2347						     rq->head, rq->tail,
  2348						     rq->fence.context,
  2349						     lower_32_bits(rq->fence.seqno),
  2350						     hwsp_seqno(rq));
  2351					ENGINE_TRACE(engine,
  2352						     "ctx:{start:%08x, head:%04x, tail:%04x}, ",
  2353						     regs[CTX_RING_START],
  2354						     regs[CTX_RING_HEAD],
  2355						     regs[CTX_RING_TAIL]);
  2356	
  2357					GEM_BUG_ON("context completed before request");
  2358				}
  2359	
  2360				execlists_schedule_out(*execlists->active++);
  2361	
  2362				GEM_BUG_ON(execlists->active - execlists->inflight >
  2363					   execlists_num_ports(execlists));
  2364			}
  2365		} while (head != tail);
  2366	
  2367		execlists->csb_head = head;
  2368		set_timeslice(engine);
  2369	
  2370		/*
  2371		 * Gen11 has proven to fail wrt global observation point between
  2372		 * entry and tail update, failing on the ordering and thus
  2373		 * we see an old entry in the context status buffer.
  2374		 *
  2375		 * Forcibly evict out entries for the next gpu csb update,
  2376		 * to increase the odds that we get a fresh entries with non
  2377		 * working hardware. The cost for doing so comes out mostly with
  2378		 * the wash as hardware, working or not, will need to do the
  2379		 * invalidation before.
  2380		 */
  2381		invalidate_csb_entries(&buf[0], &buf[num_entries - 1]);
  2382	}
  2383	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32775 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: kbuild test robot <lkp@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, kbuild-all@lists.01.org,
	dri-devel@lists.freedesktop.org
Subject: [Intel-gfx] [drm-intel:drm-intel-next-queued 5/5] drivers/gpu/drm/i915/gt/intel_lrc.c:2335:16: error: unused variable 'regs'
Date: Thu, 13 Feb 2020 13:00:55 +0800	[thread overview]
Message-ID: <202002131327.2Lo5hM6f%lkp@intel.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 7775 bytes --]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   c616d2387aeeb987f03eee848f04ffdc248c7aae
commit: c616d2387aeeb987f03eee848f04ffdc248c7aae [5/5] drm/i915/gt: Expand bad CS completion event debug
config: i386-randconfig-h003-20200213 (attached as .config)
compiler: gcc-7 (Debian 7.5.0-4) 7.5.0
reproduce:
        git checkout c616d2387aeeb987f03eee848f04ffdc248c7aae
        # save the attached .config to linux build tree
        make ARCH=i386 

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/gt/intel_lrc.c: In function 'process_csb':
>> drivers/gpu/drm/i915/gt/intel_lrc.c:2335:16: error: unused variable 'regs' [-Werror=unused-variable]
        const u32 *regs = rq->context->lrc_reg_state;
                   ^~~~
   cc1: all warnings being treated as errors

vim +/regs +2335 drivers/gpu/drm/i915/gt/intel_lrc.c

  2222	
  2223	static void process_csb(struct intel_engine_cs *engine)
  2224	{
  2225		struct intel_engine_execlists * const execlists = &engine->execlists;
  2226		const u32 * const buf = execlists->csb_status;
  2227		const u8 num_entries = execlists->csb_size;
  2228		u8 head, tail;
  2229	
  2230		/*
  2231		 * As we modify our execlists state tracking we require exclusive
  2232		 * access. Either we are inside the tasklet, or the tasklet is disabled
  2233		 * and we assume that is only inside the reset paths and so serialised.
  2234		 */
  2235		GEM_BUG_ON(!tasklet_is_locked(&execlists->tasklet) &&
  2236			   !reset_in_progress(execlists));
  2237		GEM_BUG_ON(!intel_engine_in_execlists_submission_mode(engine));
  2238	
  2239		/*
  2240		 * Note that csb_write, csb_status may be either in HWSP or mmio.
  2241		 * When reading from the csb_write mmio register, we have to be
  2242		 * careful to only use the GEN8_CSB_WRITE_PTR portion, which is
  2243		 * the low 4bits. As it happens we know the next 4bits are always
  2244		 * zero and so we can simply masked off the low u8 of the register
  2245		 * and treat it identically to reading from the HWSP (without having
  2246		 * to use explicit shifting and masking, and probably bifurcating
  2247		 * the code to handle the legacy mmio read).
  2248		 */
  2249		head = execlists->csb_head;
  2250		tail = READ_ONCE(*execlists->csb_write);
  2251		if (unlikely(head == tail))
  2252			return;
  2253	
  2254		/*
  2255		 * Hopefully paired with a wmb() in HW!
  2256		 *
  2257		 * We must complete the read of the write pointer before any reads
  2258		 * from the CSB, so that we do not see stale values. Without an rmb
  2259		 * (lfence) the HW may speculatively perform the CSB[] reads *before*
  2260		 * we perform the READ_ONCE(*csb_write).
  2261		 */
  2262		rmb();
  2263	
  2264		ENGINE_TRACE(engine, "cs-irq head=%d, tail=%d\n", head, tail);
  2265		do {
  2266			bool promote;
  2267	
  2268			if (++head == num_entries)
  2269				head = 0;
  2270	
  2271			/*
  2272			 * We are flying near dragons again.
  2273			 *
  2274			 * We hold a reference to the request in execlist_port[]
  2275			 * but no more than that. We are operating in softirq
  2276			 * context and so cannot hold any mutex or sleep. That
  2277			 * prevents us stopping the requests we are processing
  2278			 * in port[] from being retired simultaneously (the
  2279			 * breadcrumb will be complete before we see the
  2280			 * context-switch). As we only hold the reference to the
  2281			 * request, any pointer chasing underneath the request
  2282			 * is subject to a potential use-after-free. Thus we
  2283			 * store all of the bookkeeping within port[] as
  2284			 * required, and avoid using unguarded pointers beneath
  2285			 * request itself. The same applies to the atomic
  2286			 * status notifier.
  2287			 */
  2288	
  2289			ENGINE_TRACE(engine, "csb[%d]: status=0x%08x:0x%08x\n",
  2290				     head, buf[2 * head + 0], buf[2 * head + 1]);
  2291	
  2292			if (INTEL_GEN(engine->i915) >= 12)
  2293				promote = gen12_csb_parse(execlists, buf + 2 * head);
  2294			else
  2295				promote = gen8_csb_parse(execlists, buf + 2 * head);
  2296			if (promote) {
  2297				struct i915_request * const *old = execlists->active;
  2298	
  2299				GEM_BUG_ON(!assert_pending_valid(execlists, "promote"));
  2300	
  2301				ring_set_paused(engine, 0);
  2302	
  2303				/* Point active to the new ELSP; prevent overwriting */
  2304				WRITE_ONCE(execlists->active, execlists->pending);
  2305	
  2306				/* cancel old inflight, prepare for switch */
  2307				trace_ports(execlists, "preempted", old);
  2308				while (*old)
  2309					execlists_schedule_out(*old++);
  2310	
  2311				/* switch pending to inflight */
  2312				WRITE_ONCE(execlists->active,
  2313					   memcpy(execlists->inflight,
  2314						  execlists->pending,
  2315						  execlists_num_ports(execlists) *
  2316						  sizeof(*execlists->pending)));
  2317	
  2318				WRITE_ONCE(execlists->pending[0], NULL);
  2319			} else {
  2320				GEM_BUG_ON(!*execlists->active);
  2321	
  2322				/* port0 completed, advanced to port1 */
  2323				trace_ports(execlists, "completed", execlists->active);
  2324	
  2325				/*
  2326				 * We rely on the hardware being strongly
  2327				 * ordered, that the breadcrumb write is
  2328				 * coherent (visible from the CPU) before the
  2329				 * user interrupt and CSB is processed.
  2330				 */
  2331				if (GEM_SHOW_DEBUG() &&
  2332				    !i915_request_completed(*execlists->active) &&
  2333				    !reset_in_progress(execlists)) {
  2334					struct i915_request *rq = *execlists->active;
> 2335					const u32 *regs = rq->context->lrc_reg_state;
  2336	
  2337					ENGINE_TRACE(engine,
  2338						     "ring:{start:0x%08x, head:%04x, tail:%04x, ctl:%08x, mode:%08x}\n",
  2339						     ENGINE_READ(engine, RING_START),
  2340						     ENGINE_READ(engine, RING_HEAD) & HEAD_ADDR,
  2341						     ENGINE_READ(engine, RING_TAIL) & TAIL_ADDR,
  2342						     ENGINE_READ(engine, RING_CTL),
  2343						     ENGINE_READ(engine, RING_MI_MODE));
  2344					ENGINE_TRACE(engine,
  2345						     "rq:{start:%08x, head:%04x, tail:%04x, seqno:%llx:%d, hwsp:%d}, ",
  2346						     i915_ggtt_offset(rq->ring->vma),
  2347						     rq->head, rq->tail,
  2348						     rq->fence.context,
  2349						     lower_32_bits(rq->fence.seqno),
  2350						     hwsp_seqno(rq));
  2351					ENGINE_TRACE(engine,
  2352						     "ctx:{start:%08x, head:%04x, tail:%04x}, ",
  2353						     regs[CTX_RING_START],
  2354						     regs[CTX_RING_HEAD],
  2355						     regs[CTX_RING_TAIL]);
  2356	
  2357					GEM_BUG_ON("context completed before request");
  2358				}
  2359	
  2360				execlists_schedule_out(*execlists->active++);
  2361	
  2362				GEM_BUG_ON(execlists->active - execlists->inflight >
  2363					   execlists_num_ports(execlists));
  2364			}
  2365		} while (head != tail);
  2366	
  2367		execlists->csb_head = head;
  2368		set_timeslice(engine);
  2369	
  2370		/*
  2371		 * Gen11 has proven to fail wrt global observation point between
  2372		 * entry and tail update, failing on the ordering and thus
  2373		 * we see an old entry in the context status buffer.
  2374		 *
  2375		 * Forcibly evict out entries for the next gpu csb update,
  2376		 * to increase the odds that we get a fresh entries with non
  2377		 * working hardware. The cost for doing so comes out mostly with
  2378		 * the wash as hardware, working or not, will need to do the
  2379		 * invalidation before.
  2380		 */
  2381		invalidate_csb_entries(&buf[0], &buf[num_entries - 1]);
  2382	}
  2383	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32775 bytes --]

[-- Attachment #3: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

             reply	other threads:[~2020-02-13  5:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-13  5:00 kbuild test robot [this message]
2020-02-13  5:00 ` [Intel-gfx] [drm-intel:drm-intel-next-queued 5/5] drivers/gpu/drm/i915/gt/intel_lrc.c:2335:16: error: unused variable 'regs' kbuild test robot
2020-02-13  5:00 ` kbuild test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202002131327.2Lo5hM6f%lkp@intel.com \
    --to=lkp@intel.com \
    --cc=kbuild-all@lists.01.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.