On Thu, Nov 03, 2022 at 05:08:15AM +0000, Peng Fan wrote: > > 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@xxxxxxxxxxx> > > wrote: > > > > > > From: Peng Fan <peng.fan@xxxxxxx> > > > > > > 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. You could also attach() to that remote processor, if the HW supports it. But my position remains the same - either find a way to work with this situation that is not a hack or keep this patch in your internal tree. > > 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 > > >
