From: Devarsh Thakkar <devarsht@ti.com>
To: <andersson@kernel.org>, <devicetree@vger.kernel.org>,
<mathieu.poirier@linaro.org>, <p.zabel@pengutronix.de>,
<linux-remoteproc@vger.kernel.org>, <robh+dt@kernel.org>,
<linux-kernel@vger.kernel.org>,
<krzysztof.kozlowski+dt@linaro.org>, <s-anna@ti.com>
Cc: <hnagalla@ti.com>, <praneeth@ti.com>, <nm@ti.com>,
<vigneshr@ti.com>, <a-bhatia1@ti.com>, <j-luthra@ti.com>,
<devarsht@ti.com>, <rogerq@kernel.org>
Subject: [PATCH v7 1/3] remoteproc: k3-r5: Simplify cluster mode setting usage
Date: Fri, 10 Mar 2023 21:55:42 +0530 [thread overview]
Message-ID: <20230310162544.3468365-2-devarsht@ti.com> (raw)
In-Reply-To: <20230310162544.3468365-1-devarsht@ti.com>
Check the validity of mode against SoC supported modes right
at the probe to minimize the usage of same check further in the code.
Set default value of cluster-mode only if cluster-mode device tree property
is empty.
In case devicetree provided cluster-mode property is invalid For e.g. using
CLUSTER_MODE_SINGLECPU on any SoC other than am64x then return error.
If firmware has set the PROC_BOOT_STATUS_FLAG_R5_SINGLECORE_ONLY flag then
what it means is that only CLUSTER_MODE_SINGLECPU is possible to use [1]
and hence there is no need to check for soc_data->single_cpu_mode first and
then checking cluster mode.
PROC_BOOT_CFG_FLAG_R5_SINGLE_CORE flag can be set directly for
CLUSTER_MODE_SINGLECPU without checking for soc_data->single_cpu_mode since
that check has already been done during probe.
Link:
[1] https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/PROC_BOOT.html?highlight=singlecore_only#arm-r5
Signed-off-by: Devarsh Thakkar <devarsht@ti.com>
---
V1->V6: No changelog (Patch introduced in V6)
V6->V7:
- Override to appropriate cluster mode per firmware status flag directly
without checking for soc_data
- Set appropriate mode as default if not provided in DT
- Check mode validity against SoC data during probe
- Rebase on top of 6.3 linux-next
---
drivers/remoteproc/ti_k3_r5_remoteproc.c | 57 +++++++++++++-----------
1 file changed, 30 insertions(+), 27 deletions(-)
diff --git a/drivers/remoteproc/ti_k3_r5_remoteproc.c b/drivers/remoteproc/ti_k3_r5_remoteproc.c
index 0481926c6975..c2ec0f432921 100644
--- a/drivers/remoteproc/ti_k3_r5_remoteproc.c
+++ b/drivers/remoteproc/ti_k3_r5_remoteproc.c
@@ -852,38 +852,33 @@ static int k3_r5_rproc_configure(struct k3_r5_rproc *kproc)
dev_dbg(dev, "boot_vector = 0x%llx, cfg = 0x%x ctrl = 0x%x stat = 0x%x\n",
boot_vec, cfg, ctrl, stat);
- /* check if only Single-CPU mode is supported on applicable SoCs */
- if (cluster->soc_data->single_cpu_mode) {
- single_cpu =
- !!(stat & PROC_BOOT_STATUS_FLAG_R5_SINGLECORE_ONLY);
- if (single_cpu && cluster->mode == CLUSTER_MODE_SPLIT) {
- dev_err(cluster->dev, "split-mode not permitted, force configuring for single-cpu mode\n");
- cluster->mode = CLUSTER_MODE_SINGLECPU;
- }
- goto config;
+ single_cpu = !!(stat & PROC_BOOT_STATUS_FLAG_R5_SINGLECORE_ONLY);
+ lockstep_en = !!(stat & PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED);
+
+ /* Override to single CPU mode if set in status flag */
+ if (single_cpu && cluster->mode == CLUSTER_MODE_SPLIT) {
+ dev_err(cluster->dev, "split-mode not permitted, force configuring for single-cpu mode\n");
+ cluster->mode = CLUSTER_MODE_SINGLECPU;
}
- /* check conventional LockStep vs Split mode configuration */
- lockstep_en = !!(stat & PROC_BOOT_STATUS_FLAG_R5_LOCKSTEP_PERMITTED);
+ /* Override to split mode if lockstep enable bit is not set in status flag */
if (!lockstep_en && cluster->mode == CLUSTER_MODE_LOCKSTEP) {
dev_err(cluster->dev, "lockstep mode not permitted, force configuring for split-mode\n");
cluster->mode = CLUSTER_MODE_SPLIT;
}
-config:
/* always enable ARM mode and set boot vector to 0 */
boot_vec = 0x0;
if (core == core0) {
clr_cfg = PROC_BOOT_CFG_FLAG_R5_TEINIT;
- if (cluster->soc_data->single_cpu_mode) {
- /*
- * Single-CPU configuration bit can only be configured
- * on Core0 and system firmware will NACK any requests
- * with the bit configured, so program it only on
- * permitted cores
- */
- if (cluster->mode == CLUSTER_MODE_SINGLECPU)
- set_cfg = PROC_BOOT_CFG_FLAG_R5_SINGLE_CORE;
+ /*
+ * Single-CPU configuration bit can only be configured
+ * on Core0 and system firmware will NACK any requests
+ * with the bit configured, so program it only on
+ * permitted cores
+ */
+ if (cluster->mode == CLUSTER_MODE_SINGLECPU) {
+ set_cfg = PROC_BOOT_CFG_FLAG_R5_SINGLE_CORE;
} else {
/*
* LockStep configuration bit is Read-only on Split-mode
@@ -1700,12 +1695,6 @@ static int k3_r5_probe(struct platform_device *pdev)
return -ENOMEM;
cluster->dev = dev;
- /*
- * default to most common efuse configurations - Split-mode on AM64x
- * and LockStep-mode on all others
- */
- cluster->mode = data->single_cpu_mode ?
- CLUSTER_MODE_SPLIT : CLUSTER_MODE_LOCKSTEP;
cluster->soc_data = data;
INIT_LIST_HEAD(&cluster->cores);
@@ -1716,6 +1705,20 @@ static int k3_r5_probe(struct platform_device *pdev)
return ret;
}
+ if (ret == -EINVAL) {
+ /*
+ * default to most common efuse configurations - Split-mode on AM64x
+ * and LockStep-mode on all others
+ */
+ cluster->mode = data->single_cpu_mode ?
+ CLUSTER_MODE_SPLIT : CLUSTER_MODE_LOCKSTEP;
+ }
+
+ if (cluster->mode == CLUSTER_MODE_SINGLECPU && !data->single_cpu_mode) {
+ dev_err(dev, "Cluster mode = %d is not supported on this SoC\n", cluster->mode);
+ return -EINVAL;
+ }
+
num_cores = of_get_available_child_count(np);
if (num_cores != 2) {
dev_err(dev, "MCU cluster requires both R5F cores to be enabled, num_cores = %d\n",
--
2.34.1
next prev parent reply other threads:[~2023-03-10 16:29 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-10 16:25 [PATCH v7 0/3] Add single core R5F IPC for AM62 SoC family Devarsh Thakkar
2023-03-10 16:25 ` Devarsh Thakkar [this message]
2023-03-10 16:25 ` [PATCH v7 2/3] dt-bindings: remoteproc: ti: Add new compatible " Devarsh Thakkar
2023-03-14 20:08 ` Krzysztof Kozlowski
2023-03-10 16:25 ` [PATCH v7 3/3] remoteproc: k3-r5: Use separate compatible string for TI AM62x " Devarsh Thakkar
2023-03-17 16:17 ` Mathieu Poirier
2023-03-27 15:24 ` Devarsh Thakkar
2023-03-28 7:52 ` Roger Quadros
2023-03-28 16:08 ` Devarsh Thakkar
2023-03-29 8:21 ` Roger Quadros
2023-03-29 13:15 ` Devarsh Thakkar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230310162544.3468365-2-devarsht@ti.com \
--to=devarsht@ti.com \
--cc=a-bhatia1@ti.com \
--cc=andersson@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hnagalla@ti.com \
--cc=j-luthra@ti.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=nm@ti.com \
--cc=p.zabel@pengutronix.de \
--cc=praneeth@ti.com \
--cc=robh+dt@kernel.org \
--cc=rogerq@kernel.org \
--cc=s-anna@ti.com \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox