On Tue, May 18, 2010 at 3:24 PM, Felipe Contreras <felipe.contre...@gmail.com> 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. 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). -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
