Re: [RFC/PATCH 0/6] DSPBRIDGE: fix mem+cache API issues

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux