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@intel.com; Jon Flatley jflat@chromium.org; Pierre- Louis Bossart pierre-louis.bossart@linux.intel.com Cc: benzh@chromium.org; alsa-devel@alsa-project.org; Jie Yang yang.jie@linux.intel.com; Ranjani Sridharan ranjani.sridharan@linux.intel.com; cujomalainey@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@chromium.org] Sent: Thursday, August 15, 2019 5:25 AM To: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Cc: Jon Flatley jflat@chromium.org; Jie, Yang yang.jie@intel.com; benzh@chromium.org; alsa-devel@alsa-project.org; Ranjani Sridharan ranjani.sridharan@linux.intel.com; cujomalainey@chromium.org; Jie Yang yang.jie@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@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:
- the commit 0d2135ecadb0 was suggested by FW team to W/A D3
potential crash issue.
- 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).
- 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?
- 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