2012/1/10 InKi Dae daei...@gmail.com:
2012/1/10 Semwal, Sumit sumit.sem...@ti.com:
On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark r...@ti.com wrote:
On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae daei...@gmail.com wrote:
2012/1/10 Rob Clark r...@ti.com:
at least with no IOMMU, the memory
2012/1/10 Rob Clark r...@ti.com:
On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae daei...@gmail.com wrote:
2012/1/10 Rob Clark r...@ti.com:
On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae daei...@gmail.com wrote:
note : in case of sharing a buffer between v4l2 and drm driver, the
memory info would be copied
On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
I has test dmabuf based drm gem module for exynos and I found one problem.
you can refer to this test repository:
http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/exynos-drm-dmabuf
at this repository, I added
2012/1/9 Daniel Vetter dan...@ffwll.ch:
On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
I has test dmabuf based drm gem module for exynos and I found one problem.
you can refer to this test repository:
On Mon, Jan 09, 2012 at 07:10:25PM +0900, InKi Dae wrote:
2012/1/9 Daniel Vetter dan...@ffwll.ch:
On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
I has test dmabuf based drm gem module for exynos and I found one problem.
you can refer to this test repository:
2012/1/9 Daniel Vetter dan...@ffwll.ch:
On Mon, Jan 09, 2012 at 07:10:25PM +0900, InKi Dae wrote:
2012/1/9 Daniel Vetter dan...@ffwll.ch:
On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
I has test dmabuf based drm gem module for exynos and I found one problem.
you can refer to
On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae daei...@gmail.com wrote:
note : in case of sharing a buffer between v4l2 and drm driver, the
memory info would be copied vb2_xx_buf to xx_gem or xx_gem to
vb2_xx_buf through sg table. in this case, only memory info is used to
share, not some objects.
On Mon, Jan 09, 2012 at 09:06:56PM +0900, InKi Dae wrote:
2012/1/9 Daniel Vetter dan...@ffwll.ch:
On Mon, Jan 09, 2012 at 07:10:25PM +0900, InKi Dae wrote:
2012/1/9 Daniel Vetter dan...@ffwll.ch:
On Mon, Jan 09, 2012 at 03:20:48PM +0900, InKi Dae wrote:
I has test dmabuf based drm gem
2012/1/10 Rob Clark r...@ti.com:
On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae daei...@gmail.com wrote:
note : in case of sharing a buffer between v4l2 and drm driver, the
memory info would be copied vb2_xx_buf to xx_gem or xx_gem to
vb2_xx_buf through sg table. in this case, only memory info is
On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae daei...@gmail.com wrote:
2012/1/10 Rob Clark r...@ti.com:
On Mon, Jan 9, 2012 at 4:10 AM, InKi Dae daei...@gmail.com wrote:
note : in case of sharing a buffer between v4l2 and drm driver, the
memory info would be copied vb2_xx_buf to xx_gem or xx_gem to
On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark r...@ti.com wrote:
On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae daei...@gmail.com wrote:
2012/1/10 Rob Clark r...@ti.com:
at least with no IOMMU, the memory information(containing physical
memory address) would be copied to vb2_xx_buf object if drm gem
2012/1/10 Semwal, Sumit sumit.sem...@ti.com:
On Tue, Jan 10, 2012 at 7:44 AM, Rob Clark r...@ti.com wrote:
On Mon, Jan 9, 2012 at 7:34 PM, InKi Dae daei...@gmail.com wrote:
2012/1/10 Rob Clark r...@ti.com:
at least with no IOMMU, the memory information(containing physical
memory address)
On Wednesday 07 December 2011, Semwal, Sumit wrote:
Do you have a use case for making the interface compile-time disabled?
I had assumed that any code using it would make no sense if it's not
available so you don't actually need this.
Ok. Though if we keep the interface compile-time
On Wed, Dec 7, 2011 at 3:41 PM, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 07 December 2011, Semwal, Sumit wrote:
Do you have a use case for making the interface compile-time disabled?
I had assumed that any code using it would make no sense if it's not
available so you don't
On Wednesday 07 December 2011, Semwal, Sumit wrote:
Right; that would be ideal, but we may not be able to ask each user to
do so - especially when the sharing part might be interspersed in
existing buffer handling code. So for now, I would like to keep it as
it-is.
Ok, fair enough. It
Hi Daniel, Rob,
On Tue, Dec 6, 2011 at 3:41 AM, Rob Clark r...@ti.com wrote:
On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann a...@arndb.de wrote:
In the patch 2,
On Wednesday 07 December 2011, Semwal, Sumit wrote:
Thanks for the excellent discussion - it indeed is very good learning
for the relatively-inexperienced me :)
So, for the purpose of dma-buf framework, could I summarize the
following and rework accordingly?:
1. remove mmap() dma_buf_op
On Monday 05 December 2011, Rob Clark wrote:
On the topic of a coherency model for dmabuf, I think we need to look at
dma_buf_attachment_map/unmap (and also the mmap variants cpu_start and
cpu_finish or whatever they might get called) as barriers:
So after a dma_buf_map, all previsously
On Tue, Dec 06, 2011 at 01:16:58PM +, Arnd Bergmann wrote:
On Monday 05 December 2011, Rob Clark wrote:
On the topic of a coherency model for dmabuf, I think we need to look at
dma_buf_attachment_map/unmap (and also the mmap variants cpu_start and
cpu_finish or whatever they might
Hi Arnd,
Thanks for your review!
On Mon, Dec 5, 2011 at 10:48 PM, Arnd Bergmann a...@arndb.de wrote:
On Friday 02 December 2011, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
This looks very nice, but there are a few things I don't understand yet
and
On Friday 02 December 2011, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
This looks very nice, but there are a few things I don't understand yet
and a bunch of trivial comments I have about things I spotted.
Do you have prototype exporter and consumer
On Mon, Dec 05, 2011 at 05:18:48PM +, Arnd Bergmann wrote:
On Friday 02 December 2011, Sumit Semwal wrote:
+ /* 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
On Monday 05 December 2011 19:55:44 Daniel Vetter wrote:
The only way to solve this that I can think of right now is to
mandate that the mappings are all coherent (i.e. noncachable
on noncoherent architectures like ARM). If you do that, you no
longer need the sync_sg_for_* calls.
Woops,
On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann a...@arndb.de wrote:
On Friday 02 December 2011, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
This looks very nice, but there are a few things I don't understand yet
and a bunch of trivial comments I have
On Mon, Dec 05, 2011 at 08:29:49PM +0100, Arnd Bergmann wrote:
On Monday 05 December 2011 19:55:44 Daniel Vetter wrote:
The only way to solve this that I can think of right now is to
mandate that the mappings are all coherent (i.e. noncachable
on noncoherent architectures like ARM). If
On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann a...@arndb.de wrote:
In the patch 2, you have a section about migration that mentions that
it is possible to export a buffer that can be migrated after it
is already mapped into one
On Monday 05 December 2011 21:58:39 Daniel Vetter wrote:
On Mon, Dec 05, 2011 at 08:29:49PM +0100, Arnd Bergmann wrote:
...
Thanks a lot for this excellent overview. I think at least for the first
version of dmabuf we should drop the sync_* interfaces and simply require
users to bracket
On Monday 05 December 2011 14:46:47 Rob Clark wrote:
On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann a...@arndb.de wrote:
On Friday 02 December 2011, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
This looks very nice, but there are a few things I
On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
On Mon, Dec 5, 2011 at 11:18 AM, Arnd Bergmann a...@arndb.de wrote:
In the patch 2, you have a section about migration that mentions that
it is possible to export a
On Mon, Dec 5, 2011 at 4:09 PM, Arnd Bergmann a...@arndb.de wrote:
https://github.com/robclark/kernel-omap4/commits/dmabuf
Ok, thanks. I think it would be good to post these for reference
in v3, with a clear indication that they are not being submitted
for discussion/inclusion yet.
btw,
On Mon, Dec 05, 2011 at 04:11:46PM -0600, Rob Clark wrote:
On Mon, Dec 5, 2011 at 3:23 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Dec 05, 2011 at 02:46:47PM -0600, Rob Clark wrote:
I sort of preferred having the DMABUF shim because that lets you pass
a buffer around userspace without
On Mon, Dec 5, 2011 at 4:09 PM, Arnd Bergmann a...@arndb.de wrote:
On Monday 05 December 2011 14:46:47 Rob Clark wrote:
I sort of preferred having the DMABUF shim because that lets you pass
a buffer around userspace without the receiving code knowing about a
device specific API. But the
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.
A new buffer object dma_buf is added, with operations and API to allow easy
sharing of this buffer object across devices.
The framework allows:
- different
33 matches
Mail list logo
