>-----Original Message----- >From: Rojewski, Cezary >Sent: Tuesday, August 20, 2019 2:09 AM >To: Jie, Yang <yang.jie@xxxxxxxxx>; Jon Flatley <jflat@xxxxxxxxxxxx>; Pierre- >Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> >Cc: benzh@xxxxxxxxxxxx; alsa-devel@xxxxxxxxxxxxxxxx; Jie Yang ><yang.jie@xxxxxxxxxxxxxxx>; Ranjani Sridharan ><ranjani.sridharan@xxxxxxxxxxxxxxx>; cujomalainey@xxxxxxxxxxxx >Subject: Re: [BUG] bdw-rt5650 DSP boot timeout > >On 2019-08-19 04:33, Jie, Yang wrote: >> >>> -----Original Message----- >>> From: Jon Flatley [mailto:jflat@xxxxxxxxxxxx] >>> Sent: Thursday, August 15, 2019 5:25 AM >>> To: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx> >>> Cc: Jon Flatley <jflat@xxxxxxxxxxxx>; Jie, Yang <yang.jie@xxxxxxxxx>; >>> benzh@xxxxxxxxxxxx; alsa-devel@xxxxxxxxxxxxxxxx; Ranjani Sridharan >>> <ranjani.sridharan@xxxxxxxxxxxxxxx>; cujomalainey@xxxxxxxxxxxx; Jie >>> Yang <yang.jie@xxxxxxxxxxxxxxx> >>> Subject: Re: [BUG] bdw-rt5650 DSP boot timeout >>> >>> On Wed, Aug 14, 2019 at 1:51 PM Pierre-Louis Bossart <pierre- >>> louis.bossart@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx >> https://mailman.alsa-project.org/mailman/listinfo/alsa-devel >> _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
