From owner-freebsd-arm@FreeBSD.ORG Tue May 24 09:24:41 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 328A6106566B for ; Tue, 24 May 2011 09:24:41 +0000 (UTC) (envelope-from ben.r.gray@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id B216D8FC14 for ; Tue, 24 May 2011 09:24:40 +0000 (UTC) Received: by wyf23 with SMTP id 23so6568563wyf.13 for ; Tue, 24 May 2011 02:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jgh73Buq7d8IvPtTR/lo8GelyQ0xD3TIP1azd6gFnSk=; b=NFaHzxzmoPZaQrWjU4NOf74KLGANvBb/dTIXeIQZDhvVt7dDHdBcvPXIU6QQMrUUz5 H5pbF6tDaeyt8PwbuepYURwRuE8/yaEMprUYPTa8P+5rR2J/Xc4euxnn5rldzjEKhRA4 BRejOYP5mou73xqmMWAqt4Ka3xz3I5eqYHlWw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=PpWKOvaF5DyJ33BNREFuuPRCkTxBXM/Zb2mWl+CSK/xfi6u+z7pzZvOXYnWXdzySQU PxELr2KKMapDszZiM8meua5SBPkM0+nXPASuHSH0S7pJ0mOaPQV9z1wMu9/mDRXnjjBd VdWEpFYaBF+3qCqb/CcMRShR02alfNkhUUvao= Received: by 10.227.20.67 with SMTP id e3mr3176317wbb.100.1306229079613; Tue, 24 May 2011 02:24:39 -0700 (PDT) Received: from Bens-MBP.local (ip-80-238-8-128.bskyb.com [80.238.8.128]) by mx.google.com with ESMTPS id l24sm4636076wbc.47.2011.05.24.02.24.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2011 02:24:38 -0700 (PDT) Message-ID: <4DDB7955.3060803@gmail.com> Date: Tue, 24 May 2011 10:24:37 +0100 From: Ben Gray User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <4DDA788C.6020506@gmail.com> <4DDA8E4A.6060002@gmail.com> In-Reply-To: <4DDA8E4A.6060002@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: L2 cache functions and physical to virtual mappings 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: Tue, 24 May 2011 09:24:41 -0000 On 23/05/2011 17:41, Mark Tinguely wrote: > On 5/23/2011 10:09 AM, Ben Gray wrote: >> Hi, >> >> I've been working on the OMAP4430 chip (Pandaboard) which uses >> the ARM PL310 L2 cache controller. I've written basic support for >> it, but when it comes to mapping it back into cpu_l2cache_??? >> functions I hit a problem in that these functions take a virtual >> address rather than a physical address. >> >> The PL310 is a PIPT cache and naturally all cache maintenance >> operations use physical addresses. AFAICT the OMAP4430 doesn't use >> the nice cp15 instructions for flushing L2 caches (i.e. "mcr p15, >> 1, r0, c15, c9, 0"), instead operations are performed by writing to >> registers within the controller. >> >> So I guess I'm just after some advice on the best way to get >> around this, I came up with the following options but none are >> particularly neat. >> >> >> 1. Create a compile time #define which indicates the type of >> l2 cache, i.e. pseudo-code >> >> #if defined(L2_CACHE_PHYS_ADDR) >> for (adr= buf & (PAGE_SIZE - 1); adr < len; adr += >> PAGE_SIZE) >> cpu_l2cache_wb_range(pmap_extract(pmap, buf), >> PAGE_SIZE); >> #else >> cpu_l2cache_wb_range(buf, len); >> #endif >> >> >> 2. Perform the virtual to physical translation in the >> cpu_l2cache_xxx() functions using pmap_extract(). But I think this >> will require the pmap pointer to be passed to the cpu_l2cache_xxx() >> functions, therefore changing the current API. >> >> >> 3.Perform the virtual to physical translation in the >> cpu_l2cache_xxx() functions as above, but use the "CP15 c7, Virtual >> Address to Physical Address translation operations" to do the >> translation. >> >> >> Any advice would be greatly appreciated. >> >> Cheers, >> Ben. >> > > I would suggest that you send the PA to the Level 2 cache routines.. > > There are only a couple situations that the level 2 cache operations > are needed. The most common is the DMA case. The DMA routines already > does a pmap_extract to determine if the buffer needs to be bounced or > if the buffer is contiguous. The "sync list" version of > busdma_machdep.c > (http://www.tinguelys.info/mark/freebsd/busdma_machdepV7.c) can be > easily extended to also keep the extracted pa. > > The other situation needing cache operation would be the time we > change the page mapping type (normal memory -> device memory). This is > a memory mapping operation and the PA is already known. > > --Mark. > > Thanks Mark, That is beginning to look like the best idea, and as you say, with your version of the busdma code it looks pretty easy to add support for storing physical addresses. On that note, is your "sync list" busdma ready for testing? I notice it's currently missing the L2 cache functions, but it's easy to add those and if you think it's ready, I'd like to try it out. Cheers, Ben.