[alsa-devel] [BUG] bdw-rt5650 DSP boot timeout

[Jie, Yang]

>-----Original Message-----
>From: Rojewski, Cezary
>Sent: Tuesday, August 20, 2019 2:09 AM
>To: Jie, Yang <yang.jie at intel.com>; Jon Flatley <jflat at chromium.org>; Pierre-
>Louis Bossart <pierre-louis.bossart at linux.intel.com>
>Cc: benzh at chromium.org; alsa-devel at alsa-project.org; Jie Yang
><yang.jie at linux.intel.com>; Ranjani Sridharan
><ranjani.sridharan at linux.intel.com>; cujomalainey at chromium.org
>Subject: Re: [alsa-devel] [BUG] bdw-rt5650 DSP boot timeout
>
>On 2019-08-19 04:33, Jie, Yang wrote:
>>
>>> -----Original Message-----
>>> From: Jon Flatley [mailto:jflat at chromium.org]
>>> Sent: Thursday, August 15, 2019 5:25 AM
>>> To: Pierre-Louis Bossart <pierre-louis.bossart at linux.intel.com>
>>> Cc: Jon Flatley <jflat at chromium.org>; Jie, Yang <yang.jie at intel.com>;
>>> benzh at chromium.org; alsa-devel at alsa-project.org; Ranjani Sridharan
>>> <ranjani.sridharan at linux.intel.com>; cujomalainey at chromium.org; Jie
>>> Yang <yang.jie at linux.intel.com>
>>> Subject: Re: [alsa-devel] [BUG] bdw-rt5650 DSP boot timeout
>>>
>>> On Wed, Aug 14, 2019 at 1:51 PM Pierre-Louis Bossart <pierre-
>>> louis.bossart at linux.intel.com> wrote:
>>>>
>>>>
>>>>> There seems to be an issue when suspending the ALC5650. I think the
>>>>> nondeterministic behavior I was seeing just had to do with whether
>>>>> or not the DSP had yet suspended.
>>>>>
>>>>> I reverted commit 0d2135ecadb0 ("ASoC: Intel: Work around to fix HW
>>>>> D3 potential crash issue") and things started working, including
>>>>> suspend/resume of the DSP. Any ideas for why this may be? I would
>>>>> like to resolve this so I can finish upstreaming the bdw-rt5650
>>>>> machine driver.
>>>>
>>>> Copying Keyon in case he remembers the context.
>>>>
>>>> Reverting a 5yr-old commit with all sorts of clock/power-related
>>>> fixes looks brave, and it's not clear why this would work with the
>>>> rt5677 and not with 5650.
>>>
>>> No idea, I was just diffing the register writes looking for sources of
>discrepancy.
>>> The Chromium OS 3.14 kernel tree that Buddy uses doesn't have this
>>> patch, so I figured what's the worst that could happen?
>>
>> Hi Jon, sorry about just noticing this thread.
>>  From the dmesg log, the issue happens at runtime suspend/resume but not
>in boot, am I right(you can disable runtime PM for the device to confirm that)?
>>
>> My points here are:
>> 1. the commit 0d2135ecadb0 was suggested by FW team to W/A D3
>potential crash issue.
>> 2. it was verified with rt286(Broadwell.c, e.g. Dell XPS) from our side
>only(and may have been checked with rt5677 by Chrome team).
>> 3. please follow sequence in broadwell.c if issue happen at boot time.
>> If happened at runtime PM from DSP side, we should see it with all kinds of
>machine driver.
>> Could you performing more test and debugging to see what it real happen
>there?
>> 4. we have no reason to remove the commit directly, except correcting if
>some lines are proved wrong. And, as Pierre mentioned, SOF driver is
>preferred, as there is no new development effort to support SST
>haswell/Broadwell driver here(no platform, no developer, :-( ).
>>
>> Thanks,
>> ~Keyon>
>
>Got to disagree with the last one - no platform, no developer.
>We are setting up some BDW/ HSW here to join our happy SKL+ family in CI.
>This is because of /common cleanups which will engulf aDSP project
>(hsw/byt) obviously.

Yes, that's true, good to hear that you will add it to CI.

>
>These will be tested against the exact same BAT scope as other ADSP devices.
>Code here looks much better, at least compared to /skylake - ain't a high
>threshold though.. Given how outdated all SKL+ fw binaries are (on upstream
>repo) it might even come down simply to fw upgrade.
>Most of FW peps who took part in that project are already out. Although,
>found one or two who are willing to help : )

I remember Pawel Piskorski and Marcin Barlik helped me from the FW side(including explaining about the S0<->S3 sequence), please contact me offline if needed, I will try to drag for some mails which I got 5 years back.

Thanks,
~Keyon

>
>And yes, I'm setting them up with rt286 too. There are some rt56XX but I'm
>unsure if rt5650 is amount them.
>Still got some problems with ACPI, but soon two new faces should be greeting
>audio CI bonfire..
>
>Czarek
>
>>>>
>>>> Are you using the latest upstream firmware btw? Or the one which
>>>> shipped with the initial device (which could be an issue if the
>>>> protocol
>>> changed).
>>>
>>> The firmware I'm loading is: `FW info: type 01, - version: 00.00,
>>> build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a1`.
>>> Hashes the same as the upstream binary.
>> _______________________________________________
>> Alsa-devel mailing list
>> Alsa-devel at alsa-project.org
>> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>