On Fri, May 21, 2010 at 12:22 AM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: > On Wed, May 19, 2010 at 7:50 PM, Felipe Contreras > <felipe.contreras@xxxxxxxxx> 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 -- 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
