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@xxxxxxxxxxxxxxxx > > > > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
