[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DU0PR04MB94170F02CF6BD02D7869A75388389@DU0PR04MB9417.eurprd04.prod.outlook.com>
Date: Thu, 3 Nov 2022 05:08:15 +0000
From: Peng Fan <peng.fan@....com>
To: Mathieu Poirier <mathieu.poirier@...aro.org>,
"Peng Fan (OSS)" <peng.fan@....nxp.com>
CC: "andersson@...nel.org" <andersson@...nel.org>,
"shawnguo@...nel.org" <shawnguo@...nel.org>,
"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
"robh+dt@...nel.org" <robh+dt@...nel.org>,
"krzysztof.kozlowski+dt@...aro.org"
<krzysztof.kozlowski+dt@...aro.org>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
"festevam@...il.com" <festevam@...il.com>,
dl-linux-imx <linux-imx@....com>,
"linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: RE: [PATCH V2 0/2] remoteproc: imx: add start up delay
> Subject: Re: [PATCH V2 0/2] remoteproc: imx: add start up delay
>
> On Wed, 2 Nov 2022 at 05:23, Peng Fan (OSS) <peng.fan@....nxp.com>
> wrote:
> >
> > From: Peng Fan <peng.fan@....com>
> >
> > V2:
> > Rebased on linux-next
> >
> > V1:
> >
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Flkml%2F20220609123500.3492475-1-
> peng.fan%40oss.nxp.com%2
> >
> F&data=05%7C01%7Cpeng.fan%40nxp.com%7Cf14584bdef9349e744ca
> 08dabcf7
> >
> e1be%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63803007007
> 2451509%7
> >
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTiI6Ik1
> >
> haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ck73gkOPpNVT
> kcZL8olCZP8B
> > %2BrIpZHV48uZBl2R8HdM%3D&reserved=0
> >
> > 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.
> >
> > The best case is to use a method to let M4 notify Linux that M4 has
> > finished initialization, but we could not patch released firmware,
> > then update driver to detect notification.
> >
> > So add delay before linux send out vring kick message. It is not good
> > to use a fixed time delay in driver, so I choose to get that from
> > device tree.
> >
>
> From where I stand this is a hack to hide the lack of motivation to enact the
> real solution that is outlined above. I also wonder how these problems
> were not caught during the testing phase. Either find a way to upgrade your
> firmware or keep this in your internal tree.
In the beginning, i.mx not migrated to use remoteproc, i.MX release only support
uboot kick Cortex-M core and use downstream imx_rpmsg driver to
communicate with remote core. There is no runtime stop/start.
After migrated to remoteproc, we do see some issue, but old firmware was
there.
Thanks,
Peng.
>
> > Peng Fan (2):
> > dt-bindings: remoteproc: imx_rproc: add fsl,startup-delay-ms
> > remoteproc: imx_rproc: delay after kick remote processor
> >
> > .../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 4 ++++
> > drivers/remoteproc/imx_rproc.c | 9 +++++++++
> > 2 files changed, 13 insertions(+)
> >
> > --
> > 2.37.1
> >
Powered by blists - more mailing lists