On Mon, Jan 9, 2012 at 8:10 AM, Daniel Vetter wrote:
> 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 9, 2012 at 8:10 AM, Daniel Vetter dan...@ffwll.ch wrote:
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:
Hi Arnd,
On Tue, Dec 20, 2011 at 03:36:49PM +, Arnd Bergmann wrote:
On Tuesday 20 December 2011, Sakari Ailus wrote:
(I'm jumping into the discussion in the middle, and might miss something
that has already been talked about. I still hope what I'm about to say is
relevant. :-))
It
Hi Arnd,
On Tue, Dec 20, 2011 at 03:36:49PM +, Arnd Bergmann wrote:
> On Tuesday 20 December 2011, Sakari Ailus wrote:
> > (I'm jumping into the discussion in the middle, and might miss something
> > that has already been talked about. I still hope what I'm about to say is
> > relevant. :-))
On Sun, Jan 1, 2012 at 2:53 PM, Sakari Ailus wrote:
> Hi Arnd,
>
> On Tue, Dec 20, 2011 at 03:36:49PM +, Arnd Bergmann wrote:
>> On Tuesday 20 December 2011, Sakari Ailus wrote:
>> > (I'm jumping into the discussion in the middle, and might miss something
>> > that has already been talked
On Sun, Jan 1, 2012 at 2:53 PM, Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Arnd,
On Tue, Dec 20, 2011 at 03:36:49PM +, Arnd Bergmann wrote:
On Tuesday 20 December 2011, Sakari Ailus wrote:
(I'm jumping into the discussion in the middle, and might miss something
that has already been
On Wed, Dec 21, 2011 at 10:57 PM, Arnd Bergmann wrote:
> On Tuesday 20 December 2011, Daniel Vetter wrote:
>> > I'm thinking for a first version, we can get enough mileage out of it by
>> > saying:
>> > 1) only exporter can mmap to userspace
>> > 2) only importers that do not need CPU access to
On Fri, Dec 23, 2011 at 4:00 AM, Semwal, Sumit wrote:
> On Wed, Dec 21, 2011 at 10:57 PM, Arnd Bergmann wrote:
>> On Tuesday 20 December 2011, Daniel Vetter wrote:
>>> > I'm thinking for a first version, we can get enough mileage out of it by
>>> > saying:
>>> > 1) only exporter can mmap to
On Wed, Dec 21, 2011 at 10:57 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 20 December 2011, Daniel Vetter wrote:
I'm thinking for a first version, we can get enough mileage out of it by
saying:
1) only exporter can mmap to userspace
2) only importers that do not need CPU access to
On Fri, Dec 23, 2011 at 4:00 AM, Semwal, Sumit sumit.sem...@ti.com wrote:
On Wed, Dec 21, 2011 at 10:57 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 20 December 2011, Daniel Vetter wrote:
I'm thinking for a first version, we can get enough mileage out of it by
saying:
1) only
On Wed, Dec 21, 2011 at 05:27:16PM +, Arnd Bergmann wrote:
> On Tuesday 20 December 2011, Daniel Vetter wrote:
> > It also sounds like that at least for proper userspace mmap support we'd
> > need some dma api extensions on at least arm, and that might take a while
> > ...
>
> I think it's
On Tuesday 20 December 2011, Daniel Vetter wrote:
> > I'm thinking for a first version, we can get enough mileage out of it by
> > saying:
> > 1) only exporter can mmap to userspace
> > 2) only importers that do not need CPU access to buffer..
Ok, that sounds possible. The alternative to this
On Tue, Dec 20, 2011 at 10:41:45AM -0600, Rob Clark wrote:
> On Tue, Dec 20, 2011 at 9:41 AM, Arnd Bergmann wrote:
> > On Monday 19 December 2011, Semwal, Sumit wrote:
> >> I didn't see a consensus on whether dma_buf should enforce some form
> >> of serialization within the API - so atleast for
On Tue, Dec 20, 2011 at 4:05 AM, Robert Morell wrote:
>
> One of the goals of this project is to unify the fragmented space of the
> ARM SoC memory managers so that each vendor doesn't implement their own,
> and they can all be closer to mainline.
That is a very good objective.
> I fear that
On Monday 19 December 2011, Semwal, Sumit wrote:
> I didn't see a consensus on whether dma_buf should enforce some form
> of serialization within the API - so atleast for v1 of dma-buf, I
> propose to 'not' impose a restriction, and we can tackle it (add new
> ops or enforce as design?) whenever
On Tuesday 20 December 2011, Sakari Ailus wrote:
> (I'm jumping into the discussion in the middle, and might miss something
> that has already been talked about. I still hope what I'm about to say is
> relevant. :-))
It certainly is relevant.
> In subsystems such as V4L2 where drivers deal with
Hi Arnd,
On Fri, Dec 09, 2011 at 02:13:03PM +, Arnd Bergmann wrote:
> On Thursday 08 December 2011, Daniel Vetter wrote:
> > > c) only allowing streaming mappings, even if those are non-coherent
> > > (requiring strict serialization between CPU (in-kernel) and dma users of
> > > the buffer)
>
On Tue, Dec 20, 2011 at 9:41 AM, Arnd Bergmann wrote:
> On Monday 19 December 2011, Semwal, Sumit wrote:
>> I didn't see a consensus on whether dma_buf should enforce some form
>> of serialization within the API - so atleast for v1 of dma-buf, I
>> propose to 'not' impose a restriction, and we
Hi Arnd,
On Fri, Dec 09, 2011 at 02:13:03PM +, Arnd Bergmann wrote:
On Thursday 08 December 2011, Daniel Vetter wrote:
c) only allowing streaming mappings, even if those are non-coherent
(requiring strict serialization between CPU (in-kernel) and dma users of
the buffer)
I
On Tue, Dec 20, 2011 at 4:05 AM, Robert Morell rmor...@nvidia.com wrote:
One of the goals of this project is to unify the fragmented space of the
ARM SoC memory managers so that each vendor doesn't implement their own,
and they can all be closer to mainline.
That is a very good objective.
I
On Tuesday 20 December 2011, Sakari Ailus wrote:
(I'm jumping into the discussion in the middle, and might miss something
that has already been talked about. I still hope what I'm about to say is
relevant. :-))
It certainly is relevant.
In subsystems such as V4L2 where drivers deal with such
On Monday 19 December 2011, Semwal, Sumit wrote:
I didn't see a consensus on whether dma_buf should enforce some form
of serialization within the API - so atleast for v1 of dma-buf, I
propose to 'not' impose a restriction, and we can tackle it (add new
ops or enforce as design?) whenever we
On Tue, Dec 20, 2011 at 9:41 AM, Arnd Bergmann a...@arndb.de wrote:
On Monday 19 December 2011, Semwal, Sumit wrote:
I didn't see a consensus on whether dma_buf should enforce some form
of serialization within the API - so atleast for v1 of dma-buf, I
propose to 'not' impose a restriction, and
On Tue, Dec 20, 2011 at 10:41:45AM -0600, Rob Clark wrote:
On Tue, Dec 20, 2011 at 9:41 AM, Arnd Bergmann a...@arndb.de wrote:
On Monday 19 December 2011, Semwal, Sumit wrote:
I didn't see a consensus on whether dma_buf should enforce some form
of serialization within the API - so atleast
On Tue, Dec 13, 2011 at 07:10:02AM -0800, Arnd Bergmann wrote:
> On Monday 12 December 2011, Robert Morell wrote:
> > >
> > > Doing a buffer sharing with something that is not GPL is not fun, as, if
> > > any
> > > issue rises there, it would be impossible to discover if the problem is
> > >
Hi Arnd, Daniel,
On Mon, Dec 12, 2011 at 10:18 PM, Arnd Bergmann wrote:
> On Saturday 10 December 2011, Daniel Vetter wrote:
>> If userspace (through some driver calls)
>> tries to do stupid things, it'll just get garbage. See
>> Message-ID: > mail.gmail.com>
>> for my reasons why it think this
On Tue, Dec 13, 2011 at 07:10:02AM -0800, Arnd Bergmann wrote:
On Monday 12 December 2011, Robert Morell wrote:
Doing a buffer sharing with something that is not GPL is not fun, as, if
any
issue rises there, it would be impossible to discover if the problem is
either
at the
On Monday 12 December 2011, Robert Morell wrote:
> >
> > Doing a buffer sharing with something that is not GPL is not fun, as, if any
> > issue rises there, it would be impossible to discover if the problem is
> > either
> > at the closed-source driver or at the open source one. At the time I
(I've been away for the past two weeks, so I'm only now catching up)
On Thursday 08 December 2011 22:44:08 Daniel Vetter wrote:
> On Wed, Dec 7, 2011 at 14:40, Arnd Bergmann wrote:
> > On Wednesday 07 December 2011, Semwal, Sumit wrote:
> >> Thanks for the excellent discussion - it indeed is
(I've been away for the past two weeks, so I'm only now catching up)
On Thursday 08 December 2011 22:44:08 Daniel Vetter wrote:
On Wed, Dec 7, 2011 at 14:40, Arnd Bergmann a...@arndb.de wrote:
On Wednesday 07 December 2011, Semwal, Sumit wrote:
Thanks for the excellent discussion - it
On Saturday 10 December 2011, Daniel Vetter wrote:
> If userspace (through some driver calls)
> tries to do stupid things, it'll just get garbage. See
> Message-ID: mail.gmail.com>
> for my reasons why it think this is the right way to go forward. So in
> essence I'm really interested in the
On Sat, Dec 10, 2011 at 03:13:06AM -0800, Mauro Carvalho Chehab wrote:
> On 09-12-2011 20:50, Robert Morell wrote:
> > On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote:
> >> On Friday 02 December 2011, Sumit Semwal wrote:
> >>> This is the first step in defining a dma buffer sharing
On Saturday 10 December 2011, Daniel Vetter wrote:
If userspace (through some driver calls)
tries to do stupid things, it'll just get garbage. See
Message-ID:
cakmk7uhexyn-v_8cmplnwsfy14ktmurzy8yrkr5xst2-2wd...@mail.gmail.com
for my reasons why it think this is the right way to go forward.
On Sat, Dec 10, 2011 at 03:13:06AM -0800, Mauro Carvalho Chehab wrote:
On 09-12-2011 20:50, Robert Morell wrote:
On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote:
On Friday 02 December 2011, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
On 09-12-2011 20:50, Robert Morell wrote:
> On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote:
>> On Friday 02 December 2011, Sumit Semwal wrote:
>>> This is the first step in defining a dma buffer sharing mechanism.
>>
> [...]
>>
>>> + return dmabuf;
>>> +}
>>>
On Fri, Dec 9, 2011 at 15:24, Alan Cox wrote:
>> I still don't think that's possible. Please explain how you expect
>> to change the semantics of the streaming mapping API to allow multiple
>> mappers without having explicit serialization points that are visible
>> to all users. For simplicity,
On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote:
On Friday 02 December 2011, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
[...]
+ return dmabuf;
+}
+EXPORT_SYMBOL(dma_buf_export);
I agree with Konrad, this should definitely
On 09-12-2011 20:50, Robert Morell wrote:
On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote:
On Friday 02 December 2011, Sumit Semwal wrote:
This is the first step in defining a dma buffer sharing mechanism.
[...]
+ return dmabuf;
+}
+EXPORT_SYMBOL(dma_buf_export);
I
On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote:
> On Friday 02 December 2011, Sumit Semwal wrote:
> > This is the first step in defining a dma buffer sharing mechanism.
>
[...]
>
> > + return dmabuf;
> > +}
> > +EXPORT_SYMBOL(dma_buf_export);
>
> I agree with Konrad, this
> I still don't think that's possible. Please explain how you expect
> to change the semantics of the streaming mapping API to allow multiple
> mappers without having explicit serialization points that are visible
> to all users. For simplicity, let's assume a cache coherent system
I would agree.
On Thursday 08 December 2011, Daniel Vetter wrote:
> > c) only allowing streaming mappings, even if those are non-coherent
> > (requiring strict serialization between CPU (in-kernel) and dma users of
> > the buffer)
>
> I think only allowing streaming access makes the most sense:
> - I don't see
On Thursday 08 December 2011, Daniel Vetter wrote:
c) only allowing streaming mappings, even if those are non-coherent
(requiring strict serialization between CPU (in-kernel) and dma users of
the buffer)
I think only allowing streaming access makes the most sense:
- I don't see much (if
I still don't think that's possible. Please explain how you expect
to change the semantics of the streaming mapping API to allow multiple
mappers without having explicit serialization points that are visible
to all users. For simplicity, let's assume a cache coherent system
I would agree.
On Wed, Dec 7, 2011 at 14:40, Arnd Bergmann wrote:
> 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
>>
44 matches
Mail list logo
