lkml.org 
[lkml]   [2017]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Applied "spi: atmel: fix corrupted data issue on SAM9 family SoCs" to the spi tree
From
Date
Hi Russell,

Le 23/06/2017 à 19:18, Russell King - ARM Linux a écrit :
> On Fri, Jun 23, 2017 at 05:15:58PM +0100, Mark Brown wrote:
>> +#ifdef CONFIG_SOC_SAM_V4_V5
>> + /*
>> + * Atmel SoCs based on ARM9 (SAM9x) cores should not use spi_map_buf()
>> + * since this later function tries to map buffers with dma_map_sg()
>> + * even if they have not been allocated inside DMA-safe areas.
>> + * On SoCs based on Cortex A5 (SAMA5Dx), it works anyway because for
>> + * those ARM cores, the data cache follows the PIPT model.
>> + * Also the L2 cache controller of SAMA5D2 uses the PIPT model too.
>> + * In case of PIPT caches, there cannot be cache aliases.
>> + * However on ARM9 cores, the data cache follows the VIVT model, hence
>> + * the cache aliases issue can occur when buffers are allocated from
>> + * DMA-unsafe areas, by vmalloc() for instance, where cache coherency is
>> + * not taken into account or at least not handled completely (cache
>> + * lines of aliases are not invalidated).
>
> There is a solution to this - code (iow, callers of functions that perform
> IO) are expected to use flush_kernel_vmap_range() and
> invalidate_kernel_vmap_range() as documented in Documentation/cachetlb.txt
> to ensure that their "special" views are properly handled.
>
> These are no-ops for PIPT caches, but aliasing caches have to implement
> them.
>

So if I understand, calling those two functions at the right places, we
could use DMA transfer again without the need of copying data into a
bounce buffer? It sounds great, I will study that.

Thanks!

Cyrille

\
 
 \ /
  Last update: 2017-06-27 11:07    [W:1.233 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site