[drive-by observation since one thing caught my interest...]
On 2022-08-09 00:38, Elliot Berman wrote:
I might be completely wrong about this, but if my in-mind picture of
Gunyah is correct, I'd have implemented the gunyah core subsytem as
mailbox provider, RM as a separate platform driver consuming these
mailboxes and in turn being a remoteproc driver, and consoles as
remoteproc subdevices. >
The mailbox framework can only fit with message queues and not doorbells
or vCPUs.
Is that so? There was a whole long drawn-out saga around the SCMI
protocol using the Arm MHU mailbox as a set of doorbells for
shared-memory payloads, but it did eventually get merged as the separate
arm_mhu_db.c driver, so unless we're talking about some completely
different notion of "doorbell"... :/
The mailbox framework also relies on the mailbox being defined
in the devicetree. RM is an exceptional case in that it is described in
the devicetree. Message queues for other VMs would be dynamically
created at runtime as/when that VM is created. Thus, the client of the
message queue would need to "own" both the controller and client ends of
the mailbox.
FWIW, if the mailbox API does fit conceptually then it looks like it
shouldn't be *too* hard to better abstract the DT details in the
framework itself and allow providers to offer additional means to
validate channel requests, which might be more productive than inventing
a whole new thing.
Thanks,
Robin.
