1. 03 Dec, 2019 6 commits
    • Matt Roper's avatar
      drm/i915/irq: Refactor gen11 display interrupt handling · a3265d85
      Matt Roper authored
      Let's move handling and reset for gen11 display IRQs to their own
      functions, similar to how we deal with GT interrupts.  This will make
      the top-level functions a bit easier to read and potentially make things
      easier to deal with in the future if new platforms wind up needing
      different display handling logic.
      
      Cc: Lucas De Marchi <lucas.demarchi@intel.com>
      Signed-off-by: default avatarMatt Roper <matthew.d.roper@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191202171608.3361125-1-matthew.d.roper@intel.comReviewed-by: default avatarRadhakrishna Sripada <radhakrishna.sripada@intel.com>
      a3265d85
    • Chris Wilson's avatar
      drm/i915/gt: Track the context validity explicitly · f70de8d2
      Chris Wilson authored
      Rather than assume if and only if the engine->default_state is not set
      that the context is invalid, instead track when we know the context has
      valid state -- either because we have copied the default_state or we
      have completed a context switch to save the HW state.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Acked-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191203124155.3019926-1-chris@chris-wilson.co.uk
      f70de8d2
    • Chris Wilson's avatar
      drm/i915/execlists: Skip nested spinlock for validating pending · 49e74c8f
      Chris Wilson authored
      Only along the submission path can we guarantee that the locked request
      is indeed from a foreign engine, and so the nesting of engine/rq is
      permissible. On the submission tasklet (process_csb()), we may find
      ourselves competing with the normal nesting of rq/engine, invalidating
      our nesting. As we only use the spinlock for debug purposes, skip the
      debug if we cannot acquire the spinlock for safe validation - catching
      99% of the bugs is better than causing a hard lockup.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Fixes: c95d31c3 ("drm/i915/execlists: Lock the request while validating it during promotion")
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191203152631.3107653-2-chris@chris-wilson.co.uk
      49e74c8f
    • Chris Wilson's avatar
      drm/i915/execlists: Add a couple more validity checks to assert_pending() · 80aac91b
      Chris Wilson authored
      Check the pending request submission is valid: that it at least has a
      reference for the submission and that the request is on the active list.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191203152631.3107653-1-chris@chris-wilson.co.uk
      80aac91b
    • Chris Wilson's avatar
      drm/i915: Lift i915_vma_pin() out of intel_renderstate_emit() · 42d10511
      Chris Wilson authored
      Once inside a request, inside the timeline->mutex, pinning is verboten.
      
      <4> [896.032829] ======================================================
      <4> [896.032831] WARNING: possible circular locking dependency detected
      <4> [896.032835] 5.4.0-rc8-CI-Patchwork_15533+ #1 Tainted: G     U
      <4> [896.032838] ------------------------------------------------------
      <4> [896.032841] gem_exec_parall/3720 is trying to acquire lock:
      <4> [896.032844] ffff888401863270 (&kernel#2){+.+.}, at: i915_request_create+0x16/0x1c0 [i915]
      <4> [896.032915]
      but task is already holding lock:
      <4> [896.032917] ffff8883ec1c93c0 (&vm->mutex){+.+.}, at: i915_vma_pin+0xf3/0x11c0 [i915]
      <4> [896.032952]
      which lock already depends on the new lock.
      
      <4> [896.032954]
      the existing dependency chain (in reverse order) is:
      <4> [896.032956]
      -> #1 (&vm->mutex){+.+.}:
      <4> [896.032961]        __mutex_lock+0x9a/0x9d0
      <4> [896.032995]        i915_vma_pin+0xf3/0x11c0 [i915]
      <4> [896.033033]        intel_renderstate_emit+0xb9/0x9e0 [i915]
      <4> [896.033081]        i915_gem_init+0x5a9/0xa50 [i915]
      <4> [896.033112]        i915_driver_probe+0xb00/0x15f0 [i915]
      <4> [896.033144]        i915_pci_probe+0x43/0x1c0 [i915]
      <4> [896.033149]        pci_device_probe+0x9e/0x120
      <4> [896.033154]        really_probe+0xea/0x420
      <4> [896.033158]        driver_probe_device+0x10b/0x120
      <4> [896.033161]        device_driver_attach+0x4a/0x50
      <4> [896.033164]        __driver_attach+0x97/0x130
      <4> [896.033168]        bus_for_each_dev+0x74/0xc0
      <4> [896.033171]        bus_add_driver+0x142/0x220
      <4> [896.033174]        driver_register+0x56/0xf0
      <4> [896.033178]        do_one_initcall+0x58/0x2ff
      <4> [896.033183]        do_init_module+0x56/0x1f8
      <4> [896.033187]        load_module+0x243e/0x29f0
      <4> [896.033190]        __do_sys_finit_module+0xe9/0x110
      <4> [896.033194]        do_syscall_64+0x4f/0x210
      <4> [896.033197]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4> [896.033200]
      -> #0 (&kernel#2){+.+.}:
      <4> [896.033206]        __lock_acquire+0x1328/0x15d0
      <4> [896.033209]        lock_acquire+0xa7/0x1c0
      <4> [896.033213]        __mutex_lock+0x9a/0x9d0
      <4> [896.033255]        i915_request_create+0x16/0x1c0 [i915]
      <4> [896.033287]        intel_engine_flush_barriers+0x4c/0x100 [i915]
      <4> [896.033327]        ggtt_flush+0x37/0x60 [i915]
      <4> [896.033366]        i915_gem_evict_something+0x46b/0x5a0 [i915]
      <4> [896.033407]        i915_gem_gtt_insert+0x21d/0x6a0 [i915]
      <4> [896.033449]        i915_vma_pin+0xb36/0x11c0 [i915]
      <4> [896.033488]        gen6_ppgtt_pin+0xd5/0x170 [i915]
      <4> [896.033523]        ring_context_pin+0x2e/0xc0 [i915]
      <4> [896.033554]        __intel_context_do_pin+0x6b/0x190 [i915]
      <4> [896.033591]        i915_gem_do_execbuffer+0x1814/0x26c0 [i915]
      <4> [896.033627]        i915_gem_execbuffer2_ioctl+0x11b/0x460 [i915]
      <4> [896.033632]        drm_ioctl_kernel+0xa7/0xf0
      <4> [896.033635]        drm_ioctl+0x2e1/0x390
      <4> [896.033638]        do_vfs_ioctl+0xa0/0x6f0
      <4> [896.033641]        ksys_ioctl+0x35/0x60
      <4> [896.033644]        __x64_sys_ioctl+0x11/0x20
      <4> [896.033647]        do_syscall_64+0x4f/0x210
      <4> [896.033650]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Lift the object allocation and pin prior to the request construction.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191202204316.2665847-1-chris@chris-wilson.co.uk
      42d10511
    • Chris Wilson's avatar
      drm/i915/gem: Take runtime-pm wakeref prior to unbinding · 3e817471
      Chris Wilson authored
      Some machines require ACPI for runtime resume, and ACPI is quite kmalloc
      happy. We cannot handle kmalloc from inside the vm->mutex, as they are
      used by the shrinker, and so we must ensure the global runtime-pm is
      awake prior to unbinding to avoid the potential inversion.
      
      <4> [57.121748] ======================================================
      <4> [57.121750] WARNING: possible circular locking dependency detected
      <4> [57.121753] 5.4.0-rc8-CI-CI_DRM_7466+ #1 Tainted: G     U
      <4> [57.121754] ------------------------------------------------------
      <4> [57.121756] i915_pm_rpm/1105 is trying to acquire lock:
      <4> [57.121758] ffffffff82263a40 (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.117+0x0/0x30
      <4> [57.121766]
      but task is already holding lock:
      <4> [57.121768] ffff888475a593c0 (&vm->mutex){+.+.}, at: i915_vma_unbind+0x21/0x50 [i915]
      <4> [57.121868]
      which lock already depends on the new lock.
      
      <4> [57.121869]
      the existing dependency chain (in reverse order) is:
      <4> [57.121871]
      -> #1 (&vm->mutex){+.+.}:
      <4> [57.121951]        i915_gem_shrinker_taints_mutex+0xa2/0xd0 [i915]
      <4> [57.122028]        i915_address_space_init+0xa9/0x170 [i915]
      <4> [57.122104]        i915_ggtt_init_hw+0x47/0x130 [i915]
      <4> [57.122150]        i915_driver_probe+0xbb4/0x15f0 [i915]
      <4> [57.122197]        i915_pci_probe+0x43/0x1c0 [i915]
      <4> [57.122202]        pci_device_probe+0x9e/0x120
      <4> [57.122206]        really_probe+0xea/0x420
      <4> [57.122209]        driver_probe_device+0x10b/0x120
      <4> [57.122212]        device_driver_attach+0x4a/0x50
      <4> [57.122214]        __driver_attach+0x97/0x130
      <4> [57.122217]        bus_for_each_dev+0x74/0xc0
      <4> [57.122220]        bus_add_driver+0x142/0x220
      <4> [57.122222]        driver_register+0x56/0xf0
      <4> [57.122226]        do_one_initcall+0x58/0x2ff
      <4> [57.122230]        do_init_module+0x56/0x1f8
      <4> [57.122233]        load_module+0x243e/0x29f0
      <4> [57.122236]        __do_sys_finit_module+0xe9/0x110
      <4> [57.122239]        do_syscall_64+0x4f/0x210
      <4> [57.122242]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4> [57.122244]
      -> #0 (fs_reclaim){+.+.}:
      <4> [57.122249]        __lock_acquire+0x1328/0x15d0
      <4> [57.122251]        lock_acquire+0xa7/0x1c0
      <4> [57.122254]        fs_reclaim_acquire.part.117+0x24/0x30
      <4> [57.122257]        __kmalloc+0x48/0x320
      <4> [57.122261]        acpi_ns_internalize_name+0x44/0x9b
      <4> [57.122264]        acpi_ns_get_node_unlocked+0x6b/0xd3
      <4> [57.122267]        acpi_ns_get_node+0x3b/0x50
      <4> [57.122271]        acpi_get_handle+0x8a/0xb4
      <4> [57.122274]        acpi_has_method+0x1c/0x40
      <4> [57.122278]        acpi_pci_set_power_state+0x40/0xe0
      <4> [57.122281]        pci_platform_power_transition+0x3e/0x90
      <4> [57.122284]        pci_set_power_state+0x83/0xf0
      <4> [57.122287]        pci_restore_standard_config+0x22/0x40
      <4> [57.122289]        pci_pm_runtime_resume+0x23/0xc0
      <4> [57.122293]        __rpm_callback+0xb1/0x110
      <4> [57.122296]        rpm_callback+0x1a/0x70
      <4> [57.122299]        rpm_resume+0x50e/0x790
      <4> [57.122302]        __pm_runtime_resume+0x42/0x80
      <4> [57.122357]        __intel_runtime_pm_get+0x15/0x60 [i915]
      <4> [57.122435]        ggtt_unbind_vma+0x24/0x60 [i915]
      <4> [57.122514]        __i915_vma_unbind.part.39+0xb5/0x500 [i915]
      <4> [57.122593]        i915_vma_unbind+0x2d/0x50 [i915]
      <4> [57.122668]        i915_gem_object_unbind+0x11c/0x260 [i915]
      <4> [57.122740]        i915_gem_object_set_cache_level+0x32/0x90 [i915]
      <4> [57.122810]        i915_gem_set_caching_ioctl+0x1f7/0x2f0 [i915]
      <4> [57.122815]        drm_ioctl_kernel+0xa7/0xf0
      <4> [57.122818]        drm_ioctl+0x2e1/0x390
      <4> [57.122822]        do_vfs_ioctl+0xa0/0x6f0
      <4> [57.122825]        ksys_ioctl+0x35/0x60
      <4> [57.122828]        __x64_sys_ioctl+0x11/0x20
      <4> [57.122830]        do_syscall_64+0x4f/0x210
      <4> [57.122833]        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
      Closes: https://gitlab.freedesktop.org/drm/intel/issues/711Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMatthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191203101347.2836057-1-chris@chris-wilson.co.uk
      3e817471
  2. 02 Dec, 2019 29 commits
  3. 01 Dec, 2019 1 commit
  4. 30 Nov, 2019 4 commits