[PATCH 3/7] cache: andes_llcache: improve performance of LLC operation

Conor Dooley conor at kernel.org
Mon Mar 30 09:04:24 PDT 2026


On Mon, Mar 30, 2026 at 06:27:20PM +0800, Hui Min Mina Chou wrote:
> Eliminate get_cpu() on !CONFIG_SMP and switch readl/writel to their

Where is the get_cpu() that you're talking about eliminating here?

> relaxed variants to remove unnecessary fence instructions on I/O
> memory access. The platform specification defines all I/O regions are
> on channel 0 (point-to-point strongly ordered), so explicit fences are
> not required [1][2][3]. Explicit memory barriers (mb) are added before
> and after the CCTL loop to ensure overall memory consistency.
> 

> Also fix hart ID mapping by switching to cpuid_to_hartid_map() instead
> of using the logical CPU ID directly. In AMP setups (e.g. Linux on
> Hart 1, RTOS on Hart 0), Linux sees itself as CPU 0 but must access
> Hart 1's CCTL registers, so using the logical ID would cause accidental
> interference with other cores.

This seems like it should be a separate fix for sure.

> 
> [1] platform spec 2.1.1: https://github.com/riscvarchive/riscv-platform-specs/blob/main/riscv-platform-spec.adoc?plain=1#L169
> [2] privileged spec 3.6.5: https://github.com/riscv/riscv-isa-manual/blob/main/src/machine.adoc?plain=1#L2835
> [3] riscv: asm/mmio.h: https://gitea.andestech.com/RD-SW/linux/src/branch/ast-v5_4_0-branch/arch/riscv/include/asm/mmio.h#L105
> 
> Signed-off-by: Leo Yu-Chi Liang <ycliang at andestech.com>
> Signed-off-by: Hui Min Mina Chou <minachou at andestech.com>
> ---
>  drivers/cache/andes_llcache.c | 18 ++++++++++++++----
>  1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/cache/andes_llcache.c b/drivers/cache/andes_llcache.c
> index d318b8009f7f..57f666bc537a 100644
> --- a/drivers/cache/andes_llcache.c
> +++ b/drivers/cache/andes_llcache.c
> @@ -66,7 +66,7 @@ static struct andes_priv andes_priv;
>  /* LLC operations */
>  static inline uint32_t andes_cpu_llc_get_cctl_status(void)
>  {
> -	return readl(andes_priv.llc_base + ANDES_LLC_REG_CCTL_STATUS_OFFSET_C0);
> +	return readl_relaxed(andes_priv.llc_base + ANDES_LLC_REG_CCTL_STATUS_OFFSET_C0);
>  }
>  
>  static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
> @@ -74,16 +74,22 @@ static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
>  {
>  	unsigned long line_size = andes_priv.andes_cache_line_size;
>  	void __iomem *base = andes_priv.llc_base;
> -	int mhartid = smp_processor_id();
>  	unsigned long pa;
> +	int mhartid = 0;
>  
> +	if (IS_ENABLED(CONFIG_SMP))
> +		mhartid = cpuid_to_hartid_map(get_cpu());

But I dunno why this dance is required. Can't you just retain the call
to smp_processor_id() and pass the result unconditionally to
cpuid_to_hartid_map()? Or just make it a oneliner with
cpuid_to_hartid_map(smp_processor_id())?

> +	else
> +		mhartid = cpuid_to_hartid_map(0);
> +
> +	mb(); /* complete earlier memory accesses before the cache flush */
>  	while (end > start) {
>  		csr_write(CSR_UCCTLBEGINADDR, start);
>  		csr_write(CSR_UCCTLCOMMAND, l1_op);
>  
>  		pa = virt_to_phys((void *)start);
> -		writel(pa, base + ANDES_LLC_REG_CCTL_ACC_OFFSET_BY_CORE(mhartid));
> -		writel(llc_op, base + ANDES_LLC_REG_CCTL_CMD_OFFSET_BY_CORE(mhartid));
> +		writel_relaxed(pa, base + ANDES_LLC_REG_CCTL_ACC_OFFSET_BY_CORE(mhartid));
> +		writel_relaxed(llc_op, base + ANDES_LLC_REG_CCTL_CMD_OFFSET_BY_CORE(mhartid));
>  		while ((andes_cpu_llc_get_cctl_status() &
>  			ANDES_LLC_CCTL_STATUS_MASK_BY_CORE(mhartid)) !=
>  			ANDES_LLC_CCTL_STATUS_IDLE)
> @@ -91,6 +97,10 @@ static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
>  
>  		start += line_size;
>  	}
> +	mb(); /* issue later memory accesses after the cache flush */
> +
> +	if (IS_ENABLED(CONFIG_SMP))
> +		put_cpu();
>  }
>  
>  /* Write-back L1 and LLC entry */
> -- 
> 2.34.1
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20260330/b6b0aeea/attachment.sig>


More information about the linux-riscv mailing list