Thanks for the additional information.
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
So that's a fail.
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.
Oh man, Bay Lake...this must be at least 6 years old and 30+ kernel versions behind... Only a couple of years and it'll be a collector item :-)
I can't recall any of the details so we'll have to wing it. it could be that it was baytrail-T but with the software/BIOS for Baytrail-Cr, who knows.
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?
Yes indeed, and that makes me think we should force this device to look like Baytrail-CR.
You can do this with a DMI-based quirk (preferably in is_byt_cr directly so that I can reuse the code when I move it to a helper at some point).
Also I guess you'd need a second quirk in bytcr_rt5640 since the default is SSP0-AIF2.
-Pierre