Re: [RFCv1 2/4] v4l:vb2: add support for shared buffer (dma_buf)

[Daniel Vetter <daniel@ffwll.ch>]

On Mon, Jan 23, 2012 at 10:06:57AM +0100, Marek Szyprowski wrote:
> Hello,
> 
> On Friday, January 20, 2012 5:29 PM Laurent Pinchart wrote:
> 
> > On Friday 20 January 2012 17:20:22 Tomasz Stanislawski wrote:
> > > >> IMO, One way to do this is adding field 'struct device *dev' to struct
> > > >> vb2_queue. This field should be filled by a driver prior to calling
> > > >> vb2_queue_init.
> > > >
> > > > I haven't looked into the details, but that sounds good to me. Do we have
> > > > use cases where a queue is allocated before knowing which physical
> > > > device it will be used for ?
> > >
> > > I don't think so. In case of S5P drivers, vb2_queue_init is called while
> > > opening /dev/videoX.
> > >
> > > BTW. This struct device may help vb2 to produce logs with more
> > > descriptive client annotation.
> > >
> > > What happens if such a device is NULL. It would happen for vmalloc
> > > allocator used by VIVI?
> > 
> > Good question. Should dma-buf accept NULL devices ? Or should vivi pass its
> > V4L2 device to vb2 ?
> 
> I assume you suggested using struct video_device->dev entry in such case. 
> It will not work. DMA-mapping API requires some parameters to be set for the 
> client device, like for example dma mask. struct video_device contains only an
> artificial struct device entry, which has no relation to any physical device 
> and cannot be used for calling DMA-mapping functions.
> 
> Performing dma_map_* operations with such artificial struct device doesn't make
> any sense. It also slows down things significantly due to cache flushing 
> (forced by dma-mapping) which should be avoided if the buffer is accessed only 
> with CPU (like it is done by vb2-vmalloc style drivers).
> 
> IMHO this case perfectly shows the design mistake that have been made. The
> current version simply tries to do too much. 

Nope, the current dma_buf does too little. Atm it's simple not useable for
drivers that need cpu access, at least not if you're willing to resort to
ugly an non-portable tricks like prime.

We've discussed this quite a bit and decided that solving cpu access and
coherency with n other devices involved is too much v1. It looks like we
need to add that extension rather sooner than later.
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48