Baytrail-T: there is no sound with ASUS T100TAF kernel 3.17 OS: Linpus OS based on Fedora Audio HW: ealtek I2S Audio C.SALC5642-CGTQFN-48//REALTEK rt5640 can not load. If you need any information, please let me know.
At least, we nee to know how it's reported. Is the module properly configured and built at all? Some patches for BYT r5640 stuff have been merged first since 3.18-rc1, so you should try 3.18-rc1, too.
(In reply to Takashi Iwai from comment #1) > At least, we nee to know how it's reported. Is the module properly > configured and built at all? > -->Eva Reply: please refer attachment kernel .config. > Some patches for BYT r5640 stuff have been merged first since 3.18-rc1, so > you should try 3.18-rc1, too. --Eva Reply: there is no 3.18-rc1 from www.kernel.org, where get the 3.18-rc1 now? Thanks a lot!
Created attachment 154271 [details] .config
(In reply to Eva Wang from comment #2) > (In reply to Takashi Iwai from comment #1) > > At least, we nee to know how it's reported. Is the module properly > > configured and built at all? > > -->Eva Reply: please refer attachment kernel .config. > > Some patches for BYT r5640 stuff have been merged first since 3.18-rc1, so > > you should try 3.18-rc1, too. > --Eva Reply: there is no 3.18-rc1 from www.kernel.org, where get the > 3.18-rc1 now? Thanks a lot! Use git, or look through ftp.kernel.org. It's in the usual testing directory.
(In reply to Takashi Iwai from comment #4) > (In reply to Eva Wang from comment #2) > > (In reply to Takashi Iwai from comment #1) > > > At least, we nee to know how it's reported. Is the module properly > > > configured and built at all? > > > -->Eva Reply: please refer attachment kernel .config. > > > Some patches for BYT r5640 stuff have been merged first since 3.18-rc1, > so > > > you should try 3.18-rc1, too. > > --Eva Reply: there is no 3.18-rc1 from www.kernel.org, where get the > > 3.18-rc1 now? Thanks a lot! > > Use git, or look through ftp.kernel.org. It's in the usual testing > directory. OK, we will try, could you help to check whether the .config is right for RT5640? Thanks!
Config looks ok for T100 audio. What comes to my mind is there firmware for audio DSP installed under /lib/firmware/intel? There are following error messages in the kernel log in case it's missing: [ 3.572583] sst-acpi 80860F28:00: Direct firmware load for intel/fw_sst_0f28.bin-48kHz_i2s_master failed with error -2 [ 3.572637] sst-acpi 80860F28:00: Cannot load firmware intel/fw_sst_0f28.bin-48kHz_i2s_master The firmware blob can be found from the following linux-firmware commit: https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=7551a3a78453abb8a66ae26a98b715189119a3fc
Created attachment 154541 [details] 3.18-rc1 kernel dmesg User kernel 3.18-rc1, the message show: [ 14.728781] sst-acpi 80860F28:00: No matching ASoC machine driver found. I wonder what's the driver, snd-soc-sst-byt-rt5640-mach, or snd-soc-rt5640? I modprobe both of them. But it doesn't work.
Both are needed. snd-soc-rt5640 is a driver for RT5640 audio codec chip and snd-soc-sst-byt-rt5640-mach is a driver describing how RT5640 is wired in Baytrail machines. Above error indicates there is no 10EC5640 ACPI device which is ACPIID for RT5640 codec on Baytrail machines. Can you see /sys/bus/acpi/devices/10EC5640\:00/ directory in your system and if yes, what "cat /sys/bus/acpi/devices/10EC5640\:00/status" says? One possibility could be if T100TAF doesn't have RT5640 codec like T100TA. Could you attach here /sys/firmware/acpi/tables/DSDT. Then we could parse it with "iasl -d DSDT" to see if there is another ACPIID for the codec.
Created attachment 154701 [details] /sys/firmware/acpi/tables/DSDT I didn't find /sys/bus/acpi/devices/10EC5640\:00/, but find /sys/bus/acpi/devices/10EC5642\:00/. cat /sys/bus/acpi/devices/10EC5642\:00/status, say 15. Attached /sys/firmware/acpi/tables/DSDT
Created attachment 154791 [details] 1/3 ASoC: rt5640: Add RT5642 ACPI ID for Intel Baytrail
Created attachment 154801 [details] 2/3 ASoC: Intel: Cover RT5642 based machine drivers with byt-rt5640
Created attachment 154811 [details] 3/3 ASoC: Intel: byt-rt5640: Add quirk for Asus T100TAF
Created attachment 154821 [details] Mixer configuration for Asus T100TA to be tried on T100TAF
You you try the three patches I attached? I added them for supporting ACPI ID "10EC5642" for the codec chip with existing drivers. Based on ID it seems Asus T100TAF uses RT5642. As far as I know RT5642 and RT5640 are quite similar and I also assumed in the last patch that T100TAF uses the same audio setup than T100TA. I attached also my mixer configuration for T100TA with all integrated speakers, microphone, headphone output and headset microphone enabled. You could try with a test below do different inputs and outputs work: alsactrl restore -f t100_g.state arecord -f dat |aplay I'm especially interested to hear does integrated microphone work. Asus T100TA uses analogue microphone and some other machines digital one. If integrated microphone doesn't work, then we have to hack more with patch 3/3.
After added the three patches, there is still no sound. please refer the dmesg.log, lsmod.log. dmesg: [ 12.305007] baytrail-pcm-audio baytrail-pcm-audio: ipc: error DSP boot timeout [ 12.529327] byt-rt5640 byt-rt5640: ASoC: CPU DAI baytrail-pcm-audio not registered [ 12.529347] platform byt-rt5640: Driver byt-rt5640 requests probe deferra lsmod: snd_soc_sst_baytrail_pcm 25726 0 snd_soc_rt5640 93244 1 snd_soc_sst_byt_rt5640_mach snd_soc_sst_dsp 34014 1 snd_soc_sst_baytrail_pcm snd_soc_rl6231 13037 1 snd_soc_rt5640 snd_soc_core 201170 3 snd_soc_rt5640,snd_soc_sst_baytrail_pcm,snd_soc_sst_byt_rt5640_mach when run below command: [user@localhost ~]$ alsactl restore -f t100_g.state alsactl: load_state:1686: No soundcards found... [user@localhost ~]$ arecord -f dat | aplay Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stere --No sound output from internal or external microphone.
Created attachment 155321 [details] dmesg.log
Created attachment 155331 [details] lsmod
Created attachment 155341 [details] Hack patch that takes DSP-host interrupt from another index I noticed interesting thing. DSP-host interrupt is defined in another index in T100TAF DSDT table than all other machines I've seen. Could you add attached hack patch on top of previous three to see can it make DSP booting?
Created attachment 155571 [details] dmesg1.log Please refer dmesg1.log after added the patch. Thanks!
Hmm.. looks like DSP initialization got forward but appears to broke SDHCI. Could you add here content of /proc/interrupt. Just thinking if they share the same interrupt and if these drivers don't play well together.
Created attachment 155761 [details] interrupts attached the file /proc/interrupts.
(In reply to Jarkko Nikula from comment #18) > Created attachment 155341 [details] > Hack patch that takes DSP-host interrupt from another index > > I noticed interesting thing. DSP-host interrupt is defined in another index > in T100TAF DSDT table than all other machines I've seen. Could you add > attached hack patch on top of previous three to see can it make DSP booting? I see similar behaviour on my Teclast X98 Air 3G (Bay Trail-T Z3736F, sound is identical). Using your patch baytrail-pcm-audio gets initialized and I can control properties using alsamixer. My SDHCI is still working, but I am using adapted SDHCI patch by Jon Pry for Bay Trail-T platform. I will attach patch here for reference.
Created attachment 156331 [details] SDHCI patch for Baytrail-T
Created attachment 156361 [details] dmesg Yes, I applied the SDHCI patch for Baytrail-T. And get attached dmesg log.
It seems you may not have the needed codec activated in your kernel config. Please check if you enabled CONFIG_SND_SOC_RT5640 (zgrep CONFIG_SND_SOC /proc/config.gz). Afterwards the DSP should bootup correctly. For my device, the provided state file does not provide any output. But then again this maybe only true for my device and you could have more luck than me.
(In reply to Fabian Zaremba from comment #25) > > For my device, the provided state file does not provide any output. But then > again this maybe only true for my device and you could have more luck than > me. Does AudioDSP in /proc/interrupts count while playing? I guess it counts since initialization succeeded. If it counts it could be possible that machine has different audio output routings after codec chip. About my hack patch and SDHCI: did my patches caused the SDHCI problem or was it before since according to /proc/interrupts they seems to not share same irq at least.
(In reply to Jarkko Nikula from comment #26) > Does AudioDSP in /proc/interrupts count while playing? I guess it counts > since initialization succeeded. There seem to be no reference to AudioDSP in /proc/interrupts at all although initialization seems to have succeeded. I will attach the output here along with my dmesg. > If it counts it could be possible that machine has different audio output > > routings after codec chip. I too suppose output routing may not be compatible to ASUS devices. Is there any way to determine correct settings besides manually probing alsamixer? I was only able to produce fuzzing white noise instead of sound on both speakers until now. > About my hack patch and SDHCI: did my patches caused the SDHCI problem or > was it before since according to /proc/interrupts they seems to not share > same irq at least. I did not try your hack patch without the SDHCI fix, so I can't really tell if it would cause problems on its own - Maybe Eva Wang can elaborate on this. Prior to the SDHCI patch I posted I had no access to SDIO cards (e.g. wireless in this tablet), but also no errors like in dmesg attachment #155571 [details].
Created attachment 156461 [details] /proc/interrupts while playing sound on RT5642 Lack of AudioDSP - see comment #27
Created attachment 156471 [details] 3.18rc2 kernel log with RT5642 sound init With applied hack patch attachment #155341 [details] and SHDCI patch attachment #156331 [details]
(In reply to Fabian Zaremba from comment #27) > (In reply to Jarkko Nikula from comment #26) > > > Does AudioDSP in /proc/interrupts count while playing? I guess it counts > > since initialization succeeded. > > There seem to be no reference to AudioDSP in /proc/interrupts at all > although initialization seems to have succeeded. I will attach the output > here along with my dmesg. > Was this the latest dmesg? I saw from it that DSP initialization failed: [ 7.085357] baytrail-pcm-audio baytrail-pcm-audio: ipc: error DSP boot timeout That made me thinking if your device has DSP interrupt configured in different index than Asus T100TAF or other Baytrail machines. Could you upload /sys/firmware/acpi/tables/DSDT from your device here? > > If it counts it could be possible that machine has different audio output > > routings after codec chip. > > I too suppose output routing may not be compatible to ASUS devices. Is there > any way to determine correct settings besides manually probing alsamixer? I > was only able to produce fuzzing white noise instead of sound on both > speakers until now. > Unfortunately not, it's often reverse engineering by going through mixer controls in case the schematics are not available :-(
(In reply to Jarkko Nikula from comment #30) > Was this the latest dmesg? I saw from it that DSP initialization failed: > > [ 7.085357] baytrail-pcm-audio baytrail-pcm-audio: ipc: error DSP boot > timeout This was the error I received earlier when the DSP would not boot at all. I unfortunately did not search for it after the DSP initialization looked like it was completed. > That made me thinking if your device has DSP interrupt configured in > different index than Asus T100TAF or other Baytrail machines. > > Could you upload /sys/firmware/acpi/tables/DSDT from your device here? Sure - I'll attach binary DSDT here. I uploaded `iasl -d DSDT.dat` decompiled output to clbin: https://clbin.com/MiZug > Unfortunately not, it's often reverse engineering by going through mixer > controls in case the schematics are not available :-( Alright - but I guess, reverse engineering mixer settings seems acceptable compared to the effort to get all the hardware running properly in kernel :) Thanks for your help!
Created attachment 157121 [details] Binary DSDT from Teclast X98 Air 3G DSDT from "Windows mode" firmware (Teclast official release)
Hi All, could you help to update the issue status. is there any solution now? Thanks!
(In reply to Eva Wang from comment #33) > Hi All, could you help to update the issue status. is there any solution > now? Thanks! Not really :-( Fabian's Teclast X98 Air 3G has DSP-host interrupt defined at the same index than Asus T100TAF but it looks it doesn't run after initialization. Eva, danielzhao: I see from you logs that DSP got initialized and there's AudioDSP listed in /proc/interrupts. Does it count if you try to play or record or does it behave the same?
(In reply to Jarkko Nikula from comment #34) > Fabian's Teclast X98 Air 3G has DSP-host interrupt defined at the same index > than Asus T100TAF but it looks it doesn't run after initialization. I upgraded my test kernel to 3.18rc5 today (including some patches along with yours) and I now see an AudioDSP line in /proc/interrupts and it does actually count up for CPU0 while playing music. You can find the new one cat'ed after ~6 minutes of playing here: https://clbin.com/oPLKN Sadly, this didn't change the fact that I was not yet able to get audio out of the device. The only thing I found making a difference in alsamixer is unmuting "DAC MIXL Stereo ADC" - both speakears start making white noise if it is not muted. The other channels don't seem to make much a difference.
(In reply to Fabian Zaremba from comment #35) > I upgraded my test kernel to 3.18rc5 today (including some patches along > with yours) and I now see an AudioDSP line in /proc/interrupts and it does > actually count up for CPU0 while playing music. You can find the new one > cat'ed after ~6 minutes of playing here: https://clbin.com/oPLKN > Great, it indicates then that DSP is operating. > Sadly, this didn't change the fact that I was not yet able to get audio out > of the device. The only thing I found making a difference in alsamixer is > unmuting "DAC MIXL Stereo ADC" - both speakears start making white noise if > it is not muted. The other channels don't seem to make much a difference. So there is path to speakers if left ADC to DAC bypass makes noise. Which makes me thinking is there something different between DSP and codec connection. RT564x has two I2S interfaces and two pair of ADC and DAC. My t100_g.state uses IF1 and ADC/DAC L1/R1 blocks. Have you tried to toggle those IF2 and L2/R2 knobs do they make any difference?
(In reply to Jarkko Nikula from comment #36) > Great, it indicates then that DSP is operating. This is serious good news for this device! > RT564x has two I2S interfaces and two pair of ADC and DAC. My t100_g.state > uses IF1 and ADC/DAC L1/R1 blocks. Have you tried to toggle those IF2 and > L2/R2 knobs do they make any difference? I have tried about an hour to switch all IF1, IF2, L1 & R1 switches I could find, which made no difference. I tried probing settings by unmuting channels and switching interfaces, but the device only started to make strange distorted noise (without correlation to the music playing). At this point I reverted to your t100_g.state which caused it to make a loud, power-drain like sound. I am afraid to destroy the audio chip or speakers in this device with mindless probing, as I have read from earlier forum posts that it is possible to do harm the device with wrong mixer settings. I tried sending an inquiry about audio routing on this device to Teclast customer support, maybe they could release audio routing informations to you for inspection.
(In reply to Fabian Zaremba from comment #37) > I have tried about an hour to switch all IF1, IF2, L1 & R1 switches I could > find, which made no difference. I tried probing settings by unmuting > channels and switching interfaces, but the device only started to make > strange distorted noise (without correlation to the music playing). At this > point I reverted to your t100_g.state which caused it to make a loud, > power-drain like sound. > Looks like samples don't reach the codec DAC for a reason or another and sound/noise is coming only from bypass path from not-connected or pulled down/up input pin to output. > I am afraid to destroy the audio chip or speakers in this device with > mindless probing, as I have read from earlier forum posts that it is > possible to do harm the device with wrong mixer settings. > Yeah, good to keep in mind. Speakers can be DC connected and in case DAC or input bypass drives constant minimum or maximum value to speaker amplifier stage there won't be any sound since amplifier drives constant voltage to speakers (thus causing just the heat). I've seen such a cases in the past and only indication about that was click sound when toggling a mixer controls and high current consumption. > I tried sending an inquiry about audio routing on this device to Teclast > customer support, maybe they could release audio routing informations to you > for inspection. Hopefully we hear them.
Created attachment 158311 [details] ASoC: Intel: Cover RT5642 based machine drivers with byt-rt5640 (part #2) Hi Eva and danielzhao. I noticed I didn't change codec name from "i2c-10EC5640:00" to i2c-10EC5642:00" for Asus T100TAF and thus driver binding will fail. Could you try this patch on top of previous 1-3 and hack patch.
Created attachment 158761 [details] dmesg_1125.log Hi Jarkko Nikula. there is still no sound after added these patches. please refer dmesg_1125.log
Hi Eva. I forgot to ask for your last comment that did you see audio card in /proc/asound/cards and was "grep DSP /proc/interrupts" counting while playing? According to your dmesg initialization succeeded: "[ 12.138363] byt-rt5640 byt-rt5640: rt5640-aif1 <-> baytrail-pcm-audio mapping ok".
I have tested no less than five separate models of Intel Baytrail-based devices that also have no sound with these errors. Curiously, they will load this firwmare version and create a sound device though (no working playback): https://chromium.googlesource.com/chromiumos/third_party/linux-firmware/+/refs/heads/stabilize-5339.B/intel/ This issue is of particular importance to me. Should I start a new bug thread or continue in this one?
(In reply to Bobby Budnick from comment #42) > I have tested no less than five separate models of Intel Baytrail-based > devices that also have no sound with these errors. > Curiously, they will load this firwmare version and create a sound device > though (no working playback): > https://chromium.googlesource.com/chromiumos/third_party/linux-firmware/+/ > refs/heads/stabilize-5339.B/intel/ Interesting. Did you have otherwise the same setup but with "fw_sst_0f28.bin-48kHz_i2s_master" firmware DSP doesn't initialize but with "fw_sst_0f28.bin-i2s_master" (e.g. by symlinking) it does? Did you use the "Hack patch that takes DSP-host interrupt from another index" attached to this bug? https://bugzilla.kernel.org/attachment.cgi?id=155341 These newer Win8.1 (?) based machines seems to define DSP->host interrupt in the first interrupt resource entry where it has been 6th before and 6th becomes now the SSP2 interrupt (drives I2S link between DSP and codec). Just a guesswork from my side but thinking can older Chromium firmware tick also other SSP2 interrupt while booting up which is then faulty triggered as DSP->host interrupt if the hack patch is not included. > This issue is of particular importance to me. Should I start a new bug > thread or continue in this one? Let's keep tracking here until we know if there is some machine specific differences. I guess these initialization and DSP interrupt doesn't count issues can be common to all of these new machines.
Created attachment 160931 [details] T100_B.state I have an ASUS T100TA and i am using the following state, sound works fine for me need to sudo cp the t100_B.state to the /var/lib/alsa/asound.state sound works for me any questions just ask The file had to be modified here in order for the sound to work on the normal t100_B.state sound is switched, left sounds from right and vice versa this makes it normal speakers, left is left, right is right control.20 { iface MIXER name 'ADC IF1 Data Switch' value 'left copy to right' comment { access 'read write' type ENUMERATED count 1 item.0 Normal item.1 'left copy to right' item.2 'right copy to left' item.3 Swap } } control.21 { iface MIXER name 'DAC IF1 Data Switch' value 'left copy to right' comment { access 'read write' type ENUMERATED count 1 item.0 Normal item.1 'left copy to right' item.2 'right copy to left' item.3 Swap } } control.22 { iface MIXER name 'ADC IF2 Data Switch' value 'left copy to right' comment { access 'read write' type ENUMERATED count 1 item.0 Normal item.1 'left copy to right' item.2 'right copy to left' item.3 Swap } } control.23 { iface MIXER name 'DAC IF2 Data Switch' value 'left copy to right' comment { access 'read write' type ENUMERATED count 1 item.0 Normal item.1 'left copy to right' item.2 'right copy to left' item.3 Swap hope that helps
(In reply to Jarkko Nikula from comment #43) > (In reply to Bobby Budnick from comment #42) The good news is that the provided patch works to initialize the sound device with the current firmware. I get the same results as others here with the g and b state files. g - Nothing by default. White noise unrelated to speaker-test when unmuting DAC MIXL Stereo ADC. b - Nothing by default. "Power drain" sound unrelated to speaker-test when unmuting DAC MIXL Stereo ADC. The bad news is as others here have noted, playing with the mixer settings will damage the device permanently and even possibly start a fire. A noticeable amount of smoke and odor was released from my Dell Venue 8 Pro but it is still working fine. The HP Stream 7 device was not so lucky and it's audio hardware was totally destroyed. The current Stream 7 I am testing with has minor damage now too. That said, I feel we are close and I would like to get sound working regardless of the substandard hardware design of these devices. Where should we troubleshoot from here?
(In reply to Bobby Budnick from comment #45) > The bad news is as others here have noted, playing with the mixer settings > will damage the device permanently and even possibly start a fire. A > noticeable amount of smoke and odor was released from my Dell Venue 8 Pro > but it is still working fine. The HP Stream 7 device was not so lucky and > it's audio hardware was totally destroyed. The current Stream 7 I am > testing with has minor damage now too. That said, I feel we are close and I > would like to get sound working regardless of the substandard hardware > design of these devices. Where should we troubleshoot from here? Best would be if we get info from Asus, HP and/or Teclast how the audio HW is actually routed between DSP and codec since samples obviously don't reach the codec and only audio output is noise coming from codec input or when codec is driving the speaker with DC. Then it looks essential to disconnect speaker elements when hacking and perhaps use an oscilloscope to measure signals. Disconnecting the speaker of course voids the warranty :-( I could figure out (purely speculation) two things which could explain why samples don't go between DSP and codec. One if there is some sort of pin multiplexing to SSP port IIS pins (bus between DSP and codec) where pins are dynamically enabled/disabled by Windows driver. Second is if those machines use other than SSP2 port for IIS.
Hi, I tried all patches and now there is no error from dmesg. I even tried to execute alsamixer and aplay... Everythig seems work but... there is still no audio output. No noise, no sound. I can't see any error message from system. Could you please give me any advise how I can go further ?
Created attachment 163921 [details] Stream 7 Hardware Layout
Created attachment 163931 [details] Stream 7 Audio Hardware
I have attached pictures of the HP Stream 7 internals. The first picture is the overall hardware layout and the second picture focuses on the audio hardware. In the second image you can see the speaker leads to the left and the Realtek audio chip in the center. I can take further pictures and/or probe with a multimeter if someone could direct me.
Any update on this? I have a Linx7 tablet running on Arch Libux with the latest Linux-mainline kernel. I used a patch to change the address from the default '5' to '0'. Sorry for not linking, cant find the patch at the moment. My dmesg shows the not registered message, however it shows a pcm successful message after this. The firmware seems to be loaded correctly, and the device is visible in de kde mixer (as baytrail-rt5640), but unfortunately their is no sound outputz even on the headphones. I need to mention that I do run alsa with a patched state for the ASUS tablet. Will provide my dmesg, kernel config, later today. :)
*** Bug 100431 has been marked as a duplicate of this bug. ***
Hi, there have been some advancements on this problem. It is confirmed that at least on the Teclast X98 Air 3G the codec is connected to SSP0, as Jarkko guessed, while the firmware was hardcoded to SSP2. Vinod Koul released a new firmware for SSP0 and sound works with this one. There are still some minor issues, but the main cause of this bug has been found. Check out the details here: http://thread.gmane.org/gmane.linux.alsa.devel/134554/focus=140634 Ciao ciao, Antonio
(In reply to Antonio Ospite from comment #53) > Hi, there have been some advancements on this problem. > > It is confirmed that at least on the Teclast X98 Air 3G the codec is > connected to SSP0, as Jarkko guessed, while the firmware was hardcoded to > SSP2. > > Vinod Koul released a new firmware for SSP0 and sound works with this one. > There are still some minor issues, but the main cause of this bug has been > found. > > Check out the details here: > http://thread.gmane.org/gmane.linux.alsa.devel/134554/focus=140634 > > Ciao ciao, > Antonio could you post your patches that made the sound work? I'm trying to modify the mfld driver and use the ssp0 fw but i just got lots of fw errors
(In reply to Luka Karinja from comment #54) > (In reply to Antonio Ospite from comment #53) [...] > > Check out the details here: > > http://thread.gmane.org/gmane.linux.alsa.devel/134554/focus=140634 [...] > could you post your patches that made the sound work? > I'm trying to modify the mfld driver and use the ssp0 fw but i just got lots > of fw errors You just have to use the fw_sst_0f28_ssp0.bin firmware file from here: https://git.kernel.org/cgit/linux/kernel/git/vkoul/firmware.git/commit/?h=byt See the message above, here is an alternative link: http://mailman.alsa-project.org/pipermail/alsa-devel/2015-June/094172.html Most of the messages you will get in the kernel log are warnings, not errors. Also try to set the alsa state as per this message: http://mailman.alsa-project.org/pipermail/alsa-devel/2015-June/094080.html Ciao, Antonio
Created attachment 181061 [details] T100TAF dmesg with fw_sst_0f28_ssp0.bin using the fw_sst_0f28_ssp0.bin got me the following dmesg on the T100TAF changed 10EC5640 to 10EC5642 in the mfld driver probably the TAF uses a different route?
Hello, guys. Is there any success ? I've tried different versions of firmware (including latest fw_sst_0f28_ssp0.bin) and no success. 1. If I'm using firmware "fw_sst_0f28.bin-48kHz_i2s_master" - quiet, but no success, no soundcards, and still "platform byt-rt5640: Driver byt-rt5640 requests probe deferral" \ "byt-rt5640 byt-rt5640: ASoC: CPU DAI baytrail-pcm-audio not registered" 2. If I'm using "fw_sst_0f28_ssp0.bin" - it can't be loaded with error -22 thanks!
root@ntfs-UB-15MS10:/home/ntfs# uname -a Linux ntfs-UB-15MS10 3.16.0-45-generic #60~14.04.1-Ubuntu SMP Fri Jul 24 21:16:23 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux - - - root@ntfs-UB-15MS10:/home/ntfs# dmesg | grep audio [ 15.822132] byt-rt5640 byt-rt5640: ASoC: CPU DAI baytrail-pcm-audio not registered [ 15.840273] byt-rt5640 byt-rt5640: ASoC: CPU DAI baytrail-pcm-audio not registered [ 15.841207] byt-rt5640 byt-rt5640: ASoC: CPU DAI baytrail-pcm-audio not registered [ 15.904839] baytrail-pcm-audio baytrail-pcm-audio: wrong ram type 0x7 in block0x0 [ 15.904850] baytrail-pcm-audio baytrail-pcm-audio: invalid module 0 [ 15.904856] baytrail-pcm-audio baytrail-pcm-audio: error: parse fw failed -22 [ 15.904871] baytrail-pcm-audio baytrail-pcm-audio: error: failed to load firmware [ 16.611070] byt-rt5640 byt-rt5640: ASoC: CPU DAI baytrail-pcm-audio not registered [ 16.611146] byt-rt5640 byt-rt5640: ASoC: CPU DAI baytrail-pcm-audio not registered [ 16.613660] [drm] mid_hdmi_audio_register: Scheduling HDMI audio work queue [ 16.613788] byt-rt5640 byt-rt5640: ASoC: CPU DAI baytrail-pcm-audio not registered - - - root@ntfs-UB-15MS10:/home/ntfs# ls -l /lib/firmware/intel/ total 796 lrwxrwxrwx 1 root root 20 січ 24 20:55 fw_sst_0f28.bin-48kHz_i2s_master -> fw_sst_0f28_ssp0.bin lrwxrwxrwx 1 root root 20 січ 24 13:03 fw_sst_0f28.bin-i2s_master -> fw_sst_0f28_ssp0.bin -rw-r--r-- 1 ntfs ntfs 701622 січ 24 04:51 fw_sst_0f28_ssp0.bin -rw-r--r-- 1 root root 9602 лип 10 2015 ibt-hw-37.7.10-fw-1.0.1.2d.d.bseq -rw-r--r-- 1 root root 21198 лип 10 2015 ibt-hw-37.7.10-fw-1.0.2.3.d.bseq -rw-r--r-- 1 root root 3558 лип 10 2015 ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq -rw-r--r-- 1 root root 20989 лип 10 2015 ibt-hw-37.7.10-fw-1.80.2.3.d.bseq -rw-r--r-- 1 root root 96 лис 24 2014 ibt-hw-37.7.bseq -rw-r--r-- 1 root root 21775 лип 10 2015 ibt-hw-37.8.10-fw-1.10.2.27.d.bseq -rwxr-xr-x 1 root root 8441 лип 10 2015 ibt-hw-37.8.10-fw-1.10.3.11.e.bseq -rw-r--r-- 1 root root 96 гру 1 2014 ibt-hw-37.8.bseq
This issue is being handled in #117141. Can you attach the output of dmidecode, so that the DMI system identification can be added to the quirk-table in fix patch-set attached to that bug?
(In reply to Joel Holdsworth from comment #59) > This issue is being handled in #117141. > > Can you attach the output of dmidecode, so that the DMI system > identification can be added to the quirk-table in fix patch-set attached to > that bug? Done.
Hello, sorry for the long posting. I have a Toshiba Click Mini, which is much like the other Baytrail Z3735F based units: 5640 audio codec, realtek 8723bs sdio wifi & bluetooth, etc. A bunch of us are trying to get the unit working with linux, and have tried kernel versions 4.4 to 4.7-rc3. We can load the sound driver but nothing happens, devices appear, but no audio plays, and we see the kernel error "Baytrail Audio Port: ASoC: no backend DAIs enabled for Baytrail Audio Port" I've even tried kernels built for the Asus T100TA which have working sound. We've tried various firmwares, and alsa state files from devices like the Asus T100TA, but without any joy. I tried looking through the information in Windows's device manager, but I didn't see anything that helped me discover any special configurations required. I took screen shots too: https://goo.gl/He4E1Y We also find that if we load the audio driver, then it makes the computer less stable, much more prone to locking up, especially if the SDIO wifi driver is in use. If you don't use the SDIO wifi, have everything running from the eMMC and don't use an SDHC card, then it's a pretty solid device. So I think that the DSDT is screwed up on this device, which affects everything in the Storage Hub subsystems in this diagram: http://cdn.arstechnica.net/wp-content/uploads/2013/09/Screen-Shot-2013-09-13-at-6.32.07-PM.jpg is it possible to extract from Windows the live/running DSDT? thanks for any ideas Paul
p.s. if anyone has a Toshiba Click Mini and wants to join in the "fun": www.tinc-vpn.org/cgi-bin/mailman/listinfo/click
Hello, My observations with Kernel-4.7-rc4 from https://github.com/plbossart/sound/tree/t100taf-5, ucm files from https://github.com/plbossart/UCM/blob/t100taf-test/bytcr-rt5640/ and firmware fw_sst_0f28_ssp0.bin on a freshly installed 16.04 64bit machine are following: 1) No more errors in dmesg, firmware loads gracefully 2) No audio by default 3) In alsamixer, "HP" routes headphone mic to headphone (kind of amplified loopback) 4) "RCMIXL OUT MIXL" when unmute produce "beep" on left headphone Debug files: 1) Dmesg: https://gist.github.com/srikantpatnaik/34308b6318eeb6d37d05f327fabde8f4 2) Alsa info: http://www.alsa-project.org/db/?f=4e96c0938e16dfd0ff48d2dca7cd151c8fc64ffa Any help/query is welcome. Thanks.
(In reply to Srikant Patnaik from comment #63) > Hello, > > My observations with Kernel-4.7-rc4 from > https://github.com/plbossart/sound/tree/t100taf-5, ucm files from > https://github.com/plbossart/UCM/blob/t100taf-test/bytcr-rt5640/ and > firmware fw_sst_0f28_ssp0.bin on a freshly installed 16.04 64bit machine are > following: > > 1) No more errors in dmesg, firmware loads gracefully > 2) No audio by default > 3) In alsamixer, "HP" routes headphone mic to headphone (kind of amplified > loopback) > 4) "RCMIXL OUT MIXL" when unmute produce "beep" on left headphone > > Debug files: > 1) Dmesg: > https://gist.github.com/srikantpatnaik/34308b6318eeb6d37d05f327fabde8f4 > 2) Alsa info: > http://www.alsa-project.org/db/?f=4e96c0938e16dfd0ff48d2dca7cd151c8fc64ffa > > Any help/query is welcome. Thanks. [ 16.312394] bytcr_rt5640 bytcr_rt5640: quirk DMIC1_MAP enabled [ 16.312397] bytcr_rt5640 bytcr_rt5640: quirk DMIC enabled [ 16.312399] bytcr_rt5640 bytcr_rt5640: quirk SSP0_AIF2 enabled [ 16.312401] bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled [ 16.312408] bytcr_rt5640 bytcr_rt5640: Failed to get MCLK from pmc_plt_clk_3: -2 [ 16.312421] bytcr_rt5640: probe of bytcr_rt5640 failed with error -2
hi, I got sound partially working on my t100taf using: https://github.com/plbossart/sound/tree/t100taf-7 https://github.com/plbossart/UCM/tree/t100-test/bytcr-rt5640 (taf branch behaves the same) Observed: - Left speaker works, right does not - Headphone have stereo working correctly - Switching between Headphone and Speakers breaks audio until reset (manually through pulseaudio or due to idle) dmesg: [ 12.304977] bytcr_rt5640 bytcr_rt5640: quirk IN1_MAP enabled [ 12.304982] bytcr_rt5640 bytcr_rt5640: quirk MONO_SPEAKER enabled [ 12.304984] bytcr_rt5640 bytcr_rt5640: quirk DIFF_MIC enabled [ 12.304987] bytcr_rt5640 bytcr_rt5640: quirk SSP0_AIF2 enabled [ 12.304989] bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled
(In reply to raffarti from comment #65) > hi, > > I got sound partially working on my t100taf using: > https://github.com/plbossart/sound/tree/t100taf-7 > https://github.com/plbossart/UCM/tree/t100-test/bytcr-rt5640 (taf branch > behaves the same) > Observed: > - Left speaker works, right does not > - Headphone have stereo working correctly > - Switching between Headphone and Speakers breaks audio until reset > (manually through pulseaudio or due to idle) > > dmesg: > [ 12.304977] bytcr_rt5640 bytcr_rt5640: quirk IN1_MAP enabled > [ 12.304982] bytcr_rt5640 bytcr_rt5640: quirk MONO_SPEAKER enabled > [ 12.304984] bytcr_rt5640 bytcr_rt5640: quirk DIFF_MIC enabled > [ 12.304987] bytcr_rt5640 bytcr_rt5640: quirk SSP0_AIF2 enabled > [ 12.304989] bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled Forgot to mention: - Both internal and headset mic not working
Hello, my Asus T200TA is quite similar to T100, I am trying to get sound working. No success for now: no sound, no audio device detected. openSUSE Leap 42.1, kernel 4.8, Intel SST and codec byt_rt5640 drivers were taken from Pierre's git t100taf-7 branch. UCM is from Pierre's git. Firmware from Vinod's repository, fw_sst_0f28_ssp0.bin # lsmod | grep snd snd_soc_sst_bytcr_rt5640 20480 0 snd_intel_sst_acpi 16384 1 snd_intel_sst_core 77824 1 snd_intel_sst_acpi snd_soc_sst_mfld_platform 102400 1 snd_intel_sst_core snd_soc_rt5640 118784 1 snd_soc_sst_bytcr_rt5640 snd_soc_rl6231 16384 1 snd_soc_rt5640 snd_soc_core 196608 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 90112 5 snd_compress,snd_timer,snd_soc_sst_mfld_platform,snd_soc_core,snd_pcm soundcore 16384 1 snd # journalctl -k | grep sst Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: BYT-CR not detected Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: LPE base: 0xd0a00000 size:0x200000 Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: IRAM base: 0xd0ac0000 Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: DRAM base: 0xd0b00000 Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: SHIM base: 0xd0b40000 Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: Mailbox base: 0xd0b44000 Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: DDR base: 0x20000000 Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: Got drv data max stream 25 # journalctl -k | grep 5640 Окт 17 00:30:21 linux-7ute kernel: bytcr_rt5640 bytcr_rt5640: quirk DMIC1_MAP enabled Окт 17 00:30:21 linux-7ute kernel: bytcr_rt5640 bytcr_rt5640: quirk DMIC enabled Окт 17 00:30:21 linux-7ute kernel: bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled Окт 17 00:30:21 linux-7ute kernel: bytcr_rt5640 bytcr_rt5640: Failed to get MCLK from pmc_plt_clk_3: -2 Окт 17 00:30:21 linux-7ute kernel: bytcr_rt5640: probe of bytcr_rt5640 failed with error -2 What else can I test or change? Thank you!
(In reply to Alexander_Zh from comment #67) > Hello, my Asus T200TA is quite similar to T100, I am trying to get sound > working. > No success for now: no sound, no audio device detected. > > openSUSE Leap 42.1, kernel 4.8, Intel SST and codec byt_rt5640 drivers were > taken from Pierre's git t100taf-7 branch. UCM is from Pierre's git. > Firmware from Vinod's repository, fw_sst_0f28_ssp0.bin > > # lsmod | grep snd > > snd_soc_sst_bytcr_rt5640 20480 0 > snd_intel_sst_acpi 16384 1 > snd_intel_sst_core 77824 1 snd_intel_sst_acpi > snd_soc_sst_mfld_platform 102400 1 snd_intel_sst_core > snd_soc_rt5640 118784 1 snd_soc_sst_bytcr_rt5640 > snd_soc_rl6231 16384 1 snd_soc_rt5640 > snd_soc_core 196608 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 90112 5 > snd_compress,snd_timer,snd_soc_sst_mfld_platform,snd_soc_core,snd_pcm > soundcore 16384 1 snd > > # journalctl -k | grep sst > Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: BYT-CR not > detected > Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: LPE base: > 0xd0a00000 size:0x200000 > Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: IRAM base: > 0xd0ac0000 > Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: DRAM base: > 0xd0b00000 > Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: SHIM base: > 0xd0b40000 > Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: Mailbox base: > 0xd0b44000 > Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: DDR base: > 0x20000000 > Окт 17 00:30:20 linux-7ute kernel: intel_sst_acpi 80860F28:00: Got drv data > max stream 25 > # journalctl -k | grep 5640 > Окт 17 00:30:21 linux-7ute kernel: bytcr_rt5640 bytcr_rt5640: quirk > DMIC1_MAP enabled > Окт 17 00:30:21 linux-7ute kernel: bytcr_rt5640 bytcr_rt5640: quirk DMIC > enabled > Окт 17 00:30:21 linux-7ute kernel: bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN > enabled > Окт 17 00:30:21 linux-7ute kernel: bytcr_rt5640 bytcr_rt5640: Failed to get > MCLK from pmc_plt_clk_3: -2 > Окт 17 00:30:21 linux-7ute kernel: bytcr_rt5640: probe of bytcr_rt5640 > failed with error -2 > > What else can I test or change? > Thank you! Failed to get MCLK from pmc_plt_clk_3: -2 ，you need this patch，https://patchwork.kernel.org/patch/9277989/ ，
This thread from the Toshiba Click Mini mailing list might help: https://www.tinc-vpn.org/pipermail/click/2016-September/000304.html it might work for the T100TAF and other variants. if only one speaker works, them you might be unlucky like me. The speaker amp on these baytrail devices seem to have no DC blocking on the output, so if something goes wrong and they're fed a constant DC voltage it will damage the speakers. unfortunately I melted mine on my Click Mini. I was lucky and found someone on ebay selling a pair. https://www.tinc-vpn.org/pipermail/click/2016-September/000331.html
git clone https://github.com/torvalds/linux.git git remote add sound https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git git fetch sound git merge sound/topic/intel patch -p1 > 13-17-clk-x86-Add-Atom-PMC-platform-clocks.patch https://patchwork.kernel.org/patch/9277989/ get sound work
git remote add maurossi https://github.com/maurossi/linux git fetch maurossi kernel-4.8 git checkout FETCH_HEAD git remote add sound https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git git fetch sound git merge sound/topic/intel https://groups.google.com/group/android-x86/attach/d1ffc290d6d56/alsa_bytcr_andx86.zip?part=0.1&authuser=0&view=1 use alsa_cr_spk.sh and alsa_cr_hp.sh，Switching headphones and speakers . but，Internal Mic and Headset Mic doesn't work. my tablet isn't asus. I make Android x86 6.0.1 with 4.8 kernel sound work.
(In reply to youling257 from comment #70) > git clone https://github.com/torvalds/linux.git > git remote add sound > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git > git fetch sound > git merge sound/topic/intel > patch -p1 > 13-17-clk-x86-Add-Atom-PMC-platform-clocks.patch > https://patchwork.kernel.org/patch/9277989/ > > get sound work 4.9 kernel default ， merge sound already . https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=topic/intel 4.9 kernel merge upstream already .
(In reply to Alexander_Zh from comment #67) > Hello, my Asus T200TA is quite similar to T100, I am trying to get sound > working. > No success for now: no sound, no audio device detected. > > openSUSE Leap 42.1, kernel 4.8, Intel SST and codec byt_rt5640 drivers were > taken from Pierre's git t100taf-7 branch. UCM is from Pierre's git. > Firmware from Vinod's repository, fw_sst_0f28_ssp0.bin >[...] Note that with Pierre's changes you are not required to use a different firmware, the audio routing is supposed to be set using quirks. Just take that in mind when you submit the quirks to mainline. Ciao, Antonio
Hello experts, thank you! Patched kernel source with https://patchwork.kernel.org/patch/9277989/ Now sound card bytcrrt5640 is detected, volume settings are available. But, sorry, no sound. How can I test it?
(In reply to Alexander_Zh from comment #74) > Hello experts, thank you! > Patched kernel source with https://patchwork.kernel.org/patch/9277989/ > Now sound card bytcrrt5640 is detected, volume settings are available. > But, sorry, no sound. How can I test it? Do you use this https://github.com/plbossart/UCM/tree/t100-test/bytcr-rt5640 ? and removed old asound.state from /var/lib/alsa . https://groups.google.com/group/android-x86/attach/5728ceaa373ba/alsa.zip?part=0.5&authuser=0&view=1 try these alsa script，my mic can work ，first run alsa_cr.sh ，then run alsa_cr_spk.sh， Android x86 use alsa_amixer ，different from other linux ，you need edit script . if still no sound，may be you need quirk bytcr_rt5640.c .
Filed separate Bug 187331- No sound on Asus T200TAC Intel Atom Baytrail & Realtek 5640
can you try to attach a hdmi output source before bootup or disabling the hdmi module > # echo 'blacklist snd_hdmi_lpe_audio' >> > /etc/modprobe.d/50-block-hdmi-audio.conf might be related to https://bugs.freedesktop.org/show_bug.cgi?id=100488