Hi Cezary,
On Sat, Aug 17, 2019 at 6:22 PM Cezary Rojewski cezary.rojewski@intel.com wrote:
On 2019-08-15 17:44, Pierre-Louis Bossart wrote:
From: Daniel Baluta daniel.baluta@nxp.com
Add support for the audio DSP hardware found on NXP i.MX8 platform.
Signed-off-by: Daniel Baluta daniel.baluta@nxp.com Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com +static void imx8_get_reply(struct snd_sof_dev *sdev) +{
struct snd_sof_ipc_msg *msg = sdev->msg;
struct sof_ipc_reply reply;
int ret = 0;
if (!msg) {
dev_warn(sdev->dev, "unexpected ipc interrupt\n");
return;
}
/* get reply */
sof_mailbox_read(sdev, sdev->host_box.offset, &reply, sizeof(reply));
if (reply.error < 0) {
memcpy(msg->reply_data, &reply, sizeof(reply));
ret = reply.error;
} else {
/* reply has correct size? */
if (reply.hdr.size != msg->reply_size) {
dev_err(sdev->dev, "error: reply expected %zu got %u bytes\n",
msg->reply_size, reply.hdr.size);
ret = -EINVAL;
}
/* read the message */
if (msg->reply_size > 0)
sof_mailbox_read(sdev, sdev->host_box.offset,
msg->reply_data, msg->reply_size);
}
msg->reply_error = ret;
+}
Assuming reply.hdr.size is coming from HW IPC regs, msg object is representing application side - SW, kernel. If so, is msg->reply_size value an estimated size (which can be overestimated since exact size may be unknown by the host) -or- the exact size of incoming IPC reply?
I would say msg->reply_size is the exact size of incoming IPC. At least for this example:
Look at sound/soc/sof/pcm.c
sof_pcm_trigger
-> sof_ipc_tx_message(..,..,&reply, sizeof(reply))
msg->reply_size = sizeof(reply).
On the firmware side:
https://github.com/thesofproject/sof/blob/master/src/ipc/handler.c#L912 reply.rhdr.hdr.size = sizeof(reply);
The estimated-case is usually permissive as long as assumed size is >= reply.hdr.size - dev_err needed. In the exact-case, it should be viewed as a requirement. If such "requirement" fails, is it valid to read mailbox regardless? Is this to extract some error-debug payload sent by FW?
Just curious, please feel free to correct me here, Pierre.
If you think an improvement can be done, please send a patch :).
thanks, Daniel.