Skip to content

L
linux
Switch branch/tag
  1. 04 Dec, 2019 6 commits
  3. 03 Dec, 2019 11 commits
    • Chris Wilson's avatar
      drm/i915/gt: Set the PD again for Haswell · 13bb5b99
      Chris Wilson authored 
      And Haswell still occasionally forgets it is meant to be using a new
page directory, so repeat ourselves a little louder.

<7> [509.919864] heartbeat rcs0 heartbeat {prio:-2147483645} not ticking
<7> [509.919895] heartbeat 	Awake? 8
<7> [509.919903] heartbeat 	Barriers?: no
<7> [509.919912] heartbeat 	Heartbeat: 3008 ms ago
<7> [509.919930] heartbeat 	Reset count: 0 (global 0)
<7> [509.919937] heartbeat 	Requests:
<7> [509.921008] heartbeat 		active  a7eb:56e1*  @ 5847ms:
<7> [509.921157] heartbeat 		ring->start:  0x00001000
<7> [509.921164] heartbeat 		ring->head:   0x00001610
<7> [509.921170] heartbeat 		ring->tail:   0x000023d8
<7> [509.921176] heartbeat 		ring->emit:   0x000023d8
<7> [509.921182] heartbeat 		ring->space:  0x00002570
<7> [509.921189] heartbeat 		ring->hwsp:   0x7fffe100
<7> [509.921197] heartbeat [head 1628, postfix 1738, tail 1750, batch 0xffffffff_ffffffff]:
<7> [509.921289] heartbeat [0000] 7a000002 00100002 00000000 00000000 7a000002 01154c1e 7ffff080 00000000
<7> [509.921299] heartbeat [0020] 11000001 00002220 ffffffff 12400001 00002220 7ffff000 00000000 11000001
<7> [509.921308] heartbeat [0040] 00002228 6e900000 7a000002 00100002 00000000 00000000 7a000002 01154c1e
<7> [509.921317] heartbeat [0060] 7ffff080 00000000 12400001 00002228 7ffff000 00000000 7a000002 00100002
<7> [509.921326] heartbeat [0080] 00000000 00000000 7a000002 01154c1e 7ffff080 00000000 7a000002 001010a1
<7> [509.921335] heartbeat [00a0] 7ffff080 00000000 04000000 11000005 00022050 00010001 00012050 00010001
<7> [509.921345] heartbeat [00c0] 0001a050 00010001 00000000 0c000000 459a110c 00000000 11000005 00022050
<7> [509.921354] heartbeat [00e0] 00010000 00012050 00010000 0001a050 00010000 12400001 0001a050 7ffff000
<7> [509.921363] heartbeat [0100] 00000000 04000001 18802100 00000000 7a000002 011050a1 7fffe100 000056e1
<7> [509.921370] heartbeat [0120] 01000000 00000000
<7> [509.921538] heartbeat 	MMIO base:  0x00002000
<7> [509.921682] heartbeat 	CCID: 0x3fa0110d
<7> [509.922342] heartbeat 	RING_START: 0x00001000
<7> [509.922353] heartbeat 	RING_HEAD:  0x00001628
<7> [509.922366] heartbeat 	RING_TAIL:  0x000023d8
<7> [509.922381] heartbeat 	RING_CTL:   0x00003001
<7> [509.922396] heartbeat 	RING_MODE:  0x00004000
<7> [509.922408] heartbeat 	RING_IMR: ffffffde
<7> [509.922421] heartbeat 	ACTHD:  0x00000000_30e01628
<7> [509.922434] heartbeat 	BBADDR: 0x00000000_00004004
<7> [509.922446] heartbeat 	DMA_FADDR: 0x00000000_00002800
<7> [509.922458] heartbeat 	IPEIR: 0x00000000
<7> [509.922470] heartbeat 	IPEHR: 0x780c0000
<7> [509.922642] heartbeat 	PP_DIR_BASE: 0x6e700000
<7> [509.922652] heartbeat 	PP_DIR_BASE_READ: 0x00000000
<7> [509.922662] heartbeat 	PP_DIR_DCLV: 0xffffffff
<7> [509.922678] heartbeat 		E  a7eb:56e1*  @ 5849ms:
<7> [509.922689] heartbeat 		E  a7eb:56e2-  @ 5849ms:
<7> [509.922698] heartbeat 		E  a7eb:56e3  @ 5848ms:
<7> [509.922707] heartbeat 		E  a7eb:56e4  @ 5848ms:
<7> [509.922715] heartbeat 		E  a7eb:56e5  @ 5847ms:
<7> [509.922724] heartbeat 		E  a7eb:56e6  @ 5846ms:
<7> [509.922735] heartbeat 		E  a7eb:56e7  @ 5846ms:
<7> [509.922744] heartbeat 		...skipping 4 executing requests...
<7> [509.922754] heartbeat 		E  a7eb:56ec  @ 3010ms:
<7> [509.922796] heartbeat HWSP:
<7> [509.922807] heartbeat [0000] 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [509.922817] heartbeat [0020] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [509.922826] heartbeat *
<7> [509.922836] heartbeat [0100] 000056e0 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [509.922845] heartbeat [0120] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<7> [509.922851] heartbeat *
<7> [509.922870] heartbeat Idle? no
<7> [509.922878] heartbeat Signals:
<7> [509.923000] heartbeat 	[a7eb:56e2] @ 5850ms

Here, we have a failed context restore after the PD switch, but note
that the PP_DIR_BASE register does not match the LRI in the ring.

Bump it to 8^W 4 loops, and with that Baytrail starts passing the sanity
checks.
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/20191203211631.3167430-1-chris@chris-wilson.co.uk
      13bb5b99
    • Chris Wilson's avatar
      drm/i915/gem: Avoid parking the vma as we unbind · cb6c3d45
      Chris Wilson authored 
      In order to avoid keeping a reference on the i915_vma (which is long
overdue!) we have to coordinate all the possible lifetimes and only use
the vma while we know it is alive. In this episode, we are reminded that
while idle, the closed vma are destroyed. So if the GT idles while we are
working with the vma, the vma itself becomes invalid.

First class i915_vma here we come, but in the meantime keep piling on
the straw.
Signed-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/20191203155032.3137263-1-chris@chris-wilson.co.uk
      cb6c3d45
    • José Roberto de Souza's avatar
      drm/i915/display/mst: Move DPMS_OFF call to post_disable · 78eaaba3
      José Roberto de Souza authored 
      Moving just to simplify handling as there is no change in behavior.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202222513.337777-3-jose.souza@intel.com
      78eaaba3
    • José Roberto de Souza's avatar
      drm/i915/dp: Power down sink before disable pipe/transcoder clock · 50a7efb2
      José Roberto de Souza authored 
      Disabling pipe/transcoder clock before power down sink could cause
sink lost signal, causing it to trigger a hotplug to notify source
that link signal was lost.

Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202222513.337777-2-jose.souza@intel.com
      50a7efb2
    • José Roberto de Souza's avatar
      drm/i915/display: Check the old state to find port sync slave · e815aff5
      José Roberto de Souza authored 
      If the CRTC is going from enabled to disabled and it is a port sync
slave, it needs to check to the old state to be disabled before the
port sync master.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: default avatarJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191202222513.337777-1-jose.souza@intel.com
      e815aff5
    • 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
  5. 02 Dec, 2019 23 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7