diff for duplicates of <d24e8c6e35352ed5800161713f728591@chewa.net>
diff --git a/a/1.txt b/N1/1.txt
index bd4160d..47406fc 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,65 +1,33 @@
-On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski
-
-<t.stanislaws@samsung.com> wrote:
-
->> Am I understanding wrong or are you saying that you want to drop
-
-userptr
-
->> from V4L2 API in long-term? If so, why?
-
->
-
-> Dropping userptr is just some brainstorming idea.
-
-> It was found out that userptr is not a good mean
-
-> for buffer exchange between to two devices.
-
-
-
-I can believe that. But I am also inclined to believe that DMABUF is
-
-targetted at device-to-device transfer, while USERPTR is targetted at
-
-device-to-user (or user-to-device) transfers. Are you saying applications
-
-should use DMABUF and memory map the buffers? Or would you care to explain
-
-how DMABUF addresses the problem space of USERPTR?
-
-
-
-> The USERPTR simplifies userspace code but introduce
-
-> a lot of complexity problems for the kernel drivers
-
-> and frameworks.
-
-
-
-It is not only a simplification. In some cases, USERPTR is the only I/O
-
-method that supports zero copy in pretty much any circumstance. When the
-
-user cannot reliably predict the maximum number of required buffers,
-
-predicts a value larger than the device will negotiate, or needs buffers to
-
-outlive STREAMOFF (?), MMAP requires memory copying. USERPTR does not.
-
-
-
-Now, I do realize that some devices cannot support USERPTR efficiently,
-
-then they should not support USERPTR. But for those devices that can, it
-
-seems quite a nice performance enhancement.
-
-
-
---
-
-Rémi Denis-Courmont
-
+On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski\r
+<t.stanislaws@samsung.com> wrote:\r
+>> Am I understanding wrong or are you saying that you want to drop\r
+userptr\r
+>> from V4L2 API in long-term? If so, why?\r
+> \r
+> Dropping userptr is just some brainstorming idea.\r
+> It was found out that userptr is not a good mean\r
+> for buffer exchange between to two devices.\r
+\r
+I can believe that. But I am also inclined to believe that DMABUF is\r
+targetted at device-to-device transfer, while USERPTR is targetted at\r
+device-to-user (or user-to-device) transfers. Are you saying applications\r
+should use DMABUF and memory map the buffers? Or would you care to explain\r
+how DMABUF addresses the problem space of USERPTR?\r
+\r
+> The USERPTR simplifies userspace code but introduce\r
+> a lot of complexity problems for the kernel drivers\r
+> and frameworks.\r
+\r
+It is not only a simplification. In some cases, USERPTR is the only I/O\r
+method that supports zero copy in pretty much any circumstance. When the\r
+user cannot reliably predict the maximum number of required buffers,\r
+predicts a value larger than the device will negotiate, or needs buffers to\r
+outlive STREAMOFF (?), MMAP requires memory copying. USERPTR does not.\r
+\r
+Now, I do realize that some devices cannot support USERPTR efficiently,\r
+then they should not support USERPTR. But for those devices that can, it\r
+seems quite a nice performance enhancement.\r
+\r
+-- \r
+Rémi Denis-Courmont\r
Sent from my collocated server
\ No newline at end of file
diff --git a/a/content_digest b/N1/content_digest
index 12996da..047ebba 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -31,19 +31,19 @@
[
"Cc\0Mauro Carvalho Chehab <mchehab\@redhat.com>",
" Laurent Pinchart <laurent.pinchart\@ideasonboard.com>",
- " <linux-media\@vger.kernel.org>",
- " <dri-devel\@lists.freedesktop.org>",
- " <airlied\@redhat.com>",
- " <m.szyprowski\@samsung.com>",
- " <kyungmin.park\@samsung.com>",
- " <sumit.semwal\@ti.com>",
- " <daeinki\@gmail.com>",
- " <daniel.vetter\@ffwll.ch>",
- " <robdclark\@gmail.com>",
- " <pawel\@osciak.com>",
- " <linaro-mm-sig\@lists.linaro.org>",
- " <hverkuil\@xs4all.nl>",
- " <subashrp\@gmail.com>\0"
+ " linux-media\@vger.kernel.org",
+ " dri-devel\@lists.freedesktop.org",
+ " airlied\@redhat.com",
+ " m.szyprowski\@samsung.com",
+ " kyungmin.park\@samsung.com",
+ " sumit.semwal\@ti.com",
+ " daeinki\@gmail.com",
+ " daniel.vetter\@ffwll.ch",
+ " robdclark\@gmail.com",
+ " pawel\@osciak.com",
+ " linaro-mm-sig\@lists.linaro.org",
+ " hverkuil\@xs4all.nl",
+ " subashrp\@gmail.com\0"
]
[
"\0000:1\0"
@@ -52,71 +52,39 @@
"b\0"
]
[
- "On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski\n",
- "\n",
- "<t.stanislaws\@samsung.com> wrote:\n",
- "\n",
- ">> Am I understanding wrong or are you saying that you want to drop\n",
- "\n",
- "userptr\n",
- "\n",
- ">> from V4L2 API in long-term? If so, why?\n",
- "\n",
- "> \n",
- "\n",
- "> Dropping userptr is just some brainstorming idea.\n",
- "\n",
- "> It was found out that userptr is not a good mean\n",
- "\n",
- "> for buffer exchange between to two devices.\n",
- "\n",
- "\n",
- "\n",
- "I can believe that. But I am also inclined to believe that DMABUF is\n",
- "\n",
- "targetted at device-to-device transfer, while USERPTR is targetted at\n",
- "\n",
- "device-to-user (or user-to-device) transfers. Are you saying applications\n",
- "\n",
- "should use DMABUF and memory map the buffers? Or would you care to explain\n",
- "\n",
- "how DMABUF addresses the problem space of USERPTR?\n",
- "\n",
- "\n",
- "\n",
- "> The USERPTR simplifies userspace code but introduce\n",
- "\n",
- "> a lot of complexity problems for the kernel drivers\n",
- "\n",
- "> and frameworks.\n",
- "\n",
- "\n",
- "\n",
- "It is not only a simplification. In some cases, USERPTR is the only I/O\n",
- "\n",
- "method that supports zero copy in pretty much any circumstance. When the\n",
- "\n",
- "user cannot reliably predict the maximum number of required buffers,\n",
- "\n",
- "predicts a value larger than the device will negotiate, or needs buffers to\n",
- "\n",
- "outlive STREAMOFF (?), MMAP requires memory copying. USERPTR does not.\n",
- "\n",
- "\n",
- "\n",
- "Now, I do realize that some devices cannot support USERPTR efficiently,\n",
- "\n",
- "then they should not support USERPTR. But for those devices that can, it\n",
- "\n",
- "seems quite a nice performance enhancement.\n",
- "\n",
- "\n",
- "\n",
- "-- \n",
- "\n",
- "R\303\251mi Denis-Courmont\n",
- "\n",
+ "On Fri, 20 Apr 2012 10:41:37 +0200, Tomasz Stanislawski\r\n",
+ "<t.stanislaws\@samsung.com> wrote:\r\n",
+ ">> Am I understanding wrong or are you saying that you want to drop\r\n",
+ "userptr\r\n",
+ ">> from V4L2 API in long-term? If so, why?\r\n",
+ "> \r\n",
+ "> Dropping userptr is just some brainstorming idea.\r\n",
+ "> It was found out that userptr is not a good mean\r\n",
+ "> for buffer exchange between to two devices.\r\n",
+ "\r\n",
+ "I can believe that. But I am also inclined to believe that DMABUF is\r\n",
+ "targetted at device-to-device transfer, while USERPTR is targetted at\r\n",
+ "device-to-user (or user-to-device) transfers. Are you saying applications\r\n",
+ "should use DMABUF and memory map the buffers? Or would you care to explain\r\n",
+ "how DMABUF addresses the problem space of USERPTR?\r\n",
+ "\r\n",
+ "> The USERPTR simplifies userspace code but introduce\r\n",
+ "> a lot of complexity problems for the kernel drivers\r\n",
+ "> and frameworks.\r\n",
+ "\r\n",
+ "It is not only a simplification. In some cases, USERPTR is the only I/O\r\n",
+ "method that supports zero copy in pretty much any circumstance. When the\r\n",
+ "user cannot reliably predict the maximum number of required buffers,\r\n",
+ "predicts a value larger than the device will negotiate, or needs buffers to\r\n",
+ "outlive STREAMOFF (?), MMAP requires memory copying. USERPTR does not.\r\n",
+ "\r\n",
+ "Now, I do realize that some devices cannot support USERPTR efficiently,\r\n",
+ "then they should not support USERPTR. But for those devices that can, it\r\n",
+ "seems quite a nice performance enhancement.\r\n",
+ "\r\n",
+ "-- \r\n",
+ "R\303\251mi Denis-Courmont\r\n",
"Sent from my collocated server"
]
-3833f494806424657b5563f1f035a89676b0cf668a58bd852d65400f188f6cbb
+cf6f2753304594ce72f36928b3c626f2996862e20b27f72ef84b56883f716090
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.