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

[Felipe Contreras <felipe.contreras@gmail.com>]

On Fri, May 21, 2010 at 12:22 AM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> On Wed, May 19, 2010 at 7:50 PM, Felipe Contreras
> <felipe.contreras@gmail.com> 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 well :)
>
> Yes, I guess you can remove those calls from the application :)

Can't. From GStreamer point of view the decoder is independent of the
renderer, so we have no way to know that. Perhaps if the memory map
operation returned some information we can avoid those calls.

>> A few updates:
>> 1) libomxil-ti doesn't use the flush/inv ioctls at all... all buffers
>> are mapped/unmapped
>
> I'm not following libomxil-ti but I guess they count on the flushing
> that happens when the buffers are mapped (as part of the
> get_user_pages call)

Yes, initially they were doing flushes, and so was gst-dsp, but I
found that little trick (not sure if they copied the trick or found it
themselves, but I did suggest it). Unfortunately gst-dsp is a bit
smarter and doesn't do constant memory mapping for the control buffers
(very small), which means we do clean/inv. For the data buffers (big
ones) we have to rely on constant memory mapping due to GStreamer
design, so we rely on get_user_pages(), although writebacks are not
needed for output buffers, and neither inv for the input ones, but I'm
not sure how much would be the gain.

Cheers.

-- 
Felipe Contreras