From owner-freebsd-arm@FreeBSD.ORG Tue May 24 14:05:12 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 327BB1065670 for ; Tue, 24 May 2011 14:05:12 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id EA5928FC0C for ; Tue, 24 May 2011 14:05:11 +0000 (UTC) Received: by iyj12 with SMTP id 12so8018867iyj.13 for ; Tue, 24 May 2011 07:05:11 -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=+oDEDTZ9IixqQJDqmsqTyKlI0/MfQqof8VBqT6Lre0I=; b=KPwE9dB28iuqLraw3FxcNgbmuWLxJm4z5czPHlq42Ku662gR2HWa9bR0Ow93Cbqnac vUsl71ZbL0sdQdzlsRnPBDR/q5WcGDWn1UlzRhiFW6XpW7MzBe17HwroMEq/aSJszQFy RrR+wd3Q04ti64Ip/uPCWOvlC4HOrEsStnG1E= 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=PXBvs1P1oq+yAJbFTnAkjtjOKRPImWbzMeN+PG86n1FwUBoBVj23hw8SmAxT5TxWV7 eFetFex3zXHqHkVP2QUu+KRgnmeaXgWt6Ag0uAxP05iV/3RCg3qWK3pN+0N+zuo5zrMv lkRwxbJorb2n/eMmZdHUfHhXNl7q6MXOq0Xtc= Received: by 10.42.144.195 with SMTP id c3mr1288477icv.9.1306245911306; Tue, 24 May 2011 07:05:11 -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 ww2sm3092101icb.3.2011.05.24.07.05.09 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 May 2011 07:05:10 -0700 (PDT) Message-ID: <4DDBBB13.30401@gmail.com> Date: Tue, 24 May 2011 09:05:07 -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> <4DDA8E4A.6060002@gmail.com> <4DDB7955.3060803@gmail.com> In-Reply-To: <4DDB7955.3060803@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: Tue, 24 May 2011 14:05:12 -0000 On 5/24/2011 4:24 AM, Ben Gray wrote: > 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. > > _______________________________________________ > 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" > I believe Semihalf is using this busdma_machdep.c for their ARMv6 support. You may remove the lines "#ifdef FIX_DMAP_BUS_DMASYNC_POSTREAD" and the corresponding "endif". For now it is better to be one the safe side and perform the post read operation and not just rely on the pre-read operations. Rather than implement the routine "pmap_dmap_iscurrent()", you may remove those tests. This is an obscure bug, and ARM does not support devices that performs DMA operations straight from user pages. Mainly cryptology hardware device drivers directly DMA to/from the user mapped page. I combined the L1 and L2 operations into one cache operation; you will have to separate them because your L2 operation uses a PA not a VA. --Mark.