i915 dma_map_sg return value

[Daniel Vetter]

On Tue, May 05, 2015 at 07:19:57PM +0200, Volker Vogelhuber wrote:
> On 05.05.2015 17:51, Daniel Vetter wrote:
> >On Tue, May 05, 2015 at 09:42:44AM +0200, Volker Vogelhuber wrote:
> >>The documentation of the DMA-API writes the following about
> >>dma_map_sg:
> >>
> >>"The implementation is free to merge several consecutive sglist entries
> >>into one (e.g. if DMA mapping is done with PAGE_SIZE granularity, any
> >>consecutive sglist entries can be merged into one provided the first one
> >>ends and the second one starts on a page boundary - in fact this is a huge
> >>advantage for cards which either cannot do scatter-gather or have very
> >>limited number of scatter-gather entries) and returns the actual number
> >>of sg entries it mapped them to."
> >>
> >>I wonder why the return value of dma_map_sg is not returned in any way
> >>from i915_gem_map_dma_buf. It only uses the return value for error
> >>checking.
> >>Can one be sure that in case of the i915 the nents value of the scatter
> >>gather table is always equal to the value returned by dma_map_sg?
> >>I'm asking because I want to use the sg table returned by
> >>i915_gem_map_dma_buf in my own kernel module and iterate over it
> >>using for_each_sg. And the example in the documentation of the DMA-API
> >>uses the return value of dma_map_sg when calling for_each_sg and not
> >>nents and it explicitly mentions:
> >>
> >>"Then you should loop count times (note: this can be less than nents times)"
> >Hm, not looking at the return value of dma_map_sg is also how we use it
> >internally in i915_gem_gtt.c. Not sure why we get away with this ...
> Maybe you can be sure that on systems where the i915 driver is
> used no reduction of the nents will be done by dma_map_sg?

Not sure that's true. But we do use for_each_sg_page, which might be
immune to coallescing issue. But tbh I have no idea.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch