On Tue, Jul 16, 2013 at 3:11 AM, Daniel Vetter daniel.vetter@ffwll.ch wrote:
Lifetime rules seem to be solid around ->import_attach. So this patch just properly documents them.
Note that pointing directly at the attachment might have issues for devices that have multiple struct device *dev parts constituting the logical gpu and so might need multiple attachment points. Similarly for drm devices which don't need a dma attachment at all (like udl).
yeah, with msm drm driver, that might become (eventually) an issue. (But not yet, because they seem to use iommu<->dev attachment in a.. slightly different way)
But fixing that up is material for different patches.
Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch
Reviewed-by: Rob Clark robdclark@gmail.com
include/drm/drmP.h | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h index cd57646..baf030c 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -681,7 +681,16 @@ struct drm_gem_object { /* dma buf exported from this GEM object */ struct dma_buf *export_dma_buf;
/* dma buf attachment backing this object */
/**
* import_attach - dma buf attachment backing this object
*
* Any foreign dma_buf imported as a gem object has this set to the
* attachment point for the device. This is invariant over the lifetime
* of a gem object.
*
* The driver's ->gem_free_object callback is responsible for cleaning
* up the dma_buf attachment and references acquired at import time.
*/ struct dma_buf_attachment *import_attach;
};
-- 1.8.3.2
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel