On Thu, Aug 4, 2011 at 7:34 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: > 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. for sure, I think we've ruled out putting this sort of stuff in 'struct dmabuf'.. (notwithstanding any data stuffed away in a 'void * priv' on some platform or another) > - 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. btw, on intel (or desktop platforms in general), could another device (say a USB webcam) DMA directly to a tiled buffer via the GART... ie. assuming you had some way to pre-fault some pages into the GART before the DMA happened. I was sort of expecting 'struct dmabuf' to basically just be a scatterlist and some fxn ptrs, nothing about TILING.. not sure if we need an fxn ptr to ask the buffer allocator to generate some pages/addresses that some other DMA engine could write to (so you could do something like pre-faulting the buffer into some sort of GART) and again release the pages/addresses when DMA completes. BR, -R >> (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
