1. 14 12月, 2017 3 次提交
    • M
      drm/i915/guc: Move GuC workqueue allocations outside of the mutex · 3176ff49
      Michał Winiarski 提交于
      This gets rid of the following lockdep splat:
      
      ======================================================
      WARNING: possible circular locking dependency detected
      4.15.0-rc2-CI-Patchwork_7428+ #1 Not tainted
      ------------------------------------------------------
      debugfs_test/1351 is trying to acquire lock:
       (&dev->struct_mutex){+.+.}, at: [<000000009d90d1a3>] i915_mutex_lock_interruptible+0x47/0x130 [i915]
      
      but task is already holding lock:
       (&mm->mmap_sem){++++}, at: [<000000005df01c1e>] __do_page_fault+0x106/0x560
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #6 (&mm->mmap_sem){++++}:
             __might_fault+0x63/0x90
             _copy_to_user+0x1e/0x70
             filldir+0x8c/0xf0
             dcache_readdir+0xeb/0x160
             iterate_dir+0xe6/0x150
             SyS_getdents+0xa0/0x130
             entry_SYSCALL_64_fastpath+0x1c/0x89
      
      -> #5 (&sb->s_type->i_mutex_key#5){++++}:
             lockref_get+0x9/0x20
      
      -> #4 ((completion)&req.done){+.+.}:
             wait_for_common+0x54/0x210
             devtmpfs_create_node+0x130/0x150
             device_add+0x5ad/0x5e0
             device_create_groups_vargs+0xd4/0xe0
             device_create+0x35/0x40
             msr_device_create+0x22/0x40
             cpuhp_invoke_callback+0xc5/0xbf0
             cpuhp_thread_fun+0x167/0x210
             smpboot_thread_fn+0x17f/0x270
             kthread+0x173/0x1b0
             ret_from_fork+0x24/0x30
      
      -> #3 (cpuhp_state-up){+.+.}:
             cpuhp_issue_call+0x132/0x1c0
             __cpuhp_setup_state_cpuslocked+0x12f/0x2a0
             __cpuhp_setup_state+0x3a/0x50
             page_writeback_init+0x3a/0x5c
             start_kernel+0x393/0x3e2
             secondary_startup_64+0xa5/0xb0
      
      -> #2 (cpuhp_state_mutex){+.+.}:
             __mutex_lock+0x81/0x9b0
             __cpuhp_setup_state_cpuslocked+0x4b/0x2a0
             __cpuhp_setup_state+0x3a/0x50
             page_alloc_init+0x1f/0x26
             start_kernel+0x139/0x3e2
             secondary_startup_64+0xa5/0xb0
      
      -> #1 (cpu_hotplug_lock.rw_sem){++++}:
             cpus_read_lock+0x34/0xa0
             apply_workqueue_attrs+0xd/0x40
             __alloc_workqueue_key+0x2c7/0x4e1
             intel_guc_submission_init+0x10c/0x650 [i915]
             intel_uc_init_hw+0x29e/0x460 [i915]
             i915_gem_init_hw+0xca/0x290 [i915]
             i915_gem_init+0x115/0x3a0 [i915]
             i915_driver_load+0x9a8/0x16c0 [i915]
             i915_pci_probe+0x2e/0x90 [i915]
             pci_device_probe+0x9c/0x120
             driver_probe_device+0x2a3/0x480
             __driver_attach+0xd9/0xe0
             bus_for_each_dev+0x57/0x90
             bus_add_driver+0x168/0x260
             driver_register+0x52/0xc0
             do_one_initcall+0x39/0x150
             do_init_module+0x56/0x1ef
             load_module+0x231c/0x2d70
             SyS_finit_module+0xa5/0xe0
             entry_SYSCALL_64_fastpath+0x1c/0x89
      
      -> #0 (&dev->struct_mutex){+.+.}:
             lock_acquire+0xaf/0x200
             __mutex_lock+0x81/0x9b0
             i915_mutex_lock_interruptible+0x47/0x130 [i915]
             i915_gem_fault+0x201/0x760 [i915]
             __do_fault+0x15/0x70
             __handle_mm_fault+0x85b/0xe40
             handle_mm_fault+0x14f/0x2f0
             __do_page_fault+0x2d1/0x560
             page_fault+0x22/0x30
      
      other info that might help us debug this:
      
      Chain exists of:
        &dev->struct_mutex --> &sb->s_type->i_mutex_key#5 --> &mm->mmap_sem
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&mm->mmap_sem);
                                     lock(&sb->s_type->i_mutex_key#5);
                                     lock(&mm->mmap_sem);
        lock(&dev->struct_mutex);
      
       *** DEADLOCK ***
      
      1 lock held by debugfs_test/1351:
       #0:  (&mm->mmap_sem){++++}, at: [<000000005df01c1e>] __do_page_fault+0x106/0x560
      
      stack backtrace:
      CPU: 2 PID: 1351 Comm: debugfs_test Not tainted 4.15.0-rc2-CI-Patchwork_7428+ #1
      Hardware name:                  /NUC6i5SYB, BIOS SYSKLi35.86A.0057.2017.0119.1758 01/19/2017
      Call Trace:
       dump_stack+0x5f/0x86
       print_circular_bug+0x230/0x3b0
       check_prev_add+0x439/0x7b0
       ? lockdep_init_map_crosslock+0x20/0x20
       ? unwind_get_return_address+0x16/0x30
       ? __lock_acquire+0x1385/0x15a0
       __lock_acquire+0x1385/0x15a0
       lock_acquire+0xaf/0x200
       ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
       __mutex_lock+0x81/0x9b0
       ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
       ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
       ? i915_mutex_lock_interruptible+0x47/0x130 [i915]
       i915_mutex_lock_interruptible+0x47/0x130 [i915]
       ? __pm_runtime_resume+0x4f/0x80
       i915_gem_fault+0x201/0x760 [i915]
       __do_fault+0x15/0x70
       __handle_mm_fault+0x85b/0xe40
       handle_mm_fault+0x14f/0x2f0
       __do_page_fault+0x2d1/0x560
       page_fault+0x22/0x30
      RIP: 0033:0x7f98d6f49116
      RSP: 002b:00007ffd6ffc3278 EFLAGS: 00010283
      RAX: 00007f98d39a2bc0 RBX: 0000000000000000 RCX: 0000000000001680
      RDX: 0000000000001680 RSI: 00007ffd6ffc3400 RDI: 00007f98d39a2bc0
      RBP: 00007ffd6ffc33a0 R08: 0000000000000000 R09: 00000000000005a0
      R10: 000055e847c2a830 R11: 0000000000000002 R12: 0000000000000001
      R13: 000055e847c1d040 R14: 00007ffd6ffc3400 R15: 00007f98d6752ba0
      
      v2: Init preempt_work unconditionally (Chris)
      v3: Mention that we need the enable_guc=1 for lockdep splat (Chris)
      
      Testcase: igt/debugfs_test/read_all_entries # with i915.enable_guc=1
      Signed-off-by: NMichał Winiarski <michal.winiarski@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171213221352.7173-2-michal.winiarski@intel.com
      3176ff49
    • M
      drm/i915/guc: Move shared data allocation away from submission path · 1bbbca0d
      Michał Winiarski 提交于
      We need shared data for actions (e.g. guc suspend/resume), and we're
      using those with GuC submission disabled.
      Let's introduce intel_guc_init and move shared data alloc there.
      
      This fixes GPF during module unload with HuC, but without GuC submission:
      
      BUG: unable to handle kernel NULL pointer dereference at 000000005aee7809
      IP: intel_guc_suspend+0x34/0x140 [i915]
      PGD 0 P4D 0
      Oops: 0000 [#1] PREEMPT SMP
      Modules linked in: i915(O-) netconsole x86_pkg_temp_thermal
      intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
      mei_me i2c_i801 mei prime_numbers [last unloaded: i915]
      CPU: 2 PID: 2794 Comm: rmmod Tainted: G     U  W  O 4.15.0-rc2+ #297
      Hardware name: /NUC6i5SYB, BIOS SYSKLi35.86A.0054.2016.0930.1102 09/30/2016
      task: 0000000055945c61 task.stack: 00000000264ccb43
      RIP: 0010:intel_guc_suspend+0x34/0x140 [i915]
      RSP: 0018:ffffc90000483df8 EFLAGS: 00010286
      RAX: 0000000000000000 RBX: ffff880829180000 RCX: 0000000000000000
      RDX: 0000000000000006 RSI: ffff880844c2c938 RDI: ffff880844c2c000
      RBP: ffff880829180000 R08: 00000000a29c58c1 R09: 0000000000000000
      R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa040ba40
      R13: ffffffffa040bab0 R14: ffff88084a195060 R15: 000055df3ef357a0
      FS:  00007ff43c043740(0000) GS:ffff88084e200000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00000000000000f9 CR3: 000000083f179005 CR4: 00000000003606e0
      Call Trace:
       i915_gem_suspend+0x9d/0x130 [i915]
       ? i915_driver_unload+0x68/0x180 [i915]
       i915_driver_unload+0x70/0x180 [i915]
       i915_pci_remove+0x15/0x20 [i915]
       pci_device_remove+0x36/0xb0
       device_release_driver_internal+0x15f/0x220
       driver_detach+0x3a/0x80
       bus_remove_driver+0x58/0xd0
       pci_unregister_driver+0x29/0x90
       SyS_delete_module+0x150/0x1e0
       entry_SYSCALL_64_fastpath+0x23/0x9a
      RIP: 0033:0x7ff43b51b5c7
      RSP: 002b:00007ffe6825a758 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
      RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007ff43b51b5c7
      RDX: 000000000000000a RSI: 0000000000000800 RDI: 000055df3ef35808
      RBP: 0000000000000000 R08: 00007ffe682596d1 R09: 0000000000000000
      R10: 00007ff43b594880 R11: 0000000000000206 R12: 000055df3ef357a0
      R13: 00007ffe68259740 R14: 000055df3ef35260 R15: 000055df3ef357a0
      Code: 00 00 02 74 03 31 c0 c3 53 48 89 fb 48 83 ec 10 e8 52 0f
      f8 ff 48 b8 01 05 00 00 02 00 00 00 48 89 44 24 04 48 8b 83 00 12 00 00 <f6> 80
      f9 00 00 00 01 0f 84 a7 00 00 00 f6 80 98 00 00 00 01 0f
      RIP: intel_guc_suspend+0x34/0x140 [i915] RSP: ffffc90000483df8
      CR2: 00000000000000f9
      ---[ end trace 23a192a61d937a3e ]---
      
      Fixes: b8e5eb96 ("drm/i915/guc: Allocate separate shared data object for GuC communication")
      Signed-off-by: NMichał Winiarski <michal.winiarski@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171213221352.7173-1-michal.winiarski@intel.com
      1bbbca0d
    • C
      drm/i915: Unwind i915_gem_init() failure · 6ca9a2be
      Chris Wilson 提交于
      Since Michal introduced new user controllable errors other than -EIO
      during i915_gem_init(), we need to actually unwind on the error path as
      we have to abort the module load (and we expect to do so cleanly!).
      
      As we now teardown key state and then mark the driver as wedged (on
      EIO), we have to be careful to not allow ourselves to resume and
      unwedge, thus attempting to use the uninitialised driver.
      
      v2: Try not to free driver state for the suppressed EIO
      v3: Use load-fault-injection to test both error/recovery paths.
      
      References: 8620eb1d ("drm/i915/uc: Don't use -EIO to report missing firmware")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
      Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171213134347.4608-1-chris@chris-wilson.co.uk
      6ca9a2be
  2. 13 12月, 2017 9 次提交
    • C
      drm/i915: Ratelimit request allocation under oom · 31c70f97
      Chris Wilson 提交于
      If we fail to allocate a request, we can reap the outstanding requests
      and push them to the request's slab's freelist before trying again. This
      forces us to ratelimit malicious clients that tie up all of the system
      resources in requests, instead of causing a system-wide oom.
      
      Testcase: igt/gem_shrink/execbuf1
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171212180652.22061-3-chris@chris-wilson.co.uk
      31c70f97
    • C
      drm/i915: Allow fence allocations to fail · 2abe2f84
      Chris Wilson 提交于
      If a fence allocation fails in a blocking context, we will sleep on the
      fence as a last resort. We can therefore allow ourselves to fail and
      sleep on the fence instead of triggering a system-wide oom. This allows
      us to throttle malicious clients that are consuming lots of system
      resources by capping the amount of memory used by fences.
      
      Testcase: igt/gem_shrink/execbufX
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171212180652.22061-2-chris@chris-wilson.co.uk
      2abe2f84
    • C
      drm/i915: Mark up potential allocation paths within i915_sw_fence as might_sleep · e30a7581
      Chris Wilson 提交于
      As kmalloc is allowed to block (if given the right flags), mark up the
      two i915_sw_fence routines that may call kmalloc as potential sleeping
      routines.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171212180652.22061-1-chris@chris-wilson.co.uk
      e30a7581
    • C
      drm/i915: Don't check #active_requests from i915_gem_wait_for_idle() · d7dc4131
      Chris Wilson 提交于
      i915_gem_wait_for_idle() is called from inside the shrinker, to ensure
      that we drain the last resources from the GPU in dire circumstances (OOM).
      As we may allocate whilst building a request, it is then possible to hit
      the shrinker with a request under construction, and so we must account
      for the incomplete request whilst waiting. In particular, we
      preincrement (in reserve_engine) the i915->gt.active_requests counter
      and mark the GPU as busy, therefore we can not use that counter for
      shortcircuiting the wait-for-idle.
      
      [  950.859024] GEM_BUG_ON(i915->gt.active_requests)
      [  950.859041] WARNING: CPU: 2 PID: 2178 at drivers/gpu/drm/i915/i915_gem.c:3615 i915_gem_wait_for_idle.part.56+0x166/0x4e0
      [  950.859041] Modules linked in: ccm tun fuse nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_security iptable_raw arc4 iwldvm mac80211 snd_hda_codec_hdmi snd_hda_codec_idt snd_hda_codec_generic snd_hda_intel snd_hda_codec btusb snd_hda_core btrtl btbcm iwlwifi snd_hwdep btintel bluetooth snd_seq snd_seq_device snd_pcm ecdh_generic x86_pkg_temp_thermal tpm_infineon coretemp tpm_tis crc32_pclmul wmi_bmof crc32c_intel iTCO_wdt hp_wmi snd_timer iTCO_vendor_support sparse_keymap tpm_tis_core mei_me cfg80211
      [  950.859082]  snd joydev tpm mei rfkill pcspkr wmi soundcore lpc_ich hp_accel lis3lv02d input_polldev binfmt_misc e1000e ptp serio_raw pps_core
      [  950.859094] CPU: 2 PID: 2178 Comm: gem_exec_nop Tainted: G     U           4.15.0-rc2+ #900
      [  950.859102] Hardware name: Hewlett-Packard HP ProBook 6360b/1620, BIOS 68SCF Ver. B.42 12/29/2010
      [  950.859107] task: c5119cb4 task.stack: f3ccb8d8
      [  950.859112] EIP: i915_gem_wait_for_idle.part.56+0x166/0x4e0
      [  950.859113] EFLAGS: 00010296 CPU: 2
      [  950.859114] EAX: 00000024 EBX: f36c1888 ECX: f777a044 EDX: 00000007
      [  950.859115] ESI: f36c1888 EDI: edd53958 EBP: edd53970 ESP: edd53938
      [  950.859116]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
      [  950.859117] CR0: 80050033 CR2: b7f39000 CR3: 2f2b3000 CR4: 000406d0
      [  950.859118] Call Trace:
      [  950.859125]  ? drm_printk+0x70/0x70
      [  950.859129]  i915_gem_wait_for_idle+0x18/0x30
      [  950.859133]  i915_gem_shrink+0x360/0x410
      [  950.859138]  ? vmpressure+0xa8/0xf0
      [  950.859142]  ? ktime_get+0x4a/0x100
      [  950.859147]  i915_gem_shrink_all+0x21/0x40
      [  950.859151]  i915_gem_shrinker_oom+0x23/0x130
      [  950.859156]  notifier_call_chain+0x4e/0x70
      [  950.859160]  __blocking_notifier_call_chain+0x2f/0x60
      [  950.859164]  blocking_notifier_call_chain+0x11/0x20
      [  950.859169]  out_of_memory+0x207/0x280
      [  950.859174]  __alloc_pages_nodemask+0xd47/0xe60
      [  950.859179]  new_slab+0x32d/0x450
      [  950.859183]  ___slab_alloc.constprop.81+0x358/0x4e0
      [  950.859189]  ? i915_sw_fence_await_dma_fence+0x53/0x160
      [  950.859193]  ? __slab_free+0x1fe/0x310
      [  950.859197]  ? native_sched_clock+0x1e/0xc0
      [  950.859201]  ? i915_gem_request_alloc+0xcf/0x510
      [  950.859205]  ? sched_clock+0x9/0x10
      [  950.859209]  __slab_alloc.constprop.80+0x29/0x40
      [  950.859212]  ? __slab_alloc.constprop.80+0x29/0x40
      [  950.859216]  kmem_cache_alloc_trace+0x160/0x1a0
      [  950.859220]  ? i915_sw_fence_await_dma_fence+0x53/0x160
      [  950.859224]  i915_sw_fence_await_dma_fence+0x53/0x160
      [  950.859229]  i915_gem_request_await_dma_fence+0x1eb/0x390
      [  950.859233]  i915_gem_request_await_object+0xee/0x230
      [  950.859239]  i915_gem_do_execbuffer+0xc16/0x1200
      [  950.859246]  ? irqtime_account_irq+0x3e/0xc0
      [  950.859251]  ? irq_exit+0x4f/0xb0
      [  950.859257]  ? smp_apic_timer_interrupt+0x5f/0x110
      [  950.859261]  ? apic_timer_interrupt+0x35/0x3c
      [  950.859266]  i915_gem_execbuffer2_ioctl+0x212/0x440
      [  950.859270]  ? apic_timer_interrupt+0x35/0x3c
      [  950.859274]  ? i915_gem_do_execbuffer+0x1200/0x1200
      [  950.859279]  ? insn_get_seg_base+0x1b/0x50
      [  950.859283]  ? i915_gem_do_execbuffer+0x1200/0x1200
      [  950.859287]  drm_ioctl_kernel+0x51/0xa0
      [  950.859291]  drm_ioctl+0x2a3/0x350
      [  950.859294]  ? i915_gem_do_execbuffer+0x1200/0x1200
      [  950.859300]  ? sched_clock+0x9/0x10
      [  950.859303]  ? drm_getunique+0x70/0x70
      [  950.859308]  do_vfs_ioctl+0x7d/0x640
      [  950.859311]  ? native_sched_clock+0x1e/0xc0
      [  950.859315]  ? sched_clock+0x9/0x10
      [  950.859319]  ? sched_clock_cpu+0x13/0x120
      [  950.859323]  SyS_ioctl+0x4e/0x80
      [  950.859326]  do_fast_syscall_32+0x75/0x250
      [  950.859331]  ? irq_exit+0x4f/0xb0
      [  950.859334]  entry_SYSENTER_32+0x47/0x71
      [  950.859338] EIP: 0xb7f81d11
      [  950.859339] EFLAGS: 00000296 CPU: 2
      [  950.859340] EAX: ffffffda EBX: 00000003 ECX: 40406469 EDX: bfde4c20
      [  950.859340] ESI: 00000003 EDI: 40406469 EBP: 00000003 ESP: bfde4b38
      [  950.859341]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
      [  950.859343] Code: e8 30 60 01 00 83 c4 10 83 c3 04 39 f3 75 e0 8b 45 d8 8b 80 14 37 00 00 85 c0 74 13 68 dd 33 e4 c0 68 49 6f e3 c0 e8 4a 55 be ff <0f> ff 5e 5f b8 fe ff ff 3f bb 0a 00 00 00 e8 b7 14 c4 ff 8b 15
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171212132148.8124-1-chris@chris-wilson.co.ukReviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      d7dc4131
    • C
      drm/i915/fence: Use rcu to defer freeing of irq_work · 7d622351
      Chris Wilson 提交于
      It is illegal to perform an immediate free of the struct irq_work from
      inside the irq_work callback (as irq_work_run_list modifies work->flags
      after execution of the work->func()). As we use the irq_work to
      coordinate the freeing of the callback from two different softirq paths,
      we need to defer the kfree from inside our irq_work callback, for which
      we can use kfree_rcu.
      
      Fixes: 81c0ed21 ("drm/i915/fence: Avoid del_timer_sync() from inside a timer")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171213094802.28243-1-chris@chris-wilson.co.uk
      7d622351
    • C
      drm/i915: Dump the engine state before declaring wedged from wait_for_engines() · 59e4b19d
      Chris Wilson 提交于
      If wait_for_engines() fails and we resort to declaring the HW wedged,
      dump the engine state for debugging.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171211194135.27095-2-chris@chris-wilson.co.uk
      59e4b19d
    • C
      drm/i915: Bump timeout for wait_for_engines() · ee42c00e
      Chris Wilson 提交于
      Extract the timeout we use in i915_gem_idle_work_handler() and reuse it
      for wait_for_engines() in i915_gem_wait_for_idle(). It too has the same
      problem in sometimes having to wait for an extended period before the HW
      settles, so make use of the same timeout.
      
      References: 5427f207 ("drm/i915: Bump wait-times for the final CS interrupt before parking")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171211194135.27095-1-chris@chris-wilson.co.uk
      ee42c00e
    • C
      drm/i915: Downgrade misleading "Memory usable" message · 1875fe7b
      Chris Wilson 提交于
      It never meant what it said, as it was always the total size of the
      Global GTT and not a limit upon memory usage. Originally it served as a
      quick guide to the largest batch that could be submitted by userspace,
      an approximation to its maximum RSS, but was phrased badly. Today with
      the 48b ppgtt, it is even more meaningless. Replace with a more specific
      debug message; those wanting to know how much "video ram" they have
      should consult the userspace libraries for the relevant approximation.
      
      v2: Rebase
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Matthew Auld <matthew.auld@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171212113532.22574-1-chris@chris-wilson.co.ukReviewed-by: NMatthew Auld <matthew.auld@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      1875fe7b
    • C
      drm/i915: Print an error message for a reset failure on gen2 · 3ef98f50
      Chris Wilson 提交于
      Since on gen2, we do not universally have a GPU reset implementation, we
      fail i915_reset() at intel_has_gpu_reset(). However, this is also
      intentionally disabled for CI testing and so it only has a debug
      message. Promote that debug message to a user-facing error message that
      should explain why their machine became unusable following the GPU hang.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171211204040.22858-1-chris@chris-wilson.co.uk
      3ef98f50
  3. 12 12月, 2017 11 次提交
  4. 11 12月, 2017 5 次提交
  5. 09 12月, 2017 6 次提交
  6. 08 12月, 2017 6 次提交
    • C
      drm/i915: Drop fb reference on load_detect_pipe failure path · 3e72be17
      Chris Wilson 提交于
      When intel_modeset_setup_plane_state() fails drop the local framebuffer
      reference before jumping to the error, otherwise we leak the framebuffer.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Fixes: edde3617 ("drm/i915: Use atomic state to obtain load detection crtc, v3.")
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171207220025.22698-1-chris@chris-wilson.co.uk
      3e72be17
    • D
      intel/atomic: Stop updating legacy fb parameters · 7a1530d7
      Daniel Vetter 提交于
      Even fbc isn't using this stuff anymore, so time to remove it.
      
      Cleaning up one small piece of the atomic conversion cruft at the time
      ...
      
      Quick explanation on why the plane->fb assignment is ok to delete: The
      core code takes care of the refcounting and legacy ->fb pointer
      updating, but drivers are allowed to update it ahead of time. Most
      legacy modeset drivers did that as part of their set_config callback
      (since that's how the legacy/crtc helpers worked). In i915 we only
      need that to make the fbc code happy.
      
      v2: don't nuke the assignement of intel_crtc->config, I accidentally
      set CI ablaze :-) Spotted by Maarten. And better explain why nuking
      the ->fb assignement shouldn't set off alarm bells.
      
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171207143202.6021-1-daniel.vetter@ffwll.ch
      7a1530d7
    • T
      drm/i915: Restore GT performance in headless mode with DMC loaded · b6876374
      Tvrtko Ursulin 提交于
      It seems that the DMC likes to transition between the DC states a lot when
      there are no connected displays (no active power domains) during command
      submission.
      
      This activity on DC states has a negative impact on the performance of the
      chip with huge latencies observed in the interrupt handlers and elsewhere.
      Simple tests like igt/gem_latency -n 0 are slowed down by a factor of
      eight.
      
      Work around it by introducing a new power domain named,
      POWER_DOMAIN_GT_IRQ, associtated with the "DC off" power well, which is
      held for the duration of command submission activity.
      
      CNL has the same problem which will be addressed as a follow-up. Doing
      that requires a fix for a DC6 context corruption problem in the CNL DMC
      firmware which is yet to be released.
      
      v2:
       * Add commit text as comment in i915_gem_mark_busy. (Chris Wilson)
       * Protect macro body with braces. (Jani Nikula)
      
      v3:
       * Add dedicated power domain for clarity. (Chris, Imre)
       * Commit message and comment text updates.
       * Apply to all big-core GEN9 parts apart for Skylake which is pending DMC
         firmware release.
      
      v4:
       * Power domain should be inner to device runtime pm. (Chris)
       * Simplify NEEDS_CSR_GT_PERF_WA macro. (Chris)
       * Handle async DMC loading by moving the GT_IRQ power domain logic into
         intel_runtime_pm. (Daniel, Chris)
       * Include small core GEN9 as well. (Imre)
      
      v5
       * Special handling for async DMC load is not needed since on failure the
         power domain reference is kept permanently taken. (Imre)
      
      v6:
       * Drop the NEEDS_CSR_GT_PERF_WA macro since all firmwares have now been
         deployed. (Imre, Chris)
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
      Testcase: igt/gem_exec_nop/headless
      Cc: Imre Deak <imre.deak@intel.com>
      Acked-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
      Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v5)
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      [Imre: Add note about applying the WA on CNL as a follow-up]
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171205132854.26380-1-tvrtko.ursulin@linux.intel.com
      b6876374
    • C
      drm/i915/execlists: Cache ELSP register offset · 2fc7a06a
      Chris Wilson 提交于
      Currently on every submission, we recalculate the ELSP register offset
      for the engine, after chasing the pointers to find the iomem base. Since
      this is fixed for the lifetime of the driver, record the offset in the
      execlists struct.
      
      In practice the difference is negligible, it just happens to remove 27
      bytes of eyesore pointer dancing from next to the hottest instruction
      (which is itself due to stalling for a cache miss) in perf profiles of
      the execlists_submission_tasklet().
      
      v2: Trim off one more elsp local.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171207222434.17686-1-chris@chris-wilson.co.uk
      2fc7a06a
    • C
      drm/i915: Refactor common list iteration over GGTT vma · e2189dd0
      Chris Wilson 提交于
      In quite a few places, we have a list iteration over the vma on an
      object that only want to inspect GGTT vma. By construction, these are
      placed at the start of the list, so we have copied that knowledge into
      many callsites. Pull that knowledge back to i915_vma.h and provide a
      for_each_ggtt_vma() to tidy up the code.
      
      v2: Add a backreference from vma_create() to remind ourselves why we put
      ggtt vma at the head of the obj->vma_list (and ppgtt vma at the tail).
      v3: Fixup s/vma/V/
      Suggested-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171207211407.31549-1-chris@chris-wilson.co.uk
      e2189dd0
    • D
      Merge tag 'drm-intel-next-2017-12-01' of git://anongit.freedesktop.org/drm/drm-intel into drm-next · 3f1f0b1c
      Dave Airlie 提交于
      [airlied: fix conflict in intel_dsi.c]
      
      drm-intel-next-2017-12-01:
      
      - Init clock gate fix (Ville)
      - Execlists event handling corrections (Chris, Michel)
      - Improvements on GPU Cache invalidation and context switch (Chris)
      - More perf OA changes (Lionel)
      - More selftests improvements and fixes (Chris, Matthew)
      - Clean-up on modules parameters (Chris)
      - Clean-up around old ringbuffer submission and hw semaphore on old platforms (Chris)
      - More Cannonlake stabilization effort (David, James)
      - Display planes clean-up and improvements (Ville)
      - New PMU interface for perf queries... (Tvrtko)
      - ... and other subsequent PMU changes and fixes (Tvrtko, Chris)
      - Remove success dmesg noise from rotation (Chris)
      - New DMC for Kabylake (Anusha)
      - Fixes around atomic commits (Daniel)
      - GuC updates and fixes (Sagar, Michal, Chris)
      - Couple gmbus/i2c fixes (Ville)
      - Use exponential backoff for all our wait_for() (Chris)
      - Fixes for i915/fbdev (Chris)
      - Backlight fixes (Arnd)
      - Updates on shrinker (Chris)
      - Make Hotplug enable more robuts (Chris)
      - Disable huge pages (TPH) on lack of a needed workaround (Joonas)
      - New GuC images for SKL, KBL, BXT (Sagar)
      - Add HW Workaround for Geminilake performance (Valtteri)
      - Fixes for PPS timings (Imre)
      - More IPS fixes (Maarten)
      - Many fixes for Display Port on gen2-gen4 (Ville)
      - Retry GPU reset making the recover from hang more robust (Chris)
      
      * tag 'drm-intel-next-2017-12-01' of git://anongit.freedesktop.org/drm/drm-intel: (101 commits)
        drm/i915: Update DRIVER_DATE to 20171201
        drm/i915/cnl: Mask previous DDI - PLL mapping
        drm/i915: Remove unsafe i915.enable_rc6
        drm/i915: Sleep and retry a GPU reset if at first we don't succeed
        drm/i915: Interlaced DP output doesn't work on VLV/CHV
        drm/i915: Pass crtc state to intel_pipe_{enable,disable}()
        drm/i915: Wait for pipe to start on i830 as well
        drm/i915: Fix vblank timestamp/frame counter jumps on gen2
        drm/i915: Fix deadlock in i830_disable_pipe()
        drm/i915: Fix has_audio readout for DDI A
        drm/i915: Don't add the "force audio" property to DP connectors that don't support audio
        drm/i915: Disable DP audio for g4x
        drm/i915/selftests: Wake the device before executing requests on the GPU
        drm/i915: Set fake_vma.size as well as fake_vma.node.size for capture
        drm/i915: Tidy up signed/unsigned comparison
        drm/i915: Enable IPS with only sprite plane visible too, v4.
        drm/i915: Make ips_enabled a property depending on whether IPS is enabled, v3.
        drm/i915: Avoid PPS HW/SW state mismatch due to rounding
        drm/i915: Skip switch-to-kernel-context on suspend when wedged
        drm/i915/glk: Apply WaProgramL3SqcReg1DefaultForPerf for GLK too
        ...
      3f1f0b1c