Hi Daniel, Rob,
On 11 May 2012 21:00, Rob Clark wrote:
> On Tue, Apr 24, 2012 at 4:08 AM, Daniel Vetter
> wrote:
>> Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
>>
>> Cc: Rob Clark
>> Cc: Rebecca Schultz Zavin
>> Signed-Off-by: Daniel Vetter
>
> Acked-by: Rob Clark
Tha
Hi Daniel, Rob,
On 11 May 2012 21:00, Rob Clark wrote:
> On Tue, Apr 24, 2012 at 4:08 AM, Daniel Vetter wrote:
>> Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
>>
>> Cc: Rob Clark
>> Cc: Rebecca Schultz Zavin
>> Signed-Off-by: Daniel Vetter
>
> Acked-by: Rob Clark
Thanks
On Tue, Apr 24, 2012 at 4:08 AM, Daniel Vetter
wrote:
> Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
> and corresponding ioctls on the dma_buf file. The major reason for
> that is that many people seem to be under the impression that this is
> also for synchronization with ou
On Tue, Apr 24, 2012 at 4:08 AM, Daniel Vetter wrote:
> Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
> and corresponding ioctls on the dma_buf file. The major reason for
> that is that many people seem to be under the impression that this is
> also for synchronization with out
2012/4/25, Daniel Vetter :
> On Wed, Apr 25, 2012 at 01:37:51AM +0900, InKi Dae wrote:
>> Hi,
>>
>> >
>> > +static int dma_buf_mmap_internal(struct file *file, struct
>> > vm_area_struct *vma)
>> > +{
>> > + struct dma_buf *dmabuf;
>> > +
>> > + if (!is_dma_buf_file(file))
>> > +
Hi,
>
> +static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct
> *vma)
> +{
> + ? ? ? struct dma_buf *dmabuf;
> +
> + ? ? ? if (!is_dma_buf_file(file))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> + ? ? ? dmabuf = file->private_data;
> +
> + ? ? ? /* check for overflowing the buffe
2012/4/25, Daniel Vetter :
> On Wed, Apr 25, 2012 at 01:37:51AM +0900, InKi Dae wrote:
>> Hi,
>>
>> >
>> > +static int dma_buf_mmap_internal(struct file *file, struct
>> > vm_area_struct *vma)
>> > +{
>> > + struct dma_buf *dmabuf;
>> > +
>> > + if (!is_dma_buf_file(file))
>> > +
On Wed, Apr 25, 2012 at 01:37:51AM +0900, InKi Dae wrote:
> Hi,
>
> >
> > +static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct
> > *vma)
> > +{
> > + ? ? ? struct dma_buf *dmabuf;
> > +
> > + ? ? ? if (!is_dma_buf_file(file))
> > + ? ? ? ? ? ? ? return -EINVAL;
> > +
> > + ?
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed
On Wed, Apr 25, 2012 at 01:37:51AM +0900, InKi Dae wrote:
> Hi,
>
> >
> > +static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct
> > *vma)
> > +{
> > + struct dma_buf *dmabuf;
> > +
> > + if (!is_dma_buf_file(file))
> > + return -EINVAL;
> > +
> > +
Hi,
>
> +static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct
> *vma)
> +{
> + struct dma_buf *dmabuf;
> +
> + if (!is_dma_buf_file(file))
> + return -EINVAL;
> +
> + dmabuf = file->private_data;
> +
> + /* check for overflowing the buffe
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed
I'd still rather see some form of explicit cache flusing api, but I
can do that through my exporter (and probably will to get started).
Otherwise this looks good to me except for comment inline.
On Wed, Apr 18, 2012 at 6:52 AM, Daniel Vetter wrote:
> Compared to Rob Clark's RFC I've ditched the p
I'd still rather see some form of explicit cache flusing api, but I
can do that through my exporter (and probably will to get started).
Otherwise this looks good to me except for comment inline.
On Wed, Apr 18, 2012 at 6:52 AM, Daniel Vetter
wrote:
> Compared to Rob Clark's RFC I've ditched the
> How do you ensure that no device can do DMA on the buffer while it's mapped
> into user space in a noncoherent manner?
Why do we want to enforce that ? We provide the appropriate base service
but you need to know what you are doing. In reality a lot of use cases
are going to need far more than a
On Wed, Apr 18, 2012 at 02:06:13PM +, Arnd Bergmann wrote:
> On Wednesday 18 April 2012, Daniel Vetter wrote:
> > + Because existing importing subsystems might presume coherent mappings
> > for
> > + userspace, the exporter needs to set up a coherent mapping. If that's
> > not
> > + pos
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed
On Wednesday 18 April 2012, Daniel Vetter wrote:
> + Because existing importing subsystems might presume coherent mappings for
> + userspace, the exporter needs to set up a coherent mapping. If that's not
> + possible, it needs to fake coherency by manually shooting down ptes when
> + leavi
> How do you ensure that no device can do DMA on the buffer while it's mapped
> into user space in a noncoherent manner?
Why do we want to enforce that ? We provide the appropriate base service
but you need to know what you are doing. In reality a lot of use cases
are going to need far more than a
On Wed, Apr 18, 2012 at 9:06 AM, Arnd Bergmann wrote:
> On Wednesday 18 April 2012, Daniel Vetter wrote:
>> + ? Because existing importing subsystems might presume coherent mappings for
>> + ? userspace, the exporter needs to set up a coherent mapping. If that's not
>> + ? possible, it needs to fa
On Wed, Apr 18, 2012 at 02:06:13PM +, Arnd Bergmann wrote:
> On Wednesday 18 April 2012, Daniel Vetter wrote:
> > + Because existing importing subsystems might presume coherent mappings
> > for
> > + userspace, the exporter needs to set up a coherent mapping. If that's
> > not
> > + pos
On Wed, Apr 18, 2012 at 9:06 AM, Arnd Bergmann wrote:
> On Wednesday 18 April 2012, Daniel Vetter wrote:
>> + Because existing importing subsystems might presume coherent mappings for
>> + userspace, the exporter needs to set up a coherent mapping. If that's not
>> + possible, it needs to fa
On Wednesday 18 April 2012, Daniel Vetter wrote:
> + Because existing importing subsystems might presume coherent mappings for
> + userspace, the exporter needs to set up a coherent mapping. If that's not
> + possible, it needs to fake coherency by manually shooting down ptes when
> + leavi
Compared to Rob Clark's RFC I've ditched the prepare/finish hooks
and corresponding ioctls on the dma_buf file. The major reason for
that is that many people seem to be under the impression that this is
also for synchronization with outstanding asynchronous processsing.
I'm pretty massively opposed
24 matches
Mail list logo
