Re: snd_hda_intel/sst-acpi sound breakage on suspend/resume since 5.6-rc1

From: Cezary Rojewski <cezary.rojewski@intel.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Dominik Brodowski <linux@dominikbrodowski.net>
Cc: alsa-devel@alsa-project.org, curtis@malainey.com,
	Keyon Jie <yang.jie@linux.intel.com>,
	tiwai@suse.com, linux-kernel@vger.kernel.org,
	liam.r.girdwood@linux.intel.com, broonie@kernel.org
Subject: Re: snd_hda_intel/sst-acpi sound breakage on suspend/resume since 5.6-rc1
Date: Wed, 18 Mar 2020 18:35:13 +0100	[thread overview]
Message-ID: <4cd918e3-bf1a-8345-2fd6-cdcb08fd82cc@intel.com> (raw)
In-Reply-To: <ea09e20f-d7d3-fde2-2c52-07c554d78e5e@linux.intel.com>

On 2020-03-18 18:29, Pierre-Louis Bossart wrote:
> 
> 
> On 3/18/20 12:19 PM, Dominik Brodowski wrote:
>> On Wed, Mar 18, 2020 at 12:08:24PM -0500, Pierre-Louis Bossart wrote:
>>> On 3/18/20 11:20 AM, Dominik Brodowski wrote:
>>>> On Wed, Mar 18, 2020 at 10:13:54AM -0500, Pierre-Louis Bossart wrote:
>>>>>
>>>>>
>>>>>>>> While 5.5.x works fine, mainline as of ac309e7744be (v5.6-rc6+) 
>>>>>>>> causes me
>>>>>>>> some sound-related trouble: after boot, the sound works fine -- 
>>>>>>>> but once I
>>>>>>>> suspend and resume my broadwell-based XPS13, I need to switch to 
>>>>>>>> headphone
>>>>>>>> and back to speaker to hear something. But what I hear isn't 
>>>>>>>> music but
>>>>>>>> garbled output.
>>>>>
>>>>> It's my understanding that the use of the haswell driver is opt-in 
>>>>> for Dell
>>>>> XPS13 9343. When we run the SOF driver on this device, we have to 
>>>>> explicitly
>>>>> bypass an ACPI quirk that forces HDAudio to be used:
>>>>>
>>>>> https://github.com/thesofproject/linux/commit/944b6a2d620a556424ed4195c8428485fcb6c2bd 
>>>>>
>>>>>
>>>>> Have you tried to run in plain vanilla HDAudio mode?
>>>>
>>>> I had (see 18d78b64fddc), but not any more in years (and I'd like to 
>>>> keep
>>>> using I2S, which has worked flawlessly in these years).
>>>
>>> ok. I don't think Intel folks have this device available, or it's 
>>> used for
>>> other things, but if you want to bisect on you may want to use [1] to 
>>> solve
>>> DRM issues. I used it to make Broadwell/Samus work again with SOF.
>>>
>>> [1] 
>>> https://gitlab.freedesktop.org/drm/intel/uploads/ef10c6c27fdc53d114f827bb72b078aa/0001-drm-i915-psr-Force-PSR-probe-only-after-full-initial.patch.txt 
>>>
>>>
>>> An alternate path would be to switch to SOF. It's still viewed as a
>>> developer option but Broadwell/Samus work reliably for me and we have a
>>> Broadwell-rt286 platform used for CI.
>>
>> What do you mean with SOF? And no other ideas on the root cause than a
>> tedious bisect?
> 
> Sound Open Firmware (SOF) [1]. You can build your own audio firmware for 
> Broadwell and the driver is supported in the mainline (you'd need to 
> disable the legacy driver [2]).
> 
> I can't think of any changes to that haswell/broadwell legacy driver, 
> apart from Takashi's buffer management changes 3f93b1ed4ac1e2.
> 
> But there were multiple changes to the ASoC core, so it's possible that 
> they impact suspend/resume. Just a blind guess.
> 
> [1] https://thesofproject.github.io/latest/index.html
> [2] 
> https://github.com/thesofproject/kconfig/blob/023cc25cd0b26a9757592d0bbbbe719825dd728d/sof-dev-defconfig#L20 
> 
> 

Please refrain from advertising SOF as a solution for this problem.

There were plenty changes done to dmaengine and ASoC during that time. 
Right now we are digging through the code.

While we might not have Dell XPS 13 available currently on our site, 
issue reproduces on our RVPs.

Regards,
Czarek