...

...

I've been working on upstreaming the bdw-rt5650 machine driver for the Acer Chromebase 24 (buddy). There seems to be an issue when first setting the hardware controls that appears to be crashing the DSP:

[ 51.424554] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19 ... [ 84.924666] haswell-pcm-audio haswell-pcm-audio: error: audio DSP boot timeout IPCD 0x0 IPCX 0x0 [ 85.260655] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000 [ 85.273609] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed [ 85.279746] System PCM: error: failed to commit stream -110 [ 85.285388] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110 [ 85.293963] System PCM: ASoC: hw_params FE failed -110

This happens roughly 50% of the time when first setting hardware controls after a reboot. The other 50% of the time the DSP comes up just fine and audio works fine thereafter. Adding "#define DEBUG 1" to sound/soc/intel/haswell/sst-haswell-ipc.c makes the issue occur much less frequently in my testing. Seems like a subtle timing issue.

There were timing issues encountered during the bringup of the 2015 chromebook pixel (samus) which uses the bdw-rt5677 machine driver. Those were slightly different, and manifested during repeated arecords. Both devices use the same revision of the sst2 firmware.

Any ideas for how to debug this?

this could be trying to send an IPC while you are already waiting for one to complete. we've seen this before with SOF, if the IPCs are not strictly serialized then things go in the weeds and timeout.

[removing top-posting] This is roughly what I was thinking. Is there a good way to monitor the timing on the IPCs in cases like this shy of probing the hardware?

I don't think we have any magic tools here. Tracing the start and completion of an IPC, and looking at the dmesg log, along with counting number of IPCs requested and number of Acks received are the usual solutions to figure out when such problems happen.

On 7/29/19 7:53 PM, Ranjani Sridharan wrote:

On Mon, 2019-07-29 at 18:02 -0500, Pierre-Louis Bossart wrote:

...

On 7/29/19 4:53 PM, Jon Flatley wrote:

...

I've been working on upstreaming the bdw-rt5650 machine driver for the Acer Chromebase 24 (buddy). There seems to be an issue when first setting the hardware controls that appears to be crashing the DSP:

[ 51.424554] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19 ... [ 84.924666] haswell-pcm-audio haswell-pcm-audio: error: audio DSP boot timeout IPCD 0x0 IPCX 0x0 [ 85.260655] haswell-pcm-audio haswell-pcm-audio: ipc: --message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000 [ 85.273609] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed [ 85.279746] System PCM: error: failed to commit stream -110 [ 85.285388] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110 [ 85.293963] System PCM: ASoC: hw_params FE failed -110

This happens roughly 50% of the time when first setting hardware controls after a reboot. The other 50% of the time the DSP comes up just fine and audio works fine thereafter. Adding "#define DEBUG 1" to sound/soc/intel/haswell/sst-haswell-ipc.c makes the issue occur much less frequently in my testing. Seems like a subtle timing issue.

There were timing issues encountered during the bringup of the 2015 chromebook pixel (samus) which uses the bdw-rt5677 machine driver. Those were slightly different, and manifested during repeated arecords. Both devices use the same revision of the sst2 firmware.

Any ideas for how to debug this?

this could be trying to send an IPC while you are already waiting for one to complete. we've seen this before with SOF, if the IPCs are not strictly serialized then things go in the weeds and timeout.

Pierre/Jon

In this case it looks like the DSP boot failed leading to the IPC timeout? WOndering if increasing the boot timeout would help?

Yes, that too. The boot timeout is typically experimentally defined, and never decreasing due to platform variations... I am still leaning more on the side of an side effect between two IPCs, the added DEBUG points to the printk which solves timing issues. The boot timeout would typically not be impacted by such changes.

On Tue, 2019-07-30 at 10:45 -0700, Jon Flatley wrote:

On Mon, Jul 29, 2019 at 7:23 PM Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:

...

On 7/29/19 7:53 PM, Ranjani Sridharan wrote:

...

On Mon, 2019-07-29 at 18:02 -0500, Pierre-Louis Bossart wrote:

...

On 7/29/19 4:53 PM, Jon Flatley wrote:

...

I've been working on upstreaming the bdw-rt5650 machine driver for the Acer Chromebase 24 (buddy). There seems to be an issue when first setting the hardware controls that appears to be crashing the DSP:

