Date: Tue, 24 May 2011 10:24:37 +0100 From: Ben Gray <ben.r.gray@gmail.com> To: freebsd-arm@freebsd.org Subject: Re: L2 cache functions and physical to virtual mappings Message-ID: <4DDB7955.3060803@gmail.com> In-Reply-To: <4DDA8E4A.6060002@gmail.com> References: <4DDA788C.6020506@gmail.com> <4DDA8E4A.6060002@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23/05/2011 17:41, Mark Tinguely wrote: > On 5/23/2011 10:09 AM, Ben Gray wrote: >> Hi, >> >> 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. >> >> 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. >> >> 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. >> >> >> 1. Create a compile time #define which indicates the type of >> l2 cache, i.e. pseudo-code >> >> #if defined(L2_CACHE_PHYS_ADDR) >> for (adr= buf & (PAGE_SIZE - 1); adr < len; adr += >> PAGE_SIZE) >> cpu_l2cache_wb_range(pmap_extract(pmap, buf), >> PAGE_SIZE); >> #else >> cpu_l2cache_wb_range(buf, len); >> #endif >> >> >> 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. >> >> >> 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. >> >> >> Any advice would be greatly appreciated. >> >> Cheers, >> Ben. >> > > I would suggest that you send the PA to the Level 2 cache routines.. > > 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. > > 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. > > --Mark. > > Thanks Mark, 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. 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. Cheers, Ben.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DDB7955.3060803>