[alsa-devel] Intel SST on a Bay Trail tablet
Hi,
I am trying to get the Intel SST driver working on a Teclast X98 Air 3G [1], it's a Bay Trail tablet. The tests below have been made with 4.0.0-rc1 and the firmware files from https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tre...
The DSDT on this device is quite broken, and I am patching it to get stuff working.
The audio device works just fine under Android, I don't know if that's because the Android kernel is ignoring the DSDT and is hard-coding some platform data.
Anyhow, with the untouched DSDT[2] I was getting this message in dmesg[3]:
[ 11.344095] platform byt-rt5640: Driver byt-rt5640 requests probe deferral [ 11.404831] resource sanity check: requesting [mem 0x91000000-0x911fffff], which spans more than ADMA0F28:00 [mem 0x91000000-0x91000fff] [ 11.404833] ------------[ cut here ]------------ [ 11.404849] WARNING: CPU: 0 PID: 213 at arch/x86/mm/ioremap.c:197 __ioremap_caller+0x22c/0x350() ...
I guessed this was because the DSDT defined an ADMA0F28 device with a memory resource overlapping with the LPMA device.
So I removed the overlapping resources (ADMA0F28 and SSPX0000) in the DSDT and then the driver attempted to boot the audio device but failed with this message in dmesg[4]:
[ 11.602291] baytrail-pcm-audio baytrail-pcm-audio: ipc: error DSP boot timeout ...
Then I noticed that the Interrupt resources of the LPMA device were out of order in the DSDT, so I put the Interrupt 0x18 as the first one[5] and now the driver can boot the device and upload the firmware to it[6]:
[ 11.433460] baytrail-pcm-audio baytrail-pcm-audio: FW version: 04.05.13.a0 [ 11.433468] baytrail-pcm-audio baytrail-pcm-audio: Build type: a0 [ 11.433473] baytrail-pcm-audio baytrail-pcm-audio: Build date: Apr 2 2014 14:14:39 [ 11.448257] byt-rt5640 byt-rt5640: rt5640-aif1 <-> baytrail-pcm-audio mapping ok ...
But still no sound.
I can see the mixer controls in alsamixer and I tried to initialize them copying from the alsactl output from the Android kernel[7], but no, still no sound.
I do not know if that matters, but the driver still emits this message:
[ 11.398304] baytrail-pcm-audio baytrail-pcm-audio: error: invalid DMA engine 0 [ 11.398314] baytrail-pcm-audio baytrail-pcm-audio: sst_dma_new failed -22 ...
I noticed that on the Android kernel[8] the DMA channels for the ADMA0F28 device are actually configured, the intel_mid_dma driver sets up 4 channels for it along with 2 x 6 channels for the INTL9C60 device.
On the mainline kernel only the INTL9C60 device gets configured, by the dw_dmac driver and with 2 x 8 channels.
I do not know much about these details tho.
Also, the codec driver on the Android kernel (byt_rt5642) seems to use one GPIO as an interrupt[9]: 390: 0 1 0 0 VLV-GPIO-gpio byt-codec-int
Which is pin 4 on GPO2, but the codec driver in the mainline kernel does not seem to be using this; however AFAICS in sound/soc/codecs/rt5640.c a gpio pin in only used for suspend/resume, so it is not strictly needed if it's already in the correct state, right?
Last question, what is the difference between having the device detected by sound/soc/intel/sst-acpi.c (like in my case) opposed to sound/soc/intel/sst/sst_acpi.c? I can see the 80860F28 id in both the files but they seem to load different firmwares.
Any idea of what is missing? It's the DSDT which still needs adjusting, or are some changes needed (also) in the kernel driver?
Thanks, Antonio
[1] http://ao2.it/110 [2] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dsdt_sst_original.dsl [3] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_mainline_sst_orig... [4] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_mainline_sst_with... [5] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dsdt_sst_without_ADMA0F... [6] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_mainline_sst_with... [7] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/android_asound.state [8] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_Android_Teclast_X... [9] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/android_proc_interrupts...
On Mon, 23 Feb 2015 18:39:13 +0100 Antonio Ospite ao2@ao2.it wrote:
Hi,
I am trying to get the Intel SST driver working on a Teclast X98 Air 3G [1], it's a Bay Trail tablet. The tests below have been made with 4.0.0-rc1 and the firmware files from https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tre...
Hi, has anyone had a chance to take a look at my previous message?
[...]
Last question, what is the difference between having the device detected by sound/soc/intel/sst-acpi.c (like in my case) opposed to sound/soc/intel/sst/sst_acpi.c? I can see the 80860F28 id in both the files but they seem to load different firmwares.
Another thing I noticed is that the Android driver for the rt5640 codec defines some controls which are not in the mainline driver:
OUT MIXR BST3 Switch OUT MIXL BST3 Switch RECMIXR BST3 Switch RECMIXL BST3 Switch IN1 Mode Control IN2 Mode Control
I tried to add these copying from some Android kernel found on-line[1] and set the value to the ones used on Android but they don't seem to make a difference.
Any idea of what is missing? It's the DSDT which still needs adjusting, or are some changes needed (also) in the kernel driver?
Thanks, Antonio
[1] https://github.com/ZenfoneArea/android_kernel_asus_zenfone5
Hi
On 03/03/2015 04:16 PM, Antonio Ospite wrote:
On Mon, 23 Feb 2015 18:39:13 +0100 Antonio Ospite ao2@ao2.it wrote:
Hi,
I am trying to get the Intel SST driver working on a Teclast X98 Air 3G [1], it's a Bay Trail tablet. The tests below have been made with 4.0.0-rc1 and the firmware files from https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tre...
Hi, has anyone had a chance to take a look at my previous message?
I forgot to answer... Some earlier notes including Teclast X98 Air 3G and patch attempts are collected here:
https://bugzilla.kernel.org/show_bug.cgi?id=86581
Unfortunately bug is not solved since it looks these newer Baytrail Windows 8.1 based machines use different SSP port than previous ones and Linux DSP firmware is hardcoded for SSP2.
What's interesting does that Android FW use other than SSP2 or does Teclast have some extra amplifier.
[...]
Last question, what is the difference between having the device detected by sound/soc/intel/sst-acpi.c (like in my case) opposed to sound/soc/intel/sst/sst_acpi.c? I can see the 80860F28 id in both the files but they seem to load different firmwares.
Different firmware, driver stack and machine driver despite the same LPE ACPI ID and codec ACPI ID. (We really should have some additional DMI quirks that does the selection because of the same ACPI IDs).
Another thing I noticed is that the Android driver for the rt5640 codec defines some controls which are not in the mainline driver:
OUT MIXR BST3 Switch OUT MIXL BST3 Switch RECMIXR BST3 Switch RECMIXL BST3 Switch IN1 Mode Control IN2 Mode Control
I'm not sure but these might be FW implemented DSP controls? Vinod, do you know?
On Tue, Mar 03, 2015 at 04:54:53PM +0200, Jarkko Nikula wrote:
Hi
On 03/03/2015 04:16 PM, Antonio Ospite wrote:
On Mon, 23 Feb 2015 18:39:13 +0100 Antonio Ospite ao2@ao2.it wrote:
Hi,
I am trying to get the Intel SST driver working on a Teclast X98 Air 3G [1], it's a Bay Trail tablet. The tests below have been made with 4.0.0-rc1 and the firmware files from https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tre...
Hi, has anyone had a chance to take a look at my previous message?
I forgot to answer... Some earlier notes including Teclast X98 Air 3G and patch attempts are collected here:
https://bugzilla.kernel.org/show_bug.cgi?id=86581
Unfortunately bug is not solved since it looks these newer Baytrail Windows 8.1 based machines use different SSP port than previous ones and Linux DSP firmware is hardcoded for SSP2.
What's interesting does that Android FW use other than SSP2 or does Teclast have some extra amplifier.
[...]
Last question, what is the difference between having the device detected by sound/soc/intel/sst-acpi.c (like in my case) opposed to sound/soc/intel/sst/sst_acpi.c? I can see the 80860F28 id in both the files but they seem to load different firmwares.
Different firmware, driver stack and machine driver despite the same LPE ACPI ID and codec ACPI ID. (We really should have some additional DMI quirks that does the selection because of the same ACPI IDs).
Another thing I noticed is that the Android driver for the rt5640 codec defines some controls which are not in the mainline driver:
OUT MIXR BST3 Switch OUT MIXL BST3 Switch RECMIXR BST3 Switch RECMIXL BST3 Switch IN1 Mode Control IN2 Mode Control
I'm not sure but these might be FW implemented DSP controls? Vinod, do you know?
Nope these are not DSP based... From description Antonio is saying these are from rt5640 driver... not upstreamed I think.
From: Koul, Vinod Sent: Tuesday, March 3, 2015 9:48 PM To: Jarkko Nikula Cc: Antonio Ospite; alsa-devel@alsa-project.org; Babu, Ramesh; Abdullah, Omair M; Harsha Priya; Mika Westerberg Subject: Re: [alsa-devel] Intel SST on a Bay Trail tablet
On Tue, Mar 03, 2015 at 04:54:53PM +0200, Jarkko Nikula wrote:
Hi
On 03/03/2015 04:16 PM, Antonio Ospite wrote:
On Mon, 23 Feb 2015 18:39:13 +0100 Antonio Ospite ao2@ao2.it wrote:
Hi,
I am trying to get the Intel SST driver working on a Teclast X98 Air 3G [1], it's a Bay Trail tablet. The tests below have been made with 4.0.0-rc1 and the firmware files from https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-
firmware.git/tree/intel
Hi, has anyone had a chance to take a look at my previous message?
I forgot to answer... Some earlier notes including Teclast X98 Air 3G and patch attempts are collected here:
https://bugzilla.kernel.org/show_bug.cgi?id=86581
Unfortunately bug is not solved since it looks these newer Baytrail Windows 8.1 based machines use different SSP port than previous ones and Linux DSP firmware is hardcoded for SSP2.
What's interesting does that Android FW use other than SSP2 or does Teclast have some extra amplifier.
[...]
Last question, what is the difference between having the device detected by sound/soc/intel/sst-acpi.c (like in my case) opposed to sound/soc/intel/sst/sst_acpi.c? I can see the 80860F28 id in both the files but they seem to load different firmwares.
Different firmware, driver stack and machine driver despite the same LPE ACPI ID and codec ACPI ID. (We really should have some additional DMI quirks that does the selection because of the same ACPI IDs).
Another thing I noticed is that the Android driver for the rt5640 codec defines some controls which are not in the mainline driver:
OUT MIXR BST3 Switch OUT MIXL BST3 Switch RECMIXR BST3 Switch RECMIXL BST3 Switch IN1 Mode Control IN2 Mode Control
I'm not sure but these might be FW implemented DSP controls? Vinod, do you know?
Nope these are not DSP based... From description Antonio is saying these are from rt5640 driver... not upstreamed I think.
Yes, they are Realtek codec controls, which are not upstreamed yet.
-- ~Vinod
-- Jarkko
--
On Tue, 03 Mar 2015 16:54:53 +0200 Jarkko Nikula jarkko.nikula@linux.intel.com wrote:
Hi
On 03/03/2015 04:16 PM, Antonio Ospite wrote:
On Mon, 23 Feb 2015 18:39:13 +0100 Antonio Ospite ao2@ao2.it wrote:
Hi,
I am trying to get the Intel SST driver working on a Teclast X98 Air 3G [1], it's a Bay Trail tablet. The tests below have been made with 4.0.0-rc1 and the firmware files from https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tre...
Hi, has anyone had a chance to take a look at my previous message?
I forgot to answer...
Do you confirm that the ADMA0F28 and SSPX0000 devices I mentioned in the original mail are not necessary in the DSDT?
Some earlier notes including Teclast X98 Air 3G and patch attempts are collected here:
I took a look, I fixed the interrupt issue reported there in the DSDT rather than in the kernel, and I confirm I get AudioDSP interrupts when playing.
Unfortunately bug is not solved since it looks these newer Baytrail Windows 8.1 based machines use different SSP port than previous ones and Linux DSP firmware is hardcoded for SSP2.
So the current guess is that DSP is indeed sending the data, but on the wrong port and hence the codec chip is not receiving it, isn't it?
Can Intel provide another firmware?
What's interesting does that Android FW use other than SSP2 or does Teclast have some extra amplifier.
I tried the chromium firmwares too but with no much luck: https://chromium.googlesource.com/chromiumos/third_party/linux-firmware/+/re...
I cannot use the android firmware because it seems to be in a different format (ELF instead of a structured blob with a SST header), I uploaded the android blobs here: http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/android_firmware/
Any hint about how to convert them to a form usable by the mainline driver?
Or any suggestions about how can I get more info from the running Android system?
[...]
Last question, what is the difference between having the device detected by sound/soc/intel/sst-acpi.c (like in my case) opposed to sound/soc/intel/sst/sst_acpi.c? I can see the 80860F28 id in both the files but they seem to load different firmwares.
Different firmware, driver stack and machine driver despite the same LPE ACPI ID and codec ACPI ID. (We really should have some additional DMI quirks that does the selection because of the same ACPI IDs).
Just curios, is a unification of the drivers possible/planned?
If I remove snd-soc-sst-acpi.ko I can get the other driver to load (i.e. snd_intel_sst_acpi, no _soc_ in the name):
[ 9.940954] bytt100_rt5640 bytt100_rt5640: snd-soc-dummy-dai <-> media-cpu-dai mapping ok [ 9.941015] compress asoc: snd-soc-dummy-dai <-> compress-cpu-dai mapping ok [ 9.941090] bytt100_rt5640 bytt100_rt5640: rt5640-aif1 <-> ssp2-port mapping ok [ 9.941249] bytt100_rt5640 bytt100_rt5640: Connecting non-supply widget to supply widget is not supported (Int Mic -> LDO2) [ 9.941254] bytt100_rt5640 bytt100_rt5640: ASoC: no dapm match for Int Mic --> (null) --> LDO2 [ 9.941259] bytt100_rt5640 bytt100_rt5640: ASoC: Failed to add route Int Mic -> direct -> LDO2 [ 10.826466] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 0 doesn't have DAPM widget!!! [ 10.826988] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 1 doesn't have DAPM widget!!! [ 10.827496] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 2 doesn't have DAPM widget!!! [ 10.828008] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 3 doesn't have DAPM widget!!! [ 10.828501] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in0_0 doesn't have DAPM widget!!! [ 10.829022] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in0_1 doesn't have DAPM widget!!! [ 10.829550] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in1_0 doesn't have DAPM widget!!! [ 10.830212] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in1_1 doesn't have DAPM widget!!!
but then I couldn't use the card:
[ 57.970464] Baytrail Audio Port: ASoC: no backend DAIs enabled for Baytrail Audio Port
Full dmesg here: http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_mainline_snd_inte...
But this is just to see what would happen, I am supposed to use the snd-soc-sst-acpi.ko driver, right?
Another thing I noticed is that the Android driver for the rt5640 codec defines some controls which are not in the mainline driver:
OUT MIXR BST3 Switch OUT MIXL BST3 Switch RECMIXR BST3 Switch RECMIXL BST3 Switch IN1 Mode Control IN2 Mode Control
I'm not sure but these might be FW implemented DSP controls? Vinod, do you know?
I could add these myself and other small things (e.g. jack insertion detection) to the codec driver once I got audio output working, but I really do not know how to deal with the SST driver.
Thanks, Antonio
On Wed, 4 Mar 2015 17:02:18 +0100 Antonio Ospite ao2@ao2.it wrote:
On Tue, 03 Mar 2015 16:54:53 +0200 Jarkko Nikula jarkko.nikula@linux.intel.com wrote:
Hi
On 03/03/2015 04:16 PM, Antonio Ospite wrote:
On Mon, 23 Feb 2015 18:39:13 +0100 Antonio Ospite ao2@ao2.it wrote:
Hi,
I am trying to get the Intel SST driver working on a Teclast X98 Air 3G [1], it's a Bay Trail tablet. The tests below have been made with 4.0.0-rc1 and the firmware files from https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tre...
Hi, has anyone had a chance to take a look at my previous message?
I forgot to answer...
Do you confirm that the ADMA0F28 and SSPX0000 devices I mentioned in the original mail are not necessary in the DSDT?
[...]
Ping.
Can anyone comment on this and my other questions in the previous email regarding the DSP firmware?
Thanks, Antonio
Hi
On 03/12/2015 03:45 PM, Antonio Ospite wrote:
Do you confirm that the ADMA0F28 and SSPX0000 devices I mentioned in the original mail are not necessary in the DSDT?
[...]
I don't know what their function is. I've seen them only in newer DSDT tables. I guess Windows 8.1 uses them for power management etc or it has separate drivers for DMA and SSP ports.
Ping.
Can anyone comment on this and my other questions in the previous email regarding the DSP firmware?
Vinod, Ramesh: Do you know would it be possible to run that Android ELF firmware that is installed in the Teclast with the newer stack in sound/soc/intel/sst?
On Thu, Mar 12, 2015 at 04:30:38PM +0200, Jarkko Nikula wrote:
Hi
On 03/12/2015 03:45 PM, Antonio Ospite wrote:
Do you confirm that the ADMA0F28 and SSPX0000 devices I mentioned in the original mail are not necessary in the DSDT?
[...]
I don't know what their function is. I've seen them only in newer DSDT tables. I guess Windows 8.1 uses them for power management etc or it has separate drivers for DMA and SSP ports.
Ping.
Can anyone comment on this and my other questions in the previous email regarding the DSP firmware?
Vinod, Ramesh: Do you know would it be possible to run that Android ELF firmware that is installed in the Teclast with the newer stack in sound/soc/intel/sst?
Sorry havent followed the thread, but we should be able to use the upstream firware. The ELF binary and the upstream ones are similar, we decided sometime back to not use ELF for future dev so we didnt upstream that part.
On Fri, 13 Mar 2015 12:03:45 +0530 Vinod Koul vinod.koul@intel.com wrote:
On Thu, Mar 12, 2015 at 04:30:38PM +0200, Jarkko Nikula wrote:
[...]
Vinod, Ramesh: Do you know would it be possible to run that Android ELF firmware that is installed in the Teclast with the newer stack in sound/soc/intel/sst?
Sorry havent followed the thread, but we should be able to use the upstream firware. The ELF binary and the upstream ones are similar, we decided sometime back to not use ELF for future dev so we didnt upstream that part.
Jakko said that the firmware distributed at linux-firmware.git hardcodes the SSP to SSP2, while on some boards the codec may be connected to SSP0, which could be my case.
That was the whole point of trying to reuse the firmware that was working in my Android installation.
Any hint about how to extract the firmware from the ELF and convert it to an SST firmware image usable with the upstream drivers? I could dig into the sources and figure out the structures myself but maybe you have some more accessible information.
Vinod, if you feel like catching up, the thread is also here: http://thread.gmane.org/gmane.linux.alsa.devel/134554
I ask a lot of questions, I know.
Thanks, Antonio
On Wed, 4 Mar 2015 17:02:18 +0100 Antonio Ospite ao2@ao2.it wrote:
On Tue, 03 Mar 2015 16:54:53 +0200 Jarkko Nikula jarkko.nikula@linux.intel.com wrote:
[...]
[...]
Last question, what is the difference between having the device detected by sound/soc/intel/sst-acpi.c (like in my case) opposed to sound/soc/intel/sst/sst_acpi.c? I can see the 80860F28 id in both the files but they seem to load different firmwares.
Different firmware, driver stack and machine driver despite the same LPE ACPI ID and codec ACPI ID. (We really should have some additional DMI quirks that does the selection because of the same ACPI IDs).
Just curios, is a unification of the drivers possible/planned?
Hi again, I am back on this after having read something more, the full thread is still here for those willing to catch up: http://thread.gmane.org/gmane.linux.alsa.devel/134554
Since the firmware which comes with Andoid is more similar to the upstream fw_sst_0f28.bin than is to fw_sst_0f28.bin-48kHz_i2s_master I decided to give another try to bytcr_dpcm_rt5640.c instead of insisting with byt-rt5640.c
The log is still as below, but I got one step further, keep reading.
[ 9.940954] bytt100_rt5640 bytt100_rt5640: snd-soc-dummy-dai <-> media-cpu-dai mapping ok [ 9.941015] compress asoc: snd-soc-dummy-dai <-> compress-cpu-dai mapping ok [ 9.941090] bytt100_rt5640 bytt100_rt5640: rt5640-aif1 <-> ssp2-port mapping ok [ 9.941249] bytt100_rt5640 bytt100_rt5640: Connecting non-supply widget to supply widget is not supported (Int Mic -> LDO2) [ 9.941254] bytt100_rt5640 bytt100_rt5640: ASoC: no dapm match for Int Mic --> (null) --> LDO2 [ 9.941259] bytt100_rt5640 bytt100_rt5640: ASoC: Failed to add route Int Mic -> direct -> LDO2 [ 10.826466] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 0 doesn't have DAPM widget!!! [ 10.826988] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 1 doesn't have DAPM widget!!! [ 10.827496] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 2 doesn't have DAPM widget!!! [ 10.828008] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 3 doesn't have DAPM widget!!! [ 10.828501] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in0_0 doesn't have DAPM widget!!! [ 10.829022] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in0_1 doesn't have DAPM widget!!! [ 10.829550] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in1_0 doesn't have DAPM widget!!! [ 10.830212] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in1_1 doesn't have DAPM widget!!!
but then I couldn't use the card:
[ 57.970464] Baytrail Audio Port: ASoC: no backend DAIs enabled for Baytrail Audio Port
Full dmesg here: http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_mainline_snd_inte...
I realized than I needed to set up the path between the FrontEnd DAI and the BackEnd one, and in fact the error below goes away and I can _start_ some playback after switching on these controls: codec_out1 mix 0 pcm0_in Switch media0_out mix 0 media1_in Switch which AFAICS constitute the playback path.
However there is still no sound, and the playback stalls, and the interrupt count suddenly stops for the intel_sst_driver IRQ (in /proc/interrupts).
By looking at /sys/kernel/debug under Android it looks like the codec is connected to SSP2, and not SSP0 as we imagined before: /sys/kernel/debug/asoc/baytrailaudio/sst-platform/dapm/ssp2 playback /sys/kernel/debug/asoc/baytrailaudio/sst-platform/dapm/ssp2 Capture
So now I'd like to make sure the mixer settings are OK before looking elsewhere again.
Vinod, Subhransu, or anyone else, can you share some working alsa state files for the baytrailcraudio device in linux mainline?
JFTR I am running a 64bit kernel, is this OK on BayTrail? I guess it is, but I just wanted to mention this to be sure.
Thanks, Antonio
On Wed, 4 Mar 2015 17:02:18 +0100 Antonio Ospite ao2@ao2.it wrote:
On Tue, 03 Mar 2015 16:54:53 +0200 Jarkko Nikula jarkko.nikula@linux.intel.com wrote:
[...]
[...]
Last question, what is the difference between having the device detected by sound/soc/intel/sst-acpi.c (like in my case) opposed to sound/soc/intel/sst/sst_acpi.c? I can see the 80860F28 id in both the files but they seem to load different firmwares.
Different firmware, driver stack and machine driver despite the same LPE ACPI ID and codec ACPI ID. (We really should have some additional DMI quirks that does the selection because of the same ACPI IDs).
Just curios, is a unification of the drivers possible/planned?
Hi again, I am back on this after having read something more, the full thread is still here for those willing to catch up: http://thread.gmane.org/gmane.linux.alsa.devel/134554
Since the firmware which comes with Andoid is more similar to the upstream fw_sst_0f28.bin than is to fw_sst_0f28.bin-48kHz_i2s_master I decided to give another try to bytcr_dpcm_rt5640.c instead of insisting with byt-rt5640.c
The log is still as below, but I got one step further, keep reading.
[ 9.940954] bytt100_rt5640 bytt100_rt5640: snd-soc-dummy-dai <-> media-cpu-dai mapping ok [ 9.941015] compress asoc: snd-soc-dummy-dai <-> compress-cpu-dai mapping ok [ 9.941090] bytt100_rt5640 bytt100_rt5640: rt5640-aif1 <-> ssp2-port mapping ok [ 9.941249] bytt100_rt5640 bytt100_rt5640: Connecting non-supply widget to supply widget is not supported (Int Mic -> LDO2) [ 9.941254] bytt100_rt5640 bytt100_rt5640: ASoC: no dapm match for Int Mic --> (null) --> LDO2 [ 9.941259] bytt100_rt5640 bytt100_rt5640: ASoC: Failed to add route Int Mic -> direct -> LDO2 [ 10.826466] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 0 doesn't have DAPM widget!!! [ 10.826988] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 1 doesn't have DAPM widget!!! [ 10.827496] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 2 doesn't have DAPM widget!!! [ 10.828008] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 3 doesn't have DAPM widget!!! [ 10.828501] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in0_0 doesn't have DAPM widget!!! [ 10.829022] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in0_1 doesn't have DAPM widget!!! [ 10.829550] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in1_0 doesn't have DAPM widget!!! [ 10.830212] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in1_1 doesn't have DAPM widget!!!
but then I couldn't use the card:
[ 57.970464] Baytrail Audio Port: ASoC: no backend DAIs enabled for Baytrail Audio Port
Full dmesg here: http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_mainline_snd_inte...
I realized than I needed to set up the path between the FrontEnd DAI and the BackEnd one, and in fact the error below goes away and I can _start_ some playback after switching on these controls: codec_out1 mix 0 pcm0_in Switch media0_out mix 0 media1_in Switch which AFAICS constitute the playback path.
However there is still no sound, and the playback stalls, and the interrupt count suddenly stops for the intel_sst_driver IRQ (in /proc/interrupts).
By looking at /sys/kernel/debug under Android it looks like the codec is connected to SSP2, and not SSP0 as we imagined before: /sys/kernel/debug/asoc/baytrailaudio/sst-platform/dapm/ssp2 playback /sys/kernel/debug/asoc/baytrailaudio/sst-platform/dapm/ssp2 Capture
So now I'd like to make sure the mixer settings are OK before looking elsewhere again.
Vinod, Subhransu, or anyone else, can you share some working alsa state files for the baytrailcraudio device in linux mainline?
JFTR I am running a 64bit kernel, is this OK on BayTrail? I guess it is, but I just wanted to mention this to be sure.
Thanks, Antonio
My 2c below.
On 04/14/2015 04:02 PM, Antonio Ospite wrote:
On Wed, 4 Mar 2015 17:02:18 +0100 Antonio Ospite ao2@ao2.it wrote:
I realized than I needed to set up the path between the FrontEnd DAI and the BackEnd one, and in fact the error below goes away and I can _start_ some playback after switching on these controls: codec_out1 mix 0 pcm0_in Switch media0_out mix 0 media1_in Switch which AFAICS constitute the playback path.
However there is still no sound, and the playback stalls, and the interrupt count suddenly stops for the intel_sst_driver IRQ (in /proc/interrupts).
What comes to my mind did you change .acpi_ipc_irq_index = 5 to 0 zero in sound/soc/intel/sst/sst_acpi.c: byt_rvp_res_info structure?
According to Teclast's DSDT table the DSP-host interrupt is at first interrupt resource index.
By looking at /sys/kernel/debug under Android it looks like the codec is connected to SSP2, and not SSP0 as we imagined before: /sys/kernel/debug/asoc/baytrailaudio/sst-platform/dapm/ssp2 playback /sys/kernel/debug/asoc/baytrailaudio/sst-platform/dapm/ssp2 Capture
So now I'd like to make sure the mixer settings are OK before looking elsewhere again.
Vinod, Subhransu, or anyone else, can you share some working alsa state files for the baytrailcraudio device in linux mainline?
Question to Vinod et all too:
I don't find above "ssp2 playback" and "ssp2 Capture" stream names from sound/soc/intel/sst-mfld-platform-pcm.c so I guess it has been evolved a bit from those original Android drivers.
Which makes me thinking how does those strings describe the SSP port setup? E.g. do they reflect what port is actually used or could it be possible that those are just driver strings but firmware could have been tuned for SSP0? If I looked at earlier right, Teclast has the low pin-count Baytrail without SSP2 but I'm not sure about that.
JFTR I am running a 64bit kernel, is this OK on BayTrail? I guess it is, but I just wanted to mention this to be sure.
Generally yes. I've used both 32- and 64-bit kernels when developing the sound/soc/intel/sst-baytrail-* but I haven't tested sound/soc/intel/sst/. Vinod, I guess that should be 64-bit safe too?
On Tue, 14 Apr 2015 17:06:27 +0300 Jarkko Nikula jarkko.nikula@linux.intel.com wrote:
My 2c below.
Thanks for always taking the time to reply Jarkko.
On 04/14/2015 04:02 PM, Antonio Ospite wrote:
On Wed, 4 Mar 2015 17:02:18 +0100 Antonio Ospite ao2@ao2.it wrote:
I realized than I needed to set up the path between the FrontEnd DAI and the BackEnd one, and in fact the error below goes away and I can _start_ some playback after switching on these controls: codec_out1 mix 0 pcm0_in Switch media0_out mix 0 media1_in Switch which AFAICS constitute the playback path.
However there is still no sound, and the playback stalls, and the interrupt count suddenly stops for the intel_sst_driver IRQ (in /proc/interrupts).
What comes to my mind did you change .acpi_ipc_irq_index = 5 to 0 zero in sound/soc/intel/sst/sst_acpi.c: byt_rvp_res_info structure?
According to Teclast's DSDT table the DSP-host interrupt is at first interrupt resource index.
I changed the order of the interrupts in the DSDT to be as the driver expects it (0x00000018 is now the first one and 0x0000001D is the sixth one, see the LPEA device in [1]), this should be equivalent.
[1] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_mainline_sst_with...
BTW, after further tests it looks like the irq issue also depends on the mixer state, by playing with the controls I can get the interrupt to fire up again at some point.
That's one more reason for me to start from an asound.state proved to be working for someone else with the latest mainline drivers (in my latest email I was asking one for bytcr_dpcm_rt5640.c).
By looking at /sys/kernel/debug under Android it looks like the codec is connected to SSP2, and not SSP0 as we imagined before: /sys/kernel/debug/asoc/baytrailaudio/sst-platform/dapm/ssp2 playback /sys/kernel/debug/asoc/baytrailaudio/sst-platform/dapm/ssp2 Capture
So now I'd like to make sure the mixer settings are OK before looking elsewhere again.
Vinod, Subhransu, or anyone else, can you share some working alsa state files for the baytrailcraudio device in linux mainline?
Question to Vinod et all too:
I don't find above "ssp2 playback" and "ssp2 Capture" stream names from sound/soc/intel/sst-mfld-platform-pcm.c so I guess it has been evolved a bit from those original Android drivers.
Which makes me thinking how does those strings describe the SSP port setup? E.g. do they reflect what port is actually used or could it be possible that those are just driver strings but firmware could have been tuned for SSP0? If I looked at earlier right, Teclast has the low pin-count Baytrail without SSP2 but I'm not sure about that.
There is also the doubt of DMA apparently being used in the Andoid kernel, any comment on that?
I am also trying to convert the Android elf firmware to the structure used in the mainline driver, see[2], but the converted firmware does not boot with the mainline driver; I must be missing something here as well, but this is more of a blind and desperate tentative anyway.
[2] http://git.ao2.it/sst_elf_firmware_convert.git/
JFTR I am running a 64bit kernel, is this OK on BayTrail? I guess it is, but I just wanted to mention this to be sure.
Generally yes. I've used both 32- and 64-bit kernels when developing the sound/soc/intel/sst-baytrail-* but I haven't tested sound/soc/intel/sst/. Vinod, I guess that should be 64-bit safe too?
-- Jarkko
Thanks again, Antonio
On Tue, 14 Apr 2015 17:06:27 +0300 Jarkko Nikula jarkko.nikula@linux.intel.com wrote:
My 2c below.
Thanks for always taking the time to reply Jarkko.
On 04/14/2015 04:02 PM, Antonio Ospite wrote:
On Wed, 4 Mar 2015 17:02:18 +0100 Antonio Ospite ao2@ao2.it wrote:
I realized than I needed to set up the path between the FrontEnd DAI and the BackEnd one, and in fact the error below goes away and I can _start_ some playback after switching on these controls: codec_out1 mix 0 pcm0_in Switch media0_out mix 0 media1_in Switch which AFAICS constitute the playback path.
However there is still no sound, and the playback stalls, and the interrupt count suddenly stops for the intel_sst_driver IRQ (in /proc/interrupts).
What comes to my mind did you change .acpi_ipc_irq_index = 5 to 0 zero in sound/soc/intel/sst/sst_acpi.c: byt_rvp_res_info structure?
According to Teclast's DSDT table the DSP-host interrupt is at first interrupt resource index.
I changed the order of the interrupts in the DSDT to be as the driver expects it (0x00000018 is now the first one and 0x0000001D is the sixth one, see the LPEA device in [1]), this should be equivalent.
[1] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_mainline_sst_with...
BTW, after further tests it looks like the irq issue also depends on the mixer state, by playing with the controls I can get the interrupt to fire up again at some point.
That's one more reason for me to start from an asound.state proved to be working for someone else with the latest mainline drivers (in my latest email I was asking one for bytcr_dpcm_rt5640.c).
By looking at /sys/kernel/debug under Android it looks like the codec is connected to SSP2, and not SSP0 as we imagined before: /sys/kernel/debug/asoc/baytrailaudio/sst-platform/dapm/ssp2 playback /sys/kernel/debug/asoc/baytrailaudio/sst-platform/dapm/ssp2 Capture
So now I'd like to make sure the mixer settings are OK before looking elsewhere again.
Vinod, Subhransu, or anyone else, can you share some working alsa state files for the baytrailcraudio device in linux mainline?
Question to Vinod et all too:
I don't find above "ssp2 playback" and "ssp2 Capture" stream names from sound/soc/intel/sst-mfld-platform-pcm.c so I guess it has been evolved a bit from those original Android drivers.
Which makes me thinking how does those strings describe the SSP port setup? E.g. do they reflect what port is actually used or could it be possible that those are just driver strings but firmware could have been tuned for SSP0? If I looked at earlier right, Teclast has the low pin-count Baytrail without SSP2 but I'm not sure about that.
There is also the doubt of DMA apparently being used in the Andoid kernel, any comment on that?
I am also trying to convert the Android elf firmware to the structure used in the mainline driver, see[2], but the converted firmware does not boot with the mainline driver; I must be missing something here as well, but this is more of a blind and desperate tentative anyway.
[2] http://git.ao2.it/sst_elf_firmware_convert.git/
JFTR I am running a 64bit kernel, is this OK on BayTrail? I guess it is, but I just wanted to mention this to be sure.
Generally yes. I've used both 32- and 64-bit kernels when developing the sound/soc/intel/sst-baytrail-* but I haven't tested sound/soc/intel/sst/. Vinod, I guess that should be 64-bit safe too?
-- Jarkko
Thanks again, Antonio
On Tue, Apr 14, 2015 at 05:06:27PM +0300, Jarkko Nikula wrote:
My 2c below.
On 04/14/2015 04:02 PM, Antonio Ospite wrote:
On Wed, 4 Mar 2015 17:02:18 +0100 Antonio Ospite ao2@ao2.it wrote:
I realized than I needed to set up the path between the FrontEnd DAI and the BackEnd one, and in fact the error below goes away and I can _start_ some playback after switching on these controls: codec_out1 mix 0 pcm0_in Switch media0_out mix 0 media1_in Switch which AFAICS constitute the playback path.
However there is still no sound, and the playback stalls, and the interrupt count suddenly stops for the intel_sst_driver IRQ (in /proc/interrupts).
What comes to my mind did you change .acpi_ipc_irq_index = 5 to 0 zero in sound/soc/intel/sst/sst_acpi.c: byt_rvp_res_info structure?
According to Teclast's DSDT table the DSP-host interrupt is at first interrupt resource index.
By looking at /sys/kernel/debug under Android it looks like the codec is connected to SSP2, and not SSP0 as we imagined before: /sys/kernel/debug/asoc/baytrailaudio/sst-platform/dapm/ssp2 playback /sys/kernel/debug/asoc/baytrailaudio/sst-platform/dapm/ssp2 Capture
So now I'd like to make sure the mixer settings are OK before looking elsewhere again.
Vinod, Subhransu, or anyone else, can you share some working alsa state files for the baytrailcraudio device in linux mainline?
Question to Vinod et all too:
I don't find above "ssp2 playback" and "ssp2 Capture" stream names from sound/soc/intel/sst-mfld-platform-pcm.c so I guess it has been evolved a bit from those original Android drivers.
The upstream code is subset of one in Android but base stuff is still the same
Which makes me thinking how does those strings describe the SSP port setup? E.g. do they reflect what port is actually used or could it be possible that those are just driver strings but firmware could have been tuned for SSP0? If I looked at earlier right, Teclast has the low pin-count Baytrail without SSP2 but I'm not sure about that.
The FW doesnt provide way to changes ports from driver in this, so this doesnt mean much. If we are sure it is not ssp2, I can provide ssp1 fw for test
JFTR I am running a 64bit kernel, is this OK on BayTrail? I guess it is, but I just wanted to mention this to be sure.
Generally yes. I've used both 32- and 64-bit kernels when developing the sound/soc/intel/sst-baytrail-* but I haven't tested sound/soc/intel/sst/. Vinod, I guess that should be 64-bit safe too?
Yup tested on both :)
On Wed, 24 Jun 2015 15:46:13 +0530 Vinod Koul vinod.koul@intel.com wrote:
Hi Vinod, thank you for replying.
On Tue, Apr 14, 2015 at 05:06:27PM +0300, Jarkko Nikula wrote:
My 2c below.
On 04/14/2015 04:02 PM, Antonio Ospite wrote:
On Wed, 4 Mar 2015 17:02:18 +0100 Antonio Ospite ao2@ao2.it wrote:
[...]
Vinod, Subhransu, or anyone else, can you share some working alsa state files for the baytrailcraudio device in linux mainline?
This question still stands. :)
Question to Vinod et all too:
I don't find above "ssp2 playback" and "ssp2 Capture" stream names from sound/soc/intel/sst-mfld-platform-pcm.c so I guess it has been evolved a bit from those original Android drivers.
The upstream code is subset of one in Android but base stuff is still the same
Which makes me thinking how does those strings describe the SSP port setup? E.g. do they reflect what port is actually used or could it be possible that those are just driver strings but firmware could have been tuned for SSP0? If I looked at earlier right, Teclast has the low pin-count Baytrail without SSP2 but I'm not sure about that.
The FW doesnt provide way to changes ports from driver in this, so this doesnt mean much. If we are sure it is not ssp2, I can provide ssp1 fw for test
Is it possible to figure it out from the Android firmware? http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/android_firmware/
As said earlier I had also tried to convert the Android firmware to the structure used in the mainline kernel, but with no success: http://git.ao2.it/sst_elf_firmware_convert.git/
Or should I look at the board layout to find out what port the codec is connected to? I don't have an oscilloscope or a logic analyzer for more accurate investigation (would Intel be interested in sponsoring one, BTW?)
I will surely test alternative firmwares if you provide them.
Thanks, Antonio
P.S. in email messages, putting a blank line between the quoted text and the reply helps readability; not all MUAs have syntax highlighting.
On Wed, Jun 24, 2015 at 03:46:13PM +0530, Vinod Koul wrote:
On Tue, Apr 14, 2015 at 05:06:27PM +0300, Jarkko Nikula wrote:
My 2c below.
On 04/14/2015 04:02 PM, Antonio Ospite wrote:
On Wed, 4 Mar 2015 17:02:18 +0100 Antonio Ospite ao2@ao2.it wrote:
I realized than I needed to set up the path between the FrontEnd DAI and the BackEnd one, and in fact the error below goes away and I can _start_ some playback after switching on these controls: codec_out1 mix 0 pcm0_in Switch media0_out mix 0 media1_in Switch which AFAICS constitute the playback path.
However there is still no sound, and the playback stalls, and the interrupt count suddenly stops for the intel_sst_driver IRQ (in /proc/interrupts).
What comes to my mind did you change .acpi_ipc_irq_index = 5 to 0 zero in sound/soc/intel/sst/sst_acpi.c: byt_rvp_res_info structure?
According to Teclast's DSDT table the DSP-host interrupt is at first interrupt resource index.
By looking at /sys/kernel/debug under Android it looks like the codec is connected to SSP2, and not SSP0 as we imagined before: /sys/kernel/debug/asoc/baytrailaudio/sst-platform/dapm/ssp2 playback /sys/kernel/debug/asoc/baytrailaudio/sst-platform/dapm/ssp2 Capture
So now I'd like to make sure the mixer settings are OK before looking elsewhere again.
Vinod, Subhransu, or anyone else, can you share some working alsa state files for the baytrailcraudio device in linux mainline?
Question to Vinod et all too:
I don't find above "ssp2 playback" and "ssp2 Capture" stream names from sound/soc/intel/sst-mfld-platform-pcm.c so I guess it has been evolved a bit from those original Android drivers.
The upstream code is subset of one in Android but base stuff is still the same
Which makes me thinking how does those strings describe the SSP port setup? E.g. do they reflect what port is actually used or could it be possible that those are just driver strings but firmware could have been tuned for SSP0? If I looked at earlier right, Teclast has the low pin-count Baytrail without SSP2 but I'm not sure about that.
The FW doesnt provide way to changes ports from driver in this, so this doesnt mean much. If we are sure it is not ssp2, I can provide ssp1 fw for test
I ahve pushed latest BYT version we have as well as added binary for second SSP port. Please give it a try:
https://git.kernel.org/cgit/linux/kernel/git/vkoul/firmware.git/commit/?h=by...
On Thu, 25 Jun 2015 11:20:46 +0530 Vinod Koul vinod.koul@intel.com wrote:
On Wed, Jun 24, 2015 at 03:46:13PM +0530, Vinod Koul wrote:
On Tue, Apr 14, 2015 at 05:06:27PM +0300, Jarkko Nikula wrote:
[...]
Which makes me thinking how does those strings describe the SSP port setup? E.g. do they reflect what port is actually used or could it be possible that those are just driver strings but firmware could have been tuned for SSP0? If I looked at earlier right, Teclast has the low pin-count Baytrail without SSP2 but I'm not sure about that.
The FW doesnt provide way to changes ports from driver in this, so this doesnt mean much. If we are sure it is not ssp2, I can provide ssp1 fw for test
I ahve pushed latest BYT version we have as well as added binary for second SSP port. Please give it a try:
https://git.kernel.org/cgit/linux/kernel/git/vkoul/firmware.git/commit/?h=by...
Thanks Vinod, but I see these are in the ELF format, and the mainline driver does not support this format, at least the last time I checked it didn't.
Ciao, Antonio
On Thu, Jun 25, 2015 at 12:21:24PM +0200, Antonio Ospite wrote:
On Thu, 25 Jun 2015 11:20:46 +0530 Vinod Koul vinod.koul@intel.com wrote:
On Wed, Jun 24, 2015 at 03:46:13PM +0530, Vinod Koul wrote:
On Tue, Apr 14, 2015 at 05:06:27PM +0300, Jarkko Nikula wrote:
[...]
Which makes me thinking how does those strings describe the SSP port setup? E.g. do they reflect what port is actually used or could it be possible that those are just driver strings but firmware could have been tuned for SSP0? If I looked at earlier right, Teclast has the low pin-count Baytrail without SSP2 but I'm not sure about that.
The FW doesnt provide way to changes ports from driver in this, so this doesnt mean much. If we are sure it is not ssp2, I can provide ssp1 fw for test
I ahve pushed latest BYT version we have as well as added binary for second SSP port. Please give it a try:
https://git.kernel.org/cgit/linux/kernel/git/vkoul/firmware.git/commit/?h=by...
Thanks Vinod, but I see these are in the ELF format, and the mainline driver does not support this format, at least the last time I checked it didn't.
My bad, updated the patch now with right format
https://git.kernel.org/cgit/linux/kernel/git/vkoul/firmware.git/commit/?h=by...
On Thu, 25 Jun 2015 22:17:17 +0530 Vinod Koul vinod.koul@intel.com wrote:
On Thu, Jun 25, 2015 at 12:21:24PM +0200, Antonio Ospite wrote:
On Thu, 25 Jun 2015 11:20:46 +0530 Vinod Koul vinod.koul@intel.com wrote:
On Wed, Jun 24, 2015 at 03:46:13PM +0530, Vinod Koul wrote:
On Tue, Apr 14, 2015 at 05:06:27PM +0300, Jarkko Nikula wrote:
[...]
Which makes me thinking how does those strings describe the SSP port setup? E.g. do they reflect what port is actually used or could it be possible that those are just driver strings but firmware could have been tuned for SSP0? If I looked at earlier right, Teclast has the low pin-count Baytrail without SSP2 but I'm not sure about that.
The FW doesnt provide way to changes ports from driver in this, so this doesnt mean much. If we are sure it is not ssp2, I can provide ssp1 fw for test
I ahve pushed latest BYT version we have as well as added binary for second SSP port. Please give it a try:
https://git.kernel.org/cgit/linux/kernel/git/vkoul/firmware.git/commit/?h=by...
Thanks Vinod, but I see these are in the ELF format, and the mainline driver does not support this format, at least the last time I checked it didn't.
My bad, updated the patch now with right format
https://git.kernel.org/cgit/linux/kernel/git/vkoul/firmware.git/commit/?h=by...
(Adding Michele to CC)
OK, so Jarkko was right: after a quick test I confirm that with fw_sst_0f28_ssp0.bin I get sound; this is quite an improvement, thanks!
I am going to update the report on bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86581
I used the amixer commands which Vinod provided in the other thread, in particular, the playback path is this one:
amixer -c0 sset 'codec_out0 mix 0 pcm0_in' on amixer -c0 sset 'media0_out mix 0 media1_in' on
The sound is a bit distorted tho, I can alleviate this effect by lowering the values of these controls: - codec_out0 Gain0 - media1_in Gain0 - pcm0_in Gain0
but the distortions do not go completely away, and they are not present in Android even at the highest volume.
I will perform more tests (capture, headphones) when 4.2-rc1 is out and report back the results.
JFTR, I made sure to use the DPCM driver by preventing the other one from being loaded:
diff --git a/sound/soc/intel/common/sst-acpi.c b/sound/soc/intel/common/sst-acpi.c index 42f293f..66ee705 100644 --- a/sound/soc/intel/common/sst-acpi.c +++ b/sound/soc/intel/common/sst-acpi.c @@ -266,7 +266,6 @@ static struct sst_acpi_desc sst_acpi_baytrail_desc = { static struct acpi_device_id sst_acpi_match[] = { { "INT33C8", (unsigned long)&sst_acpi_haswell_desc }, { "INT3438", (unsigned long)&sst_acpi_broadwell_desc }, - { "80860F28", (unsigned long)&sst_acpi_baytrail_desc }, { } }; MODULE_DEVICE_TABLE(acpi, sst_acpi_match);
Would it be worth providing a SSP0 variant of fw_sst_0f28.bin-48kHz_i2s_master too? Or is the intel/atom/sst/sst_acpi.c going to completely replace intel/common/sst-acpi.c?
Thanks a lot, Antonio
On Fri, Jun 26, 2015 at 03:05:28PM +0200, Antonio Ospite wrote:
On Thu, 25 Jun 2015 22:17:17 +0530 Vinod Koul vinod.koul@intel.com wrote:
On Thu, Jun 25, 2015 at 12:21:24PM +0200, Antonio Ospite wrote:
On Thu, 25 Jun 2015 11:20:46 +0530 Vinod Koul vinod.koul@intel.com wrote:
On Wed, Jun 24, 2015 at 03:46:13PM +0530, Vinod Koul wrote:
On Tue, Apr 14, 2015 at 05:06:27PM +0300, Jarkko Nikula wrote:
[...]
Which makes me thinking how does those strings describe the SSP port setup? E.g. do they reflect what port is actually used or could it be possible that those are just driver strings but firmware could have been tuned for SSP0? If I looked at earlier right, Teclast has the low pin-count Baytrail without SSP2 but I'm not sure about that.
The FW doesnt provide way to changes ports from driver in this, so this doesnt mean much. If we are sure it is not ssp2, I can provide ssp1 fw for test
I ahve pushed latest BYT version we have as well as added binary for second SSP port. Please give it a try:
https://git.kernel.org/cgit/linux/kernel/git/vkoul/firmware.git/commit/?h=by...
Thanks Vinod, but I see these are in the ELF format, and the mainline driver does not support this format, at least the last time I checked it didn't.
My bad, updated the patch now with right format
https://git.kernel.org/cgit/linux/kernel/git/vkoul/firmware.git/commit/?h=by...
(Adding Michele to CC)
OK, so Jarkko was right: after a quick test I confirm that with fw_sst_0f28_ssp0.bin I get sound; this is quite an improvement, thanks!
Okay that is great
I am going to update the report on bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=86581
I used the amixer commands which Vinod provided in the other thread, in particular, the playback path is this one:
amixer -c0 sset 'codec_out0 mix 0 pcm0_in' on amixer -c0 sset 'media0_out mix 0 media1_in' on
The sound is a bit distorted tho, I can alleviate this effect by lowering the values of these controls:
- codec_out0 Gain0
- media1_in Gain0
- pcm0_in Gain0
but the distortions do not go completely away, and they are not present in Android even at the highest volume.
I dont think the gain is causing the distortion. It can be SSP settings DO you see distortion in one channel or both (try with headset)
Also on Android, do you know kernel source for this, if vendor did release we cna check the settings there and configure the same here. Also cna you confirm which machine driver was loaded
I will perform more tests (capture, headphones) when 4.2-rc1 is out and report back the results.
JFTR, I made sure to use the DPCM driver by preventing the other one from being loaded:
You should blacklist that one ...
Vinod Koul <vinod.koul <at> intel.com> writes:
The sound is a bit distorted tho, I can alleviate this effect by lowering the values of these controls:
- codec_out0 Gain0
- media1_in Gain0
- pcm0_in Gain0
but the distortions do not go completely away, and they are not present in Android even at the highest volume.
I dont think the gain is causing the distortion. It can be SSP settings DO you see distortion in one channel or both (try with headset)
Hi Vinod,
I've been following this thread since a while and trying out the various things suggested. I have an Acer Aspire Switch 10 which seems to have the same audio chip like the Teclast and the other tablets mentioned in the bugzilla thread. I also had to change the interrupt index and tried the other driver with the fw_sst_0f28.bin-48kHz_i2s_master firmware, got overheating etc. etc. Finally following the advice in this thread I got to the same point, mfld driver with ssp0 firmware and applying the alsa settings as in
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-June/094080.html
I get the distorted sound. I've been playing around with the mixer controls and wanted to report back my findings, maybe it can help. What I've found:
1) Sound seems only to be coming from the right speaker. If I turn off "Speaker R" there's no sound. Turning off "Speaker L" doesn't seem to do anything. If I turn off both playback stalls. Generally If I turn off any of the setting suggested in your mail playback stalls (mplayer).
2) By turning on "HPO MIX DAC1" "HPO MIX DAC2" "HP L" and "HP R" I get sound from the headset. Here also the sound is distorted and is only coming from the right channel.
3) Volume controls "Headphone" "Speaker" have no effect (I can't turn off the volume).
My kernel is: 4.1.0
Modules:
$ lsmod | grep snd
snd_soc_sst_bytcr_rt5640 16384 0 snd_soc_rt5640 86016 1 snd_soc_rl6231 16384 1 snd_soc_rt5640 regmap_i2c 16384 1 snd_soc_rt5640 snd_intel_sst_acpi 16384 1 snd_intel_sst_core 69632 1 snd_intel_sst_acpi snd_soc_sst_mfld_platform 69632 3 snd_intel_sst_core snd_soc_core 155648 4 snd_soc_rt5640,snd_soc_sst_mfld_platform,snd_soc_sst_bytcr_rt5640 snd_compress 20480 1 snd_soc_core snd_pcm 106496 4 snd_soc_rt5640,snd_soc_core,snd_soc_sst_mfld_platform,snd_soc_sst_bytcr_rt5640 snd_timer 28672 1 snd_pcm snd 69632 7 snd_soc_core,snd_timer,snd_pcm,snd_soc_sst_mfld_platform,snd_compress soundcore 16384 1 snd
alsa.state is "baytrailcraudio" with the setting suggested in your mail.
I hope this info will be helpful!
regards Istvan
Yes, with ssp0 firmware, my board sound work too, but the mic don't work, when using arecord -f dat -t wav -d 5 foobar.wav, the record data is 0.
hexdump foobar.wav 0000000 4952 4646 a624 000e 4157 4556 6d66 2074 0000010 0010 0000 0001 0002 bb80 0000 ee00 0002 0000020 0004 0010 6164 6174 a600 000e 0000 0000 0000030 0000 0000 0000 0000 0000 0000 0000 0000 * 00ea62c
my analog microphone is connected to the IN2+ and MIC_BIAS1 codec pins I set alsa as : Stereo ADC MIXL ADC1 on Stereo ADC1 Mux ==> ADCL RECMIXL INL on RECMIXL BST2 on pcm1_out mix 0 codec_in1 on
participants (6)
-
Antonio Ospite -
Babu, Ramesh -
Istvan Sandor -
Jarkko Nikula -
LemonZou -
Vinod Koul