[PATCH 0/2] Enable compile testing for K3 RemoteProc drivers

[PATCH 0/2] Enable compile testing for K3 RemoteProc drivers

[Andrew Davis]

Hello all,

This is a follow up to [0] that adds the same for the other two K3
RemoteProc drivers. Series is based on rproc-next branch.

Thanks,
Andrew

[0] https://lore.kernel.org/lkml/20241007132441.2732215-1-arnd@kernel.org/

Andrew Davis (2):
  remoteproc: k3-dsp: Add compile testing support
  remoteproc: k3-r5: Add compile testing support

 drivers/remoteproc/Kconfig | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

-- 
2.39.2

[PATCH 1/2] remoteproc: k3-dsp: Add compile testing support

[Andrew Davis]

This driver can be compile tested on non-K3 architectures as long
as TI_SCI_PROTOCOL is not compiled as a module. Enable this here
to improve this driver's build coverage.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/remoteproc/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 62f8548fb46a5..0ac1c8a6e4581 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -329,7 +329,8 @@ config STM32_RPROC
 
 config TI_K3_DSP_REMOTEPROC
 	tristate "TI K3 DSP remoteproc support"
-	depends on ARCH_K3
+	depends on ARCH_K3 || COMPILE_TEST
+	depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)
 	depends on OMAP2PLUS_MBOX
 	help
 	  Say m here to support TI's C66x and C71x DSP remote processor
-- 
2.39.2

[PATCH 2/2] remoteproc: k3-r5: Add compile testing support

[Andrew Davis]

This driver can be compile tested on non-K3 architectures as long
as TI_SCI_PROTOCOL is not compiled as a module. Enable this here
to improve this driver's build coverage.

Signed-off-by: Andrew Davis <afd@ti.com>
---
 drivers/remoteproc/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 0ac1c8a6e4581..83962a114dc9f 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -355,7 +355,8 @@ config TI_K3_M4_REMOTEPROC
 
 config TI_K3_R5_REMOTEPROC
 	tristate "TI K3 R5 remoteproc support"
-	depends on ARCH_K3
+	depends on ARCH_K3 || COMPILE_TEST
+	depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)
 	depends on OMAP2PLUS_MBOX
 	help
 	  Say m here to support TI's R5F remote processor subsystems
-- 
2.39.2

Re: [PATCH 0/2] Enable compile testing for K3 RemoteProc drivers

[Mathieu Poirier]

On Wed, Oct 16, 2024 at 11:41:39AM -0500, Andrew Davis wrote:
> Hello all,
> 
> This is a follow up to [0] that adds the same for the other two K3
> RemoteProc drivers. Series is based on rproc-next branch.
> 
> Thanks,
> Andrew
> 
> [0] https://lore.kernel.org/lkml/20241007132441.2732215-1-arnd@kernel.org/
> 
> Andrew Davis (2):
>   remoteproc: k3-dsp: Add compile testing support
>   remoteproc: k3-r5: Add compile testing support
>

I have applied this set.

Thanks,
Mathieu

>  drivers/remoteproc/Kconfig | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> -- 
> 2.39.2
> 

Re: [PATCH 2/2] remoteproc: k3-r5: Add compile testing support

[kernel test robot]

Hi Andrew,

kernel test robot noticed the following build warnings:

