L2 cache functions and physical to virtual mappings

[Mark Tinguely]

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.

You may remove the lines  "#ifdef FIX_DMAP_BUS_DMASYNC_POSTREAD" and the 
corresponding "endif". For now it is better to be one the safe side and 
perform the post read operation and not just rely on the pre-read 
operations.

Rather than implement the routine "pmap_dmap_iscurrent()", you may 
remove those tests. This is an obscure bug, and ARM does not support 
devices that performs DMA operations straight from user pages. Mainly 
cryptology hardware device drivers directly DMA to/from the user mapped 
page.

I combined the L1 and L2 operations into one cache operation; you will 
have to separate them because your L2  operation uses a PA not a VA.

--Mark.