1. 04 Sep, 2017 5 commits
    • Ville Syrjälä's avatar
      drm/i915: io unmap functions want __iomem · afe722be
      Ville Syrjälä authored
      Don't cast away the __iomem from the io_mapping functions so that
      sparse won't be so unhappy when we pass the pointer to the unmap
      functions. Instead let's move the cast to where we actually use the
      pointer.
      
      Fixes the following sparse warnings:
      i915_gem.c:1022:33: warning: incorrect type in argument 1 (different address spaces)
      i915_gem.c:1022:33:    expected void [noderef] <asn:2>*vaddr
      i915_gem.c:1022:33:    got void *[assigned] vaddr
      i915_gem.c:1027:34: warning: incorrect type in argument 1 (different address spaces)
      i915_gem.c:1027:34:    expected void [noderef] <asn:2>*vaddr
      i915_gem.c:1027:34:    got void *[assigned] vaddr
      i915_gem.c:1199:33: warning: incorrect type in argument 1 (different address spaces)
      i915_gem.c:1199:33:    expected void [noderef] <asn:2>*vaddr
      i915_gem.c:1199:33:    got void *[assigned] vaddr
      i915_gem.c:1204:34: warning: incorrect type in argument 1 (different address spaces)
      i915_gem.c:1204:34:    expected void [noderef] <asn:2>*vaddr
      i915_gem.c:1204:34:    got void *[assigned] vaddr
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170901171252.31025-2-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      afe722be
    • Ville Syrjälä's avatar
      drm/i915: Add __rcu to radix tree slot pointer · c23aa71b
      Ville Syrjälä authored
      radix_tree_for_each_slot() wants an __rcu annotated pointer for the
      slot. So let's add the annotation.
      
      Fixes the following sparse warnings:
      i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
      i915_gem.c:2217:9:    expected void **slot
      i915_gem.c:2217:9:    got void [noderef] <asn:4>**
      i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
      i915_gem.c:2217:9:    expected void **slot
      i915_gem.c:2217:9:    got void [noderef] <asn:4>**
      i915_gem.c:2217:9: warning: incorrect type in argument 1 (different address spaces)
      i915_gem.c:2217:9:    expected void [noderef] <asn:4>**slot
      i915_gem.c:2217:9:    got void **slot
      i915_gem.c:2217:9: warning: incorrect type in assignment (different address spaces)
      i915_gem.c:2217:9:    expected void **slot
      i915_gem.c:2217:9:    got void [noderef] <asn:4>**
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Fixes: 96d77634 ("drm/i915: Use a radixtree for random access to the object's backing storage")
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170901171252.31025-1-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      c23aa71b
    • Ville Syrjälä's avatar
      drm/i915: Wake up the device for the fbdev setup · c6364232
      Ville Syrjälä authored
      Our fbdev setup requires the device to be awake for access
      through the GTT. If one boots without connected displays and
      later plugs one in, we won't have any runtime PM references when
      the fbdev setup runs. Explicitly grab a runtime PM reference during
      the fbdev setup to avoid the following spew:
      
      [   62.518435] RPM wakelock ref not held during HW access
      [   62.518459] ------------[ cut here ]------------
      [   62.518546] WARNING: CPU: 3 PID: 37 at ../drivers/gpu/drm/i915/intel_drv.h:1800 i915_vma_pin_iomap+0x144/0x150 [i915]
      [   62.518585] Modules linked in: i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm intel_gtt agpgart netconsole nls_iso8859_1 nls_cp437 vfat fat efi_pstore coretemp hwmon intel_rapl x86_pkg_temp_thermal e1000e efivars ptp pps_core video evdev ip_tables x_tables ipv6 autofs4
      [   62.518741] CPU: 3 PID: 37 Comm: kworker/3:1 Not tainted 4.13.0-rc7-skl+ #1077
      [   62.518770] Hardware name:                  /NUC7i5BNB, BIOS BNKBL357.86A.0048.2017.0704.1415 07/04/2017
      [   62.518827] Workqueue: events i915_hotplug_work_func [i915]
      [   62.518853] task: ffff88046c00dc00 task.stack: ffffc90000184000
      [   62.518896] RIP: 0010:i915_vma_pin_iomap+0x144/0x150 [i915]
      [   62.518919] RSP: 0018:ffffc90000187cc8 EFLAGS: 00010292
      [   62.518942] RAX: 000000000000002a RBX: ffff880460044000 RCX: 0000000000000006
      [   62.518969] RDX: 0000000000000006 RSI: ffffffff819c3e6f RDI: ffffffff819f1c0e
      [   62.518996] RBP: ffffc90000187cd8 R08: ffff88046c00e4f0 R09: 0000000000000000
      [   62.519022] R10: ffff8804669ca800 R11: 0000000000000000 R12: ffff880461d20000
      [   62.519049] R13: ffffc90000187d48 R14: ffff880461d20000 R15: ffff880460044000
      [   62.519076] FS:  0000000000000000(0000) GS:ffff88047ed80000(0000) knlGS:0000000000000000
      [   62.519107] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   62.519130] CR2: 000056478ae213f0 CR3: 0000000002c0f000 CR4: 00000000003406e0
      [   62.519156] Call Trace:
      [   62.519190]  intelfb_create+0x176/0x360 [i915]
      [   62.519216]  __drm_fb_helper_initial_config_and_unlock+0x1c7/0x3c0 [drm_kms_helper]
      [   62.519251]  drm_fb_helper_hotplug_event.part.18+0xac/0xc0 [drm_kms_helper]
      [   62.519282]  drm_fb_helper_hotplug_event+0x1a/0x20 [drm_kms_helper]
      [   62.519324]  intel_fbdev_output_poll_changed+0x1a/0x20 [i915]
      [   62.519352]  drm_kms_helper_hotplug_event+0x27/0x30 [drm_kms_helper]
      [   62.519395]  i915_hotplug_work_func+0x24e/0x2b0 [i915]
      [   62.519420]  process_one_work+0x1d3/0x6d0
      [   62.519440]  worker_thread+0x4b/0x400
      [   62.519458]  ? schedule+0x4a/0x90
      [   62.519475]  ? preempt_count_sub+0x97/0xf0
      [   62.519495]  kthread+0x114/0x150
      [   62.519511]  ? process_one_work+0x6d0/0x6d0
      [   62.519530]  ? kthread_create_on_node+0x40/0x40
      [   62.519551]  ret_from_fork+0x27/0x40
      [   62.519569] Code: c4 78 e6 e0 0f ff e9 08 ff ff ff 80 3d d5 bc 0c 00 00 0f 85 0b ff ff ff 48 c7 c7 d8 50 32 a0 c6 05 c1 bc 0c 00 01 e8 9d 78 e6 e0 <0f> ff e9 f1 fe ff ff 0f 1f 44 00 00 0f 1f 44 00 00 0f b6 87 98
      [   62.519771] ---[ end trace 5fbe271f991a58ae ]---
      Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170901195456.6386-1-ville.syrjala@linux.intel.comReviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      c6364232
    • Changbin Du's avatar
      drm/i915: Add interface to reserve fence registers for vGPU · 969b0950
      Changbin Du authored
      In the past, vGPU alloc fence registers by walking through mm.fence_list
      to find fence which pin_count = 0 and vma is empty. vGPU may not find
      enough fence registers this way. Because a fence can be bind to vma even
      though it is not in using. We have found such failure many times these
      days.
      
      An option to resolve this issue is that we can force-remove fence from
      vma in this case.
      
      This patch added two new api to the fence management code:
       - i915_reserve_fence() will try to find a free fence from fence_list
         and force-remove vma if need.
       - i915_unreserve_fence() reclaim a reserved fence after vGPU has
         finished.
      
      With this change, the fence management is more clear to work with vGPU.
      GVTg do not need remove fence from fence_list in private.
      
      v3: (Chris)
        - Add struct_mutex lock assertion.
        - Only count for unpinned fence.
      
      v2: (Chris)
        - Rename the new api for symmetry.
        - Add safeguard to ensure at least 1 fence remained for host display.
      Signed-off-by: default avatarChangbin Du <changbin.du@intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Link: https://patchwork.freedesktop.org/patch/msgid/1504512061-5892-1-git-send-email-changbin.du@intel.comAcked-by: default avatarZhenyu Wang <zhenyuw@linux.intel.com>
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      969b0950
    • Thierry Reding's avatar
      drm/i915: Use correct path to trace include · 4e6d7719
      Thierry Reding authored
      The header comment in include/trace/define_trace.h specifies that the
      TRACE_INCLUDE_PATH needs to be relative to the define_trace.h header
      rather than the trace file including it. Most instances get that wrong
      and work around it by adding the $(src) directory to the include path.
      
      While this works, it is preferable to refer to the correct path to the
      trace file in the first place and avoid any workaround.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Acked-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20170901144954.19620-4-thierry.reding@gmail.com
      4e6d7719
  2. 02 Sep, 2017 1 commit
  3. 01 Sep, 2017 10 commits
  4. 31 Aug, 2017 18 commits
  5. 30 Aug, 2017 3 commits
  6. 29 Aug, 2017 3 commits