ARM + CACHE_LINE_SIZE + DMA

[Svatopluk Kraus]

On Mon, May 21, 2012 at 6:20 PM, Ian Lepore
<freebsd at damnhippie.dyndns.org> wrote:
>> ...
>> Some more notes.
>>
>> SMP makes things worse and ARM11mpcore is about SMP too. For example,
>> another thread could be open about that how to flush caches (exclusive
>> L1 cache) in SMP case.
>>
>> I'm not sure how to correctly change memory attributes on page which
>> is in use. Making new temporary mapping with different attributes is
>> wrong and does not help at all. It's question how to do TLB and cache
>> flushes on two and more processors and be sure that everything is OK.
>> It could be slow and maybe, changing memory attributes on the fly is
>> not a good idea at all.
>>
>
> My suggestion of making a temporary writable mapping was the answer to
> how to correctly change memory attributes on a page which is in use, at
> least in the existing code, which is for a single processor.
>
> You don't need, and won't even use, the temporary mapping.  You would
> make it just because doing so invokes logic in arm/arm/pmap.c which will
> find all existing virtual mappings of the given physical pages, and
> disable caching in each of those existing mappings.  In effect, it makes
> all existing mappings of the physical pages DMA_COHERENT.  When you
> later free the temporary mapping, all other existing mappings are
> changed back to being cacheable (as long as no more than one of the
> mappings that remain is writable).
>
> I don't know that making a temporary mapping just for its side effect of
> changing other existing mappings is a good idea, it's just a quick and
> easy thing to do if you want to try changing all existing mappings to
> non-cacheable.  It could be that a better way would be to have the
> busdma_machdep code call directly to lower-level routines in pmap.c to
> change existing mappings without making a new temporary mapping in the
> kernel pmap.  The actual changes to the existing mappings are made by
> pmap_fix_cache() but that routine isn't directly callable right now.
>

Thanks for explanation. In fact, I known only a little about current
ARM pmap implementation in FreeBSD tree. I took i386 pmap
implementation and modified it according to arm11mpcore.

> Also, as far as I know all of this automatic disabling of cache for
> multiple writable mappings applies only to VIVT cache architectures.
> I'm not sure how the pmap code is going to change to support VIPT and
> PIPT caches, but it may no longer be true that making a second writable
> mapping of a page will lead to changing all existing mappings to
> non-cacheable.
>
> -- Ian


Svata