[alsa-devel] Intel SST on a Bay Trail tablet

[Antonio Ospite]

On Tue, 14 Apr 2015 17:06:27 +0300
Jarkko Nikula <jarkko.nikula at 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 at 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?