“015941a8eab9e6f474febb8e216850f269d34582”上不存在“demo/sequence_labeling/README.md.bak”
  1. 29 9月, 2020 2 次提交
    • K
      ASoC: soc-component: add mark for snd_soc_pcm_component_pm_runtime_get/put() · 939a5cfb
      Kuninori Morimoto 提交于
      soc_pcm_open() does rollback when failed (A),
      but, it is almost same as soc_pcm_close().
      
      	static int soc_pcm_open(xxx)
      	{
      		...
      		if (ret < 0)
      			goto xxx_err;
      		...
      		return 0;
      
       ^	config_err:
       |		...
       |	rtd_startup_err:
      (A)		...
       |	component_err:
       |		...
       v		return ret;
      	}
      
      The difference is
      soc_pcm_close() is for all dai/component/substream,
      rollback        is for succeeded part only.
      
      This kind of duplicated code can be a hotbed of bugs,
      thus, we want to share soc_pcm_close() and rollback.
      
      Now, soc_pcm_open/close() are handling
      	1) snd_soc_dai_startup/shutdown()
      	2) snd_soc_link_startup/shutdown()
      	3) snd_soc_component_module_get/put()
      	4) snd_soc_component_open/close()
      =>	5) pm_runtime_put/get()
      
      This patch is for 5) pm_runtime_put/get().
      
      The idea of having bit-flag or counter is not enough for this purpose.
      For example if one DAI is used for 2xPlaybacks for some reasons,
      and if 1st Playback was succeeded but 2nd Playback was failed,
      2nd Playback rollback doesn't need to call shutdown.
      But it has succeeded bit-flag or counter via 1st Playback,
      thus, 2nd Playback rollback will call unneeded shutdown.
      And 1st Playback's necessary shutdown will not be called,
      because bit-flag or counter was cleared by wrong 2nd Playback rollback.
      
      To avoid such case, this patch marks substream pointer when get() was
      succeeded. If rollback needed, it will check rollback flag and marked
      substream pointer.
      
      One note here is that it cares *current* get() only now.
      but we might want to check *whole* marked substream in the future.
      This patch is using macro named "push/pop", so that it can be easily
      update.
      Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Link: https://lore.kernel.org/r/87h7ribwnb.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>
      939a5cfb
    • K
      ASoC: soc-component: add mark for soc_pcm_components_open/close() · 51aff91a
      Kuninori Morimoto 提交于
      soc_pcm_open() does rollback when failed (A),
      but, it is almost same as soc_pcm_close().
      
      	static int soc_pcm_open(xxx)
      	{
      		...
      		if (ret < 0)
      			goto xxx_err;
      		...
      		return 0;
      
       ^	config_err:
       |		...
       |	rtd_startup_err:
      (A)		...
       |	component_err:
       |		...
       v		return ret;
      	}
      
      The difference is
      soc_pcm_close() is for all dai/component/substream,
      rollback        is for succeeded part only.
      
      This kind of duplicated code can be a hotbed of bugs,
      thus, we want to share soc_pcm_close() and rollback.
      
      Now, soc_pcm_open/close() are handling
      	1) snd_soc_dai_startup/shutdown()
      	2) snd_soc_link_startup/shutdown()
      =>	3) snd_soc_component_module_get/put()
      =>	4) snd_soc_component_open/close()
      	5) pm_runtime_put/get()
      
      This patch is for 3) snd_soc_component_module_get/put()
      4) snd_soc_component_open/close().
      
      The idea of having bit-flag or counter is not enough for this purpose.
      For example if one DAI is used for 2xPlaybacks for some reasons,
      and if 1st Playback was succeeded but 2nd Playback was failed,
      2nd Playback rollback doesn't need to call shutdown.
      But it has succeeded bit-flag or counter via 1st Playback,
      thus, 2nd Playback rollback will call unneeded shutdown.
      And 1st Playback's necessary shutdown will not be called,
      because bit-flag or counter was cleared by wrong 2nd Playback rollback.
      
      To avoid such case, this patch marks substream pointer when open() was
      succeeded. If rollback needed, it will check rollback flag and marked
      substream pointer.
      
      One note here is that it cares *current* open() only now.
      but we might want to check *whole* marked substream in the future.
      This patch is using macro named "push/pop", so that it can be easily
      update.
      Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Link: https://lore.kernel.org/r/87imbybwno.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>
      51aff91a
  2. 11 8月, 2020 1 次提交
    • T
      ASoC: Make soc_component_read() returning an error code again · efc913c8
      Takashi Iwai 提交于
      Along with the recent unification of snd_soc_component_read*()
      functions, the behavior of snd_soc_component_read() was changed
      slightly; namely it returns the register read value directly, and even
      if an error happens, it returns zero (but it prints an error
      message).  That said, the caller side can't know whether it's an error
      or not any longer.
      
      Ideally this shouldn't matter much, but in practice this seems causing
      a regression, as John reported.  And, grepping the tree revealed that
      there are still plenty of callers that do check the error code, so
      we'll need to deal with them in anyway.
      
      As a quick band-aid over the regression, this patch changes the return
      value of snd_soc_component_read() again to the negative error code.
      It can't work, obviously, for 32bit register values, but it should be
      enough for the known regressions, so far.
      
      Fixes: cf6e26c7 ("ASoC: soc-component: merge snd_soc_component_read() and snd_soc_component_read32()")
      Reported-by: NJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Link: https://lore.kernel.org/r/20200810134631.19742-1-tiwai@suse.deSigned-off-by: NMark Brown <broonie@kernel.org>
      efc913c8
  3. 01 8月, 2020 1 次提交
  4. 24 7月, 2020 2 次提交
  5. 17 7月, 2020 1 次提交
  6. 22 6月, 2020 2 次提交
    • K
      ASoC: soc-component: use io_mutex correctly · e8712315
      Kuninori Morimoto 提交于
      component has io_mutex, but it had been used at
      snd_soc_component_update_bits_legacy() only which does read and write.
      
      	static int snd_soc_component_update_bits_legacy(...)
      	{
      		...
      =>		mutex_lock(&component->io_mutex);
      		...
      		old = snd_soc_component_read(...);
      		...
      		ret = snd_soc_component_write(...);
      		...
      =>		mutex_unlock(&component->io_mutex);
      		...
      	}
      
      It is pointless if it is not used with both read and write functions.
      This patch uses io_mutex correctly with read/write.
      Here, xxx_no_lock() is local functions.
      
      	static int snd_soc_component_read(...)
      	{
      		...
      =>		mutex_lock(&component->io_mutex);
      		val = soc_component_read_no_lock(...);
      =>		mutex_unlock(&component->io_mutex);
      		...
      	}
      
      	static int snd_soc_component_write(...)
      	{
      		...
      =>		mutex_lock(&component->io_mutex);
      		ret = soc_component_write_no_lock(...);
      =>		mutex_unlock(&component->io_mutex);
      		...
      	}
      
      	static int snd_soc_component_update_bits_legacy(...)
      	{
      		...
      =>		mutex_lock(&component->io_mutex);
      		...
      		old = soc_component_read_no_lock(...);
      		...
      		ret = soc_component_write_no_lock(...);
      		...
      =>		mutex_unlock(&component->io_mutex);
      		...
      	}
      Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Link: https://lore.kernel.org/r/87r1uf4mfa.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>
      e8712315
    • K
      ASoC: soc-component: merge snd_soc_component_read() and snd_soc_component_read32() · cf6e26c7
      Kuninori Morimoto 提交于
      We had read/write function for Codec, Platform, etc,
      but these has been merged into snd_soc_component_read/write().
      
      Internally, it is using regmap or driver function.
      In read case, each styles are like below
      
      regmap
      	ret = regmap_read(..., reg, &val);
      
      driver function
      	val = xxx->read(..., reg);
      
      Because of this kind of different style, to keep same read style,
      when we merged each read function into snd_soc_component_read(),
      we created snd_soc_component_read32(), like below.
      commit 738b49ef ("ASoC: add snd_soc_component_read32")
      
      (1)	val = snd_soc_component_read32(component, reg);
      
      (2)	ret = snd_soc_component_read(component, reg, &val);
      
      Many drivers are using snd_soc_component_read32(), and
      some drivers are using snd_soc_component_read() today.
      
      In generally, we don't check read function successes,
      because, we will have many other issues at initial timing
      if read function didn't work.
      
      Now we can use soc_component_err() when error case.
      This means, it is easy to notice if error occurred.
      
      This patch aggressively merge snd_soc_component_read() and _read32(),
      and makes snd_soc_component_read/write() as generally style.
      
      This patch do
      	1) merge snd_soc_component_read() and snd_soc_component_read32()
      	2) it uses soc_component_err() when error case (easy to notice)
      	3) keeps read32 for now by #define
      	4) update snd_soc_component_read() for all drivers
      
      Because _read() user drivers are not too many, this patch changes
      all user drivers.
      Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Reviewed-by: NKai Vehmanen <kai.vehmanen@linux.intel.com>
      Link: https://lore.kernel.org/r/87sgev4mfl.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>
      cf6e26c7
  7. 16 6月, 2020 10 次提交
  8. 29 2月, 2020 1 次提交
  9. 25 2月, 2020 1 次提交
  10. 13 2月, 2020 1 次提交
  11. 10 1月, 2020 1 次提交
    • K
      ASoC: soc-core: remove snd_soc_rtdcom_list · 613fb500
      Kuninori Morimoto 提交于
      Current ALSA SoC is using struct snd_soc_rtdcom_list to
      connecting component to rtd by using list_head.
      
      	struct snd_soc_rtdcom_list {
      		struct snd_soc_component *component;
      		struct list_head list; /* rtd::component_list */
      	};
      
      	struct snd_soc_pcm_runtime {
      		...
      		struct list_head component_list; /* list of connected components */
      		...
      	};
      
      The CPU/Codec/Platform component which will be connected to rtd (a)
      is indicated via dai_link at snd_soc_add_pcm_runtime()
      
      	int snd_soc_add_pcm_runtime(...)
      	{
      		...
      		/* Find CPU from registered CPUs */
      		rtd->cpu_dai = snd_soc_find_dai(dai_link->cpus);
      		...
      (a)		snd_soc_rtdcom_add(rtd, rtd->cpu_dai->component);
      		...
      
      		/* Find CODEC from registered CODECs */
      (b)		for_each_link_codecs(dai_link, i, codec) {
      			rtd->codec_dais[i] = snd_soc_find_dai(codec);
      			...
      (a)			snd_soc_rtdcom_add(rtd, rtd->codec_dais[i]->component);
      		}
      		...
      
      		/* Find PLATFORM from registered PLATFORMs */
      (b)		for_each_link_platforms(dai_link, i, platform) {
      			for_each_component(component) {
      				...
      (a)				snd_soc_rtdcom_add(rtd, component);
      			}
      		}
      
      	}
      
      It shows, it is possible to know how many components will be
      connected to rtd by using
      
      	dai_link->num_cpus
      	dai_link->num_codecs
      	dai_link->num_platforms
      
      If so, we can use component pointer array instead of list_head,
      in such case, code can be more simple.
      This patch removes struct snd_soc_rtdcom_list that is only
      of temporary value, and convert to pointer array.
      Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Reviewed-By: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
      Link: https://lore.kernel.org/r/87a76wt4wm.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>
      613fb500
  12. 08 1月, 2020 1 次提交
  13. 22 11月, 2019 1 次提交
  14. 20 11月, 2019 1 次提交
  15. 24 10月, 2019 1 次提交
  16. 08 10月, 2019 3 次提交
  17. 05 8月, 2019 10 次提交