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@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Felipe Contreras > Sent: Wednesday, September 02, 2009 10:38 AM > To: Palande Ameya (Nokia-D/Helsinki) > Cc: linux-omap@xxxxxxxxxxxxxxx; 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@xxxxxxxxx> > > 2. Felipe Contreras <felipe.contreras@xxxxxxxxx> > > 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
