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