diff for duplicates of <20120103210927.GJ17472@phenom.dumpdata.com> diff --git a/a/1.txt b/N1/1.txt index 0e736a5..10c9bff 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -11,7 +11,7 @@ On Fri, Dec 23, 2011 at 03:22:35PM +0530, Semwal, Sumit wrote: > >> > >> The framework allows: > >> - different devices to 'attach' themselves to this buffer, to facilitate -> >> ? backing storage negotiation, using dma_buf_attach() API. +> >> backing storage negotiation, using dma_buf_attach() API. > > > > Any thoughts of adding facility to track them? So you can see who is using what? > Not for version 1, but it would be a useful addition once we start @@ -21,21 +21,21 @@ OK. Looking forward to V2. > > > > >> - association of a file pointer with each user-buffer and associated -> >> ? ?allocator-defined operations on that buffer. This operation is called the -> >> ? ?'export' operation. +> >> allocator-defined operations on that buffer. This operation is called the +> >> 'export' operation. > > -> > ?'create'? or 'alloc' ? +> > 'create'? or 'alloc' ? > > > > export implies an import somwhere and I don't think that is the case here. > I will rephrase it as suggested by Rob as well. > > > > >> - this exported buffer-object to be shared with the other entity by asking for -> >> ? ?its 'file-descriptor (fd)', and sharing the fd across. +> >> its 'file-descriptor (fd)', and sharing the fd across. > >> - a received fd to get the buffer object back, where it can be accessed using -> >> ? ?the associated exporter-defined operations. +> >> the associated exporter-defined operations. > >> - the exporter and user to share the scatterlist using map_dma_buf and -> >> ? ?unmap_dma_buf operations. +> >> unmap_dma_buf operations. > >> > >> Atleast one 'attach()' call is required to be made prior to calling the > >> map_dma_buf() operation. @@ -54,7 +54,7 @@ Can you include his words of wisdom in the git description? > >> + */ > >> +static inline int is_dma_buf_file(struct file *file) > >> +{ -> >> + ? ? return file->f_op == &dma_buf_fops; +> >> + return file->f_op == &dma_buf_fops; > >> +} > >> + > >> +/** @@ -80,7 +80,7 @@ Documentation/* trumps what I recall. > > > >> + * @dmabuf: buffer for this attachment. > >> + * @dev: device attached to the buffer. -> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^^^ this +> > ^^^ this > >> + * @node: list_head to allow manipulation of list of dma_buf_attachment. > > > > Just say: "list of dma_buf_attachment"' @@ -97,10 +97,10 @@ to inhibit this patch from being merged. > > > >> + */ > >> +struct dma_buf_attachment { -> >> + ? ? struct dma_buf *dmabuf; -> >> + ? ? struct device *dev; -> >> + ? ? struct list_head node; -> >> + ? ? void *priv; +> >> + struct dma_buf *dmabuf; +> >> + struct device *dev; +> >> + struct list_head node; +> >> + void *priv; > >> +}; > > > > Why don't you move the decleration of this below 'struct dma_buf'? @@ -120,8 +120,8 @@ one. But if it is too ugly, don't bother. > >> + * @attach: allows different devices to 'attach' themselves to the given > > > > register? -> >> + * ? ? ? buffer. It might return -EBUSY to signal that backing storage -> >> + * ? ? ? is already allocated and incompatible with the requirements +> >> + * buffer. It might return -EBUSY to signal that backing storage +> >> + * is already allocated and incompatible with the requirements > > > > Wait.. allocated or attached? > This and above comment on 'register' are already answered by Rob in @@ -132,7 +132,7 @@ OK. Might want to mention the user to look in the Documentation, in case you don already have it. > > > -> >> + * ? ? ? of requesting device. [optional] +> >> + * of requesting device. [optional] > > > > What is optional? The return value? Or the 'attach' call? If the later , say > > that in the first paragraph. @@ -141,23 +141,23 @@ already have it. > > > >> + * @detach: detach a given device from this buffer. [optional] > >> + * @map_dma_buf: returns list of scatter pages allocated, increases usecount -> >> + * ? ? ? ? ? ?of the buffer. Requires atleast one attach to be called -> >> + * ? ? ? ? ? ?before. Returned sg list should already be mapped into -> >> + * ? ? ? ? ? ?_device_ address space. This call may sleep. May also return +> >> + * of the buffer. Requires atleast one attach to be called +> >> + * before. Returned sg list should already be mapped into +> >> + * _device_ address space. This call may sleep. May also return > > > > Ok, there is some __might_sleep macro you should put on the function. > > > That's a nice suggestion; I will add it to the wrapper function for > map_dma_buf(). > -> >> + * ? ? ? ? ? ?-EINTR. +> >> + * -EINTR. > > > > Ok. What is the return code if attach has _not_ been called? > Will document it to return -EINVAL if atleast on attach() hasn't been called. > > > > >> + * @unmap_dma_buf: decreases usecount of buffer, might deallocate scatter -> >> + * ? ? ? ? ? ? ?pages. +> >> + * pages. > >> + * @release: release this buffer; to be called after the last dma_buf_put. > >> + * @sync_sg_for_cpu: sync the sg list for cpu. > >> + * @sync_sg_for_device: synch the sg list for device. @@ -167,7 +167,7 @@ already have it. > > >> + */ > <snip> -> >> + ? ? /* TODO: Add try_map_dma_buf version, to return immed with -EBUSY +> >> + /* TODO: Add try_map_dma_buf version, to return immed with -EBUSY > > > > Ewww. Why? Why not just just the 'map_dma_buf' and return that? > Requirement is to allow for blocking and non-blocking versions of @@ -198,8 +198,8 @@ return -ENOSPC and move the TODO to the code instead of it being in the header? > > user of this have something like this: > > > > struct my_dma_bufs { -> > ? ? ? ?struct dma_buf[20]; -> > ? ? ? ?void *priv; +> > struct dma_buf[20]; +> > void *priv; > > } > > > > Anyhow? @@ -211,3 +211,10 @@ return -ENOSPC and move the TODO to the code instead of it being in the header? Sure. And please put 'Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>'. > Best 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> diff --git a/a/content_digest b/N1/content_digest index 1ae862b..4033b2a 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,10 +2,24 @@ "ref\01324283611-18344-3-git-send-email-sumit.semwal@ti.com\0" "ref\020111220163650.GB3964@phenom.dumpdata.com\0" "ref\0CAB2ybb_jZNgQma7dv2qojOf8K0-1wutfMkNr3xjqFvfpw2aNTQ@mail.gmail.com\0" - "From\0konrad.wilk@oracle.com (Konrad Rzeszutek Wilk)\0" - "Subject\0[RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism\0" + "From\0Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\0" + "Subject\0Re: [RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism\0" "Date\0Tue, 3 Jan 2012 16:09:27 -0500\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "To\0Semwal" + " Sumit <sumit.semwal@ti.com>\0" + "Cc\0linux-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 + patches@linaro.org + rob@ti.com + Sumit Semwal <sumit.semwal@linaro.org> + " m.szyprowski@samsung.com\0" "\00:1\0" "b\0" "On Fri, Dec 23, 2011 at 03:22:35PM +0530, Semwal, Sumit wrote:\n" @@ -21,7 +35,7 @@ "> >>\n" "> >> The framework allows:\n" "> >> - different devices to 'attach' themselves to this buffer, to facilitate\n" - "> >> ? backing storage negotiation, using dma_buf_attach() API.\n" + "> >> \302\240 backing storage negotiation, using dma_buf_attach() API.\n" "> >\n" "> > Any thoughts of adding facility to track them? So you can see who is using what?\n" "> Not for version 1, but it would be a useful addition once we start\n" @@ -31,21 +45,21 @@ "> \n" "> >\n" "> >> - association of a file pointer with each user-buffer and associated\n" - "> >> ? ?allocator-defined operations on that buffer. This operation is called the\n" - "> >> ? ?'export' operation.\n" + "> >> \302\240 \302\240allocator-defined operations on that buffer. This operation is called the\n" + "> >> \302\240 \302\240'export' operation.\n" "> >\n" - "> > ?'create'? or 'alloc' ?\n" + "> > \302\240'create'? or 'alloc' ?\n" "> >\n" "> > export implies an import somwhere and I don't think that is the case here.\n" "> I will rephrase it as suggested by Rob as well.\n" "> \n" "> >\n" "> >> - this exported buffer-object to be shared with the other entity by asking for\n" - "> >> ? ?its 'file-descriptor (fd)', and sharing the fd across.\n" + "> >> \302\240 \302\240its 'file-descriptor (fd)', and sharing the fd across.\n" "> >> - a received fd to get the buffer object back, where it can be accessed using\n" - "> >> ? ?the associated exporter-defined operations.\n" + "> >> \302\240 \302\240the associated exporter-defined operations.\n" "> >> - the exporter and user to share the scatterlist using map_dma_buf and\n" - "> >> ? ?unmap_dma_buf operations.\n" + "> >> \302\240 \302\240unmap_dma_buf operations.\n" "> >>\n" "> >> Atleast one 'attach()' call is required to be made prior to calling the\n" "> >> map_dma_buf() operation.\n" @@ -64,7 +78,7 @@ "> >> + */\n" "> >> +static inline int is_dma_buf_file(struct file *file)\n" "> >> +{\n" - "> >> + ? ? return file->f_op == &dma_buf_fops;\n" + "> >> + \302\240 \302\240 return file->f_op == &dma_buf_fops;\n" "> >> +}\n" "> >> +\n" "> >> +/**\n" @@ -90,7 +104,7 @@ "> >\n" "> >> + * @dmabuf: buffer for this attachment.\n" "> >> + * @dev: device attached to the buffer.\n" - "> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^^^ this\n" + "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240^^^ this\n" "> >> + * @node: list_head to allow manipulation of list of dma_buf_attachment.\n" "> >\n" "> > Just say: \"list of dma_buf_attachment\"'\n" @@ -107,10 +121,10 @@ "> >\n" "> >> + */\n" "> >> +struct dma_buf_attachment {\n" - "> >> + ? ? struct dma_buf *dmabuf;\n" - "> >> + ? ? struct device *dev;\n" - "> >> + ? ? struct list_head node;\n" - "> >> + ? ? void *priv;\n" + "> >> + \302\240 \302\240 struct dma_buf *dmabuf;\n" + "> >> + \302\240 \302\240 struct device *dev;\n" + "> >> + \302\240 \302\240 struct list_head node;\n" + "> >> + \302\240 \302\240 void *priv;\n" "> >> +};\n" "> >\n" "> > Why don't you move the decleration of this below 'struct dma_buf'?\n" @@ -130,8 +144,8 @@ "> >> + * @attach: allows different devices to 'attach' themselves to the given\n" "> >\n" "> > register?\n" - "> >> + * ? ? ? buffer. It might return -EBUSY to signal that backing storage\n" - "> >> + * ? ? ? is already allocated and incompatible with the requirements\n" + "> >> + * \302\240 \302\240 \302\240 buffer. It might return -EBUSY to signal that backing storage\n" + "> >> + * \302\240 \302\240 \302\240 is already allocated and incompatible with the requirements\n" "> >\n" "> > Wait.. allocated or attached?\n" "> This and above comment on 'register' are already answered by Rob in\n" @@ -142,7 +156,7 @@ "already have it.\n" "> \n" "> >\n" - "> >> + * ? ? ? of requesting device. [optional]\n" + "> >> + * \302\240 \302\240 \302\240 of requesting device. [optional]\n" "> >\n" "> > What is optional? The return value? Or the 'attach' call? If the later , say\n" "> > that in the first paragraph.\n" @@ -151,23 +165,23 @@ "> >\n" "> >> + * @detach: detach a given device from this buffer. [optional]\n" "> >> + * @map_dma_buf: returns list of scatter pages allocated, increases usecount\n" - "> >> + * ? ? ? ? ? ?of the buffer. Requires atleast one attach to be called\n" - "> >> + * ? ? ? ? ? ?before. Returned sg list should already be mapped into\n" - "> >> + * ? ? ? ? ? ?_device_ address space. This call may sleep. May also return\n" + "> >> + * \302\240 \302\240 \302\240 \302\240 \302\240 \302\240of the buffer. Requires atleast one attach to be called\n" + "> >> + * \302\240 \302\240 \302\240 \302\240 \302\240 \302\240before. Returned sg list should already be mapped into\n" + "> >> + * \302\240 \302\240 \302\240 \302\240 \302\240 \302\240_device_ address space. This call may sleep. May also return\n" "> >\n" "> > Ok, there is some __might_sleep macro you should put on the function.\n" "> >\n" "> That's a nice suggestion; I will add it to the wrapper function for\n" "> map_dma_buf().\n" "> \n" - "> >> + * ? ? ? ? ? ?-EINTR.\n" + "> >> + * \302\240 \302\240 \302\240 \302\240 \302\240 \302\240-EINTR.\n" "> >\n" "> > Ok. What is the return code if attach has _not_ been called?\n" "> Will document it to return -EINVAL if atleast on attach() hasn't been called.\n" "> \n" "> >\n" "> >> + * @unmap_dma_buf: decreases usecount of buffer, might deallocate scatter\n" - "> >> + * ? ? ? ? ? ? ?pages.\n" + "> >> + * \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240pages.\n" "> >> + * @release: release this buffer; to be called after the last dma_buf_put.\n" "> >> + * @sync_sg_for_cpu: sync the sg list for cpu.\n" "> >> + * @sync_sg_for_device: synch the sg list for device.\n" @@ -177,7 +191,7 @@ "> \n" "> >> + */\n" "> <snip>\n" - "> >> + ? ? /* TODO: Add try_map_dma_buf version, to return immed with -EBUSY\n" + "> >> + \302\240 \302\240 /* TODO: Add try_map_dma_buf version, to return immed with -EBUSY\n" "> >\n" "> > Ewww. Why? Why not just just the 'map_dma_buf' and return that?\n" "> Requirement is to allow for blocking and non-blocking versions of\n" @@ -208,8 +222,8 @@ "> > user of this have something like this:\n" "> >\n" "> > struct my_dma_bufs {\n" - "> > ? ? ? ?struct dma_buf[20];\n" - "> > ? ? ? ?void *priv;\n" + "> > \302\240 \302\240 \302\240 \302\240struct dma_buf[20];\n" + "> > \302\240 \302\240 \302\240 \302\240void *priv;\n" "> > }\n" "> >\n" "> > Anyhow?\n" @@ -220,6 +234,13 @@ "\n" "Sure. And please put 'Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>'.\n" "> Best regards,\n" - > ~Sumit. + "> ~Sumit.\n" + "\n" + "--\n" + "To unsubscribe, send a message with 'unsubscribe linux-mm' in\n" + "the body to majordomo@kvack.org. For more info on Linux MM,\n" + "see: http://www.linux-mm.org/ .\n" + "Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/\n" + "Don't email: <a href=mailto:\"dont@kvack.org\"> email@kvack.org </a>" -21cde499e8c31d31a0d8aa69042c7483216e32ccc058e0e408efdfa2638e5c69 +a5df7b4b3df5c2fef0a76cf82103b43a1213974b09e1d9a50950781b0a917e72
diff --git a/a/1.txt b/N2/1.txt index 0e736a5..f70ead3 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -11,7 +11,7 @@ On Fri, Dec 23, 2011 at 03:22:35PM +0530, Semwal, Sumit wrote: > >> > >> The framework allows: > >> - different devices to 'attach' themselves to this buffer, to facilitate -> >> ? backing storage negotiation, using dma_buf_attach() API. +> >> backing storage negotiation, using dma_buf_attach() API. > > > > Any thoughts of adding facility to track them? So you can see who is using what? > Not for version 1, but it would be a useful addition once we start @@ -21,21 +21,21 @@ OK. Looking forward to V2. > > > > >> - association of a file pointer with each user-buffer and associated -> >> ? ?allocator-defined operations on that buffer. This operation is called the -> >> ? ?'export' operation. +> >> allocator-defined operations on that buffer. This operation is called the +> >> 'export' operation. > > -> > ?'create'? or 'alloc' ? +> > 'create'? or 'alloc' ? > > > > export implies an import somwhere and I don't think that is the case here. > I will rephrase it as suggested by Rob as well. > > > > >> - this exported buffer-object to be shared with the other entity by asking for -> >> ? ?its 'file-descriptor (fd)', and sharing the fd across. +> >> its 'file-descriptor (fd)', and sharing the fd across. > >> - a received fd to get the buffer object back, where it can be accessed using -> >> ? ?the associated exporter-defined operations. +> >> the associated exporter-defined operations. > >> - the exporter and user to share the scatterlist using map_dma_buf and -> >> ? ?unmap_dma_buf operations. +> >> unmap_dma_buf operations. > >> > >> Atleast one 'attach()' call is required to be made prior to calling the > >> map_dma_buf() operation. @@ -54,7 +54,7 @@ Can you include his words of wisdom in the git description? > >> + */ > >> +static inline int is_dma_buf_file(struct file *file) > >> +{ -> >> + ? ? return file->f_op == &dma_buf_fops; +> >> + return file->f_op == &dma_buf_fops; > >> +} > >> + > >> +/** @@ -80,7 +80,7 @@ Documentation/* trumps what I recall. > > > >> + * @dmabuf: buffer for this attachment. > >> + * @dev: device attached to the buffer. -> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^^^ this +> > ^^^ this > >> + * @node: list_head to allow manipulation of list of dma_buf_attachment. > > > > Just say: "list of dma_buf_attachment"' @@ -97,10 +97,10 @@ to inhibit this patch from being merged. > > > >> + */ > >> +struct dma_buf_attachment { -> >> + ? ? struct dma_buf *dmabuf; -> >> + ? ? struct device *dev; -> >> + ? ? struct list_head node; -> >> + ? ? void *priv; +> >> + struct dma_buf *dmabuf; +> >> + struct device *dev; +> >> + struct list_head node; +> >> + void *priv; > >> +}; > > > > Why don't you move the decleration of this below 'struct dma_buf'? @@ -120,8 +120,8 @@ one. But if it is too ugly, don't bother. > >> + * @attach: allows different devices to 'attach' themselves to the given > > > > register? -> >> + * ? ? ? buffer. It might return -EBUSY to signal that backing storage -> >> + * ? ? ? is already allocated and incompatible with the requirements +> >> + * buffer. It might return -EBUSY to signal that backing storage +> >> + * is already allocated and incompatible with the requirements > > > > Wait.. allocated or attached? > This and above comment on 'register' are already answered by Rob in @@ -132,7 +132,7 @@ OK. Might want to mention the user to look in the Documentation, in case you don already have it. > > > -> >> + * ? ? ? of requesting device. [optional] +> >> + * of requesting device. [optional] > > > > What is optional? The return value? Or the 'attach' call? If the later , say > > that in the first paragraph. @@ -141,23 +141,23 @@ already have it. > > > >> + * @detach: detach a given device from this buffer. [optional] > >> + * @map_dma_buf: returns list of scatter pages allocated, increases usecount -> >> + * ? ? ? ? ? ?of the buffer. Requires atleast one attach to be called -> >> + * ? ? ? ? ? ?before. Returned sg list should already be mapped into -> >> + * ? ? ? ? ? ?_device_ address space. This call may sleep. May also return +> >> + * of the buffer. Requires atleast one attach to be called +> >> + * before. Returned sg list should already be mapped into +> >> + * _device_ address space. This call may sleep. May also return > > > > Ok, there is some __might_sleep macro you should put on the function. > > > That's a nice suggestion; I will add it to the wrapper function for > map_dma_buf(). > -> >> + * ? ? ? ? ? ?-EINTR. +> >> + * -EINTR. > > > > Ok. What is the return code if attach has _not_ been called? > Will document it to return -EINVAL if atleast on attach() hasn't been called. > > > > >> + * @unmap_dma_buf: decreases usecount of buffer, might deallocate scatter -> >> + * ? ? ? ? ? ? ?pages. +> >> + * pages. > >> + * @release: release this buffer; to be called after the last dma_buf_put. > >> + * @sync_sg_for_cpu: sync the sg list for cpu. > >> + * @sync_sg_for_device: synch the sg list for device. @@ -167,7 +167,7 @@ already have it. > > >> + */ > <snip> -> >> + ? ? /* TODO: Add try_map_dma_buf version, to return immed with -EBUSY +> >> + /* TODO: Add try_map_dma_buf version, to return immed with -EBUSY > > > > Ewww. Why? Why not just just the 'map_dma_buf' and return that? > Requirement is to allow for blocking and non-blocking versions of @@ -198,8 +198,8 @@ return -ENOSPC and move the TODO to the code instead of it being in the header? > > user of this have something like this: > > > > struct my_dma_bufs { -> > ? ? ? ?struct dma_buf[20]; -> > ? ? ? ?void *priv; +> > struct dma_buf[20]; +> > void *priv; > > } > > > > Anyhow? diff --git a/a/content_digest b/N2/content_digest index 1ae862b..40dd151 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -2,10 +2,24 @@ "ref\01324283611-18344-3-git-send-email-sumit.semwal@ti.com\0" "ref\020111220163650.GB3964@phenom.dumpdata.com\0" "ref\0CAB2ybb_jZNgQma7dv2qojOf8K0-1wutfMkNr3xjqFvfpw2aNTQ@mail.gmail.com\0" - "From\0konrad.wilk@oracle.com (Konrad Rzeszutek Wilk)\0" - "Subject\0[RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism\0" + "From\0Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>\0" + "Subject\0Re: [RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism\0" "Date\0Tue, 3 Jan 2012 16:09:27 -0500\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "To\0Semwal" + " Sumit <sumit.semwal@ti.com>\0" + "Cc\0linux-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 + patches@linaro.org + rob@ti.com + Sumit Semwal <sumit.semwal@linaro.org> + " m.szyprowski@samsung.com\0" "\00:1\0" "b\0" "On Fri, Dec 23, 2011 at 03:22:35PM +0530, Semwal, Sumit wrote:\n" @@ -21,7 +35,7 @@ "> >>\n" "> >> The framework allows:\n" "> >> - different devices to 'attach' themselves to this buffer, to facilitate\n" - "> >> ? backing storage negotiation, using dma_buf_attach() API.\n" + "> >> \302\240 backing storage negotiation, using dma_buf_attach() API.\n" "> >\n" "> > Any thoughts of adding facility to track them? So you can see who is using what?\n" "> Not for version 1, but it would be a useful addition once we start\n" @@ -31,21 +45,21 @@ "> \n" "> >\n" "> >> - association of a file pointer with each user-buffer and associated\n" - "> >> ? ?allocator-defined operations on that buffer. This operation is called the\n" - "> >> ? ?'export' operation.\n" + "> >> \302\240 \302\240allocator-defined operations on that buffer. This operation is called the\n" + "> >> \302\240 \302\240'export' operation.\n" "> >\n" - "> > ?'create'? or 'alloc' ?\n" + "> > \302\240'create'? or 'alloc' ?\n" "> >\n" "> > export implies an import somwhere and I don't think that is the case here.\n" "> I will rephrase it as suggested by Rob as well.\n" "> \n" "> >\n" "> >> - this exported buffer-object to be shared with the other entity by asking for\n" - "> >> ? ?its 'file-descriptor (fd)', and sharing the fd across.\n" + "> >> \302\240 \302\240its 'file-descriptor (fd)', and sharing the fd across.\n" "> >> - a received fd to get the buffer object back, where it can be accessed using\n" - "> >> ? ?the associated exporter-defined operations.\n" + "> >> \302\240 \302\240the associated exporter-defined operations.\n" "> >> - the exporter and user to share the scatterlist using map_dma_buf and\n" - "> >> ? ?unmap_dma_buf operations.\n" + "> >> \302\240 \302\240unmap_dma_buf operations.\n" "> >>\n" "> >> Atleast one 'attach()' call is required to be made prior to calling the\n" "> >> map_dma_buf() operation.\n" @@ -64,7 +78,7 @@ "> >> + */\n" "> >> +static inline int is_dma_buf_file(struct file *file)\n" "> >> +{\n" - "> >> + ? ? return file->f_op == &dma_buf_fops;\n" + "> >> + \302\240 \302\240 return file->f_op == &dma_buf_fops;\n" "> >> +}\n" "> >> +\n" "> >> +/**\n" @@ -90,7 +104,7 @@ "> >\n" "> >> + * @dmabuf: buffer for this attachment.\n" "> >> + * @dev: device attached to the buffer.\n" - "> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^^^ this\n" + "> > \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240^^^ this\n" "> >> + * @node: list_head to allow manipulation of list of dma_buf_attachment.\n" "> >\n" "> > Just say: \"list of dma_buf_attachment\"'\n" @@ -107,10 +121,10 @@ "> >\n" "> >> + */\n" "> >> +struct dma_buf_attachment {\n" - "> >> + ? ? struct dma_buf *dmabuf;\n" - "> >> + ? ? struct device *dev;\n" - "> >> + ? ? struct list_head node;\n" - "> >> + ? ? void *priv;\n" + "> >> + \302\240 \302\240 struct dma_buf *dmabuf;\n" + "> >> + \302\240 \302\240 struct device *dev;\n" + "> >> + \302\240 \302\240 struct list_head node;\n" + "> >> + \302\240 \302\240 void *priv;\n" "> >> +};\n" "> >\n" "> > Why don't you move the decleration of this below 'struct dma_buf'?\n" @@ -130,8 +144,8 @@ "> >> + * @attach: allows different devices to 'attach' themselves to the given\n" "> >\n" "> > register?\n" - "> >> + * ? ? ? buffer. It might return -EBUSY to signal that backing storage\n" - "> >> + * ? ? ? is already allocated and incompatible with the requirements\n" + "> >> + * \302\240 \302\240 \302\240 buffer. It might return -EBUSY to signal that backing storage\n" + "> >> + * \302\240 \302\240 \302\240 is already allocated and incompatible with the requirements\n" "> >\n" "> > Wait.. allocated or attached?\n" "> This and above comment on 'register' are already answered by Rob in\n" @@ -142,7 +156,7 @@ "already have it.\n" "> \n" "> >\n" - "> >> + * ? ? ? of requesting device. [optional]\n" + "> >> + * \302\240 \302\240 \302\240 of requesting device. [optional]\n" "> >\n" "> > What is optional? The return value? Or the 'attach' call? If the later , say\n" "> > that in the first paragraph.\n" @@ -151,23 +165,23 @@ "> >\n" "> >> + * @detach: detach a given device from this buffer. [optional]\n" "> >> + * @map_dma_buf: returns list of scatter pages allocated, increases usecount\n" - "> >> + * ? ? ? ? ? ?of the buffer. Requires atleast one attach to be called\n" - "> >> + * ? ? ? ? ? ?before. Returned sg list should already be mapped into\n" - "> >> + * ? ? ? ? ? ?_device_ address space. This call may sleep. May also return\n" + "> >> + * \302\240 \302\240 \302\240 \302\240 \302\240 \302\240of the buffer. Requires atleast one attach to be called\n" + "> >> + * \302\240 \302\240 \302\240 \302\240 \302\240 \302\240before. Returned sg list should already be mapped into\n" + "> >> + * \302\240 \302\240 \302\240 \302\240 \302\240 \302\240_device_ address space. This call may sleep. May also return\n" "> >\n" "> > Ok, there is some __might_sleep macro you should put on the function.\n" "> >\n" "> That's a nice suggestion; I will add it to the wrapper function for\n" "> map_dma_buf().\n" "> \n" - "> >> + * ? ? ? ? ? ?-EINTR.\n" + "> >> + * \302\240 \302\240 \302\240 \302\240 \302\240 \302\240-EINTR.\n" "> >\n" "> > Ok. What is the return code if attach has _not_ been called?\n" "> Will document it to return -EINVAL if atleast on attach() hasn't been called.\n" "> \n" "> >\n" "> >> + * @unmap_dma_buf: decreases usecount of buffer, might deallocate scatter\n" - "> >> + * ? ? ? ? ? ? ?pages.\n" + "> >> + * \302\240 \302\240 \302\240 \302\240 \302\240 \302\240 \302\240pages.\n" "> >> + * @release: release this buffer; to be called after the last dma_buf_put.\n" "> >> + * @sync_sg_for_cpu: sync the sg list for cpu.\n" "> >> + * @sync_sg_for_device: synch the sg list for device.\n" @@ -177,7 +191,7 @@ "> \n" "> >> + */\n" "> <snip>\n" - "> >> + ? ? /* TODO: Add try_map_dma_buf version, to return immed with -EBUSY\n" + "> >> + \302\240 \302\240 /* TODO: Add try_map_dma_buf version, to return immed with -EBUSY\n" "> >\n" "> > Ewww. Why? Why not just just the 'map_dma_buf' and return that?\n" "> Requirement is to allow for blocking and non-blocking versions of\n" @@ -208,8 +222,8 @@ "> > user of this have something like this:\n" "> >\n" "> > struct my_dma_bufs {\n" - "> > ? ? ? ?struct dma_buf[20];\n" - "> > ? ? ? ?void *priv;\n" + "> > \302\240 \302\240 \302\240 \302\240struct dma_buf[20];\n" + "> > \302\240 \302\240 \302\240 \302\240void *priv;\n" "> > }\n" "> >\n" "> > Anyhow?\n" @@ -222,4 +236,4 @@ "> Best regards,\n" > ~Sumit. -21cde499e8c31d31a0d8aa69042c7483216e32ccc058e0e408efdfa2638e5c69 +5a3c19c26014672f74b938ce6d1af6806472918b89bd069095f2fdee39670e95
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.