From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: documentation Date: Fri, 26 Apr 2002 19:54:53 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <20020424193226.2349.qmail@web11503.mail.yahoo.com> Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Return-path: In-Reply-To: <20020424193226.2349.qmail@web11503.mail.yahoo.com> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: Guilhem Tardy Cc: alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org At Wed, 24 Apr 2002 12:32:26 -0700 (PDT), Guilhem Tardy wrote: > > > > What is required from my part to support memory mapping from the driver > > > to the application? Would this be supported through the OSS compatibility > > > layer, too? > > > > hmm... mmap without dma? > > how do you transfer the data on buffer to hardware? > > The card doesn't support DMA, yet. Data is transferred to/from the buffer by > the driver copying 32-bit chunks. Those buffers were allocated by the MMAP, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > today through the V4Lv2 API (this is an audio+video card). how do you mean here? the allocated buffers are mmaped to user? > > the copy and silence ops are called when write() is called (more > > exactly on alsa it's ioctl) - the thread writing to the device does > > actually work like DMA. on mmap mode, there is no such one. so you > > need an extra thread (or if it's not too heavy then tasklet might be > > available) anyway. > > Having checked the brief documentation you referred to > (http://www.alsa-project.org/alsa-doc/alsa-lib/), I guess using the direct no, i posted to alsa-devel ML, a month ago or so. the document you read is for the user library, not for the driver. > audio buffer to communicate with the device means DMA+MMAP. I would like to do > the same thing, but have the driver actually copy data to/from the device. What > do you call "mmap mode" above? in your case, you need to copy the data on the buffer to the hw by yourself. then what is the merit of mmap? (well, it would be a bit more efficient than copy_from_user(), but the advantage of copy_from_user() is that you can use non-contiguous buffer while alsa's mmap supports, so far, only contiguous region.) on alsa, when the program runs in the mmap mode, no read/write is called but the data is read/written on the mmapped buffer, and the also mmaped status is updated. during the app writes data, DMA transfers the data from the mmaped buffer. that is, the thread is free from the kernel mode. > Is there any other documentation more specific to driver development? at least i am not aware of such documents. check alsa-devel ML archive. Takashi