On 11/10/22 10:06, Cezary Rojewski wrote:
On 2022-11-10 4:39 PM, Pierre-Louis Bossart wrote:
On 11/10/22 08:13, Cezary Rojewski wrote:
--- a/sound/soc/intel/avs/pcm.c +++ b/sound/soc/intel/avs/pcm.c @@ -934,8 +934,11 @@ static int avs_component_pm_op(struct snd_soc_component *component, bool be, rtd = snd_pcm_substream_chip(data->substream); if (rtd->dai_link->no_pcm == be && !rtd->dai_link->ignore_suspend) { ret = op(dai, data); - if (ret < 0) + if (ret < 0) { + data->substream->runtime->status->state = + SNDRV_PCM_STATE_DISCONNECTED;
should runtime->state be used instead of runtime->status->state?
A quick grep shows the former seems more popular in drivers, status->seems to be only used in pcm_native.c?
Another plumbing question is whether it's actually ok to change the state of the runtime in a driver, are you not going to have locking issues? Very few drivers change the internal state and I wonder how legit/safe this is.
Unless something new has been added/updated, there is no runtime->state field available. All the PCM code works with runtime->status->state.
cd sound/
git grep -c 'runtime->state' core/compress_offload.c:27 core/oss/pcm_oss.c:21 core/pcm.c:2 core/pcm_compat.c:2 core/pcm_lib.c:8 core/pcm_native.c:50 drivers/aloop.c:2 firewire/bebob/bebob_pcm.c:2 firewire/dice/dice-pcm.c:2 firewire/digi00x/digi00x-pcm.c:2 firewire/fireface/ff-pcm.c:2 firewire/fireworks/fireworks_pcm.c:2 firewire/motu/motu-pcm.c:2 firewire/oxfw/oxfw-pcm.c:4 firewire/tascam/tascam-pcm.c:2 hda/hdmi_chmap.c:1 isa/gus/gus_pcm.c:1 soc/intel/skylake/skl-pcm.c:2 soc/sh/rz-ssi.c:1 usb/pcm.c:2 usb/usx2y/usbusx2yaudio.c:1 usb/usx2y/usx2yhwdeppcm.c:1
git grep -c 'status->state' core/pcm_compat.c:2 core/pcm_native.c:4