[ 51.424554] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19 ... [ 84.924666] haswell-pcm-audio haswell-pcm-audio: error: audio DSP boot timeout IPCD 0x0 IPCX 0x0 [ 85.260655] haswell-pcm-audio haswell-pcm-audio: ipc: -- message timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx 0x7fff0000 [ 85.273609] haswell-pcm-audio haswell-pcm-audio: error: stream commit failed [ 85.279746] System PCM: error: failed to commit stream -110 [ 85.285388] haswell-pcm-audio haswell-pcm-audio: ASoC: haswell-pcm-audio hw params failed: -110 [ 85.293963] System PCM: ASoC: hw_params FE failed -110

This happens roughly 50% of the time when first setting hardware controls after a reboot. The other 50% of the time the DSP comes up just fine and audio works fine thereafter. Adding "#define DEBUG 1" to sound/soc/intel/haswell/sst-haswell-ipc.c makes the issue occur much less frequently in my testing. Seems like a subtle timing issue.

There were timing issues encountered during the bringup of the 2015 chromebook pixel (samus) which uses the bdw-rt5677 machine driver. Those were slightly different, and manifested during repeated arecords. Both devices use the same revision of the sst2 firmware.

Any ideas for how to debug this?

this could be trying to send an IPC while you are already waiting for one to complete. we've seen this before with SOF, if the IPCs are not strictly serialized then things go in the weeds and timeout.

Pierre/Jon

In this case it looks like the DSP boot failed leading to the IPC timeout? WOndering if increasing the boot timeout would help?

I did actually try this without success.

...

Yes, that too. The boot timeout is typically experimentally defined, and never decreasing due to platform variations... I am still leaning more on the side of an side effect between two IPCs, the added DEBUG points to the printk which solves timing issues. The boot timeout would typically not be impacted by such changes.

I think the real struggle I'm having is finding a good debugging method that doesn't impact the timing of the IPCs significantly (as adding DEBUG seems to). This could maybe be overcome with using a stress test to reproduce. The crash only seems to occur when first booting the DSP, and so far I've been testing this by completely power cycling the machine on every test, which is very slow and tedious. So maybe the issue with DEBUG defined occurs 1 in 20 reboots rather than 1 in 2, I wouldn't know. If there's a way to reboot the DSP and reproduce this crash without rebooting the entire device that would be very helpful to me.

Maybe you've already tried this. But, how about blacklisting the audio driver and then trying a modprobe/rmmod to insert and remove themodule. This should attempt to boot the DSP upon every modprobe. But what I am not sure about is whether the rmmod would succeed if the IPC times out because the DSP has crashed.

Thanks, Ranjani

Thanks, Jon

On Tue, Jul 30, 2019 at 12:04 PM Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:

On 7/30/19 1:47 PM, Ranjani Sridharan wrote:

...

On Tue, 2019-07-30 at 10:45 -0700, Jon Flatley wrote:

...

On Mon, Jul 29, 2019 at 7:23 PM Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:

...

On 7/29/19 7:53 PM, Ranjani Sridharan wrote:

...

On Mon, 2019-07-29 at 18:02 -0500, Pierre-Louis Bossart wrote:

...

On 7/29/19 4:53 PM, Jon Flatley wrote: > I've been working on upstreaming the bdw-rt5650 machine > driver for > the > Acer Chromebase 24 (buddy). There seems to be an issue when > first > setting the hardware controls that appears to be crashing the > DSP: > > [ 51.424554] haswell-pcm-audio haswell-pcm-audio: FW > loaded, > mailbox > readback FW info: type 01, - version: 00.00, build 77, source > commit > id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19 > ... > [ 84.924666] haswell-pcm-audio haswell-pcm-audio: error: > audio > DSP > boot timeout IPCD 0x0 IPCX 0x0 > [ 85.260655] haswell-pcm-audio haswell-pcm-audio: ipc: -- > message > timeout-- ipcx 0x83000000 isr 0x00000000 ipcd 0x00000000 imrx > 0x7fff0000 > [ 85.273609] haswell-pcm-audio haswell-pcm-audio: error: > stream > commit failed > [ 85.279746] System PCM: error: failed to commit stream > -110 > [ 85.285388] haswell-pcm-audio haswell-pcm-audio: ASoC: > haswell-pcm-audio hw params failed: -110 > [ 85.293963] System PCM: ASoC: hw_params FE failed -110 > > This happens roughly 50% of the time when first setting > hardware > controls after a reboot. The other 50% of the time the DSP > comes up > just fine and audio works fine thereafter. Adding "#define > DEBUG 1" > to > sound/soc/intel/haswell/sst-haswell-ipc.c makes the issue > occur > much > less frequently in my testing. Seems like a subtle timing > issue. > > There were timing issues encountered during the bringup of > the 2015 > chromebook pixel (samus) which uses the bdw-rt5677 machine > driver. > Those were slightly different, and manifested during repeated > arecords. Both devices use the same revision of the sst2 > firmware. > > Any ideas for how to debug this?

