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

[Cezary Rojewski]

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.
>>> _______________________________________________
>>> Alsa-devel mailing list
>>> Alsa-devel at alsa-project.org
>>> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>