On Mon, May 24, 2010 at 10:21 PM, Felipe Contreras
wrote:
> On Mon, May 24, 2010 at 7:19 PM, Ohad Ben-Cohen wrote:
>> On Fri, May 21, 2010 at 12:42 PM, Felipe Contreras
>> wrote:
>>> Although I'm still worried that VM_IO != write-combine, but I guess
>>> it's a safe assumption to do for now.
>>
On Mon, May 24, 2010 at 7:19 PM, Ohad Ben-Cohen wrote:
> On Fri, May 21, 2010 at 12:42 PM, Felipe Contreras
> 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
On Fri, May 21, 2010 at 12:42 PM, Felipe Contreras
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, u3
On Fri, May 21, 2010 at 11:22 AM, Ohad Ben-Cohen wrote:
> On Fri, May 21, 2010 at 9:14 AM, Felipe Contreras
> wrote:
>> On Fri, May 21, 2010 at 12:22 AM, Ohad Ben-Cohen wrote:
>>> On Wed, May 19, 2010 at 7:50 PM, Felipe Contreras
>>> wrote:
I don't know what VM_IO means, but essentially we
On Fri, May 21, 2010 at 9:14 AM, Felipe Contreras
wrote:
> On Fri, May 21, 2010 at 12:22 AM, Ohad Ben-Cohen wrote:
>> On Wed, May 19, 2010 at 7:50 PM, Felipe Contreras
>> wrote:
>>> I don't know what VM_IO means, but essentially we don't want to go
>>> find each and page when we know the memory
On Fri, May 21, 2010 at 12:22 AM, Ohad Ben-Cohen wrote:
> On Wed, May 19, 2010 at 7:50 PM, Felipe Contreras
> wrote:
>> I don't know what VM_IO means, but essentially we don't want to go
>> find each and page when we know the memory is contiguous. Although the
>> fact that the memory is writecomb
On Fri, May 21, 2010 at 12:22 AM, Ohad Ben-Cohen wrote:
>> 4) I'm already doing the changes needed in gst-dsp.
>
> Great! I briefly looked at the patches and they seem very nice.
Btw I'll soon post version 2 of the DMA patches.
Thanks,
Ohad.
>
> Thanks a lot,
> Ohad.
>
>
>>
>> Cheers.
>>
>> --
Hi Felipe,
On Wed, May 19, 2010 at 7:50 PM, Felipe Contreras
wrote:
> I don't know what VM_IO means, but essentially we don't want to go
> find each and page when we know the memory is contiguous. Although the
> fact that the memory is writecombine would help us avoid unnecessary
> flushes as wel
Hi Felipe,
On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
wrote:
> Also, I noticed an important problem. Your code assumes that we would
> always have a bunch of scattered pages,
Just a small note: the pages can be contiguous even in normal memory
allocation (not with framebuffer). That's pe
On Tue, May 18, 2010 at 3:53 PM, Ohad Ben-Cohen wrote:
> On Tue, May 18, 2010 at 3:24 PM, Felipe Contreras
> wrote:
Cool. I actually tried your patches to render to the framebuffer, and
everything seemed to work fine. I didn't check for error codes or
anything, so I'm not sure what
On Tue, May 18, 2010 at 3:24 PM, Felipe Contreras
wrote:
>>> Cool. I actually tried your patches to render to the framebuffer, and
>>> everything seemed to work fine. I didn't check for error codes or
>>> anything, so I'm not sure what's going on.
>>
>> How is the framebuffer mmap'ed ?
>
> mmap(NU
On Tue, May 18, 2010 at 2:57 PM, Ohad Ben-Cohen wrote:
> On Tue, May 18, 2010 at 2:43 PM, Felipe Contreras
> wrote:
>>> I'll just add support for the VM_IO path you mentioned.
>>
>> Cool. I actually tried your patches to render to the framebuffer, and
>> everything seemed to work fine. I didn't c
On Tue, May 18, 2010 at 2:43 PM, Felipe Contreras
wrote:
> On Tue, May 18, 2010 at 2:14 PM, Ohad Ben-Cohen wrote:
Unfortunately I don't have a setup right now to test this, but the code
seems to be ok for our needs, don't you think ?
>>>
>>> But yeah, actually that fits our needs; calli
On Tue, May 18, 2010 at 2:14 PM, Ohad Ben-Cohen wrote:
>>> Unfortunately I don't have a setup right now to test this, but the code
>>> seems to be ok for our needs, don't you think ?
>>
>> But yeah, actually that fits our needs; calling the dma_map only,
>> while still wrong, will give us the same
On Tue, May 18, 2010 at 2:02 PM, Felipe Contreras
wrote:
> On Tue, May 18, 2010 at 11:05 AM, Ohad Ben-Cohen wrote:
>> On Mon, May 17, 2010 at 2:51 AM, Felipe Contreras
>> wrote:
>>> So currently (v2.6.33), before sending a read-olny buffer (TO_DEVICE),
>>> we do dmac_flush_range (should be clean
On Tue, May 18, 2010 at 11:05 AM, Ohad Ben-Cohen wrote:
> On Mon, May 17, 2010 at 2:51 AM, Felipe Contreras
> wrote:
>> So currently (v2.6.33), before sending a read-olny buffer (TO_DEVICE),
>> we do dmac_flush_range (should be clean, but whatever) and before
>> sending a write-only (FROM_DEVICE)
On Mon, May 17, 2010 at 2:51 AM, Felipe Contreras
wrote:
> So currently (v2.6.33), before sending a read-olny buffer (TO_DEVICE),
> we do dmac_flush_range (should be clean, but whatever) and before
> sending a write-only (FROM_DEVICE), we do dmac_inv_range.
>
> On v2.6.33 the same could be achieve
Hi Felipe,
On Mon, May 17, 2010 at 3:05 AM, Felipe Contreras
wrote:
> On Mon, May 17, 2010 at 2:25 AM, Ohad Ben-Cohen wrote:
>> Out of curiosity, what board/environment do you use to play with
>> the code ? I'd like to run the same use cases you do, so I can
>> reproduce any issue you may bump i
On Mon, May 17, 2010 at 2:25 AM, Ohad Ben-Cohen wrote:
> Out of curiosity, what board/environment do you use to play with
> the code ? I'd like to run the same use cases you do, so I can
> reproduce any issue you may bump into.
I use a beagleboard, use the DSP firmware in L23.i3.3[1], do simple
t
Hello,
On Mon, May 17, 2010 at 1:57 AM, Ohad Ben-Cohen wrote:
> On Sun, May 16, 2010 at 8:35 PM, Felipe Contreras
> wrote:
>> Now I understand better; arch/arm/mm/dma-mapping.c will not be used
>> unless CONFIG_DMABOUNCE=y, which is not the case for OMAP3.
>>
>> So, as you can see in arch/arm/in
On Mon, May 17, 2010 at 2:15 AM, Felipe Contreras
wrote:
> Hi Ohad,
>
> On Mon, May 17, 2010 at 1:35 AM, Ohad Ben-Cohen wrote:
>> On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
>> wrote:
>>> I looked into the dma code (I guess it's in arch/arm/mm/dma-mapping.c)
>>> and I don't understand wha
On Mon, May 17, 2010 at 2:15 AM, Felipe Contreras
wrote:
> Hi Ohad,
>
> On Mon, May 17, 2010 at 1:35 AM, Ohad Ben-Cohen wrote:
>> On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
>> wrote:
>>> I looked into the dma code (I guess it's in arch/arm/mm/dma-mapping.c)
>>> and I don't understand wha
Hi Ohad,
On Mon, May 17, 2010 at 1:35 AM, Ohad Ben-Cohen wrote:
> On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
> wrote:
>> I looked into the dma code (I guess it's in arch/arm/mm/dma-mapping.c)
>> and I don't understand what dma_unmap_sg is supposed to do.
>
> Portable code must use the dm
Hi Felipe,
On Sun, May 16, 2010 at 8:35 PM, Felipe Contreras
wrote:
> On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
> wrote:
>> I spent some time looking deeper into this patch series, and I have some
>> doubts.
>>
>> On Sun, May 2, 2010 at 8:47 PM, Ohad Ben-Cohen wrote:
>>> Basically you
Hi Felipe,
On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
wrote:
> Hi,
>
> I spent some time looking deeper into this patch series, and I have some
> doubts.
>
> On Sun, May 2, 2010 at 8:47 PM, Ohad Ben-Cohen wrote:
>> On Sun, May 2, 2010 at 4:17 PM, Felipe Contreras
>> wrote:
>>> On Sat,
On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras
wrote:
> I spent some time looking deeper into this patch series, and I have some
> doubts.
>
> On Sun, May 2, 2010 at 8:47 PM, Ohad Ben-Cohen wrote:
>> Basically you're right, but the patches currently silently allow
>> today's user space
>> to
On Sat, May 15, 2010 at 12:08 PM, Felipe Contreras
wrote:
> On Sat, May 15, 2010 at 11:26 AM, Felipe Contreras
> wrote:
>> On Fri, May 14, 2010 at 10:49 PM, Omar Ramirez Luna
>> wrote:
>>> On 5/14/2010 2:27 PM, Felipe Contreras wrote:
>>> [...]
So, I tried your patches, and a simple t
On Sat, May 15, 2010 at 11:26 AM, Felipe Contreras
wrote:
> On Fri, May 14, 2010 at 10:49 PM, Omar Ramirez Luna
> wrote:
>> On 5/14/2010 2:27 PM, Felipe Contreras wrote:
>> [...]
>>>
>>> So, I tried your patches, and a simple test app worked fine without
>>> modification, but a real video decodi
On Fri, May 14, 2010 at 10:49 PM, Omar Ramirez Luna wrote:
> On 5/14/2010 2:27 PM, Felipe Contreras wrote:
> [...]
>>
>> So, I tried your patches, and a simple test app worked fine without
>> modification, but a real video decoding hanged the device
>> completely... some spinlock was stuck. I don'
On 5/14/2010 2:27 PM, Felipe Contreras wrote:
[...]
So, I tried your patches, and a simple test app worked fine without
modification, but a real video decoding hanged the device
completely... some spinlock was stuck. I don't know if it's because of
your patches, or because of the state of the br
Hi,
I spent some time looking deeper into this patch series, and I have some doubts.
On Sun, May 2, 2010 at 8:47 PM, Ohad Ben-Cohen wrote:
> On Sun, May 2, 2010 at 4:17 PM, Felipe Contreras
> wrote:
>> On Sat, May 1, 2010 at 11:44 PM, Ohad Ben-Cohen wrote:
>>> The patchset renames the flush
On Sun, May 2, 2010 at 4:17 PM, Felipe Contreras
wrote:
> On Sat, May 1, 2010 at 11:44 PM, Ohad Ben-Cohen wrote:
>> This patchset introduces an approach to eliminate the direct calls
>> to follow_page and to the low level cache APIs.
>>
>> The patchset works by caching the page information while
On Sat, May 1, 2010 at 11:44 PM, Ohad Ben-Cohen wrote:
> This patchset introduces an approach to eliminate the direct calls
> to follow_page and to the low level cache APIs.
>
> The patchset works by caching the page information while memory
> is mapped, and then using that information later when
This patchset introduces an approach to eliminate the direct calls
to follow_page and to the low level cache APIs.
The patchset works by caching the page information while memory
is mapped, and then using that information later when needed
instead of calling follow_page. The low level cache API i
34 matches
Mail list logo