this could be trying to send an IPC while you are already waiting for one to complete. we've seen this before with SOF, if the IPCs are not strictly serialized then things go in the weeds and timeout.

Pierre/Jon

In this case it looks like the DSP boot failed leading to the IPC timeout? WOndering if increasing the boot timeout would help?

I did actually try this without success.

...

Yes, that too. The boot timeout is typically experimentally defined, and never decreasing due to platform variations... I am still leaning more on the side of an side effect between two IPCs, the added DEBUG points to the printk which solves timing issues. The boot timeout would typically not be impacted by such changes.

I think the real struggle I'm having is finding a good debugging method that doesn't impact the timing of the IPCs significantly (as adding DEBUG seems to). This could maybe be overcome with using a stress test to reproduce. The crash only seems to occur when first booting the DSP, and so far I've been testing this by completely power cycling the machine on every test, which is very slow and tedious. So maybe the issue with DEBUG defined occurs 1 in 20 reboots rather than 1 in 2, I wouldn't know. If there's a way to reboot the DSP and reproduce this crash without rebooting the entire device that would be very helpful to me.

Maybe you've already tried this. But, how about blacklisting the audio driver and then trying a modprobe/rmmod to insert and remove themodule. This should attempt to boot the DSP upon every modprobe. But what I am not sure about is whether the rmmod would succeed if the IPC times out because the DSP has crashed.

I don't think we can really reduce the 'Heisenbug' nature of code instrumentations. But as Ranjani suggested it increasing the test frequency would make things more observable. I would go for suspend-resume tests, that would also force a DSP reboot without requiring a full reboot.

rtcwake -s 3 -m mem

I suspect modprobe/rmmod isn't likely to work, those legacy drivers were not exactly written with stress-test in mind. Suspend-resume is likely more reliable - been used in real products but tested with older kernels so your mileage may vary.

We should really have completed SOF support for Broadwell instead of supporting zombie drivers. Gah.

I've been off this issue for a couple of weeks but yesterday I made some progress.

There seems to be an issue when suspending the ALC5650. I think the nondeterministic behavior I was seeing just had to do with whether or not the DSP had yet suspended.

I reverted commit 0d2135ecadb0 ("ASoC: Intel: Work around to fix HW D3 potential crash issue") and things started working, including suspend/resume of the DSP. Any ideas for why this may be? I would like to resolve this so I can finish upstreaming the bdw-rt5650 machine driver.

Thanks, -Jon

On Wed, Aug 14, 2019 at 1:51 PM Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com wrote:

...

There seems to be an issue when suspending the ALC5650. I think the nondeterministic behavior I was seeing just had to do with whether or not the DSP had yet suspended.

I reverted commit 0d2135ecadb0 ("ASoC: Intel: Work around to fix HW D3 potential crash issue") and things started working, including suspend/resume of the DSP. Any ideas for why this may be? I would like to resolve this so I can finish upstreaming the bdw-rt5650 machine driver.

Copying Keyon in case he remembers the context.

Reverting a 5yr-old commit with all sorts of clock/power-related fixes looks brave, and it's not clear why this would work with the rt5677 and not with 5650.

No idea, I was just diffing the register writes looking for sources of discrepancy. The Chromium OS 3.14 kernel tree that Buddy uses doesn't have this patch, so I figured what's the worst that could happen?

Are you using the latest upstream firmware btw? Or the one which shipped with the initial device (which could be an issue if the protocol changed).

The firmware I'm loading is: `FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a1`. Hashes the same as the upstream binary.

On 2019-08-19 04:33, Jie, Yang wrote:

...

