On Tue, Jul 16, 2013 at 3:11 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> 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@xxxxxxxx>
Reviewed-by: Rob Clark <robdclark@xxxxxxxxx>
> ---
> 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@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
