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. Each client of dma_buf should 'map' the provided sgtable/scatterlist on its own. Only the client device driver has all knowledge to make a proper 'mapping'. Real physical devices usually will use dma_map_sg() for such operation, while some virtual ones will only create a kernel mapping for the provided scatterlist (like vivi with vmalloc memory module). Best regards -- Marek Szyprowski Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
