On Tue, Sep 04, 2012 at 09:03:03PM +0100, Chris Wilson wrote: > This will be used i915 in forthcoming patches in order to measure the > largest contiguous chunk of memory available for enabling chipset > features. > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk> > Cc: Dave Airlie <airlied at redhat.com> One nitpick below. > @@ -99,6 +112,19 @@ static inline bool drm_mm_initialized(struct drm_mm *mm) > entry != NULL; entry = next, \ > next = entry ? list_entry(entry->node_list.next, \ > struct drm_mm_node, node_list) : NULL) \ > + > +/* Note that we need to unroll list_for_each_entry in order to inline > + * setting hole_start and hole_end on each iteration and keep the > + * macro sane. > + */ > +#define drm_mm_for_each_hole(entry, mm, hole_start, hole_end) \ > + for (entry = list_entry((mm)->hole_stack.next, typeof(struct drm_mm_node), hole_stack); \ > + &entry->hole_stack != &(mm)->hole_stack ? \ > + hole_start = drm_mm_hole_node_start(entry), \ > + hole_end = drm_mm_hole_node_end(entry) : \ > + 0; \ > + entry = list_entry(entry->hole_stack.next, typeof(struct drm_mm_node), hole_stack)) Minor bikeshed for the macro: - typeof(struct drm_mm_node) is a bit redundant - I'd add a , 1 to the conditional check to not implicitly rely on drm_mm_hole_node_end != 0 for the correctness of this macro. With that this is: Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch> To follow due process can you please resubmit these two drm_mm patches to dri-devel, so that I can properly bugger Dave for his maintainer-ack? Thanks, Daniel > + > /* > * Basic range manager support (drm_mm.c) > */ > -- > 1.7.10.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
