From: "Semwal, Sumit" <sumit.semwal@ti.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org,
linaro-mm-sig@lists.linaro.org, dri-devel@lists.freedesktop.org,
linux-media@vger.kernel.org, t.stanislaws@samsung.com,
linux@arm.linux.org.uk, arnd@arndb.de, rob@ti.com,
Sumit Semwal <sumit.semwal@linaro.org>,
m.szyprowski@samsung.com
Subject: Re: [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
Date: Mon, 5 Dec 2011 15:18:00 +0530 [thread overview]
Message-ID: <CAB2ybb-G=4igL+XdRgH6oFSFdsBLuCoany4KeNaFfnLEaQzgdw@mail.gmail.com> (raw)
In-Reply-To: <20111202171117.GA27322@phenom.dumpdata.com>
Hi Konrad,
On Fri, Dec 2, 2011 at 10:41 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Fri, Dec 02, 2011 at 02:27:31PM +0530, Sumit Semwal wrote:
>> This is the first step in defining a dma buffer sharing mechanism.
>>
<snip>
>>
>> [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
>> [2]: http://lwn.net/Articles/454389
>>
>> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
>> Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
>
> You have a clone? You only need one SOB.
:) Thanks for your review - Well, not a clone, but I have two 'employers' :))
I have a rather weird reason for this - I am employed with Texas
Instruments, but working with Linaro as well. And due to some
'non-technical' reasons, I need to send this work from @ti.com mail
ID. At the same time, I would like to acknowledge that this work was
done as part of the Linaro umbrella, so I put another SOB @linaro.org.
>
>
<snip>
>> + * Copyright(C) 2011 Linaro Limited. All rights reserved.
>> + * Author: Sumit Semwal <sumit.semwal@ti.com>
>
> OK, so the SOB should be from @ti.com then.
>
>> + *
<snip>
>> +static int dma_buf_mmap(struct file *file, struct vm_area_struct *vma)
>> +{
>> + struct dma_buf *dmabuf;
>> +
>> + if (!is_dma_buf_file(file))
>> + return -EINVAL;
>> +
>> + dmabuf = file->private_data;
>> +
>
> Should you check if dmabuf is NULL and or dmabuf->ops is NULL too?
>
> Hm, you probably don't need to check for dmabuf, but from
> looking at dma_buf_export one could pass a NULL for the ops.
see next comment
>
>> + if (!dmabuf->ops->mmap)
>> + return -EINVAL;
>> +
>> + return dmabuf->ops->mmap(dmabuf, vma);
>> +}
>> +
>> +static int dma_buf_release(struct inode *inode, struct file *file)
>> +{
>> + struct dma_buf *dmabuf;
>> +
>> + if (!is_dma_buf_file(file))
>> + return -EINVAL;
>> +
>> + dmabuf = file->private_data;
>> +
>
> No checking here for ops or ops->release?
Hmmm.. you're right, of course. for this common check in mmap and
release, I guess I'd add it to 'is_dma_buf_file()' helper [maybe call
it is_valid_dma_buf_file() or something similar]
>
<snip>
>> +
>> +/**
>
> I don't think the ** is anymore the current kernel doc format.
thanks for catching this :) - will correct.
>
>> + * dma_buf_export - Creates a new dma_buf, and associates an anon file
>> + * with this buffer,so it can be exported.
>
> Put a space there.
ok
>
>> + * Also connect the allocator specific data and ops to the buffer.
>> + *
>> + * @priv: [in] Attach private data of allocator to this buffer
>> + * @ops: [in] Attach allocator-defined dma buf ops to the new buffer.
>> + * @flags: [in] mode flags for the file.
>> + *
>> + * Returns, on success, a newly created dma_buf object, which wraps the
>> + * supplied private data and operations for dma_buf_ops. On failure to
>> + * allocate the dma_buf object, it can return NULL.
>
> "it can" I think the right word is "it will".
Right.
>
>> + *
>> + */
>> +struct dma_buf *dma_buf_export(void *priv, struct dma_buf_ops *ops,
>> + int flags)
>> +{
>> + struct dma_buf *dmabuf;
>> + struct file *file;
>> +
>> + BUG_ON(!priv || !ops);
>
> Whoa. Crash the whole kernel b/c of this? No no. You should
> use WARN_ON and just return NULL.
ok
>
>> +
>> + dmabuf = kzalloc(sizeof(struct dma_buf), GFP_KERNEL);
>> + if (dmabuf == NULL)
>> + return dmabuf;
>
> Hmm, why not return ERR_PTR(-ENOMEM); ?
ok
>
>> +
>> + dmabuf->priv = priv;
>> + dmabuf->ops = ops;
>> +
>> + file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
>> +
>> + dmabuf->file = file;
>> +
>> + mutex_init(&dmabuf->lock);
>> + INIT_LIST_HEAD(&dmabuf->attachments);
>> +
>> + return dmabuf;
>> +}
>> +EXPORT_SYMBOL(dma_buf_export);
>
> _GPL ?
sure; will change it.
>
>> +
>> +
>> +/**
>> + * dma_buf_fd - returns a file descriptor for the given dma_buf
>> + * @dmabuf: [in] pointer to dma_buf for which fd is required.
>> + *
>> + * On success, returns an associated 'fd'. Else, returns error.
>> + */
>> +int dma_buf_fd(struct dma_buf *dmabuf)
>> +{
>> + int error, fd;
>> +
>
> Should you check if dmabuf is NULL first?
yes.
>
>> + if (!dmabuf->file)
>> + return -EINVAL;
>> +
>> + error = get_unused_fd_flags(0);
>> + if (error < 0)
>> + return error;
>> + fd = error;
>> +
>> + fd_install(fd, dmabuf->file);
>> +
>> + return fd;
>> +}
>> +EXPORT_SYMBOL(dma_buf_fd);
>
> GPL?
sure; will change it.
>> +
>> +/**
>> + * dma_buf_get - returns the dma_buf structure related to an fd
>> + * @fd: [in] fd associated with the dma_buf to be returned
>> + *
>> + * On success, returns the dma_buf structure associated with an fd; uses
>> + * file's refcounting done by fget to increase refcount. returns ERR_PTR
>> + * otherwise.
>> + */
>> +struct dma_buf *dma_buf_get(int fd)
>> +{
>> + struct file *file;
>> +
>> + file = fget(fd);
>> +
>> + if (!file)
>> + return ERR_PTR(-EBADF);
>> +
>> + if (!is_dma_buf_file(file)) {
>> + fput(file);
>> + return ERR_PTR(-EINVAL);
>> + }
>> +
>> + return file->private_data;
>> +}
>> +EXPORT_SYMBOL(dma_buf_get);
>
> GPL
sure; will change it.
>> +
>> +/**
>> + * dma_buf_put - decreases refcount of the buffer
>> + * @dmabuf: [in] buffer to reduce refcount of
>> + *
>> + * Uses file's refcounting done implicitly by fput()
>> + */
>> +void dma_buf_put(struct dma_buf *dmabuf)
>> +{
>> + BUG_ON(!dmabuf->file);
>
> Yikes. BUG_ON? Can't you do WARN_ON and continue on without
> doing the refcounting?
ok
>
>> +
>> + fput(dmabuf->file);
>> +}
>> +EXPORT_SYMBOL(dma_buf_put);
>> +
>> +/**
>> + * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
>> + * calls attach() of dma_buf_ops to allow device-specific attach functionality
>> + * @dmabuf: [in] buffer to attach device to.
>> + * @dev: [in] device to be attached.
>> + *
>> + * Returns struct dma_buf_attachment * for this attachment; may return NULL.
>> + *
>> + */
>> +struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
>> + struct device *dev)
>
> 'struct device' should be at the same column as 'struct dma_buf' ..
>
>> +{
>> + struct dma_buf_attachment *attach;
>> + int ret;
>> +
>> + BUG_ON(!dmabuf || !dev);
>
> Again, BUG_ON...
will correct
>
>> +
>> + attach = kzalloc(sizeof(struct dma_buf_attachment), GFP_KERNEL);
>> + if (attach == NULL)
>> + goto err_alloc;
>> +
>> + mutex_lock(&dmabuf->lock);
>> +
>> + attach->dev = dev;
>> + attach->dmabuf = dmabuf;
>> + if (dmabuf->ops->attach) {
>
> No checking first of dmabuf->ops?
Attach is told to be a mandatory operation for dmabuf exporter, but I
understand your point - checking for it won't hurt.
>
>> + ret = dmabuf->ops->attach(dmabuf, dev, attach);
>> + if (!ret)
>> + goto err_attach;
>> + }
>> + list_add(&attach->node, &dmabuf->attachments);
>> +
>> + mutex_unlock(&dmabuf->lock);
>> +
>> +err_alloc:
>> + return attach;
>> +err_attach:
>> + kfree(attach);
>> + mutex_unlock(&dmabuf->lock);
>> + return ERR_PTR(ret);
>> +}
>> +EXPORT_SYMBOL(dma_buf_attach);
>
> GPL
sure; will change it.
<snip>
Thanks and regards,
~Sumit.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-12-05 9:48 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-02 8:57 [RFC v2 0/2] Introduce DMA " Sumit Semwal
2011-12-02 8:57 ` [RFC v2 1/2] dma-buf: Introduce dma " Sumit Semwal
2011-12-02 17:11 ` Konrad Rzeszutek Wilk
2011-12-05 9:48 ` Semwal, Sumit [this message]
2011-12-05 17:18 ` Arnd Bergmann
2011-12-05 18:55 ` Daniel Vetter
2011-12-05 19:29 ` Arnd Bergmann
2011-12-05 20:58 ` Daniel Vetter
2011-12-05 22:04 ` Arnd Bergmann
2011-12-05 22:33 ` Daniel Vetter
2011-12-05 20:46 ` Rob Clark
2011-12-05 21:23 ` Daniel Vetter
2011-12-05 22:11 ` Rob Clark
2011-12-05 22:33 ` Daniel Vetter
2011-12-06 13:16 ` Arnd Bergmann
2011-12-06 15:28 ` Daniel Vetter
2011-12-07 13:27 ` Semwal, Sumit
2011-12-07 13:40 ` Arnd Bergmann
2011-12-08 21:44 ` [Linaro-mm-sig] " Daniel Vetter
2011-12-09 14:13 ` Arnd Bergmann
2011-12-09 14:24 ` Alan Cox
2011-12-10 4:01 ` Daniel Vetter
2011-12-12 16:48 ` Arnd Bergmann
2011-12-19 6:16 ` Semwal, Sumit
2011-12-20 15:41 ` Arnd Bergmann
2011-12-20 16:41 ` Rob Clark
2011-12-20 17:14 ` Daniel Vetter
2011-12-21 17:27 ` Arnd Bergmann
2011-12-21 19:04 ` Daniel Vetter
2011-12-23 10:00 ` Semwal, Sumit
2011-12-23 17:10 ` Rob Clark
2011-12-20 9:03 ` Sakari Ailus
2011-12-20 15:36 ` Arnd Bergmann
2012-01-01 20:53 ` Sakari Ailus
2012-01-01 23:12 ` Rob Clark
2011-12-13 13:33 ` Hans Verkuil
2011-12-05 22:09 ` Arnd Bergmann
2011-12-05 22:15 ` Rob Clark
2011-12-05 22:35 ` Rob Clark
2011-12-07 6:35 ` Semwal, Sumit
2011-12-07 10:11 ` Arnd Bergmann
2011-12-07 11:02 ` Semwal, Sumit
2011-12-07 11:34 ` Arnd Bergmann
2011-12-09 22:50 ` [Linaro-mm-sig] " Robert Morell
2011-12-10 11:13 ` Mauro Carvalho Chehab
2011-12-12 22:44 ` Robert Morell
2011-12-13 15:10 ` Arnd Bergmann
2011-12-20 2:05 ` Robert Morell
2011-12-20 14:29 ` Anca Emanuel
2012-01-09 6:20 ` InKi Dae
2012-01-09 8:10 ` Daniel Vetter
2012-01-09 8:11 ` [Linaro-mm-sig] " Dave Airlie
2012-01-09 10:10 ` InKi Dae
2012-01-09 10:27 ` Daniel Vetter
2012-01-09 12:06 ` InKi Dae
2012-01-09 16:02 ` Daniel Vetter
2012-01-09 15:17 ` Rob Clark
2012-01-10 1:34 ` InKi Dae
2012-01-10 2:14 ` Rob Clark
2012-01-10 6:09 ` Semwal, Sumit
2012-01-10 7:28 ` InKi Dae
2012-01-10 9:19 ` InKi Dae
2012-01-11 1:08 ` InKi Dae
2011-12-02 8:57 ` [RFC v2 2/2] dma-buf: Documentation for buffer sharing framework Sumit Semwal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAB2ybb-G=4igL+XdRgH6oFSFdsBLuCoany4KeNaFfnLEaQzgdw@mail.gmail.com' \
--to=sumit.semwal@ti.com \
--cc=arnd@arndb.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=konrad.wilk@oracle.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@arm.linux.org.uk \
--cc=m.szyprowski@samsung.com \
--cc=rob@ti.com \
--cc=sumit.semwal@linaro.org \
--cc=t.stanislaws@samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox