Hi Daniel,
On Tue, Mar 6, 2012 at 12:27 AM, Daniel Vetter
wrote:
> On Fri, Mar 2, 2012 at 23:24, Rob Clark wrote:
>> Perhaps we should check somewhere for required dmabuf ops fxns (like
>> kmap_atomic here), rather than just calling unconditionally what might
>> be a null ptr. ?At least put it i
Hi Daniel,
On Tue, Mar 6, 2012 at 12:27 AM, Daniel Vetter wrote:
> On Fri, Mar 2, 2012 at 23:24, Rob Clark wrote:
>> Perhaps we should check somewhere for required dmabuf ops fxns (like
>> kmap_atomic here), rather than just calling unconditionally what might
>> be a null ptr. At least put it in
On Fri, Mar 2, 2012 at 23:53, Rob Clark wrote:
> nitially the expectation was that userspace would not pass a buffer
> to multiple subsystems for writing (or that if it did, it would get
> the undefined results that one could expect).. ?so dealing w/
> synchronization was punted.
Imo synchronizat
On Fri, Mar 2, 2012 at 23:24, Rob Clark wrote:
> Perhaps we should check somewhere for required dmabuf ops fxns (like
> kmap_atomic here), rather than just calling unconditionally what might
> be a null ptr. ?At least put it in the WARN_ON(), but it might be
> nicer to catch a missing required fxn
On Fri, Mar 2, 2012 at 23:53, Rob Clark wrote:
> nitially the expectation was that userspace would not pass a buffer
> to multiple subsystems for writing (or that if it did, it would get
> the undefined results that one could expect).. so dealing w/
> synchronization was punted.
Imo synchronizat
On Fri, Mar 2, 2012 at 23:24, Rob Clark wrote:
> Perhaps we should check somewhere for required dmabuf ops fxns (like
> kmap_atomic here), rather than just calling unconditionally what might
> be a null ptr. At least put it in the WARN_ON(), but it might be
> nicer to catch a missing required fxn
On Thu, 1 Mar 2012 16:36:00 +0100, Daniel Vetter
wrote:
> Big differences to other contenders in the field (like ion) is
> that this also supports highmem, so we have to split up the cpu
> access from the kernel side into a prepare and a kmap step.
>
> Prepare is allowed to fail and should do e
On Fri, Mar 2, 2012 at 4:38 PM, Chris Wilson
wrote:
> On Thu, ?1 Mar 2012 16:36:00 +0100, Daniel Vetter
> wrote:
>> Big differences to other contenders in the field (like ion) is
>> that this also supports highmem, so we have to split up the cpu
>> access from the kernel side into a prepare and
On Thu, Mar 1, 2012 at 9:36 AM, Daniel Vetter wrote:
> Big differences to other contenders in the field (like ion) is
> that this also supports highmem, so we have to split up the cpu
> access from the kernel side into a prepare and a kmap step.
>
> Prepare is allowed to fail and should do everyth
On Fri, Mar 2, 2012 at 4:38 PM, Chris Wilson wrote:
> On Thu, 1 Mar 2012 16:36:00 +0100, Daniel Vetter
> wrote:
>> Big differences to other contenders in the field (like ion) is
>> that this also supports highmem, so we have to split up the cpu
>> access from the kernel side into a prepare and
On Thu, 1 Mar 2012 16:36:00 +0100, Daniel Vetter
wrote:
> Big differences to other contenders in the field (like ion) is
> that this also supports highmem, so we have to split up the cpu
> access from the kernel side into a prepare and a kmap step.
>
> Prepare is allowed to fail and should do e
On Thu, Mar 1, 2012 at 9:36 AM, Daniel Vetter wrote:
> Big differences to other contenders in the field (like ion) is
> that this also supports highmem, so we have to split up the cpu
> access from the kernel side into a prepare and a kmap step.
>
> Prepare is allowed to fail and should do everyth
Big differences to other contenders in the field (like ion) is
that this also supports highmem, so we have to split up the cpu
access from the kernel side into a prepare and a kmap step.
Prepare is allowed to fail and should do everything required so that
the kmap calls can succeed (like swapin/ba
Big differences to other contenders in the field (like ion) is
that this also supports highmem, so we have to split up the cpu
access from the kernel side into a prepare and a kmap step.
Prepare is allowed to fail and should do everything required so that
the kmap calls can succeed (like swapin/ba
14 matches
Mail list logo
