[alsa-devel] ASoC: Intel: sst: Missing IRQ at index 5 on BYT-T device
Stephan Gerhold
stephan at gerhold.net
Mon Dec 17 20:10:55 CET 2018
On Mon, Dec 17, 2018 at 12:29:43PM -0600, Pierre-Louis Bossart wrote:
>
> 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.
Okay, sorry - I'm not _that_ sure. :)
It's mostly based on something called "spid" that was being used in the
stock Android kernel on the device and some code from the stock kernel
I've looked at.
I don't mind checking this again to be absolutely sure :)
The call to iosf_mbi_read() returns 0x400b0100
/* bits 26:27 mirror PMIC options */
bios_status = (bios_status >> 26) & 3;
Results in bios_status = 0x0
The stock kernel printed this on every startup:
SPID updated according to ACPI Table:
spid customer id : 0000
spid vendor id : 0000
spid manufacturer id : 00ff
spid platform family id : 0007 --> INTEL_BYT_TABLET
spid product line id : 0000 --> INTEL_BYT_TABLET_BLK_PRO
spid hardware id : 0004 --> BYT_TABLET_BLK_8PR0 /* Bay Lake FFRD-8 PR0 */
spid fru[4..0] : 00 00 00 00 00
spid fru[9..5] : 00 00 00 00 00
Based on spid.h [1] I added the "-->" above. Then I guessed that this is
BYT-T (there is another "BYT T CR V2" value), but to be honest I don't
know for sure.
[1]: https://github.com/me176c-dev/me176c-kernel/blob/stock/kernel/arch/x86/include/asm/spid.h
>
> 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 quirks to get sound working with bytcr-rt5640 on that device are:
BYT_RT5640_SSP0_AIF1 | BYT_RT5640_IN1_MAP | BYT_RT5640_MCLK_EN
I guess this means that SSP0 is 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
More information about the Alsa-devel
mailing list