I have few things to bring into discussion now, perhaps you can comment on it.
Firstly, we might want to look at the mailbox controller (drivers/mailbox/mailbox.c). It looks like the communication from AP (application processor) and the DSP uses shim + mailbox in Intel implementation, which could be abstracted by a mailbox client.
The confusing part here is the naming. In the Linux kernel the shim layer you use is abstracted by the mailbox controller, while mailbox from Intel implementation is really a shared memory area.
We have this already implemented for our mailbox (Messaging Unit) in drivers/mailbox/imx-mailbox.c and trying to integrate with SOF.
So, for IPC we have the following "naming" differences:
- imx mailbox MU - equivalent with SHIM layer from Intel SOF.
- imx shared memory - equivalent with mailbox layer from Intel SOF.
the "shim" on the intel side is a mix of control capabilities. There are indeed IPC registers in there, but also clock, DMA and power control capabilities. I am not sure we can really remove direct access to the shim, it's really the host-visible set of DSP registers.
We'll look at the pointer to the i.mx mailbox, thanks for the information.
Secondly, the "doorbell" naming of the interrupts. It surely looks like a doorbell because we notify the DSP that we pushed some data in a shared memory area. Anyhow, besides pushing data to the shared memory area we also send some data with the notification too.
For example, in byt_send_msg we do:
sof_mailbox_write(sdev, sdev->host_box.offset, msg->msg_data, msg->msg_size); snd_sof_dsp_write64(sdev, BYT_DSP_BAR, SHIM_IPCX, cmd | SHIM_BYT_IPCX_BUSY);
Not sure how cmd is used on the DSP side. Anyhow, this is not really important for the next version of the patches. Just wanted to hear your opinion.
Humm, that one looks like an exception as well, it makes no sense. This is over a year old. Liam, any memories of this?