From owner-freebsd-arm@FreeBSD.ORG Mon Oct 12 11:15:44 2009 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 5AB011065696 for ; Mon, 12 Oct 2009 11:15:44 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 0BF4A8FC20 for ; Mon, 12 Oct 2009 11:15:43 +0000 (UTC) Received: from localhost (unknown [213.17.239.109]) by smtp.semihalf.com (Postfix) with ESMTP id 1C23FC3BA4; Mon, 12 Oct 2009 13:10:03 +0200 (CEST) X-Virus-Scanned: by amavisd-new at semihalf.com Received: from smtp.semihalf.com ([213.17.239.109]) by localhost (smtp.semihalf.com [213.17.239.109]) (amavisd-new, port 10024) with ESMTP id 0InmkUTIoxPb; Mon, 12 Oct 2009 13:10:02 +0200 (CEST) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 48EB6C3BA9; Mon, 12 Oct 2009 13:10:02 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Rafal Jaworowski In-Reply-To: <200910081613.n98GDt7r053539@casselton.net> Date: Mon, 12 Oct 2009 13:15:41 +0200 Content-Transfer-Encoding: 7bit Message-Id: <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> References: <200910081613.n98GDt7r053539@casselton.net> To: Mark Tinguely X-Mailer: Apple Mail (2.1076) Cc: gballet@gmail.com, freebsd-arm@freebsd.org Subject: Re: Adding members to struct cpu_functions 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, 12 Oct 2009 11:15:44 -0000 On 2009-10-08, at 18:13, Mark Tinguely wrote: > -- on a tangent about the future -- > Since the ARMv7 is coming to FreeBSD, there are other ARMv4/5 vrs > ARMv6/7 > questions, the most important is should we break the new ARM chips > with > their physical tagged caches to another subbranch or define it into > the > existing code? One example of the existing pmap code that does not > mesh > well with ARMv6/7 is the exisiting flush of the level 2 cache > because the > old archs have VIVT level 2 caches). ARMv6/7 level 2 caches are PIPT, > and would not be flushed until DMA time. A simple solution would be if > an arch needs to flush the level 2 cache when it flushes the level 1 > cache, then it should do so in the level 1 cache flushing routine. I was wondering whether a separate pmap module for ARMv6-7 would not be the best approach. After all v6-7 should be considered an entirely new architecture variation, and we would avoid the very likely #ifdefs hell in case of a single pmap.c. Rafal