Date: Mon, 12 Oct 2009 14:29:19 +0200 From: Guillaume Ballet <gballet@gmail.com> To: Stanislav Sedov <stas@deglitch.com> Cc: Mark Tinguely <tinguely@casselton.net>, freebsd-arm@freebsd.org Subject: Re: Adding members to struct cpu_functions Message-ID: <fd183dc60910120529h5c741449rc8ad20b29fecd2ba@mail.gmail.com> In-Reply-To: <20091012153628.9196951f.stas@deglitch.com> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> <20091012153628.9196951f.stas@deglitch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 12, 2009 at 1:36 PM, Stanislav Sedov <stas@deglitch.com> wrote: > On Mon, 12 Oct 2009 13:15:41 +0200 > Rafal Jaworowski <raj@semihalf.com> mentioned: > >> >> On 2009-10-08, at 18:13, Mark Tinguely wrote: >> >> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- on a tangent about the futu= re -- >> > 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. >> > > Yeah, I think that would be the best solution. =A0We could conditionally > select the right pmap.c file based on the target CPU selected (just > like we do for board variations for at91/marvell). > pmap.c is a very large file that seems to change very often. I fear having several versions is going to be difficult to maintain. Granted, I haven't read the whole file line after line. Yet it seems to me its content can be abstracted to rely on arch-specific functions that would be found in cpufuncs instead of hardcoded macros. Is there something fundamentally wrong with enhancing struct cpufunc in order to let the portmeisters decide what the MMU and caching bits should look like? This is a blocking issue for me, since it looks like the omap has some problem with backward compatibility mode. Without fixing up the TLBs in my initarm function, it doesn't work. Speaking of #ifdef hell, why not breaking cpufuncs.c into several cpufuncs_<myarch>.c? That would be a good way to start that reorganization Mark has been talking about in his email. Guillaume
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fd183dc60910120529h5c741449rc8ad20b29fecd2ba>