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

[Pierre-Louis Bossart]

On 12/17/18 12:17 PM, Stephan Gerhold wrote:
> On Mon, Dec 17, 2018 at 08:52:46AM -0600, Pierre-Louis Bossart wrote:
>> On 12/16/18 12:54 PM, Stephan Gerhold wrote:
>>> Hi,
>>>
>>> I have an Intel Bay Trail (BYT-T) tablet that was originally shipped
>>> with Android. With the right quirks, bytcr-rt5640 is working fine, but
>>> there is a problem in sst_acpi.c that is preventing it from working
>>> with a mainline kernel:
>>>
>>> Even though this is a BYT-T device, there is no IRQ at index 5 in the
>>> ACPI DSDT table. This means that SST will fail to probe, and actually
>>> leads to a NULL pointer dereference later when the ALSA device is first
>>> opened. (I have submitted a possible solution for this as
>>> "[PATCH] ASoC: Intel: sst: Delay machine device creation until after
>>> initialization")
>>>
>>> The correct IRQ is actually located on index 0, just like it is already
>>> being used for BYT-CR devices. So if I force is_byt_cr() to return TRUE,
>>> everything works as expected.
>> So the root cause of your problem is that the detection of byt-cr doesn't
>> work? That would be a first.
> No. is_byt_cr() works correctly, as my device is a BYT-T (not a BYT-CR)
> device. :)

What information is your analysis based on and how do you infer this 
conclusion? The BYT-T and BYT-CR silicon dies are identical, product 
documentation can barely be trusted and it's a package difference that 
can only be tested indirectly.

I don't mean to dismiss your claim, just want to find out if this is a 
case where the PMIC-type-based byt_cr detection fails or if we have a 
BIOS issue. Another smoking gun is if you find in your code traces of 
SSP0 being used.

>
> The problem here is that the kernel expects the IRQ at index 5 for BYT-T
> devices, but my device has only a single IRQ listed. Forcing is_byt_cr()
> to return TRUE is just a workaround to make it use the IRQ at index 0
> (which is the correct one).
>
> Currently, sst_acpi supports these two variations:
>    - BYT-T:  5 IRQs listed -> acpi_ipc_irq_index = 5
>    - BYT-CR: 5 IRQs listed -> acpi_ipc_irq_index = 0
>
> On my device (and a few other Android based BYT-T devices) I have found:
>    - BYT-T:  1 IRQ  listed -> acpi_ipc_irq_index = 0
> but at the moment the kernel attempts to use acpi_ipc_irq_index = 5 from
> BYT-T above.
>
>> Can you please double-check that CONFIG_IOSF_MBI is enabled and provide a
>> trace of the bios status in this piece of code:
>>
>>      /* bits 26:27 mirror PMIC options */
>>              bios_status = (bios_status >> 26) & 3;
>>
>>              if ((bios_status == 1) || (bios_status == 3))
>>                  *bytcr = true;
>>              else
>>                  dev_info(dev, "BYT-CR not detected\n");
>>
>>> Here is the relevant part from the ACPI DSDT table:
>>>
>>>     Name (_ADR, Zero)  // _ADR: Address
>>>     Name (_HID, "80860F28" /* Intel SST Audio DSP */)  // _HID: Hardware ID
>>>     Name (_CID, "80860F28" /* Intel SST Audio DSP */)  // _CID: Compatible ID
>>>     Name (_DDN, "Intel(R) Low Power Audio Controller - 80860F28")  // _DDN: DOS Device Name
>>>     Name (_SUB, "80867270")  // _SUB: Subsystem ID
>>>     Name (_UID, One)  // _UID: Unique ID
>>>
>>>     Name (RBUF, ResourceTemplate ()
>>>     {
>>>         Memory32Fixed (ReadWrite,
>>>             0x12345678,         // Address Base
>>>             0x00200000,         // Address Length
>>>             _Y08)
>>>         Memory32Fixed (ReadWrite,
>>>             0xFE830000,         // Address Base
>>>             0x00001000,         // Address Length
>>>             _Y09)
>>>         Memory32Fixed (ReadWrite,
>>>             0x55AA55AA,         // Address Base
>>>             0x00200000,         // Address Length
>>>             _Y0A)
>>>         Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, )
>>>         {
>>>             0x0000001D,
>>>         }
>>>     })
>>>
>>> Unlike many of the other DSDT dumps I've looked at, there is only one
>>> interrupt listed. Full ACPI DSDT table is at [1].
>>>
>>> Since there is no IRQ at index 5, platform_get_irq will return -ENXIO.
>>> Couldn't we fall back to index 0 in this case? I would say that if the
>>> seemingly "correct" IRQ at index 5 does not even exist, we still have
>>> a better chance of picking the right one if we try the one at index 0.
>>> Or we could check the number of interrupts that are actually available.
>>>
>>> The other option would be some kind of DMI-based quirk, but personally
>>> I would prefer to avoid that.. (In my opinion, there is way too much
>>> device specific code with the quirks etc already...)
>>>
>>> Or do you have any other suggestions?
>>>
>>> Thanks,
>>> Stephan
>>>
>>> [1]: https://github.com/me176c-dev/me176c-acpi/blob/f48c78c11b0819b899f988407b6ece3d8c2cca71/dsdt.dsl#L3989-L4035
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel at alsa-project.org
>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel