Date: Tue, 24 May 2011 17:27:49 +0200 From: Rafal Jaworowski <raj@semihalf.com> To: Mark Tinguely <marktinguely@gmail.com> Cc: freebsd-arm@freebsd.org Subject: Re: L2 cache functions and physical to virtual mappings Message-ID: <36EEF760-ADB6-4873-905E-0FBC8050614F@semihalf.com> In-Reply-To: <4DDBBB13.30401@gmail.com> References: <4DDA788C.6020506@gmail.com> <4DDA8E4A.6060002@gmail.com> <4DDB7955.3060803@gmail.com> <4DDBBB13.30401@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2011-05-24, at 16:05, Mark Tinguely wrote: > 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, >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> 1. Create a compile time #define which indicates the type of = l2 cache, i.e. pseudo-code >>>>=20 >>>> #if defined(L2_CACHE_PHYS_ADDR) >>>> for (adr=3D buf & (PAGE_SIZE - 1); adr < len; adr +=3D= PAGE_SIZE) >>>> cpu_l2cache_wb_range(pmap_extract(pmap, buf), = PAGE_SIZE); >>>> #else >>>> cpu_l2cache_wb_range(buf, len); >>>> #endif >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> Any advice would be greatly appreciated. >>>>=20 >>>> Cheers, >>>> Ben. >>>>=20 >>>=20 >>> I would suggest that you send the PA to the Level 2 cache routines.. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> --Mark. >>>=20 >>>=20 >> Thanks Mark, >>=20 >> 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. >>=20 >> 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. >>=20 >> Cheers, >> Ben. >>=20 >> _______________________________________________ >> 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" >>=20 >=20 > I believe Semihalf is using this busdma_machdep.c for their ARMv6 = support. Yes, for example this [oldish] diff includes busdma for v6: = http://people.freebsd.org/~raj/patches/arm/dove_v6.diff Rafal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36EEF760-ADB6-4873-905E-0FBC8050614F>