Audio device not recognized on Toshiba Chromebook 2, shipping with a Intel Bay Trail chipset. Not working since Linux 4.5, currently on 4.8.6, on every distribution I currenty tried. Thank you.
Did it work with 4.4 kernel? There hasn't been so much change about HD-audio functionality recently. If any, it's likely in other components. In anyway, give alsa-info.sh outputs on both working (4.4?) and non-working (the recent one) kernels. Run the script with --no-upload option and attach the outputs.
Created attachment 244401 [details] alsa-info.sh output on linux 4.8.6 As requested, alsa-input.sh output run on a linux 4.8.6 installation.
The more important bit is the output from the working (4.4.x) kernel.
Created attachment 244781 [details] alsa-info.sh output on linux 4.4.0 As requested, alsa-input.sh output run on a linux 4.4.0 installation.
Thanks. So the analog audio part has never been HD-audio. The HDMI part is HD-audio, but others aren't. It's Intel ASoC driver, and that seems to get a regression after 4.4. Vinod, is this something for you?
can you please send me dmesg after boot. I think some of Pierre's changes made the older byt driver deprecated so audio doesn't work anymore.
Created attachment 244871 [details] dmesg output on linux 4.8.7 As requested, boot log over a 4.8.7 installation. Do you need also the one from the 4.4.X?
Created attachment 244891 [details] dmesg output on linux 4.4.0 It has not been explicitly requested, but here you have dmesg on 4.4.0.
Nothing new about this one?
the information you provided is somewhat inconsistent in the 4.4 alas-info.sh, one can see that snd_soc_sst_byt_max98090_mach is loaded - this is encouraging since it's a known hardware setting that has worked for quite some time. In 4.8.6 it is not so you probably didn't have the right KConfig settings and dmesg shows a realtek ALC-892 codec (which makes no sense) There is a known problem to handle this configuration with the 'regular' atom/sst driver without any config hacks but the code is still there and you can enable byt-max98090 in all existing kernels, see http://lxr.free-electrons.com/source/sound/soc/intel/Kconfig#L111
Created attachment 246391 [details] alsa-info.sh output on linux 4.8.10 Executed alsa-info.sh on a 4.8.10 installation, with SND_SOC_INTEL_BYT_MAX98090_MACH enabled.
Created attachment 246401 [details] dmesg output on linux 4.8.10 Executed dmesg on a 4.8.10 installation, with SND_SOC_INTEL_BYT_MAX98090_MACH enabled.
from dmesg I see that the codec driver is loaded but the machine driver isn't found. Can you double check that the config allows for the CONFIG_SND_SST_IPC_ACPI config as well http://lxr.free-electrons.com/source/sound/soc/intel/common/sst-acpi.c#L218
I can confirm that variable was correctly configured as CONFIG_SND_SST_IPC_ACPI=m.
Created attachment 246861 [details] dmesg output on linux 4.8.11 dmesg output on linux 4.8.11, with CONFIG_SND_SST_IPC_ACPI=m.
Created attachment 246871 [details] alsa-info.sh output on linux 4.8.11
alas-info.sh shows you are still using the new set driver: snd_soc_sst_mfld_platform This codec is not yet supported with the new driver and you need to use the older one. It looks like your Kconfig are not right.
Is it a matter of time for it to be supported along with the new driver? What do you suggest?
There is already the cht_max98090 driver which is mostly compatible, it just needs to be modified to enable the MCLK for Baytrail which is the only hardware difference.it's a couple of hours tops but people who know how to do it don't have hardware to test.
We can try to bind just with the existing cht_max98090 driver as a start. Davide, could you give the ACPI dump? You can find it in /sys/firmware/acpi/tables/*, too.
(In reply to Takashi Iwai from comment #20) > We can try to bind just with the existing cht_max98090 driver as a start. I meant some thing like below. At least we can check whether the binding works. --- a/sound/soc/intel/atom/sst/sst_acpi.c +++ b/sound/soc/intel/atom/sst/sst_acpi.c @@ -445,6 +445,8 @@ static struct sst_acpi_mach sst_acpi_bytcr[] = { &byt_rvp_platform_data }, {"10EC5651", "bytcr_rt5651", "intel/fw_sst_0f28.bin", "bytcr_rt5651", NULL, &byt_rvp_platform_data }, + {"193C9890", "cht-bsw-max98090", "intel/fw_sst_0f28.bin", "cht-bsw", NULL, + &byt_rvp_platform_data }, {}, };
see my branch on github, it does what Takashi suggested and add support for the MCLK that's needed on Baytrail. in theory you should have sound with that if you set the mixers right https://github.com/plbossart/sound/tree/experimental/codecs The branch name means it's compile-tested only and not run on any platform. standard disclaimers apply.
Created attachment 247361 [details] alsa-info.sh output on linux 4.8.12 (patched)
Created attachment 247371 [details] dmesg output on linux 4.8.12 (patched)
Created attachment 247381 [details] acpidump
Is this [https://github.com/plbossart/sound/commit/768974414bad9c49dae8215ed7be89754031e640] the commit you're talking about? Currently applied it without any success (attachments dedicated for both dmesg and alsa-info). Anyway, for Takashi, attached acpidump's output.
Nothing new?
please take the entire branch instead of cherry-picking
Created attachment 247631 [details] dmesg output on linux 4.9.0 (experimental/codecs)
Created attachment 247641 [details] alsa-info.sh output on linux 4.9.0 (experimental/codecs)
Ok, as you can see, something more promising using the whole branch by Pierre. Any tip, now?
Very cool, thanks for testing. Now the problem is no longer a kernel issue but a mixer configuration, the 'no backend' thing is normal since the DSP mixers aren't set by default. Since you are using PulseAudio the best is to create a UCM file. I can do it for you quickly if you share the mixer settings you used for the different inputs and outputs with the previous driver. Or if you are daring and willing to learn you can copy/paste the bytcr-rt5640 directory and modify as needed, only keeping the initial part of the HiFi file for the Intel DSP mixer. see https://github.com/plbossart/UCM/tree/master/byt-rt5640
It's totally new stuff for me, so I think I'll accept your offer to quickly do it for me. :) What do you need me to share with you? On which platform? With 'previous driver' you mean the one working (used on 4.4.x), or the updated not working one (used on 4.8.x)? Thank you for your help, really appreciated!
what mixer settings did you use in the previous setup? do you have a file used to initialize the mixers?
alternatively there are mixer settings here https://chromium.googlesource.com/chromiumos/third_party/adhd/+/a32d5028fd2f149e8221e76e4d0699135073803d/ucm-config/rambi/byt-max98090/HiFi.conf that could be used. I don't know how different the devices are.
Sincerely don't know. Previously I needed to patch alsa this way: https://plus.google.com/+JamesFuBEEFCAKE/posts/Tf4Pc5Z8reH .
I am afraid there is no generic solution since there are dozens of devices using the same audio hardware but having different settings. ChromeOS folks publish all their UCM files here git clone https://chromium.googlesource.com/chromiumos/third_party/adhd your 'swanky' device is no longer maintained in ucm-configs, but you can find the data in older branches (git branch -r | grep swanky) You would need to take this swanky directory, change the name to chtmax98090 and edit the file as needed to reflect changes in mixer names since 2014. You would also need to add the mixers for the DSP (taken from my ucm files) Once you are done copy the directory to /usr/share/alsa/ucm It's not complicated but it's painful.
well I am too nice so here's a tentative solution https://github.com/plbossart/UCM/commits/rambi take the chtmax98090 directory and copy it in /usr/share/alsa/ucm There are a set of #FIXME that can be dealt with later. The mixer names may have changed but you'll have to log with pulse audio -vvv which ones fail.
Created attachment 247671 [details] pulseaudio on linux 4.9.0 (experimental/codecs) Thank you for the hints, Pierre. Now all the interfaces are correctly recognized by the whole system, but still unable to produce sounds. Actually, it seems that few missing configurations files and instructions in your HiFi.conf do not permitt to correctly load all the configurations you provided. I faced errors as these ones: > I: [pulseaudio] (alsa-lib)parser.c: error: could not parse configuration for > card HDA Intel PCH > I: [pulseaudio] (alsa-lib)main.c: error: failed to import HDA Intel PCH use > case configuration -2 [...] > I: [pulseaudio] (alsa-lib)pcm_hw.c: open '/dev/snd/pcmC0D0c' failed (-2) > I: [pulseaudio] alsa-util.c: Error opening PCM device hw:0: File o directory > non esistente [...] > I: [pulseaudio] (alsa-lib)main.c: unable to execute cset 'name='HP Left Out > Switch' off' > I: [pulseaudio] (alsa-lib)main.c: error: failed to initialize new use case: > HiFi > E: [pulseaudio] alsa-ucm.c: Failed to get the verb HiFi > E: [pulseaudio] alsa-ucm.c: No UCM verb is valid for chtmax98090 Complete log attached.
the first part is fine, it'll fallback to normal mode without UCM for HDMI output. The error I: [pulseaudio] (alsa-lib)main.c: unable to execute cset 'name='HP Left Out Switch' off' is likely due to a control that has changed. You will need to run amixer -Dchtmax98090 controls | grep Switch and figure out if this control was renamed or removed. You may need to look at the source code. If you have a single error then UCM stops, that's not right but that's how it is today.
Yeah, UCM parser can be more tolerant. Below patch to alsa-lib should improve the behavior. --- a/src/ucm/main.c +++ b/src/ucm/main.c @@ -436,7 +436,7 @@ static int execute_sequence(snd_use_case_mgr_t *uc_mgr, err = execute_cset(ctl, s->data.cset, s->type); if (err < 0) { uc_error("unable to execute cset '%s'\n", s->data.cset); - goto __fail; + /* goto __fail; */ } break; case SEQUENCE_ELEMENT_TYPE_SLEEP:
Created attachment 247711 [details] pulseaudio on linux 4.9.0 (experimental/codecs) #2 Pulseaudio logged with latest kernel, alsa-lib with latest patch you provided. Actually, no more audio interfaces detected by system.
This is getting hairy. The only difference I see with other UCM files is that it's missing Value { CaptureChannels 2 } Value { PlaybackChannels 2 } Maybe look at the examples from bytcr_rt5640 and try out.
Created attachment 247741 [details] pulseaudio on linux 4.9.0 (experimental/codecs) #3 Ok, actually I think it's the best configuration I could apply. So: > taken UCM files from chromium source code > (https://chromium.googlesource.com/chromiumos/third_party/adhd/+/f11e4d0d1e288faa3635203c9ebf9891008e4802/ucm-config/swanky/byt-max98090) > taken asound.state from confirmed working area > (https://github.com/fascinatingcaptain/CBFixesAndTweaks/blob/master/asound.state) Even the pulseaudio log seems to be little bit cleaner, but actually still no sounds (but interfaces are correctly recognized systemwide).
did you go in the sound control panel and select the speaker output? Can you provide pulse audio and dmesg logs when you do so?
Created attachment 247761 [details] pulseaudio on audio switch on linux 4.9.0 (experimental/codecs)
Created attachment 247771 [details] dmesg output on switch audio on linux 4.9.0 (experimental/codecs)
Here you have them, my dear.
I don't know how you enabled all these logs in dmesg, it's quite verbose. It's really hard to test remotely. The only advice I can give at this point is to recheck the UCM configuration. If there are some switches that weren't understood by alsamixer maybe the controls were renamed and the output is still switched off? You could also try to load the previous alsa state to see if this makes a difference and actually you can do a diff: dump the state in a file, load the previous one see if it works and dump the state again in another file so that we can see what changed.
Created attachment 247821 [details] Working audio stuff on 4.4.x (ubuntu based) This package contains stuff as UCM configuration files and asound.state files from a audio-working 4.4.x installation. Actually, as you can see, in UCM we don't see any max98090 associated config.
Created attachment 247841 [details] Working pulseaudio on 4.4.x (ubuntu based) Also, here you have a working pulseaudio instance, on the same installation.
i am not able to tell you what's wrong based on the entire asound.state, you'd have to provide the difference between what worked and what doesn't to guide the discussion. I don't have any data to work from at the moment.
Created attachment 247851 [details] Diff between working Pulseaudio and not working I just understood that modifying asound.state will not help us (that specific asound.state is needed to get speakers working, every other function should be working out-of-box). Attached you can read about the lines involved in the diff between pulseaudio on not-working installation (4.9.0, first comparing element) and the one on working installation (4.4.x, latter comparing element). Let me know if you find something more useful than I do. Thank you :)
no I was talking about the differences in asound.state, what mixer values are changed and what do they impact.
Created attachment 247931 [details] asound.state patch from the one from stock (not-working) to working one As I really do not understand how these things work, neither do know how to interpret this patch. Your help would be really appreciated, as till now.
the patch is totally cryptic to me as well. The problem is that the controls are renumbered and we are not comparing the same states. It's a generic problem I have with asound.state is that I'd like to see the difference between default values and things that have been set-up explicitly (in short having a diff state would be a lot more useful).
The problem is that the working asound.state is currently taken from ChromeOS, not from someone who additions upon it, so I have no idea how to do it.
Hey Pierre. You currently made lot of stuff to help me figuring out to solve problems, making me reach important steps into fixing audio. Two questions and I'll let you be free: 1. Will your kernel changes (the ones from experimental/codecs) ever be included in official mainstream branch? 2. Do you know someone to address me to, that can help me to fix last things with UCM/asound.state and whatever else is needed to be touched?
Ping...
Hi i'm on 4.4.0. If you need, I can do any test you currently need to debug what ever is wrong with new kernel versions. Waiting for updates. :)
Thank you, Fabrizio. Pierre, just to know: what is the pro to switch to the CHR driver, instead of the old - and working - BYT one? Why changing to the CherryTrail's one, on a BayTrail chipset?
The old driver is not compatible with the new one, and that means the old one is disabled in most distributions now. So you can keep the old as long as you manually run make menuconfig at every release. Or you can help us remove this legacy so that audio just works with the new driver and you can can move on with your hardware natively supported.
OK, then. I'm available to do whatever you want me to check, using your 'experimental/codecs' branch. I think Fabrizio, could help us on the other side getting informations on a working environment. Let us know what you need.
Created attachment 249181 [details] pulseaudio on linux 4.9.0 (experimental/codecs) #4 Actually pulled another pulseaudio daemon start log, in the following environment: - kernel 4.9.0 (from Pierre's branch experimental/codecs) - chtmax98090's UCM (pulled from https://chromium.googlesource.com/chromiumos/third_party/adhd/+/214263e2eb29f8a003876a4b2dbe17e6ca5d62cf/ucm-config/swanky/byt-max98090/HiFi.conf, changing 'cdev "hw:bytmax98090"' with 'cdev "hw:chtmax98090"') - /etc/modprobe.d/alsa-base.conf, where inserted 'options snd_hda_intel index=1,0' to set chtmax98090 as primary audio device. Also, I must say: when I attach headphones, I'm currently able to listen something like a little noise. Also when I play with 'alsamixer' command, unmuting random stuff, I can listen again noises both from the speaker and the headphones and from the mic on the headphones. Can you please take a look at it, Pierre?
(In reply to Davide Pucci from comment #64) > Created attachment 249181 [details] > pulseaudio on linux 4.9.0 (experimental/codecs) #4 > > Actually pulled another pulseaudio daemon start log, in the following > environment: > - kernel 4.9.0 (from Pierre's branch experimental/codecs) > - chtmax98090's UCM (pulled from > https://chromium.googlesource.com/chromiumos/third_party/adhd/+/ > 214263e2eb29f8a003876a4b2dbe17e6ca5d62cf/ucm-config/swanky/byt-max98090/HiFi. > conf, changing 'cdev "hw:bytmax98090"' with 'cdev "hw:chtmax98090"') > - /etc/modprobe.d/alsa-base.conf, where inserted 'options snd_hda_intel > index=1,0' to set chtmax98090 as primary audio device. > > Also, I must say: when I attach headphones, I'm currently able to listen > something like a little noise. Also when I play with 'alsamixer' command, > unmuting random stuff, I can listen again noises both from the speaker and > the headphones and from the mic on the headphones. > > Can you please take a look at it, Pierre? the UCM file I generated is pretty much the same as the one from Chromium, but with different settings for the Intel DSP mixers. Did you look at the differences? I remember there was a change at some point with switch off becoming switch on...
Created attachment 249221 [details] pulseaudio on linux 4.9.0 (experimental/codecs) #5 Ok, retried with your UCM config: now with this I can listen noises even on switching audio interface (between speaker and headset). Log attached. Do you notice something evidently wrong?
It's impossible to debug audio quality issues with logs. Can you try this: 0. play once with the speakers. 1. save the current asound state. kill pulseaudio (and make sure it doesn't restart with the autospawn disabled in /etc/pulse/client.conf) 2. override the asound state with the previous one from Chrome OS 3. comment out all the codec configuration parts in the UCM file but keep the initial DSP mixers 4. restart pulseaudio and report the changes.
I think I need your help modifying UCM file. I'm not able to identify which lines to comment out. Thank you!
(In reply to Davide Pucci from comment #68) > I think I need your help modifying UCM file. I'm not able to identify which > lines to comment out. Thank you! It's not complicated, just remove everything tied to codec. see attachment.
Created attachment 249991 [details] modified UCM file to set Intel DSP mixers use asound.state to load the codec parts and see what works.
Created attachment 250181 [details] pulseaudio on linux 4.9.0 (experimental/codecs) #6 Commented out the lines you suggested from UCM. No interface detected due to this failure: > I: [pulseaudio] alsa-ucm.c: UCM available for card chtmax98090 > I: [pulseaudio] alsa-ucm.c: Set UCM verb to HiFi > W: [pulseaudio] alsa-ucm.c: UCM file does not specify 'PlaybackChannels' or > 'CaptureChannels'for device Mic, assuming stereo duplex. > D: [pulseaudio] alsa-ucm.c: No _conflictingdevs for device Mic > D: [pulseaudio] alsa-ucm.c: No _supporteddevs for device Mic > W: [pulseaudio] alsa-ucm.c: UCM file does not specify 'PlaybackChannels' or > 'CaptureChannels'for device Headphone, assuming stereo duplex. > D: [pulseaudio] alsa-ucm.c: No _conflictingdevs for device Headphone > D: [pulseaudio] alsa-ucm.c: No _supporteddevs for device Headphone > I: [pulseaudio] module-alsa-card.c: Found UCM profiles > E: [pulseaudio] alsa-ucm.c: No sink and source at HiFi: Mic > E: [pulseaudio] alsa-ucm.c: No sink and source at HiFi: Headphone Extended log attached. Used both asound.state from ChromeOS and from my distro.
just look at the example here https://github.com/plbossart/UCM/blob/master/bytcr-rt5640/HiFi and add the values for PlaybackChannels and CaptureChannels
Tried: still no luck, not working.
I installed the patched kernel and tried all the fixes, sound still not working though.
Created attachment 251611 [details] alsa-info with custom kernel and without pusleaudio The kernel module seems to work as the card is recognized. Thanks for your work! I am using alsa without pulseaudio. However, I have 291 controls in alsamixer, and speaker-test doesn't work. I attached the output of alsa-info.sh. I have different errors. For most interfaces, I get: Unable to set hw params for playback: Invalid argument Setting of hwparams failed: Invalid argument For dmix, I get: ALSA lib pcm_direct.c:1054:(snd1_pcm_direct_initialize_slave) unable to install hw params ALSA lib pcm_dmix.c:1053:(snd_pcm_dmix_open) unable to initialize slave Playback open error: -22,Invalid argument Finally, for dsnoop, I have: ALSA lib pcm_dsnoop.c:556:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream Playback open error: -22,Invalid argument Also, running speaker-test generated some kernel error. I added them at the end of the alsa-info output.
the no back-end error is because the DSP mixers are not configured. You need to use the UCM file i provided, use the fix indicated above and help debug the differences with your previous setting.
Hey Pierre. Just for informational purpose: why on bytmax98090 driver we needed no custom UCM configurations and on chtmax98090 isn't that way?
because the older firmware/driver had hard-coded assumptions such as use of SSP2, which precludes its use in platforms where SSP0 is needed. With the new you can do both but need a configuration step. One might argued that choosing a default would have been nice but that wasn't the case so the configuration is needed.
Created attachment 253811 [details] Fix byt-max98090 fix for kernel >= 4.5
Created attachment 253821 [details] asound.state for byt-max98090
It seems that the 4.10 kernel has a regression as I don't have any input / output driver loading, making my chromebook only usable via ssh which is not practical for sound driver debugging. It took me a while to figure out but it's now almost certainly due to the upstream kernel, and thus it affects your experimental/codec branch based on 4.10-rc3. I will submit a proper bug report once I've bisected the source. I the meanwhile, I managed to make the old byt-max98090 driver work on a vanilla 4.9.6 kernel (latest stable). I attached the patch and the full asound.state. The speakers, headphone and microphone are working, although the mic has a very poor quality (tested with arecord).
compiled 4.9.6 kernel with patch applied and installed the provided asound.state, audio still not working. The audio interface disappeared again. Am i missing something?
Created attachment 253881 [details] alsa-info.sh output 4.9.6 patched
you are not providing any details on what branch this is so there's no way I can help. use the latest experimental/codecs branch so that I least I know what code this is. The 4.9 branches are for backport of known solutions, not for development.
Read Nicolas' post. I compiled on the stable brach (which i assume corresponds to "vanilla kernel") applying the patch he provided before compiling without any result. More precisely i compiled on elementary os 'Loki' whith the elementary default config for kernel 4.4.
Vanilla kernel is the official kernel source from kernel.org. @Pierre: I can't use your branch because of the I/O problem I mentioned. I will try again next week, but first I need to find the change that broke the kernel. Also, please note that we are talking about the old driver (byt-max98090). Although I don't know the details of kernel development cycle, I guess this fix is applicable for stable branch of the kernel as this is a regression appearing in kernel 4.5. @Fabrizio: Same remark, this is the old driver. It is not compatible with sound drivers using the newer driver. For that, you need to disable all other drivers present in "Device Drivers" -> "Sound card support" -> "Advanced Linux Sound Architecture". You can also have a look to my kernel configuration (https://github.com/Nicop06/dotfiles/blob/master/kernel_netbook), especially the section entitled "Common SoC Audio options for Freescale CPUs". Please don't use this configuration directly as its optimized for my laptop to reduce compilation time and thus have most drivers disabled.
I confirm that compiling 4.9.6 stable with the instructions provided by Nicolas brings back the audio. Thank you for your work Nicolas!
@Nicolas: if you're running into the same problem I was running into, see commit 49c03096263871a68c9dea3e86b7d1e163d2fba8 upstream to fix it.
Created attachment 254829 [details] attachment-6285-0.html Thanks for your email I am attending ELC-NA Please expect delayed response. Regards -- ~Vinod
Okay, I was able to get the codecs/experimental tree booting with the above bay trail fixed (which has sense landed in v4.10). Then, I placed the HiFi.conf file in /usr/share/alsa/ucm/chtmax98090/HiFi.conf, and made a /usr/share/alsa/ucm/chtmax98090/chtmax908090.conf which lists "HiFi" as a default usecases. I am able to successfully run 'alsaucm -c chtmax98090 set _verb HiFi', however, I am still unable to get audio from this device. Attempts to use 'aplay' result in the same error shown above: ALSA lib pcm_dmix.c:1052:(snd_pcm_dmix_open) unable to open slave aplay: main:788: audio open error: No such file or directory Please advise on what the next step might be for debugging this further. It'd be nice to get this new driver up and working. On the off chance anyone is at ELC this week, I'll be around with a laptop which has the problem.
Vinod is at ELC, hint hint wink wink... I am supposed to received one of those Rambi devices sometime this month, in the mean time I also need to check how well this driver works with a Cyan CHT-based Chromebook. Maybe there is something wrong with the driver in the first place...
Well, I tried to find Vinod at ELC and failed, so any further debugging tips that can help us move forward on this is most appreciated.
What would really help is for someone to take the 'old' driver and build a matching UCM file that is known to work for headphone, speaker, headset and internal mic endpoints. I am unable to figure out based on the asound.state what is or is not required to configure the codec and for what endpoint. A shell script is fine as well as long as there are clear indication as to which configuration does what. I created an UCM file based on the ChromeOS reference but I have no idea if it works in the first place. If/when we have control settings that are known to work, then we can debug clocks/connections settings and make progress. the same settings should work both on Rambi and Cyan since it's the same codec and the hardware configuration is identical (SSP2+I2S 16 bits)
For your convenience: the patch below allows to build both the new and the old drivers when you set CONFIG_SND_SOC_INTEL_LEGACY_MACH=y. By passing snd-soc-sst-dsp.bind_legacy=1 option, the old driver will be bound. As default when ACPI is set, the new driver is bound. (Note: only compile-tested, so far!)
Created attachment 254917 [details] Patch to allow to build both old and new BYT drivers
Hey Takashi, how do I pass "snd-soc-sst-dsp.bind_legacy = 1" option?
(In reply to Takashi Iwai from comment #95) > Created attachment 254917 [details] > Patch to allow to build both old and new BYT drivers Hi. I'm gonna see if I can build with this patch on my archlinux system, but I noticed a small typo, I assume SND_SOC_TINTEL_BAYTRAIL is supposed to be SND_SOC_INTEL_BAYTRAIL regards
Failing to patch. Guess I'm too much kernel noob. -- patching file sound/soc/intel/Kconfig Hunk #1 FAILED at 93. Hunk #2 succeeded at 110 with fuzz 2 (offset 4 lines). 1 out of 2 hunks FAILED -- saving rejects to file sound/soc/intel/Kconfig.rej --
Ok, I came back to this, finally figured what was wrong. Compiled a fresh arch kernel with this patch (patched fine, added the new legacy option), compiled ok, installed it, added the snd-soc-sst-dsp.bind_legacy=1 kernel option, rebooted. Got the same old "dummy output". Only hdmi detected. Same problems as with default kernels.