On Thu, Mar 19, 2020 at 04:48:03PM +0100, Cezary Rojewski wrote:
On 2020-03-19 14:41, Mark Brown wrote:
On Thu, Mar 19, 2020 at 02:00:49PM +0100, Dominik Brodowski wrote:
Have some good news now, namely that a bisect is complete: That pointed to
1272063a7ee4 ("ASoC: soc-core: care .ignore_suspend for Component suspend");
therefore I've added Kuninori Morimoto to this e-mail thread.
If that's an issue it feels more like a driver bug in that if the driver
asked for ignore_suspend then it should expect not to have the suspend
callback called.
Requested for tests with following diff applied:
diff --git a/sound/soc/intel/boards/broadwell.c
b/sound/soc/intel/boards/broadwell.c
index db7e1e87156d..6ed4c1b0a515 100644
--- a/sound/soc/intel/boards/broadwell.c
+++ b/sound/soc/intel/boards/broadwell.c
@@ -212,7 +212,6 @@ static struct snd_soc_dai_link broadwell_rt286_dais[] =
{
.init = broadwell_rt286_codec_init,
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
SND_SOC_DAIFMT_CBS_CFS,
- .ignore_suspend = 1,
.ignore_pmdown_time = 1,
.be_hw_params_fixup = broadwell_ssp0_fixup,
.ops = &broadwell_rt286_ops,
That patch fixes the issue(s). I didn't even need to revert 64df6afa0dab
("ASoC: Intel: broadwell: change cpu_dai and platform components for SOF")
on top of that. But you can assess better whether that patch needs care for
other reasons; for me, this one-liner you have suggested is perfect.