[Sound-open-firmware] Whiskeylake support and kernel version
![](https://secure.gravatar.com/avatar/41c3ff8b93e275e6b669f8289bfa2a8b.jpg?s=120&d=mm&r=g)
Hi,
I'm working on bringing up Debian on a Whiskeylake based system and having some problems with the audio not working. I'm running a 5.2.9 kernel with the 1.3 SOF firmware - will that support whiskeylake or do I need to update to newer (I also have a cometlake system and I needed 5.3 there - but it was more obvious in the kernel configuration)
Thanks! Mark
![](https://secure.gravatar.com/avatar/fb6e542c9256b956fe05f4bf16c32571.jpg?s=120&d=mm&r=g)
Hi,
On Thu, 12 Sep 2019, Mark Pearson wrote:
I'm working on bringing up Debian on a Whiskeylake based system and having some problems with the audio not working. I'm running a 5.2.9 kernel with the 1.3 SOF firmware - will that support whiskeylake or do I need to update to newer (I also have a cometlake system and I needed 5.3 there - but it was more obvious in the kernel configuration)
yes, that should work. Based on a quick check, 5.2.9 should have all the needed patches in. What kind of issues you are having?
Br, Kai
![](https://secure.gravatar.com/avatar/41c3ff8b93e275e6b669f8289bfa2a8b.jpg?s=120&d=mm&r=g)
Hi Kai,
OK - good to know it should work. I'm seeing the card and devices show up under aplay/arecord but am not getting any audio out with speaker-test and haven't really gotten into debugging the input side yet
Mark
-----Original Message----- From: Kai Vehmanen kai.vehmanen@linux.intel.com Sent: Thursday, September 12, 2019 8:50 AM To: Mark Pearson mpearson@lenovo.com Cc: sound-open-firmware@alsa-project.org Subject: [External] Re: [Sound-open-firmware] Whiskeylake support and kernel version
Hi,
On Thu, 12 Sep 2019, Mark Pearson wrote:
I'm working on bringing up Debian on a Whiskeylake based system and having some problems with the audio not working. I'm running a 5.2.9 kernel with the 1.3 SOF firmware - will that support whiskeylake or do I need to update to newer (I also have a cometlake system and I needed 5.3 there - but it was more obvious in the kernel configuration)
yes, that should work. Based on a quick check, 5.2.9 should have all the needed patches in. What kind of issues you are having?
Br, Kai
![](https://secure.gravatar.com/avatar/41c3ff8b93e275e6b669f8289bfa2a8b.jpg?s=120&d=mm&r=g)
I just realized how useless my response was...a bit lacking in specifics
When running 'speaker-test -D hw:0,0 -c 2' I get "playback open error: -22 Invalid argument" And similarly with 'arecord -f dat -D hw:0,6 -d 5 test.wav' we get: " arecord: main:828: audio open error: Invalid argument"
These commands are all working on my cometlake based system (admittedly with the 5.3 kernel) and the devices all show up with arecord/aplay.
Reviewing the dmesg (and I can attach the log if it's helpful) it starts off well but I noticed these messages: [ 3.003833] sof-audio-pci 0000:00:1f.3: Firmware info: version 1:1:0-5dd9a [ 3.003834] sof-audio-pci 0000:00:1f.3: Firmware: ABI 3:7:0 Kernel ABI 3:6:0 [ 3.003835] sof-audio-pci 0000:00:1f.3: warn: FW ABI is more recent than kernel [ 3.005845] sof-audio-pci 0000:00:1f.3: Topology: ABI 3:7:0 Kernel ABI 3:6:0 [ 3.005846] sof-audio-pci 0000:00:1f.3: warn: topology ABI is more recent than kernel
Which makes me wonder if I should be using an older firmware/topology version? Any thoughts and where would I get 'compatible' versions to try out?
I also see further down still: [ 1116.759684] sof-audio-pci 0000:00:1f.3: error: volume get failed to idle -16 [ 1209.452223] sof-audio-pci 0000:00:1f.3: error: no reply expected, received 0x0 [ 1212.452605] sof-audio-pci 0000:00:1f.3: error: load fw failed ret: -110 [ 1212.452628] sof-audio-pci 0000:00:1f.3: error: status = 0x00000000 panic = 0x00000000 [ 1212.452633] sof-audio-pci 0000:00:1f.3: error: failed to reset DSP [ 1212.452637] sof-audio-pci 0000:00:1f.3: error: failed to boot DSP firmware after resume -110 [ 1212.452655] sof-audio-pci 0000:00:1f.3: error: pcm open failed to resume -22 [ 1212.452658] sof-audio-pci 0000:00:1f.3: ASoC: can't open component 0000:00:1f.3: -22 [ 1212.452662] HDA Analog: ASoC: failed to start FE -22
But at this point I'm assuming it's all gone rather wrong.
Mark
-----Original Message----- From: Sound-open-firmware sound-open-firmware-bounces@alsa-project.org On Behalf Of Mark Pearson Sent: Thursday, September 12, 2019 8:54 AM To: Kai Vehmanen kai.vehmanen@linux.intel.com Cc: sound-open-firmware@alsa-project.org Subject: Re: [Sound-open-firmware] [External] Re: Whiskeylake support and kernel version
Hi Kai,
OK - good to know it should work. I'm seeing the card and devices show up under aplay/arecord but am not getting any audio out with speaker-test and haven't really gotten into debugging the input side yet
Mark
-----Original Message----- From: Kai Vehmanen kai.vehmanen@linux.intel.com Sent: Thursday, September 12, 2019 8:50 AM To: Mark Pearson mpearson@lenovo.com Cc: sound-open-firmware@alsa-project.org Subject: [External] Re: [Sound-open-firmware] Whiskeylake support and kernel version
Hi,
On Thu, 12 Sep 2019, Mark Pearson wrote:
I'm working on bringing up Debian on a Whiskeylake based system and having some problems with the audio not working. I'm running a 5.2.9 kernel with the 1.3 SOF firmware - will that support whiskeylake or do I need to update to newer (I also have a cometlake system and I needed 5.3 there - but it was more obvious in the kernel configuration)
yes, that should work. Based on a quick check, 5.2.9 should have all the needed patches in. What kind of issues you are having?
Br, Kai
_______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
![](https://secure.gravatar.com/avatar/59bffa8d29505a5951521a2fd09a4fd9.jpg?s=120&d=mm&r=g)
Hi Mark,
On 9/12/19 8:34 AM, Mark Pearson wrote:
I just realized how useless my response was...a bit lacking in specifics
When running 'speaker-test -D hw:0,0 -c 2' I get "playback open error: -22 Invalid argument"
I always use -r 48000, maybe that helps
And similarly with 'arecord -f dat -D hw:0,6 -d 5 test.wav' we get: " arecord: main:828: audio open error: Invalid argument"
It could also be that this is due to the format, IIRC for DMIC you need to use S32_LE. I think we added some checks recently, and we did change the device names to make them self-explanatory.
These commands are all working on my cometlake based system (admittedly with the 5.3 kernel) and the devices all show up with arecord/aplay.
Reviewing the dmesg (and I can attach the log if it's helpful) it starts off well but I noticed these messages: [ 3.003833] sof-audio-pci 0000:00:1f.3: Firmware info: version 1:1:0-5dd9a [ 3.003834] sof-audio-pci 0000:00:1f.3: Firmware: ABI 3:7:0 Kernel ABI 3:6:0 [ 3.003835] sof-audio-pci 0000:00:1f.3: warn: FW ABI is more recent than kernel [ 3.005845] sof-audio-pci 0000:00:1f.3: Topology: ABI 3:7:0 Kernel ABI 3:6:0 [ 3.005846] sof-audio-pci 0000:00:1f.3: warn: topology ABI is more recent than kernel
Which makes me wonder if I should be using an older firmware/topology version? Any thoughts and where would I get 'compatible' versions to try out?
I also see further down still: [ 1116.759684] sof-audio-pci 0000:00:1f.3: error: volume get failed to idle -16 [ 1209.452223] sof-audio-pci 0000:00:1f.3: error: no reply expected, received 0x0 [ 1212.452605] sof-audio-pci 0000:00:1f.3: error: load fw failed ret: -110 [ 1212.452628] sof-audio-pci 0000:00:1f.3: error: status = 0x00000000 panic = 0x00000000 [ 1212.452633] sof-audio-pci 0000:00:1f.3: error: failed to reset DSP [ 1212.452637] sof-audio-pci 0000:00:1f.3: error: failed to boot DSP firmware after resume -110 [ 1212.452655] sof-audio-pci 0000:00:1f.3: error: pcm open failed to resume -22 [ 1212.452658] sof-audio-pci 0000:00:1f.3: ASoC: can't open component 0000:00:1f.3: -22 [ 1212.452662] HDA Analog: ASoC: failed to start FE -22
But at this point I'm assuming it's all gone rather wrong.
I would try with the latest kernel (topic/sof-dev on GitHub) and 1.3 firmware. We've done quite a few improvements for suspend/resume robustness and I am not sure they are all in 5.3. That error message was familiar a couple of months ago, I haven't seen it in a while. if it helps I can share the kernel config we use, you don't have to spend time recompiling useless stuff just to test audio. Also the autodetect for DMIC is not in 5.3, it was added later and is queued for 5.4
In terms of topologies, you probably want a recent version. Seppo added a filter to remove the DC component and boost the DMIC volume, the initial releases were 20dB too low. If this helps you can get the ones we tested at https://bugzilla.kernel.org/show_bug.cgi?id=201251, where DMIC issues were solved with others.
Soonish we will have packages and distros will be able to use stable releases and auto updates, please bear with the delays, the Summer has been quite busy.
-Pierre
![](https://secure.gravatar.com/avatar/41c3ff8b93e275e6b669f8289bfa2a8b.jpg?s=120&d=mm&r=g)
Thanks Pierre - that's really useful. As an aside you've also solved another puzzle I had that the mic wasn't showing up on my 5.3 based kernel :)
I'll try the newer kernel on this platform and see how it goes - I figured I was going to have to do that but the customer wants 5.2.9 and so I was hoping I might be able to get enough working that way. Sounds like that's not a reasonable route to go (without backporting patches, special builds etc)
Mark
-----Original Message----- From: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Sent: Thursday, September 12, 2019 9:53 AM To: Mark Pearson mpearson@lenovo.com; Kai Vehmanen kai.vehmanen@linux.intel.com Cc: sound-open-firmware@alsa-project.org Subject: Re: [Sound-open-firmware] [External] Re: Whiskeylake support and kernel version
Hi Mark,
On 9/12/19 8:34 AM, Mark Pearson wrote:
I just realized how useless my response was...a bit lacking in specifics
When running 'speaker-test -D hw:0,0 -c 2' I get "playback open error: -22 Invalid argument"
I always use -r 48000, maybe that helps
And similarly with 'arecord -f dat -D hw:0,6 -d 5 test.wav' we get: " arecord: main:828: audio open error: Invalid argument"
It could also be that this is due to the format, IIRC for DMIC you need to use S32_LE. I think we added some checks recently, and we did change the device names to make them self-explanatory.
These commands are all working on my cometlake based system (admittedly with the 5.3 kernel) and the devices all show up with arecord/aplay.
Reviewing the dmesg (and I can attach the log if it's helpful) it starts off well but I noticed these messages: [ 3.003833] sof-audio-pci 0000:00:1f.3: Firmware info: version 1:1:0-5dd9a [ 3.003834] sof-audio-pci 0000:00:1f.3: Firmware: ABI 3:7:0 Kernel ABI 3:6:0 [ 3.003835] sof-audio-pci 0000:00:1f.3: warn: FW ABI is more recent than kernel [ 3.005845] sof-audio-pci 0000:00:1f.3: Topology: ABI 3:7:0 Kernel ABI 3:6:0 [ 3.005846] sof-audio-pci 0000:00:1f.3: warn: topology ABI is more recent than kernel
Which makes me wonder if I should be using an older firmware/topology version? Any thoughts and where would I get 'compatible' versions to try out?
I also see further down still: [ 1116.759684] sof-audio-pci 0000:00:1f.3: error: volume get failed to idle -16 [ 1209.452223] sof-audio-pci 0000:00:1f.3: error: no reply expected, received 0x0 [ 1212.452605] sof-audio-pci 0000:00:1f.3: error: load fw failed ret: -110 [ 1212.452628] sof-audio-pci 0000:00:1f.3: error: status = 0x00000000 panic = 0x00000000 [ 1212.452633] sof-audio-pci 0000:00:1f.3: error: failed to reset DSP [ 1212.452637] sof-audio-pci 0000:00:1f.3: error: failed to boot DSP firmware after resume -110 [ 1212.452655] sof-audio-pci 0000:00:1f.3: error: pcm open failed to resume -22 [ 1212.452658] sof-audio-pci 0000:00:1f.3: ASoC: can't open component 0000:00:1f.3: -22 [ 1212.452662] HDA Analog: ASoC: failed to start FE -22
But at this point I'm assuming it's all gone rather wrong.
I would try with the latest kernel (topic/sof-dev on GitHub) and 1.3 firmware. We've done quite a few improvements for suspend/resume robustness and I am not sure they are all in 5.3. That error message was familiar a couple of months ago, I haven't seen it in a while. if it helps I can share the kernel config we use, you don't have to spend time recompiling useless stuff just to test audio. Also the autodetect for DMIC is not in 5.3, it was added later and is queued for 5.4
In terms of topologies, you probably want a recent version. Seppo added a filter to remove the DC component and boost the DMIC volume, the initial releases were 20dB too low. If this helps you can get the ones we tested at https://bugzilla.kernel.org/show_bug.cgi?id=201251, where DMIC issues were solved with others.
Soonish we will have packages and distros will be able to use stable releases and auto updates, please bear with the delays, the Summer has been quite busy.
-Pierre
![](https://secure.gravatar.com/avatar/41c3ff8b93e275e6b669f8289bfa2a8b.jpg?s=120&d=mm&r=g)
Hi,
If I wanted to backport the latest SOF support back to 5.2.9 (for the customer who wants that) - would that be a crazy thing to do? Any tips or pointers on doing that? Just update sound/soc/sof, include/uapi/sound/soc and include/sound/sof....maybe?
Thx Mark
-----Original Message----- From: Sound-open-firmware sound-open-firmware-bounces@alsa-project.org On Behalf Of Mark Pearson Sent: Thursday, September 12, 2019 10:04 AM To: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com; Kai Vehmanen kai.vehmanen@linux.intel.com Cc: sound-open-firmware@alsa-project.org Subject: Re: [Sound-open-firmware] [External] Re: Whiskeylake support and kernel version
Thanks Pierre - that's really useful. As an aside you've also solved another puzzle I had that the mic wasn't showing up on my 5.3 based kernel :)
I'll try the newer kernel on this platform and see how it goes - I figured I was going to have to do that but the customer wants 5.2.9 and so I was hoping I might be able to get enough working that way. Sounds like that's not a reasonable route to go (without backporting patches, special builds etc)
Mark
-----Original Message----- From: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Sent: Thursday, September 12, 2019 9:53 AM To: Mark Pearson mpearson@lenovo.com; Kai Vehmanen kai.vehmanen@linux.intel.com Cc: sound-open-firmware@alsa-project.org Subject: Re: [Sound-open-firmware] [External] Re: Whiskeylake support and kernel version
Hi Mark,
On 9/12/19 8:34 AM, Mark Pearson wrote:
I just realized how useless my response was...a bit lacking in specifics
When running 'speaker-test -D hw:0,0 -c 2' I get "playback open error: -22 Invalid argument"
I always use -r 48000, maybe that helps
And similarly with 'arecord -f dat -D hw:0,6 -d 5 test.wav' we get: " arecord: main:828: audio open error: Invalid argument"
It could also be that this is due to the format, IIRC for DMIC you need to use S32_LE. I think we added some checks recently, and we did change the device names to make them self-explanatory.
These commands are all working on my cometlake based system (admittedly with the 5.3 kernel) and the devices all show up with arecord/aplay.
Reviewing the dmesg (and I can attach the log if it's helpful) it starts off well but I noticed these messages: [ 3.003833] sof-audio-pci 0000:00:1f.3: Firmware info: version 1:1:0-5dd9a [ 3.003834] sof-audio-pci 0000:00:1f.3: Firmware: ABI 3:7:0 Kernel ABI 3:6:0 [ 3.003835] sof-audio-pci 0000:00:1f.3: warn: FW ABI is more recent than kernel [ 3.005845] sof-audio-pci 0000:00:1f.3: Topology: ABI 3:7:0 Kernel ABI 3:6:0 [ 3.005846] sof-audio-pci 0000:00:1f.3: warn: topology ABI is more recent than kernel
Which makes me wonder if I should be using an older firmware/topology version? Any thoughts and where would I get 'compatible' versions to try out?
I also see further down still: [ 1116.759684] sof-audio-pci 0000:00:1f.3: error: volume get failed to idle -16 [ 1209.452223] sof-audio-pci 0000:00:1f.3: error: no reply expected, received 0x0 [ 1212.452605] sof-audio-pci 0000:00:1f.3: error: load fw failed ret: -110 [ 1212.452628] sof-audio-pci 0000:00:1f.3: error: status = 0x00000000 panic = 0x00000000 [ 1212.452633] sof-audio-pci 0000:00:1f.3: error: failed to reset DSP [ 1212.452637] sof-audio-pci 0000:00:1f.3: error: failed to boot DSP firmware after resume -110 [ 1212.452655] sof-audio-pci 0000:00:1f.3: error: pcm open failed to resume -22 [ 1212.452658] sof-audio-pci 0000:00:1f.3: ASoC: can't open component 0000:00:1f.3: -22 [ 1212.452662] HDA Analog: ASoC: failed to start FE -22
But at this point I'm assuming it's all gone rather wrong.
I would try with the latest kernel (topic/sof-dev on GitHub) and 1.3 firmware. We've done quite a few improvements for suspend/resume robustness and I am not sure they are all in 5.3. That error message was familiar a couple of months ago, I haven't seen it in a while. if it helps I can share the kernel config we use, you don't have to spend time recompiling useless stuff just to test audio. Also the autodetect for DMIC is not in 5.3, it was added later and is queued for 5.4
In terms of topologies, you probably want a recent version. Seppo added a filter to remove the DC component and boost the DMIC volume, the initial releases were 20dB too low. If this helps you can get the ones we tested at https://bugzilla.kernel.org/show_bug.cgi?id=201251, where DMIC issues were solved with others.
Soonish we will have packages and distros will be able to use stable releases and auto updates, please bear with the delays, the Summer has been quite busy.
-Pierre _______________________________________________ Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
![](https://secure.gravatar.com/avatar/59bffa8d29505a5951521a2fd09a4fd9.jpg?s=120&d=mm&r=g)
On 9/12/19 10:13 AM, Mark Pearson wrote:
Hi,
If I wanted to backport the latest SOF support back to 5.2.9 (for the customer who wants that) - would that be a crazy thing to do? Any tips or pointers on doing that? Just update sound/soc/sof, include/uapi/sound/soc and include/sound/sof....maybe?
We have a dumb script that detects all the changes upstream and tries to apply them on top of whatever kernel version. It's dumb in the sense that it just picks in arbitrary libraries and contributor names, but it can get a working config. It'd have to be a custom build since we only take specific things and can't guarantee that the same backported stuff will work on all platforms.
The main problem is that there were a lot of reworks at the core level, with the 'modern' dai style, so I see 226 patches if you do this blindly.
# get all changes in broonie-next since last backport git log --oneline --reverse --no-merges v5.2.9..broonie/for-next \ > log_broonie.tmp
# get log based on directory (can be edited at will) git log --oneline --reverse --no-merges v5.2.9..broonie/for-next -- \ include/sound/sof/*.h include/uapi/sound/sof/*.h \ sound/pci/hda sound/hda \ sound/soc/sof/ \ > log_dir.tmp
# get log from sound/ and include/sound based on authors from intel git log --oneline --reverse --no-merges v5.2.9..broonie/for-next --author=intel.com -- sound/ include/sound > log_intel.tmp
# merge SHA1s cat log_intel.tmp log_dir.tmp | sort -u > list.tmp
# extract the relevant SHA1s from the initial list grep -F -x -f list.tmp log_broonie.tmp > gitlog.txt
To apply the list (possibly edited), run this: cat gitlog.txt | awk '{print $1}' > log1.tmp cat log1.tmp | git cherry-pick -x --stdin
Disclaimer: backport support is beyond the scope of the SOF development team.
![](https://secure.gravatar.com/avatar/41c3ff8b93e275e6b669f8289bfa2a8b.jpg?s=120&d=mm&r=g)
Hi Pierre,
The issue I'm seeing in the 5.2.9 kernel seems to be related to suspend and resume (crash in sof_suspend).
Are there any particular commits you can point to that might address just that problem? If the crash doesn't happen (rare) then the audio works fine so if I can get it stable it will be good enough for now.
Thanks! Mark
-----Original Message----- From: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Sent: Thursday, September 12, 2019 1:08 PM To: Mark Pearson mpearson@lenovo.com; Kai Vehmanen kai.vehmanen@linux.intel.com Cc: sound-open-firmware@alsa-project.org Subject: Re: [Sound-open-firmware] [External] Re: Whiskeylake support and kernel version
On 9/12/19 10:13 AM, Mark Pearson wrote:
Hi,
If I wanted to backport the latest SOF support back to 5.2.9 (for the customer
who wants that) - would that be a crazy thing to do? Any tips or pointers on doing that? Just update sound/soc/sof, include/uapi/sound/soc and include/sound/sof....maybe?
We have a dumb script that detects all the changes upstream and tries to apply them on top of whatever kernel version. It's dumb in the sense that it just picks in arbitrary libraries and contributor names, but it can get a working config. It'd have to be a custom build since we only take specific things and can't guarantee that the same backported stuff will work on all platforms.
The main problem is that there were a lot of reworks at the core level, with the 'modern' dai style, so I see 226 patches if you do this blindly.
# get all changes in broonie-next since last backport git log --oneline --reverse -- no-merges v5.2.9..broonie/for-next \ > log_broonie.tmp
# get log based on directory (can be edited at will) git log --oneline --reverse -- no-merges v5.2.9..broonie/for-next -- \ include/sound/sof/*.h include/uapi/sound/sof/*.h \ sound/pci/hda sound/hda \ sound/soc/sof/ \ > log_dir.tmp
# get log from sound/ and include/sound based on authors from intel git log -- oneline --reverse --no-merges v5.2.9..broonie/for-next --author=intel.com -- sound/ include/sound > log_intel.tmp
# merge SHA1s cat log_intel.tmp log_dir.tmp | sort -u > list.tmp
# extract the relevant SHA1s from the initial list grep -F -x -f list.tmp log_broonie.tmp > gitlog.txt
To apply the list (possibly edited), run this: cat gitlog.txt | awk '{print $1}' > log1.tmp cat log1.tmp | git cherry-pick -x --stdin
Disclaimer: backport support is beyond the scope of the SOF development team.
![](https://secure.gravatar.com/avatar/59bffa8d29505a5951521a2fd09a4fd9.jpg?s=120&d=mm&r=g)
On 9/13/19 4:55 PM, Mark Pearson wrote:
Hi Pierre,
The issue I'm seeing in the 5.2.9 kernel seems to be related to suspend and resume (crash in sof_suspend).
Are there any particular commits you can point to that might address just that problem? If the crash doesn't happen (rare) then the audio works fine so if I can get it stable it will be good enough for now.
I can't think of any specific commit, it was quite dynamic in Q2 and we added quite a few patches. I would maybe look at the delta between 5.3 and 5.2.9 in the sound/soc/sof directory and try to backport this minimum.
Alternatively the backport for a 5.0 product by the Ubuntu team might be also a solution. I don't know where their kernel is though, others would need to chime in.
Thanks! Mark
-----Original Message----- From: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Sent: Thursday, September 12, 2019 1:08 PM To: Mark Pearson mpearson@lenovo.com; Kai Vehmanen kai.vehmanen@linux.intel.com Cc: sound-open-firmware@alsa-project.org Subject: Re: [Sound-open-firmware] [External] Re: Whiskeylake support and kernel version
On 9/12/19 10:13 AM, Mark Pearson wrote:
Hi,
If I wanted to backport the latest SOF support back to 5.2.9 (for the customer
who wants that) - would that be a crazy thing to do? Any tips or pointers on doing that? Just update sound/soc/sof, include/uapi/sound/soc and include/sound/sof....maybe?
We have a dumb script that detects all the changes upstream and tries to apply them on top of whatever kernel version. It's dumb in the sense that it just picks in arbitrary libraries and contributor names, but it can get a working config. It'd have to be a custom build since we only take specific things and can't guarantee that the same backported stuff will work on all platforms.
The main problem is that there were a lot of reworks at the core level, with the 'modern' dai style, so I see 226 patches if you do this blindly.
# get all changes in broonie-next since last backport git log --oneline --reverse -- no-merges v5.2.9..broonie/for-next \ > log_broonie.tmp
# get log based on directory (can be edited at will) git log --oneline --reverse -- no-merges v5.2.9..broonie/for-next -- \ include/sound/sof/*.h include/uapi/sound/sof/*.h \ sound/pci/hda sound/hda \ sound/soc/sof/ \ > log_dir.tmp
# get log from sound/ and include/sound based on authors from intel git log -- oneline --reverse --no-merges v5.2.9..broonie/for-next --author=intel.com -- sound/ include/sound > log_intel.tmp
# merge SHA1s cat log_intel.tmp log_dir.tmp | sort -u > list.tmp
# extract the relevant SHA1s from the initial list grep -F -x -f list.tmp log_broonie.tmp > gitlog.txt
To apply the list (possibly edited), run this: cat gitlog.txt | awk '{print $1}' > log1.tmp cat log1.tmp | git cherry-pick -x --stdin
Disclaimer: backport support is beyond the scope of the SOF development team.
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
![](https://secure.gravatar.com/avatar/2838be12ecafd4f01bd2661e602a5e76.jpg?s=120&d=mm&r=g)
-----Original Message----- From: Sound-open-firmware sound-open-firmware-bounces@alsa-project.org On Behalf Of Pierre-Louis Bossart Sent: Saturday, September 14, 2019 12:53 To: Mark Pearson mpearson@lenovo.com Cc: sound-open-firmware@alsa-project.org Subject: Re: [Sound-open-firmware] [External] Re: Whiskeylake support and kernel version
On 9/13/19 4:55 PM, Mark Pearson wrote:
Hi Pierre,
The issue I'm seeing in the 5.2.9 kernel seems to be related to suspend and
resume (crash in sof_suspend).
Are there any particular commits you can point to that might address just that
problem? If the crash doesn't happen (rare) then the audio works fine so if I can get it stable it will be good enough for now.
I can't think of any specific commit, it was quite dynamic in Q2 and we added quite a few patches. I would maybe look at the delta between 5.3 and 5.2.9 in the sound/soc/sof directory and try to backport this minimum.
Hi Mark,
Could you check the GitHub issues:
https://github.com/thesofproject/linux/issues/494 https://github.com/thesofproject/linux/issues/505
And I think the final fix is
https://github.com/thesofproject/linux/pull/619
Could you have a look if this patch will solve your issue?
PS: The issue is mainly caused by FW signing check is not passed. So I am very interesting in how do you solve the issue for FW signing? I think there will be FW load failure before the panic happen?
PPS: If no FW sign issue, please check if you enable DSP in BIOS. And could you attach more demsg log for us to identify what the issue is.
Thanks Xiuli
Alternatively the backport for a 5.0 product by the Ubuntu team might be also a solution. I don't know where their kernel is though, others would need to chime in.
Thanks! Mark
-----Original Message----- From: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Sent: Thursday, September 12, 2019 1:08 PM To: Mark Pearson mpearson@lenovo.com; Kai Vehmanen kai.vehmanen@linux.intel.com Cc: sound-open-firmware@alsa-project.org Subject: Re: [Sound-open-firmware] [External] Re: Whiskeylake support and kernel version
On 9/12/19 10:13 AM, Mark Pearson wrote:
Hi,
If I wanted to backport the latest SOF support back to 5.2.9 (for the customer
who wants that) - would that be a crazy thing to do? Any tips or pointers on doing that? Just update sound/soc/sof, include/uapi/sound/soc and include/sound/sof....maybe?
We have a dumb script that detects all the changes upstream and tries to apply them on top of whatever kernel version. It's dumb in the sense that it just picks in arbitrary libraries and contributor names, but it can get a working config.
It'd
have to be a custom build since we only take specific things and can't
guarantee
that the same backported stuff will work on all platforms.
The main problem is that there were a lot of reworks at the core level, with
the
'modern' dai style, so I see 226 patches if you do this blindly.
# get all changes in broonie-next since last backport git log --oneline --reverse
--
no-merges v5.2.9..broonie/for-next \ > log_broonie.tmp
# get log based on directory (can be edited at will) git log --oneline --reverse -- no-merges v5.2.9..broonie/for-next -- \ include/sound/sof/*.h include/uapi/sound/sof/*.h \ sound/pci/hda sound/hda \ sound/soc/sof/ \ > log_dir.tmp
# get log from sound/ and include/sound based on authors from intel git log -- oneline --reverse --no-merges v5.2.9..broonie/for-next --author=intel.com -- sound/ include/sound > log_intel.tmp
# merge SHA1s cat log_intel.tmp log_dir.tmp | sort -u > list.tmp
# extract the relevant SHA1s from the initial list grep -F -x -f list.tmp log_broonie.tmp > gitlog.txt
To apply the list (possibly edited), run this: cat gitlog.txt | awk '{print $1}' > log1.tmp cat log1.tmp | git cherry-pick -x --stdin
Disclaimer: backport support is beyond the scope of the SOF development
team.
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
Sound-open-firmware mailing list Sound-open-firmware@alsa-project.org https://mailman.alsa-project.org/mailman/listinfo/sound-open-firmware
![](https://secure.gravatar.com/avatar/41c3ff8b93e275e6b669f8289bfa2a8b.jpg?s=120&d=mm&r=g)
Hi Xiuli
Many thanks for the response - very much appreciated
Could you check the GitHub issues:
https://github.com/thesofproject/linux/issues/494 https://github.com/thesofproject/linux/issues/505
And I think the final fix is
https://github.com/thesofproject/linux/pull/619
Could you have a look if this patch will solve your issue?
I believe these changes are already in the 5.2.9 kernel - at least they 're in the source code I'm building from. Let me know if I've missed something obvious.
PS: The issue is mainly caused by FW signing check is not passed. So I am very interesting in how do you solve the issue for FW signing? I think there will be FW load failure before the panic happen?
I do have FW and have been using the intel signed version (the 1.3 version).
As a note - to get it to "work" we boot in single user mode and then launch the x-server. Not sure why it makes a difference - I suspect some timing maybe?
Looking at the code there are some interesting commits around pm.c and pmc.c that I'm hoping might help. I was debugging the setup remotely and am waiting for it to arrive so I can debug locally and get more into the details and try things out.
PPS: If no FW sign issue, please check if you enable DSP in BIOS. And could you attach more demsg log for us to identify what the issue is.
I'm pretty sure we're good here. With the 5.3 kernel everything works fine - I just need to find which piece of magic is needed to make the 5.2.9 kernel behave. I tried a blanket approach backport but it was starting to get messy so I'm putting that on the back burner for now.
Thanks! Mark
![](https://secure.gravatar.com/avatar/fb6e542c9256b956fe05f4bf16c32571.jpg?s=120&d=mm&r=g)
Hi,
On Thu, 12 Sep 2019, Mark Pearson wrote:
These commands are all working on my cometlake based system (admittedly with the 5.3 kernel) and the devices all show up with arecord/aplay.
could you try with the same 5.3 kernel? That's probably the quickest thing to try.
Reviewing the dmesg (and I can attach the log if it's helpful) it starts off well but I noticed these messages: [ 3.003833] sof-audio-pci 0000:00:1f.3: Firmware info: version 1:1:0-5dd9a [ 3.003834] sof-audio-pci 0000:00:1f.3: Firmware: ABI 3:7:0 Kernel ABI 3:6:0 [ 3.003835] sof-audio-pci 0000:00:1f.3: warn: FW ABI is more recent than kernel [ 3.005845] sof-audio-pci 0000:00:1f.3: Topology: ABI 3:7:0 Kernel ABI 3:6:0 [ 3.005846] sof-audio-pci 0000:00:1f.3: warn: topology ABI is more recent than kernel
This means the FW+topology are newer, so 5.2.9 is a bit too old. I did check this and the kernel should be compatible (there was timestamping added to one of the IPCs), but maybe I missed something. In any case you have received the first IPC message from FW ("FW_READY") which leads to printing above info, so that is already indicating you are pretty far (e.g. authentication of the firmware has succeeded):
Which makes me wonder if I should be using an older firmware/topology version? Any thoughts and where would I get 'compatible' versions to try out?
I recommend sticking to 1.3. Older versions won't work on your device, and there are no newer ones yet available (we are working towards 1.4 release now).
Br, Kai
participants (4)
-
Kai Vehmanen
-
Mark Pearson
-
Pan, Xiuli
-
Pierre-Louis Bossart