From owner-freebsd-arm@FreeBSD.ORG Wed May 23 14:30:38 2012 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5650F106566B; Wed, 23 May 2012 14:30:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 0298C8FC0A; Wed, 23 May 2012 14:30:37 +0000 (UTC) Received: from 63.imp.bsdimp.com (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id q4NEStUq054927 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Wed, 23 May 2012 08:28:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Wed, 23 May 2012 08:28:54 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1337285248.1503.308.camel@revolution.hippie.lan> <1337617221.2516.38.camel@revolution.hippie.lan> To: Svatopluk Kraus X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Wed, 23 May 2012 08:28:56 -0600 (MDT) Cc: freebsd-arm@FreeBSD.org, hackers@FreeBSD.org, Alexander Kabaev , Richard Hodges Subject: Re: ARM + CACHE_LINE_SIZE + DMA X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 14:30:38 -0000 Hi Svatopluk, That looks very interesting. You may be interested in the efforts of various people to bring up the = armv6 multi-core boards. You can checkout the source from = http://svn.freebsd.org/base/projects/armv6 to see where we are in that = effort. I believe that many of these issues have been addressed. = Perhaps you could take a look and contribute to any areas that are = incomplete rather than starting from scratch? Hope you are doing well! We need more people that truly understand the = ARM cache issues. Warner On May 23, 2012, at 7:13 AM, Svatopluk Kraus wrote: > Hi, >=20 > with respect to your replies and among other things, the following > summary could be made: >=20 > There are three kinds of DMA buffers according to their origin: >=20 > 1. driver buffers > As Alexander wrote, the buffers should be allocated by > bus_dmamap_alloc(). The function should be implemented to allocate the > buffers correctly aligned with help of bus_dma_tag_t. For these > buffers, we can avoid bouncing totally just by correct driver > implementation. For badly implemented drivers, bouncing penalty is > paid in case of unaligned buffers. For BUS_DMA_COHERENT allocations, > as Mark wrote, an allocation pool of coherent pages is good > optimalization. >=20 > 2. well-known system buffers > Mbufs and vfs buffers. The buffers should be aligned on > CACHE_LINE_SIZE (start and size). > It should be enough for vfs buffers as they are carring data only and > only whole buffers should be accessed by DMA. The mbuf is a structure > and data can be carried on three possible locations. The first one, > the external buffer, should be aligned on CACHE_LINE_SIZE. The next > two locations, which are parts of the mbuf structure, could be > unaligned in general. If we assume that no one else is writing any > part of the mbuf during DMA access, we can set BUS_DMA_UNALIGNED_SAFE > flag in mbuf load functions. I.e., we don't bounce unaligned buffers > if the flag is set in dmamap. A tunable can be implemented to suppres > the flag for debugging purposes. >=20 > 3. other buffers > As we know nothing about these buffers, we must always bounce = unaligned ones. >=20 > Just two more notes. The DMA buffer should not be access by anyone > (except DMA itself) after PRESYNC and before POSTSYNC. For DMA > descriptors (for example), using bus_dmamap_alloc() with > BUS_DMA_COHERENT flag could be inevitable. >=20 > As I'm implementing bus dma for ARM11mpcore, I'm doing it with next = assumptions: > 1. ARMv6k and higher > 2. PIPT data cache > 3. SMP ready >=20 > Svata > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 >=20