[DSPBRIDGE RFC] Combining Reserve and Map into a new IOCTL

[Ameya Palande <ameya.palande@nokia.com>]

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 <hiroshi.doyu@nokia.com>
2. Felipe Contreras <felipe.contreras@nokia.com>

Cheers,
Ameya.