On Mon, May 24, 2010 at 7:19 PM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote:
> On Fri, May 21, 2010 at 12:42 PM, Felipe Contreras
> <felipe.contreras@xxxxxxxxx> wrote:
>> Although I'm still worried that VM_IO != write-combine, but I guess
>> it's a safe assumption to do for now.
>
> small update we missed:
>
> The original code is ignoring VM_IO buffers as well:
>
> static int memory_sync_vma(unsigned long start, u32 len,
> enum dsp_flushtype ftype)
> {
> ...
> if (vma->vm_flags & (VM_IO | VM_PFNMAP))
> return -EINVAL;
> ...
> }
>
> So the new code is actually behaving in exactly the same manner
> (besides the error code, which is now -EFAULT and not -EINVAL).
That's what I said in my original comment:
> Reading your patches I see the ioctl to start the dmap operations would
> simply error out, but from the looks of it, they would be failing already,
> which is weird, because we are already using framebuffer memory for video
> decoding + rendering.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
