[alsa-devel] ASoC: Intel: sst: Missing IRQ at index 5 on BYT-T device

[Hans de Goede]

Hi,

On 19-12-18 21:59, Antonio Ospite wrote:
> On Wed, 19 Dec 2018 15:23:13 +0100
> Hans de Goede <hdegoede at redhat.com> wrote:
> 
>> Hi,
>>
>> On 19-12-18 15:04, Pierre-Louis Bossart wrote:
>>> On 12/19/18 7:07 AM, Stephan Gerhold wrote:
> [...]
>>>> I have tested the patch above on my device with:
>>>>    - as-is, without any modifications:
>>>>       -> "Falling back to Baytrail-CR platform", sound now working
>>>>    - a simulated "BYT-T" device: (copied the IRQs from the DSDT of the T100TA)
>>>>       -> "BYT-CR not detected" - uses 5th IRQ, sound working
>>>>    - a simulated "BYT-CR" device (made is_byt_cr() return "true" and
>>>>      copied the IRQs from the DSDT of the T100TAF)
>>>>       -> "Detected Baytrail-CR platform" - uses IRQ at index 0, sound working
>>>>
>>>> Let me know what you think!
>>>
>>> Sounds good, playing with resources is what I had in mind rather than an interrupt count which isn't necessarily safe. The only improvement I would suggest is to add this test inside of is_byt_cr(). This routine will be moved as a helper outside of sst_acpi to be reused for SOF, so if we can make this test more self-contained it's more future-proof.
>>
>> AFAICT this will not fix all cases of this, so it might be better to see if
>> we can make is_byt_cr() return true on these devices in some other way.
>>
>> E.g. the "Teclast X98 Air 3G" Antonio reported does list 5 IRQs, but we
>> should still use the first IRQ and not the 5t.
>>
>> Antonio, do you know if your device uses SSP0 ?
>>
> 
> TBH I don't remember off the top of my head, I'll check my notes and
> get back on that when I also report back about recent kernels on my
> device.

As Stephan pointed out the kernel has this quirk for your device:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/sound/soc/intel/boards/bytcr_rt5640.c?id=ec1c90e777e5a555632747527fae142aa238e583

Which says it is using SSP0, which indicates it is a Bay Trail CR
(Cost Reduced) device. So it should indeed by using the IRQ at index
0, not at index 5. Chances are when you first tested things the
kernel did not have special handling for the CR variant yet and
things will just work.

In which case we can go with Stephan's solution of checking for
there not being a 5th IRQ to recognize the BYTCR like devices
which are not properly recognized as BYTCR.

Regards,

Hans