On Thu, Aug 25, 2011 at 12:22 AM, Sumit Semwal sumit.semwal@linaro.org wrote:
Hi Rob, On 25 August 2011 06:33, Clark, Rob rob@ti.com wrote:
On Wed, Aug 10, 2011 at 7:11 AM, Sumit Semwal sumit.semwal@ti.com wrote:
+/**
- struct dma_buf - shared buffer object
- @file: file pointer used for sharing buffers across, and for
refcounting.
- @ops: dma_buf_ops associated with this buffer object
- @priv: user specific private data
- */
+struct dma_buf {
- struct file *file;
- struct dma_buf_ops *ops;
- void *priv;
+};
hmm, I wonder if we should stuff a ptr in there to store the creating driver (or device?) ptr? This way if it somehow gets passed back to the creating driver, it could realize that it is a dma_buf that it created in the first place.. and that it was safe to cast and deref the priv ptr.
Hmmm... Do you mean the platform driver (device?) ptr? That's a good idea - I will make these changes you suggested, and re-post. I'm thinking of posting the next version to the upstream mailing lists as well. Everyone: if you could please spend some time for a review, it'd help me post something without obvious, stupid mistakes to the upstream mailing lists.
well, don't assume that it is a platform_driver.. it should be just a plain 'driver'. Or maybe 'device'. I'm not sure about it. If you have multiple device instances with the same driver, I guess it is enough that they know that they know how to interpret the 'void *priv'.
But in thinking through how things might play out in userspace, it seems to me that it is possible to hit scenarios of passing a buffer back to the device that created it. And I guess it would be useful to have a way to avoid evil twins.
BR, -R
Thanks and best regards, ~Sumit.
BR, -R
Linaro-mm-sig mailing list Linaro-mm-sig@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-mm-sig
--
Thanks and regards,
Sumit Semwal
Linaro Kernel Engineer - Graphics working group
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog