Vinod,

I have attached the dmesg that occurs after I play the sound test. 
(dynamic debug and FE-BE was set via SSH terminal)

Antonio,

While it is true that I had not played any sound when I had collected 
the interrupts from previous mail, after doing the test for Vinod above 
I again collected the interrupt count, unfortunately as you can see it 
is the same...

root@mykro:~# cat /proc/interrupts | grep intel
    7:          0          0          0          0   IO-APIC 
28-fasteoi   intel_sst_driver

Additionally, you were correct about the sorting of interrupts, as my 
dissembled DSDT table shows:
(from Device(LPEA) section)
       Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, )
                 {
                     0x0000001D,
                 }
                 Interrupt (ResourceConsumer, Level, ActiveLow, 
Exclusive, ,, )
                 {
                     0x00000018,
                 }
                 Interrupt (ResourceConsumer, Level, ActiveLow, 
Exclusive, ,, )
                 {
                     0x00000019,
                 }
                 Interrupt (ResourceConsumer, Level, ActiveLow, 
Exclusive, ,, )
                 {
                     0x0000001A,
                 }
                 Interrupt (ResourceConsumer, Level, ActiveLow, 
Exclusive, ,, )
                 {
                     0x0000001B,
                 }
                 Interrupt (ResourceConsumer, Level, ActiveLow, 
Exclusive, ,, )
                 {
                     0x0000001C,
                 }

For now I can research into overriding the DSDT so the interrupts are in 
order.

Thanks-

Tyler

On 07/08/2015 04:23 AM, Antonio Ospite wrote:
> On Wed, 8 Jul 2015 09:06:04 +0530
> Vinod Koul <vinod.koul@intel.com> wrote:
>
>> On Tue, Jul 07, 2015 at 05:06:18PM -0400, Tyler Yeomans wrote:
> [...]
>>> Additionally, the interrupts report as follows... none:
>>> $ cat /proc/interrupts | grep sst
>>>     7:          0          0          0          0   IO-APIC
>>> 28-fasteoi   intel_sst_driver
>> So this makes me suspect interrupts, we should have seen something here
>>
> Tyler, maybe it's trivial but I will spell it out anyway: before any
> interrupt gets fired, something needs to be played (e.g. speaker-test).
>
>> Liam, do you know how whats different in BYT devices from interrupts. I
>> recall Jarkko saying some issues with the way interrupts are exposed..?
>>
> The details are here:
> https://bugzilla.kernel.org/show_bug.cgi?id=86581
>
> A summary is below:
>
> Some devices declare interrupts in their DSDT in an order different from
> what the mainline linux driver expects, in particular the DSP-host
> interrupt is sometimes declared first while the driver expects it at
> index 5.
>
> To check that, dump the DSDT table (look up the details), and look for
> "Device (LPEA)", then check the order of the "Interrupt" definitions.
>
> Some devices define 0x0000001D as the first one, and this does not work
> with the the mainline driver which expects the interrupts sorted
> numerically (i.e. 0x0000001D is the sixth one starting from 0x00000018
> and after 0x0000001C).
>
> The problem can be fixed in two ways:
>    - Override your DSDT with one which reorders the interrupts
>      (that's what I did).
>    - Apply https://bugzilla.kernel.org/attachment.cgi?id=155341 to the
>      driver to use the "right" index as per the original device DSDT.
>      NOTE: the file paths changed in recent kernels so you may need to
>      apply the change manually.
>
> A final note, you also need to set the right codec controls to get
> audio; setting the FE-BE path is necessary to make playback "work" but
> it may not be enough to actually get sound, so make sure you run the
> full script Vinod provided in
> http://mailman.alsa-project.org/pipermail/alsa-devel/2015-June/094080.html
>
> Ciao,
>     Antonio
>