[alsa-devel] ASoC: Intel: sst: Missing IRQ at index 5 on BYT-T device
Hans de Goede
hdegoede at redhat.com
Sun Dec 16 20:07:30 CET 2018
Hi,
On 16-12-18 19:54, 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.
>
> 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.
If I'm not mistaken then you already mentioned in another thread
(the "tusb1210 probe of dwc3.0.auto.ulpi fails with EBUSY on 4.19+")
thread that the DSTD of this Andriod only device has several bugs in
there such as wrong GPIOs in some places, etc. and you need to do a
DSDT override anyways to get some things to work, right ?
In that case I believe it would be best to just also patch up this
part of the DSDT in your override and leave the current kernel code
as is.
Regards,
Hans
More information about the Alsa-devel
mailing list