[U-Boot] [RFC PATCH 0/2] Add Kconfig to disable cache ops

[U-Boot] [RFC PATCH 0/2] Add Kconfig to disable cache ops

[Vignesh Raghavendra]

This series adds a Kconfig to disable cache maintenance operations on
a coherent architectures. And disable cache flush/invalidate ops for
SPL/U-Boot code running on A53 core of AM654 SoC(which is IO coherent)

Vignesh Raghavendra (2):
  arch: armv8: Provide a way to disable cache maintenance ops
  board: ti: am654: select SYS_ARCH_IS_COHERENT for arm64

 arch/Kconfig                  |  7 +++++++
 arch/arm/cpu/armv8/cache_v8.c | 18 ++++++++++++++++++
 board/ti/am65x/Kconfig        |  1 +
 3 files changed, 26 insertions(+)

-- 
2.21.0

[U-Boot] [RFC PATCH 1/2] arch: armv8: Provide a way to disable cache maintenance ops

[Vignesh Raghavendra]

On AM654 SoC(arm64) which is IO coherent and has L3 Cache, cache
maintenance operations being done to support non-coherent platforms
causes issues.

For example, here is how U-Boot prepares/handles a buffer to receive
data from a device (DMA Write). This may vary slightly depending on the
driver framework:

	Start DMA to write to destination buffer
	Wait for DMA to be done (dma_receive()/dma_memcpy())
	Invalidate destination buffer (invalidate_dcache_range())
	Read from destination buffer

The invalidate after the DMA is needed in order to read latest data from
memory that’s updated by DMA write. Also, in case random prefetch has
pulled in buffer data during the “wait for DMA” before the DMA has
written to it. This works well for non-coherent architectures.

In case of coherent architecture with L3 cache, DMA write would directly
update L3 cache contents (assuming cacheline is present in L3) without
updating the DDR memory. So invalidate after “wait for DMA” in above
sequence would discard latest data and read will cause stale data to be
fetched from DDR. Therefore invalidate after “wait for DMA” is not
always correct on coherent architecture.

Therefore, provide a Kconfig option to disable cache maintenance ops on
coherent architectures. This has added benefit of improving the
performance of DMA transfers as we no longer need to invalidate/flush
individual cache lines(especially for buffer thats several KBs in size).

In order to facilitate use of same Kconfig across different
architecture, I have added the symbol to top level arch/Kconfig file.
Patch currently disables cache maintenance ops for arm64 only.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
---
 arch/Kconfig                  |  7 +++++++
 arch/arm/cpu/armv8/cache_v8.c | 18 ++++++++++++++++++
 2 files changed, 25 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index 2f3d07c13a18..d32a458deedc 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -227,6 +227,13 @@ config SYS_CONFIG_NAME
 	  The header file include/configs/<CONFIG_SYS_CONFIG_NAME>.h
 	  should be included from include/config.h.
 
+config SYS_ARCH_IS_COHERENT
+	bool
+	help
+	Select this option, if your architecture is coherent and needs
+	to avoid cache maintenance operations. Note that, its up to the
+	individual architectures to implement this functionality
+
 source "arch/arc/Kconfig"
 source "arch/arm/Kconfig"
 source "arch/m68k/Kconfig"
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 038405173eb1..b39d6a65cf9c 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -417,6 +417,7 @@ __weak void mmu_setup(void)
 	set_sctlr(get_sctlr() | CR_M);
 }
 
+#ifndef CONFIG_SYS_ARCH_IS_COHERENT
 /*
  * Performs a invalidation of the entire data cache at all levels
  */
@@ -458,6 +459,23 @@ void flush_dcache_range(unsigned long start, unsigned long stop)
 {
 	__asm_flush_dcache_range(start, stop);
 }
