Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264278AbUFWPhF (ORCPT ); Wed, 23 Jun 2004 11:37:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265124AbUFWPhF (ORCPT ); Wed, 23 Jun 2004 11:37:05 -0400 Received: from cantor.suse.de ([195.135.220.2]:25295 "EHLO Cantor.suse.de") by vger.kernel.org with ESMTP id S264278AbUFWPg7 (ORCPT ); Wed, 23 Jun 2004 11:36:59 -0400 Date: Wed, 23 Jun 2004 17:36:57 +0200 Message-ID: From: Takashi Iwai To: Russell King Cc: Linus Torvalds , Jeff Garzik , Matt Porter , Jamey Hicks , Ian Molton , linux-kernel@vger.kernel.org, greg@kroah.com, tony@atomide.com, david-b@pacbell.net, joshua@joshuawise.com Subject: Re: DMA API issues In-Reply-To: <20040623133423.B27549@flint.arm.linux.org.uk> References: <20040618110721.B3851@home.com> <40D3356E.8040800@hp.com> <20040618122112.D3851@home.com> <20040618204322.C17516@flint.arm.linux.org.uk> <20040622000838.B7802@flint.arm.linux.org.uk> <40D7941F.3020909@pobox.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 15) (Security Through Obscurity) (i386-suse-linux) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2712 Lines: 64 At Wed, 23 Jun 2004 13:34:23 +0100, Russell King wrote: > > On Tue, Jun 22, 2004 at 12:40:45PM +0200, Takashi Iwai wrote: > > At Mon, 21 Jun 2004 20:26:39 -0700 (PDT), > > Linus Torvalds wrote: > > > > > > On Mon, 21 Jun 2004, Linus Torvalds wrote: > > > > > > > > The argument at some point was that some architectures may not even _have_ > > > > a "struct page" for DMA memory, since it's not "normal" memory (ie "slow > > > > memory" on m68k). However, I thought we all agreed that such a "struct > > > > page" could be furnished if that architecture wants so support mmap'ing. > > > > > > .. which is not to say that we shouldn't have a "pci_mmap_pages()" thing > > > _too_. Pretty clearly the easiest interface often is to just map the pages > > > at mmap() time, and then we should just have a helper function to do that. > > > > > > I thought we did one already, but hey, maybe not. > > > > I don't think we have such. > > > > Russell has once proposed a similar one (but not pci-specific), and I > > believe it makes sense for many drivers. We can hide the > > architecture-specific cache handling inside the helper function, too. > > Ok. So does anyone have any objections if I push the ARM DMA mmap > interface upstream, which consists of: > > /** > * dma_mmap_coherent - map a coherent DMA allocation into user space > * @dev: valid struct device pointer, or NULL for ISA and EISA-like devices > * @vma: vm_area_struct describing requested user mapping > * @cpu_addr: kernel CPU-view address returned from dma_alloc_coherent > * @handle: device-view address returned from dma_alloc_coherent > * @size: size of memory originally requested in dma_alloc_coherent > * > * Map a coherent DMA buffer previously allocated by dma_alloc_coherent > * into user space. The coherent DMA buffer must not be freed by the > * driver until the user space mapping has been released. > */ > int dma_mmap_coherent(struct device *dev, struct vm_area_struct *vma, > void *cpu_addr, dma_addr_t handle, size_t size); This looks easy to use for me. > and a similar one for the ARM-specific "write combining" case (for > framebuffers utilising the DMA API)? pgprot_noncached() is used on many other architectures in fbmem.c (well, not really, but the result is identical). Should it be provided as another one, or is it used as default in dma_mmap_coherent()? Also, it would be nice to have a version for sg-buffer, too. Takashi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/