[auto build test WARNING on remoteproc/rproc-next]
[also build test WARNING on linus/master v6.12-rc3 next-20241018]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Andrew-Davis/remoteproc-k3-dsp-Add-compile-testing-support/20241017-004305
base:   https://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git rproc-next
patch link:    https://lore.kernel.org/r/20241016164141.93401-3-afd%40ti.com
patch subject: [PATCH 2/2] remoteproc: k3-r5: Add compile testing support
config: csky-randconfig-r132-20241019 (https://download.01.org/0day-ci/archive/20241020/202410200636.i36IwjjR-lkp@intel.com/config)
compiler: csky-linux-gcc (GCC) 14.1.0
reproduce: (https://download.01.org/0day-ci/archive/20241020/202410200636.i36IwjjR-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202410200636.i36IwjjR-lkp@intel.com/

sparse warnings: (new ones prefixed by >>)
>> drivers/remoteproc/ti_k3_r5_remoteproc.c:490:28: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void *dest @@     got void [noderef] __iomem *cpu_addr @@
   drivers/remoteproc/ti_k3_r5_remoteproc.c:490:28: sparse:     expected void *dest
   drivers/remoteproc/ti_k3_r5_remoteproc.c:490:28: sparse:     got void [noderef] __iomem *cpu_addr
   drivers/remoteproc/ti_k3_r5_remoteproc.c:493:28: sparse: sparse: incorrect type in argument 1 (different address spaces) @@     expected void *dest @@     got void [noderef] __iomem *cpu_addr @@
   drivers/remoteproc/ti_k3_r5_remoteproc.c:493:28: sparse:     expected void *dest
   drivers/remoteproc/ti_k3_r5_remoteproc.c:493:28: sparse:     got void [noderef] __iomem *cpu_addr
   drivers/remoteproc/ti_k3_r5_remoteproc.c:720:17: sparse: sparse: cast removes address space '__iomem' of expression

vim +490 drivers/remoteproc/ti_k3_r5_remoteproc.c

e3865c85385aa0c Suman Anna 2022-02-13  430  
6dedbd1d544389d Suman Anna 2020-10-02  431  /*
6dedbd1d544389d Suman Anna 2020-10-02  432   * The R5F cores have controls for both a reset and a halt/run. The code
6dedbd1d544389d Suman Anna 2020-10-02  433   * execution from DDR requires the initial boot-strapping code to be run
6dedbd1d544389d Suman Anna 2020-10-02  434   * from the internal TCMs. This function is used to release the resets on
6dedbd1d544389d Suman Anna 2020-10-02  435   * applicable cores to allow loading into the TCMs. The .prepare() ops is
6dedbd1d544389d Suman Anna 2020-10-02  436   * invoked by remoteproc core before any firmware loading, and is followed
6dedbd1d544389d Suman Anna 2020-10-02  437   * by the .start() ops after loading to actually let the R5 cores run.
ee99ee7c929c3e7 Suman Anna 2021-03-27  438   *
ee99ee7c929c3e7 Suman Anna 2021-03-27  439   * The Single-CPU mode on applicable SoCs (eg: AM64x) only uses Core0 to
ee99ee7c929c3e7 Suman Anna 2021-03-27  440   * execute code, but combines the TCMs from both cores. The resets for both
ee99ee7c929c3e7 Suman Anna 2021-03-27  441   * cores need to be released to make this possible, as the TCMs are in general
ee99ee7c929c3e7 Suman Anna 2021-03-27  442   * private to each core. Only Core0 needs to be unhalted for running the
ee99ee7c929c3e7 Suman Anna 2021-03-27  443   * cluster in this mode. The function uses the same reset logic as LockStep
ee99ee7c929c3e7 Suman Anna 2021-03-27  444   * mode for this (though the behavior is agnostic of the reset release order).
1168af40b1ad8cb Suman Anna 2022-02-13  445   * This callback is invoked only in remoteproc mode.
6dedbd1d544389d Suman Anna 2020-10-02  446   */
6dedbd1d544389d Suman Anna 2020-10-02  447  static int k3_r5_rproc_prepare(struct rproc *rproc)
6dedbd1d544389d Suman Anna 2020-10-02  448  {
6dedbd1d544389d Suman Anna 2020-10-02  449  	struct k3_r5_rproc *kproc = rproc->priv;
6dedbd1d544389d Suman Anna 2020-10-02  450  	struct k3_r5_cluster *cluster = kproc->cluster;
6dedbd1d544389d Suman Anna 2020-10-02  451  	struct k3_r5_core *core = kproc->core;
6dedbd1d544389d Suman Anna 2020-10-02  452  	struct device *dev = kproc->dev;
7508ea19b20da80 Suman Anna 2020-11-18  453  	u32 ctrl = 0, cfg = 0, stat = 0;
7508ea19b20da80 Suman Anna 2020-11-18  454  	u64 boot_vec = 0;
7508ea19b20da80 Suman Anna 2020-11-18  455  	bool mem_init_dis;
6dedbd1d544389d Suman Anna 2020-10-02  456  	int ret;
6dedbd1d544389d Suman Anna 2020-10-02  457  
7508ea19b20da80 Suman Anna 2020-11-18  458  	ret = ti_sci_proc_get_status(core->tsp, &boot_vec, &cfg, &ctrl, &stat);
7508ea19b20da80 Suman Anna 2020-11-18  459  	if (ret < 0)
7508ea19b20da80 Suman Anna 2020-11-18  460  		return ret;
7508ea19b20da80 Suman Anna 2020-11-18  461  	mem_init_dis = !!(cfg & PROC_BOOT_CFG_FLAG_R5_MEM_INIT_DIS);
7508ea19b20da80 Suman Anna 2020-11-18  462  
ee99ee7c929c3e7 Suman Anna 2021-03-27  463  	/* Re-use LockStep-mode reset logic for Single-CPU mode */
ee99ee7c929c3e7 Suman Anna 2021-03-27  464  	ret = (cluster->mode == CLUSTER_MODE_LOCKSTEP ||
ee99ee7c929c3e7 Suman Anna 2021-03-27  465  	       cluster->mode == CLUSTER_MODE_SINGLECPU) ?
6dedbd1d544389d Suman Anna 2020-10-02  466  		k3_r5_lockstep_release(cluster) : k3_r5_split_release(core);
34f2653686fecc9 Suman Anna 2020-10-02  467  	if (ret) {
6dedbd1d544389d Suman Anna 2020-10-02  468  		dev_err(dev, "unable to enable cores for TCM loading, ret = %d\n",
6dedbd1d544389d Suman Anna 2020-10-02  469  			ret);
6dedbd1d544389d Suman Anna 2020-10-02  470  		return ret;
6dedbd1d544389d Suman Anna 2020-10-02  471  	}
6dedbd1d544389d Suman Anna 2020-10-02  472  
7508ea19b20da80 Suman Anna 2020-11-18  473  	/*
7508ea19b20da80 Suman Anna 2020-11-18  474  	 * Newer IP revisions like on J7200 SoCs support h/w auto-initialization
7508ea19b20da80 Suman Anna 2020-11-18  475  	 * of TCMs, so there is no need to perform the s/w memzero. This bit is
7508ea19b20da80 Suman Anna 2020-11-18  476  	 * configurable through System Firmware, the default value does perform
7508ea19b20da80 Suman Anna 2020-11-18  477  	 * auto-init, but account for it in case it is disabled
7508ea19b20da80 Suman Anna 2020-11-18  478  	 */
7508ea19b20da80 Suman Anna 2020-11-18  479  	if (cluster->soc_data->tcm_ecc_autoinit && !mem_init_dis) {
7508ea19b20da80 Suman Anna 2020-11-18  480  		dev_dbg(dev, "leveraging h/w init for TCM memories\n");
7508ea19b20da80 Suman Anna 2020-11-18  481  		return 0;
7508ea19b20da80 Suman Anna 2020-11-18  482  	}
7508ea19b20da80 Suman Anna 2020-11-18  483  
34f2653686fecc9 Suman Anna 2020-10-02  484  	/*
34f2653686fecc9 Suman Anna 2020-10-02  485  	 * Zero out both TCMs unconditionally (access from v8 Arm core is not
34f2653686fecc9 Suman Anna 2020-10-02  486  	 * affected by ATCM & BTCM enable configuration values) so that ECC
34f2653686fecc9 Suman Anna 2020-10-02  487  	 * can be effective on all TCM addresses.
34f2653686fecc9 Suman Anna 2020-10-02  488  	 */
34f2653686fecc9 Suman Anna 2020-10-02  489  	dev_dbg(dev, "zeroing out ATCM memory\n");
34f2653686fecc9 Suman Anna 2020-10-02 @490  	memset(core->mem[0].cpu_addr, 0x00, core->mem[0].size);
34f2653686fecc9 Suman Anna 2020-10-02  491  
34f2653686fecc9 Suman Anna 2020-10-02  492  	dev_dbg(dev, "zeroing out BTCM memory\n");
34f2653686fecc9 Suman Anna 2020-10-02  493  	memset(core->mem[1].cpu_addr, 0x00, core->mem[1].size);
34f2653686fecc9 Suman Anna 2020-10-02  494  
34f2653686fecc9 Suman Anna 2020-10-02  495  	return 0;
34f2653686fecc9 Suman Anna 2020-10-02  496  }
34f2653686fecc9 Suman Anna 2020-10-02  497  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH 2/2] remoteproc: k3-r5: Add compile testing support

[Andrew Davis]

On 10/16/24 11:41 AM, Andrew Davis wrote:
> This driver can be compile tested on non-K3 architectures as long
> as TI_SCI_PROTOCOL is not compiled as a module. Enable this here
> to improve this driver's build coverage.
> 
> Signed-off-by: Andrew Davis <afd@ti.com>
> ---
>   drivers/remoteproc/Kconfig | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 0ac1c8a6e4581..83962a114dc9f 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -355,7 +355,8 @@ config TI_K3_M4_REMOTEPROC
>   
>   config TI_K3_R5_REMOTEPROC
>   	tristate "TI K3 R5 remoteproc support"
> -	depends on ARCH_K3
> +	depends on ARCH_K3 || COMPILE_TEST

kernel test robot is giving some extra warning now around the lines:

memset(core->mem[0].cpu_addr, 0x00, core->mem[0].size);

This was already an issue and threw warnings even on ARM64 builds, but
now that we can compile test on other archs, all those will start
complaining too.

Fix is easy, just s/memset()/memset_io() here. I'll give that a test
run then send a patch.

Andrew

> +	depends on TI_SCI_PROTOCOL || (COMPILE_TEST && TI_SCI_PROTOCOL=n)
>   	depends on OMAP2PLUS_MBOX
>   	help
>   	  Say m here to support TI's R5F remote processor subsystems