#
b3949a9a |
| 30-Jul-2017 |
Hans Verkuil <hverkuil@xs4all.nl> |
drm/msm: fix WARN_ON in add_vma() with no iommu
While I was testing the upcoming adv7533 CEC support with my Dragonboard c410 I encountered this warning several times during boot:
[ 4.408309] WA
drm/msm: fix WARN_ON in add_vma() with no iommu
While I was testing the upcoming adv7533 CEC support with my Dragonboard c410 I encountered this warning several times during boot:
[ 4.408309] WARNING: CPU: 3 PID: 1347 at drivers/gpu/drm/msm/msm_gem.c:312 add_vma+0x78/0x88 [msm] [ 4.412951] Modules linked in: snd_soc_hdmi_codec adv7511 cec qcom_wcnss_pil msm mdt_loader drm_kms_helper msm_rng rng_core drm [ 4.421728] CPU: 3 PID: 1347 Comm: kworker/3:3 Not tainted 4.13.0-rc1-dragonboard #111 [ 4.433090] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 4.441081] Workqueue: events deferred_probe_work_func [ 4.447929] task: ffff800031243600 task.stack: ffff800003394000 [ 4.453023] PC is at add_vma+0x78/0x88 [msm] [ 4.458823] LR is at _msm_gem_new+0xd4/0x188 [msm] [ 4.463207] pc : [<ffff000000ac01f8>] lr : [<ffff000000ac06b4>] pstate: 40000145 [ 4.467811] sp : ffff8000033978a0 [ 4.475357] x29: ffff8000033978a0 x28: ffff8000031dea18 [ 4.478572] x27: ffff800003933a00 x26: ffff800003b39800 [ 4.483953] x25: ffff8000338ff800 x24: 0000000000000001 [ 4.489249] x23: 0000000000000000 x22: ffff800003b39800 [ 4.494544] x21: ffff8000338ff800 x20: 0000000000000000 [ 4.499839] x19: ffff800003932600 x18: 0000000000000001 [ 4.505135] x17: 0000ffff8969e9e0 x16: ffff7e00000ce7a0 [ 4.510429] x15: ffffffffffffffff x14: ffff8000833977ef [ 4.515724] x13: ffff8000033977f3 x12: 0000000000000038 [ 4.521020] x11: 0101010101010101 x10: ffffff7f7fff7f7f [ 4.526315] x9 : 0000000000000000 x8 : ffff800003932800 [ 4.531633] x7 : 0000000000000000 x6 : 000000000000003f [ 4.531644] x5 : 0000000000000040 x4 : 0000000000000000 [ 4.531650] x3 : ffff800031243600 x2 : 0000000000000000 [ 4.531655] x1 : 0000000000000000 x0 : 0000000000000000 [ 4.531670] Call trace: [ 4.531676] Exception stack(0xffff8000033976c0 to 0xffff8000033977f0) [ 4.531683] 76c0: ffff800003932600 0001000000000000 ffff8000033978a0 ffff000000ac01f8 [ 4.531688] 76e0: 0000000000000140 0000000000000000 ffff800003932550 ffff800003397780 [ 4.531694] 7700: ffff800003397730 ffff000008261ce8 0000000000000000 ffff8000031d2f80 [ 4.531699] 7720: ffff800003397800 ffff0000081d671c 0000000000000140 0000000000000000 [ 4.531705] 7740: ffff000000ac04c0 0000000000004003 ffff800003397908 00000000014080c0 [ 4.531710] 7760: 0000000000000000 ffff800003b39800 0000000000000000 0000000000000000 [ 4.531716] 7780: 0000000000000000 ffff800031243600 0000000000000000 0000000000000040 [ 4.531721] 77a0: 000000000000003f 0000000000000000 ffff800003932800 0000000000000000 [ 4.531726] 77c0: ffffff7f7fff7f7f 0101010101010101 0000000000000038 ffff8000033977f3 [ 4.531730] 77e0: ffff8000833977ef ffffffffffffffff [ 4.531881] [<ffff000000ac01f8>] add_vma+0x78/0x88 [msm] [ 4.532011] [<ffff000000ac06b4>] _msm_gem_new+0xd4/0x188 [msm] [ 4.532134] [<ffff000000ac1900>] msm_gem_new+0x10/0x18 [msm] [ 4.532260] [<ffff000000acb274>] msm_dsi_host_modeset_init+0x17c/0x268 [msm] [ 4.532384] [<ffff000000ac9024>] msm_dsi_modeset_init+0x34/0x1b8 [msm] [ 4.532504] [<ffff000000ab6168>] modeset_init+0x408/0x488 [msm] [ 4.532623] [<ffff000000ab6c4c>] mdp5_kms_init+0x2b4/0x338 [msm] [ 4.532745] [<ffff000000abeff8>] msm_drm_bind+0x218/0x4e8 [msm] [ 4.532755] [<ffff00000855d744>] try_to_bring_up_master+0x1f4/0x318 [ 4.532762] [<ffff00000855d900>] component_add+0x98/0x180 [ 4.532887] [<ffff000000ac8da0>] dsi_dev_probe+0x18/0x28 [msm] [ 4.532895] [<ffff000008565fe8>] platform_drv_probe+0x58/0xc0 [ 4.532901] [<ffff00000856410c>] driver_probe_device+0x324/0x458 [ 4.532907] [<ffff00000856440c>] __device_attach_driver+0xac/0x170 [ 4.532913] [<ffff000008561ef4>] bus_for_each_drv+0x4c/0x98 [ 4.532918] [<ffff000008563c38>] __device_attach+0xc0/0x160 [ 4.532924] [<ffff000008564530>] device_initial_probe+0x10/0x18 [ 4.532929] [<ffff000008562f84>] bus_probe_device+0x94/0xa0 [ 4.532934] [<ffff0000085635d4>] deferred_probe_work_func+0x8c/0xe8 [ 4.532941] [<ffff0000080d79bc>] process_one_work+0x1d4/0x330 [ 4.532946] [<ffff0000080d7b60>] worker_thread+0x48/0x468 [ 4.532952] [<ffff0000080ddae4>] kthread+0x12c/0x130 [ 4.532958] [<ffff000008082f10>] ret_from_fork+0x10/0x40 [ 4.532962] ---[ end trace b1ac6888ec40b0bb ]---
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
71e3dfa1 |
| 10-Jul-2017 |
Dan Carpenter <dan.carpenter@oracle.com> |
drm/msm: unlock on error in msm_gem_get_iova()
We recently added locking to this function but there was a direct return that was overlooked where we need to unlock.
Fixes: 0e08270a1f01 ("drm/msm: S
drm/msm: unlock on error in msm_gem_get_iova()
We recently added locking to this function but there was a direct return that was overlooked where we need to unlock.
Fixes: 0e08270a1f01 ("drm/msm: Separate locking of buffer resources from struct_mutex") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: v4.12 |
|
#
0e08270a |
| 13-Jun-2017 |
Sushmita Susheelendra <ssusheel@codeaurora.org> |
drm/msm: Separate locking of buffer resources from struct_mutex
Buffer object specific resources like pages, domains, sg list need not be protected with struct_mutex. They can be protected with a bu
drm/msm: Separate locking of buffer resources from struct_mutex
Buffer object specific resources like pages, domains, sg list need not be protected with struct_mutex. They can be protected with a buffer object level lock. This simplifies locking and makes it easier to avoid potential recursive locking scenarios for SVM involving mmap_sem and struct_mutex. This also removes unnecessary serialization when creating buffer objects, and also between buffer object creation and GPU command submission.
Signed-off-by: Sushmita Susheelendra <ssusheel@codeaurora.org> [robclark: squash in handling new locking for shrinker] Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
4b85f7f5 |
| 13-Jun-2017 |
Rob Clark <robdclark@gmail.com> |
drm/msm: support for an arbitrary number of address spaces
It means we have to do a list traversal where we once had an index into a table. But the list will normally have one or two entries.
Sign
drm/msm: support for an arbitrary number of address spaces
It means we have to do a list traversal where we once had an index into a table. But the list will normally have one or two entries.
Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
f4839bd5 |
| 13-Jun-2017 |
Rob Clark <robdclark@gmail.com> |
drm/msm: refactor how we handle vram carveout buffers
Pull some of the logic out into msm_gem_new() (since we don't need to care about the imported-bo case), and don't defer allocating pages. The l
drm/msm: refactor how we handle vram carveout buffers
Pull some of the logic out into msm_gem_new() (since we don't need to care about the imported-bo case), and don't defer allocating pages. The latter is generally a good idea, since if we are using VRAM carveout to allocate contiguous buffers (ie. no IOMMU), the allocation is more likely to fail. So failing at allocation time is a more sane option. Plus this simplifies things in the next patch.
Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
8bdcd949 |
| 13-Jun-2017 |
Rob Clark <robdclark@gmail.com> |
drm/msm: pass address-space to _get_iova() and friends
No functional change, that will come later. But this will make it easier to deal with dynamically created address spaces (ie. per- process pag
drm/msm: pass address-space to _get_iova() and friends
No functional change, that will come later. But this will make it easier to deal with dynamically created address spaces (ie. per- process pagetables for gpu).
Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
cb1e3818 |
| 13-Jun-2017 |
Rob Clark <robdclark@gmail.com> |
drm/msm: fix locking inconsistency for gpu->hw_init()
Most, but not all, paths where calling the with struct_mutex held. The fast-path in msm_gem_get_iova() (plus some sub-code-paths that only run
drm/msm: fix locking inconsistency for gpu->hw_init()
Most, but not all, paths where calling the with struct_mutex held. The fast-path in msm_gem_get_iova() (plus some sub-code-paths that only run the first time) was masking this issue.
So lets just always hold struct_mutex for hw_init(). And sprinkle some WARN_ON()'s and might_lock() to avoid this sort of problem in the future.
Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: v4.10.17, v4.10.16 |
|
#
90dd57de |
| 08-May-2017 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm: Take the mutex before calling msm_gem_new_impl
Amongst its other duties, msm_gem_new_impl adds the newly created GEM object to the shared inactive list which may also be actively modifiying
drm/msm: Take the mutex before calling msm_gem_new_impl
Amongst its other duties, msm_gem_new_impl adds the newly created GEM object to the shared inactive list which may also be actively modifiying the list during submission. All the paths to modify the list are protected by the mutex except for the one through msm_gem_import which can end up causing list corruption.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> [add extra WARN_ON(!mutex_is_locked(&dev->struct_mutex))] Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
2098105e |
| 17-May-2017 |
Michal Hocko <mhocko@kernel.org> |
drm: drop drm_[cm]alloc* helpers
Now that drm_[cm]alloc* helpers are simple one line wrappers around kvmalloc_array and drm_free_large is just kvfree alias we can drop them and replace by their nati
drm: drop drm_[cm]alloc* helpers
Now that drm_[cm]alloc* helpers are simple one line wrappers around kvmalloc_array and drm_free_large is just kvfree alias we can drop them and replace by their native forms.
This shouldn't introduce any functional change.
Changes since v1 - fix typo in drivers/gpu//drm/etnaviv/etnaviv_gem.c - noticed by 0day build robot
Suggested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Michal Hocko <mhocko@suse.com>drm: drop drm_[cm]alloc* helpers [danvet: Fixup vgem which grew another user very recently.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Christian König <christian.koenig@amd.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170517122312.GK18247@dhcp22.suse.cz
show more ...
|
Revision tags: v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2 |
|
#
0041ba39 |
| 07-Mar-2017 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm: Don't allow zero sized buffer objects
Zero sized buffer objects tend to make various bits of the GEM infrastructure complain:
WARNING: CPU: 1 PID: 2323 at drivers/gpu/drm/drm_mm.c:389 drm
drm/msm: Don't allow zero sized buffer objects
Zero sized buffer objects tend to make various bits of the GEM infrastructure complain:
WARNING: CPU: 1 PID: 2323 at drivers/gpu/drm/drm_mm.c:389 drm_mm_insert_node_generic+0x258/0x2f0 Modules linked in:
CPU: 1 PID: 2323 Comm: drm-api-test Tainted: G W 4.9.0-rc4-00906-g693af44 #213 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) task: ffff8000d7353400 task.stack: ffff8000d7720000 PC is at drm_mm_insert_node_generic+0x258/0x2f0 LR is at drm_vma_offset_add+0x4c/0x70
Zero sized buffers serve no appreciable value to the user so disallow them at create time.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
1a5dff5d |
| 07-Mar-2017 |
Jordan Crouse <jcrouse@codeaurora.org> |
drm/msm: Don't allow zero sized buffer objects
Zero sized buffer objects tend to make various bits of the GEM infrastructure complain:
WARNING: CPU: 1 PID: 2323 at drivers/gpu/drm/drm_mm.c:389 drm
drm/msm: Don't allow zero sized buffer objects
Zero sized buffer objects tend to make various bits of the GEM infrastructure complain:
WARNING: CPU: 1 PID: 2323 at drivers/gpu/drm/drm_mm.c:389 drm_mm_insert_node_generic+0x258/0x2f0 Modules linked in:
CPU: 1 PID: 2323 Comm: drm-api-test Tainted: G W 4.9.0-rc4-00906-g693af44 #213 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) task: ffff8000d7353400 task.stack: ffff8000d7720000 PC is at drm_mm_insert_node_generic+0x258/0x2f0 LR is at drm_vma_offset_add+0x4c/0x70
Zero sized buffers serve no appreciable value to the user so disallow them at create time.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: v4.10.1 |
|
#
11bac800 |
| 24-Feb-2017 |
Dave Jiang <dave.jiang@intel.com> |
mm, fs: reduce fault, page_mkwrite, and pfn_mkwrite to take only vmf
->fault(), ->page_mkwrite(), and ->pfn_mkwrite() calls do not need to take a vma and vmf parameter when the vma already resides i
mm, fs: reduce fault, page_mkwrite, and pfn_mkwrite to take only vmf
->fault(), ->page_mkwrite(), and ->pfn_mkwrite() calls do not need to take a vma and vmf parameter when the vma already resides in vmf.
Remove the vma parameter to simplify things.
[arnd@arndb.de: fix ARM build] Link: http://lkml.kernel.org/r/20170125223558.1451224-1-arnd@arndb.de Link: http://lkml.kernel.org/r/148521301778.19116.10840599906674778980.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com> Cc: Theodore Ts'o <tytso@mit.edu> Cc: Darrick J. Wong <darrick.wong@oracle.com> Cc: Matthew Wilcox <mawilcox@microsoft.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Jan Kara <jack@suse.com> Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v4.10 |
|
#
4e64e553 |
| 02-Feb-2017 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
The drm_mm range manager claimed to support top-down insertion, but it was neither searching for the top-most hole that could fit
drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
The drm_mm range manager claimed to support top-down insertion, but it was neither searching for the top-most hole that could fit the allocation request nor fitting the request to the hole correctly.
In order to search the range efficiently, we create a secondary index for the holes using either their size or their address. This index allows us to find the smallest hole or the hole at the bottom or top of the range efficiently, whilst keeping the hole stack to rapidly service evictions.
v2: Search for holes both high and low. Rename flags to mode. v3: Discover rb_entry_safe() and use it! v4: Kerneldoc for enum drm_mm_insert_mode.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Russell King <rmk+kernel@armlinux.org.uk> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Stephen Warren <swarren@wwwdotorg.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Eric Anholt <eric@anholt.net> Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> # vmwgfx Reviewed-by: Lucas Stach <l.stach@pengutronix.de> #etnaviv Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170202210438.28702-1-chris@chris-wilson.co.uk
show more ...
|
Revision tags: v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32 |
|
#
2c935bc5 |
| 14-Nov-2016 |
Peter Zijlstra <peterz@infradead.org> |
locking/atomic, kref: Add kref_read()
Since we need to change the implementation, stop exposing internals.
Provide kref_read() to read the current reference count; typically used for debug messages
locking/atomic, kref: Add kref_read()
Since we need to change the implementation, stop exposing internals.
Provide kref_read() to read the current reference count; typically used for debug messages.
Kills two anti-patterns:
atomic_read(&kref->refcount) kref->refcount.counter
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
#
de85d2b3 |
| 12-Jan-2017 |
Rob Clark <robdclark@gmail.com> |
drm/msm: fix potential null ptr issue in non-iommu case
Fixes: 9cb07b099fb ("drm/msm: support multiple address spaces") Reported-by: Riku Voipio <riku.voipio@linaro.org> Signed-off-by: Rob Clark <ro
drm/msm: fix potential null ptr issue in non-iommu case
Fixes: 9cb07b099fb ("drm/msm: support multiple address spaces") Reported-by: Riku Voipio <riku.voipio@linaro.org> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
1a29d85e |
| 14-Dec-2016 |
Jan Kara <jack@suse.cz> |
mm: use vmf->address instead of of vmf->virtual_address
Every single user of vmf->virtual_address typed that entry to unsigned long before doing anything with it so the type of virtual_address does
mm: use vmf->address instead of of vmf->virtual_address
Every single user of vmf->virtual_address typed that entry to unsigned long before doing anything with it so the type of virtual_address does not really provide us any additional safety. Just use masked vmf->address which already has the appropriate type.
Link: http://lkml.kernel.org/r/1479460644-25076-3-git-send-email-jack@suse.cz Signed-off-by: Jan Kara <jack@suse.cz> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
78babc16 |
| 11-Nov-2016 |
Rob Clark <robdclark@gmail.com> |
drm/msm: convert iova to 64b
For a5xx the gpu is 64b so we need to change iova to 64b everywhere. On the display side, iova is still 32b so it can ignore the upper bits. (Although all the armv8 dev
drm/msm: convert iova to 64b
For a5xx the gpu is 64b so we need to change iova to 64b everywhere. On the display side, iova is still 32b so it can ignore the upper bits. (Although all the armv8 devices have an iommu that can map 64b pa to 32b iova.)
Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6 |
|
#
667ce33e |
| 28-Sep-2016 |
Rob Clark <robdclark@gmail.com> |
drm/msm: support multiple address spaces
We can have various combinations of 64b and 32b address space, ie. 64b CPU but 32b display and gpu, or 64b CPU and GPU but 32b display. So best to decouple
drm/msm: support multiple address spaces
We can have various combinations of 64b and 32b address space, ie. 64b CPU but 32b display and gpu, or 64b CPU and GPU but 32b display. So best to decouple the device iova's from mmap offset.
Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
f54d1867 |
| 25-Oct-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
dma-buf: Rename struct fence to dma_fence
I plan to usurp the short name of struct fence for a core kernel struct, and so I need to rename the specialised fence/timeline for DMA operations to make r
dma-buf: Rename struct fence to dma_fence
I plan to usurp the short name of struct fence for a core kernel struct, and so I need to rename the specialised fence/timeline for DMA operations to make room.
A consensus was reached in https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html that making clear this fence applies to DMA operations was a good thing. Since then the patch has grown a bit as usage increases, so hopefully it remains a good thing!
(v2...: rebase, rerun spatch) v3: Compile on msm, spotted a manual fixup that I broke. v4: Try again for msm, sorry Daniel
coccinelle script: @@
@@ - struct fence + struct dma_fence @@
@@ - struct fence_ops + struct dma_fence_ops @@
@@ - struct fence_cb + struct dma_fence_cb @@
@@ - struct fence_array + struct dma_fence_array @@
@@ - enum fence_flag_bits + enum dma_fence_flag_bits @@
@@ ( - fence_init + dma_fence_init | - fence_release + dma_fence_release | - fence_free + dma_fence_free | - fence_get + dma_fence_get | - fence_get_rcu + dma_fence_get_rcu | - fence_put + dma_fence_put | - fence_signal + dma_fence_signal | - fence_signal_locked + dma_fence_signal_locked | - fence_default_wait + dma_fence_default_wait | - fence_add_callback + dma_fence_add_callback | - fence_remove_callback + dma_fence_remove_callback | - fence_enable_sw_signaling + dma_fence_enable_sw_signaling | - fence_is_signaled_locked + dma_fence_is_signaled_locked | - fence_is_signaled + dma_fence_is_signaled | - fence_is_later + dma_fence_is_later | - fence_later + dma_fence_later | - fence_wait_timeout + dma_fence_wait_timeout | - fence_wait_any_timeout + dma_fence_wait_any_timeout | - fence_wait + dma_fence_wait | - fence_context_alloc + dma_fence_context_alloc | - fence_array_create + dma_fence_array_create | - to_fence_array + to_dma_fence_array | - fence_is_array + dma_fence_is_array | - trace_fence_emit + trace_dma_fence_emit | - FENCE_TRACE + DMA_FENCE_TRACE | - FENCE_WARN + DMA_FENCE_WARN | - FENCE_ERR + DMA_FENCE_ERR ) ( ... )
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Acked-by: Sumit Semwal <sumit.semwal@linaro.org> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161025120045.28839-1-chris@chris-wilson.co.uk
show more ...
|
Revision tags: v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20 |
|
#
f755e227 |
| 29-Aug-2016 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm/msm: Remove call to reservation_object_test_signaled_rcu before wait
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a timeout of 0 becomes reservation_object_test_signaled_r
drm/msm: Remove call to reservation_object_test_signaled_rcu before wait
Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not need to handle such conversion in the caller. The only challenge are those callers that wish to differentiate the error code between the nonblocking busy check and potentially blocking wait.
v2: 9 is only 0 in German.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
#
d78d383a |
| 22-Aug-2016 |
Rob Clark <robdclark@gmail.com> |
drm/msm: protect against faults from copy_from_user() in submit ioctl
An evil userspace could try to cause deadlock by passing an unfaulted-in GEM bo as submit->bos (or submit->cmds) table. Which w
drm/msm: protect against faults from copy_from_user() in submit ioctl
An evil userspace could try to cause deadlock by passing an unfaulted-in GEM bo as submit->bos (or submit->cmds) table. Which will trigger msm_gem_fault() while we already hold struct_mutex. See:
https://github.com/freedreno/msmtest/blob/master/evilsubmittest.c
Cc: stable@vger.kernel.org Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1 |
|
#
0a677125 |
| 13-Jul-2016 |
Markus Elfring <elfring@users.sourceforge.net> |
drm/msm: Delete an unnecessary check before drm_gem_object_unreference()
The drm_gem_object_unreference() function tests whether its argument is NULL and then returns immediately. Thus the test arou
drm/msm: Delete an unnecessary check before drm_gem_object_unreference()
The drm_gem_object_unreference() 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: Rob Clark <robdclark@gmail.com>
show more ...
|
#
e73a8569 |
| 13-Jul-2016 |
Markus Elfring <elfring@users.sourceforge.net> |
drm/msm: Delete unnecessary checks before drm_gem_object_unreference_unlocked()
The drm_gem_object_unreference_unlocked() function tests whether its argument is NULL and then returns immediately. Th
drm/msm: Delete unnecessary checks before drm_gem_object_unreference_unlocked()
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 <elfring@users.sourceforge.net> Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|
Revision tags: openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12 |
|
#
e1e9db2c |
| 27-May-2016 |
Rob Clark <robdclark@gmail.com> |
drm/msm: wire up vmap shrinker
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
#
18f23049 |
| 26-May-2016 |
Rob Clark <robdclark@gmail.com> |
drm/msm: change gem->vmap() to get/put
Before we can add vmap shrinking, we really need to know which vmap'ings are currently being used. So switch to get/put interface. Stubbed put fxns for now.
drm/msm: change gem->vmap() to get/put
Before we can add vmap shrinking, we really need to know which vmap'ings are currently being used. So switch to get/put interface. Stubbed put fxns for now.
Signed-off-by: Rob Clark <robdclark@gmail.com>
show more ...
|