+#else
+void invalidate_dcache_all(void)
+{
+}
+
+void flush_dcache_all(void)
+{
+}
+
+void invalidate_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+
+void flush_dcache_range(unsigned long start, unsigned long stop)
+{
+}
+#endif /* CONFIG_SYS_ARCH_IS_COHERENT */
 
 void dcache_enable(void)
 {
-- 
2.21.0

[U-Boot] [RFC PATCH 2/2] board: ti: am654: select SYS_ARCH_IS_COHERENT for arm64

[Vignesh Raghavendra]

AM654 SoC is IO coherent wrt A53 cores, therefore enable
SYS_ARCH_IS_COHERENT to avoid cache operations in A53 SPL/U-Boot.

Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
---
 board/ti/am65x/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/ti/am65x/Kconfig b/board/ti/am65x/Kconfig
index d4b36dbb42f3..2c4a02834fc2 100644
--- a/board/ti/am65x/Kconfig
+++ b/board/ti/am65x/Kconfig
@@ -11,6 +11,7 @@ config TARGET_AM654_A53_EVM
 	bool "TI K3 based AM654 EVM running on A53"
 	select ARM64
 	select SOC_K3_AM6
+	select SYS_ARCH_IS_COHERENT
 
 config TARGET_AM654_R5_EVM
 	bool "TI K3 based AM654 EVM running on R5"
-- 
2.21.0

[U-Boot] [RFC PATCH 1/2] arch: armv8: Provide a way to disable cache maintenance ops

[Tero Kristo]

On 25/03/2019 19:21, Vignesh Raghavendra wrote:
> On AM654 SoC(arm64) which is IO coherent and has L3 Cache, cache
> maintenance operations being done to support non-coherent platforms
> causes issues.
> 
> For example, here is how U-Boot prepares/handles a buffer to receive
> data from a device (DMA Write). This may vary slightly depending on the
> driver framework:
> 
> 	Start DMA to write to destination buffer
> 	Wait for DMA to be done (dma_receive()/dma_memcpy())
> 	Invalidate destination buffer (invalidate_dcache_range())
> 	Read from destination buffer
> 
> The invalidate after the DMA is needed in order to read latest data from
> memory that’s updated by DMA write. Also, in case random prefetch has
> pulled in buffer data during the “wait for DMA” before the DMA has
> written to it. This works well for non-coherent architectures.
> 
> In case of coherent architecture with L3 cache, DMA write would directly
> update L3 cache contents (assuming cacheline is present in L3) without
> updating the DDR memory. So invalidate after “wait for DMA” in above
> sequence would discard latest data and read will cause stale data to be
> fetched from DDR. Therefore invalidate after “wait for DMA” is not
> always correct on coherent architecture.
> 
> Therefore, provide a Kconfig option to disable cache maintenance ops on
> coherent architectures. This has added benefit of improving the
> performance of DMA transfers as we no longer need to invalidate/flush
> individual cache lines(especially for buffer thats several KBs in size).
> 
> In order to facilitate use of same Kconfig across different
> architecture, I have added the symbol to top level arch/Kconfig file.
> Patch currently disables cache maintenance ops for arm64 only.
> 
> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
> ---
>   arch/Kconfig                  |  7 +++++++
>   arch/arm/cpu/armv8/cache_v8.c | 18 ++++++++++++++++++
>   2 files changed, 25 insertions(+)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 2f3d07c13a18..d32a458deedc 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -227,6 +227,13 @@ config SYS_CONFIG_NAME
>   	  The header file include/configs/<CONFIG_SYS_CONFIG_NAME>.h
>   	  should be included from include/config.h.
>   
> +config SYS_ARCH_IS_COHERENT
> +	bool
> +	help
> +	Select this option, if your architecture is coherent and needs
> +	to avoid cache maintenance operations. Note that, its up to the
> +	individual architectures to implement this functionality

I think you should use something more generic here as the name / 
description of the Kconfig. SYS_ARCH_IS_COHERENT is a valid term for 
K2/K3, but there might be reasons why someone would want to disable 
cache ops on other architectures also. Also, SYS_ARCH_IS_COHERENT leads 
the user to believe that some real magic is done, instead of simple 
disabling of cache ops completely. If we are talking about the different 
evolutions of the coherency support in uboot, are you planning to 
re-write this Kconfig option to the mixed coherency support at some 
point, or just introduce a new Kconfig, or drop this completely?

Other than that, series seems fine to me.

-Tero

> +
>   source "arch/arc/Kconfig"
>   source "arch/arm/Kconfig"
>   source "arch/m68k/Kconfig"
> diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
> index 038405173eb1..b39d6a65cf9c 100644
> --- a/arch/arm/cpu/armv8/cache_v8.c
> +++ b/arch/arm/cpu/armv8/cache_v8.c
> @@ -417,6 +417,7 @@ __weak void mmu_setup(void)
>   	set_sctlr(get_sctlr() | CR_M);
>   }
>   
> +#ifndef CONFIG_SYS_ARCH_IS_COHERENT
>   /*
>    * Performs a invalidation of the entire data cache at all levels
>    */
> @@ -458,6 +459,23 @@ void flush_dcache_range(unsigned long start, unsigned long stop)
>   {
>   	__asm_flush_dcache_range(start, stop);
>   }
> +#else
> +void invalidate_dcache_all(void)
> +{
> +}
> +
> +void flush_dcache_all(void)
> +{
> +}
> +
> +void invalidate_dcache_range(unsigned long start, unsigned long stop)
> +{
> +}
> +
> +void flush_dcache_range(unsigned long start, unsigned long stop)
> +{
> +}
> +#endif /* CONFIG_SYS_ARCH_IS_COHERENT */
>   
>   void dcache_enable(void)
>   {
> 

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki