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

[Gustaw Lewandowski]

On 8/22/19 5:29 PM, Cezary Rojewski wrote:
> On 2019-08-20 04:11, Jie, Yang wrote:
>>
>>> -----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
>>
>
> Please do not name people on official list unless you are 100% sure 
> about their engagement in linux solutions, which for both individuals 
> you have listed, is no longer the case. Any recommendations? - you can 
> provide internally.
>
> Anyway, I've contacted Marcin and once he is available, we will review 
> the patch together. Note, that I'm a IGK dweller too, so it's highly 
> probable whomever you had in mind I've either already met or drank a 
> beer with.
>
> Czarek
>
>>>
>>> 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.

I don't have a specified codec for testing so I tried with rt286. I was 
not able to reproduce this issue. Could you collect logs(dmesg) with 
enabled debug like below for S3 or enabled debug during build for 
resting reboot scenario?
echo -n 'module  snd* +p' |  dd of=/sys/kernel/debug/dynamic_debug/control
Since enabling debug decreases problem occurrence ratio please also 
check below change:

--- a/sound/soc/intel/haswell/sst-haswell-ipc.c
+++ b/sound/soc/intel/haswell/sst-haswell-ipc.c
@@ -81,7 +81,7 @@

  /* IPC message timeout (msecs) */
  #define IPC_TIMEOUT_MSECS      300
-#define IPC_BOOT_MSECS         200
+#define IPC_BOOT_MSECS         300

Gustaw