Hi Andrew,
On Fri, Feb 2, 2024 at 1:26 AM Andrew Davis wrote:
>
> The disable_linefill_optimization() function is only ever loaded by the
> R5 core, move the code into the R5 directory.
>
> Signed-off-by: Andrew Davis
> ---
> arch/arm/mach-k3/common.c| 25 -
> arch/arm/mach-k3/r5/Makefile | 1 +
> arch/arm/mach-k3/r5/common.c | 35 +++
> 3 files changed, 36 insertions(+), 25 deletions(-)
> create mode 100644 arch/arm/mach-k3/r5/common.c
>
> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
> index f411366778f..5d53efed85b 100644
> --- a/arch/arm/mach-k3/common.c
> +++ b/arch/arm/mach-k3/common.c
> @@ -453,31 +453,6 @@ void board_prep_linux(struct bootm_headers *images)
> }
> #endif
>
> -#ifdef CONFIG_CPU_V7R
> -void disable_linefill_optimization(void)
> -{
> - u32 actlr;
> -
> - /*
> -* On K3 devices there are 2 conditions where R5F can deadlock:
> -* 1.When software is performing series of store operations to
> -* cacheable write back/write allocate memory region and later
> -* on software execute barrier operation (DSB or DMB). R5F may
> -* hang at the barrier instruction.
> -* 2.When software is performing a mix of load and store operations
> -* within a tight loop and store operations are all writing to
> -* cacheable write back/write allocates memory regions, R5F may
> -* hang at one of the load instruction.
> -*
> -* To avoid the above two conditions disable linefill optimization
> -* inside Cortex R5F.
> -*/
> - asm("mrc p15, 0, %0, c1, c0, 1" : "=r" (actlr));
> - actlr |= (1 << 13); /* Set DLFO bit */
> - asm("mcr p15, 0, %0, c1, c0, 1" : : "r" (actlr));
> -}
> -#endif
> -
> static void remove_fwl_regions(struct fwl_data fwl_data, size_t num_regions,
>enum k3_firewall_region_type fwl_type)
> {
> diff --git a/arch/arm/mach-k3/r5/Makefile b/arch/arm/mach-k3/r5/Makefile
> index b99199d3374..8ad86eb2798 100644
> --- a/arch/arm/mach-k3/r5/Makefile
> +++ b/arch/arm/mach-k3/r5/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_SOC_K3_J721S2) += j721s2/
> obj-$(CONFIG_SOC_K3_AM625) += am62x/
> obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/
>
> +obj-y += common.o
> obj-y += lowlevel_init.o
> obj-y += r5_mpu.o
>
> diff --git a/arch/arm/mach-k3/r5/common.c b/arch/arm/mach-k3/r5/common.c
> new file mode 100644
> index 000..ef81f50c6c7
> --- /dev/null
> +++ b/arch/arm/mach-k3/r5/common.c
> @@ -0,0 +1,35 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * K3: R5 Common Architecture initialization
> + *
> + * Copyright (C) 2023 Texas Instruments Incorporated - https://www.ti.com/
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "../common.h"
> +
> +void disable_linefill_optimization(void)
> +{
> + u32 actlr;
> +
> + /*
> +* On K3 devices there are 2 conditions where R5F can deadlock:
> +* 1.When software is performing series of store operations to
> +* cacheable write back/write allocate memory region and later
> +* on software execute barrier operation (DSB or DMB). R5F may
> +* hang at the barrier instruction.
> +* 2.When software is performing a mix of load and store operations
> +* within a tight loop and store operations are all writing to
> +* cacheable write back/write allocates memory regions, R5F may
> +* hang at one of the load instruction.
> +*
> +* To avoid the above two conditions disable linefill optimization
> +* inside Cortex R5F.
> +*/
> + asm("mrc p15, 0, %0, c1, c0, 1" : "=r" (actlr));
> + actlr |= (1 << 13); /* Set DLFO bit */
> + asm("mcr p15, 0, %0, c1, c0, 1" : : "r" (actlr));
> +}
> --
> 2.39.2
>
Reviewed-by: Igor Opaniuk
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
Senior Software Engineer, Embedded & Security
E: igor.opan...@foundries.io
W: www.foundries.io
