| Message ID | E1dORFW-00037E-N8@debutante (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 27, 2017 at 11:05:56AM +0200, Cyrille Pitchen wrote: > 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. Yes. The down-side is that you don't have any idea from the higher levels whether the driver used DMA or PIO, and in the case of PIO, it's extra work that the CPU ends up doing. These were introduced for XFS, since it does IO and expects to be able to see the results via vmalloc space. Since it's working with the block layer, the expectation there is that PIO drivers will always ensure that data read by PIO reaches the point of coherence, so it can do a cache invalidate after the read in every case without losing data. That's not true of SPI, so you need to be extra careful about how you're using these - I think you can only use flush_kernel_vmap_range() before writes and flush_kernel_vmap_range() both before and after reads. You need it before a read to ensure that any dirty cache lines from the vmalloc mapping won't overwrite the data you're reading via the non-vmalloc mapping, and the one after caters for any speculatively prefetching that may have occurred.
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c index 1eb83c9613d5..78c885d80c96 100644 --- a/drivers/spi/spi-atmel.c +++ b/drivers/spi/spi-atmel.c @@ -269,6 +269,7 @@ struct atmel_spi_caps { bool is_spi2; bool has_wdrbt; bool has_dma_support; + bool has_pdc_support; }; /* @@ -1426,7 +1427,28 @@ static void atmel_get_caps(struct atmel_spi *as) as->caps.is_spi2 = version > 0x121; as->caps.has_wdrbt = version >= 0x210; +#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). + * This is not a theorical issue: it was reproduced when trying to mount + * a UBI file-system on a at91sam9g35ek board. + */ + as->caps.has_dma_support = false; +#else as->caps.has_dma_support = version >= 0x212; +#endif + as->caps.has_pdc_support = version < 0x212; } /*-------------------------------------------------------------------------*/ @@ -1567,7 +1589,7 @@ static int atmel_spi_probe(struct platform_device *pdev) } else if (ret == -EPROBE_DEFER) { return ret; } - } else { + } else if (as->caps.has_pdc_support) { as->use_pdc = true; }