1. 18 Jul, 2016 19 commits
  2. 15 Jul, 2016 8 commits
  3. 14 Jul, 2016 2 commits
    • Daniel Vetter's avatar
      Revert "drm: Resurrect atomic rmfb code" · 0dcac500
      Daniel Vetter authored
      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: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Reported-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Acked-by: default avatarMika Kuoppala <mika.kuoppala@intel.com>
      Acked-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1468502194-17029-1-git-send-email-daniel.vetter@ffwll.ch
      0dcac500
    • Chris Wilson's avatar
      drm: Don't overwrite user ioctl arg unless requested · 01d3434a
      Chris Wilson authored
      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: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarDaniel 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 Jul, 2016 3 commits
  5. 12 Jul, 2016 8 commits