Re: ASoC: Intel: sst: Missing IRQ at index 5 on BYT-T device - Pierre-Louis Bossart

From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Stephan Gerhold <stephan@gerhold.net>
Cc: Liam Girdwood <liam.r.girdwood@linux.intel.com>,
	Hans de Goede <hdegoede@redhat.com>,
	alsa-devel@alsa-project.org, Mark Brown <broonie@kernel.org>,
	Jie Yang <yang.jie@linux.intel.com>
Subject: Re: ASoC: Intel: sst: Missing IRQ at index 5 on BYT-T device
Date: Mon, 17 Dec 2018 13:39:13 -0600	[thread overview]
Message-ID: <d5755c1c-f9d6-5bed-73ee-00a24d36fccc@linux.intel.com> (raw)
In-Reply-To: <20181217191054.GA10938@gerhold.net>

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.
>
> [1]: https://github.com/me176c-dev/me176c-kernel/blob/stock/kernel/arch/x86/include/asm/spid.h

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

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel