Hi Felipe, On Fri, May 14, 2010 at 10:27 PM, Felipe Contreras <felipe.contreras@xxxxxxxxx> 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 perfectly ok and there's no problem with that in the code. > however you are not taking > into account bridge_brd_mem_map() where vm_flags have VM_IO... in that > case get_user_pages() is skipped completely. This code-path is > important in order to mmap framebuffer memory, which is contiguous. > So, in this case there are no pages too keep track at all. I gave some thought to this, and I concluded that nothing needs to be changed in the patches for this scenario. You see, in this case, as you said, no pages were pinned in memory using get_user_pages. This is perfectly fine since the MM application writes to a physical writecombine framebuffer memory which is not cached or swapped out. If the MM application will try to begin a DMA operation on this memory it will immediately fail because no related mapping will be found. This should actually be the expected behavior in such case: there really isn't a mapping to this buffer since there's no point to have it in VM_IO memory, and applications should not even try to flush/inv such memory: it's just redundant. IOW, the support for this scenario is actually to have no support : just return an error, which is what already happens. Thanks, Ohad. -- 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
