From: Inki Dae <inki.dae@samsung.com>
To: linux-fbdev@vger.kernel.org
Subject: RE: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
Date: Tue, 18 Jun 2013 09:04:44 +0000 [thread overview]
Message-ID: <008a01ce6c02$e00a9f50$a01fddf0$%dae@samsung.com> (raw)
In-Reply-To: <1371467722-665-1-git-send-email-inki.dae@samsung.com>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Tuesday, June 18, 2013 5:43 PM
> To: Inki Dae
> Cc: 'Maarten Lankhorst'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI mailing
> list'; 'Rob Clark'; 'myungjoo.ham'; 'YoungJun Cho'; 'Daniel Vetter';
> linux-arm-kernel@lists.infradead.org; linux-media@vger.kernel.org
> Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
> framework
>
> On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote:
> > So I'd like to ask for other DRM maintainers. How do you think about it?
> it
> > seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained
> by
> > Rob) and GEM CMA helper also have same issue Russell pointed out. I
> think
> > not only the above approach but also the performance is very important.
>
> CMA uses coherent memory to back their buffers, though that might not be
> true of memory obtained from other drivers via dma_buf. Plus, there is
> no support in the CMA helper for exporting or importng these buffers.
>
It's not so. Please see Dave's drm next. recently dmabuf support for the CMA
helper has been merged to there.
> I guess Intel i915 is only used on x86, which is a coherent platform and
> requires no cache maintanence for DMA.
>
> OMAP DRM does not support importing non-DRM buffers buffers back into
Correct. TODO yet.
> DRM. Moreover, it will suffer from the problems I described if any
> attempt is made to write to the buffer after it has been re-imported.
>
> Lastly, I should point out that the dma_buf stuff is really only useful
> when you need to export a dma buffer from one driver and import it into
> another driver - for example to pass data from a camera device driver to
Most people know that.
> a display device driver. It shouldn't be used within a single driver
> as a means of passing buffers between userspace and kernel space.
What I try to do is not really such ugly thing. What I try to do is to
notify that, when CPU tries to access a buffer , to kernel side through
dmabuf interface. So it's not really to send the buffer to kernel.
Thanks,
Inki Dae
WARNING: multiple messages have this Message-ID (diff)
From: inki.dae@samsung.com (Inki Dae)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
Date: Tue, 18 Jun 2013 18:04:44 +0900 [thread overview]
Message-ID: <008a01ce6c02$e00a9f50$a01fddf0$%dae@samsung.com> (raw)
In-Reply-To: <20130618084308.GU2718@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Tuesday, June 18, 2013 5:43 PM
> To: Inki Dae
> Cc: 'Maarten Lankhorst'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI mailing
> list'; 'Rob Clark'; 'myungjoo.ham'; 'YoungJun Cho'; 'Daniel Vetter';
> linux-arm-kernel at lists.infradead.org; linux-media at vger.kernel.org
> Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
> framework
>
> On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote:
> > So I'd like to ask for other DRM maintainers. How do you think about it?
> it
> > seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained
> by
> > Rob) and GEM CMA helper also have same issue Russell pointed out. I
> think
> > not only the above approach but also the performance is very important.
>
> CMA uses coherent memory to back their buffers, though that might not be
> true of memory obtained from other drivers via dma_buf. Plus, there is
> no support in the CMA helper for exporting or importng these buffers.
>
It's not so. Please see Dave's drm next. recently dmabuf support for the CMA
helper has been merged to there.
> I guess Intel i915 is only used on x86, which is a coherent platform and
> requires no cache maintanence for DMA.
>
> OMAP DRM does not support importing non-DRM buffers buffers back into
Correct. TODO yet.
> DRM. Moreover, it will suffer from the problems I described if any
> attempt is made to write to the buffer after it has been re-imported.
>
> Lastly, I should point out that the dma_buf stuff is really only useful
> when you need to export a dma buffer from one driver and import it into
> another driver - for example to pass data from a camera device driver to
Most people know that.
> a display device driver. It shouldn't be used within a single driver
> as a means of passing buffers between userspace and kernel space.
What I try to do is not really such ugly thing. What I try to do is to
notify that, when CPU tries to access a buffer , to kernel side through
dmabuf interface. So it's not really to send the buffer to kernel.
Thanks,
Inki Dae
WARNING: multiple messages have this Message-ID (diff)
From: Inki Dae <inki.dae@samsung.com>
To: 'Russell King - ARM Linux' <linux@arm.linux.org.uk>
Cc: 'Maarten Lankhorst' <maarten.lankhorst@canonical.com>,
'linux-fbdev' <linux-fbdev@vger.kernel.org>,
'Kyungmin Park' <kyungmin.park@samsung.com>,
'DRI mailing list' <dri-devel@lists.freedesktop.org>,
'Rob Clark' <robdclark@gmail.com>,
"'myungjoo.ham'" <myungjoo.ham@samsung.com>,
'YoungJun Cho' <yj44.cho@samsung.com>,
'Daniel Vetter' <daniel@ffwll.ch>,
linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org
Subject: RE: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
Date: Tue, 18 Jun 2013 18:04:44 +0900 [thread overview]
Message-ID: <008a01ce6c02$e00a9f50$a01fddf0$%dae@samsung.com> (raw)
In-Reply-To: <20130618084308.GU2718@n2100.arm.linux.org.uk>
> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Tuesday, June 18, 2013 5:43 PM
> To: Inki Dae
> Cc: 'Maarten Lankhorst'; 'linux-fbdev'; 'Kyungmin Park'; 'DRI mailing
> list'; 'Rob Clark'; 'myungjoo.ham'; 'YoungJun Cho'; 'Daniel Vetter';
> linux-arm-kernel@lists.infradead.org; linux-media@vger.kernel.org
> Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
> framework
>
> On Tue, Jun 18, 2013 at 02:27:40PM +0900, Inki Dae wrote:
> > So I'd like to ask for other DRM maintainers. How do you think about it?
> it
> > seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained
> by
> > Rob) and GEM CMA helper also have same issue Russell pointed out. I
> think
> > not only the above approach but also the performance is very important.
>
> CMA uses coherent memory to back their buffers, though that might not be
> true of memory obtained from other drivers via dma_buf. Plus, there is
> no support in the CMA helper for exporting or importng these buffers.
>
It's not so. Please see Dave's drm next. recently dmabuf support for the CMA
helper has been merged to there.
> I guess Intel i915 is only used on x86, which is a coherent platform and
> requires no cache maintanence for DMA.
>
> OMAP DRM does not support importing non-DRM buffers buffers back into
Correct. TODO yet.
> DRM. Moreover, it will suffer from the problems I described if any
> attempt is made to write to the buffer after it has been re-imported.
>
> Lastly, I should point out that the dma_buf stuff is really only useful
> when you need to export a dma buffer from one driver and import it into
> another driver - for example to pass data from a camera device driver to
Most people know that.
> a display device driver. It shouldn't be used within a single driver
> as a means of passing buffers between userspace and kernel space.
What I try to do is not really such ugly thing. What I try to do is to
notify that, when CPU tries to access a buffer , to kernel side through
dmabuf interface. So it's not really to send the buffer to kernel.
Thanks,
Inki Dae
next prev parent reply other threads:[~2013-06-18 9:04 UTC|newest]
Thread overview: 135+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-13 8:28 [RFC PATCH] dmabuf-sync: Introduce buffer synchronization framework Inki Dae
2013-06-13 8:28 ` Inki Dae
2013-06-13 8:28 ` Inki Dae
2013-06-13 11:25 ` Inki Dae
2013-06-13 11:25 ` Inki Dae
2013-06-13 11:25 ` Inki Dae
2013-06-13 17:26 ` Russell King - ARM Linux
2013-06-13 17:26 ` Russell King - ARM Linux
2013-06-13 17:26 ` Russell King - ARM Linux
2013-06-14 2:32 ` Inki Dae
2013-06-14 2:32 ` Inki Dae
2013-06-14 2:32 ` Inki Dae
2013-06-17 11:15 ` [RFC PATCH v2] " Inki Dae
2013-06-17 11:15 ` Inki Dae
2013-06-17 11:15 ` Inki Dae
2013-06-17 11:34 ` Maarten Lankhorst
2013-06-17 11:34 ` Maarten Lankhorst
2013-06-17 11:34 ` Maarten Lankhorst
2013-06-17 13:04 ` Inki Dae
2013-06-17 13:04 ` Inki Dae
2013-06-17 13:04 ` Inki Dae
2013-06-17 13:31 ` Russell King - ARM Linux
2013-06-17 13:31 ` Russell King - ARM Linux
2013-06-17 13:31 ` Russell King - ARM Linux
2013-06-17 15:03 ` Inki Dae
2013-06-17 15:42 ` Russell King - ARM Linux
2013-06-17 15:42 ` Russell King - ARM Linux
2013-06-17 15:42 ` Russell King - ARM Linux
2013-06-17 16:01 ` Russell King - ARM Linux
2013-06-17 16:01 ` Russell King - ARM Linux
2013-06-17 16:01 ` Russell King - ARM Linux
2013-06-17 17:19 ` Inki Dae
2013-06-17 18:21 ` Russell King - ARM Linux
2013-06-17 18:21 ` Russell King - ARM Linux
2013-06-17 18:21 ` Russell King - ARM Linux
2013-06-18 7:00 ` Daniel Vetter
2013-06-18 7:00 ` Daniel Vetter
2013-06-18 7:00 ` Daniel Vetter
2013-06-18 10:46 ` Russell King - ARM Linux
2013-06-18 10:46 ` Russell King - ARM Linux
2013-06-18 10:46 ` Russell King - ARM Linux
2013-06-25 9:23 ` Daniel Vetter
2013-06-25 9:23 ` Daniel Vetter
2013-06-25 9:23 ` Daniel Vetter
2013-06-26 17:18 ` Russell King - ARM Linux
2013-06-26 17:18 ` Russell King - ARM Linux
2013-06-26 17:18 ` Russell King - ARM Linux
2013-06-17 13:31 ` Maarten Lankhorst
2013-06-17 13:31 ` Maarten Lankhorst
2013-06-17 13:31 ` Maarten Lankhorst
2013-06-17 15:20 ` Inki Dae
2013-06-18 5:27 ` Inki Dae
2013-06-18 5:27 ` Inki Dae
2013-06-18 5:27 ` Inki Dae
2013-06-18 8:43 ` Russell King - ARM Linux
2013-06-18 8:43 ` Russell King - ARM Linux
2013-06-18 8:43 ` Russell King - ARM Linux
2013-06-18 9:04 ` Inki Dae [this message]
2013-06-18 9:04 ` Inki Dae
2013-06-18 9:04 ` Inki Dae
2013-06-18 9:38 ` Russell King - ARM Linux
2013-06-18 9:38 ` Russell King - ARM Linux
2013-06-18 9:38 ` Russell King - ARM Linux
2013-06-18 9:47 ` Lucas Stach
2013-06-18 9:47 ` Lucas Stach
2013-06-18 9:47 ` Lucas Stach
2013-06-19 5:45 ` Inki Dae
2013-06-19 5:45 ` Inki Dae
2013-06-19 5:45 ` Inki Dae
2013-06-19 10:22 ` Lucas Stach
2013-06-19 10:22 ` Lucas Stach
2013-06-19 10:22 ` Lucas Stach
2013-06-19 9:10 ` [RFC PATCH v3] " Inki Dae
2013-06-19 9:10 ` Inki Dae
2013-06-19 9:10 ` Inki Dae
2013-06-19 10:44 ` [RFC PATCH v2] " Inki Dae
2013-06-19 10:44 ` Inki Dae
2013-06-19 10:44 ` Inki Dae
2013-06-19 12:34 ` Lucas Stach
2013-06-19 12:34 ` Lucas Stach
2013-06-19 12:34 ` Lucas Stach
2013-06-19 15:10 ` Inki Dae
2013-06-19 18:29 ` Russell King - ARM Linux
2013-06-19 18:29 ` Russell King - ARM Linux
2013-06-19 18:29 ` Russell King - ARM Linux
2013-06-20 6:43 ` Inki Dae
2013-06-20 6:43 ` Inki Dae
2013-06-20 6:43 ` Inki Dae
2013-06-20 7:47 ` Lucas Stach
2013-06-20 7:47 ` Lucas Stach
2013-06-20 7:47 ` Lucas Stach
2013-06-20 8:17 ` Russell King - ARM Linux
2013-06-20 8:17 ` Russell King - ARM Linux
2013-06-20 8:17 ` Russell King - ARM Linux
2013-06-20 8:26 ` Lucas Stach
2013-06-20 8:26 ` Lucas Stach
2013-06-20 8:26 ` Lucas Stach
2013-06-20 8:24 ` Inki Dae
2013-06-20 8:24 ` Inki Dae
2013-06-20 8:24 ` Inki Dae
2013-06-20 10:11 ` Lucas Stach
2013-06-20 10:11 ` Lucas Stach
2013-06-20 10:11 ` Lucas Stach
2013-06-20 11:15 ` Inki Dae
2013-06-20 11:15 ` Inki Dae
2013-06-20 11:15 ` Inki Dae
2013-06-21 8:54 ` Lucas Stach
2013-06-21 8:54 ` Lucas Stach
2013-06-21 8:54 ` Lucas Stach
2013-06-21 11:01 ` Inki Dae
2013-06-21 12:27 ` Lucas Stach
2013-06-21 12:27 ` Lucas Stach
2013-06-21 12:27 ` Lucas Stach
2013-06-21 16:55 ` Inki Dae
2013-06-21 16:55 ` Inki Dae
2013-06-21 16:55 ` Inki Dae
2013-06-21 19:02 ` Jerome Glisse
2013-06-21 19:02 ` Jerome Glisse
2013-06-21 19:02 ` Jerome Glisse
2013-06-22 1:36 ` Inki Dae
2013-06-25 9:09 ` [RFC PATCH] " Inki Dae
2013-06-25 11:32 ` Rob Clark
2013-06-25 11:32 ` Rob Clark
2013-06-25 11:32 ` Rob Clark
2013-06-25 14:17 ` Inki Dae
2013-06-25 14:17 ` Inki Dae
2013-06-25 14:17 ` Inki Dae
2013-06-25 14:49 ` Jerome Glisse
2013-06-25 14:49 ` Jerome Glisse
2013-06-25 14:49 ` Jerome Glisse
2013-06-26 16:06 ` Inki Dae
2013-06-26 16:06 ` Inki Dae
2013-06-26 16:06 ` Inki Dae
-- strict thread matches above, loose matches on Subject: below --
2013-08-12 9:55 About buffer sychronization mechanism and cache operation Inki Dae
2013-08-12 9:55 ` Inki Dae
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='008a01ce6c02$e00a9f50$a01fddf0$%dae@samsung.com' \
--to=inki.dae@samsung.com \
--cc=linux-fbdev@vger.kernel.org \
/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 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.