Bug 86581 - Baytrail-T: there is no sound with ASUS T100TAF
Summary: Baytrail-T: there is no sound with ASUS T100TAF
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: Intel Linux
: P1 blocking
Assignee: Jaroslav Kysela
URL:
Keywords:
: 100431 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-10-20 09:02 UTC by Eva Wang
Modified: 2018-03-07 11:55 UTC (History)
33 users (show)

See Also:
Kernel Version: 3.17
Subsystem:
Regression: No
Bisected commit-id:


Attachments
.config (167.75 KB, application/octet-stream)
2014-10-20 09:44 UTC, Eva Wang
Details
3.18-rc1 kernel dmesg (47.87 KB, text/plain)
2014-10-22 08:02 UTC, danielzhao
Details
/sys/firmware/acpi/tables/DSDT (73.33 KB, application/octet-stream)
2014-10-24 01:50 UTC, danielzhao
Details
1/3 ASoC: rt5640: Add RT5642 ACPI ID for Intel Baytrail (922 bytes, patch)
2014-10-24 11:55 UTC, Jarkko Nikula
Details | Diff
2/3 ASoC: Intel: Cover RT5642 based machine drivers with byt-rt5640 (1.16 KB, patch)
2014-10-24 11:56 UTC, Jarkko Nikula
Details | Diff
3/3 ASoC: Intel: byt-rt5640: Add quirk for Asus T100TAF (1.07 KB, patch)
2014-10-24 11:56 UTC, Jarkko Nikula
Details | Diff
Mixer configuration for Asus T100TA to be tried on T100TAF (19.31 KB, application/octet-stream)
2014-10-24 11:57 UTC, Jarkko Nikula
Details
dmesg.log (47.22 KB, application/octet-stream)
2014-10-27 09:00 UTC, Eva Wang
Details
lsmod (2.50 KB, application/octet-stream)
2014-10-27 09:00 UTC, Eva Wang
Details
Hack patch that takes DSP-host interrupt from another index (441 bytes, patch)
2014-10-27 12:13 UTC, Jarkko Nikula
Details | Diff
dmesg1.log (57.19 KB, application/octet-stream)
2014-10-28 03:37 UTC, Eva Wang
Details
interrupts (2.94 KB, text/plain)
2014-10-29 07:40 UTC, danielzhao
Details
SDHCI patch for Baytrail-T (4.52 KB, patch)
2014-11-02 21:50 UTC, Fabian Zaremba
Details | Diff
dmesg (48.71 KB, text/plain)
2014-11-03 08:35 UTC, danielzhao
Details
/proc/interrupts while playing sound on RT5642 (2.76 KB, text/plain)
2014-11-04 09:30 UTC, Fabian Zaremba
Details
3.18rc2 kernel log with RT5642 sound init (46.00 KB, application/octet-stream)
2014-11-04 09:33 UTC, Fabian Zaremba
Details
Binary DSDT from Teclast X98 Air 3G (62.43 KB, application/x-ns-proxy-autoconfig)
2014-11-10 10:32 UTC, Fabian Zaremba
Details
ASoC: Intel: Cover RT5642 based machine drivers with byt-rt5640 (part #2) (1.38 KB, patch)
2014-11-21 11:06 UTC, Jarkko Nikula
Details | Diff
dmesg_1125.log (51.85 KB, text/plain)
2014-11-25 02:44 UTC, Eva Wang
Details
T100_B.state (19.38 KB, application/octet-stream)
2014-12-17 10:21 UTC, Brian Loften
Details
Stream 7 Hardware Layout (1.85 MB, image/jpeg)
2015-01-20 17:51 UTC, Bobby Budnick
Details
Stream 7 Audio Hardware (1.64 MB, image/jpeg)
2015-01-20 17:53 UTC, Bobby Budnick
Details
T100TAF dmesg with fw_sst_0f28_ssp0.bin (39.76 KB, application/octet-stream)
2015-06-27 10:22 UTC, Luka Karinja
Details

Description Eva Wang 2014-10-20 09:02:00 UTC
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.
Comment 1 Takashi Iwai 2014-10-20 09:22:44 UTC
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.
Comment 2 Eva Wang 2014-10-20 09:44:17 UTC
(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!
Comment 3 Eva Wang 2014-10-20 09:44:36 UTC
Created attachment 154271 [details]
.config
Comment 4 Takashi Iwai 2014-10-20 09:46:19 UTC
(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.
Comment 5 Eva Wang 2014-10-20 09:54:03 UTC
(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!
Comment 6 Jarkko Nikula 2014-10-20 10:17:11 UTC
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
Comment 7 danielzhao 2014-10-22 08:02:36 UTC
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.
Comment 8 Jarkko Nikula 2014-10-23 13:48:09 UTC
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.
Comment 9 danielzhao 2014-10-24 01:50:09 UTC
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
Comment 10 Jarkko Nikula 2014-10-24 11:55:33 UTC
Created attachment 154791 [details]
1/3 ASoC: rt5640: Add RT5642 ACPI ID for Intel Baytrail
Comment 11 Jarkko Nikula 2014-10-24 11:56:00 UTC
Created attachment 154801 [details]
2/3 ASoC: Intel: Cover RT5642 based machine drivers with byt-rt5640
Comment 12 Jarkko Nikula 2014-10-24 11:56:20 UTC
Created attachment 154811 [details]
3/3 ASoC: Intel: byt-rt5640: Add quirk for Asus T100TAF
Comment 13 Jarkko Nikula 2014-10-24 11:57:35 UTC
Created attachment 154821 [details]
Mixer configuration for Asus T100TA to be tried on T100TAF
Comment 14 Jarkko Nikula 2014-10-24 12:11:08 UTC
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.
Comment 15 Eva Wang 2014-10-27 08:59:25 UTC
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.
Comment 16 Eva Wang 2014-10-27 09:00:02 UTC
Created attachment 155321 [details]
dmesg.log
Comment 17 Eva Wang 2014-10-27 09:00:21 UTC
Created attachment 155331 [details]
lsmod
Comment 18 Jarkko Nikula 2014-10-27 12:13:39 UTC
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?
Comment 19 Eva Wang 2014-10-28 03:37:47 UTC
Created attachment 155571 [details]
dmesg1.log

Please refer dmesg1.log after added the patch. Thanks!
Comment 20 Jarkko Nikula 2014-10-29 07:23:55 UTC
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.
Comment 21 danielzhao 2014-10-29 07:40:29 UTC
Created attachment 155761 [details]
interrupts

attached the file /proc/interrupts.
Comment 22 Fabian Zaremba 2014-11-02 21:48:25 UTC
(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.
Comment 23 Fabian Zaremba 2014-11-02 21:50:08 UTC
Created attachment 156331 [details]
SDHCI patch for Baytrail-T
Comment 24 danielzhao 2014-11-03 08:35:36 UTC
Created attachment 156361 [details]
dmesg

Yes, I applied the SDHCI patch for Baytrail-T. And get attached dmesg log.
Comment 25 Fabian Zaremba 2014-11-03 11:47:36 UTC
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.
Comment 26 Jarkko Nikula 2014-11-04 08:37:21 UTC
(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.
Comment 27 Fabian Zaremba 2014-11-04 09:26:49 UTC
(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].
Comment 28 Fabian Zaremba 2014-11-04 09:30:29 UTC
Created attachment 156461 [details]
/proc/interrupts while playing sound on RT5642

Lack of AudioDSP - see comment #27
Comment 29 Fabian Zaremba 2014-11-04 09:33:05 UTC
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]
Comment 30 Jarkko Nikula 2014-11-10 09:29:13 UTC
(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 :-(
Comment 31 Fabian Zaremba 2014-11-10 10:27:40 UTC
(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!
Comment 32 Fabian Zaremba 2014-11-10 10:32:59 UTC
Created attachment 157121 [details]
Binary DSDT from Teclast X98 Air 3G

DSDT from "Windows mode" firmware (Teclast official release)
Comment 33 Eva Wang 2014-11-14 06:12:00 UTC
Hi All, could you help to update the issue status. is there any solution now? Thanks!
Comment 34 Jarkko Nikula 2014-11-17 09:31:27 UTC
(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?
Comment 35 Fabian Zaremba 2014-11-18 20:50:05 UTC
(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.
Comment 36 Jarkko Nikula 2014-11-20 14:41:40 UTC
(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?
Comment 37 Fabian Zaremba 2014-11-20 15:19:39 UTC
(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.
Comment 38 Jarkko Nikula 2014-11-21 08:40:39 UTC
(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.
Comment 39 Jarkko Nikula 2014-11-21 11:06:48 UTC
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.
Comment 40 Eva Wang 2014-11-25 02:44:07 UTC
Created attachment 158761 [details]
dmesg_1125.log

Hi Jarkko Nikula.
there is still no sound after added these patches. please refer dmesg_1125.log
Comment 41 Jarkko Nikula 2014-12-05 07:55:40 UTC
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".
Comment 42 Bobby Budnick 2014-12-15 20:11:01 UTC
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?
Comment 43 Jarkko Nikula 2014-12-16 12:30:56 UTC
(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.
Comment 44 Brian Loften 2014-12-17 10:21:47 UTC
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
Comment 45 Bobby Budnick 2014-12-17 18:15:27 UTC
(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?
Comment 46 Jarkko Nikula 2014-12-18 08:09:17 UTC
(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.
Comment 47 Tonie 2015-01-20 07:42:50 UTC
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 ?
Comment 48 Bobby Budnick 2015-01-20 17:51:58 UTC
Created attachment 163921 [details]
Stream 7 Hardware Layout
Comment 49 Bobby Budnick 2015-01-20 17:53:15 UTC
Created attachment 163931 [details]
Stream 7 Audio Hardware
Comment 50 Bobby Budnick 2015-01-20 17:57:11 UTC
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.
Comment 51 beta990 2015-05-26 17:02:42 UTC
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. :)
Comment 52 Takashi Iwai 2015-06-25 12:19:59 UTC
*** Bug 100431 has been marked as a duplicate of this bug. ***
Comment 53 Antonio Ospite 2015-06-26 13:17:51 UTC
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
Comment 54 Luka Karinja 2015-06-26 20:42:04 UTC
(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
Comment 55 Antonio Ospite 2015-06-26 22:13:45 UTC
(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
Comment 56 Luka Karinja 2015-06-27 10:22:50 UTC
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?
Comment 57 Vitaliy Blats 2016-01-24 16:57:15 UTC
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!
Comment 58 Vitaliy Blats 2016-01-24 19:14:20 UTC
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
Comment 59 Joel Holdsworth 2016-04-25 02:17:43 UTC
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?
Comment 60 Stephen 2016-05-04 20:33:18 UTC
(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.
Comment 61 Paul Mansfield 2016-06-13 20:33:52 UTC
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
Comment 62 Paul Mansfield 2016-06-15 16:19:18 UTC
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
Comment 63 Srikant Patnaik 2016-07-13 13:26:03 UTC
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.
Comment 64 youling257 2016-08-31 23:56:19 UTC
(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
Comment 65 raffarti 2016-09-18 13:29:06 UTC
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
Comment 66 raffarti 2016-09-18 13:33:56 UTC
(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
Comment 67 Alexander_Zh 2016-10-16 22:05:49 UTC
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!
Comment 68 youling257 2016-10-16 22:32:24 UTC
(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/
Comment 69 Paul Mansfield 2016-10-16 22:45:51 UTC
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
Comment 70 youling257 2016-10-16 22:52:13 UTC
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
Comment 71 youling257 2016-10-16 22:59:46 UTC
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.
Comment 72 youling257 2016-10-17 04:55:49 UTC
(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 .
Comment 73 Antonio Ospite 2016-10-17 08:46:52 UTC
(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
Comment 74 Alexander_Zh 2016-11-04 21:07:54 UTC
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?
Comment 75 youling257 2016-11-04 21:28:00 UTC
(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 .
Comment 76 Alexander_Zh 2016-11-08 21:45:18 UTC
Filed separate Bug 187331- No sound on Asus T200TAC Intel Atom Baytrail & Realtek 5640
Comment 77 roman 2018-03-07 11:55:27 UTC
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

Note You need to log in before you can comment on or make changes to this bug.