Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752707AbdF0JGB (ORCPT ); Tue, 27 Jun 2017 05:06:01 -0400 Received: from esa5.microchip.iphmx.com ([216.71.150.166]:12351 "EHLO esa5.microchip.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751504AbdF0JGA (ORCPT ); Tue, 27 Jun 2017 05:06:00 -0400 X-IronPort-AV: E=Sophos;i="5.39,399,1493708400"; d="scan'208";a="1769894" Subject: Re: Applied "spi: atmel: fix corrupted data issue on SAM9 family SoCs" to the spi tree To: Russell King - ARM Linux , Mark Brown CC: , , , , References: <20170623171830.GV4902@n2100.armlinux.org.uk> From: Cyrille Pitchen Message-ID: Date: Tue, 27 Jun 2017 11:05:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170623171830.GV4902@n2100.armlinux.org.uk> Content-Type: text/plain; charset="utf-8" Content-Language: en-GB Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1587 Lines: 35 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