On Fri, May 15, 2009 at 5:54 PM, Kanigeri, Hari <h-kanige...@ti.com> wrote: >> >>While we are at it, this new mapping could do >> >> PROC_ReserveMemory at the same time so that the user-space application >> >> doesn't get a chance to modify the pa. >> >> >> > -- What does PROC_ReserveMemory has to do with pa ? >> >> Sorry, I don't know what kind of address PROC_ReserveMemory returns >> (va?), but I don't see any point in having PROC_ReserveMemory and >> PROC_Map as separate ioctls >> > > -- The purpose of PROC_ReserveMemory is for the Bridge clients to grab DSP VA > memory one time and use the PROC_MapMemory to map the address within this > reserved memory. So, in a way with proper usage of PROC_ReserveMemory, it > should be called only one time and subsequent Map/Unmaps from a client should > happen within this memory region. By following this, you can eliminate the > overhead of calling redundant reserve/unreserve calls that go into the driver.
Do you know of any client that doing ReseveMemory and Map independently? How much overhead is there in ReserveMemory? What happens if the Map size is different than the ReserveMemory? What happens if the size is bigger? In fact I don't even understand what is DSP VA memory. Is that virtual memory? What meaning is there on virtual memory that has no physical memory? -- Felipe Contreras -- 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
