Re: [BUG] bdw-rt5650 DSP boot timeout

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux