From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, andriy.shevchenko@intel.com,
tiwai@suse.de, Daniel Baluta <daniel.baluta@gmail.com>,
liam.r.girdwood@linux.intel.com, vkoul@kernel.org,
Alan Cox <alan@linux.intel.com>,
sound-open-firmware@alsa-project.org
Subject: Re: [PATCH v3 04/14] ASoC: SOF: Add support for IPC IO between DSP and Host
Date: Thu, 10 Jan 2019 14:11:32 -0600 [thread overview]
Message-ID: <876df209-c829-873e-047e-c73fb0579d68@linux.intel.com> (raw)
In-Reply-To: <20190109203720.GQ10405@sirena.org.uk>
[consolidated answers from Liam and me]
>> +/* wait for IPC message reply */
>> +static int tx_wait_done(struct snd_sof_ipc *ipc, struct snd_sof_ipc_msg *msg,
>> + void *reply_data)
>> +{
> This has exactly one caller, why not inline it (or make both tx and rx
> separate functions)?
we'll look into it.
>
>> + spin_lock_irqsave(&sdev->ipc_lock, flags);
>> +
>> + /* get an empty message */
>> + msg = msg_get_empty(ipc);
>> + if (!msg) {
>> + spin_unlock_irqrestore(&sdev->ipc_lock, flags);
>> + return -EBUSY;
>> + }
>> +
>> + msg->header = header;
>> + msg->msg_size = msg_bytes;
>> + msg->reply_size = reply_bytes;
>> + msg->ipc_complete = false;
>> +
>> + /* attach any data */
>> + if (msg_bytes)
>> + memcpy(msg->msg_data, msg_data, msg_bytes);
> How big do these messages get? Do we need to hold the lock while we
> memcpy()?
Messages can be as big as the mailbox, which is hardware dependent. It
could be from a few bytes to a larger e.g. 4k page or more, and indeed
we need to keep the lock.
>
>> + /* schedule the message if not busy */
>> + if (snd_sof_dsp_is_ready(sdev))
>> + schedule_work(&ipc->tx_kwork);
> If the DSP is idle is there a reason this has to happen in another
> thread?
we will rename this as snd_sof_dsp_is_ipc_ready() to avoid any confusion
with the DSP state. We only care about IPC registers/doorbells at this
point, not the fact that the DSP is in its idle loop.
>
>> +
>> + spin_unlock_irqrestore(&sdev->ipc_lock, flags);
> The thread is also going to take an irq spinlock after all.
didn't get this point, sorry.
>
>> + /* send first message in TX list */
>> + msg = list_first_entry(&ipc->tx_list, struct snd_sof_ipc_msg, list);
>> + list_move(&msg->list, &ipc->reply_list);
>> + snd_sof_dsp_send_msg(sdev, msg);
> Should the move happen if the send fails (I see it can return an error
> code, though we ignore it)?
so far neither the HDaudio nor the BYT stuff return an error on
send_msg, so we'll need to thing about what happens should this happen
with other hardware, or demote the status to void.
We'll look into this.
>
>> + int err = -EINVAL;
>> + case SOF_IPC_FW_READY:
>> + /* check for FW boot completion */
>> + if (!sdev->boot_complete) {
>> + if (sdev->ops->fw_ready)
>> + err = sdev->ops->fw_ready(sdev, cmd);
>> + if (err < 0) {
>> + dev_err(sdev->dev, "error: DSP firmware boot timeout %d\n",
>> + err);
> err defaults to -EINVAL here which doesn't seem like the right thing if
> fw_ready() is really optional. Perhaps just validate the ops on
> registration and call this unconditionally?
Good catch, err should default to 0, thanks for pointing this out.
>
>> +void snd_sof_ipc_free(struct snd_sof_dev *sdev)
>> +{
>> + cancel_work_sync(&sdev->ipc->tx_kwork);
>> + cancel_work_sync(&sdev->ipc->rx_kwork);
>> +}
>> +EXPORT_SYMBOL(snd_sof_ipc_free);
> It might be better to have something that stops any new messages being
> processed as well, to prevent races on removal.
ok, we will add something to stop the IPC, good suggestion indeed.
next prev parent reply other threads:[~2019-01-10 20:11 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-11 21:23 [PATCH v3 00/14] Sound Open Firmware (SOF) core Pierre-Louis Bossart
2018-12-11 21:23 ` [PATCH v3 01/14] ASoC: SOF: Add Sound Open Firmware driver core Pierre-Louis Bossart
2018-12-11 22:20 ` Andy Shevchenko
2018-12-11 23:20 ` Pierre-Louis Bossart
2018-12-12 7:51 ` Takashi Iwai
2018-12-12 14:53 ` Pierre-Louis Bossart
2018-12-12 20:42 ` Daniel Baluta
2018-12-12 22:35 ` Pierre-Louis Bossart
2019-01-29 16:49 ` Daniel Baluta
2019-01-30 16:12 ` Pierre-Louis Bossart
2018-12-11 21:23 ` [PATCH v3 02/14] ASoC: SOF: Add Sound Open Firmware KControl support Pierre-Louis Bossart
2018-12-11 22:23 ` Andy Shevchenko
2018-12-11 22:48 ` Pierre-Louis Bossart
2018-12-11 23:25 ` Andy Shevchenko
2018-12-12 20:18 ` Pierre-Louis Bossart
2018-12-12 7:35 ` Takashi Iwai
2018-12-12 15:01 ` Pierre-Louis Bossart
2018-12-11 21:23 ` [PATCH v3 03/14] ASoC: SOF: Add driver debug support Pierre-Louis Bossart
2018-12-11 22:32 ` Andy Shevchenko
2018-12-11 23:29 ` Pierre-Louis Bossart
2019-01-09 19:40 ` Mark Brown
2019-01-10 20:47 ` Pierre-Louis Bossart
2018-12-11 21:23 ` [PATCH v3 04/14] ASoC: SOF: Add support for IPC IO between DSP and Host Pierre-Louis Bossart
2018-12-11 22:57 ` Andy Shevchenko
2018-12-11 23:38 ` Pierre-Louis Bossart
2018-12-12 8:17 ` Takashi Iwai
2018-12-12 15:19 ` Pierre-Louis Bossart
2018-12-12 15:34 ` Takashi Iwai
2018-12-13 5:24 ` Keyon Jie
2018-12-13 7:48 ` Takashi Iwai
2018-12-13 9:13 ` Keyon Jie
2018-12-13 8:06 ` Keyon Jie
2018-12-13 8:59 ` rander.wang
2019-01-09 20:37 ` Mark Brown
2019-01-10 20:11 ` Pierre-Louis Bossart [this message]
2019-01-22 19:04 ` Mark Brown
2019-01-22 21:05 ` Pierre-Louis Bossart
2019-01-22 21:13 ` Mark Brown
2019-01-23 5:51 ` [Sound-open-firmware] " Keyon Jie
2019-01-14 15:10 ` Daniel Baluta
2019-01-14 17:39 ` Pierre-Louis Bossart
2018-12-11 21:23 ` [PATCH v3 05/14] ASoC: SOF: Add PCM operations support Pierre-Louis Bossart
2018-12-12 8:04 ` Takashi Iwai
2018-12-12 13:12 ` Andy Shevchenko
2018-12-12 15:29 ` [Sound-open-firmware] " Pierre-Louis Bossart
2018-12-12 15:43 ` Takashi Iwai
2018-12-12 16:10 ` Pierre-Louis Bossart
2018-12-12 22:09 ` Daniel Baluta
2018-12-11 21:23 ` [PATCH v3 06/14] ASoC: SOF: Add support for loading topologies Pierre-Louis Bossart
2018-12-11 21:23 ` [PATCH v3 07/14] ASoC: SOF: Add DSP firmware logger support Pierre-Louis Bossart
2018-12-11 23:21 ` Andy Shevchenko
2018-12-11 23:43 ` Pierre-Louis Bossart
2018-12-12 6:44 ` Takashi Iwai
2018-12-12 11:11 ` Takashi Iwai
2018-12-12 16:04 ` [Sound-open-firmware] " Pierre-Louis Bossart
2018-12-12 16:12 ` Takashi Iwai
2018-12-12 17:01 ` Pierre-Louis Bossart
2019-01-09 20:44 ` Mark Brown
2019-01-09 21:39 ` Pierre-Louis Bossart
2019-01-22 18:57 ` Mark Brown
2019-01-22 20:33 ` Pierre-Louis Bossart
2019-01-22 20:41 ` Mark Brown
2019-01-22 20:52 ` Pierre-Louis Bossart
2019-01-22 21:08 ` Mark Brown
2019-01-22 21:13 ` Pierre-Louis Bossart
2018-12-11 21:23 ` [PATCH v3 08/14] ASoC: SOF: Add DSP HW abstraction operations Pierre-Louis Bossart
2018-12-11 23:16 ` Andy Shevchenko
2018-12-11 23:45 ` Pierre-Louis Bossart
2019-01-09 20:51 ` Mark Brown
2019-01-09 21:37 ` Pierre-Louis Bossart
2019-01-22 18:56 ` Mark Brown
2018-12-11 21:23 ` [PATCH v3 09/14] ASoC: SOF: Add firmware loader support Pierre-Louis Bossart
2018-12-11 22:38 ` Andy Shevchenko
2018-12-11 23:54 ` Pierre-Louis Bossart
2019-01-09 20:55 ` Mark Brown
2018-12-12 11:23 ` Takashi Iwai
2018-12-12 16:06 ` [Sound-open-firmware] " Pierre-Louis Bossart
2019-01-09 21:02 ` Mark Brown
2019-01-09 21:24 ` Pierre-Louis Bossart
2018-12-11 21:23 ` [PATCH v3 10/14] ASoC: SOF: Add userspace ABI support Pierre-Louis Bossart
2018-12-21 11:10 ` Daniel Baluta
2018-12-21 14:59 ` [Sound-open-firmware] " Pierre-Louis Bossart
2018-12-11 21:23 ` [PATCH v3 11/14] ASoC: SOF: Add PM support Pierre-Louis Bossart
2018-12-12 11:32 ` Takashi Iwai
2018-12-12 16:08 ` Pierre-Louis Bossart
2018-12-11 21:23 ` [PATCH v3 12/14] ASoC: SOF: Add Nocodec machine driver support Pierre-Louis Bossart
2018-12-11 21:23 ` [PATCH v3 13/14] ASoC: SOF: Add xtensa support Pierre-Louis Bossart
2018-12-11 23:08 ` Andy Shevchenko
2018-12-12 0:00 ` Pierre-Louis Bossart
[not found] ` <93aff9af-c693-c951-4821-e9e334133ed0@linux.intel.com>
2018-12-13 9:58 ` [Sound-open-firmware] " rander.wang
2018-12-17 13:45 ` Takashi Iwai
2018-12-17 14:24 ` Mark Brown
2018-12-11 21:23 ` [PATCH v3 14/14] ASoC: SOF: Add utils Pierre-Louis Bossart
2018-12-11 23:06 ` Andy Shevchenko
2018-12-12 0:06 ` Pierre-Louis Bossart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=876df209-c829-873e-047e-c73fb0579d68@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alan@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=andriy.shevchenko@intel.com \
--cc=broonie@kernel.org \
--cc=daniel.baluta@gmail.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=sound-open-firmware@alsa-project.org \
--cc=tiwai@suse.de \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox