1. 12 Jan, 2017 4 commits
    • Libin Yang's avatar
      ALSA: hda - add DP MST audio support · 9152085d
      Libin Yang authored
      This patch adds the DP MST audio support on i915 platform and
      it will enable dyn_pcm_assign feature.
      
      DP MST supports several device entry on the same port and each
      device entry can map to one pcm stream. For example, on i915,
      there are 3 pins, and each pin has 3 device entries. This means
      there should be 3x3 pcms. However, there is only 3 pipe lines in
      i915. This means 3 pcms are actived at most at the same moment.
      We will create 5 pcms (pin number + dev entry num - 1) in this case.
      For the details, please refer commit a76056f2
      ("ALSA: hda - hdmi dynamically bind PCM to pin when monitor hotplug")
      
      Each device entry is a virtual pin. It is described by pin_nid and dev_id
      in struct hdmi_spec_per_pin.
      Reviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLibin Yang <libin.yang@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1484208294-8637-3-git-send-email-libin.yang@intel.com
      9152085d
    • Libin Yang's avatar
      ALSA: hda - add DP mst verb support · 13800f39
      Libin Yang authored
      Add snd_hda_get_dev_select() and snd_hda_set_dev_select() functions
      for DP MST audio support.
      Reviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarLibin Yang <libin.yang@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1484208294-8637-2-git-send-email-libin.yang@intel.com
      13800f39
    • Zhenyu Wang's avatar
      drm/i915: check ppgtt validity when init reg state · 34869776
      Zhenyu Wang authored
      Check if ppgtt is valid for context when init reg state. For gvt
      context which has no i915 allocated ppgtt, failed to check that
      would cause kernel null ptr reference error.
      
      v2: remove !48bit ppgtt case as we'll always update before submit (Chris)
      Signed-off-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170109131453.3943-1-zhenyuw@linux.intel.com
      34869776
    • Chris Wilson's avatar
      drm/i915: Detect vma reserved for execbuf in evict-for-node · 16ee2061
      Chris Wilson authored
      The vma->exec_list is still the only means we have for both reserving an
      object in execbuf, and for constructing the eviction list. So during the
      construction of the eviction list, we must treat anything already on the
      exec_list as being pinned.
      
      Yes, this sharing of two semantically different lists will be fixed! But
      in the meantime, we have the issue that this is tripping up CI since we
      started using i915_gem_gtt_reserve_node() + i915_gem_evict_for_node()
      from the regular execbuf reservation path in commit 606fec95
      ("drm/i915: Prefer random replacement before eviction search"):
      
      [  108.424063] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:254!
      [  108.424072] invalid opcode: 0000 [#1] PREEMPT SMP
      [  108.424079] Modules linked in: snd_hda_intel i915 intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core mei_me snd_pcm lpc_ich mei sdhci_pci sdhci mmc_core e1000e ptp pps_core [last unloaded: i915]
      [  108.424132] CPU: 1 PID: 6865 Comm: gem_cs_tlb Tainted: G     U          4.10.0-rc3-CI-CI_DRM_2049+ #1
      [  108.424143] Hardware name: Hewlett-Packard HP EliteBook 8440p/172A, BIOS 68CCU Ver. F.24 09/13/2013
      [  108.424154] task: ffff88012ae22600 task.stack: ffffc90000a14000
      [  108.424220] RIP: 0010:i915_gem_evict_for_node+0x237/0x410 [i915]
      [  108.424229] RSP: 0018:ffffc90000a17a58 EFLAGS: 00010202
      [  108.424237] RAX: 0000000000005871 RBX: ffff88012d1ad778 RCX: 0000000000000000
      [  108.424246] RDX: 000000007ffff000 RSI: ffffc90000a17a68 RDI: ffff880127e694d8
      [  108.424255] RBP: ffffc90000a17aa0 R08: ffffc90000a17a68 R09: 0000000000000000
      [  108.424264] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000080000000
      [  108.424273] R13: ffffc90000a17a68 R14: ffff880127e694d8 R15: ffffffffa0387330
      [  108.424283] FS:  00007f8236e3d8c0(0000) GS:ffff880137c40000(0000) knlGS:0000000000000000
      [  108.424293] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  108.424305] CR2: 00007f82347a2000 CR3: 000000012c866000 CR4: 00000000000006e0
      [  108.424317] Call Trace:
      [  108.424368]  i915_gem_gtt_reserve+0x67/0x80 [i915]
      [  108.424424]  __i915_vma_do_pin+0x248/0x620 [i915]
      [  108.424487]  ? __i915_vma_do_pin+0x162/0x620 [i915]
      [  108.424540]  i915_gem_execbuffer_reserve_vma.isra.8+0x153/0x1f0 [i915]
      [  108.424591]  i915_gem_execbuffer_reserve.isra.9+0x40e/0x440 [i915]
      [  108.424643]  i915_gem_do_execbuffer.isra.15+0x6d9/0x1b20 [i915]
      [  108.424696]  i915_gem_execbuffer2+0xc0/0x250 [i915]
      [  108.424712]  drm_ioctl+0x200/0x450
      [  108.424760]  ? i915_gem_execbuffer+0x330/0x330 [i915]
      [  108.424776]  do_vfs_ioctl+0x90/0x6e0
      [  108.424789]  ? up_read+0x1a/0x40
      [  108.424800]  ? trace_hardirqs_on_caller+0x122/0x1b0
      [  108.424813]  SyS_ioctl+0x3c/0x70
      [  108.424828]  entry_SYSCALL_64_fastpath+0x1c/0xb1
      [  108.424839] RIP: 0033:0x7f8235867357
      [  108.424848] RSP: 002b:00007ffdc14504c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      [  108.424866] RAX: ffffffffffffffda RBX: 00007ffdc1450600 RCX: 00007f8235867357
      [  108.424878] RDX: 00007ffdc14505a0 RSI: 0000000040406469 RDI: 0000000000000003
      [  108.424890] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000022
      [  108.424903] R10: 0000000000000007 R11: 0000000000000246 R12: 0000000000000002
      [  108.424915] R13: 0000000000419101 R14: 00007ffdc1450600 R15: 00007ffdc14505f0
      [  108.424928] Code: 45 b8 8b 4d c0 4c 89 f2 48 89 de ff d0 49 8b 07 4c 8b 45 b8 48 85 c0 75 dd 65 ff 0d d4 a1 c8 5f 0f 84 47 01 00 00 e9 0d fe ff ff <0f> 0b 45 31 f6 4c 8b 65 c8 49 8b 04 24 4d 39 ec 49 8d 9c 24 28
      [  108.425055] RIP: i915_gem_evict_for_node+0x237/0x410 [i915] RSP: ffffc90000a17a58
      
      Fixes: 172ae5b4 ("drm/i915: Fix i915_gem_evict_for_vma (soft-pinning)")
      Fixes: 606fec95 ("drm/i915: Prefer random replacement before eviction search")
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170111182132.19174-1-chris@chris-wilson.co.ukReviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      16ee2061
  2. 11 Jan, 2017 4 commits
    • Chris Wilson's avatar
      drm/i915: Add a sanity check that no request is submitted in the middle · c781c978
      Chris Wilson authored
      It is an error to start a new request on the same timeline (ringbuffer)
      as the current one before the current is submitted. If there are two
      requests emitting to the ringbuffer at the same time, the operation is
      undefined. We can catch this by checking for the timeline having a later
      seqno than ours when we come to submit our request.
      
      Currently we have this check at the end of __i915_add_request, but
      having an early check as well isolates a failure in the caller versus a
      failure in sealing the request (i.e. from inside __i915_add_request
      itself). For example, CI is currently tripping over this late assertion
      on ctg/ilk:
      
      [  100.329399] [IGT] gem_cs_tlb: starting subtest basic-default
      [  100.336333] ------------[ cut here ]------------
      [  100.336341] kernel BUG at drivers/gpu/drm/i915/i915_gem_request.c:908!
      [  100.336347] invalid opcode: 0000 [#1] PREEMPT SMP
      [  100.336351] Modules linked in: snd_hda_intel i915 snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm coretemp mei_me lpc_ich mei e1000e ptp pps_core [last unloaded: i915]
      [  100.336373] CPU: 0 PID: 6308 Comm: gem_cs_tlb Tainted: G     U          4.10.0-rc3-CI-CI_DRM_2045+ #1
      [  100.336380] Hardware name: LENOVO 7465CTO/7465CTO, BIOS 6DET44WW (2.08 ) 04/22/2009
      [  100.336386] task: ffff88012b738040 task.stack: ffffc90000560000
      [  100.336441] RIP: 0010:__i915_add_request+0x4aa/0x510 [i915]
      [  100.336445] RSP: 0018:ffffc90000563ac0 EFLAGS: 00010212
      [  100.336451] RAX: 0000000000005d52 RBX: ffff880133bb84c0 RCX: 0000000000000001
      [  100.336456] RDX: 0000000080000001 RSI: ffff88012b738860 RDI: 00000000ffffffff
      [  100.336461] RBP: ffffc90000563b00 R08: ffff880133bb8780 R09: 0000000000000000
      [  100.336466] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88012f53d950
      [  100.336472] R13: ffff88012a2b0af8 R14: ffff88012a5b0008 R15: ffff88012f53d960
      [  100.336477] FS:  00007f0d19da38c0(0000) GS:ffff88013bc00000(0000) knlGS:0000000000000000
      [  100.336483] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  100.336488] CR2: 00007f0d17706000 CR3: 000000012aa3e000 CR4: 00000000000406f0
      [  100.336496] Call Trace:
      [  100.336527]  i915_gem_switch_to_kernel_context+0x131/0x1b0 [i915]
      [  100.336559]  i915_gem_evict_vm+0x202/0x2b0 [i915]
      [  100.336590]  i915_gem_execbuffer_reserve.isra.9+0x3ae/0x440 [i915]
      [  100.336623]  i915_gem_do_execbuffer.isra.15+0x6d9/0x1b20 [i915]
      [  100.336656]  i915_gem_execbuffer2+0xc0/0x250 [i915]
      [  100.336666]  drm_ioctl+0x200/0x450
      [  100.336697]  ? i915_gem_execbuffer+0x330/0x330 [i915]
      [  100.336708]  do_vfs_ioctl+0x90/0x6e0
      [  100.336716]  ? up_read+0x1a/0x40
      [  100.336723]  ? trace_hardirqs_on_caller+0x122/0x1b0
      [  100.336730]  SyS_ioctl+0x3c/0x70
      [  100.336738]  entry_SYSCALL_64_fastpath+0x1c/0xb1
      [  100.336745] RIP: 0033:0x7f0d187cb357
      [  100.336750] RSP: 002b:00007ffe0b2f7c28 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      [  100.336761] RAX: ffffffffffffffda RBX: 00007ffe0b2f7d60 RCX: 00007f0d187cb357
      [  100.336768] RDX: 00007ffe0b2f7d00 RSI: 0000000040406469 RDI: 0000000000000003
      [  100.336775] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000022
      [  100.336782] R10: 0000000000000007 R11: 0000000000000246 R12: 0000000000000002
      [  100.336789] R13: 0000000000419101 R14: 00007ffe0b2f7d60 R15: 00007ffe0b2f7d50
      [  100.336797] Code: 5f 74 1e e9 d4 fb ff ff e8 bc 1e 9c e0 e9 ae fb ff ff 4c 89 e7 e8 77 22 fd ff e9 88 fd ff ff 0f 0b e8 a3 1e 9c e0 e9 b1 fb ff ff <0f> 0b 0f 0b e8 fd af ab e0 85 c0 75 c2 48 c7 c2 80 2c 71 a0 be
      [  100.336877] RIP: __i915_add_request+0x4aa/0x510 [i915] RSP: ffffc90000563ac0
      [  100.336886] ---[ end trace 22b36545479e5eb7 ]---
      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/20170111140858.1922-1-chris@chris-wilson.co.ukReviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      c781c978
    • Chris Wilson's avatar
      drm/i915: Prefer random replacement before eviction search · 606fec95
      Chris Wilson authored
      Performing an eviction search can be very, very slow especially for a
      range restricted replacement. For example, a workload like
      gem_concurrent_blit will populate the entire GTT and then cause aperture
      thrashing. Since the GTT is a mix of active and inactive tiny objects,
      we have to search through almost 400k objects before finding anything
      inside the mappable region, and as this search is required before every
      operation performance falls off a cliff.
      
      Instead of performing the full search, we do a trial replacement of the
      node at a random location fitting the specified restrictions. We lose
      the strict LRU property of the GTT in exchange for avoiding the slow
      search (several orders of runtime improvement for gem_concurrent_blit
      4KiB-global-gtt, e.g. from 5000s to 20s). The loss of LRU replacement is
      (later) mitigated firstly by only doing replacement if we find no
      freespace and secondly by execbuf doing a PIN_NONBLOCK search first before
      it starts thrashing (i.e. the random replacement will only occur from the
      already inactive set of objects).
      
      v2: Ascii-art, and check preconditionst
      v3: Rephrase final sentence in comment to explain why we don't bother
      with if (i915_is_ggtt(vm)) for preferring random replacement.
      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>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170111112312.31493-3-chris@chris-wilson.co.uk
      606fec95
    • Chris Wilson's avatar
      drm/i915: Extract reserving space in the GTT to a helper · 625d988a
      Chris Wilson authored
      Extract drm_mm_reserve_node + calling i915_gem_evict_for_node into its
      own routine so that it can be shared rather than duplicated.
      
      v2: Kerneldoc
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: igvt-g-dev@lists.01.org
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170111112312.31493-2-chris@chris-wilson.co.uk
      625d988a
    • Chris Wilson's avatar
      drm/i915: Use the MRU stack search after evicting · e007b19d
      Chris Wilson authored
      When we evict from the GTT to make room for an object, the hole we
      create is put onto the MRU stack inside the drm_mm range manager. On the
      next search pass, we can speed up a PIN_HIGH allocation by referencing
      that stack for the new hole.
      
      v2: Pull together the 3 identical implements (ahem, a couple were
      outdated) into a common routine for allocating a node and evicting as
      necessary.
      v3: Detect invalid calls to i915_gem_gtt_insert()
      v4: kerneldoc
      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/20170111112312.31493-1-chris@chris-wilson.co.uk
      e007b19d
  3. 10 Jan, 2017 25 commits
  4. 09 Jan, 2017 7 commits