Hi, Current DSPBridge MPU side API provides following IOCTLs which are related to reserving and mapping DSP address space:
1. DSPProcessor_ReserveMemory(): Reserve a virtually contiguous region of DSP address space. 2. DSPProcessor_Map(): Maps an MPU buffer to the DSP virtual address space. 3. DSPProcessor_UnMap(): Remove an MPU buffer mapping from the DSP virtual address space. 4. DSPProcessor_UnReserveMemory(): Frees a previously reserved region of the DSP virtual address space. Typical call sequence is: DSPProcessor_ReserveMemory() DSPProcessor_Map() DSPProcessor_UnMap() DSPProcessor_UnReserveMemory() Current approach has following problems: 1. Caller has to perform 4 system calls in order to map and unmap a buffer. 2. Kernel has no idea about the type of buffer (input/output). So depending on buffer type caller has to explicitly call DSPProcessor_FlushMemory() or DSPProcessor_InvalidateMemory(). Proposed approach: Introduce 2 new IOCTLs which combine (reserve, map) and (unmap, unreserve). Caller should also specify buffer type (input/output) attribute as a parameter to new mapping IOCTL. Benefits of new approach: 1. Saves 2 system calls per map and unmap pair. 2. By implementing lazy unreserve we can introduce cache of reserved mappings, which can skip reserve, unreserve operations. 3. Kernel can take care of flushing/invalidating cache depending on buffer type, which saves system call overhead and removed explicit cache control from user space. These IOCTLs can be added to the current set of API which doesn't break compatibility with old applications. Waiting for comments! Ideas proposed in this document are from: 1. Hiroshi Doyu <[email protected]> 2. Felipe Contreras <[email protected]> Cheers, Ameya. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