-----Original Message----- From: Jon Flatley [mailto:jflat@chromium.org] Sent: Thursday, August 15, 2019 5:25 AM To: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Cc: Jon Flatley jflat@chromium.org; Jie, Yang yang.jie@intel.com; benzh@chromium.org; alsa-devel@alsa-project.org; Ranjani Sridharan ranjani.sridharan@linux.intel.com; cujomalainey@chromium.org; Jie Yang yang.jie@linux.intel.com Subject: Re: [alsa-devel] [BUG] bdw-rt5650 DSP boot timeout

On Wed, Aug 14, 2019 at 1:51 PM Pierre-Louis Bossart <pierre- louis.bossart@linux.intel.com> wrote:

...

...

There seems to be an issue when suspending the ALC5650. I think the nondeterministic behavior I was seeing just had to do with whether or not the DSP had yet suspended.

I reverted commit 0d2135ecadb0 ("ASoC: Intel: Work around to fix HW D3 potential crash issue") and things started working, including suspend/resume of the DSP. Any ideas for why this may be? I would like to resolve this so I can finish upstreaming the bdw-rt5650 machine driver.

Copying Keyon in case he remembers the context.

Reverting a 5yr-old commit with all sorts of clock/power-related fixes looks brave, and it's not clear why this would work with the rt5677 and not with 5650.

No idea, I was just diffing the register writes looking for sources of discrepancy. The Chromium OS 3.14 kernel tree that Buddy uses doesn't have this patch, so I figured what's the worst that could happen?

Hi Jon, sorry about just noticing this thread. From the dmesg log, the issue happens at runtime suspend/resume but not in boot, am I right(you can disable runtime PM for the device to confirm that)?

My points here are:

1. the commit 0d2135ecadb0 was suggested by FW team to W/A D3 potential crash issue.
2. it was verified with rt286(Broadwell.c, e.g. Dell XPS) from our side only(and may have been checked with rt5677 by Chrome team).
3. please follow sequence in broadwell.c if issue happen at boot time.

