Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 08 11月, 2016 7 次提交
  3. 07 11月, 2016 7 次提交
    • I
      drm/i915: Add assert for no pending GPU requests during suspend/resume in LR mode · 31ab49ab
      由 Imre Deak 提交于 
      During resume we will reset the SW/HW tracking for each ring head/tail
pointers and so are not prepared to replay any pending requests (as
opposed to GPU reset time). Add an assert for this both to the suspend
and the resume code.

v2:
- Check for ELSP port idle already during suspend and check !gt.awake
  during resume. (Chris)
v3:
- Move the !gt.awake check to i915_gem_resume().
v4:
- s/intel_lr_engines_idle/intel_execlists_idle/ (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1478510405-11799-4-git-send-email-imre.deak@intel.com
      31ab49ab
    • I
      drm/i915: Make sure engines are idle during GPU idling in LR mode · 0cb5670b
      由 Imre Deak 提交于 
      We assume that the GPU is idle once receiving the seqno via the last
request's user interrupt. In execlist mode the corresponding context
completed interrupt can be delayed though and until this latter
interrupt arrives we consider the request to be pending on the ELSP
submit port. This can cause a problem during system suspend where this
last request will be seen by the resume code as still pending. Such
pending requests are normally replayed after a GPU reset, but during
resume we reset both SW and HW tracking of the ring head/tail pointers,
so replaying the pending request with its stale tail pointer will leave
the ring in an inconsistent state. A subsequent request submission can
lead then to the GPU executing from uninitialized area in the ring
behind the above stale tail pointer.

Fix this by making sure any pending request on the ELSP port is
completed before suspending. I used a polling wait since the completion
time I measured was <1ms and since normally we only need to wait during
system suspend. GPU idling during runtime suspend is scheduled with a
delay (currently 50-100ms) after the retirement of the last request at
which point the context completed interrupt must have arrived already.

The chance of this bug was increased by

commit 1c777c5d
Author: Imre Deak <imre.deak@intel.com>
Date:   Wed Oct 12 17:46:37 2016 +0300

    drm/i915/hsw: Fix GPU hang during resume from S3-devices state

but it could happen even without the explicit GPU reset, since we
disable interrupts afterwards during the suspend sequence.

v2:
- Do an unlocked poll-wait first. (Chris)
v3-4:
- s/intel_lr_engines_idle/intel_execlists_idle/ and move
  i915.enable_execlists check to the new helper. (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98470Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1478510405-11799-3-git-send-email-imre.deak@intel.com
      0cb5670b
    • I
      drm/i915: Avoid early GPU idling due to race with new request · 93c97dc1
      由 Imre Deak 提交于 
      There is a small race where a new request can be submitted and retired
after the idle worker started to run which leads to idling the GPU too
early. Fix this by deferring the idling to the pending instance of the
worker.

This scenario was pointed out by Chris.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1478510405-11799-2-git-send-email-imre.deak@intel.com
      93c97dc1
    • I
      drm/i915: Avoid early GPU idling due to already pending idle work · 5bd11a34
      由 Imre Deak 提交于 
      Atm, in case an idle work handler is already pending but haven't yet
started to run, retiring a new request will not extend the active period
as required, rather simply leaves the pending idle work to be scheduled
at the original expiration time. This may lead to idling the GPU too
early. Fix this by using the delayed-work scheduler alternative which
makes sure the handler's expiration time is extended in this case.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Requested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1478510405-11799-1-git-send-email-imre.deak@intel.com
      5bd11a34
    • C
      drm/i915: Limit Valleyview and earlier to only using mappable scanout · 767a222e
      由 Chris Wilson 提交于 
      Valleyview appears to be limited to only scanning out from the first 512MiB
of the Global GTT. Lets presume that this behaviour was inherited from the
display block copied from g4x (not Ironlake) and all earlier generations
are similarly affected, though testing suggests different symptoms. For
simplicity, impose that these platforms must scanout from the mappable
region. (For extra simplicity, use HAS_GMCH_DISPLAY even though this
catches Cherryview which does not appear to be limited to the low
aperture for its scanout.)

v2: Use HAS_GMCH_DISPLAY() to more clearly convey my intent about
limiting this workaround to the old style of display engine.

v3: Update changelog to reflect testing by Ville Syrjälä
v4: Include the changes to the comments as well
Reported-by: NLuis Botello <luis.botello.ortega@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98036
Fixes: 2efb813d ("drm/i915: Fallback to using unmappable memory for scanout")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Akash Goel <akash.goel@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.9-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20161107110128.28762-1-chris@chris-wilson.co.uk
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com
      767a222e
    • C
      drm/i915: Round tile chunks up for constructing partial VMAs · 0ef723cb
      由 Chris Wilson 提交于 
      When we split a large object up into chunks for GTT faulting (because we
can't fit the whole object into the aperture) we have to align our cuts
with the fence registers. Each partial VMA must cover a complete set of
tile rows or the offset into each partial VMA is not aligned with the
whole image. Currently we enforce a minimum size on each partial VMA,
but this minimum size itself was not aligned to the tile row causing
distortion.
Reported-by: NAndreas Reis <andreas.reis@gmail.com>
Reported-by: NChris Clayton <chris2553@googlemail.com>
Reported-by: NNorbert Preining <preining@logic.at>
Tested-by: NNorbert Preining <preining@logic.at>
Tested-by: NChris Clayton <chris2553@googlemail.com>
Fixes: 03af84fe ("drm/i915: Choose partial chunksize based on tile row size")
Fixes: a61007a8 ("drm/i915: Fix partial GGTT faulting") # enabling patch
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98402
Testcase: igt/gem_mmap_gtt/medium-copy-odd
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.9-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20161107105443.27855-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      0ef723cb
    • C
      drm/i915: Remove the vma from the object list upon close · dfd2812e
      由 Chris Wilson 提交于 
      Currently, the vma is being unlink from the object lookup on destroy.
However, we are meant to be decoupling it upon close so that the user
cannot access the closed vma whilst it remains active on the GPU.

[   34.074858] kernel BUG at drivers/gpu/drm/i915/i915_gem_gtt.c:3561!
[   34.074875] invalid opcode: 0000 [#1] PREEMPT SMP
[   34.074888] Modules linked in: snd_hda_intel i915 x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel lpc_ich mei_me mei snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_codec snd_hwdep snd_hda_core i2c_designware_platform i2c_designware_core snd_pcm e1000e ptp pps_core sdhci_acpi sdhci mmc_core i2c_hid [last unloaded: i915]
[   34.075010] CPU: 1 PID: 6224 Comm: gem_close_race Tainted: G     U          4.9.0-rc3-CI-CI_DRM_1800+ #1
[   34.075034] Hardware name:                  /NUC5i7RYB, BIOS RYBDWi35.86A.0355.2016.0224.1501 02/24/2016
[   34.075057] task: ffff8802459a8040 task.stack: ffffc90000524000
[   34.075074] RIP: 0010:[<ffffffffa0392cbc>]  [<ffffffffa0392cbc>] i915_gem_obj_lookup_or_create_vma+0x8c/0xc0 [i915]
[   34.075118] RSP: 0018:ffffc90000527b68  EFLAGS: 00010202
[   34.075135] RAX: ffff8802426c5e40 RBX: 0000000000000000 RCX: ffff8802447fc2a8
[   34.075158] RDX: 0000000000000000 RSI: ffff8802447fc2a8 RDI: ffff880248a4a880
[   34.075181] RBP: ffffc90000527b88 R08: 0000000000000008 R09: 0000000000000000
[   34.075203] R10: 0000000000000001 R11: 0000000000000000 R12: ffff880248a4a880
[   34.075225] R13: ffff8802447fc2a8 R14: ffff880243e9afa8 R15: ffff880248a4a9c8
[   34.075248] FS:  00007f9b43e59740(0000) GS:ffff880256c80000(0000) knlGS:0000000000000000
[   34.075273] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   34.075292] CR2: 00007f9b43419140 CR3: 000000024455d000 CR4: 00000000003406e0
[   34.075314] Stack:
[   34.075323]  0000000000000000 ffffc90000527bd0 ffff880243cb8008 ffff880243e9afa8
[   34.075353]  ffffc90000527c08 ffffffffa03874c7 ffffc90000527bb8 ffff880243e9afa8
[   34.075383]  ffff880243e9afb0 ffffc90000527e10 ffff8802447fc2a8 ffff880243cb8040
[   34.075414] Call Trace:
[   34.075435]  [<ffffffffa03874c7>] eb_lookup_vmas.isra.7+0x247/0x330 [i915]
[   34.075468]  [<ffffffffa0388c34>] i915_gem_do_execbuffer.isra.15+0x604/0x1a10 [i915]
[   34.075507]  [<ffffffffa039c957>] ? i915_gem_object_get_sg+0x347/0x380 [i915]
[   34.075532]  [<ffffffff811a69ce>] ? __might_fault+0x3e/0x90
[   34.075562]  [<ffffffffa038a430>] i915_gem_execbuffer2+0xc0/0x250 [i915]
[   34.075585]  [<ffffffff81552926>] drm_ioctl+0x1f6/0x480
[   34.075604]  [<ffffffff8100107a>] ? trace_hardirqs_on_thunk+0x1a/0x1c
[   34.075635]  [<ffffffffa038a370>] ? i915_gem_execbuffer+0x330/0x330 [i915]
[   34.075658]  [<ffffffff81202d2e>] do_vfs_ioctl+0x8e/0x690
[   34.075677]  [<ffffffff8181582d>] ? _raw_spin_unlock_irqrestore+0x3d/0x60
[   34.075700]  [<ffffffff810fcd51>] ? SyS_timer_settime+0x141/0x1e0
[   34.075721]  [<ffffffff810d6de2>] ? trace_hardirqs_on_caller+0x122/0x1b0
[   34.075742]  [<ffffffff8120336c>] SyS_ioctl+0x3c/0x70
[   34.075760]  [<ffffffff8181602e>] entry_SYSCALL_64_fastpath+0x1c/0xb1
[   34.075781] Code: 44 a0 48 c7 c2 9a 7e 43 a0 be e0 0d 00 00 48 c7 c7 a0 45 44 a0 e8 55 b8 ce e0 48 85 db 74 a3 49 83 bd f8 03 00 00 00 74 99 0f 0b <0f> 0b 48 89 da 4c 89 ee 4c 89 e7 e8 04 a9 ff ff 48 89 da 49 89
[   34.075955] RIP  [<ffffffffa0392cbc>] i915_gem_obj_lookup_or_create_vma+0x8c/0xc0 [i915]
[   34.075994]  RSP <ffffc90000527b68>

Testcase: igt/gem_close_race/basic-threads
Fixes: db6c2b41 ("drm/i915: Store the vma in an rbtree...")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161104161241.25871-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      dfd2812e
  5. 05 11月, 2016 2 次提交
    • L
      drm/i915: Reinit polling before hpd when resuming · e0b70061
      由 Lyude 提交于 
      Now that we don't run the connector reprobing from i915_drm_resume(), we
need to make it so we don't have to wait for reprobing to finish so that
we actually speed things up. In order to do this, we need to make sure
that i915_drm_resume() doesn't get blocked by i915_hpd_poll_init_work()
while trying to acquire the mode_config lock that
drm_kms_helper_poll_enable() needs to acquire.

The easiest way to do this is to just enable polling before hpd. This
shouldn't break anything since at that point we have everything else we
need for polling enabled.

As well, this should result in a rather significant improvement in how
quickly we can resume the system.
Signed-off-by: NLyude <lyude@redhat.com>
Tested-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915
      e0b70061
    • L
      drm/i915: Remove redundant reprobe in i915_drm_resume · f97f1936
      由 Lyude 提交于 
      Weine's investigation on benchmarking the suspend/resume process pointed
out a lot of the time in suspend/resume is being spent reprobing. While
the reprobing process is a lengthy one for good reason, we don't need to
hold up the entire suspend/resume process while we wait for it to
finish. Luckily as it turns out, we already trigger a full connector
reprobe in i915_hpd_poll_init_work(), so we can just ditch reprobing in
i915_drm_resume() entirely.

This won't lead to less time spent resuming just yet since now the
bottleneck will be waiting for the mode_config lock in
drm_kms_helper_poll_enable(), since that will be held as long as
i915_hpd_poll_init_work() is reprobing all of the connectors. But we'll
address that in the next patch.
Signed-off-by: NLyude <lyude@redhat.com>
Tested-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: NDavid Weinehall <david.weinehall@linux.intel.com>
Testcase: analyze_suspend.py -config config/suspend-callgraph.cfg -filter i915
      f97f1936
  7. 04 11月, 2016 5 次提交
  9. 03 11月, 2016 2 次提交
  11. 02 11月, 2016 7 次提交
  13. 01 11月, 2016 10 次提交