On Mon, May 24, 2010 at 10:21 PM, Felipe Contreras
<felipe.contreras@xxxxxxxxx> wrote:
> 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:
Oh I missed that one, and thought you meant this is rather a new behavior.
One thing I can think of to make this dspbridge VM_IO assumption
stronger is this:
diff --git a/drivers/dsp/bridge/core/tiomap3430.c
b/drivers/dsp/bridge/core/tiomap3430.c
index e122f04..7030012 100644
--- a/drivers/dsp/bridge/core/tiomap3430.c
+++ b/drivers/dsp/bridge/core/tiomap3430.c
@@ -1326,7 +1326,7 @@ static dsp_status bridge_brd_mem_map(struct
bridge_dev_context *hDevContext,
goto func_cont;
}
- if (vma->vm_flags & VM_IO) {
+ if (vma->vm_flags & (VM_IO | VM_PFNMAP)) {
num_usr_pgs = ul_num_bytes / PG_SIZE4K;
mpu_addr = ul_mpu_addr;
This is exactly what __get_user_pages is checking for as well, and it
applies to our framebuffer use case.
Anyway I wonder if we have such dspbridge scenarios in which vm_flags
& VM_IO is true, but vm_flags & VM_PFNMAP is false.
Obviously this all issue has nothing to do with the current mem/cache
API patches.
Thanks,
Ohad.
>> 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
>
--
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