If happened at runtime PM from DSP side, we should see it with all kinds of machine driver. Could you performing more test and debugging to see what it real happen there? 4. we have no reason to remove the commit directly, except correcting if some lines are proved wrong. And, as Pierre mentioned, SOF driver is preferred, as there is no new development effort to support SST haswell/Broadwell driver here(no platform, no developer, :-( ).

Thanks, ~Keyon>

Got to disagree with the last one - no platform, no developer. We are setting up some BDW/ HSW here to join our happy SKL+ family in CI. This is because of /common cleanups which will engulf aDSP project (hsw/byt) obviously.

These will be tested against the exact same BAT scope as other ADSP devices. Code here looks much better, at least compared to /skylake - ain't a high threshold though.. Given how outdated all SKL+ fw binaries are (on upstream repo) it might even come down simply to fw upgrade. Most of FW peps who took part in that project are already out. Although, found one or two who are willing to help : )

And yes, I'm setting them up with rt286 too. There are some rt56XX but I'm unsure if rt5650 is amount them. Still got some problems with ACPI, but soon two new faces should be greeting audio CI bonfire..

Czarek

...

...

Are you using the latest upstream firmware btw? Or the one which shipped with the initial device (which could be an issue if the protocol

changed).

The firmware I'm loading is: `FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a1`. Hashes the same as the upstream binary.

---

Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

On Mon, Aug 19, 2019 at 3:37 PM Jon Flatley jflat@chromium.org wrote:

On Mon, Aug 19, 2019 at 11:08 AM Cezary Rojewski cezary.rojewski@intel.com wrote:

...

On 2019-08-19 04:33, Jie, Yang wrote:

...

...

-----Original Message----- From: Jon Flatley [mailto:jflat@chromium.org] Sent: Thursday, August 15, 2019 5:25 AM To: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Cc: Jon Flatley jflat@chromium.org; Jie, Yang yang.jie@intel.com; benzh@chromium.org; alsa-devel@alsa-project.org; Ranjani Sridharan ranjani.sridharan@linux.intel.com; cujomalainey@chromium.org; Jie Yang yang.jie@linux.intel.com Subject: Re: [alsa-devel] [BUG] bdw-rt5650 DSP boot timeout

On Wed, Aug 14, 2019 at 1:51 PM Pierre-Louis Bossart <pierre- louis.bossart@linux.intel.com> wrote:

...

...

There seems to be an issue when suspending the ALC5650. I think the nondeterministic behavior I was seeing just had to do with whether or not the DSP had yet suspended.

I reverted commit 0d2135ecadb0 ("ASoC: Intel: Work around to fix HW D3 potential crash issue") and things started working, including suspend/resume of the DSP. Any ideas for why this may be? I would like to resolve this so I can finish upstreaming the bdw-rt5650 machine driver.

Copying Keyon in case he remembers the context.

Reverting a 5yr-old commit with all sorts of clock/power-related fixes looks brave, and it's not clear why this would work with the rt5677 and not with 5650.

No idea, I was just diffing the register writes looking for sources of discrepancy. The Chromium OS 3.14 kernel tree that Buddy uses doesn't have this patch, so I figured what's the worst that could happen?

Hi Jon, sorry about just noticing this thread. From the dmesg log, the issue happens at runtime suspend/resume but not in boot, am I right(you can disable runtime PM for the device to confirm that)?

From what I can tell that is correct. Disabling runtime PM seems to stabilize things. I tested this over 10 reboots. I'll kick off my stress test script overnight just to see if this is 100% consistent.

...

...

My points here are:

1. the commit 0d2135ecadb0 was suggested by FW team to W/A D3 potential crash issue.
2. it was verified with rt286(Broadwell.c, e.g. Dell XPS) from our side only(and may have been checked with rt5677 by Chrome team).
3. please follow sequence in broadwell.c if issue happen at boot time.

If happened at runtime PM from DSP side, we should see it with all kinds of machine driver.

I'm not really a sound guy; I've been picking this up as I go along. From what I've gathered it doesn't make sense to me why this is an issue on buddy, but not other bdw platforms, such as samus. If I understand correctly they both have the same DSP and use the same runtime suspend/resume code. What makes this fail with the 5650 and not the 5677 is the million dollar question.

...

...

Could you performing more test and debugging to see what it real happen there?

Yes, I'll continue poking at this. The debugging that got me this far basically just involved placing traces on the sst_shim32_write/read functions and looking at the diff from my best working reference, which is our cros-kernel-3.14 branch. This is what lead me to reverting 0d2135ecadb0, as it produced effectively identical traces as I was seeing in 3.14.

...

...

4. we have no reason to remove the commit directly, except correcting if some lines are proved wrong. And, as Pierre mentioned, SOF driver is preferred, as there is no new development effort to support SST haswell/Broadwell driver here(no platform, no developer, :-( ).

I'm not suggesting removing the commit, merely observing that reverting it seems to fix the problem.

...

...

Thanks, ~Keyon>

Got to disagree with the last one - no platform, no developer. We are setting up some BDW/ HSW here to join our happy SKL+ family in CI. This is because of /common cleanups which will engulf aDSP project (hsw/byt) obviously.

These will be tested against the exact same BAT scope as other ADSP devices. Code here looks much better, at least compared to /skylake - ain't a high threshold though.. Given how outdated all SKL+ fw binaries are (on upstream repo) it might even come down simply to fw upgrade. Most of FW peps who took part in that project are already out. Although, found one or two who are willing to help : )

And yes, I'm setting them up with rt286 too. There are some rt56XX but I'm unsure if rt5650 is amount them. Still got some problems with ACPI, but soon two new faces should be greeting audio CI bonfire..

Czarek

I can continue to work at this to see if I can make any more headway. Unfortunately without a solid intuitive understanding of the system, or insight into the DSP, I'm limited to looking at traces and git history for the most part.

Curtis: Do you think it makes sense to poke at samus and see if there are any differences in the suspend/resume process, or are they pretty much guaranteed to be identical?

My recommendation would be to look at the machine driver and see if its making additional calls to the DSP driver that is not made in other machine drivers such as the bdw-rt5677 (Samus.) That might indicate an additional code path that might be getting exercised in your context that isn't used in samus which is causing your problems. If you find something you can always copy it over to samus to see if it causes the same breakage. So yes definitely look. Usually the suspend/resume paths aren't that long, but I would search the whole machine driver for anything that can alter state.

Thanks for all your help on this.

• Jon

...

...

...

...

Are you using the latest upstream firmware btw? Or the one which shipped with the initial device (which could be an issue if the protocol

changed).

The firmware I'm loading is: `FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a1`. Hashes the same as the upstream binary.

---

Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

-----Original Message----- From: Rojewski, Cezary Sent: Tuesday, August 20, 2019 2:09 AM To: Jie, Yang yang.jie@intel.com; Jon Flatley jflat@chromium.org; Pierre- Louis Bossart pierre-louis.bossart@linux.intel.com Cc: benzh@chromium.org; alsa-devel@alsa-project.org; Jie Yang yang.jie@linux.intel.com; Ranjani Sridharan ranjani.sridharan@linux.intel.com; cujomalainey@chromium.org Subject: Re: [alsa-devel] [BUG] bdw-rt5650 DSP boot timeout

On 2019-08-19 04:33, Jie, Yang wrote:

...

...

-----Original Message----- From: Jon Flatley [mailto:jflat@chromium.org] Sent: Thursday, August 15, 2019 5:25 AM To: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Cc: Jon Flatley jflat@chromium.org; Jie, Yang yang.jie@intel.com; benzh@chromium.org; alsa-devel@alsa-project.org; Ranjani Sridharan ranjani.sridharan@linux.intel.com; cujomalainey@chromium.org; Jie Yang yang.jie@linux.intel.com Subject: Re: [alsa-devel] [BUG] bdw-rt5650 DSP boot timeout

On Wed, Aug 14, 2019 at 1:51 PM Pierre-Louis Bossart <pierre- louis.bossart@linux.intel.com> wrote:

...

...

There seems to be an issue when suspending the ALC5650. I think the nondeterministic behavior I was seeing just had to do with whether or not the DSP had yet suspended.

I reverted commit 0d2135ecadb0 ("ASoC: Intel: Work around to fix HW D3 potential crash issue") and things started working, including suspend/resume of the DSP. Any ideas for why this may be? I would like to resolve this so I can finish upstreaming the bdw-rt5650 machine driver.

Copying Keyon in case he remembers the context.

Reverting a 5yr-old commit with all sorts of clock/power-related fixes looks brave, and it's not clear why this would work with the rt5677 and not with 5650.

No idea, I was just diffing the register writes looking for sources of

discrepancy.

...

...

The Chromium OS 3.14 kernel tree that Buddy uses doesn't have this patch, so I figured what's the worst that could happen?

Hi Jon, sorry about just noticing this thread. From the dmesg log, the issue happens at runtime suspend/resume but not

in boot, am I right(you can disable runtime PM for the device to confirm that)?

...

My points here are:

1. the commit 0d2135ecadb0 was suggested by FW team to W/A D3

potential crash issue.

...

2. it was verified with rt286(Broadwell.c, e.g. Dell XPS) from our side

only(and may have been checked with rt5677 by Chrome team).

...

3. please follow sequence in broadwell.c if issue happen at boot time.

If happened at runtime PM from DSP side, we should see it with all kinds of

machine driver.

...

Could you performing more test and debugging to see what it real happen

there?

...

4. we have no reason to remove the commit directly, except correcting if

some lines are proved wrong. And, as Pierre mentioned, SOF driver is preferred, as there is no new development effort to support SST haswell/Broadwell driver here(no platform, no developer, :-( ).

...

Thanks, ~Keyon>

Got to disagree with the last one - no platform, no developer. We are setting up some BDW/ HSW here to join our happy SKL+ family in CI. This is because of /common cleanups which will engulf aDSP project (hsw/byt) obviously.

Yes, that's true, good to hear that you will add it to CI.

These will be tested against the exact same BAT scope as other ADSP devices. Code here looks much better, at least compared to /skylake - ain't a high threshold though.. Given how outdated all SKL+ fw binaries are (on upstream repo) it might even come down simply to fw upgrade. Most of FW peps who took part in that project are already out. Although, found one or two who are willing to help : )

I remember Pawel Piskorski and Marcin Barlik helped me from the FW side(including explaining about the S0<->S3 sequence), please contact me offline if needed, I will try to drag for some mails which I got 5 years back.

Thanks, ~Keyon

And yes, I'm setting them up with rt286 too. There are some rt56XX but I'm unsure if rt5650 is amount them. Still got some problems with ACPI, but soon two new faces should be greeting audio CI bonfire..

Czarek

...

...

...

Are you using the latest upstream firmware btw? Or the one which shipped with the initial device (which could be an issue if the protocol

changed).

The firmware I'm loading is: `FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a1`. Hashes the same as the upstream binary.

---

Alsa-devel mailing list Alsa-devel@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/alsa-devel