Re: [PATCH 2/2] remoteproc: k3-r5: Extend support to R5F clusters on AM64x SoCs
On 3/25/21 5:17 PM, Mathieu Poirier wrote:
> On Thu, Mar 25, 2021 at 04:00:55PM -0500, Suman Anna wrote:
>> Hi Mathieu,
>>
>> On 3/25/21 12:30 PM, Mathieu Poirier wrote:
>>> Good morning,
>>>
>>> On Thu, Mar 18, 2021 at 04:58:42PM -0500, Suman Anna wrote:
The K3 AM64x SoC family has a revised R5F sub-system and contains a
subset of the R5F clusters present on J721E SoCs. The K3 AM64x SoCs
only have two dual-core Arm R5F clusters/subsystems with 2 R5F cores
each present within the MAIN voltage domain (MAIN_R5FSS0 & MAIN_R5FSS1).
The revised IP has the following distinct features:
1. The R5FSS IP supports a new "Single-CPU" mode instead of the LockStep
mode on existing SoCs (AM65x, J721E or J7200). This mode is similar
to LockStep-mode on J7200 SoCs in terms of TCM usage without the
fault-tolerant safety feature provided by the LockStep mode.
The Core1 TCMs are combined with the Core0 TCMs effectively doubling
the amount of TCMs available in Single-CPU mode. The LockStep-mode
on previous AM65x and J721E SoCs could only use the Core0 TCMs. These
combined TCMs appear contiguous at the respective Core0 TCM addresses.
The code though is executed only on a single CPU (on Core0), and as
such, requires the halt signal to be programmed only for Core0, while
the resets need to be managed for both the cores.
2. TCMs are auto-initialized during module power-up, and the behavior
is programmable through a MMR bit. This feature is the same as on
the recent J7200 SoCs.
Extend the support to these clusters in the K3 R5F remoteproc driver
using AM64x specific compatibles. New TI-SCI flags and a unique cluster
mode are also needed for the cluster mode detection on these SoCs. The
reset assert and deassert sequence of both the cores in Single-CPU mode
is agnostic of the order, so the same LockStep reset and release sequences
are re-used.
The integration of these clusters is very much similar to existing SoCs
otherwise.
Signed-off-by: Suman Anna
---
drivers/remoteproc/ti_k3_r5_remoteproc.c | 155 ++-
1 file changed, 126 insertions(+), 29 deletions(-)
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index 5cf8d030a1f0..497f0d05b887 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -40,6 +40,8 @@
#define PROC_BOOT_CFG_FLAG_R5_ATCM_EN 0x2000
/* Available from J7200 SoCs onwards */
#define PROC_BOOT_CFG_FLAG_R5_MEM_INIT_DIS0x4000
+/* Applicable to only AM64x SoCs */
+#define PROC_BOOT_CFG_FLAG_R5_SINGLE_CORE 0x8000
/* R5 TI-SCI Processor Control Flags */
#define PROC_BOOT_CTRL_FLAG_R5_CORE_HALT 0x0001
@@ -49,6 +51,8 @@
#define PROC_BOOT_STATUS_FLAG_R5_WFI 0x0002
#define PROC_BOOT_STATUS_FLAG_R5_CLK_GATED0x0004
#define PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED 0x0100
+/* Applicable to only AM64x SoCs */
+#define PROC_BOOT_STATUS_FLAG_R5_SINGLECORE_ONLY 0x0200
/**
* struct k3_r5_mem - internal memory structure
@@ -64,19 +68,29 @@ struct k3_r5_mem {
size_t size;
};
+/*
+ * All cluster mode values are not applicable on all SoCs. The following
+ * are the modes supported on various SoCs:
+ * Split mode : AM65x, J721E, J7200 and AM64x SoCs
+ * LockStep mode : AM65x, J721E and J7200 SoCs
+ * Single-CPU mode : AM64x SoCs only
+ */
enum cluster_mode {
CLUSTER_MODE_SPLIT = 0,
CLUSTER_MODE_LOCKSTEP,
+ CLUSTER_MODE_SINGLECPU,
};
/**
* struct k3_r5_soc_data - match data to handle SoC variations
* @tcm_is_double: flag to denote the larger unified TCMs in certain modes
* @tcm_ecc_autoinit: flag to denote the auto-initialization of TCMs for
ECC
+ * @single_cpu_mode: flag to denote if SoC/IP supports Single-CPU mode
*/
struct k3_r5_soc_data {
bool tcm_is_double;
bool tcm_ecc_autoinit;
+ bool single_cpu_mode;
};
/**
@@ -369,6 +383,13 @@ static inline int k3_r5_core_run(struct k3_r5_core
*core)
* applicable cores to allow loading into the TCMs. The .prepare() ops is
* invoked by remoteproc core before any firmware loading, and is followed
* by the .start() ops after loading to actually let the R5 cores run.
+ *
+ * The Single-CPU mode on applicable SoCs (eg: AM64x) only uses Core0 to
+ * execute code, but combines the TCMs from both cores. The resets for
both
+ * cores need
Re: [PATCH 2/2] remoteproc: k3-r5: Extend support to R5F clusters on AM64x SoCs
On Thu, Mar 25, 2021 at 04:00:55PM -0500, Suman Anna wrote:
> Hi Mathieu,
>
> On 3/25/21 12:30 PM, Mathieu Poirier wrote:
> > Good morning,
> >
> > On Thu, Mar 18, 2021 at 04:58:42PM -0500, Suman Anna wrote:
> >> The K3 AM64x SoC family has a revised R5F sub-system and contains a
> >> subset of the R5F clusters present on J721E SoCs. The K3 AM64x SoCs
> >> only have two dual-core Arm R5F clusters/subsystems with 2 R5F cores
> >> each present within the MAIN voltage domain (MAIN_R5FSS0 & MAIN_R5FSS1).
> >>
> >> The revised IP has the following distinct features:
> >> 1. The R5FSS IP supports a new "Single-CPU" mode instead of the LockStep
> >> mode on existing SoCs (AM65x, J721E or J7200). This mode is similar
> >> to LockStep-mode on J7200 SoCs in terms of TCM usage without the
> >> fault-tolerant safety feature provided by the LockStep mode.
> >>
> >> The Core1 TCMs are combined with the Core0 TCMs effectively doubling
> >> the amount of TCMs available in Single-CPU mode. The LockStep-mode
> >> on previous AM65x and J721E SoCs could only use the Core0 TCMs. These
> >> combined TCMs appear contiguous at the respective Core0 TCM addresses.
> >> The code though is executed only on a single CPU (on Core0), and as
> >> such, requires the halt signal to be programmed only for Core0, while
> >> the resets need to be managed for both the cores.
> >>
> >> 2. TCMs are auto-initialized during module power-up, and the behavior
> >> is programmable through a MMR bit. This feature is the same as on
> >> the recent J7200 SoCs.
> >>
> >> Extend the support to these clusters in the K3 R5F remoteproc driver
> >> using AM64x specific compatibles. New TI-SCI flags and a unique cluster
> >> mode are also needed for the cluster mode detection on these SoCs. The
> >> reset assert and deassert sequence of both the cores in Single-CPU mode
> >> is agnostic of the order, so the same LockStep reset and release sequences
> >> are re-used.
> >>
> >> The integration of these clusters is very much similar to existing SoCs
> >> otherwise.
> >>
> >> Signed-off-by: Suman Anna
> >> ---
> >> drivers/remoteproc/ti_k3_r5_remoteproc.c | 155 ++-
> >> 1 file changed, 126 insertions(+), 29 deletions(-)
> >>
> >> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> >> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> >> index 5cf8d030a1f0..497f0d05b887 100644
> >> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> >> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> >> @@ -40,6 +40,8 @@
> >> #define PROC_BOOT_CFG_FLAG_R5_ATCM_EN 0x2000
> >> /* Available from J7200 SoCs onwards */
> >> #define PROC_BOOT_CFG_FLAG_R5_MEM_INIT_DIS0x4000
> >> +/* Applicable to only AM64x SoCs */
> >> +#define PROC_BOOT_CFG_FLAG_R5_SINGLE_CORE 0x8000
> >>
> >> /* R5 TI-SCI Processor Control Flags */
> >> #define PROC_BOOT_CTRL_FLAG_R5_CORE_HALT 0x0001
> >> @@ -49,6 +51,8 @@
> >> #define PROC_BOOT_STATUS_FLAG_R5_WFI 0x0002
> >> #define PROC_BOOT_STATUS_FLAG_R5_CLK_GATED0x0004
> >> #define PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED 0x0100
> >> +/* Applicable to only AM64x SoCs */
> >> +#define PROC_BOOT_STATUS_FLAG_R5_SINGLECORE_ONLY 0x0200
> >>
> >> /**
> >> * struct k3_r5_mem - internal memory structure
> >> @@ -64,19 +68,29 @@ struct k3_r5_mem {
> >>size_t size;
> >> };
> >>
> >> +/*
> >> + * All cluster mode values are not applicable on all SoCs. The following
> >> + * are the modes supported on various SoCs:
> >> + * Split mode : AM65x, J721E, J7200 and AM64x SoCs
> >> + * LockStep mode : AM65x, J721E and J7200 SoCs
> >> + * Single-CPU mode : AM64x SoCs only
> >> + */
> >> enum cluster_mode {
> >>CLUSTER_MODE_SPLIT = 0,
> >>CLUSTER_MODE_LOCKSTEP,
> >> + CLUSTER_MODE_SINGLECPU,
> >> };
> >>
> >> /**
> >> * struct k3_r5_soc_data - match data to handle SoC variations
> >> * @tcm_is_double: flag to denote the larger unified TCMs in certain modes
> >> * @tcm_ecc_autoinit: flag to denote the auto-initialization of TCMs for
> >> ECC
> >> + * @single_cpu_mode: flag to denote if SoC/IP supports Single-CPU mode
> >> */
> >> struct k3_r5_soc_data {
> >>bool tcm_is_double;
> >>bool tcm_ecc_autoinit;
> >> + bool single_cpu_mode;
> >> };
> >>
> >> /**
> >> @@ -369,6 +383,13 @@ static inline int k3_r5_core_run(struct k3_r5_core
> >> *core)
> >> * applicable cores to allow loading into the TCMs. The .prepare() ops is
> >> * invoked by remoteproc core before any firmware loading, and is followed
> >> * by the .start() ops after loading to actually let the R5 cores run.
> >> + *
> >> + * The Single-CPU mode on applicable SoCs (eg: AM64x) only uses Core0 to
> >> + * execute code, but combines the TCMs from both cores. The resets for
> >> both
> >> + * cores need to be released to make this possible, as the
Re: [PATCH 2/2] remoteproc: k3-r5: Extend support to R5F clusters on AM64x SoCs
Hi Mathieu,
On 3/25/21 12:30 PM, Mathieu Poirier wrote:
> Good morning,
>
> On Thu, Mar 18, 2021 at 04:58:42PM -0500, Suman Anna wrote:
>> The K3 AM64x SoC family has a revised R5F sub-system and contains a
>> subset of the R5F clusters present on J721E SoCs. The K3 AM64x SoCs
>> only have two dual-core Arm R5F clusters/subsystems with 2 R5F cores
>> each present within the MAIN voltage domain (MAIN_R5FSS0 & MAIN_R5FSS1).
>>
>> The revised IP has the following distinct features:
>> 1. The R5FSS IP supports a new "Single-CPU" mode instead of the LockStep
>> mode on existing SoCs (AM65x, J721E or J7200). This mode is similar
>> to LockStep-mode on J7200 SoCs in terms of TCM usage without the
>> fault-tolerant safety feature provided by the LockStep mode.
>>
>> The Core1 TCMs are combined with the Core0 TCMs effectively doubling
>> the amount of TCMs available in Single-CPU mode. The LockStep-mode
>> on previous AM65x and J721E SoCs could only use the Core0 TCMs. These
>> combined TCMs appear contiguous at the respective Core0 TCM addresses.
>> The code though is executed only on a single CPU (on Core0), and as
>> such, requires the halt signal to be programmed only for Core0, while
>> the resets need to be managed for both the cores.
>>
>> 2. TCMs are auto-initialized during module power-up, and the behavior
>> is programmable through a MMR bit. This feature is the same as on
>> the recent J7200 SoCs.
>>
>> Extend the support to these clusters in the K3 R5F remoteproc driver
>> using AM64x specific compatibles. New TI-SCI flags and a unique cluster
>> mode are also needed for the cluster mode detection on these SoCs. The
>> reset assert and deassert sequence of both the cores in Single-CPU mode
>> is agnostic of the order, so the same LockStep reset and release sequences
>> are re-used.
>>
>> The integration of these clusters is very much similar to existing SoCs
>> otherwise.
>>
>> Signed-off-by: Suman Anna
>> ---
>> drivers/remoteproc/ti_k3_r5_remoteproc.c | 155 ++-
>> 1 file changed, 126 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
>> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
>> index 5cf8d030a1f0..497f0d05b887 100644
>> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
>> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
>> @@ -40,6 +40,8 @@
>> #define PROC_BOOT_CFG_FLAG_R5_ATCM_EN 0x2000
>> /* Available from J7200 SoCs onwards */
>> #define PROC_BOOT_CFG_FLAG_R5_MEM_INIT_DIS 0x4000
>> +/* Applicable to only AM64x SoCs */
>> +#define PROC_BOOT_CFG_FLAG_R5_SINGLE_CORE 0x8000
>>
>> /* R5 TI-SCI Processor Control Flags */
>> #define PROC_BOOT_CTRL_FLAG_R5_CORE_HALT0x0001
>> @@ -49,6 +51,8 @@
>> #define PROC_BOOT_STATUS_FLAG_R5_WFI0x0002
>> #define PROC_BOOT_STATUS_FLAG_R5_CLK_GATED 0x0004
>> #define PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED 0x0100
>> +/* Applicable to only AM64x SoCs */
>> +#define PROC_BOOT_STATUS_FLAG_R5_SINGLECORE_ONLY0x0200
>>
>> /**
>> * struct k3_r5_mem - internal memory structure
>> @@ -64,19 +68,29 @@ struct k3_r5_mem {
>> size_t size;
>> };
>>
>> +/*
>> + * All cluster mode values are not applicable on all SoCs. The following
>> + * are the modes supported on various SoCs:
>> + * Split mode : AM65x, J721E, J7200 and AM64x SoCs
>> + * LockStep mode : AM65x, J721E and J7200 SoCs
>> + * Single-CPU mode : AM64x SoCs only
>> + */
>> enum cluster_mode {
>> CLUSTER_MODE_SPLIT = 0,
>> CLUSTER_MODE_LOCKSTEP,
>> +CLUSTER_MODE_SINGLECPU,
>> };
>>
>> /**
>> * struct k3_r5_soc_data - match data to handle SoC variations
>> * @tcm_is_double: flag to denote the larger unified TCMs in certain modes
>> * @tcm_ecc_autoinit: flag to denote the auto-initialization of TCMs for ECC
>> + * @single_cpu_mode: flag to denote if SoC/IP supports Single-CPU mode
>> */
>> struct k3_r5_soc_data {
>> bool tcm_is_double;
>> bool tcm_ecc_autoinit;
>> +bool single_cpu_mode;
>> };
>>
>> /**
>> @@ -369,6 +383,13 @@ static inline int k3_r5_core_run(struct k3_r5_core
>> *core)
>> * applicable cores to allow loading into the TCMs. The .prepare() ops is
>> * invoked by remoteproc core before any firmware loading, and is followed
>> * by the .start() ops after loading to actually let the R5 cores run.
>> + *
>> + * The Single-CPU mode on applicable SoCs (eg: AM64x) only uses Core0 to
>> + * execute code, but combines the TCMs from both cores. The resets for both
>> + * cores need to be released to make this possible, as the TCMs are in
>> general
>> + * private to each core. Only Core0 needs to be unhalted for running the
>> + * cluster in this mode. The function uses the same reset logic as LockStep
>> + * mode for this (though the behavior is agnostic of the reset release
>> order).
>> */
>>
Re: [PATCH 2/2] remoteproc: k3-r5: Extend support to R5F clusters on AM64x SoCs
Good morning,
On Thu, Mar 18, 2021 at 04:58:42PM -0500, Suman Anna wrote:
> The K3 AM64x SoC family has a revised R5F sub-system and contains a
> subset of the R5F clusters present on J721E SoCs. The K3 AM64x SoCs
> only have two dual-core Arm R5F clusters/subsystems with 2 R5F cores
> each present within the MAIN voltage domain (MAIN_R5FSS0 & MAIN_R5FSS1).
>
> The revised IP has the following distinct features:
> 1. The R5FSS IP supports a new "Single-CPU" mode instead of the LockStep
> mode on existing SoCs (AM65x, J721E or J7200). This mode is similar
> to LockStep-mode on J7200 SoCs in terms of TCM usage without the
> fault-tolerant safety feature provided by the LockStep mode.
>
> The Core1 TCMs are combined with the Core0 TCMs effectively doubling
> the amount of TCMs available in Single-CPU mode. The LockStep-mode
> on previous AM65x and J721E SoCs could only use the Core0 TCMs. These
> combined TCMs appear contiguous at the respective Core0 TCM addresses.
> The code though is executed only on a single CPU (on Core0), and as
> such, requires the halt signal to be programmed only for Core0, while
> the resets need to be managed for both the cores.
>
> 2. TCMs are auto-initialized during module power-up, and the behavior
> is programmable through a MMR bit. This feature is the same as on
> the recent J7200 SoCs.
>
> Extend the support to these clusters in the K3 R5F remoteproc driver
> using AM64x specific compatibles. New TI-SCI flags and a unique cluster
> mode are also needed for the cluster mode detection on these SoCs. The
> reset assert and deassert sequence of both the cores in Single-CPU mode
> is agnostic of the order, so the same LockStep reset and release sequences
> are re-used.
>
> The integration of these clusters is very much similar to existing SoCs
> otherwise.
>
> Signed-off-by: Suman Anna
> ---
> drivers/remoteproc/ti_k3_r5_remoteproc.c | 155 ++-
> 1 file changed, 126 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 5cf8d030a1f0..497f0d05b887 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -40,6 +40,8 @@
> #define PROC_BOOT_CFG_FLAG_R5_ATCM_EN0x2000
> /* Available from J7200 SoCs onwards */
> #define PROC_BOOT_CFG_FLAG_R5_MEM_INIT_DIS 0x4000
> +/* Applicable to only AM64x SoCs */
> +#define PROC_BOOT_CFG_FLAG_R5_SINGLE_CORE0x8000
>
> /* R5 TI-SCI Processor Control Flags */
> #define PROC_BOOT_CTRL_FLAG_R5_CORE_HALT 0x0001
> @@ -49,6 +51,8 @@
> #define PROC_BOOT_STATUS_FLAG_R5_WFI 0x0002
> #define PROC_BOOT_STATUS_FLAG_R5_CLK_GATED 0x0004
> #define PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED 0x0100
> +/* Applicable to only AM64x SoCs */
> +#define PROC_BOOT_STATUS_FLAG_R5_SINGLECORE_ONLY 0x0200
>
> /**
> * struct k3_r5_mem - internal memory structure
> @@ -64,19 +68,29 @@ struct k3_r5_mem {
> size_t size;
> };
>
> +/*
> + * All cluster mode values are not applicable on all SoCs. The following
> + * are the modes supported on various SoCs:
> + * Split mode : AM65x, J721E, J7200 and AM64x SoCs
> + * LockStep mode : AM65x, J721E and J7200 SoCs
> + * Single-CPU mode : AM64x SoCs only
> + */
> enum cluster_mode {
> CLUSTER_MODE_SPLIT = 0,
> CLUSTER_MODE_LOCKSTEP,
> + CLUSTER_MODE_SINGLECPU,
> };
>
> /**
> * struct k3_r5_soc_data - match data to handle SoC variations
> * @tcm_is_double: flag to denote the larger unified TCMs in certain modes
> * @tcm_ecc_autoinit: flag to denote the auto-initialization of TCMs for ECC
> + * @single_cpu_mode: flag to denote if SoC/IP supports Single-CPU mode
> */
> struct k3_r5_soc_data {
> bool tcm_is_double;
> bool tcm_ecc_autoinit;
> + bool single_cpu_mode;
> };
>
> /**
> @@ -369,6 +383,13 @@ static inline int k3_r5_core_run(struct k3_r5_core *core)
> * applicable cores to allow loading into the TCMs. The .prepare() ops is
> * invoked by remoteproc core before any firmware loading, and is followed
> * by the .start() ops after loading to actually let the R5 cores run.
> + *
> + * The Single-CPU mode on applicable SoCs (eg: AM64x) only uses Core0 to
> + * execute code, but combines the TCMs from both cores. The resets for both
> + * cores need to be released to make this possible, as the TCMs are in
> general
> + * private to each core. Only Core0 needs to be unhalted for running the
> + * cluster in this mode. The function uses the same reset logic as LockStep
> + * mode for this (though the behavior is agnostic of the reset release
> order).
> */
> static int k3_r5_rproc_prepare(struct rproc *rproc)
> {
> @@ -386,7 +407,9 @@ static int k3_r5_rproc_prepare(struct rproc *rproc)
> return ret;
Re: [PATCH 2/2] remoteproc: k3-r5: Extend support to R5F clusters on AM64x SoCs
Hi Mathieu,
On 3/24/21 11:46 AM, Mathieu Poirier wrote:
> Good day Suman,
>
> On Thu, Mar 18, 2021 at 04:58:42PM -0500, Suman Anna wrote:
>> The K3 AM64x SoC family has a revised R5F sub-system and contains a
>> subset of the R5F clusters present on J721E SoCs. The K3 AM64x SoCs
>> only have two dual-core Arm R5F clusters/subsystems with 2 R5F cores
>> each present within the MAIN voltage domain (MAIN_R5FSS0 & MAIN_R5FSS1).
>>
>> The revised IP has the following distinct features:
>> 1. The R5FSS IP supports a new "Single-CPU" mode instead of the LockStep
>> mode on existing SoCs (AM65x, J721E or J7200). This mode is similar
>> to LockStep-mode on J7200 SoCs in terms of TCM usage without the
>> fault-tolerant safety feature provided by the LockStep mode.
>>
>> The Core1 TCMs are combined with the Core0 TCMs effectively doubling
>> the amount of TCMs available in Single-CPU mode. The LockStep-mode
>> on previous AM65x and J721E SoCs could only use the Core0 TCMs. These
>> combined TCMs appear contiguous at the respective Core0 TCM addresses.
>> The code though is executed only on a single CPU (on Core0), and as
>> such, requires the halt signal to be programmed only for Core0, while
>> the resets need to be managed for both the cores.
>>
>> 2. TCMs are auto-initialized during module power-up, and the behavior
>> is programmable through a MMR bit. This feature is the same as on
>> the recent J7200 SoCs.
>>
>> Extend the support to these clusters in the K3 R5F remoteproc driver
>> using AM64x specific compatibles. New TI-SCI flags and a unique cluster
>> mode are also needed for the cluster mode detection on these SoCs. The
>> reset assert and deassert sequence of both the cores in Single-CPU mode
>> is agnostic of the order, so the same LockStep reset and release sequences
>> are re-used.
>>
>> The integration of these clusters is very much similar to existing SoCs
>> otherwise.
>>
>> Signed-off-by: Suman Anna
>> ---
>> drivers/remoteproc/ti_k3_r5_remoteproc.c | 155 ++-
>> 1 file changed, 126 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
>> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
>> index 5cf8d030a1f0..497f0d05b887 100644
>> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
>> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
>> @@ -40,6 +40,8 @@
>> #define PROC_BOOT_CFG_FLAG_R5_ATCM_EN 0x2000
>> /* Available from J7200 SoCs onwards */
>> #define PROC_BOOT_CFG_FLAG_R5_MEM_INIT_DIS 0x4000
>> +/* Applicable to only AM64x SoCs */
>> +#define PROC_BOOT_CFG_FLAG_R5_SINGLE_CORE 0x8000
>>
>> /* R5 TI-SCI Processor Control Flags */
>> #define PROC_BOOT_CTRL_FLAG_R5_CORE_HALT0x0001
>> @@ -49,6 +51,8 @@
>> #define PROC_BOOT_STATUS_FLAG_R5_WFI0x0002
>> #define PROC_BOOT_STATUS_FLAG_R5_CLK_GATED 0x0004
>> #define PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED 0x0100
>> +/* Applicable to only AM64x SoCs */
>> +#define PROC_BOOT_STATUS_FLAG_R5_SINGLECORE_ONLY0x0200
>>
>> /**
>> * struct k3_r5_mem - internal memory structure
>> @@ -64,19 +68,29 @@ struct k3_r5_mem {
>> size_t size;
>> };
>>
>> +/*
>> + * All cluster mode values are not applicable on all SoCs. The following
>> + * are the modes supported on various SoCs:
>> + * Split mode : AM65x, J721E, J7200 and AM64x SoCs
>> + * LockStep mode : AM65x, J721E and J7200 SoCs
>> + * Single-CPU mode : AM64x SoCs only
>> + */
>> enum cluster_mode {
>> CLUSTER_MODE_SPLIT = 0,
>> CLUSTER_MODE_LOCKSTEP,
>> +CLUSTER_MODE_SINGLECPU,
>> };
>>
>> /**
>> * struct k3_r5_soc_data - match data to handle SoC variations
>> * @tcm_is_double: flag to denote the larger unified TCMs in certain modes
>> * @tcm_ecc_autoinit: flag to denote the auto-initialization of TCMs for ECC
>> + * @single_cpu_mode: flag to denote if SoC/IP supports Single-CPU mode
>> */
>> struct k3_r5_soc_data {
>> bool tcm_is_double;
>> bool tcm_ecc_autoinit;
>> +bool single_cpu_mode;
>> };
>>
>> /**
>> @@ -369,6 +383,13 @@ static inline int k3_r5_core_run(struct k3_r5_core
>> *core)
>> * applicable cores to allow loading into the TCMs. The .prepare() ops is
>> * invoked by remoteproc core before any firmware loading, and is followed
>> * by the .start() ops after loading to actually let the R5 cores run.
>> + *
>> + * The Single-CPU mode on applicable SoCs (eg: AM64x) only uses Core0 to
>> + * execute code, but combines the TCMs from both cores. The resets for both
>> + * cores need to be released to make this possible, as the TCMs are in
>> general
>> + * private to each core. Only Core0 needs to be unhalted for running the
>> + * cluster in this mode. The function uses the same reset logic as LockStep
>> + * mode for this (though the behavior is agnostic of the reset release
>> order).
>> */
>>
Re: [PATCH 2/2] remoteproc: k3-r5: Extend support to R5F clusters on AM64x SoCs
Good day Suman,
On Thu, Mar 18, 2021 at 04:58:42PM -0500, Suman Anna wrote:
> The K3 AM64x SoC family has a revised R5F sub-system and contains a
> subset of the R5F clusters present on J721E SoCs. The K3 AM64x SoCs
> only have two dual-core Arm R5F clusters/subsystems with 2 R5F cores
> each present within the MAIN voltage domain (MAIN_R5FSS0 & MAIN_R5FSS1).
>
> The revised IP has the following distinct features:
> 1. The R5FSS IP supports a new "Single-CPU" mode instead of the LockStep
> mode on existing SoCs (AM65x, J721E or J7200). This mode is similar
> to LockStep-mode on J7200 SoCs in terms of TCM usage without the
> fault-tolerant safety feature provided by the LockStep mode.
>
> The Core1 TCMs are combined with the Core0 TCMs effectively doubling
> the amount of TCMs available in Single-CPU mode. The LockStep-mode
> on previous AM65x and J721E SoCs could only use the Core0 TCMs. These
> combined TCMs appear contiguous at the respective Core0 TCM addresses.
> The code though is executed only on a single CPU (on Core0), and as
> such, requires the halt signal to be programmed only for Core0, while
> the resets need to be managed for both the cores.
>
> 2. TCMs are auto-initialized during module power-up, and the behavior
> is programmable through a MMR bit. This feature is the same as on
> the recent J7200 SoCs.
>
> Extend the support to these clusters in the K3 R5F remoteproc driver
> using AM64x specific compatibles. New TI-SCI flags and a unique cluster
> mode are also needed for the cluster mode detection on these SoCs. The
> reset assert and deassert sequence of both the cores in Single-CPU mode
> is agnostic of the order, so the same LockStep reset and release sequences
> are re-used.
>
> The integration of these clusters is very much similar to existing SoCs
> otherwise.
>
> Signed-off-by: Suman Anna
> ---
> drivers/remoteproc/ti_k3_r5_remoteproc.c | 155 ++-
> 1 file changed, 126 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> index 5cf8d030a1f0..497f0d05b887 100644
> --- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
> +++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
> @@ -40,6 +40,8 @@
> #define PROC_BOOT_CFG_FLAG_R5_ATCM_EN0x2000
> /* Available from J7200 SoCs onwards */
> #define PROC_BOOT_CFG_FLAG_R5_MEM_INIT_DIS 0x4000
> +/* Applicable to only AM64x SoCs */
> +#define PROC_BOOT_CFG_FLAG_R5_SINGLE_CORE0x8000
>
> /* R5 TI-SCI Processor Control Flags */
> #define PROC_BOOT_CTRL_FLAG_R5_CORE_HALT 0x0001
> @@ -49,6 +51,8 @@
> #define PROC_BOOT_STATUS_FLAG_R5_WFI 0x0002
> #define PROC_BOOT_STATUS_FLAG_R5_CLK_GATED 0x0004
> #define PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED 0x0100
> +/* Applicable to only AM64x SoCs */
> +#define PROC_BOOT_STATUS_FLAG_R5_SINGLECORE_ONLY 0x0200
>
> /**
> * struct k3_r5_mem - internal memory structure
> @@ -64,19 +68,29 @@ struct k3_r5_mem {
> size_t size;
> };
>
> +/*
> + * All cluster mode values are not applicable on all SoCs. The following
> + * are the modes supported on various SoCs:
> + * Split mode : AM65x, J721E, J7200 and AM64x SoCs
> + * LockStep mode : AM65x, J721E and J7200 SoCs
> + * Single-CPU mode : AM64x SoCs only
> + */
> enum cluster_mode {
> CLUSTER_MODE_SPLIT = 0,
> CLUSTER_MODE_LOCKSTEP,
> + CLUSTER_MODE_SINGLECPU,
> };
>
> /**
> * struct k3_r5_soc_data - match data to handle SoC variations
> * @tcm_is_double: flag to denote the larger unified TCMs in certain modes
> * @tcm_ecc_autoinit: flag to denote the auto-initialization of TCMs for ECC
> + * @single_cpu_mode: flag to denote if SoC/IP supports Single-CPU mode
> */
> struct k3_r5_soc_data {
> bool tcm_is_double;
> bool tcm_ecc_autoinit;
> + bool single_cpu_mode;
> };
>
> /**
> @@ -369,6 +383,13 @@ static inline int k3_r5_core_run(struct k3_r5_core *core)
> * applicable cores to allow loading into the TCMs. The .prepare() ops is
> * invoked by remoteproc core before any firmware loading, and is followed
> * by the .start() ops after loading to actually let the R5 cores run.
> + *
> + * The Single-CPU mode on applicable SoCs (eg: AM64x) only uses Core0 to
> + * execute code, but combines the TCMs from both cores. The resets for both
> + * cores need to be released to make this possible, as the TCMs are in
> general
> + * private to each core. Only Core0 needs to be unhalted for running the
> + * cluster in this mode. The function uses the same reset logic as LockStep
> + * mode for this (though the behavior is agnostic of the reset release
> order).
> */
> static int k3_r5_rproc_prepare(struct rproc *rproc)
> {
> @@ -386,7 +407,9 @@ static int k3_r5_rproc_prepare(struct rproc *rproc)
> return
[PATCH 2/2] remoteproc: k3-r5: Extend support to R5F clusters on AM64x SoCs
The K3 AM64x SoC family has a revised R5F sub-system and contains a
subset of the R5F clusters present on J721E SoCs. The K3 AM64x SoCs
only have two dual-core Arm R5F clusters/subsystems with 2 R5F cores
each present within the MAIN voltage domain (MAIN_R5FSS0 & MAIN_R5FSS1).
The revised IP has the following distinct features:
1. The R5FSS IP supports a new "Single-CPU" mode instead of the LockStep
mode on existing SoCs (AM65x, J721E or J7200). This mode is similar
to LockStep-mode on J7200 SoCs in terms of TCM usage without the
fault-tolerant safety feature provided by the LockStep mode.
The Core1 TCMs are combined with the Core0 TCMs effectively doubling
the amount of TCMs available in Single-CPU mode. The LockStep-mode
on previous AM65x and J721E SoCs could only use the Core0 TCMs. These
combined TCMs appear contiguous at the respective Core0 TCM addresses.
The code though is executed only on a single CPU (on Core0), and as
such, requires the halt signal to be programmed only for Core0, while
the resets need to be managed for both the cores.
2. TCMs are auto-initialized during module power-up, and the behavior
is programmable through a MMR bit. This feature is the same as on
the recent J7200 SoCs.
Extend the support to these clusters in the K3 R5F remoteproc driver
using AM64x specific compatibles. New TI-SCI flags and a unique cluster
mode are also needed for the cluster mode detection on these SoCs. The
reset assert and deassert sequence of both the cores in Single-CPU mode
is agnostic of the order, so the same LockStep reset and release sequences
are re-used.
The integration of these clusters is very much similar to existing SoCs
otherwise.
Signed-off-by: Suman Anna
---
drivers/remoteproc/ti_k3_r5_remoteproc.c | 155 ++-
1 file changed, 126 insertions(+), 29 deletions(-)
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c
b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index 5cf8d030a1f0..497f0d05b887 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -40,6 +40,8 @@
#define PROC_BOOT_CFG_FLAG_R5_ATCM_EN 0x2000
/* Available from J7200 SoCs onwards */
#define PROC_BOOT_CFG_FLAG_R5_MEM_INIT_DIS 0x4000
+/* Applicable to only AM64x SoCs */
+#define PROC_BOOT_CFG_FLAG_R5_SINGLE_CORE 0x8000
/* R5 TI-SCI Processor Control Flags */
#define PROC_BOOT_CTRL_FLAG_R5_CORE_HALT 0x0001
@@ -49,6 +51,8 @@
#define PROC_BOOT_STATUS_FLAG_R5_WFI 0x0002
#define PROC_BOOT_STATUS_FLAG_R5_CLK_GATED 0x0004
#define PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED0x0100
+/* Applicable to only AM64x SoCs */
+#define PROC_BOOT_STATUS_FLAG_R5_SINGLECORE_ONLY 0x0200
/**
* struct k3_r5_mem - internal memory structure
@@ -64,19 +68,29 @@ struct k3_r5_mem {
size_t size;
};
+/*
+ * All cluster mode values are not applicable on all SoCs. The following
+ * are the modes supported on various SoCs:
+ * Split mode : AM65x, J721E, J7200 and AM64x SoCs
+ * LockStep mode : AM65x, J721E and J7200 SoCs
+ * Single-CPU mode : AM64x SoCs only
+ */
enum cluster_mode {
CLUSTER_MODE_SPLIT = 0,
CLUSTER_MODE_LOCKSTEP,
+ CLUSTER_MODE_SINGLECPU,
};
/**
* struct k3_r5_soc_data - match data to handle SoC variations
* @tcm_is_double: flag to denote the larger unified TCMs in certain modes
* @tcm_ecc_autoinit: flag to denote the auto-initialization of TCMs for ECC
+ * @single_cpu_mode: flag to denote if SoC/IP supports Single-CPU mode
*/
struct k3_r5_soc_data {
bool tcm_is_double;
bool tcm_ecc_autoinit;
+ bool single_cpu_mode;
};
/**
@@ -369,6 +383,13 @@ static inline int k3_r5_core_run(struct k3_r5_core *core)
* applicable cores to allow loading into the TCMs. The .prepare() ops is
* invoked by remoteproc core before any firmware loading, and is followed
* by the .start() ops after loading to actually let the R5 cores run.
+ *
+ * The Single-CPU mode on applicable SoCs (eg: AM64x) only uses Core0 to
+ * execute code, but combines the TCMs from both cores. The resets for both
+ * cores need to be released to make this possible, as the TCMs are in general
+ * private to each core. Only Core0 needs to be unhalted for running the
+ * cluster in this mode. The function uses the same reset logic as LockStep
+ * mode for this (though the behavior is agnostic of the reset release order).
*/
static int k3_r5_rproc_prepare(struct rproc *rproc)
{
@@ -386,7 +407,9 @@ static int k3_r5_rproc_prepare(struct rproc *rproc)
return ret;
mem_init_dis = !!(cfg & PROC_BOOT_CFG_FLAG_R5_MEM_INIT_DIS);
- ret = (cluster->mode == CLUSTER_MODE_LOCKSTEP) ?
+ /* Re-use LockStep-mode reset logic for Single-CPU mode */
+ ret = (cluster->mode == CLUSTER_MODE_LOCKSTEP ||
+
