On 19 September 2011 05:37, Clark, Rob <rob@ti.com> wrote:

On Tue, Sep 13, 2011 at 9:29 AM, Sumit Semwal <sumit.semwal@ti.com> wrote:
> +struct dma_buf_ops {
> + void (*attach)(struct dma_buf *, struct device *,
> + struct dma_buf_attachment *);
> +
> + void (*detach)(struct dma_buf *, struct dma_buf_attachment *);
> +
> + struct scatterlist * (*get_scatterlist)(struct dma_buf *,
> + struct dma_buf_attachment *,
> + enum dma_buf_optype,
> + enum dma_buf_attr_flags);

I guess you don't need to pass both 'struct dma_buf' and 'struct
dma_buf_attachment'.. the 'struct dma_buf_attachment' can have the
'struct dma_buf' ptr. This somehow seems a bit more logical and
cleaner to me.

Thanks, I agree, and will remove it in the next version.

Also, I'm not sure about dma_buf_attr_flags. I think we could add
whatever is needed to 'struct device_dma_parameters'
(dev->dma_params).

Yes, I think we will leave it for addition-as-and-when-required.

With these changes, I am thinking of publishing out this RFC to the upstream mailing lists - do you all think it's ready, or does it need some more obvious work?

If it is ok, could you all please let me know what all mailing lists should I target? [I have thought of linux-arm-kernel, linux-mm, linux-arch - in addition, linux-media, dri-devel; CC to Arnd and Russell. Any others?]

Best regards,

~Sumit.

BR,
-R

> + void (*put_scatterlist)(struct dma_buf *, struct dma_buf_attachment *,

> + struct scatterlist *);
> +
> + /* allow mmap optionally for devices that need it */
> + int (*mmap)(struct dma_buf *, struct vm_area_struct *);
> + /* after final dma_buf_put() */
> + void (*release)(struct dma_buf *);
> +
> + /* allow allocator to take care of cache ops */
> + void (*sync_sg_for_cpu) (struct dma_buf *, struct device *);
> + void (*sync_sg_for_device)(struct dma_buf *, struct device *);
> +};
> +