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@xxxxxxx>
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@xxxxxxx>
Reviewed-by: Ye Li <ye.li@xxxxxxx>
Signed-off-by: Peng Fan <peng.fan@xxxxxxx>
---
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().
