1. 02 Apr, 2019 4 commits
    • Chris Wilson's avatar
      drm/i915: Only emit one semaphore per request · 7881e605
      Chris Wilson authored
      Ideally we only need one semaphore per ring to accommodate waiting on
      multiple engines in parallel. However, since we do not know which fences
      we will finally be waiting on, we emit a semaphore for every fence. It
      turns out to be quite easy to trick ourselves into exhausting our
      ringbuffer causing an error, just by feeding in a batch that depends on
      several thousand contexts.
      
      Since we never can be waiting on more than one semaphore in parallel
      (other than perhaps the desire to busywait on multiple engines), just
      pick the first fence for our semaphore. If we pick the wrong fence to
      busywait on, we just miss an opportunity to reduce latency.
      
      An adaption might be to use sched.flags as either a semaphore counter,
      or to track the first busywait on each engine, converting it back to a
      single use bit prior to closing the request.
      
      v2: Track first semaphore used per-engine (this caters for our basic
      igt that semaphores are working).
      Reported-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Testcase: igt/gem_exec_fence/long-history
      Fixes: e8861964 ("drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190401162641.10963-3-chris@chris-wilson.co.ukReviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      7881e605
    • Chris Wilson's avatar
      drm/i915: Split out i915_priolist_types into its own header · 8b74594a
      Chris Wilson authored
      For more intel_engine_mask_t detangling. This time so that we can use
      intel_engine_mask_t inside the scheduling structs.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190401162641.10963-2-chris@chris-wilson.co.ukReviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      8b74594a
    • Chris Wilson's avatar
      drm/i915: Move intel_engine_mask_t around for use by i915_request_types.h · 3a891a62
      Chris Wilson authored
      We want to use intel_engine_mask_t inside i915_request.h, which means
      extracting it from the general header file mess and placing it inside a
      types.h. A knock on effect is that the compiler wants to warn about
      type-contraction of ALL_ENGINES into intel_engine_maskt_t, so prepare
      for the worst.
      
      v2: Use intel_engine_mask_t consistently
      v3: Move I915_NUM_ENGINES to its natural home at the end of the enum
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: John Harrison <John.C.Harrison@Intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190401162641.10963-1-chris@chris-wilson.co.ukReviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      3a891a62
    • Chris Wilson's avatar
      drm/i915: Prefault before locking pages in shmem_pwrite · b01720bf
      Chris Wilson authored
      If the user passes in a pointer to a GGTT mmaping of the same buffer
      being written to, we can hit a deadlock in acquiring the shmemfs page
      (once as the write destination and then as the read source).
      
      [<0>] io_schedule+0xd/0x30
      [<0>] __lock_page+0x105/0x1b0
      [<0>] find_lock_entry+0x55/0x90
      [<0>] shmem_getpage_gfp+0xbb/0x800
      [<0>] shmem_read_mapping_page_gfp+0x2d/0x50
      [<0>] shmem_get_pages+0x158/0x5d0 [i915]
      [<0>] ____i915_gem_object_get_pages+0x17/0x90 [i915]
      [<0>] __i915_gem_object_get_pages+0x57/0x70 [i915]
      [<0>] i915_gem_fault+0x1b4/0x5c0 [i915]
      [<0>] __do_fault+0x2d/0x80
      [<0>] __handle_mm_fault+0xad4/0xfb0
      [<0>] handle_mm_fault+0xe6/0x1f0
      [<0>] __do_page_fault+0x18f/0x3f0
      [<0>] page_fault+0x1b/0x20
      [<0>] copy_user_enhanced_fast_string+0x7/0x10
      [<0>] _copy_from_user+0x37/0x60
      [<0>] shmem_pwrite+0xf0/0x160 [i915]
      [<0>] i915_gem_pwrite_ioctl+0x14e/0x520 [i915]
      [<0>] drm_ioctl_kernel+0x81/0xd0
      [<0>] drm_ioctl+0x1a7/0x310
      [<0>] do_vfs_ioctl+0x88/0x5d0
      [<0>] ksys_ioctl+0x35/0x70
      [<0>] __x64_sys_ioctl+0x11/0x20
      [<0>] do_syscall_64+0x39/0xe0
      [<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      We can reduce (but not eliminate!) the chance of this happening by
      faulting the user_data before we take the page lock in
      pagecache_write_begin(). One way to eliminate the potential recursion
      here is by disabling pagefaults for the copy, and handling the fallback
      to use an alternative method -- so convert to use kmap_atomic (which
      should disable preemption and pagefaulting for the copy) and report
      ENODEV instead of EFAULT so that our caller tries again with a different
      copy mechanism -- we already check that the page should have been
      faultable so a false negative should be rare.
      
      Testcase: igt/gem_pwrite/self
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Matthew Auld <matthew.william.auld@gmail.com>
      Reviewed-by: default avatarMatthew Auld <matthew.william.auld@gmail.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190401133909.31203-1-chris@chris-wilson.co.uk
      b01720bf
  2. 01 Apr, 2019 5 commits
  3. 31 Mar, 2019 2 commits
  4. 30 Mar, 2019 1 commit
  5. 29 Mar, 2019 5 commits
    • Chris Wilson's avatar
      drm/i915: Always backoff after a drm_modeset_lock() deadlock · ee6df569
      Chris Wilson authored
      If drm_modeset_lock() reports a deadlock it sets the ctx->contexted
      field and insists that the caller calls drm_modeset_backoff() or else it
      generates a WARN on cleanup.
      
      <4> [1601.870376] WARNING: CPU: 3 PID: 8445 at drivers/gpu/drm/drm_modeset_lock.c:228 drm_modeset_drop_locks+0x35/0x40
      <4> [1601.870395] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal i915 coretemp crct10dif_pclmul
      <6> [1601.870403] Console: switching
      <4> [1601.870403]  snd_hda_intel
      <4> [1601.870406] to colour frame buffer device 320x90
      <4> [1601.870406]  crc32_pclmul snd_hda_codec snd_hwdep ghash_clmulni_intel e1000e snd_hda_core cdc_ether ptp usbnet mii pps_core snd_pcm i2c_i801 mei_me mei prime_numbers
      <4> [1601.870422] CPU: 3 PID: 8445 Comm: cat Tainted: G     U            5.0.0-rc7-CI-CI_DRM_5650+ #1
      <4> [1601.870424] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.2402.AD3.1810170014 10/17/2018
      <4> [1601.870427] RIP: 0010:drm_modeset_drop_locks+0x35/0x40
      <4> [1601.870430] Code: 29 48 8b 43 60 48 8d 6b 60 48 39 c5 74 19 48 8b 43 60 48 8d b8 70 ff ff ff e8 87 ff ff ff 48 8b 43 60 48 39 c5 75 e7 5b 5d c3 <0f> 0b eb d3 0f 1f 80 00 00 00 00 41 56 41 55 41 54 55 53 48 8b 6f
      <4> [1601.870432] RSP: 0018:ffffc90000d67ce8 EFLAGS: 00010282
      <4> [1601.870435] RAX: 00000000ffffffdd RBX: ffffc90000d67d00 RCX: 5dbbe23d00000000
      <4> [1601.870437] RDX: 0000000000000000 RSI: 0000000093e6194a RDI: ffffc90000d67d00
      <4> [1601.870439] RBP: ffff88849e62e678 R08: 0000000003b7329a R09: 0000000000000001
      <4> [1601.870441] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888492100410
      <4> [1601.870442] R13: ffff88849ea50958 R14: ffff8884a67eb028 R15: ffff8884a67eb028
      <4> [1601.870445] FS:  00007fa7a27745c0(0000) GS:ffff8884aff80000(0000) knlGS:0000000000000000
      <4> [1601.870447] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      <4> [1601.870449] CR2: 000055af07e66000 CR3: 00000004a8cc2006 CR4: 0000000000760ee0
      <4> [1601.870451] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      <4> [1601.870453] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      <4> [1601.870454] PKRU: 55555554
      <4> [1601.870456] Call Trace:
      <4> [1601.870505]  i915_dsc_fec_support_show+0x91/0x190 [i915]
      <4> [1601.870522]  seq_read+0xdb/0x3c0
      <4> [1601.870531]  full_proxy_read+0x51/0x80
      <4> [1601.870538]  __vfs_read+0x31/0x190
      <4> [1601.870546]  ? __se_sys_newfstat+0x3c/0x60
      <4> [1601.870552]  vfs_read+0x9e/0x150
      <4> [1601.870557]  ksys_read+0x50/0xc0
      <4> [1601.870564]  do_syscall_64+0x55/0x190
      <4> [1601.870569]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
      <4> [1601.870572] RIP: 0033:0x7fa7a226d081
      <4> [1601.870574] Code: fe ff ff 48 8d 3d 67 9c 0a 00 48 83 ec 08 e8 a6 4c 02 00 66 0f 1f 44 00 00 48 8d 05 81 08 2e 00 8b 00 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 f3 c3 0f 1f 44 00 00 41 54 55 49 89 d4 53
      <4> [1601.870576] RSP: 002b:00007ffcc05140c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
      <4> [1601.870579] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fa7a226d081
      <4> [1601.870581] RDX: 0000000000020000 RSI: 000055af07e63000 RDI: 0000000000000007
      <4> [1601.870583] RBP: 0000000000020000 R08: 000000000000007b R09: 0000000000000000
      <4> [1601.870585] R10: 000055af07e60010 R11: 0000000000000246 R12: 000055af07e63000
      <4> [1601.870587] R13: 0000000000000007 R14: 000055af07e634bf R15: 0000000000020000
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109745
      Fixes: e845f099 ("drm/i915/dsc: Add Per connector debugfs node for DSC support/enable")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
      Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
      Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
      Cc: Lyude Paul <lyude@redhat.com>
      Cc: Manasi Navare <manasi.d.navare@intel.com>
      Reviewed-by: default avatarManasi Navare <manasi.d.navare@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190329165152.29259-1-chris@chris-wilson.co.uk
      ee6df569
    • Uma Shankar's avatar
      drm/i915: Program EXT2 GC MAX registers · 502da13a
      Uma Shankar authored
      EXT2 GC MAX registers are introduced from Gen10+ to
      program values from 3.0 to 7.0. Enabled the same, but
      currently limiting it to 1.0 as userspace ABI is limited
      at that currently.
      
      v2: Updated the 1.0 programming and aligned as per GLK, also added
      GLK along with GEN10+ check, as per Ville's feedback.
      Signed-off-by: default avatarUma Shankar <uma.shankar@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1553869756-4546-3-git-send-email-uma.shankar@intel.com
      502da13a
    • Uma Shankar's avatar
      drm/i915: Fix GCMAX color register programming · 61eae851
      Uma Shankar authored
      GC MAX register is used to program values from 1.0 to
      less than 3.0. A different register was used instead of
      the intended one. Fixed the same.
      
      Currently limiting it to 1.0 due to ABI limitations.
      
      v2: Updated the 1.0 programming and aligned as per GLK, based
      on Ville's feedback.
      Reported-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarUma Shankar <uma.shankar@intel.com>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/1553869756-4546-2-git-send-email-uma.shankar@intel.com
      61eae851
    • Daniele Ceraolo Spurio's avatar
      drm/i915: fix i9xx irq enable/disable · e15be429
      Daniele Ceraolo Spurio authored
      Those functions are used on gen4 as well and gen4 does have a non-RCS
      engine, so remove the BUG_ON and flip back the logic to what it was
      before the ENGINE_READ/WRITE update
      
      v2: update the posting read as well (Chris, Ville).
      
      Fixes: baba6e57 ("drm/i915: take a reference to uncore in the engine and use it")
      Signed-off-by: default avatarDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190329165018.32953-1-daniele.ceraolospurio@intel.com
      e15be429
    • Daniele Ceraolo Spurio's avatar
      drm/i915: move the edram detection out of uncore init · f6ac993f
      Daniele Ceraolo Spurio authored
      edram is not part of uncore and there is no requirement for the
      detection to be done before we initialize the uncore functions. The
      first check on HAS_EDRAM is in the ggtt_init path, so move it to
      i915_driver_init_hw, where other dram-related detection happens.
      
      While at it, save the size in MB instead of the capabilities because the
      size is the only thing we look at outside of the init function.
      Signed-off-by: default avatarDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190328174533.31532-1-daniele.ceraolospurio@intel.com
      f6ac993f
  6. 28 Mar, 2019 13 commits
  7. 27 Mar, 2019 10 commits