Intel SST on a Bay Trail tablet

Intel SST on a Bay Trail tablet

[Antonio Ospite]

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

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_original_DSDT.log
[4] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_mainline_sst_without_ADMA0F28.log
[5] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dsdt_sst_without_ADMA0F28_reorder_Interrupts.dsl
[6] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/dmesg_mainline_sst_without_ADMA0F28_reorder_Interrupts.log
[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_X98_Air_3G.log
[9] http://ao2.it/tmp/sst-baytrail-on-Teclast-X98-Air-3G/android_proc_interrupts.log

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: Intel SST on a Bay Trail tablet

[Antonio Ospite]

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?

[...]
> 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

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: Intel SST on a Bay Trail tablet

[Jarkko Nikula]

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?

-- 
Jarkko

Re: Intel SST on a Bay Trail tablet

[Vinod Koul]

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.

-- 
~Vinod

> 
> -- 
> Jarkko

-- 

Re: Intel SST on a Bay Trail tablet

[Babu, Ramesh]

> 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
> 
> --

Re: Intel SST on a Bay Trail tablet

[Antonio Ospite]

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/tree/intel
> >>
> >
> > 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:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=86581
>

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/+/refs/heads/stabilize-5339.B/intel/

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_intel_sst_acpi.log

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

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: Intel SST on a Bay Trail tablet

[Antonio Ospite]

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/tree/intel
> > >>
> > >
> > > 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

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: Intel SST on a Bay Trail tablet

[Jarkko Nikula]

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?

-- 
Jarkko

Re: Intel SST on a Bay Trail tablet

[Vinod Koul]

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.

-- 
~Vinod

Re: Intel SST on a Bay Trail tablet

[Antonio Ospite]

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

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: Intel SST on a Bay Trail tablet

[Antonio Ospite]

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_intel_sst_acpi.log
> 

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

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: Intel SST on a Bay Trail tablet

[Antonio Ospite]

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_intel_sst_acpi.log
> 

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

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Intel SST on a Bay Trail tablet

[Jarkko Nikula]

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?

-- 
Jarkko

Re: Intel SST on a Bay Trail tablet

[Antonio Ospite]

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_without_ADMA0F28_reorder_Interrupts.log

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

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: Intel SST on a Bay Trail tablet

[Antonio Ospite]

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_without_ADMA0F28_reorder_Interrupts.log

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

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: Intel SST on a Bay Trail tablet

[Vinod Koul]

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 :)

-- 
~Vinod

Re: Intel SST on a Bay Trail tablet

[Antonio Ospite]

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.

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: Intel SST on a Bay Trail tablet

[Vinod Koul]

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=byt&id=28ff420dd33ec299217bad7d526ff3bfd163b551

-- 
~Vinod

> > 
> > >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 :)
> 
> -- 
> ~Vinod

-- 

Re: Intel SST on a Bay Trail tablet

[Antonio Ospite]

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=byt&id=28ff420dd33ec299217bad7d526ff3bfd163b551
> 

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

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: Intel SST on a Bay Trail tablet

[Vinod Koul]

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=byt&id=28ff420dd33ec299217bad7d526ff3bfd163b551
> > 
> 
> 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=byt

-- 
~Vinod

Re: Intel SST on a Bay Trail tablet

[Antonio Ospite]

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=byt&id=28ff420dd33ec299217bad7d526ff3bfd163b551
> > > 
> > 
> > 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=byt
>

