On Tue, May 18, 2010 at 3:53 PM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote: > On Tue, May 18, 2010 at 3:24 PM, Felipe Contreras > <felipe.contreras@xxxxxxxxx> 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(NULL, self->mem_info.size, PROT_WRITE, MAP_SHARED, self->overlay_fd, 0); >> >>> Can you please tell me more about this scenario ? >>> (applications + drivers involved). >> >> I use gst-omapfb[1], and then it's very easy with a gst-launch command > > Ok, thanks. I think I know why it worked for you - > The framebuffer is mmap'ed as uncacheable on ARM (check out > fb_pgprotect in fbmem.c), > which makes the whole dspbridge cache manipulations on it redundant. > In our case the cache operations silently failed, but it didn't matter. Indeed, although it's not uncacheable, it's writecombine. That explains a lot. > We can probably just return whenever a dspbridge DMA operation will be > requested on VM_IO buffers (unless there are other VM_IO dspbrdige use > cases which are different). 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 :) A few updates: 1) libomxil-ti doesn't use the flush/inv ioctls at all... all buffers are mapped/unmapped 2) I said only 4 buffers are mapped at a time. Actually, it's more like 8 * 3 + 1. Most of these are 4K, although only a few bytes are used. 4) I'm already doing the changes needed in gst-dsp. 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
