From: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
To: "Mukunda,Vijendar" <vijendar.mukunda@amd.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Peter Ujfalusi <peter.ujfalusi@linux.intel.com>,
Bard Liao <yung-chuan.liao@linux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
Daniel Baluta <daniel.baluta@nxp.com>,
Kai Vehmanen <kai.vehmanen@linux.intel.com>,
Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>,
Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
Takashi Iwai <tiwai@suse.com>,
Venkata Prasad Potturu <venkataprasad.potturu@amd.com>,
"Hiregoudar, Basavaraj" <Basavaraj.Hiregoudar@amd.com>,
"Dommati, Sunil-kumar" <Sunil-kumar.Dommati@amd.com>
Cc: kernel@collabora.com, sound-open-firmware@alsa-project.org,
linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] ASoC: SOF: amd: Handle IPC replies before FW_BOOT_COMPLETE
Date: Fri, 7 Feb 2025 19:00:35 +0200 [thread overview]
Message-ID: <f253bb70-5991-4ee6-9f44-ac59751c6a38@collabora.com> (raw)
In-Reply-To: <eb1628c2-b209-40a1-9f20-1057c2815536@amd.com>
On 2/7/25 2:24 PM, Mukunda,Vijendar wrote:
> On 07/02/25 17:46, Cristian Ciocaltea wrote:
>> On 2/7/25 1:55 PM, Mukunda,Vijendar wrote:
>>> On 07/02/25 17:16, Cristian Ciocaltea wrote:
>>>> In some cases, e.g. during resuming from suspend, there is a possibility
>>>> that some IPC reply messages get received by the host while the DSP
>>>> firmware has not yet reached the complete boot state.
>>>>
>>>> Detect when this happens and do not attempt to process the unexpected
>>>> replies from DSP. Instead, provide proper debugging support.
>>> As per our understanding, before FW boot completion there won't
>>> be any IPC responses sent from Firmware.
>>> In this case, do we really need such a condition check?
>> During the suspend/resume stress testing I was able to get this kind of
>> messages, and that's the actual reason for introducing the verification.
>>
>> Also it doesn't seem to be uncommon, e.g. Intel HDA IPC also provides
>> similar checks.
>>
> Could you please share reference logs to know which IPC messages
> are being received before FW_READY message/FW boot complete?
As mentioned in a previous reply, I couldn't enable debugging during
stress testing because it had the annoying effect of hiding the audio
breakage issue. I will try to experiment with some more targeted
instrumentation and see if it's possible to extract some useful data.
Regardless, I think it's worth keeping this check in place as it's
definitely helpful to spot potential FW issues (for current or future
products).
>>>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>>>> ---
>>>> sound/soc/sof/amd/acp-ipc.c | 23 ++++++++++++++++-------
>>>> 1 file changed, 16 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/sound/soc/sof/amd/acp-ipc.c b/sound/soc/sof/amd/acp-ipc.c
>>>> index 5f371d9263f3bad507236ace95b7ef323c369187..12caefd08788595be8de03a863b88b5bbc15847d 100644
>>>> --- a/sound/soc/sof/amd/acp-ipc.c
>>>> +++ b/sound/soc/sof/amd/acp-ipc.c
>>>> @@ -167,6 +167,7 @@ irqreturn_t acp_sof_ipc_irq_thread(int irq, void *context)
>>>>
>>>> if (sdev->first_boot && sdev->fw_state != SOF_FW_BOOT_COMPLETE) {
>>>> acp_mailbox_read(sdev, sdev->dsp_box.offset, &status, sizeof(status));
>>>> +
>>>> if ((status & SOF_IPC_PANIC_MAGIC_MASK) == SOF_IPC_PANIC_MAGIC) {
>>>> snd_sof_dsp_panic(sdev, sdev->dsp_box.offset + sizeof(status),
>>>> true);
>>>> @@ -188,13 +189,21 @@ irqreturn_t acp_sof_ipc_irq_thread(int irq, void *context)
>>>>
>>>> dsp_ack = snd_sof_dsp_read(sdev, ACP_DSP_BAR, ACP_SCRATCH_REG_0 + dsp_ack_write);
>>>> if (dsp_ack) {
>>>> - spin_lock_irq(&sdev->ipc_lock);
>>>> - /* handle immediate reply from DSP core */
>>>> - acp_dsp_ipc_get_reply(sdev);
>>>> - snd_sof_ipc_reply(sdev, 0);
>>>> - /* set the done bit */
>>>> - acp_dsp_ipc_dsp_done(sdev);
>>>> - spin_unlock_irq(&sdev->ipc_lock);
>>>> + if (likely(sdev->fw_state == SOF_FW_BOOT_COMPLETE)) {
>>>> + spin_lock_irq(&sdev->ipc_lock);
>>>> +
>>>> + /* handle immediate reply from DSP core */
>>>> + acp_dsp_ipc_get_reply(sdev);
>>>> + snd_sof_ipc_reply(sdev, 0);
>>>> + /* set the done bit */
>>>> + acp_dsp_ipc_dsp_done(sdev);
>>>> +
>>>> + spin_unlock_irq(&sdev->ipc_lock);
>>>> + } else {
>>>> + dev_dbg_ratelimited(sdev->dev, "IPC reply before FW_BOOT_COMPLETE: %#x\n",
>>>> + dsp_ack);
>>>> + }
>>>> +
>>>> ipc_irq = true;
>>>> }
>>>>
>>>>
>
next prev parent reply other threads:[~2025-02-07 17:00 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-07 11:46 [PATCH 0/4] Sound fix for Valve Steam Deck OLED on resume from suspend Cristian Ciocaltea
2025-02-07 11:46 ` [PATCH 1/4] ASoC: SOF: amd: Add post_fw_run_delay ACP quirk Cristian Ciocaltea
2025-02-07 12:35 ` Mukunda,Vijendar
2025-02-07 16:44 ` Cristian Ciocaltea
2025-02-07 11:46 ` [PATCH 2/4] ASoC: SOF: amd: Drop unused includes from Vangogh driver Cristian Ciocaltea
2025-02-10 11:38 ` potturu venkata prasad
2025-02-07 11:46 ` [PATCH 3/4] ASoC: SOF: amd: Handle IPC replies before FW_BOOT_COMPLETE Cristian Ciocaltea
2025-02-07 11:55 ` Mukunda,Vijendar
2025-02-07 12:16 ` Cristian Ciocaltea
2025-02-07 12:24 ` Mukunda,Vijendar
2025-02-07 17:00 ` Cristian Ciocaltea [this message]
2025-02-07 11:46 ` [PATCH 4/4] ASoC: SOF: amd: Add branch prediction hint in ACP IRQ handler Cristian Ciocaltea
2025-02-10 11:40 ` potturu venkata prasad
2025-02-10 16:41 ` [PATCH 0/4] Sound fix for Valve Steam Deck OLED on resume from suspend Mark Brown
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=f253bb70-5991-4ee6-9f44-ac59751c6a38@collabora.com \
--to=cristian.ciocaltea@collabora.com \
--cc=Basavaraj.Hiregoudar@amd.com \
--cc=Sunil-kumar.Dommati@amd.com \
--cc=broonie@kernel.org \
--cc=daniel.baluta@nxp.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=kernel@collabora.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=peter.ujfalusi@linux.intel.com \
--cc=pierre-louis.bossart@linux.dev \
--cc=ranjani.sridharan@linux.intel.com \
--cc=sound-open-firmware@alsa-project.org \
--cc=tiwai@suse.com \
--cc=venkataprasad.potturu@amd.com \
--cc=vijendar.mukunda@amd.com \
--cc=yung-chuan.liao@linux.intel.com \
/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