On Thu, Aug 4, 2011 at 13:14, Clark, Rob <rob@xxxxxx> wrote: > hmm, there would be a dmabuf->private ptr in struct dmabuf. Normally > that should be for private data of the buffer allocator, but I guess > it could be (ab)used for under the hood communication between drivers > a platform specific way. It does seem a bit hacky, but at least it > does not need to be exposed to userspace. An idea that just crossed my mind: I think we should seperate two kinds of meta-data about a shared piece of data (dmabuf): - logical metadata about it's contents, like strides, number of dimensions, pixel format/vbo layout, ... Imo that stuff doesn't belong into the buffer sharing simply because it's an a) awful mess and b) gem doesn't know it. To recap: only userspace knows this stuff and has to make sense of the data in the buffer by either setting up correct gpu command streams or telling kms what format this thing it needs to scan out has. - metadata about the physical layout: tiling layout, memory bank interleaving, page size for the iommu/contiguous buffer. As far as I can tell (i.e. please correct) for embedded systems this just depends on the (in)saneness of to iommu/bus/memory controller sitting between the ic block and it's data. So it would be great if we could completely hide this from drivers (and userspace) an shovel it into the dma subsystem (as private data). Unfortunately at least on Intel tiling needs to be known by the iommu code, the core gem kernel driver code and the userspace drivers. Otoh using tiled buffers for sharing is maybe a bit ambitious for the first cut. So maybe we can just ignore tiling which largely just leaves handling iommus restrictions (or their complete lack) which looks doable. > (Or maybe a better option is just 'rm -rf omx' ;-)) Yeah ;-) -Daniel -- Daniel Vetter daniel.vetter@xxxxxxxx - +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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
