From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paul Mundt Date: Thu, 17 May 2012 08:03:09 +0000 Subject: Re: ALSA dma_area not utilizing D-cahce Message-Id: <20120517080308.GB14027@linux-sh.org> List-Id: References: <20120516095123.73abdf103d1ca64996d9c23c@kanno.co.jp> In-Reply-To: <20120516095123.73abdf103d1ca64996d9c23c@kanno.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-sh@vger.kernel.org On Thu, May 17, 2012 at 04:51:06PM +0900, MASAO TAKAHASHI wrote: > On Thu, 17 May 2012 16:22:41 +0900 > Paul Mundt wrote: > > On Thu, May 17, 2012 at 02:16:21PM +0900, MASAO TAKAHASHI wrote: > > > Is the runtime->dma_area address is a paging object ? > > > > > This is going to depend entirely on your driver. If your driver is > > deciding to use a vmalloc backed area, then yes, it will be cached. If > > you are obtaining your memory from vmalloc then that's going to reside in > > P3SEG on legacy paltforms anyways, so P2SEGADDR isn't going to help you > > regardless. > > > > If you need a consistent DMA mapping in your driver make sure you are > > using SNDRV_DMA_TYPE_DEV. I notice the fsi driver has this comment: > > > > /* > > * dont use SNDRV_DMA_TYPE_DEV, since it will oops the SH kernel > > * in MMAP mode (i.e. aplay -M) > > */ > > > > which suggests that someone was lazy and trying to avoid fixing up the > > aforementioned snd_pcm_default_page_ops/snd_pcm_lib_default_mmap cases. > > > > I've added Morimoto-san to the Cc, as I'm definitely the wrong person to ask > > about anything involving alsa drivers. > My driver assigns DMA area as follows. > > snd_pcm_lib_preallocate_pages_for_all( > pcm, > SNDRV_DMA_TYPE_CONTINUOUS, > snd_dma_continuous_data(GFP_KERNEL), > 64*1024, 64*1024); > So , it does not have SNDRV_DMA_TYPE_DEV type as you said. > I have an another idea to use ioremap_nocache as follows. > In xxx_prepare() function in the driver > to add the next codes. > runtime->dma_area = ioremap_nocache > (virt_to_phys(runtime->dma_area), 64*1024); > Is it good? > No, you are basically just duplicating the behaviour of SNDRV_DMA_TYPE_DEV. You really want dma_alloc_coherent(), which is what SNDRV_DMA_TYPE_DEV gets you. This will map to dma_generic_alloc_coherent() in arch/sh/mm/consistent.c, which does what you are trying to do, only correctly. Your implementation fails to take in to account extant cachelines for pages obtained from the page allocator prior to DMA, which is about as fun to debug as it sounds. Any time you decide to start fighting the API and roll your own thing it is going to end badly. The FSI driver gets away with it because it does streaming DMA and uses the dma-mapping API correctly. Rather than trying to hack around SNDRV_DMA_TYPE_DEV and inventing your own interface, your cycles would be better spent trying to figure out where SNDRV_DMA_TYPE_DEV goes wrong in the mmap case and sending patches. You already have several places to look at to get you started.