1. 21 1月, 2021 2 次提交
  2. 30 11月, 2020 1 次提交
  3. 27 11月, 2020 2 次提交
  4. 11 11月, 2020 1 次提交
  5. 26 10月, 2020 1 次提交
  6. 30 9月, 2020 1 次提交
  7. 28 8月, 2020 2 次提交
    • D
      ASoC: core: remove artificial component and DAI name constraint · 45dd9943
      Dmitry Baryshkov 提交于
      Current fmt_single_name code limits maximum name of a DAI or component
      to 32 bytes. On some systems corresponding device names might be longer
      than that (e.g.
      17300000.remoteproc:glink-edge:apr:apr-service@8:routing). This will
      result in duplicate DAI/component names. Rewrite fmt_single_name() to
      remove such length limitations.
      Signed-off-by: NDmitry Baryshkov <dmitry.baryshkov@linaro.org>
      Link: https://lore.kernel.org/r/20200827205100.1479331-1-dmitry.baryshkov@linaro.orgSigned-off-by: NMark Brown <broonie@kernel.org>
      45dd9943
    • K
      ASoC: soc-core: add snd_soc_find_dai_with_mutex() · 20d9fdee
      Kuninori Morimoto 提交于
      commit 25612477 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
      added snd_soc_dai_link_set_capabilities().
      But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
      And client_mutex is soc-core.c local.
      
      	struct snd_soc_dai *snd_soc_find_dai(xxx)
      	{
      		...
      (B)		lockdep_assert_held(&client_mutex);
      		...
      	}
      
      	void snd_soc_dai_link_set_capabilities(xxx)
      	{
      		...
      		for_each_pcm_streams(direction) {
      			...
      			for_each_link_cpus(dai_link, i, cpu) {
      (A)				dai = snd_soc_find_dai(cpu);
      				...
      			}
      			...
      			for_each_link_codecs(dai_link, i, codec) {
      (A)				dai = snd_soc_find_dai(codec);
      				...
      			}
      		}
      		...
      	}
      
      Because of these background, we will get WARNING if .config has CONFIG_LOCKDEP.
      
      	WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
      	CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ #328
      	Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
      	Workqueue: events deferred_probe_work_func
      	pstate: 60000005 (nZCv daif -PAN -UAO)
      	pc : snd_soc_find_dai+0xf8/0x100
      	lr : snd_soc_find_dai+0xf4/0x100
      	...
      	Call trace:
      	 snd_soc_find_dai+0xf8/0x100
      	 snd_soc_dai_link_set_capabilities+0xa0/0x16c
      	 graph_dai_link_of_dpcm+0x390/0x3c0
      	 graph_for_each_link+0x134/0x200
      	 graph_probe+0x144/0x230
      	 platform_drv_probe+0x5c/0xb0
      	 really_probe+0xe4/0x430
      	 driver_probe_device+0x60/0xf4
      
      snd_soc_find_dai() will be used from (X) CPU/Codec/Platform driver with
      mutex lock, and (Y) Card driver without mutex lock.
      This snd_soc_dai_link_set_capabilities() is for Card driver,
      this means called without mutex.
      This patch adds snd_soc_find_dai_with_mutex() to solve it.
      
      Fixes: 25612477 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
      Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Link: https://lore.kernel.org/r/87blixvuab.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>
      20d9fdee
  8. 27 8月, 2020 1 次提交
    • K
      ASoC: soc-core: add snd_soc_find_dai_with_mutex() · c1c277b2
      Kuninori Morimoto 提交于
      commit 25612477 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
      added snd_soc_dai_link_set_capabilities().
      But it is using snd_soc_find_dai() (A) which is required client_mutex (B).
      And client_mutex is soc-core.c local.
      
      	struct snd_soc_dai *snd_soc_find_dai(xxx)
      	{
      		...
      (B)		lockdep_assert_held(&client_mutex);
      		...
      	}
      
      	void snd_soc_dai_link_set_capabilities(xxx)
      	{
      		...
      		for_each_pcm_streams(direction) {
      			...
      			for_each_link_cpus(dai_link, i, cpu) {
      (A)				dai = snd_soc_find_dai(cpu);
      				...
      			}
      			...
      			for_each_link_codecs(dai_link, i, codec) {
      (A)				dai = snd_soc_find_dai(codec);
      				...
      			}
      		}
      		...
      	}
      
      Because of these background, we will get WARNING if .config has CONFIG_LOCKDEP.
      
      	WARNING: CPU: 2 PID: 53 at sound/soc/soc-core.c:814 snd_soc_find_dai+0xf8/0x100
      	CPU: 2 PID: 53 Comm: kworker/2:1 Not tainted 5.7.0-rc1+ #328
      	Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
      	Workqueue: events deferred_probe_work_func
      	pstate: 60000005 (nZCv daif -PAN -UAO)
      	pc : snd_soc_find_dai+0xf8/0x100
      	lr : snd_soc_find_dai+0xf4/0x100
      	...
      	Call trace:
      	 snd_soc_find_dai+0xf8/0x100
      	 snd_soc_dai_link_set_capabilities+0xa0/0x16c
      	 graph_dai_link_of_dpcm+0x390/0x3c0
      	 graph_for_each_link+0x134/0x200
      	 graph_probe+0x144/0x230
      	 platform_drv_probe+0x5c/0xb0
      	 really_probe+0xe4/0x430
      	 driver_probe_device+0x60/0xf4
      
      snd_soc_find_dai() will be used from (X) CPU/Codec/Platform driver with
      mutex lock, and (Y) Card driver without mutex lock.
      This snd_soc_dai_link_set_capabilities() is for Card driver,
      this means called without mutex.
      This patch adds snd_soc_find_dai_with_mutex() to solve it.
      
      Fixes: 25612477 ("ASoC: soc-dai: set dai_link dpcm_ flags with a helper")
      Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Link: https://lore.kernel.org/r/87blixvuab.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>
      c1c277b2
  9. 24 8月, 2020 1 次提交
  10. 18 8月, 2020 1 次提交
  11. 01 8月, 2020 3 次提交
  12. 31 7月, 2020 1 次提交
  13. 17 7月, 2020 1 次提交
  14. 07 7月, 2020 1 次提交
    • M
      ASoC: core: Remove only the registered component in devm functions · 58f30150
      Maxime Ripard 提交于
      The ASoC devm_ functions that register a component
      (devm_snd_soc_register_component and devm_snd_dmaengine_pcm_register) will
      clean their component by running snd_soc_unregister_component.
      
      snd_soc_unregister_component will then remove all the components for the
      device that was used to register the component in the first place.
      
      However, some drivers register several components (such as a DAI and a
      dmaengine PCM) on the same device, and if the dmaengine PCM is registered
      first, then the DAI will be cleaned up first and
      snd_dmaengine_pcm_unregister will be called next.
      
      snd_dmaengine_pcm_unregister will then lookup the dmaengine PCM component
      on the device, and if there's one unregister that component and release its
      dmaengine channels. That doesn't happen in practice though since the first
      call to snd_soc_unregister_component removed all the components, so we
      never get the chance to release the dmaengine channels.
      
      In order to fix this, instead of removing all the components for a given
      device, we can simply remove the component that was registered in the first
      place. We should have the same number of component registration than we
      have components, so it should work just fine.
      Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
      Link: https://lore.kernel.org/r/20200707074237.287171-1-maxime@cerno.techSigned-off-by: NMark Brown <broonie@kernel.org>
      58f30150
  15. 23 6月, 2020 1 次提交
  16. 16 6月, 2020 4 次提交
  17. 12 6月, 2020 1 次提交
  18. 09 6月, 2020 1 次提交
  19. 30 5月, 2020 11 次提交
  20. 25 5月, 2020 2 次提交
  21. 18 5月, 2020 1 次提交