From owner-freebsd-arm@FreeBSD.ORG Sun Oct 18 14:05:50 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 4D0411065679; Sun, 18 Oct 2009 14:05:50 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id 03C568FC2A; Sun, 18 Oct 2009 14:05:49 +0000 (UTC) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.14.3/8.14.3) with ESMTP id n9IE5hGU093572; Sun, 18 Oct 2009 09:05:43 -0500 (CDT) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1255874743; bh=NfjGg/wUXkieaPNy6sTOprE+yD+Z91E+iOmjj9YivjM=; h=Date:From:Message-Id:To:Subject:Cc:In-Reply-To; b=Ajb6Qg3wO6IkFNHus7Ers+m5x2djVFqfDIsgOqKtZ4TRZylwESY1xajb0BZXyJ3/C FJ/tqXzxjABCBH7zESQL11PyAxREpFE/wAbDQzelFyN+EBDXdVVt0n/mbvz3yL4bqn 0MxZGI0c5XSV6G3JZonz3/tRZEOYwCv2P53+CtuA= Received: (from tinguely@localhost) by casselton.net (8.14.3/8.14.2/Submit) id n9IE5gsi093570; Sun, 18 Oct 2009 09:05:42 -0500 (CDT) (envelope-from tinguely) Date: Sun, 18 Oct 2009 09:05:42 -0500 (CDT) From: Mark Tinguely Message-Id: <200910181405.n9IE5gsi093570@casselton.net> To: gballet@gmail.com, tinguely@casselton.net In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.3.2 (casselton.net [127.0.0.1]); Sun, 18 Oct 2009 09:05:43 -0500 (CDT) Cc: freebsd-arm@freebsd.org, stas@deglitch.com 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: Sun, 18 Oct 2009 14:05:50 -0000 > >> =A0either, for the same reason. The compiler can not inline a call > >> =A0through a function pointer. > >> > >> =A0In which case, why not create a bunch of headers files with the > >> =A0pattern cpufunc_myarch.h, in which all functions would be declared > >> =A0inline? Something like: > >> > >> =A0static inline l2_l_entry(vm_addr_t pa, int prot, int cache); > >> =A0static inline l2_s_entry(vm_addr_t pa, int prot, int cache); > >> =A0... > >> =A0which would then be included by pmap.c and friends. > > > > I think they need to be regular function calls because assembly routines > > call the per-cpu functions. A few simple macros would save the branch to = > NOP > > functions. > > > > I'm not sure what you mean by that: would macros be ok, in your > opinion? I am a bit puzzled because I see a contradiction with the > previous sentence that requires the functions to be callable from the > assembly code. Obviously I am misinterpreting, so would you mind > clarifying, please? > > I think it is important to notice that even though cache management > relies a lot on assembly function, I haven't found any page table > management done in assembly past locore.S. I think using macros for > page table management functions can be done. For cache management, > however, I agree that having different pmap.c files is probably the > way to go. In both cases, I am still curious to see what Nathan will > come up with. You are correct, the page tables routines are pmap.c oriented. I extended clean up thought to all the cpu specific functions. There are cpu specific functions that are NOPs that we branch to and back again. I was just throwing out a global re-organization thought. > I took a more thorough look at pmap, and there is indeed lots of > machine-specific code, especially at the beginning. And when it comes > to cpufunc, it's all about #ifdefs. Since I'm still working on the > cleanup for the beagleboard, I will declare cpufuncs in an > armv6-specific file. Let's call it cpufunc_armv6.c. I am struggling > with another MMU problem at the moment, but I'll try to come up asap > with a patch for pmap.c. It will replace hardcoded values with > machine-defined macros, for reference. I think you are running that processor in v5 mode. There is still some individuals looking at a cache problem with recent code. I still believe, we need to add the PVF_REF flag when adding the new unmanaged (PVF_UNMAN) pv_entry, so pmap_fix_cache() will clean write back the cache and remove the tlb. That and the changes to remove dangling allocations. --Mark.