diff mbox series

[2/2] remoteproc: imx_rproc: add start up delay

Message ID 20230707232444.374431-2-marex@denx.de
State New
Headers show
Series [1/2] dt-bindings: remoteproc: imx_rproc: Support i.MX8MN/P MMIO | expand

Commit Message

Marek Vasut July 7, 2023, 11:24 p.m. UTC 
From: Peng Fan <peng.fan@nxp.com>

There is case that after remoteproc start remote processor[M4], the M4
runs slow and before M4 finish its own rpmsg framework initialization,
linux sends out vring kick message, then M4 firmware drops the kick
message. Some NXP released Cortex-M[x] images has such limitation that
it requires linux sends out vring kick message after M4 firmware finish
its rpmsg framework initialization.

Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
Note: picked from NXP downstream LF-6630-2 remoteproc: imx_rproc: add start up delay
https://github.com/nxp-imx/linux-imx.git 0b1b91c95b291a3b60d6224b13f6a95a75896abf
---
Note: Literally all of the NXP BSP 2.13.0 firmware builds fail to boot
      without this being set to something like 50..500 ms , so this is
      rather useful to have.
---
Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: NXP Linux Team <linux-imx@nxp.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-remoteproc@vger.kernel.org
---
 drivers/remoteproc/imx_rproc.c | 9 +++++++++
 1 file changed, 9 insertions(+)

Comments

Marek Vasut July 10, 2023, 4:31 p.m. UTC | #1 
On 7/10/23 17:53, Mathieu Poirier wrote:
> On Sat, Jul 08, 2023 at 01:24:44AM +0200, Marek Vasut wrote:
>> From: Peng Fan <peng.fan@nxp.com>
>>
>> There is case that after remoteproc start remote processor[M4], the M4
>> runs slow and before M4 finish its own rpmsg framework initialization,
>> linux sends out vring kick message, then M4 firmware drops the kick
>> message. Some NXP released Cortex-M[x] images has such limitation that
>> it requires linux sends out vring kick message after M4 firmware finish
>> its rpmsg framework initialization.
>>
>> Reviewed-by: Jacky Bai <ping.bai@nxp.com>
>> Reviewed-by: Ye Li <ye.li@nxp.com>
>> Signed-off-by: Peng Fan <peng.fan@nxp.com>
>> ---
>> Note: picked from NXP downstream LF-6630-2 remoteproc: imx_rproc: add start up delay
>> https://github.com/nxp-imx/linux-imx.git 0b1b91c95b291a3b60d6224b13f6a95a75896abf
>> ---
>> Note: Literally all of the NXP BSP 2.13.0 firmware builds fail to boot
>>        without this being set to something like 50..500 ms , so this is
>>        rather useful to have.
> 
> My stance on this hasn't changed - hacks such as these do not scale and are a
> nightmare to maintain.  The problem should be fixed in the M4's firmware.

If the firmware cannot be updated, how do you propose that would be 
fixed in the firmware ?

Frankly, I do not see much of an issue in maintaining driver-specific 
mdelay().
diff mbox series

Patch

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index f9874fc5a80ff..d0eb96d6a4fe1 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -6,6 +6,7 @@ 
 #include <dt-bindings/firmware/imx/rsrc.h>
 #include <linux/arm-smccc.h>
 #include <linux/clk.h>
+#include <linux/delay.h>
 #include <linux/err.h>
 #include <linux/firmware/imx/sci.h>
 #include <linux/interrupt.h>
@@ -110,6 +111,7 @@  struct imx_rproc {
 	u32				core_index;
 	struct device                   **pd_dev;
 	struct device_link              **pd_dev_link;
+	u32				startup_delay;
 };
 
 static const struct imx_rproc_att imx_rproc_att_imx93[] = {
@@ -382,6 +384,9 @@  static int imx_rproc_start(struct rproc *rproc)
 	if (ret)
 		dev_err(dev, "Failed to enable remote core!\n");
 
+	if (priv->startup_delay)
+		msleep(priv->startup_delay);
+
 	return ret;
 }
 
@@ -1090,6 +1095,10 @@  static int imx_rproc_probe(struct platform_device *pdev)
 	if (rproc->state != RPROC_DETACHED)
 		rproc->auto_boot = of_property_read_bool(np, "fsl,auto-boot");
 
+	ret = of_property_read_u32(dev->of_node, "fsl,startup-delay-ms", &priv->startup_delay);
+	if (ret)
+		priv->startup_delay = 0;
+
 	ret = rproc_add(rproc);
 	if (ret) {
 		dev_err(dev, "rproc_add failed\n");