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
Hi Daniel,
On Tue, Mar 6, 2012 at 12:27 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Fri, Mar 2, 2012 at 23:24, Rob Clark robdcl...@gmail.com wrote:
Perhaps we should check somewhere for required dmabuf ops fxns (like
kmap_atomic here), rather than just calling unconditionally what might
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
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
On Fri, Mar 2, 2012 at 23:24, Rob Clark robdcl...@gmail.com 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
On Fri, Mar 2, 2012 at 23:53, Rob Clark rob.cl...@linaro.org 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.
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
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
On Thu, Mar 1, 2012 at 9:36 AM, Daniel Vetter daniel.vet...@ffwll.ch 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
On Thu, 1 Mar 2012 16:36:00 +0100, Daniel Vetter daniel.vet...@ffwll.ch
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
On Fri, Mar 2, 2012 at 4:38 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Thu, 1 Mar 2012 16:36:00 +0100, Daniel Vetter daniel.vet...@ffwll.ch
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
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
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
13 matches
Mail list logo
