Commit 1c9bd1ed authored by Daniel Vetter's avatar Daniel Vetter

drm/mm: Document locking rules

Drivers need to take care. Motivated by a discussion between Mark and
Rob on dri-devel.

Cc: Mark yao <mark.yao@rock-chips.com>
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
[danvet: s/alloc|freeing/modifications/ per Chris' suggestion.]
Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1482833457-29592-1-git-send-email-daniel.vetter@ffwll.ch
parent adb040b8
...@@ -90,6 +90,11 @@ ...@@ -90,6 +90,11 @@
* *
* Finally iteration helpers to walk all nodes and all holes are provided as are * Finally iteration helpers to walk all nodes and all holes are provided as are
* some basic allocator dumpers for debugging. * some basic allocator dumpers for debugging.
*
* Note that this range allocator is not thread-safe, drivers need to protect
* modifications with their on locking. The idea behind this is that for a full
* memory manager additional data needs to be protected anyway, hence internal
* locking would be fully redundant.
*/ */
static struct drm_mm_node *drm_mm_search_free_in_range_generic(const struct drm_mm *mm, static struct drm_mm_node *drm_mm_search_free_in_range_generic(const struct drm_mm *mm,
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment