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://lore.kernel.org/lkml/20220609123500.3492475-1-peng.fan@xxxxxxxxxxx/ > > 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. > 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 >
