From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mundt Subject: Re: [PATCH v3] ad7877: keep dma rx buffers in seperate cache lines Date: Thu, 13 May 2010 15:21:43 +0900 Message-ID: <20100513062143.GB9920@linux-sh.org> References: <20100511063309.GC9644@core.coreip.homeip.net> <1273608441.15067.1002.camel@calx> <4BE9C033.2020106@cs.helsinki.fi> <4BE9C258.10706@cs.helsinki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from 124x34x33x190.ap124.ftth.ucom.ne.jp ([124.34.33.190]:59769 "EHLO master.linux-sh.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751028Ab0EMGWb (ORCPT ); Thu, 13 May 2010 02:22:31 -0400 Content-Disposition: inline In-Reply-To: <4BE9C258.10706@cs.helsinki.fi> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Pekka Enberg Cc: Mike Frysinger , Christoph Lameter , Matt Mackall , Dmitry Torokhov , Andrew Morton , Oskar Schirmer , Michael Hennerich , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Daniel Gl??ckner , Oliver Schneidewind , Johannes Weiner , Nick Piggin , David Rientjes , David Brownell , Grant Likely On Tue, May 11, 2010 at 11:47:20PM +0300, Pekka Enberg wrote: > Mike Frysinger wrote: > >On Tue, May 11, 2010 at 16:38, Pekka Enberg wrote: > >>Mike Frysinger wrote: > >>>that is a question for David/Grant. i'm not the SPI core maintainer, > >>>i'm merely watching over some SPI drivers. however, this answer also > >>>doesnt sound like it's thinking big enough because what you're > >>>proposing isnt specific to the SPI bus -- any time a DMA safe buffer > >>>is needed dynamically, this function could be used. > >>Well, we have dma_alloc_coherent(), shouldn't you be using that instead? > > > >my understanding is that dma_alloc_coherent() gives you a buffer that > >is always coherent. the SPI layers take care of flushing and such on > >the fly which means allocating coherent memory is overkill and bad for > >performance. > > OK, I'm out of my expert area here but if dma_alloc_coherent() doesn't > work for you, you should probably extend the DMA API, not kmalloc(). > Note that the DMA API already has dma_alloc_noncoherent() for these sorts of cases. If the driver is taking care of cache maintenance then dma_alloc_noncoherent() is certainly a reasonable way to go. Most architectures today simply wrap dma_alloc_noncoherent() to dma_alloc_coherent(), but if there were more users of the API then that would quickly change.