Hi Morimoto-san,
Sorry for the delayed reply as I was on sick leave.
Sure. BTW, there are more such candidates which require 'lock' version
of these helpers.
For example: soc_find_component(), snd_soc_add/remove_pcm_runtime()
and snd_soc_register_dai().
soc_find_component() is static function,
Hi Sameer
> Sure. BTW, there are more such candidates which require 'lock' version
> of these helpers.
> For example: soc_find_component(), snd_soc_add/remove_pcm_runtime()
> and snd_soc_register_dai().
soc_find_component() is static function, no need to care about mutex.
other functions are in
Hi Morimoto-san,
Other solution is create both snd_soc_find_dai_with_mutex()/without_mutex().
I'm not sure which style is best.
I don't know how complex it is to have a unified solution. But if we
can protect snd_soc_find_dai() itself, things would be simpler may be
in long term. Right now ther
Hi Sameer
> > Other solution is create both snd_soc_find_dai_with_mutex()/without_mutex().
> > I'm not sure which style is best.
>
> I don't know how complex it is to have a unified solution. But if we
> can protect snd_soc_find_dai() itself, things would be simpler may be
> in long term. Right
Hi Morimoto-san,
Yes, I'm posting fixup patch.
https://patchwork.kernel.org/patch/11719919/
Just curious that why snd_soc_find_dai() itself cannot be protected,
instead of leaving this to callers.
Because, snd_soc_find_dai() is called both with/without client_mutex.
(same/sof are ca
Hi Sameer
> > Yes, I'm posting fixup patch.
> >
> > https://patchwork.kernel.org/patch/11719919/
>
> Just curious that why snd_soc_find_dai() itself cannot be protected,
> instead of leaving this to callers.
Because, snd_soc_find_dai() is called both with/without client_mutex.
(same/
Hi Morimoto-san,
(snip)
I tried testing this with LOCKDEP config enabled at my end.
It seems I don't see warning originated from above function.
Are you suggesting that, in general, snd_soc_find_dai()
should be called with client_mutex held?
Hmm ? strange...
Yes indeed. For saftely I will f
Hi Sameer
> +static bool soc_component_is_pcm(struct
> snd_soc_dai_link_component *dlc)
> +{
> + struct snd_soc_dai *dai = snd_soc_find_dai(dlc);
> +
> + if (dai && (dai->component->driver->pcm_construct ||
> +
Hi Kuninori,
On 8/18/2020 8:11 AM, Kuninori Morimoto wrote:
External email: Use caution opening links or attachments
Hi Sameer
PCM devices are created for FE dai links with 'no-pcm' flag as '0'.
Such DAI links have CPU component which implement either pcm_construct()
or pcm_new() at componen
Hi Kuninori,
On 8/18/2020 10:53 AM, Kuninori Morimoto wrote:
External email: Use caution opening links or attachments
Hi again
PCM devices are created for FE dai links with 'no-pcm' flag as '0'.
Such DAI links have CPU component which implement either pcm_construct()
or pcm_new() at componen
Hi again
> PCM devices are created for FE dai links with 'no-pcm' flag as '0'.
> Such DAI links have CPU component which implement either pcm_construct()
> or pcm_new() at component or dai level respectively. Based on this,
> current patch exposes a helper function to identify such components
>
Hi Sameer
> PCM devices are created for FE dai links with 'no-pcm' flag as '0'.
> Such DAI links have CPU component which implement either pcm_construct()
> or pcm_new() at component or dai level respectively. Based on this,
> current patch exposes a helper function to identify such components
>
PCM devices are created for FE dai links with 'no-pcm' flag as '0'.
Such DAI links have CPU component which implement either pcm_construct()
or pcm_new() at component or dai level respectively. Based on this,
current patch exposes a helper function to identify such components
and populate 'no_pcm'
13 matches
Mail list logo
