On 11/25/2014 02:08 AM, Zachary Reizner wrote: > After looking into removing platform_device, I found that using > dma_buf_attach with a NULL device always returns an error, thereby > preventing me from using VGEM for import and mmap. The solution seems > to be to skip using dma_buf_attach, and instead use dma_buf_mmap when > user-space tries to mmap a gem object that was imported into VGEM. The > drawback to this approach is that most drivers stub their > dma_buf_ops->mmap implementation. Presumably mmap could be implemented > for the drivers that this would make sense for. Are there any > comments, questions, or concerns for this proposed solution? I see now that this driver has entered -next, and I'm sorry this comment didn't arrive before. I simply missed this discussion :( My biggest concern, as stated many many times before, is that dma-buf mmap is a horrible interface for incoherent drivers, and for drivers that use odd format (tiled) dma-bufs, basically since it doesn't supply a dirtied region. Therefore (correct me if I'm wrong) there has been an agreement that for purposes outside of ARM SOC, we should simply not implement dma-buf mmap for other uses than for internal driver use. So assume a real driver implements dma-buf mmap, but it is crawling due to coherency- or untiling / tiling operations. How do you tell a generic user of the vgem driver *NOT* to mmap for performance reasons? Or is this driver only intended for ARM SOC systems? Thanks, Thomas _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
