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

[Artem Bityutskiy <dedekind1@gmail.com>]

On 09/01/2009 04:35 PM, Ameya Palande wrote:
> Current approach has following problems:
0. It is brain-dead.
> 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>

Sounds good for an non-expert.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html