Re: [PATCH 2/2] remoteproc: imx_rproc: add start up delay

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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 <>

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 <>
Signed-off-by: Peng Fan <>
Note: picked from NXP downstream LF-6630-2 remoteproc: imx_rproc: add start up delay 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().

[Index of Archives]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux