From owner-freebsd-arm@FreeBSD.ORG Mon May 23 16:41:50 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 EE0CA106566B for ; Mon, 23 May 2011 16:41:49 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id A595D8FC15 for ; Mon, 23 May 2011 16:41:49 +0000 (UTC) Received: by ywf7 with SMTP id 7so2782681ywf.13 for ; Mon, 23 May 2011 09:41:49 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3XUuKenHSBkLcU6pfdxebq7GQFQBQopTe63ozWYmJZw=; b=ZrtKGewVbtgPHD7aqxDuAp7fBJCa1KKYaDfyjej4AkdkEiqwNAQQJPZijGQk7c3NNw rg8cMgqtyfKEBX9Qc38y34z+P4+6uj6hLuphcUbm8cB37NL5zaX8mjnkXmqtOJ6wWus+ hmuGMTbwXWCclxV6KdQvq85W4fEGU5v2uvDqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=a8OZM1Ok2H6A+aiqwGfDeokUXTKyc44w9CyTPfLvTbl2ndyC7lce3zFmzgXsgHzGku Oke2+w48GnrPNIsvAQoYpo67pNXgnKS1zdVyD0PcN+FpHRJwvzCD2lqBO+guLNDo8F0m sbCS2dHjyzYGtQHIdNM8CXZw7GkQ2g3QMpIuw= Received: by 10.150.75.10 with SMTP id x10mr3171935yba.110.1306168908898; Mon, 23 May 2011 09:41:48 -0700 (PDT) Received: from [192.168.1.111] (c-24-245-26-12.hsd1.mn.comcast.net [24.245.26.12]) by mx.google.com with ESMTPS id r9sm2806310yba.16.2011.05.23.09.41.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 May 2011 09:41:48 -0700 (PDT) Message-ID: <4DDA8E4A.6060002@gmail.com> Date: Mon, 23 May 2011 11:41:46 -0500 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Ben Gray References: <4DDA788C.6020506@gmail.com> In-Reply-To: <4DDA788C.6020506@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org 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: Mon, 23 May 2011 16:41:50 -0000 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.