From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Frysinger Subject: Re: [PATCH v3] ad7877: keep dma rx buffers in seperate cache lines Date: Tue, 11 May 2010 18:39:54 -0400 Message-ID: References: <20100511063309.GC9644@core.coreip.homeip.net> <1273608441.15067.1002.camel@calx> <20100511214836.GH1726@emlix.com> <20100511215359.GF7396@core.coreip.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail-gw0-f46.google.com ([74.125.83.46]:44332 "EHLO mail-gw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751449Ab0EKWkR convert rfc822-to-8bit (ORCPT ); Tue, 11 May 2010 18:40:17 -0400 In-Reply-To: <20100511215359.GF7396@core.coreip.homeip.net> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Dmitry Torokhov Cc: Johannes Weiner , Christoph Lameter , Pekka Enberg , Matt Mackall , Andrew Morton , Oskar Schirmer , Michael Hennerich , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, =?UTF-8?Q?Daniel_Gl=C3=B6ckner?= , Oliver Schneidewind , Nick Piggin , David Rientjes , David Brownell , Grant Likely On Tue, May 11, 2010 at 17:53, Dmitry Torokhov wrote: > On Tue, May 11, 2010 at 11:48:36PM +0200, Johannes Weiner wrote: >> On Tue, May 11, 2010 at 04:54:41PM -0400, Mike Frysinger wrote: >> > does the phrase "DMA safe buffer" imply cache alignment ? >> >> I guess that depends on the architectural requirements. =C2=A0On x86= , >> apparently, not so much. =C2=A0On ARM, probably yes, as it's the >> requirement to properly maintain coherency. > > It looks liek ARM (and a few others) do this: > > [dtor@hammer work]$ grep -r ARCH_KMALLOC_MINALIGN arch/ > arch/sh/include/asm/page.h:#define ARCH_KMALLOC_MINALIGN =C2=A0 =C2=A0= =C2=A0 =C2=A0L1_CACHE_BYTES > arch/frv/include/asm/mem-layout.h:#define =C2=A0 =C2=A0 =C2=A0 ARCH_K= MALLOC_MINALIGN =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8 > arch/powerpc/include/asm/page_32.h:#define ARCH_KMALLOC_MINALIGN =C2=A0= =C2=A0 =C2=A0 =C2=A0L1_CACHE_BYTES > arch/arm/include/asm/cache.h:#define ARCH_KMALLOC_MINALIGN =C2=A0 =C2= =A0 =C2=A0L1_CACHE_BYTES > arch/microblaze/include/asm/page.h:#define ARCH_KMALLOC_MINALIGN =C2=A0= =C2=A0 =C2=A0 =C2=A0L1_CACHE_BYTES > arch/mips/include/asm/mach-tx49xx/kmalloc.h: * All happy, no need to = define ARCH_KMALLOC_MINALIGN > arch/mips/include/asm/mach-ip27/kmalloc.h: * All happy, no need to de= fine ARCH_KMALLOC_MINALIGN > arch/mips/include/asm/mach-ip32/kmalloc.h:#define ARCH_KMALLOC_MINALI= GN 32 > arch/mips/include/asm/mach-ip32/kmalloc.h:#define ARCH_KMALLOC_MINALI= GN 128 > arch/mips/include/asm/mach-generic/kmalloc.h:#define ARCH_KMALLOC_MIN= ALIGN =C2=A0 =C2=A0 =C2=A0128 > arch/avr32/include/asm/cache.h:#define ARCH_KMALLOC_MINALIGN =C2=A0 =C2= =A0L1_CACHE_BYTES if ARCH_KMALLOC_MINALIGN is not defined, the current allocators default= to: slub - alignof(unsigned long long) slab - alignof(unsigned long long) slob - alignof(unsigned long) which for many arches can mean an alignment of merely 4 or 8 lets look at the cacheline sizes for arches that dont set ARCH_KMALLOC_MINALIGN to L1_CACHE_BYTES: - alplha - 32 or 64 - frv - 32 or 64 - blackfin - 32 - parisc - 32 or 64 - mn10300 - 16 - s390 - 256 - score - 16 - sparc - 32 - xtensa - 16 or 32 assuming alpha and s390 handle cache coherency in hardware, it looks to me like the proposed assumption (kmalloc returns cachealigned pointers when cache management is in software) does not hold true. so should these other arches also be setting ARCH_KMALLOC_MINALIGN to L1_CACHE_BYTES ? -mike -- To unsubscribe from this list: send the line "unsubscribe linux-input" = in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html