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

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

[Ameya Palande]

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.

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

[Artem Bityutskiy]

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

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

[Felipe Contreras]

On Tue, Sep 01, 2009 at 03:35:15PM +0200, Ameya Palande wrote:
> 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>

The whole proposal looks good to me :)

However, sometimes you would still want to do some extra cache
operations afer Map() there should be a way to do 'flush', 'clean' and
'inv'.

Cheers.

-- 
Felipe Contreras

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

[Kanigeri, Hari]

The initial idea behind DSPProcessor_ReserveMemory call was to provide the User's the option of doing DSP buffer management for a pool of memory by themselves. So, call Reserve one time, and do map/unmap multiple times within that region, and call Unreserve only once you are done using the Buffer. But obviously that's not how this is being used.

Thank you,
Best regards,
Hari

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Felipe Contreras
> Sent: Wednesday, September 02, 2009 10:38 AM
> To: Palande Ameya (Nokia-D/Helsinki)
> Cc: linux-omap@vger.kernel.org; Ramirez Luna, Omar; Guzman Lugo, Fernando;
> Doyu Hiroshi (Nokia-D/Helsinki); Tereshonkov Roman (Nokia-D/Helsinki)
> Subject: Re: [DSPBRIDGE RFC] Combining Reserve and Map into a new IOCTL
> 
> On Tue, Sep 01, 2009 at 03:35:15PM +0200, Ameya Palande wrote:
> > 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>
> 
> The whole proposal looks good to me :)
> 
> However, sometimes you would still want to do some extra cache
> operations afer Map() there should be a way to do 'flush', 'clean' and
> 'inv'.
> 
> Cheers.
> 
> --
> Felipe Contreras
> --
> 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

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

[Felipe Contreras]

On Wed, Sep 02, 2009 at 06:16:26PM +0200, Hari Kanigeri wrote:
> The initial idea behind DSPProcessor_ReserveMemory call was to provide
> the User's the option of doing DSP buffer management for a pool of
> memory by themselves. So, call Reserve one time, and do map/unmap
> multiple times within that region, and call Unreserve only once you
> are done using the Buffer. But obviously that's not how this is being
> used.

And they still would be able to do that because the old ioctls are not
be removed (yet).

-- 
Felipe Contreras

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

[Hiroshi DOYU]

Hi Hari,

From: "ext Kanigeri, Hari" <h-kanigeri2@ti.com>
Subject: RE: [DSPBRIDGE RFC] Combining Reserve and Map into a new IOCTL
Date: Wed, 2 Sep 2009 18:16:26 +0200

> The initial idea behind DSPProcessor_ReserveMemory call was to
> provide the User's the option of doing DSP buffer management for a
> pool of memory by themselves. So, call Reserve one time, and do
> map/unmap multiple times within that region, and call Unreserve only
> once you are done using the Buffer. But obviously that's not how
> this is being used.

Would it be possible to explan a little bit more about the advantage
of above use case, where it reserves onece, and maps/unmaps multiple
times?