Re: Discussion about imx_dsp_rproc FW_READY policy

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


Hi Mathieu, S.J,

Any comments about this?

I feel that the Linux kernel driver shouldn't enforce the policy of
waiting for a reply or confirmation that the firmware booted.

The Linux kernel driver should offer a mechanism for checking this and
the policy should be set either in userspace or via dts.

First option would be to have an ioctl but we need to also mirror this
in the sysfs interface. Second option would be to have a property in
the dts.

What do you think?

We are trying to fix this in the firmware side:

but we are getting some setbacks there too.


On Wed, Jul 26, 2023 at 11:26 AM Daniel Baluta <daniel.baluta@xxxxxxxxx> wrote:
> Hello all,
> I want to start this thread in order to clarify what assumptions a
> remoteproc driver is able to make
> about a firmware loaded on a remote processor.
> Discussion is generated by this thread:
> [1]
> imx_dsp_rproc driver assumes that the remote firmware will send a
> notification once it has booted up and this is the default behavior.
> This doesn't work well with Zephyr samples which do not send such notification!
> I want to get an agreement for the following questions:
> 1) What should be the default behavior of a remote proc driver?
> In my opinion it should not make any assumption about the remote part.
> Thus by default the driver should not wait for any message!
> 2) How can we support various "protocols" of starting up. Eg (wait for
> firmware / no wait for firmware).
> In patch [1] Iulia proposed to add a flag that will select the correct
> behavior. As per Mathieu's comments this doesn't
> scale up, for next flags.
> How can we solve this? In my opinion using a kernel module parameter
> OR a device tree property should be enough.
> What do you think?
> thanks,
> Daniel.

[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