- 18 Jul, 2016 27 commits
-
-
Chris Wilson authored
If we fail to create the anon file, we need to remember to release the module reference on the owner. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1468840582-21469-1-git-send-email-chris@chris-wilson.co.uk
-
Tobias Jakobi authored
Currently enabling ARM HDLCD DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Signed-off-by:
-
Tobias Jakobi authored
Currently enabling AST Server DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling VirtIO DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling USB DisplayLink DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling Bochs DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling Freescale DCU DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling TI LCDC DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling Intel GMA DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling SH Mobile DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling Freescale i.MX DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling QXL DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling QEMU Cirrus DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling MGA G200 DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling OMAP DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling Marvell Armada DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling ARC DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Markus Elfring authored
The drm_gem_object_unreference_unlocked() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
Markus Elfring authored
The drm_fbdev_cma_hotplug_event() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The drm_gem_object_unreference_unlocked() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The vunmap() function performs also input parameter validation. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The drm_gem_object_unreference_unlocked() function tests whether its argument is NULL and then returns immediately. Thus the test around the calls is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The drm_fbdev_cma_hotplug_event() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The following functions test whether their argument is NULL and then return immediately. * drm_fbdev_cma_hotplug_event * drm_fbdev_cma_restore_mode Thus the tests around their calls are not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The drm_gem_object_unreference_unlocked() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Markus Elfring authored
The drm_gem_object_unreference_unlocked() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by:
-
Chris Wilson authored
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:
Zach Reizner <zachr@google.com> Signed-off-by:
-
- 15 Jul, 2016 8 commits
-
-
Tobias Jakobi authored
Currently enabling Nouveau DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
Sean Paul <seanpaul@chromium.org>
-
Tobias Jakobi authored
Currently enabling ATMEL HLCDC DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling R-Car DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Tobias Jakobi authored
Currently enabling Rockchip DRM support automatically pulls in fbdev dependency. However this dep is unnecessary since DRM core already handles this for us (DRM_FBDEV_EMULATION). Signed-off-by:
-
Peter Chen authored
of_node_put needs to be called when the device node which is got from of_parse_phandle has finished using. Cc: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by:
Peter Chen <peter.chen@nxp.com> Signed-off-by:
-
Peter Chen authored
of_node_put needs to be called when the device node which is got from of_parse_phandle has finished using. Cc: Joonyoung Shim <jy0922.shim@samsung.com> Cc: Seung-Woo Kim <sw0312.kim@samsung.com> Cc: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
-
Peter Chen authored
of_node_put needs to be called when the device node which is got from of_parse_phandle has finished using. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Peter Chen authored
of_node_put needs to be called when the device node which is got from of_parse_phandle has finished using. Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
- 14 Jul, 2016 2 commits
-
-
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:
Mika Kuoppala <mika.kuoppala@intel.com> Reported-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
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:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
- 13 Jul, 2016 3 commits
-
-
Gustavo Padovan authored
We've got a complaint saying that the description was quite obtuse and indeed it was. This patch tries to improve it. Cc: Dave Jones <davej@codemonkey.org.uk> Signed-off-by:
Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org>
-
Gustavo Padovan authored
Add Gustavo as maintainer for the Sync File Framework. Sumit is co-maintainer as he maintains drivers/dma-buf/. It also uses Sumit's tree as base. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
This was somehow lost between v3 and the merged version in Maarten's patch merged as: commit f2d580b9 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Wed May 4 14:38:26 2016 +0200 drm/core: Do not preserve framebuffer on rmfb, v4. Actual code copied from Maarten's patch, but with the slight change to just use dev->mode_config.funcs->atomic_commit to decide whether to use the atomic path or not. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
