Re: [RFCv2 PATCH 7/9] v4l: vb2-dma-contig: change map/unmap behaviour

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Daniel,

On Thursday 22 March 2012 13:25:20 Daniel Vetter wrote:
> On Thu, Mar 22, 2012 at 13:15, Laurent Pinchart wrote:
> > On Tuesday 13 March 2012 11:17:05 Tomasz Stanislawski wrote:
> >> The DMABUF documentation says that the map_dma_buf callback should return
> >> scatterlist that is mapped into a caller's address space. In practice,
> >> almost none of existing implementations of DMABUF exporter does it.  This
> >> patch breaks the DMABUF specification in order to allow exchange DMABUF
> >> buffers between other APIs like DRM.
> > 
> > Then it's time to fix the spec, and squash 6/9 and 7/9 together (I started
> > reviewing 6/9 and the implementation puzzled me until I saw the "fixes" in
> > 7/9).
> 
> Nope. The drm proof of concept stuff that just grabbed the struct
> pages pointers from the sg_table has always just been a gross hack to
> get things of the ground. With proper kernel cpu access and mmap
> support we can ditch these, and Dave Airlie has already started with
> that:
> 
> http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-dmabuf2
> 
> Furthermore the kernel cpu access helpers are designed to just plug
> into the corresponding ttm helpers. It'll be slightly more messy for
> drm/i915 and udl because they don't use ttm.
> 
> And the afaik the proof of concept stuff from Rob Clark very much
> depends upon handing out addresses in the targets device address
> space. And there are other scenarios that just require this, besides
> that it makes imo more sense from an api design pov.

Let's continue this discussion in the "[Linaro-mm-sig] Minutes from V4L2 
update call" mail thread if you don't mind to avoid scattering the topic all 
over. I've listed the two options there (mapping the buffer to the importer 
device's address space in the export driver or the importer driver).

-- 
Regards,

Laurent Pinchart