| Message ID | 1851514.XmzcdsvJt0@wks-pdc-gentoo (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On 5/31/16 3:43 AM, Pietro wrote: > Hi, > > I'm an owner of a 2 in 1 Netbook with an Atom X5 Z8300 SoC with rt5651 codec (Cube iWork 11). > > To get audio working I Added these lines of code to the ./soc/intel/atom/sst/sst_acpi.c file: > > --- ./soc/intel/atom/sst/sst_acpi.c.old 2016-05-31 09:05:40.045682194 +0200 > +++ ./soc/intel/atom/sst/sst_acpi.c 2016-05-31 09:07:26.829324148 +0200 > @@ -342,9 +342,12 @@ > &chv_platform_data }, > {"193C9890", "cht-bsw-max98090", "intel/fw_sst_22a8.bin", "cht-bsw", NULL, > &chv_platform_data }, > + {"10EC5651", "bytcr_rt5651", "intel/fw_sst_0f28.bin", "bytcr_rt5651", NULL, > + &byt_rvp_platform_data }, > {}, > }; use the same as for rt5640 on cht: /* some CHT-T platforms rely on RT5640, use Baytrail machine driver */ {"10EC5640", "bytcr_rt5640", "intel/fw_sst_22a8.bin", "bytcr_rt5640", NULL, &chv_platform_data }, > > + > static const struct acpi_device_id sst_acpi_ids[] = { > { "80860F28", (unsigned long)&sst_acpi_bytcr}, > { "808622A8", (unsigned long) &sst_acpi_chv}, > > > > > Then i added the UCM files linked in these archive: > https://github.com/plbossart/UCM/tree/master/bytcr-rt5651 > > > > With this configuration, audio seems to work, but is 'slow': Playback speed is at slow motion, and seconds move slowly (Tried with aplay and audacious with many sound files, using directly Alsa and Pulseaudio with no differencies). > > This seems to be a DSP Clock problem. Have you got any suggestions to solve this problem? we've had this report before with rt5640 but it's unclear what might cause this. the codec is configured as slave and uses the bit clock as source for its PLL. the easiest fix in this case would be to use the 19.2 MCLK which is enabled by default on CHT, see examples in cht-bsw-rt5645 (look at platform clock control and everything with set_sys_clk, but keep the 2 slots). We will add this on baytrail as well at some point when we have a clock framework driver for the MCLK control.
the changes look ok > > But I still have the same problem: Audio plays slowly. > > > > It seems the DSP is clocked at 19.2, but the system is still clocked for > 25, and these changes doesn't seem to have effects... no, CHT doesn't have a 25 MHz clock at all so that's just not physically possible. Can you try: - tracing to make sure you are actually on a CHT device - pastebin dmesg somewhere - sudo cat /sys/bus/acpi/devices/10EC5651:01/status - enabling DSP loopbacks to see if the DSP consumes data at the right rate. look at the UCM file and change cset "name='pcm1_out mix 0 pcm0_in Switch' off" to on if you record and loopback on USB output this should play at the right speed.
Hi,
Here are the answers:
- tracing to make sure you are actually on a CHT device
The device should be CHT (The processor is an Atom X3-Z8300). Can it be that the processor is an X3 series, but the platform is BT and not a CHT? I know many manifacturers simply upgraded their notebooks series from BT to CHT by changing the CPU and mantaining all the other components the same (For example the Audio codec).
How can I trace this?
- pastebin dmesg somewhere
Here is it: http://pastebin.com/FnpAD1kg
- sudo cat /sys/bus/acpi/devices/10EC5651:01/status
Here are the results:
/sys/bus/acpi/devices/10EC5651:00/status
Returns 15
/sys/bus/acpi/devices/10EC5651:01/status
Returns 0
- enabling DSP loopbacks to see if the DSP consumes data at the right rate. look at the UCM file and change cset "name='pcm1_out mix 0 pcm0_in Switch' off" to on if you record and loopback on USB output this should play at the right speed.
I've changed the value in the HiFi file, but no changes.
How can i enable DSP loopbacks? I'm not an alsa developer so I need some help here :)
Please let me know if you need other informations.
On Tuesday 31 May 2016 15:27:45 Pierre-Louis Bossart wrote:
> the changes look ok
> >
> > But I still have the same problem: Audio plays slowly.
> >
> >
> >
> > It seems the DSP is clocked at 19.2, but the system is still clocked for
> > 25, and these changes doesn't seem to have effects...
>
> no, CHT doesn't have a 25 MHz clock at all so that's just not physically
> possible.
>
> Can you try:
> - tracing to make sure you are actually on a CHT device
> - pastebin dmesg somewhere
> - sudo cat /sys/bus/acpi/devices/10EC5651:01/status
> - enabling DSP loopbacks to see if the DSP consumes data at the right
> rate. look at the UCM file and change
> cset "name='pcm1_out mix 0 pcm0_in Switch' off" to on
> if you record and loopback on USB output this should play at the right
> speed.
>
>
>
On 5/31/16 3:56 PM, Pietro wrote: > Hi, > Here are the answers: > > - tracing to make sure you are actually on a CHT device > The device should be CHT (The processor is an Atom X3-Z8300). Can it be that the processor is an X3 series, but the platform is BT and not a CHT? I know many manifacturers simply upgraded their notebooks series from BT to CHT by changing the CPU and mantaining all the other components the same (For example the Audio codec). > How can I trace this? you see a lot of references to cherrytrail-cr and 22A8, the right ID. > > - pastebin dmesg somewhere > Here is it: http://pastebin.com/FnpAD1kg You have lots of errors or warnings in there. Not sure why, i have machines that don't behave as badly. I am not sure why using the CHT firmware leads to an error, somehow you probably have a combination of issues. I would really start there, if the regular firmware doesn't work for you something is very wrong. > - sudo cat /sys/bus/acpi/devices/10EC5651:01/status > Here are the results: > /sys/bus/acpi/devices/10EC5651:00/status > Returns 15 this matches what the machine driver expects so that's good. > > /sys/bus/acpi/devices/10EC5651:01/status > Returns 0 > > - enabling DSP loopbacks to see if the DSP consumes data at the right rate. look at the UCM file and change cset "name='pcm1_out mix 0 pcm0_in Switch' off" to on if you record and loopback on USB output this should play at the right speed. > I've changed the value in the HiFi file, but no changes. > How can i enable DSP loopbacks? I'm not an alsa developer so I need some help here :) you need to record to enable the loopback while you play... > > Please let me know if you need other informations. can you extract the DSDT and pastebin it as well? > > On Tuesday 31 May 2016 15:27:45 Pierre-Louis Bossart wrote: >> the changes look ok >>> >>> But I still have the same problem: Audio plays slowly. >>> >>> >>> >>> It seems the DSP is clocked at 19.2, but the system is still clocked for >>> 25, and these changes doesn't seem to have effects... >> >> no, CHT doesn't have a 25 MHz clock at all so that's just not physically >> possible. >> >> Can you try: >> - tracing to make sure you are actually on a CHT device >> - pastebin dmesg somewhere >> - sudo cat /sys/bus/acpi/devices/10EC5651:01/status >> - enabling DSP loopbacks to see if the DSP consumes data at the right >> rate. look at the UCM file and change >> cset "name='pcm1_out mix 0 pcm0_in Switch' off" to on >> if you record and loopback on USB output this should play at the right >> speed. >> >> >> > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >
Hi, The Kernel error messages should be related to the Intel DRM graphics, so I don't care about them (at least for now). Anyway I don't know if tese warning can in some way be related to my problem: [ 9.565990] rt5651 i2c-10EC5651:00: ASoC: mux INL1 Mux has no paths [ 9.586586] rt5651 i2c-10EC5651:00: ASoC: mux INR1 Mux has no paths [ 9.586596] rt5651 i2c-10EC5651:00: ASoC: mux INL2 Mux has no paths [ 9.586601] rt5651 i2c-10EC5651:00: ASoC: mux INR2 Mux has no paths [ 12.646035] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 0 doesn't have DAPM widget!!! [ 12.649356] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 1 doesn't have DAPM widget!!! [ 12.652673] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 2 doesn't have DAPM widget!!! [ 12.656323] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 3 doesn't have DAPM widget!!! [ 12.659868] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in0_0 doesn't have DAPM widget!!! [ 12.663456] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in0_1 doesn't have DAPM widget!!! ------------- For your convenience I've extracted the DSDT from Android and Linux, because they seem to differ. Here they are: DSDT Linux: http://paste.ubuntu.com/16885538/ DSDT Android: http://paste.ubuntu.com/16885557/ And this is the dmesg from android: http://pastebin.com/nY5mtW76 Here are the Firmware Blobs I'm currently using: http://pastebin.com/UKN0c0as (Fw listing) https://drive.google.com/file/d/0By5f76WVVa0Eb3RacGZRbzNGeFU/view?usp=sharing (Fw blobs) When I'll return home I'll try to record and play and let you know. Thanks, Pietro On Tuesday 31 May 2016 17:26:30 Pierre-Louis Bossart wrote: > On 5/31/16 3:56 PM, Pietro wrote: > > Hi, > > Here are the answers: > > > > - tracing to make sure you are actually on a CHT device > > The device should be CHT (The processor is an Atom X3-Z8300). Can it be that the processor is an X3 series, but the platform is BT and not a CHT? I know many manifacturers simply upgraded their notebooks series from BT to CHT by changing the CPU and mantaining all the other components the same (For example the Audio codec). > > How can I trace this? > > you see a lot of references to cherrytrail-cr and 22A8, the right ID. > > > > - pastebin dmesg somewhere > > Here is it: http://pastebin.com/FnpAD1kg > > You have lots of errors or warnings in there. Not sure why, i have > machines that don't behave as badly. > > I am not sure why using the CHT firmware leads to an error, somehow you > probably have a combination of issues. I would really start there, if > the regular firmware doesn't work for you something is very wrong. > > > - sudo cat /sys/bus/acpi/devices/10EC5651:01/status > > Here are the results: > > /sys/bus/acpi/devices/10EC5651:00/status > > Returns 15 > > this matches what the machine driver expects so that's good. > > > > /sys/bus/acpi/devices/10EC5651:01/status > > Returns 0 > > > > - enabling DSP loopbacks to see if the DSP consumes data at the right rate. look at the UCM file and change cset "name='pcm1_out mix 0 pcm0_in Switch' off" to on if you record and loopback on USB output this should play at the right speed. > > I've changed the value in the HiFi file, but no changes. > > How can i enable DSP loopbacks? I'm not an alsa developer so I need some help here :) > > you need to record to enable the loopback while you play... > > > > Please let me know if you need other informations. > > can you extract the DSDT and pastebin it as well? > > > > > On Tuesday 31 May 2016 15:27:45 Pierre-Louis Bossart wrote: > >> the changes look ok > >>> > >>> But I still have the same problem: Audio plays slowly. > >>> > >>> > >>> > >>> It seems the DSP is clocked at 19.2, but the system is still clocked for > >>> 25, and these changes doesn't seem to have effects... > >> > >> no, CHT doesn't have a 25 MHz clock at all so that's just not physically > >> possible. > >> > >> Can you try: > >> - tracing to make sure you are actually on a CHT device > >> - pastebin dmesg somewhere > >> - sudo cat /sys/bus/acpi/devices/10EC5651:01/status > >> - enabling DSP loopbacks to see if the DSP consumes data at the right > >> rate. look at the UCM file and change > >> cset "name='pcm1_out mix 0 pcm0_in Switch' off" to on > >> if you record and loopback on USB output this should play at the right > >> speed. > >> > >> > >> > > > > _______________________________________________ > > Alsa-devel mailing list > > Alsa-devel@alsa-project.org > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > >
On 6/1/16 3:38 AM, Pietro wrote: > Hi, > > > > The Kernel error messages should be related to the Intel DRM graphics, > so I don't care about them (at least for now). > > > > Anyway I don't know if tese warning can in some way be related to my > problem: > > > > [ 9.565990] rt5651 i2c-10EC5651:00: ASoC: mux INL1 Mux has no paths > > [ 9.586586] rt5651 i2c-10EC5651:00: ASoC: mux INR1 Mux has no paths > > [ 9.586596] rt5651 i2c-10EC5651:00: ASoC: mux INL2 Mux has no paths > > [ 9.586601] rt5651 i2c-10EC5651:00: ASoC: mux INR2 Mux has no paths probably the config is incorrect, I didn't enable capture in the UCM file > > [ 12.646035] sst-mfld-platform sst-mfld-platform: Slot control: > codec_out tx interleaver slot 0 doesn't have DAPM widget!!! > > [ 12.649356] sst-mfld-platform sst-mfld-platform: Slot control: > codec_out tx interleaver slot 1 doesn't have DAPM widget!!! > > [ 12.652673] sst-mfld-platform sst-mfld-platform: Slot control: > codec_out tx interleaver slot 2 doesn't have DAPM widget!!! > > [ 12.656323] sst-mfld-platform sst-mfld-platform: Slot control: > codec_out tx interleaver slot 3 doesn't have DAPM widget!!! > > [ 12.659868] sst-mfld-platform sst-mfld-platform: Slot control: codec_in > rx deinterleaver codec_in0_0 doesn't have DAPM widget!!! > > [ 12.663456] sst-mfld-platform sst-mfld-platform: Slot control: codec_in > rx deinterleaver codec_in0_1 doesn't have DAPM widget!!! this last warning is fixed upstream. > For your convenience I've extracted the DSDT from Android and Linux, > because they seem to differ. Here they are: > > > > DSDT Linux: http://paste.ubuntu.com/16885538/ > > DSDT Android: http://paste.ubuntu.com/16885557/ DSDT is OS independent so that doesn't make sense. Just to be clear, is this an Android tablet on which you are installing ubuntu? And did you try to use the firmware from upstream or from the Android distribution?
Hi, Sorry for the wrong information: the 2 DSDTs were decompiled using different iasl versions (20140828 for Android vs 20150717 for Linux), giving apparently different results (the functions were decoded differently, but the keys were the same). The tablet is a dual boot Windows+Android (Surely based on AndroidIA, with a Patched gmin kernel... Obviously the sources were not provided by the manifacturer). I've made some tests using both the firmware included in Android, and the upstream ones, with no apparent results (Always slow Audio). But when you suggested me to use the fw_sst_22a8.bin I was trying to load the Android one, giving me load errors. Now I've tried the upstream one and it works with correct timing settings (!!) Then I've tried to restore the 4.5.2 stock bytcr_rt5651.c, but this gave me inconsistent playback: The speed was right, but there were continue audio artifacts (like the ones given by a bad resampler, to give you an idea). Using the patched driver, following your suggestion (patching it exatcly as I've wrote in the past E-Mails), solved this issue, so now the Audio is correctly played. In the following days I'll make some tests (For example audio recording, switch between Headset and Speakers Etc.) and let you know if I'll find other issues. Thanks for your continuous support, I've really appreciated it. Pietro On Wednesday 01 June 2016 10:13:17 Pierre-Louis Bossart wrote: > On 6/1/16 3:38 AM, Pietro wrote: > > Hi, > > > > > > > > The Kernel error messages should be related to the Intel DRM graphics, > > so I don't care about them (at least for now). > > > > > > > > Anyway I don't know if tese warning can in some way be related to my > > problem: > > > > > > > > [ 9.565990] rt5651 i2c-10EC5651:00: ASoC: mux INL1 Mux has no paths > > > > [ 9.586586] rt5651 i2c-10EC5651:00: ASoC: mux INR1 Mux has no paths > > > > [ 9.586596] rt5651 i2c-10EC5651:00: ASoC: mux INL2 Mux has no paths > > > > [ 9.586601] rt5651 i2c-10EC5651:00: ASoC: mux INR2 Mux has no paths > > probably the config is incorrect, I didn't enable capture in the UCM file > > > > > [ 12.646035] sst-mfld-platform sst-mfld-platform: Slot control: > > codec_out tx interleaver slot 0 doesn't have DAPM widget!!! > > > > [ 12.649356] sst-mfld-platform sst-mfld-platform: Slot control: > > codec_out tx interleaver slot 1 doesn't have DAPM widget!!! > > > > [ 12.652673] sst-mfld-platform sst-mfld-platform: Slot control: > > codec_out tx interleaver slot 2 doesn't have DAPM widget!!! > > > > [ 12.656323] sst-mfld-platform sst-mfld-platform: Slot control: > > codec_out tx interleaver slot 3 doesn't have DAPM widget!!! > > > > [ 12.659868] sst-mfld-platform sst-mfld-platform: Slot control: codec_in > > rx deinterleaver codec_in0_0 doesn't have DAPM widget!!! > > > > [ 12.663456] sst-mfld-platform sst-mfld-platform: Slot control: codec_in > > rx deinterleaver codec_in0_1 doesn't have DAPM widget!!! > > this last warning is fixed upstream. > > > For your convenience I've extracted the DSDT from Android and Linux, > > because they seem to differ. Here they are: > > > > > > > > DSDT Linux: http://paste.ubuntu.com/16885538/ > > > > DSDT Android: http://paste.ubuntu.com/16885557/ > > DSDT is OS independent so that doesn't make sense. > Just to be clear, is this an Android tablet on which you are installing > ubuntu? > And did you try to use the firmware from upstream or from the Android > distribution? > >
On 6/1/16 4:43 PM, Pietro wrote: > Hi, > > Sorry for the wrong information: > the 2 DSDTs were decompiled using different iasl versions (20140828 for Android vs 20150717 for Linux), giving apparently different results (the functions were decoded differently, but the keys were the same). > > The tablet is a dual boot Windows+Android (Surely based on AndroidIA, with a Patched gmin kernel... Obviously the sources were not provided by the manifacturer). > > I've made some tests using both the firmware included in Android, and the upstream ones, with no apparent results (Always slow Audio). > > But when you suggested me to use the fw_sst_22a8.bin I was trying to load the Android one, giving me load errors. Now I've tried the upstream one and it works with correct timing settings (!!) > > Then I've tried to restore the 4.5.2 stock bytcr_rt5651.c, but this gave me inconsistent playback: The speed was right, but there were continue audio artifacts (like the ones given by a bad resampler, to give you an idea). > Using the patched driver, following your suggestion (patching it exatcly as I've wrote in the past E-Mails), solved this issue, so now the Audio is correctly played. > > In the following days I'll make some tests (For example audio recording, switch between Headset and Speakers Etc.) and let you know if I'll find other issues. > > Thanks for your continuous support, I've really appreciated it. Good to hear! Yes as a general rule mixing upstream drivers with Android firmware and vice-versa is not a good idea, and using the MCLK is the only way to solve audio quality issues, it's however not enabled on every board unfortunately. When we have the clock driver I will make this the default and use quirks to go back to bit-clock based PLL configs. If you want to send me a patch I can merge it with the rest of Baytrail cleanups still being worked on. > > Pietro > > > On Wednesday 01 June 2016 10:13:17 Pierre-Louis Bossart wrote: >> On 6/1/16 3:38 AM, Pietro wrote: >>> Hi, >>> >>> >>> >>> The Kernel error messages should be related to the Intel DRM graphics, >>> so I don't care about them (at least for now). >>> >>> >>> >>> Anyway I don't know if tese warning can in some way be related to my >>> problem: >>> >>> >>> >>> [ 9.565990] rt5651 i2c-10EC5651:00: ASoC: mux INL1 Mux has no paths >>> >>> [ 9.586586] rt5651 i2c-10EC5651:00: ASoC: mux INR1 Mux has no paths >>> >>> [ 9.586596] rt5651 i2c-10EC5651:00: ASoC: mux INL2 Mux has no paths >>> >>> [ 9.586601] rt5651 i2c-10EC5651:00: ASoC: mux INR2 Mux has no paths >> >> probably the config is incorrect, I didn't enable capture in the UCM file >> >>> >>> [ 12.646035] sst-mfld-platform sst-mfld-platform: Slot control: >>> codec_out tx interleaver slot 0 doesn't have DAPM widget!!! >>> >>> [ 12.649356] sst-mfld-platform sst-mfld-platform: Slot control: >>> codec_out tx interleaver slot 1 doesn't have DAPM widget!!! >>> >>> [ 12.652673] sst-mfld-platform sst-mfld-platform: Slot control: >>> codec_out tx interleaver slot 2 doesn't have DAPM widget!!! >>> >>> [ 12.656323] sst-mfld-platform sst-mfld-platform: Slot control: >>> codec_out tx interleaver slot 3 doesn't have DAPM widget!!! >>> >>> [ 12.659868] sst-mfld-platform sst-mfld-platform: Slot control: codec_in >>> rx deinterleaver codec_in0_0 doesn't have DAPM widget!!! >>> >>> [ 12.663456] sst-mfld-platform sst-mfld-platform: Slot control: codec_in >>> rx deinterleaver codec_in0_1 doesn't have DAPM widget!!! >> >> this last warning is fixed upstream. >> >>> For your convenience I've extracted the DSDT from Android and Linux, >>> because they seem to differ. Here they are: >>> >>> >>> >>> DSDT Linux: http://paste.ubuntu.com/16885538/ >>> >>> DSDT Android: http://paste.ubuntu.com/16885557/ >> >> DSDT is OS independent so that doesn't make sense. >> Just to be clear, is this an Android tablet on which you are installing >> ubuntu? >> And did you try to use the firmware from upstream or from the Android >> distribution? >> >> > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel >
Hi, You can find the full patch here: http://pastebin.com/uFYq4UAL[1] I've patched it against the 4.7RC1 tree. I have tested it only on 4.5.2, but I don't think there will be significant differences between 4.5.2 and 4.7RC1 trunks (I only noticed the add of RT5640 support for cherryview). Anyway I'll let you know if I'll find some problems. Pietro On Wednesday 01 June 2016 16:58:35 Pierre-Louis Bossart wrote: > On 6/1/16 4:43 PM, Pietro wrote: > > Hi, > > > > Sorry for the wrong information: > > the 2 DSDTs were decompiled using different iasl versions (20140828 for Android vs 20150717 for Linux), giving apparently different results (the functions were decoded differently, but the keys were the same). > > > > The tablet is a dual boot Windows+Android (Surely based on AndroidIA, with a Patched gmin kernel... Obviously the sources were not provided by the manifacturer). > > > > I've made some tests using both the firmware included in Android, and the upstream ones, with no apparent results (Always slow Audio). > > > > But when you suggested me to use the fw_sst_22a8.bin I was trying to load the Android one, giving me load errors. Now I've tried the upstream one and it works with correct timing settings (!!) > > > > Then I've tried to restore the 4.5.2 stock bytcr_rt5651.c, but this gave me inconsistent playback: The speed was right, but there were continue audio artifacts (like the ones given by a bad resampler, to give you an idea). > > Using the patched driver, following your suggestion (patching it exatcly as I've wrote in the past E-Mails), solved this issue, so now the Audio is correctly played. > > > > In the following days I'll make some tests (For example audio recording, switch between Headset and Speakers Etc.) and let you know if I'll find other issues. > > > > Thanks for your continuous support, I've really appreciated it. > > Good to hear! > Yes as a general rule mixing upstream drivers with Android firmware and > vice-versa is not a good idea, and using the MCLK is the only way to > solve audio quality issues, it's however not enabled on every board > unfortunately. When we have the clock driver I will make this the > default and use quirks to go back to bit-clock based PLL configs. > If you want to send me a patch I can merge it with the rest of Baytrail > cleanups still being worked on. > > > > > Pietro > > > > > > On Wednesday 01 June 2016 10:13:17 Pierre-Louis Bossart wrote: > >> On 6/1/16 3:38 AM, Pietro wrote: > >>> Hi, > >>> > >>> > >>> > >>> The Kernel error messages should be related to the Intel DRM graphics, > >>> so I don't care about them (at least for now). > >>> > >>> > >>> > >>> Anyway I don't know if tese warning can in some way be related to my > >>> problem: > >>> > >>> > >>> > >>> [ 9.565990] rt5651 i2c-10EC5651:00: ASoC: mux INL1 Mux has no paths > >>> > >>> [ 9.586586] rt5651 i2c-10EC5651:00: ASoC: mux INR1 Mux has no paths > >>> > >>> [ 9.586596] rt5651 i2c-10EC5651:00: ASoC: mux INL2 Mux has no paths > >>> > >>> [ 9.586601] rt5651 i2c-10EC5651:00: ASoC: mux INR2 Mux has no paths > >> > >> probably the config is incorrect, I didn't enable capture in the UCM file > >> > >>> > >>> [ 12.646035] sst-mfld-platform sst-mfld-platform: Slot control: > >>> codec_out tx interleaver slot 0 doesn't have DAPM widget!!! > >>> > >>> [ 12.649356] sst-mfld-platform sst-mfld-platform: Slot control: > >>> codec_out tx interleaver slot 1 doesn't have DAPM widget!!! > >>> > >>> [ 12.652673] sst-mfld-platform sst-mfld-platform: Slot control: > >>> codec_out tx interleaver slot 2 doesn't have DAPM widget!!! > >>> > >>> [ 12.656323] sst-mfld-platform sst-mfld-platform: Slot control: > >>> codec_out tx interleaver slot 3 doesn't have DAPM widget!!! > >>> > >>> [ 12.659868] sst-mfld-platform sst-mfld-platform: Slot control: codec_in > >>> rx deinterleaver codec_in0_0 doesn't have DAPM widget!!! > >>> > >>> [ 12.663456] sst-mfld-platform sst-mfld-platform: Slot control: codec_in > >>> rx deinterleaver codec_in0_1 doesn't have DAPM widget!!! > >> > >> this last warning is fixed upstream. > >> > >>> For your convenience I've extracted the DSDT from Android and Linux, > >>> because they seem to differ. Here they are: > >>> > >>> > >>> > >>> DSDT Linux: http://paste.ubuntu.com/16885538/ > >>> > >>> DSDT Android: http://paste.ubuntu.com/16885557/ > >> > >> DSDT is OS independent so that doesn't make sense. > >> Just to be clear, is this an Android tablet on which you are installing > >> ubuntu? > >> And did you try to use the firmware from upstream or from the Android > >> distribution? > >> > >> > > > > _______________________________________________ > > Alsa-devel mailing list > > Alsa-devel@alsa-project.org > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > > > -------- [1] http://pastebin.com/uFYq4UAL
--- ./soc/intel/atom/sst/sst_acpi.c.old 2016-05-31 09:05:40.045682194 +0200 +++ ./soc/intel/atom/sst/sst_acpi.c 2016-05-31 09:07:26.829324148 +0200 @@ -342,9 +342,12 @@ &chv_platform_data }, {"193C9890", "cht-bsw-max98090", "intel/fw_sst_22a8.bin", "cht-bsw", NULL, &chv_platform_data }, + {"10EC5651", "bytcr_rt5651", "intel/fw_sst_0f28.bin", "bytcr_rt5651", NULL, + &byt_rvp_platform_data }, {}, }; + static const struct acpi_device_id sst_acpi_ids[] = { { "80860F28", (unsigned long)&sst_acpi_bytcr}, { "808622A8", (unsigned long) &sst_acpi_chv},