L2 cache functions and physical to virtual mappings

[Ben Gray]

On 24/05/2011 16:27, Rafal Jaworowski wrote:
> 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,
>>>>>
>>>>>     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.
>>>
>>> _______________________________________________
>>> freebsd-arm at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm
>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>>>
>> 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
>
Thanks guys - hopefully this weekend I'll have some time to have a play 
with it.  I'll let you know if I hit any problems.

Once again, thanks a lot.
Ben.