On 6/1/23 14:56, Arnaud POULIQUEN wrote:
Hi,
[...]
I assume that if the firmware does not use the detach mailbox, then the
detach mailbox is just ignored and unused, so there is no problem with
having it described in the DT in any case ?
Yes, The aim of the ST evaluation board is to provide a DT to a support
different firmwares for demo and tests. But it is not the case of all boards...
If your boards provide demo using the "detach" it is justified.
If you just add it as a workaround to mask the warnings, you just mask the issue.
Then it seems there is no issue with the boards modified here, because
as far as I can tell, those are all general purpose SoMs and evaluation
boards. With such systems, you cannot predict what the user would like
to use those for, that could include whatever ST demo.
And if that's the case, then I would much rather prefer to have all the boards
describe the same set of mailboxes, so they don't diverge . What do you
think ?
I would avoid this. It is only a configuration by default for current demo.
That current demo is restricted to ST produced boards only, or can it
also be run on development kits manufactured by other vendors ? I think
it is the later, and I don't see why those should be kept out.
The allocation depends on the firmware loaded on M4, so depend on the project.
For instance, a work has started in OpenAMP community to implement the vIrtio Services
For the IPC. Each virtio services would be associated to one or several mailbox
Channels. In this case we would need to arbitrate allocations.
The result could be that we propose a virtio channel for rpmsg + some other virtio.
More than that we probably manage the mailboxes in sub node
Here is an RFC on the topic (https://lore.kernel.org/lkml/20220920202201.GB1042164@p14s/)
That said, fixing rpmsg virqueue and the shutdown mailboxes in the SoC dtsi, seems reasonable as it
provides the default expected implementation.
Do the same for the detach that is optional and mainly unused, I'm not fan.
Adding the detach mailbox in the DT to mask a warning issue, I'm rather against it
Removal of divergence.
Rather than adding unused optional mailbox, I will more in favor of
having a mbox_request_channel_byname_optional helper or something
similar
See above, I think it is better to have the mailbox described in DT always and
not use it (the user can always remove it), than to not have it described on
some boards and have it described on other boards (inconsistency).
Adding it in the DT ( and especially in the Soc DTSI) can also be interpreted as
"it is defined so you must use it". I would expect that the Bindings already provide
the information to help user to add it on need.
Why should every single board add it separately and duplicate the same
stuff, if they can all start with it, and if anyone needs to tweak the
mailbox allocation, then they can do that in the board DT ? I really
don't like the duplication suggestion here.
