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

[Marek Vasut]

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