Bug 187331
|
Description
Alexander_Zh
2016-11-08 21:38:24 UTC
Please use the upstream firmware, the _ssp0 version is NOT needed Also provide the dsdt and dmesg log Created attachment 244051 [details]
DSDT original
Created attachment 244061 [details]
DSDT decompiled
Created attachment 244071 [details]
journalctl -k kernel messages all
Currently I have the following firmware: # ls -l /lib/firmware/intel/*.bin -rw-rw-rw- 1 zhiraf users 701622 Окт 17 00:28 /lib/firmware/intel/fw_sst_0f28.bin -rw-rw-rw- 1 zhiraf users 701614 Сен 24 2015 /lib/firmware/intel/fw_sst_22a8.bin -rw-r--r-- 1 root root 260320 Сен 24 2015 /lib/firmware/intel/IntcSST2.bin The file fw_sst_0f28.bin was renamed from fw_sst_0f28_ssp0.bin All attached logs correspond to these fw files. Will try the ones without _ssp0 and report. the firmware rename is likely the issue, it changes the routing to SSP0 which is usually not connected on Baytrail platforms (intel_sst_acpi 80860F28:00: BYT-CR not detected means you are on an older version where SSP2 is connected). this _ssp0 file was needed on baytrail-CR platforms in the past but with the update in v4.9 the baseline file can (and should be) used as is Yes I got sound! Removed old fw_sst_0f28.bin Took 2 files: fw_sst_0f28.bin fw_sst_0f28.bin-48kHz_i2s_master from https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/intel And sound is working fine, both channels. Continue testing, it will take a while. Pierre-Louis, thank you so much! Hello, sound does work, but microphone doesn't. To get all working I am trying with 4.11-rc7 kernel. No patches. Sound card is not detected: bytcr_rt5640 bytcr_rt5640: quirk DMIC1_MAP enabled bytcr_rt5640 bytcr_rt5640: quirk DMIC enabled bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled bytcr_rt5640 bytcr_rt5640: ASoC: CODEC DAI rt5640-aif1 not registered bytcr_rt5640 bytcr_rt5640: devm_snd_soc_register_card failed -517 bytcr_rt5640 bytcr_rt5640: quirk DMIC1_MAP enabled bytcr_rt5640 bytcr_rt5640: quirk DMIC enabled bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled bytcr_rt5640 bytcr_rt5640: ASoC: CODEC DAI rt5640-aif1 not registered bytcr_rt5640 bytcr_rt5640: devm_snd_soc_register_card failed -517 how can I fix it? looks like you have a problem with the codec driver. Can you add the entire dmesg as an attachment? And if things worked before and there is a regression you will have to run git bisect to provide us with more data on what the root cause is. Created attachment 255997 [details]
dmesg with kernel 4.11 rc7
Hello Pierre, in <source>/sound/soc/intel/boards/bytcr_rt5640.c there are lines: DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100TA") and DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "T100TAF") None of them are activated on T200TAC I am using. Do I need to change one of them to T200TAC? bytcr_rt5640.c is compiled byt_rt5640.c is not compiled - is it correct? yes byt_rt5640 should not be compiled. That said, I don't understand your point on the DMI match, if your device had sound before then I don't see how those references help. without a git bisect I won't be able to provide any guidance i am afraid, there were just too many changes since November. Pierre, I am learning git and working on bisect. Please advise: when I test a new kernel do I need to delete alsa state file? Maybe any other actions are required to make sure the problem is in kernel and not in some external settings? Thank you. if you are using UCM w/ PulseAudio I don't think you need to change or alter the asound.state, I never touch this file. As the first point I plan to check if the following commits (dated Jan 27 2017, 4.10.0-rc1) were good for my device: 282a4e4ce5f99e3c166abac929498885a711e19f platform/x86: Enable Atom PMC platform clocks 80a7581f38c0b2e83dc883a2125340b90b5635ec arch/x86/platform/atom: Move pmc_atom to drivers/platform/x86 1141d9d08184565b71a943a50ffe712b2dfc697f clk: x86: Add Atom PMC platform clocks f35b6542c3ac3f28056d298348a81f7d56d3a041 clk: Make x86/ conditional on CONFIG_COMMON_CLK These commits do the same as patch did (I suspect). So after them kernel should provide sound without patches. It will be a start point to run bisect later. I took the state after them, will compile and see if kernel without patches is ok. So I did: git checkout 4e0a90b381bd8bddf1644591dc585cf4c6ea652e compiling kernel... Created attachment 256137 [details]
dmesg with kernel 4.10.0-rc7 (Jan 27 state)
bytcr_rt5640 bytcr_rt5640: quirk DMIC1_MAP enabled
bytcr_rt5640 bytcr_rt5640: quirk DMIC enabled
bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled
bytcr_rt5640 bytcr_rt5640: Failed to get MCLK from pmc_plt_clk_3: -2
bytcr_rt5640: probe of bytcr_rt5640 failed with error -2
I used to deal with this problem by applying the patch...
Created attachment 256333 [details]
4.10rc1 kernel with patch (v12) - dmesg
Applied the patch (mentioned above) and here is the key output:
bytcr_rt5640 bytcr_rt5640: quirk DMIC1_MAP enabled
bytcr_rt5640 bytcr_rt5640: quirk DMIC enabled
bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled
bytcr_rt5640 bytcr_rt5640: ASoC: CODEC DAI rt5640-aif1 not registered
bytcr_rt5640 bytcr_rt5640: devm_snd_soc_register_card failed -517
it's the same message as for 4.11rc7 I tested before.
So this 4.10rc1+patch version as "bad".
sorry, you are not providing any data that helps identify when the solution worked and when it stopped working. The dmesg above shows the codec driver did not complete the DAI registration and you have to look into this by - running alas-info.sh to show what is loaded - make sure RT5640 is compiled in as a module - check that ACPI creates the right device in /sys/bus/acpi/device/10EC5640 - check the dais in /sys/debug/kernel/asoc Created attachment 256337 [details]
4.10rc1 kernel with patch (v12) - alsa-info.sh output
Please find alsa-info.sh output attached.
# lsmod | grep snd
snd_soc_sst_bytcr_rt5640 20480 0
snd_intel_sst_acpi 16384 1
snd_soc_rt5640 118784 1 snd_soc_sst_bytcr_rt5640
snd_intel_sst_core 77824 1 snd_intel_sst_acpi
snd_soc_sst_mfld_platform 102400 1 snd_intel_sst_core
snd_soc_rl6231 16384 1 snd_soc_rt5640
snd_soc_core 204800 3 snd_soc_sst_bytcr_rt5640,snd_soc_rt5640,snd_soc_sst_mfld_platform
snd_soc_sst_match 16384 2 snd_soc_sst_bytcr_rt5640,snd_intel_sst_acpi
snd_compress 20480 1 snd_soc_core
snd_pcm 122880 4 snd_soc_sst_bytcr_rt5640,snd_soc_rt5640,snd_soc_sst_mfld_platform,snd_soc_core
snd_timer 32768 1 snd_pcm
snd 86016 5 snd_compress,snd_timer,snd_soc_sst_mfld_platform,snd_soc_core,snd_pcm
soundcore 16384 1 snd
ls -l /sys/bus/acpi/devices/ | grep 5640
lrwxrwxrwx 1 root root 0 Май 9 22:25 10EC5640:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/80860F41:01/10EC5640:00
Sorry, in my .config:
CONFIG_DEBUG_INFO is not set
CONFIG_DEBUG_KERNEL=y
there is no /sys/debug directory.
Should I re-compile?
Created attachment 256339 [details]
4.08.0 kernel with patch - sound works - alsa-info.sh out
Adding alsa-info.sh output from 4.8.0 kernel+patch with sound working.
Sorry, I did not mention it here, When I got sound I took sound/soc source files from your repository t100taf-7 https://github.com/plbossart/sound/tree/t100taf-7 as far as I remember... I experimented a lot. Created attachment 256341 [details]
4.08.0 kernel with patch - sound works - /sys/kernel/debug info
Created attachment 256343 [details]
4.10rc1 kernel with patch (v12) - /sys/kernel/debug/asoc info
If any other data is needed please let me know
the last information on /sys/kernel/debug/asoc shows that the codec driver did not complete its probe and did not register any DAI, so indeed the machine driver cannot figure out what is happening and register the sound card. You must have something bad in the codec driver, this should be where you need to debug. try adding traces in the rt5640.c code. Created attachment 256349 [details]
4.08.0 kernel (kernel.org) with patch (v13) - dmesg
I made another test with 4.8.0 kernel from kernel.org + patch. Sound works.
So this is "good" version.
still doesn't tell me what went wrong, you need to tell us what happened between the good and bad versions, and specifically how come the codec driver doesn't register the DAIs. I made attempts to add "traces" to rt5640.c but they are not working. Can you please give example of the code that I should add? enable dynamic debug and/or add some printks in rt5640.c to show that the codec registration goes through http://elixir.free-electrons.com/linux/latest/source/sound/soc/codecs/rt5640.c#L2430 Created attachment 256499 [details]
rt5640.c with traces (v14)
Added some "traces". Compilation went fine. Is it what was needed?
rt5640.c attached. Below is an example of what I added:
static int rt5640_i2c_probe(struct i2c_client *i2c,
const struct i2c_device_id *id)
{
struct rt5640_platform_data *pdata = dev_get_platdata(&i2c->dev);
struct rt5640_priv *rt5640;
int ret;
unsigned int val;
dev_err(&i2c->dev, "--- 09 rt5640_i2c_probe begin ---\n");
dev_err(&i2c->dev, "--- ============================= ---\n");
rt5640 = devm_kzalloc(&i2c->dev,
sizeof(struct rt5640_priv),
GFP_KERNEL);
...
Created attachment 256501 [details]
4.11.0 kernel (no patches) (v14) - dmesg
Sorry, my "traces" did not appear in dmesg.
What should I write to see it in dmesg?
Created attachment 256511 [details]
rt5640.c with traces (v14m02) - printk() added
Added printk() traces. Example:
printk(KERN_INFO "--- 10 before snd_soc_register_codec \n");
Created attachment 256513 [details]
4.11.0 kernel (no patches) (v14m02) - printk() traces - dmesg
printk() messages did not appear in dmesg
I studied snd-soc-rt5640.ko and found my added messages there.
My printk() are not executed.
Created attachment 256519 [details]
4.11.0 kernel (no patches) (v14m03) - printk() traces in soc-core.c - dmesg
Added some printk() to sound/soc/soc-core.c Now I see them in dmesg.
But printk() output I added to rt5640.c still does not appear.
What else can I change?
it could be that either you don't have the right log level or the probe doesn't get executed. I'd use KERN_ERR to be on the safe side. Assuming the latter case, if the probe isn't executed then something is very wrong with ACPI. You'd really need to run a bisect to tell us when things start to go wrong. Changed to KERN_ERR, added more printk(). No messages from rt5640.c in dmesg. Added printk() traces to bytcr_rt5640.c, got messages in dmesg. My plan is to trace all sound-related modules to clarify what is the last executed function. Working on it. When I finish here, will do a bisect. Created attachment 256611 [details]
4.11.0 kernel (no patches) (v14m07) - dai names output - dmesg
Added a lot of printk's. Marked the functions connected with DAI registering.
DAI name, DAI driver (dai_drv) and device (dev_name) names are output.
Example:
---[soc-core.c] snd_soc_register_dais
---[soc-core.c] snd_soc_dai ^^^ soc_add_dai --- begin
---[soc-core.c] ASoC: dynamically register DAI dev_name sst-mfld-platform
---[soc-core.c] snd_soc_dai ^^^ soc_add_dai --- dai_drv name media-cpu-dai
etc..
DAI names:
ASoC: Registered DAI 'snd-soc-dummy-dai'
ASoC: Registered DAI 'media-cpu-dai'
ASoC: Registered DAI 'deepbuffer-cpu-dai'
ASoC: Registered DAI 'compress-cpu-dai'
ASoC: Registered DAI 'ssp0-port'
ASoC: Registered DAI 'ssp1-port'
ASoC: Registered DAI 'ssp2-port'
After all of them registered the following functions are executed, but only 4 times:
---[soc-core.c] snd_soc_dai ^^^ snd_soc_find_dai
---[soc-core.c] soc_bind_dai_link - Find CODEC from registered CODECs
---[soc-core.c] snd_soc_dai ^^^ snd_soc_find_dai
---[soc-core.c] soc_add_pcm_runtime
---[soc-core.c] soc_bind_dai_link ---AZkv14m07
---[soc-core.c] soc_is_dai_link_bound
---[soc-core.c] snd_soc_pcm_runtime ^^^soc_new_pcm_runtime
Probably after registering 'compress-cpu-dai' the message appears:
bytcr_rt5640 bytcr_rt5640: ASoC: CODEC DAI rt5640-aif1 not registered
...as far as I understand.
Does it give any clue?
What parameters should I output?
To repeat myself, the codec probe does not happen and the rt5640-aif1 DAI is not registered. So you need to bisect and find out why this probe in rt5640.c isn't executed and why this used to work before. The rest of the traces just confirm the rest of the system looks fine. Made 3 bisect iterations:
> git bisect log
git bisect start
# bad: [8fa3b6f9392bf6d90cb7b908e07bd90166639f0a] Merge tag 'cris-for-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris
git bisect bad 8fa3b6f9392bf6d90cb7b908e07bd90166639f0a
# good: [c8d2bc9bc39ebea8437fd974fdbc21847bb897a3] Linux 4.8
git bisect good c8d2bc9bc39ebea8437fd974fdbc21847bb897a3
# good: [d4e65476bc68dbc9231b3c772b71f1576579b6fb] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
git bisect good d4e65476bc68dbc9231b3c772b71f1576579b6fb
# good: [44dc8c9d685a2b7c9d4f5a87c746799c80aa53f0] Merge tag 'platform-drivers-x86-v4.9-1' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
git bisect good 44dc8c9d685a2b7c9d4f5a87c746799c80aa53f0
Sorry, the 4th iteration 4.9-rc5 has broken EFI stub, so I cannot boot it.
Working on it.
Created attachment 256777 [details] git bisect log - complete Bisect completed. Resulting output: 67bf5156edc4f58241fd7c119ae145c552adddd6 is the first bad commit commit 67bf5156edc4f58241fd7c119ae145c552adddd6 Author: David Arcari <darcari@redhat.com> Date: Wed Oct 12 18:40:30 2016 +0200 gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get() acpi_dev_gpio_irq_get() currently ignores the error returned by acpi_get_gpiod_by_index() and overwrites it with -ENOENT. Problem is this error can be -EPROBE_DEFER, which just blows up some drivers when the module ordering is not correct. Cc: stable@vger.kernel.org Signed-off-by: David Arcari <darcari@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> :040000 040000 bb2c49225606d2196a807317bf5ab727838d16a9 345df96f1b221ff6bc04dae809e8aee1af3d0bf1 M drivers bisect log is attached. On every bisect iteration I applied the patch mentioned above, compiled and tested. Created attachment 256779 [details]
The patch which make sound work for kernel 4.8
Attaching the patch for completeness and clarity.
(In reply to Alexander_Zh from comment #39) > Created attachment 256777 [details] > git bisect log - complete > > Bisect completed. > Resulting output: > 67bf5156edc4f58241fd7c119ae145c552adddd6 is the first bad commit > commit 67bf5156edc4f58241fd7c119ae145c552adddd6 > Author: David Arcari <darcari@redhat.com> > Date: Wed Oct 12 18:40:30 2016 +0200 > > gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get() > > acpi_dev_gpio_irq_get() currently ignores the error returned > by acpi_get_gpiod_by_index() and overwrites it with -ENOENT. > > Problem is this error can be -EPROBE_DEFER, which just blows > up some drivers when the module ordering is not correct. > > Cc: stable@vger.kernel.org > Signed-off-by: David Arcari <darcari@redhat.com> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> > Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> > Signed-off-by: Linus Walleij <linus.walleij@linaro.org> To be clear, if you take 4.11 and revert this patch does audio work well for you? > :040000 040000 bb2c49225606d2196a807317bf5ab727838d16a9 > 345df96f1b221ff6bc04dae809e8aee1af3d0bf1 M drivers > > bisect log is attached. > On every bisect iteration I applied the patch mentioned above, compiled and > tested. Pierre, git revert 67bf5156edc4f58241fd7c119ae145c552adddd6 error: could not revert 67bf515... gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get() hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit' how do I fix it? Pierre, I compiled v4.12-rc3 without any patches. Did not revert any commit. Changed make .config. Sound works. bytcr_rt5640 bytcr_rt5640: quirk DMIC1_MAP enabled bytcr_rt5640 bytcr_rt5640: quirk DMIC enabled bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled bytcr_rt5640 bytcr_rt5640: snd-soc-dummy-dai <-> media-cpu-dai mapping ok bytcr_rt5640 bytcr_rt5640: snd-soc-dummy-dai <-> deepbuffer-cpu-dai mapping ok compress asoc: snd-soc-dummy-dai <-> compress-cpu-dai mapping ok bytcr_rt5640 bytcr_rt5640: rt5640-aif1 <-> ssp2-port mapping ok Did you solve the issue? I have not contributed any patches, it's likely that your config was borked. I changed only network and video - related items, to cut the compilation time. Did not touch sound and ACPI. Will compile with old config and report. Hi, Compiled kernel v4.12rc3 with my old .config (used for bisect) - sound is not working. The same problem. Also compiled v4.9 which was the oldest "bad" version for bisect. Used my new .config. Patched as usual. Sound is working. So it does depend on kernel .config. Will study more options later. Pierre, if you need any specific information please let me know. Pierre, can you please help me with microphone. I checked all levels and tested it with arecord - no recording. check if the INP1 or INP3 microphone quirks works for your platform. There's no way to detect it, so you either add a quirk in the code or use the new kernel module parameter added by Takashi |