Date: Mon, 12 Oct 2009 15:36:28 +0400 From: Stanislav Sedov <stas@deglitch.com> To: Rafal Jaworowski <raj@semihalf.com> Cc: gballet@gmail.com, Mark Tinguely <tinguely@casselton.net>, freebsd-arm@freebsd.org Subject: Re: Adding members to struct cpu_functions Message-ID: <20091012153628.9196951f.stas@deglitch.com> In-Reply-To: <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com> References: <200910081613.n98GDt7r053539@casselton.net> <4A95E6D9-7BA5-4D8A-99A1-6BC6A7EABC18@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Signature=_Mon__12_Oct_2009_15_36_28_+0400_76ge5vAWbE9fDut7 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 12 Oct 2009 13:15:41 +0200 Rafal Jaworowski <raj@semihalf.com> mentioned: >=20 > On 2009-10-08, at 18:13, Mark Tinguely wrote: >=20 > > -- on a tangent about the future -- > > Since the ARMv7 is coming to FreeBSD, there are other ARMv4/5 vrs =20 > > ARMv6/7 > > questions, the most important is should we break the new ARM chips =20 > > with > > their physical tagged caches to another subbranch or define it into =20 > > the > > existing code? One example of the existing pmap code that does not =20 > > mesh > > well with ARMv6/7 is the exisiting flush of the level 2 cache =20 > > 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. >=20 > I was wondering whether a separate pmap module for ARMv6-7 would not =20 > be the best approach. After all v6-7 should be considered an entirely =20 > new architecture variation, and we would avoid the very likely #ifdefs =20 > hell in case of a single pmap.c. >=20 Yeah, I think that would be the best solution. We could conditionally select the right pmap.c file based on the target CPU selected (just like we do for board variations for at91/marvell). --=20 Stanislav Sedov ST4096-RIPE --Signature=_Mon__12_Oct_2009_15_36_28_+0400_76ge5vAWbE9fDut7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJK0xTAAAoJEKN82nOYvCd0z3AP/0MBYNgRt4Gz4vCo2j+JZHIY L60R2hai88fAbG/5mBfQWP/rGUCUz0FFU/is8g9Vgajx2uJzy7mbhBgs16IEvlO9 LRETjDoJy+NHYq1u5te9tvgr2v13kiZkmLIyuKdSk4o8Umcrc/Q9H46jliItNbY/ jNAbfK1gCOM4hEGCpclACzjBXj/P7RQJ/DCiawNYl49T2kYx/mwUsxJudQheJZ/w h5DCh3bMahjA05tzf+GhUiFPc+M6znWIubN/RY3mGgZFpv5JrE43TEEnAkBIVCB/ Bc62B4BSY0GIJwvqF/wmpoLrqFc2DCIL7NoKo9z5GfYIfletB6Ss3UpRldZxIBlZ uQ8cMqLBJ003ZTjqLDseaydDSmb/g64A4z98643AGBcK/UfxvxDu++psHD5+i7Af 0dxzCZ4UZ/hAHEmc3t4OOhwLc8Tjx3YjPXM+asWayJMdU0Z01CL6eebiGUqXeTGr b4/Sl9qefGSJAbYWaK91pyia8HjwNMB0GUA8sekAXrJ8zGUP9lpPZUiMS7aFjc97 NeWNEHJMNyZs2VB/5UoOt7VfjZumFAtNQeaefiHP/DkyDlwxQlRdmoYnIIVe0Q8n hmoE1o2FPt7Nep0F9gTBBwCprjbINlA5gBsCgAS3U4Q6Hm4eaGuT6mh220+VaG/D NRuAtK7kbTqZvXLFNR8X =atIn -----END PGP SIGNATURE----- --Signature=_Mon__12_Oct_2009_15_36_28_+0400_76ge5vAWbE9fDut7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091012153628.9196951f.stas>