| Message ID | 20230707232444.374431-2-marex@denx.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] dt-bindings: remoteproc: imx_rproc: Document fsl,startup-delay-ms | expand |
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. > --- > 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(+) > > 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"); > -- > 2.40.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 --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");