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
Hi Hari,
From: ext Kanigeri, Hari h-kanige...@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
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.
-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.
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
