-----Original Message-----
From: Lucas Stach [mailto:l.stach@pengutronix.de]
Sent: Thursday, June 20, 2013 7:11 PM
To: Inki Dae
Cc: 'Russell King - ARM Linux'; 'Inki Dae'; 'linux-fbdev'; 'YoungJun Cho';
'Kyungmin Park'; 'myungjoo.ham'; 'DRI mailing list'; linux-arm-
kernel@lists.infradead.org; linux-media@vger.kernel.org
Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
framework
Am Donnerstag, den 20.06.2013, 17:24 +0900 schrieb Inki Dae:
[...]
quoted
quoted
quoted
In addition, please see the below more detail examples.
The conventional way (without dmabuf-sync) is:
Task A
----------------------------
1. CPU accesses buf
2. Send the buf to Task B
3. Wait for the buf from Task B
4. go to 1
Task B
---------------------------
1. Wait for the buf from Task A
2. qbuf the buf
2.1 insert the buf to incoming queue
3. stream on
3.1 dma_map_sg if ready, and move the buf to ready queue
3.2 get the buf from ready queue, and dma start.
4. dqbuf
4.1 dma_unmap_sg after dma operation completion
4.2 move the buf to outgoing queue
5. back the buf to Task A
6. go to 1
In case that two tasks share buffers, and data flow goes from Task A
to
quoted
quoted
Task
quoted
B, we would need IPC operation to send and receive buffers properly
94 more quoted lines
In my opinion, that's not definitely easiest way. What I try to do is to avoid using *the out-of-band IPC*. As I mentioned in document file, the conventional mechanism not only makes user application complicated-user process needs to understand how the device driver is worked-but also may incur performance overhead by using the out-of-band IPC. The above my example may not be enough to you but there would be other cases able to use my approach efficiently.
A more advanced way to achieve this
would be using cross-device fences to avoid going through userspace for
every syncpoint.
Ok, maybe there is something I missed. So question. What is the cross-device fences? dma fence?. And how we can achieve the synchronization mechanism without going through user space for every syncpoint; CPU and DMA share a same buffer?. And could you explain it in detail as long as possible like I did?
quoted
With dmabuf-sync is:
Task A
----------------------------
1. dma_buf_sync_lock <- synpoint (call by user side)
2. CPU writes something to buf1
3. dma_buf_sync_unlock <- syncpoint (call by user side)
4. copy buf1 to buf2
Random contents here? What's in the buffer, content from the CPU write,
or from V4L2 device write?
Please presume that buf1 is physically non contiguous memory, and buf2 is physically contiguous memory; device A without IOMMU is seeing buf2. We would need to copy buf1 to buf2 to send the contents of the buf1 to device A because DMA of the device A cannot access the buf1 directly. And CPU and V4L2 device don't share the contents of the buf1 but share the buf1 as storage.
Thanks,
Inki Dae
quoted
5. go to 1
Task B
---------------------------
1. dma_buf_sync_lock
2. CPU writes something to buf3
3. dma_buf_sync_unlock
4. qbuf the buf3(src) and buf1(dst)
4.1 insert buf3,1 to incoming queue
4.2 dma_buf_sync_lock <- syncpoint (call by kernel side)
5. stream on
5.1 dma_map_sg if ready, and move the buf to ready queue
5.2 get the buf from ready queue, and dma start.
6. dqbuf
6.1 dma_buf_sync_unlock <- syncpoint (call by kernel side)
6.2 dma_unmap_sg after dma operation completion
6.3 move the buf3,1 to outgoing queue
7. go to 1
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |