drm/mm: Document locking rules
authorDaniel Vetter <daniel.vetter@ffwll.ch>
Tue, 27 Dec 2016 10:10:57 +0000 (11:10 +0100)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Wed, 28 Dec 2016 13:05:20 +0000 (14:05 +0100)
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: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: s/alloc|freeing/modifications/ per Chris' suggestion.]
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1482833457-29592-1-git-send-email-daniel.vetter@ffwll.ch
drivers/gpu/drm/drm_mm.c

index 58a7e3bbe13079264772e0fd0b410a98bcd310c1..713f4336107f09b55980da6a9d49545c7a78b127 100644 (file)
  *
  * Finally iteration helpers to walk all nodes and all holes are provided as are
  * 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,