| Message ID | 20200402184948.3014-1-hdegoede@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] ASoC: SOF: Fix "no reply expected" error during firmware-boot | expand |
On 4/2/20 1:49 PM, Hans de Goede wrote: > At least on Canon Lake each time the SOF firmware is booted, > the following error is logged in dmesg: > > [ 36.711803] sof-audio-pci 0000:00:1f.3: error: no reply expected, received 0x0 > > Since the DSP is powered down when not in used this happens everytime > e.g. a notification plays, polluting dmesg with these false-positive > errors. What kernel are you using Hans? I thought this was solved with 8354d9b44530b ("ASoC: SOF: Intel: hda-loader: clear the IPC ack bit after FW_PURGE done") Set DONE bit after the FW_PURGE IPC is polled successfully, to clear the interrupt and avoid the arrival of the confusing unexpected ipc. > Add a check to snd_sof_ipc_reply() which makes it return success when > receiving an unexpected msg_id 0 during fw-boot, fixing these > false-positive errors being logged. > > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > --- > sound/soc/sof/ipc.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/sound/soc/sof/ipc.c b/sound/soc/sof/ipc.c > index 78aa1da7c7a9..7303b3d42f12 100644 > --- a/sound/soc/sof/ipc.c > +++ b/sound/soc/sof/ipc.c > @@ -312,6 +312,11 @@ int snd_sof_ipc_reply(struct snd_sof_dev *sdev, u32 msg_id) > { > struct snd_sof_ipc_msg *msg = &sdev->ipc->msg; > > + /* Ignore msg_id 0 being send during fw-boot */ > + if (msg->ipc_complete && sdev->fw_state == SOF_FW_BOOT_IN_PROGRESS && > + msg_id == 0) > + return 0; > + > if (msg->ipc_complete) { > dev_err(sdev->dev, "error: no reply expected, received 0x%x", > msg_id); >
Hi, On 4/2/20 9:15 PM, Pierre-Louis Bossart wrote: > > > On 4/2/20 1:49 PM, Hans de Goede wrote: >> At least on Canon Lake each time the SOF firmware is booted, >> the following error is logged in dmesg: >> >> [ 36.711803] sof-audio-pci 0000:00:1f.3: error: no reply expected, received 0x0 >> >> Since the DSP is powered down when not in used this happens everytime >> e.g. a notification plays, polluting dmesg with these false-positive >> errors. > > What kernel are you using Hans? I thought this was solved with 5.6.0 > 8354d9b44530b ("ASoC: SOF: Intel: hda-loader: clear the IPC ack bit after FW_PURGE done") > > Set DONE bit after the FW_PURGE IPC is polled successfully, to clear the > interrupt and avoid the arrival of the confusing unexpected ipc. That commit is not in Torvald's tree yet, but it is in broonie/sound.git, I've cherry picked it into my local tree and reverted my own fix. Unfortunately even with that patch cherry picked the errors my patch silences still happen. Regards, Hans >> Add a check to snd_sof_ipc_reply() which makes it return success when >> receiving an unexpected msg_id 0 during fw-boot, fixing these >> false-positive errors being logged. >> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> sound/soc/sof/ipc.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/sound/soc/sof/ipc.c b/sound/soc/sof/ipc.c >> index 78aa1da7c7a9..7303b3d42f12 100644 >> --- a/sound/soc/sof/ipc.c >> +++ b/sound/soc/sof/ipc.c >> @@ -312,6 +312,11 @@ int snd_sof_ipc_reply(struct snd_sof_dev *sdev, u32 msg_id) >> { >> struct snd_sof_ipc_msg *msg = &sdev->ipc->msg; >> + /* Ignore msg_id 0 being send during fw-boot */ >> + if (msg->ipc_complete && sdev->fw_state == SOF_FW_BOOT_IN_PROGRESS && >> + msg_id == 0) >> + return 0; >> + >> if (msg->ipc_complete) { >> dev_err(sdev->dev, "error: no reply expected, received 0x%x", >> msg_id); >> >
On 4/3/20 3:01 AM, Hans de Goede wrote: > Hi, > > On 4/2/20 9:15 PM, Pierre-Louis Bossart wrote: >> >> >> On 4/2/20 1:49 PM, Hans de Goede wrote: >>> At least on Canon Lake each time the SOF firmware is booted, >>> the following error is logged in dmesg: >>> >>> [ 36.711803] sof-audio-pci 0000:00:1f.3: error: no reply expected, >>> received 0x0 >>> >>> Since the DSP is powered down when not in used this happens everytime >>> e.g. a notification plays, polluting dmesg with these false-positive >>> errors. >> >> What kernel are you using Hans? I thought this was solved with > > 5.6.0 > >> 8354d9b44530b ("ASoC: SOF: Intel: hda-loader: clear the IPC ack bit >> after FW_PURGE done") > >> Set DONE bit after the FW_PURGE IPC is polled successfully, to clear the >> interrupt and avoid the arrival of the confusing unexpected ipc. > > That commit is not in Torvald's tree yet, but it is in > broonie/sound.git, I've cherry picked it into my local tree > and reverted my own fix. > > Unfortunately even with that patch cherry picked the errors my > patch silences still happen. Ok, we'll look into it. Give us a couple of days on this one, thanks!
On Fri, Apr 03, 2020 at 08:17:32AM -0500, Pierre-Louis Bossart wrote: > On 4/3/20 3:01 AM, Hans de Goede wrote: > > That commit is not in Torvald's tree yet, but it is in > > broonie/sound.git, I've cherry picked it into my local tree > > and reverted my own fix. > > Unfortunately even with that patch cherry picked the errors my > > patch silences still happen. > Ok, we'll look into it. Give us a couple of days on this one, thanks! It's been more than a few days now...
On 4/20/20 7:48 AM, Mark Brown wrote: > On Fri, Apr 03, 2020 at 08:17:32AM -0500, Pierre-Louis Bossart wrote: >> On 4/3/20 3:01 AM, Hans de Goede wrote: > >>> That commit is not in Torvald's tree yet, but it is in >>> broonie/sound.git, I've cherry picked it into my local tree >>> and reverted my own fix. > >>> Unfortunately even with that patch cherry picked the errors my >>> patch silences still happen. > >> Ok, we'll look into it. Give us a couple of days on this one, thanks! > > It's been more than a few days now... Sorry about the delay, on my side I don't see this anymore in my ApolloLake or CML tests. Kai, can you confirm for HDaudio platforms?
Hey, On Mon, 20 Apr 2020, Pierre-Louis Bossart wrote: >>> On 4/3/20 3:01 AM, Hans de Goede wrote: >>>> Unfortunately even with that patch cherry picked the errors my >>>> patch silences still happen. > > Sorry about the delay, on my side I don't see this anymore in my ApolloLake or > CML tests. Kai, can you confirm for HDaudio platforms? I tested on a set of HDA platforms and I could not trigger the "no reply expected" errors. Tested with sof-dev (Mark's latest tree but staged SOF patches) that has the "ASoC: SOF: Intel: hda-loader: clear the IPC ack bit after FW_PURGE" patch. If I revert this patch, the error trace comes back immediately, so this definitely helps to the trace spam at least in these cases. There could of course be some relation to FW version. So if someone can still get the error trace, the FW version and platform used would be interesting information. Br, Kai
Hi, On 4/20/20 10:28 PM, Kai Vehmanen wrote: > Hey, > > On Mon, 20 Apr 2020, Pierre-Louis Bossart wrote: > >>>> On 4/3/20 3:01 AM, Hans de Goede wrote: >>>>> Unfortunately even with that patch cherry picked the errors my >>>>> patch silences still happen. >> >> Sorry about the delay, on my side I don't see this anymore in my ApolloLake or >> CML tests. Kai, can you confirm for HDaudio platforms? > > I tested on a set of HDA platforms and I could not trigger the "no reply > expected" errors. Tested with sof-dev (Mark's latest tree but staged SOF > patches) that has the "ASoC: SOF: Intel: hda-loader: clear the IPC ack bit > after FW_PURGE" patch. > > If I revert this patch, the error trace comes back immediately, so this > definitely helps to the trace spam at least in these cases. > > There could of course be some relation to FW version. So if someone can > still get the error trace, the FW version and platform used would be > interesting information. I've retested with 5.7-rc2 (previous testing was on 5.6-rc# + the "ASoC: SOF: Intel: hda-loader: clear the IPC ack bit after FW_PURGE" patch) and I'm no longer seeing this. So I guess fixing this also needed some other patches which have now landed in 5.7. So this is resolved now and my patch for this can be dropped. Regards, Hans
> I've retested with 5.7-rc2 (previous testing was on 5.6-rc# + the > "ASoC: SOF: Intel: hda-loader: clear the IPC ack bit after FW_PURGE" patch) > and I'm no longer seeing this. So I guess fixing this also needed some > other > patches which have now landed in 5.7. > > So this is resolved now and my patch for this can be dropped. Thanks for confirming Hans. We followed-up on your suggestion and demoted additional error messages to avoid polluting the logs.
diff --git a/sound/soc/sof/ipc.c b/sound/soc/sof/ipc.c index 78aa1da7c7a9..7303b3d42f12 100644 --- a/sound/soc/sof/ipc.c +++ b/sound/soc/sof/ipc.c @@ -312,6 +312,11 @@ int snd_sof_ipc_reply(struct snd_sof_dev *sdev, u32 msg_id) { struct snd_sof_ipc_msg *msg = &sdev->ipc->msg; + /* Ignore msg_id 0 being send during fw-boot */ + if (msg->ipc_complete && sdev->fw_state == SOF_FW_BOOT_IN_PROGRESS && + msg_id == 0) + return 0; + if (msg->ipc_complete) { dev_err(sdev->dev, "error: no reply expected, received 0x%x", msg_id);
At least on Canon Lake each time the SOF firmware is booted, the following error is logged in dmesg: [ 36.711803] sof-audio-pci 0000:00:1f.3: error: no reply expected, received 0x0 Since the DSP is powered down when not in used this happens everytime e.g. a notification plays, polluting dmesg with these false-positive errors. Add a check to snd_sof_ipc_reply() which makes it return success when receiving an unexpected msg_id 0 during fw-boot, fixing these false-positive errors being logged. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- sound/soc/sof/ipc.c | 5 +++++ 1 file changed, 5 insertions(+)