From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: John Harrison <John.C.Harrison@Intel.com>,
Chris Wilson <chris@chris-wilson.co.uk>,
intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 08/34] drm/i915: Make all GPU resets atomic
Date: Wed, 23 Jan 2019 10:52:03 +0200 [thread overview]
Message-ID: <87k1ivn4cs.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <2943ee42-b094-8977-a4fa-fac111d5604d@Intel.com>
John Harrison <John.C.Harrison@Intel.com> writes:
> On 1/21/2019 14:20, Chris Wilson wrote:
>> In preparation for the next few commits, make resetting the GPU atomic.
>> Currently, we have prepared gen6+ for atomic resetting of individual
>> engines, but now there is a requirement to perform the whole device
>> level reset (just the register poking) from inside an atomic context.
>>
>> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
>> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
>> ---
>> drivers/gpu/drm/i915/i915_reset.c | 50 +++++++++++++++++--------------
>> 1 file changed, 27 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c
>> index 342d9ee42601..b9d0ea70361c 100644
>> --- a/drivers/gpu/drm/i915/i915_reset.c
>> +++ b/drivers/gpu/drm/i915/i915_reset.c
>> @@ -144,14 +144,14 @@ static int i915_do_reset(struct drm_i915_private *i915,
>>
>> /* Assert reset for at least 20 usec, and wait for acknowledgement. */
>> pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
>> - usleep_range(50, 200);
>> - err = wait_for(i915_in_reset(pdev), 500);
>> + udelay(50);
>> + err = wait_for_atomic(i915_in_reset(pdev), 50);
> Is it known to be safe to reduce all of these time out values? Where did
> the originally 500ms value come from? Is there any chance of getting
> sporadic failures because 50ms is borderline in the worst case scenario?
> It still sounds huge but an order of magnitude change in a timeout
> always seems worrying!
>
>>
>> /* Clear the reset request. */
>> pci_write_config_byte(pdev, I915_GDRST, 0);
>> - usleep_range(50, 200);
>> + udelay(50);
>> if (!err)
>> - err = wait_for(!i915_in_reset(pdev), 500);
>> + err = wait_for_atomic(!i915_in_reset(pdev), 50);
>>
>> return err;
>> }
>> @@ -171,7 +171,7 @@ static int g33_do_reset(struct drm_i915_private *i915,
>> struct pci_dev *pdev = i915->drm.pdev;
>>
>> pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
>> - return wait_for(g4x_reset_complete(pdev), 500);
>> + return wait_for_atomic(g4x_reset_complete(pdev), 50);
>> }
>>
>> static int g4x_do_reset(struct drm_i915_private *dev_priv,
>> @@ -182,13 +182,13 @@ static int g4x_do_reset(struct drm_i915_private *dev_priv,
>> int ret;
>>
>> /* WaVcpClkGateDisableForMediaReset:ctg,elk */
>> - I915_WRITE(VDECCLK_GATE_D,
>> - I915_READ(VDECCLK_GATE_D) | VCP_UNIT_CLOCK_GATE_DISABLE);
>> - POSTING_READ(VDECCLK_GATE_D);
>> + I915_WRITE_FW(VDECCLK_GATE_D,
>> + I915_READ(VDECCLK_GATE_D) | VCP_UNIT_CLOCK_GATE_DISABLE);
>> + POSTING_READ_FW(VDECCLK_GATE_D);
>>
>> pci_write_config_byte(pdev, I915_GDRST,
>> GRDOM_MEDIA | GRDOM_RESET_ENABLE);
>> - ret = wait_for(g4x_reset_complete(pdev), 500);
>> + ret = wait_for_atomic(g4x_reset_complete(pdev), 50);
>> if (ret) {
>> DRM_DEBUG_DRIVER("Wait for media reset failed\n");
>> goto out;
>> @@ -196,7 +196,7 @@ static int g4x_do_reset(struct drm_i915_private *dev_priv,
>>
>> pci_write_config_byte(pdev, I915_GDRST,
>> GRDOM_RENDER | GRDOM_RESET_ENABLE);
>> - ret = wait_for(g4x_reset_complete(pdev), 500);
>> + ret = wait_for_atomic(g4x_reset_complete(pdev), 50);
>> if (ret) {
>> DRM_DEBUG_DRIVER("Wait for render reset failed\n");
>> goto out;
>> @@ -205,9 +205,9 @@ static int g4x_do_reset(struct drm_i915_private *dev_priv,
>> out:
>> pci_write_config_byte(pdev, I915_GDRST, 0);
>>
>> - I915_WRITE(VDECCLK_GATE_D,
>> - I915_READ(VDECCLK_GATE_D) & ~VCP_UNIT_CLOCK_GATE_DISABLE);
>> - POSTING_READ(VDECCLK_GATE_D);
>> + I915_WRITE_FW(VDECCLK_GATE_D,
>> + I915_READ(VDECCLK_GATE_D) & ~VCP_UNIT_CLOCK_GATE_DISABLE);
>> + POSTING_READ_FW(VDECCLK_GATE_D);
>>
>> return ret;
>> }
>> @@ -218,27 +218,29 @@ static int ironlake_do_reset(struct drm_i915_private *dev_priv,
>> {
>> int ret;
>>
>> - I915_WRITE(ILK_GDSR, ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
>> - ret = intel_wait_for_register(dev_priv,
>> - ILK_GDSR, ILK_GRDOM_RESET_ENABLE, 0,
>> - 500);
>> + I915_WRITE_FW(ILK_GDSR, ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
>> + ret = __intel_wait_for_register_fw(dev_priv, ILK_GDSR,
>> + ILK_GRDOM_RESET_ENABLE, 0,
>> + 5000, 0,
>> + NULL);
> These two timeouts are now two orders of magnitude smaller? It was 500ms
> but is now 5000us (=5ms)?
Agreed. I indirecty raised same concern on previous round of
review by saying that it would be nice if we had some statistics
from CI.
The original ballooning of these numbers, from the little
that is available on documentation, is the fact that
previously, it didn't do much harm to pick a large number
to be on safe side, so why not.
Now, it is a different game.
-Mika
>
> John.
>
>
>> if (ret) {
>> DRM_DEBUG_DRIVER("Wait for render reset failed\n");
>> goto out;
>> }
>>
>> - I915_WRITE(ILK_GDSR, ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
>> - ret = intel_wait_for_register(dev_priv,
>> - ILK_GDSR, ILK_GRDOM_RESET_ENABLE, 0,
>> - 500);
>> + I915_WRITE_FW(ILK_GDSR, ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
>> + ret = __intel_wait_for_register_fw(dev_priv, ILK_GDSR,
>> + ILK_GRDOM_RESET_ENABLE, 0,
>> + 5000, 0,
>> + NULL);
>> if (ret) {
>> DRM_DEBUG_DRIVER("Wait for media reset failed\n");
>> goto out;
>> }
>>
>> out:
>> - I915_WRITE(ILK_GDSR, 0);
>> - POSTING_READ(ILK_GDSR);
>> + I915_WRITE_FW(ILK_GDSR, 0);
>> + POSTING_READ_FW(ILK_GDSR);
>> return ret;
>> }
>>
>> @@ -572,7 +574,9 @@ int intel_gpu_reset(struct drm_i915_private *i915, unsigned int engine_mask)
>> ret = -ENODEV;
>> if (reset) {
>> GEM_TRACE("engine_mask=%x\n", engine_mask);
>> + preempt_disable();
>> ret = reset(i915, engine_mask, retry);
>> + preempt_enable();
>> }
>> if (ret != -ETIMEDOUT || engine_mask != ALL_ENGINES)
>> break;
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-01-23 8:53 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-21 22:20 HWSP for HW semaphores Chris Wilson
2019-01-21 22:20 ` [PATCH 01/34] drm/i915/execlists: Mark up priority boost on preemption Chris Wilson
2019-01-21 22:20 ` [PATCH 02/34] drm/i915/execlists: Suppress preempting self Chris Wilson
2019-01-22 22:18 ` John Harrison
2019-01-22 22:38 ` Chris Wilson
2019-01-21 22:20 ` [PATCH 03/34] drm/i915: Show all active engines on hangcheck Chris Wilson
2019-01-22 12:33 ` Mika Kuoppala
2019-01-22 12:42 ` Chris Wilson
2019-01-21 22:20 ` [PATCH 04/34] drm/i915/selftests: Refactor common live_test framework Chris Wilson
2019-01-22 12:37 ` Matthew Auld
2019-01-21 22:20 ` [PATCH 05/34] drm/i915/selftests: Track evict objects explicitly Chris Wilson
2019-01-22 11:53 ` Matthew Auld
2019-01-21 22:20 ` [PATCH 06/34] drm/i915/selftests: Create a clean GGTT for vma/gtt selftesting Chris Wilson
2019-01-22 12:07 ` Matthew Auld
2019-01-21 22:20 ` [PATCH 07/34] drm/i915: Refactor out intel_context_init() Chris Wilson
2019-01-22 12:32 ` Matthew Auld
2019-01-22 12:39 ` Mika Kuoppala
2019-01-22 12:48 ` Chris Wilson
2019-01-21 22:20 ` [PATCH 08/34] drm/i915: Make all GPU resets atomic Chris Wilson
2019-01-22 22:19 ` John Harrison
2019-01-22 22:27 ` Chris Wilson
2019-01-23 8:52 ` Mika Kuoppala [this message]
2019-01-21 22:20 ` [PATCH 09/34] drm/i915/guc: Disable global reset Chris Wilson
2019-01-22 22:23 ` John Harrison
2019-01-21 22:20 ` [PATCH 10/34] drm/i915: Remove GPU reset dependence on struct_mutex Chris Wilson
2019-01-24 12:06 ` Mika Kuoppala
2019-01-24 12:50 ` Chris Wilson
2019-01-24 13:12 ` Chris Wilson
2019-01-24 14:10 ` Chris Wilson
2019-01-21 22:20 ` [PATCH 11/34] drm/i915/selftests: Trim struct_mutex duration for set-wedged selftest Chris Wilson
2019-01-21 22:20 ` [PATCH 12/34] drm/i915: Issue engine resets onto idle engines Chris Wilson
2019-01-23 1:18 ` John Harrison
2019-01-23 1:31 ` Chris Wilson
2019-01-21 22:20 ` [PATCH 13/34] drm/i915: Stop tracking MRU activity on VMA Chris Wilson
2019-01-21 22:20 ` [PATCH 14/34] drm/i915: Pull VM lists under the VM mutex Chris Wilson
2019-01-22 9:09 ` Tvrtko Ursulin
2019-01-21 22:20 ` [PATCH 15/34] drm/i915: Move vma lookup to its own lock Chris Wilson
2019-01-21 22:20 ` [PATCH 16/34] drm/i915: Always allocate an object/vma for the HWSP Chris Wilson
2019-01-21 22:21 ` [PATCH 17/34] drm/i915: Move list of timelines under its own lock Chris Wilson
2019-01-21 22:21 ` [PATCH 18/34] drm/i915/selftests: Use common mock_engine::advance Chris Wilson
2019-01-22 9:33 ` Tvrtko Ursulin
2019-01-21 22:21 ` [PATCH 19/34] drm/i915: Tidy common test_bit probing of i915_request->fence.flags Chris Wilson
2019-01-22 9:35 ` Tvrtko Ursulin
2019-01-21 22:21 ` [PATCH 20/34] drm/i915: Introduce concept of per-timeline (context) HWSP Chris Wilson
2019-01-23 1:35 ` John Harrison
2019-01-21 22:21 ` [PATCH 21/34] drm/i915: Enlarge vma->pin_count Chris Wilson
2019-01-21 22:21 ` [PATCH 22/34] drm/i915: Allocate a status page for each timeline Chris Wilson
2019-01-21 22:21 ` [PATCH 23/34] drm/i915: Share per-timeline HWSP using a slab suballocator Chris Wilson
2019-01-22 10:47 ` Tvrtko Ursulin
2019-01-22 11:12 ` Chris Wilson
2019-01-22 11:33 ` Tvrtko Ursulin
2019-01-21 22:21 ` [PATCH 24/34] drm/i915: Track the context's seqno in its own timeline HWSP Chris Wilson
2019-01-22 12:24 ` Tvrtko Ursulin
2019-01-21 22:21 ` [PATCH 25/34] drm/i915: Track active timelines Chris Wilson
2019-01-22 14:56 ` Tvrtko Ursulin
2019-01-22 15:17 ` Chris Wilson
2019-01-23 22:32 ` John Harrison
2019-01-23 23:08 ` Chris Wilson
2019-01-21 22:21 ` [PATCH 26/34] drm/i915: Identify active requests Chris Wilson
2019-01-22 15:34 ` Tvrtko Ursulin
2019-01-22 15:45 ` Chris Wilson
2019-01-21 22:21 ` [PATCH 27/34] drm/i915: Remove the intel_engine_notify tracepoint Chris Wilson
2019-01-22 15:50 ` Tvrtko Ursulin
2019-01-23 12:54 ` Chris Wilson
2019-01-23 13:18 ` Tvrtko Ursulin
2019-01-23 13:24 ` Chris Wilson
2019-01-21 22:21 ` [PATCH 28/34] drm/i915: Replace global breadcrumbs with per-context interrupt tracking Chris Wilson
2019-01-23 9:21 ` Tvrtko Ursulin
2019-01-23 10:01 ` Chris Wilson
2019-01-23 16:28 ` Tvrtko Ursulin
2019-01-23 11:41 ` [PATCH] " Chris Wilson
2019-01-21 22:21 ` [PATCH 29/34] drm/i915: Drop fake breadcrumb irq Chris Wilson
2019-01-24 17:55 ` Tvrtko Ursulin
2019-01-24 18:18 ` Chris Wilson
2019-01-21 22:21 ` [PATCH 30/34] drm/i915: Keep timeline HWSP allocated until the system is idle Chris Wilson
2019-01-21 22:37 ` Chris Wilson
2019-01-21 22:48 ` Chris Wilson
2019-01-21 22:21 ` [PATCH 31/34] drm/i915/execlists: Refactor out can_merge_rq() Chris Wilson
2019-01-21 22:21 ` [PATCH 32/34] drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+ Chris Wilson
2019-01-21 22:21 ` [PATCH 33/34] drm/i915: Prioritise non-busywait semaphore workloads Chris Wilson
2019-01-23 0:33 ` Chris Wilson
2019-01-21 22:21 ` [PATCH 34/34] drm/i915: Replace global_seqno with a hangcheck heartbeat seqno Chris Wilson
2019-01-22 0:09 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/34] drm/i915/execlists: Mark up priority boost on preemption Patchwork
2019-01-22 0:22 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-01-22 0:30 ` ✓ Fi.CI.BAT: success " Patchwork
2019-01-22 1:35 ` ✗ Fi.CI.IGT: failure " Patchwork
2019-01-23 12:00 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/34] drm/i915/execlists: Mark up priority boost on preemption (rev2) Patchwork
2019-01-23 12:11 ` ✗ Fi.CI.SPARSE: " Patchwork
2019-01-23 12:48 ` ✗ Fi.CI.BAT: failure " Patchwork
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=87k1ivn4cs.fsf@gaia.fi.intel.com \
--to=mika.kuoppala@linux.intel.com \
--cc=John.C.Harrison@Intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.