(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

-- 
Antonio Ospite
http://ao2.it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Re: Intel SST on a Bay Trail tablet

[Vinod Koul]

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=byt&id=28ff420dd33ec299217bad7d526ff3bfd163b551
> > > > 
> > > 
> > > 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=byt
> >
> 
> (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

> 
> 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
> 
> -- 
> Antonio Ospite
> http://ao2.it
> 
> A: Because it messes up the order in which people normally read text.
>    See http://en.wikipedia.org/wiki/Posting_style
> Q: Why is top-posting such a bad thing?

-- 

Re: Intel SST on a Bay Trail tablet

[Istvan Sandor]

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

Re: Intel SST on a Bay Trail tablet

[LemonZou]

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

Intel SST on a Bay Trail tablet

[Michele Curti]

> On Thu, 25 Jun 2015 22:17:17 +0530 Vinod Koul 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 at 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=byt&id=28ff420dd33ec299217bad7d526ff3bfd163b551
> > > > 
> > > 
> > > 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=byt
> >
> 
> (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!

Damn, completely missed..

Hi Vinod,
if it's possible, could you please generate a fw_sst_0f28_ssp1.bin
also, so I can test my driver (mine was for the Asus X205TA laptop,
where the codec is on SSP1 port)?

Thanks,
Michele

Re: Intel SST on a Bay Trail tablet

[Vinod Koul]

On Mon, Aug 24, 2015 at 03:29:04PM +0200, Michele Curti wrote:
> > On Thu, 25 Jun 2015 22:17:17 +0530 Vinod Koul 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 at 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=byt&id=28ff420dd33ec299217bad7d526ff3bfd163b551
> > > > > 
> > > > 
> > > > 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=byt
> > >
> > 
> > (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!
> 
> Damn, completely missed..
> 
> Hi Vinod,
> if it's possible, could you please generate a fw_sst_0f28_ssp1.bin
> also, so I can test my driver (mine was for the Asus X205TA laptop,
> where the codec is on SSP1 port)?

Are you sure you ahve SSP1 port enabled. I have not seen anyone using that
one. Jarkko do you know about this?

I will ask firmware folks for generation (i don't do that) and get back

-- 
~Vinod

Re: Intel SST on a Bay Trail tablet

[Luka Karinja]

>> Damn, completely missed..
>>
>> Hi Vinod,
>> if it's possible, could you please generate a fw_sst_0f28_ssp1.bin
>> also, so I can test my driver (mine was for the Asus X205TA laptop,
>> where the codec is on SSP1 port)?
> Are you sure you ahve SSP1 port enabled. I have not seen anyone using that
> one. Jarkko do you know about this?
>
> I will ask firmware folks for generation (i don't do that) and get back
>
Hi Vinod

The Asus T100TAF seems to be using the SSP1 port too with a RT5642,.
I have tested SSP2 and SSP0 firmwares, only getting heat and clicks,
errors reported by Michele are the same on my device.
In the DSDT there are only references to SSP1.

Re: Intel SST on a Bay Trail tablet

[Pierre-Louis Bossart]

> The Asus T100TAF seems to be using the SSP1 port too with a RT5642,.
> I have tested SSP2 and SSP0 firmwares, only getting heat and clicks,
> errors reported by Michele are the same on my device.
> In the DSDT there are only references to SSP1.

On the original Asus T100 there are also references to SSP1 but they are 
not related to audio at all (they are in the XHCI1 scope). To the best 
of my knowledge the SSP number is not configured in the BIOS, that seems 
like a red herring.
Can you please share the DSDT table for this device?

Thanks,
-Pierre

Re: Intel SST on a Bay Trail tablet

[Michele Curti]

On Mon, Aug 24, 2015 at 05:05:41PM +0200, Luka Karinja wrote:
> 
> >>Damn, completely missed..
> >>
> >>Hi Vinod,
> >>if it's possible, could you please generate a fw_sst_0f28_ssp1.bin
> >>also, so I can test my driver (mine was for the Asus X205TA laptop,
> >>where the codec is on SSP1 port)?
> >Are you sure you ahve SSP1 port enabled. I have not seen anyone using that
> >one. Jarkko do you know about this?
> >
> >I will ask firmware folks for generation (i don't do that) and get back
> >
> Hi Vinod
> 
> The Asus T100TAF seems to be using the SSP1 port too with a RT5642,.
> I have tested SSP2 and SSP0 firmwares, only getting heat and clicks,
> errors reported by Michele are the same on my device.
> In the DSDT there are only references to SSP1.

Yep, I also remember only SSP1 in ACPI tables.  I'll check when I'll have
access to the laptop to be sure.

Thanks,
Michele

Re: Intel SST on a Bay Trail tablet

[Michele Curti]

On Mon, Aug 24, 2015 at 07:56:25PM +0530, Vinod Koul wrote:
> On Mon, Aug 24, 2015 at 03:29:04PM +0200, Michele Curti wrote:
> > 
> > Damn, completely missed..
> > 
> > Hi Vinod,
> > if it's possible, could you please generate a fw_sst_0f28_ssp1.bin
> > also, so I can test my driver (mine was for the Asus X205TA laptop,
> > where the codec is on SSP1 port)?
> 
> Are you sure you ahve SSP1 port enabled. I have not seen anyone using that
> one. Jarkko do you know about this?
> 
> I will ask firmware folks for generation (i don't do that) and get back
>

Yes, I can confirm, SSP1 in under LPEA

    Scope (_SB)
    {
        Device (LPEA)
        {
            Name (_ADR, Zero)  // _ADR: Address
            Name (_HID, "80860F28" /* Intel SST Audio DSP */)  // _HID: Hardware ID

            ... snip ...

            Device (SSP1)
            {
                Name (_ADR, Zero)  // _ADR: Address
                Name (_HID, "SSPX0000" /* Intel SSP Device */)  // _HID: Hardware ID
                Name (_CID, "SSPX0000" /* Intel SSP Device */)  // _CID: Compatible ID

Full dsdt.dsl here:
https://github.com/michelecurti/x205ta/blob/master/dsdt.dsl


Thank you,
Michele

Re: Intel SST on a Bay Trail tablet

[Pierre-Louis Bossart]

On 8/24/15 1:17 PM, Michele Curti wrote:
> On Mon, Aug 24, 2015 at 07:56:25PM +0530, Vinod Koul wrote:
>> On Mon, Aug 24, 2015 at 03:29:04PM +0200, Michele Curti wrote:
>>>
>>> Damn, completely missed..
>>>
>>> Hi Vinod,
>>> if it's possible, could you please generate a fw_sst_0f28_ssp1.bin
>>> also, so I can test my driver (mine was for the Asus X205TA laptop,
>>> where the codec is on SSP1 port)?
>>
>> Are you sure you ahve SSP1 port enabled. I have not seen anyone using that
>> one. Jarkko do you know about this?
>>
>> I will ask firmware folks for generation (i don't do that) and get back
>>
>
> Yes, I can confirm, SSP1 in under LPEA
>
>      Scope (_SB)
>      {
>          Device (LPEA)
>          {
>              Name (_ADR, Zero)  // _ADR: Address
>              Name (_HID, "80860F28" /* Intel SST Audio DSP */)  // _HID: Hardware ID
>
>              ... snip ...
>
>              Device (SSP1)
>              {
>                  Name (_ADR, Zero)  // _ADR: Address
>                  Name (_HID, "SSPX0000" /* Intel SSP Device */)  // _HID: Hardware ID
>                  Name (_CID, "SSPX0000" /* Intel SSP Device */)  // _CID: Compatible ID
>
> Full dsdt.dsl here:
> https://github.com/michelecurti/x205ta/blob/master/dsdt.dsl

No idea why the BIOS vendor thought here, we don't handle the SSPX0000 
(illegal) _HID and we have no driver to load against... This SSP1 entry 
will be ignored in Linux.
Probably only used by Windows for Bluetooth HFP, see the DSM that 
returns ("BLUET")

    Device (SSP1)
             {
                 Name (_ADR, Zero)  // _ADR: Address
                 Name (_HID, "SSPX0000" /* Intel SSP Device */)  // 
_HID: Hardware ID
                 Name (_CID, "SSPX0000" /* Intel SSP Device */)  // 
_CID: Compatible ID
                 Name (_DDN, "Intel(R) SSP Device")  // _DDN: DOS Device 
Name
                 Name (_UID, One)  // _UID: Unique ID
                 Method (_STA, 0, NotSerialized)  // _STA: Status
                 {
                     If ((OSSL & 0x80)) <<< OSSL==0x08, test fails
                     {
                         Return (0x0F)
                     }

                     Return (Zero) <<<<< device is not reported present 
to kernel
                 }

Re: Intel SST on a Bay Trail tablet

[Michele Curti]

On Mon, Aug 24, 2015 at 02:28:21PM -0500, Pierre-Louis Bossart wrote:
> On 8/24/15 1:17 PM, Michele Curti wrote:
> >On Mon, Aug 24, 2015 at 07:56:25PM +0530, Vinod Koul wrote:
> >>On Mon, Aug 24, 2015 at 03:29:04PM +0200, Michele Curti wrote:
> >>>
> >>>Damn, completely missed..
> >>>
> >>>Hi Vinod,
> >>>if it's possible, could you please generate a fw_sst_0f28_ssp1.bin
> >>>also, so I can test my driver (mine was for the Asus X205TA laptop,
> >>>where the codec is on SSP1 port)?
> >>
> >>Are you sure you ahve SSP1 port enabled. I have not seen anyone using that
> >>one. Jarkko do you know about this?
> >>
> >>I will ask firmware folks for generation (i don't do that) and get back
> >>
> >
> >Yes, I can confirm, SSP1 in under LPEA
> >
> >     Scope (_SB)
> >     {
> >         Device (LPEA)
> >         {
> >             Name (_ADR, Zero)  // _ADR: Address
> >             Name (_HID, "80860F28" /* Intel SST Audio DSP */)  // _HID: Hardware ID
> >
> >             ... snip ...
> >
> >             Device (SSP1)
> >             {
> >                 Name (_ADR, Zero)  // _ADR: Address
> >                 Name (_HID, "SSPX0000" /* Intel SSP Device */)  // _HID: Hardware ID
> >                 Name (_CID, "SSPX0000" /* Intel SSP Device */)  // _CID: Compatible ID
> >
> >Full dsdt.dsl here:
> >https://github.com/michelecurti/x205ta/blob/master/dsdt.dsl
> 
> No idea why the BIOS vendor thought here, we don't handle the SSPX0000
> (illegal) _HID and we have no driver to load against... This SSP1 entry will
> be ignored in Linux.
> Probably only used by Windows for Bluetooth HFP, see the DSM that returns
> ("BLUET")


Oh, so no need of a SSP1 driver, thank you!

I'll try the SSP0 one :)

Thanks,
Michele

> 
>    Device (SSP1)
>             {
>                 Name (_ADR, Zero)  // _ADR: Address
>                 Name (_HID, "SSPX0000" /* Intel SSP Device */)  // _HID:
> Hardware ID
>                 Name (_CID, "SSPX0000" /* Intel SSP Device */)  // _CID:
> Compatible ID
>                 Name (_DDN, "Intel(R) SSP Device")  // _DDN: DOS Device Name
>                 Name (_UID, One)  // _UID: Unique ID
>                 Method (_STA, 0, NotSerialized)  // _STA: Status
>                 {
>                     If ((OSSL & 0x80)) <<< OSSL==0x08, test fails
>                     {
>                         Return (0x0F)
>                     }
> 
>                     Return (Zero) <<<<< device is not reported present to
> kernel
>                 }
> 
> 

Re: Intel SST on a Bay Trail tablet

[Luka Karinja]

Hello Michele,

>
> Oh, so no need of a SSP1 driver, thank you!
>
> I'll try the SSP0 one :)
>
Any luck to get the sound working on your device?

Re: Intel SST on a Bay Trail tablet

[Michele Curti]

On Thu, Sep 17, 2015 at 10:54:30PM +0200, Luka Karinja wrote:
> Hello Michele,
> 
> >
> >Oh, so no need of a SSP1 driver, thank you!
> >
> >I'll try the SSP0 one :)
> >
> Any luck to get the sound working on your device?

Hi Luka,
I did a try but without success..  I think it's beyond my 
capabilities eheh

Regards,
Michele