Stress tests show that DSP may occasionally be late with signaling WAIT state when all pins are made use of simultaneously plus start/stop (pause) gets involved. While this isn't tied to standard audio scenarios where only System Pin (playback and capture) is involved, ensure user is not hindered when playing with more advanced scenarios.
From DSP perspective, clock acts as a resource: low clock equals less
resources, high clock more resources. Relax clock selection procedure so only low -> high switch is allowed when awaiting WAIT signal times out. Once active stream count decreases, DSP will have more time internally to adjust thus low clock selection becomes possible again.
Signed-off-by: Cezary Rojewski cezary.rojewski@intel.com ---
TLDR: While issue is connected to DSP hw/firmware, software may address this by relaxing the conditions so audio remains stable when stress scenarios are ongoing for several iterations. It is rare for user to start system pb/offload0/offload1/system cp/loopback all at once and play with them but let's account for that too.
sound/soc/intel/catpt/dsp.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/sound/soc/intel/catpt/dsp.c b/sound/soc/intel/catpt/dsp.c index 7d2968571951..9e807b941732 100644 --- a/sound/soc/intel/catpt/dsp.c +++ b/sound/soc/intel/catpt/dsp.c @@ -267,9 +267,12 @@ static int catpt_dsp_select_lpclock(struct catpt_dev *cdev, bool lp, bool waiti) reg, (reg & CATPT_ISD_DCPWM), 500, 10000); if (ret) { - dev_err(cdev->dev, "await WAITI timeout\n"); - mutex_unlock(&cdev->clk_mutex); - return ret; + dev_warn(cdev->dev, "await WAITI timeout\n"); + /* no signal - only high clock selection allowed */ + if (lp) { + mutex_unlock(&cdev->clk_mutex); + return 0; + } } }