1. 01 Nov, 2016 24 commits
  2. 31 Oct, 2016 5 commits
    • Ville Syrjälä's avatar
      drm/i915: Reorganize sprite init · 1890ae64
      Ville Syrjälä authored
      Kill the switch statement from the sprite init code and replace with a
      more straightforward if ladder. Now each significant evolution of the
      sprite hardware is in its own neat box.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1477411083-19255-5-git-send-email-ville.syrjala@linux.intel.comReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      1890ae64
    • Ville Syrjälä's avatar
      drm/i915: Bail if plane/crtc init fails · b079bd17
      Ville Syrjälä authored
      Due to the plane->index not getting readjusted in drm_plane_cleanup(),
      we can't continue initialization of some plane/crtc init fails.
      Well, we sort of could I suppose if we left all initialized planes on
      the list, but that would expose those planes to userspace as well.
      
      But for crtcs the situation is even worse since we assume that
      pipe==crtc index occasionally, so we can't really deal with a partially
      initialize set of crtcs.
      
      So seems safest to just abort the entire thing if anything goes wrong.
      All the failure paths here are kmalloc()s anyway, so it seems unlikely
      we'd get very far if these start failing.
      
      v2: Add (enum plane) case to silence gcc
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1477411083-19255-4-git-send-email-ville.syrjala@linux.intel.comReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      b079bd17
    • Ville Syrjälä's avatar
      drm/i915: Initialize planes in a reasonable order · a81d6fa0
      Ville Syrjälä authored
      The zpos magic sorting uses the object ID to solve conflicting zpos
      values. Let's initialize our planes in an order that makes the object
      IDs agree with the normal primary->sprites->cursor z order.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1477411083-19255-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      a81d6fa0
    • Ville Syrjälä's avatar
      drm/i915: Don't try to initialize sprite planes on pre-ilk · 33edc24d
      Ville Syrjälä authored
      We don't currently implement support for sprite planes on pre-ilk
      platforms, so let's leave num_sprites at 0 so that we don't get
      spurious errors during driver init.
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1477411083-19255-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      33edc24d
    • Chris Wilson's avatar
      drm/i915: Mark up obj->mm.lock for shrinker · 7b7a119e
      Chris Wilson authored
      As we may allocate from within the obj->mm.lock we may enter the
      shrinker for direct reclaim. Operating on the current object is
      prevented by checking for obj->mm.pages (which is only set as the last
      operation in the allocation path). However, we need to identify the
      single recursion of accessing another object's obj->mm.lock as the two
      locks have identical class and so appear to be the same to lockdep,
      convincing it that a deadlock is possible. Use mutex_lock_nested() to
      remove the false positive.
      
      [ 2165.945734] =================================
      [ 2165.945749] [ INFO: inconsistent lock state ]
      [ 2165.945765] 4.9.0-rc2+ #2 Tainted: G        W
      [ 2165.945781] ---------------------------------
      [ 2165.945796] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
      [ 2165.945816] kswapd0/62 [HC0[0]:SC0[0]:HE1:SE1] takes: (&obj->mm.lock){+.+.?.}, at: [<ffffffffc0289a1f>] i915_gem_shrink+0x29f/0x500 [i915]
      [ 2165.945904] {RECLAIM_FS-ON-W} state was registered at:
      [ 2165.945931] [<ffffffffb10bd50f>] mark_held_locks+0x6f/0xa0
      [ 2165.945956] [<ffffffffb10bf889>] lockdep_trace_alloc+0x69/0xc0
      [ 2165.945982] [<ffffffffb11eea53>] kmem_cache_alloc_trace+0x33/0x2a0
      [ 2165.946019] [<ffffffffc028a28a>] i915_gem_object_get_pages_stolen+0x6a/0xd0 [i915]
      [ 2165.946060] [<ffffffffc027e1d0>] ____i915_gem_object_get_pages+0x20/0x60 [i915]
      [ 2165.946098] [<ffffffffc027e268>] __i915_gem_object_get_pages+0x58/0x70 [i915]
      [ 2165.946138] [<ffffffffc028a3dc>] _i915_gem_object_create_stolen+0xec/0x120 [i915]
      [ 2165.946177] [<ffffffffc028af73>] i915_gem_object_create_stolen_for_preallocated+0xf3/0x3f0 [i915]
      [ 2165.946222] [<ffffffffc02bae43>] intel_alloc_initial_plane_obj.isra.125+0xd3/0x200 [i915]
      [ 2165.946266] [<ffffffffc02cb1c1>] intel_modeset_init+0x931/0x1530 [i915]
      [ 2165.946301] [<ffffffffc023d584>] i915_driver_load+0xa14/0x14a0 [i915]
      [ 2165.946335] [<ffffffffc0248aff>] i915_pci_probe+0x4f/0x70 [i915]
      [ 2165.946362] [<ffffffffb13cc452>] local_pci_probe+0x42/0xa0
      [ 2165.946386] [<ffffffffb13cd903>] pci_device_probe+0x103/0x150
      [ 2165.946411] [<ffffffffb14adeb3>] driver_probe_device+0x223/0x430
      [ 2165.946436] [<ffffffffb14ae1a3>] __driver_attach+0xe3/0xf0
      [ 2165.946461] [<ffffffffb14ab943>] bus_for_each_dev+0x73/0xc0
      [ 2165.946485] [<ffffffffb14ad5ee>] driver_attach+0x1e/0x20
      [ 2165.946508] [<ffffffffb14ad003>] bus_add_driver+0x173/0x270
      [ 2165.946533] [<ffffffffb14aee70>] driver_register+0x60/0xe0
      [ 2165.946557] [<ffffffffb13cbd6d>] __pci_register_driver+0x5d/0x60
      [ 2165.946606] [<ffffffffc0378057>] soundcore_open+0x17/0x230 [soundcore]
      [ 2165.946636] [<ffffffffb1000450>] do_one_initcall+0x50/0x180
      [ 2165.946661] [<ffffffffb117fd2d>] do_init_module+0x5f/0x1f1
      [ 2165.946685] [<ffffffffb1108964>] load_module+0x2174/0x2a80
      [ 2165.946709] [<ffffffffb11094df>] SYSC_finit_module+0xdf/0x110
      [ 2165.946734] [<ffffffffb110952e>] SyS_finit_module+0xe/0x10
      [ 2165.946758] [<ffffffffb1742aea>] entry_SYSCALL_64_fastpath+0x18/0xad
      [ 2165.946776] irq event stamp: 90871
      [ 2165.946788] hardirqs last  enabled at (90871):
      [ 2165.946805] [<ffffffffb173e9da>] __mutex_unlock_slowpath+0x11a/0x1c0
      [ 2165.946823] hardirqs last disabled at (90870):
      [ 2165.946839] [<ffffffffb173e91b>] __mutex_unlock_slowpath+0x5b/0x1c0
      [ 2165.946856] softirqs last  enabled at (90858):
      [ 2165.946872] [<ffffffffb174581a>] __do_softirq+0x39a/0x4c6
      [ 2165.946887] softirqs last disabled at (90671):
      [ 2165.946902] [<ffffffffb1066cea>] irq_exit+0xea/0xf0
      [ 2165.946916] other info that might help us debug this:
      [ 2165.946936]  Possible unsafe locking scenario:
      [ 2165.946955]        CPU0
      [ 2165.946965]        ----
      [ 2165.946975]   lock(&obj->mm.lock);
      [ 2165.947000]   <Interrupt>
      [ 2165.947010]     lock(&obj->mm.lock);
      [ 2165.947035] *** DEADLOCK ***
      [ 2165.947054] 2 locks held by kswapd0/62:
      [ 2165.947067]  #0: (shrinker_rwsem){++++..}, at: [<ffffffffb119a20e>] shrink_slab.part.40+0x5e/0x5d0
      [ 2165.947120]  #1: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffc028954b>] i915_gem_shrinker_lock+0x1b/0x60 [i915]
      [ 2165.948909] stack backtrace:
      [ 2165.950650] CPU: 2 PID: 62 Comm: kswapd0 Tainted: G        W 4.9.0-rc2+ #2
      [ 2165.951587] Hardware name: LENOVO 80MX/Lenovo E31-80, BIOS DCCN34WW(V2.03) 12/01/2015
      [ 2165.952484]  ffffc90000b5f8c8 ffffffffb137f645 ffff88016c5a2700 ffffffffb25f20a0
      [ 2165.953395]  ffffc90000b5f918 ffffffffb10bcecd 0000000000000000 ffff880100000001
      [ 2165.954305]  0000000000000001 000000000000000a ffff88016c5a2fd0 ffff88016c5a2700
      [ 2165.955240] Call Trace:
      [ 2165.956170]  [<ffffffffb137f645>] dump_stack+0x68/0x93
      [ 2165.957071]  [<ffffffffb10bcecd>] print_usage_bug+0x1dd/0x1f0
      [ 2165.957979]  [<ffffffffb10bd439>] mark_lock+0x559/0x5c0
      [ 2165.958875]  [<ffffffffb10bc3f0>] ?  print_shortest_lock_dependencies+0x1b0/0x1b0
      [ 2165.959829]  [<ffffffffb10be04d>] __lock_acquire+0x66d/0x12a0
      [ 2165.960729]  [<ffffffffb11ef541>] ? __slab_free+0xa1/0x340
      [ 2165.961625]  [<ffffffffb10dba5d>] ?  debug_lockdep_rcu_enabled+0x1d/0x20
      [ 2165.962530]  [<ffffffffb10bd50f>] ? mark_held_locks+0x6f/0xa0
      [ 2165.963457]  [<ffffffffb10bf0b0>] lock_acquire+0xf0/0x1f0
      [ 2165.964368]  [<ffffffffc0289a1f>] ? i915_gem_shrink+0x29f/0x500 [i915]
      [ 2165.965269]  [<ffffffffc0289a1f>] ? i915_gem_shrink+0x29f/0x500 [i915]
      [ 2165.966150]  [<ffffffffb173d837>] mutex_lock_nested+0x77/0x420
      [ 2165.967030]  [<ffffffffc0289a1f>] ? i915_gem_shrink+0x29f/0x500 [i915]
      [ 2165.967952]  [<ffffffffc027c7a1>] ?  __i915_gem_object_put_pages.part.58+0x161/0x1b0 [i915]
      [ 2165.968835]  [<ffffffffc0289a1f>] i915_gem_shrink+0x29f/0x500 [i915]
      [ 2165.969712]  [<ffffffffc0289e40>] i915_gem_shrinker_scan+0x70/0xb0 [i915]
      [ 2165.970591]  [<ffffffffb119a3ae>] shrink_slab.part.40+0x1fe/0x5d0
      [ 2165.971504]  [<ffffffffb119f19c>] shrink_node+0x22c/0x320
      [ 2165.972371]  [<ffffffffb11a05fb>] kswapd+0x38b/0x9b0
      [ 2165.973238]  [<ffffffffb11a0270>] ?  mem_cgroup_shrink_node+0x330/0x330
      [ 2165.974068]  [<ffffffffb108630f>] kthread+0xff/0x120
      [ 2165.974929]  [<ffffffffb1086210>] ? kthread_park+0x60/0x60
      [ 2165.975847]  [<ffffffffb1742d57>] ret_from_fork+0x27/0x40
      Reported-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Fixes: 1233e2db ("drm/i915: Move object backing storage manipulation...")
      Testcase: igt/gem_ctx_create/maximum-swap
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161031124048.30355-1-chris@chris-wilson.co.uk
      7b7a119e
  3. 29 Oct, 2016 2 commits
  4. 28 Oct, 2016 9 commits
    • Chris Wilson's avatar
      drm/i915: Enable multiple timelines · 80b204bc
      Chris Wilson authored
      With the infrastructure converted over to tracking multiple timelines in
      the GEM API whilst preserving the efficiency of using a single execution
      timeline internally, we can now assign a separate timeline to every
      context with full-ppgtt.
      
      v2: Add a comment to indicate the xfer between timelines upon submission.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-35-chris@chris-wilson.co.uk
      80b204bc
    • Chris Wilson's avatar
      drm/i915: Defer setting of global seqno on request to submission · f2d13290
      Chris Wilson authored
      Defer the assignment of the global seqno on a request to its submission.
      In the next patch, we will only allocate the global seqno at that time,
      here we are just enabling the wait-for-submission before wait-for-seqno
      paths.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-34-chris@chris-wilson.co.uk
      f2d13290
    • Chris Wilson's avatar
      drm/i915: Reserve space in the global seqno during request allocation · 28176ef4
      Chris Wilson authored
      A restriction on our global seqno is that they cannot wrap, and that we
      cannot use the value 0. This allows us to detect when a request has not
      yet been submitted, its global seqno is still 0, and ensures that
      hardware semaphores are monotonic as required by older hardware. To
      meet these restrictions when we defer the assignment of the global
      seqno, we must check that we have an available slot in the global seqno
      space during request construction. If that test fails, we wait for all
      requests to be completed and reset the hardware back to 0.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-33-chris@chris-wilson.co.uk
      28176ef4
    • Chris Wilson's avatar
      drm/i915: Convert breadcrumbs spinlock to be irqsafe · f6168e33
      Chris Wilson authored
      The breadcrumbs are about to be used from within IRQ context sections
      (e.g. nouveau signals a fence from an interrupt handler causing us to
      submit a new request) and/or from bottom-half tasklets (i.e.
      intel_lrc_irq_handler), therefore we need to employ the irqsafe spinlock
      variants.
      
      For example, deferring the request submission to the
      intel_lrc_irq_handler generates this trace:
      
      [   66.388639] =================================
      [   66.388650] [ INFO: inconsistent lock state ]
      [   66.388663] 4.9.0-rc2+ #56 Not tainted
      [   66.388672] ---------------------------------
      [   66.388682] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [   66.388695] swapper/1/0 [HC0[0]:SC1[1]:HE0:SE0] takes:
      [   66.388706]  (&(&b->lock)->rlock){+.?...} , at: [<ffffffff81401c88>] intel_engine_enable_signaling+0x78/0x150
      [   66.388761] {SOFTIRQ-ON-W} state was registered at:
      [   66.388772]   [   66.388783] [<ffffffff810bd842>] __lock_acquire+0x682/0x1870
      [   66.388795]   [   66.388803] [<ffffffff810bedbc>] lock_acquire+0x6c/0xb0
      [   66.388814]   [   66.388824] [<ffffffff8161753a>] _raw_spin_lock+0x2a/0x40
      [   66.388835]   [   66.388845] [<ffffffff81401e41>] intel_engine_reset_breadcrumbs+0x21/0xb0
      [   66.388857]   [   66.388866] [<ffffffff81403ae7>] gen8_init_common_ring+0x67/0x100
      [   66.388878]   [   66.388887] [<ffffffff81403b92>] gen8_init_render_ring+0x12/0x60
      [   66.388903]   [   66.388912] [<ffffffff813f8707>] i915_gem_init_hw+0xf7/0x2a0
      [   66.388927]   [   66.388936] [<ffffffff813f899b>] i915_gem_init+0xbb/0xf0
      [   66.388950]   [   66.388959] [<ffffffff813b4980>] i915_driver_load+0x7e0/0x1330
      [   66.388978]   [   66.388988] [<ffffffff813c09d8>] i915_pci_probe+0x28/0x40
      [   66.389003]   [   66.389013] [<ffffffff812fa0db>] pci_device_probe+0x8b/0xf0
      [   66.389028]   [   66.389037] [<ffffffff8147737e>] driver_probe_device+0x21e/0x430
      [   66.389056]   [   66.389065] [<ffffffff8147766e>] __driver_attach+0xde/0xe0
      [   66.389080]   [   66.389090] [<ffffffff814751ad>] bus_for_each_dev+0x5d/0x90
      [   66.389105]   [   66.389113] [<ffffffff81477799>] driver_attach+0x19/0x20
      [   66.389134]   [   66.389144] [<ffffffff81475ced>] bus_add_driver+0x15d/0x260
      [   66.389159]   [   66.389168] [<ffffffff81477e3b>] driver_register+0x5b/0xd0
      [   66.389183]   [   66.389281] [<ffffffff812fa19b>] __pci_register_driver+0x5b/0x60
      [   66.389301]   [   66.389312] [<ffffffff81aed333>] i915_init+0x3e/0x45
      [   66.389326]   [   66.389336] [<ffffffff81ac2ffa>] do_one_initcall+0x8b/0x118
      [   66.389350]   [   66.389359] [<ffffffff81ac323a>] kernel_init_freeable+0x1b3/0x23b
      [   66.389378]   [   66.389387] [<ffffffff8160fc39>] kernel_init+0x9/0x100
      [   66.389402]   [   66.389411] [<ffffffff816180e7>] ret_from_fork+0x27/0x40
      [   66.389426] irq event stamp: 315865
      [   66.389438] hardirqs last  enabled at (315864): [<ffffffff816178f1>] _raw_spin_unlock_irqrestore+0x31/0x50
      [   66.389469] hardirqs last disabled at (315865): [<ffffffff816176b3>] _raw_spin_lock_irqsave+0x13/0x50
      [   66.389499] softirqs last  enabled at (315818): [<ffffffff8107a04c>] _local_bh_enable+0x1c/0x50
      [   66.389530] softirqs last disabled at (315819): [<ffffffff8107a50e>] irq_exit+0xbe/0xd0
      [   66.389559]
      [   66.389559] other info that might help us debug this:
      [   66.389580]  Possible unsafe locking scenario:
      [   66.389580]
      [   66.389598]        CPU0
      [   66.389609]        ----
      [   66.389620]   lock(&(&b->lock)->rlock);
      [   66.389650]   <Interrupt>
      [   66.389661]     lock(&(&b->lock)->rlock);
      [   66.389690]
      [   66.389690]  *** DEADLOCK ***
      [   66.389690]
      [   66.389715] 2 locks held by swapper/1/0:
      [   66.389728]  #0: (&(&tl->lock)->rlock){..-...}, at: [<ffffffff81403e01>] intel_lrc_irq_handler+0x201/0x3c0
      [   66.389785]  #1: (&(&req->lock)->rlock/1){..-...}, at: [<ffffffff813fc0af>] __i915_gem_request_submit+0x8f/0x170
      [   66.389854]
      [   66.389854] stack backtrace:
      [   66.389959] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.9.0-rc2+ #56
      [   66.389976] Hardware name:                  /        , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
      [   66.389999]  ffff88027fd03c58 ffffffff812beae5 ffff88027696e680 ffffffff822afe20
      [   66.390036]  ffff88027fd03ca8 ffffffff810bb420 0000000000000001 0000000000000000
      [   66.390070]  0000000000000000 0000000000000006 0000000000000004 ffff88027696ee10
      [   66.390104] Call Trace:
      [   66.390117]  <IRQ>
      [   66.390128]  [<ffffffff812beae5>] dump_stack+0x68/0x93
      [   66.390147]  [<ffffffff810bb420>] print_usage_bug+0x1d0/0x1e0
      [   66.390164]  [<ffffffff810bb8a0>] mark_lock+0x470/0x4f0
      [   66.390181]  [<ffffffff810ba9d0>] ? print_shortest_lock_dependencies+0x1b0/0x1b0
      [   66.390203]  [<ffffffff810bd75d>] __lock_acquire+0x59d/0x1870
      [   66.390221]  [<ffffffff810bedbc>] lock_acquire+0x6c/0xb0
      [   66.390237]  [<ffffffff810bedbc>] ? lock_acquire+0x6c/0xb0
      [   66.390255]  [<ffffffff81401c88>] ? intel_engine_enable_signaling+0x78/0x150
      [   66.390273]  [<ffffffff8161753a>] _raw_spin_lock+0x2a/0x40
      [   66.390291]  [<ffffffff81401c88>] ? intel_engine_enable_signaling+0x78/0x150
      [   66.390309]  [<ffffffff81401c88>] intel_engine_enable_signaling+0x78/0x150
      [   66.390327]  [<ffffffff813fc170>] __i915_gem_request_submit+0x150/0x170
      [   66.390345]  [<ffffffff81403e8b>] intel_lrc_irq_handler+0x28b/0x3c0
      [   66.390363]  [<ffffffff81079d97>] tasklet_action+0x57/0xc0
      [   66.390380]  [<ffffffff8107a249>] __do_softirq+0x119/0x240
      [   66.390396]  [<ffffffff8107a50e>] irq_exit+0xbe/0xd0
      [   66.390414]  [<ffffffff8101afd5>] do_IRQ+0x65/0x110
      [   66.390431]  [<ffffffff81618806>] common_interrupt+0x86/0x86
      [   66.390446]  <EOI>
      [   66.390457]  [<ffffffff814ec6d1>] ? cpuidle_enter_state+0x151/0x200
      [   66.390480]  [<ffffffff814ec7a2>] cpuidle_enter+0x12/0x20
      [   66.390498]  [<ffffffff810b639e>] call_cpuidle+0x1e/0x40
      [   66.390516]  [<ffffffff810b65ae>] cpu_startup_entry+0x10e/0x1f0
      [   66.390534]  [<ffffffff81036133>] start_secondary+0x103/0x130
      
      (This is split out of the defer global seqno allocation patch due to
      realisation that we need a more complete conversion if we want to defer
      request submission even further.)
      
      v2: lockdep was warning about mixed SOFTIRQ contexts not HARDIRQ
      contexts so we only need to use spin_lock_bh and not disable interrupts.
      
      v3: We need full irq protection as we may be called from a third party
      interrupt handler (via fences).
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-32-chris@chris-wilson.co.uk
      f6168e33
    • Chris Wilson's avatar
      drm/i915: Create a unique name for the context · 562f5d45
      Chris Wilson authored
      This will be used for communicating issues with this context to
      userspace, so we want to identify the parent process and the individual
      context. Note that the name isn't quite unique, it makes the presumption
      of there only being a single device fd per process.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-31-chris@chris-wilson.co.uk
      562f5d45
    • Chris Wilson's avatar
      drm/i915: Move the global sync optimisation to the timeline · 85e17f59
      Chris Wilson authored
      Currently we try to reduce the number of synchronisations (now the
      number of requests we need to wait upon) by noting that if we have
      earlier waited upon a request, all subsequent requests in the timeline
      will be after the wait. This only applies to requests in this timeline,
      as other timelines will not be ordered by that waiter.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-30-chris@chris-wilson.co.uk
      85e17f59
    • Chris Wilson's avatar
      drm/i915: Defer breadcrumb emission · caddfe71
      Chris Wilson authored
      Move the actual emission of the breadcrumb for closing the request from
      i915_add_request() to the submit callback. (It can be moved later when
      required.) This allows us to defer the allocation of the global_seqno
      from request construction to actual submission, allowing us to emit the
      requests out of order (wrt to the order of their construction, they
      still will only be executed one all of their dependencies are resolved
      including that all earlier requests on their timeline have been
      submitted.) We have to specialise how we then emit the request in order
      to write into the preallocated space, rather than at the tail of the
      ringbuffer (which will have been advanced by the addition of new
      requests).
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-29-chris@chris-wilson.co.uk
      caddfe71
    • Chris Wilson's avatar
      drm/i915: Record space required for breadcrumb emission · 98f29e8d
      Chris Wilson authored
      In the next patch, we will use deferred breadcrumb emission. That requires
      reserving sufficient space in the ringbuffer to emit the breadcrumb, which
      first requires us to know how large the breadcrumb is.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-28-chris@chris-wilson.co.uk
      98f29e8d
    • Chris Wilson's avatar
      drm/i915: Rename ->emit_request to ->emit_breadcrumb · 9b81d556
      Chris Wilson authored
      Now that the emission of the request tail and its submission to hardware
      are two separate steps, engine->emit_request() is confusing.
      engine->emit_request() is called to emit the breadcrumb commands for the
      request into the ring, name it such (engine->emit_breadcrumb).
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20161028125858.23563-27-chris@chris-wilson.co.uk
      9b81d556