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
