1. 18 7月, 2016 1 次提交
    • C
      drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl) · 40777984
      Chris Wilson 提交于
      vGEM buffers are useful for passing data between software clients and
      hardware renders. By allowing the user to create and attach fences to
      the exported vGEM buffers (on the dma-buf), the user can implement a
      deferred renderer and queue hardware operations like flipping and then
      signal the buffer readiness (i.e. this allows the user to schedule
      operations out-of-order, but have them complete in-order).
      
      This also makes it much easier to write tightly controlled testcases for
      dma-buf fencing and signaling between hardware drivers.
      
      v2: Don't pretend the fences exist in an ordered timeline, but allocate
      a separate fence-context for each fence so that the fences are
      unordered.
      v3: Make the debug output more interesting, and show the signaled status.
      v4: Automatically signal the fence to prevent userspace from
      indefinitely hanging drivers.
      
      Testcase: igt/vgem_basic/dmabuf-fence
      Testcase: igt/vgem_slow/nohang
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Sean Paul <seanpaul@chromium.org>
      Cc: Zach Reizner <zachr@google.com>
      Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: NZach Reizner <zachr@google.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1468571471-12610-1-git-send-email-chris@chris-wilson.co.uk
      40777984
  2. 15 7月, 2016 8 次提交
  3. 14 7月, 2016 2 次提交
    • D
      Revert "drm: Resurrect atomic rmfb code" · 0dcac500
      Daniel Vetter 提交于
      This reverts commit 11c21e73.
      
      For reasons totally unclear this manages to wreak havoc with the audio
      rpm refcount:
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 215 at drivers/gpu/drm/i915/intel_runtime_pm.c:1729 intel_display_power_put+0xe8/0x100 [i915]
      Use count on domain AUDIO is already zero
      Modules linked in: i915 ax88179_178a usbnet mii snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec x86_pkg_temp_thermal snd_hwdep intel_powerclamp snd_hda_core co
      f_pclmul crc32_pclmul snd_pcm ghash_clmulni_intel mei_me mei e1000e ptp pps_core i2c_hid [last unloaded: i915]
      CPU: 0 PID: 215 Comm: kworker/0:2 Not tainted 4.7.0-rc6+ #44
      Hardware name: Intel Corporation Skylake Client platform/Skylake Halo DDR4 RVP11, BIOS SKLSE2R1.R00.X106.B00.1601180206 01/18/2016
      Workqueue: events output_poll_execute
       0000000000000000 ffff88045573fa38 ffffffff813a2d6b ffff88045573fa88
       0000000000000000 ffff88045573fa78 ffffffff81075db6 000006c15a590000
       ffff88045a59a238 ffff88045a590054 ffff88045a590000 ffff88045a590000
      Call Trace:
       [<ffffffff813a2d6b>] dump_stack+0x4d/0x72
       [<ffffffff81075db6>] __warn+0xc6/0xe0
       [<ffffffff81075e1a>] warn_slowpath_fmt+0x4a/0x50
       [<ffffffffa046399d>] ? hsw_audio_codec_disable+0xdd/0x110 [i915]
       [<ffffffffa041e638>] intel_display_power_put+0xe8/0x100 [i915]
       [<ffffffffa049d776>] intel_disable_ddi+0x46/0x80 [i915]
       [<ffffffffa0474eef>] haswell_crtc_disable+0x16f/0x290 [i915]
       [<ffffffffa047cb53>] intel_atomic_commit_tail+0x153/0x10e0 [i915]
       [<ffffffff814aa020>] ? drm_atomic_helper_swap_state+0x140/0x2d0
       [<ffffffffa047dedd>] intel_atomic_commit+0x3fd/0x520 [i915]
       [<ffffffff814d0252>] ? drm_atomic_add_affected_connectors+0x22/0xf0
       [<ffffffff814cf8a2>] drm_atomic_commit+0x32/0x50
       [<ffffffff814aed07>] restore_fbdev_mode+0x147/0x260
       [<ffffffff814b026e>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2e/0x70
       [<ffffffff814b02d8>] drm_fb_helper_set_par+0x28/0x50
       [<ffffffff814b0203>] drm_fb_helper_hotplug_event+0x143/0x180
       [<ffffffffa0498ab5>] intel_fbdev_output_poll_changed+0x15/0x20 [i915]
       [<ffffffff814a1f92>] drm_kms_helper_hotplug_event+0x22/0x30
       [<ffffffff814a2172>] output_poll_execute+0x192/0x1e0
       [<ffffffff8108cf7c>] process_one_work+0x14c/0x480
       [<ffffffff8108d4fa>] worker_thread+0x24a/0x4e0
       [<ffffffff8108d2b0>] ? process_one_work+0x480/0x480
       [<ffffffff8108d2b0>] ? process_one_work+0x480/0x480
       [<ffffffff81092904>] kthread+0xc4/0xe0
       [<ffffffff8173013f>] ret_from_fork+0x1f/0x40
       [<ffffffff81092840>] ? kthread_worker_fn+0x180/0x180
      ---[ end trace 2d440da5f0c053e4 ]---
      
      Instead of scratching heads too much while CI is down, let's revert
      before more trouble is caused.
      
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reported-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: NMika Kuoppala <mika.kuoppala@intel.com>
      Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1468502194-17029-1-git-send-email-daniel.vetter@ffwll.ch
      0dcac500
    • C
      drm: Don't overwrite user ioctl arg unless requested · 01d3434a
      Chris Wilson 提交于
      Currently, we completely ignore the user when it comes to the in/out
      direction of the ioctl argument, as we simply cannot trust userspace.
      (For example, they might request a copy of the modified ioctl argument
      when the driver is not expecting such and so leak kernel stack.)
      However, blindly copying over the target address may also lead to a
      spurious EFAULT, and a failure after the ioctl was completed
      successfully. This is important in order to avoid an ABI break when
      extending an ioctl from IOR to IORW. Similar to how we only copy the
      intersection of the kernel arg size and the user arg size, we only want
      to copy back the kernel arg data iff both the kernel and userspace
      request the copy.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1468335590-21023-1-git-send-email-chris@chris-wilson.co.uk
      01d3434a
  4. 13 7月, 2016 3 次提交
  5. 12 7月, 2016 26 次提交