Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 11月, 2017 1 次提交
    • K
      ASoC: rsnd: remove NULL check from rsnd_mod_name()/rsnd_mod_id() · 9b6ea250
      由 Kuninori Morimoto 提交于 
      Current rsnd driver has rsnd_mod_id() which returns mod ID,
and it returns -1 if mod was NULL.
In the same time, this driver has rsnd_mod_name() which returns mod
name, and it returns "unknown" if mod or mod->ops was NULL.

Basically these "mod" never be NULL, but the reason why rsnd driver
has such behavior is that DMA path finder is assuming memory as
"mod == NULL".
Thus, current DMA path debug code prints like below.
Here "unknown[-1]" means it was memory.

	...
	rcar_sound ec500000.sound:   unknown[-1] from
	rcar_sound ec500000.sound:   src[0] to
	rcar_sound ec500000.sound:   ctu[2]
	rcar_sound ec500000.sound:   mix[0]
	rcar_sound ec500000.sound:   dvc[0]
	rcar_sound ec500000.sound:   ssi[0]
	rcar_sound ec500000.sound: audmac[0] unknown[-1] -> src[0]
	...

1st issue is that it is confusable for user.
2nd issue is rsnd driver has something like below code.

	mask |= 1 << rsnd_mod_id(mod);

Because of this kind of code, some statically code checker will
reports "Shifting by a negative value is undefined behaviour".

But this "mod" never be NULL, thus negative shift never happen.
To avoid these issues, this patch adds new dummy "mem" to
indicate memory, and use it to indicate debug information,
and, remove unneeded "NULL mod" behavior from rsnd_mod_id() and
rsnd_mod_name().

The debug information will be like below by this patch
	...
	rcar_sound ec500000.sound:   mem[0] from
	rcar_sound ec500000.sound:   src[0] to
	rcar_sound ec500000.sound:   ctu[2]
	rcar_sound ec500000.sound:   mix[0]
	rcar_sound ec500000.sound:   dvc[0]
	rcar_sound ec500000.sound:   ssi[0]
	rcar_sound ec500000.sound: audmac[0] mem[0] -> src[0]
	...
Reported-by: NHiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      9b6ea250
  3. 31 10月, 2017 4 次提交
  5. 04 10月, 2017 2 次提交
  7. 18 8月, 2017 1 次提交
  9. 15 8月, 2017 2 次提交
  11. 10 8月, 2017 2 次提交
  13. 28 7月, 2017 1 次提交
  15. 24 7月, 2017 1 次提交
  17. 30 6月, 2017 1 次提交
  19. 21 6月, 2017 1 次提交
  21. 16 6月, 2017 2 次提交
  23. 14 6月, 2017 3 次提交
  25. 08 6月, 2017 2 次提交
  27. 20 5月, 2017 3 次提交
  29. 17 5月, 2017 2 次提交
  31. 20 4月, 2017 1 次提交
  33. 06 4月, 2017 1 次提交
  35. 29 3月, 2017 1 次提交
  37. 25 3月, 2017 1 次提交
  39. 22 2月, 2017 1 次提交
  41. 23 1月, 2017 1 次提交
  43. 20 1月, 2017 1 次提交
  45. 15 12月, 2016 1 次提交
  47. 07 12月, 2016 1 次提交
  49. 05 12月, 2016 1 次提交
  51. 23 11月, 2016 1 次提交
  53. 25 10月, 2016 1 次提交
    • K
      ASoC: rsnd: add nolock_start/stop callback · 10a9cca1
      由 Kuninori Morimoto 提交于 
      Current Renesas Sound driver requests DMA channel when .probe timing,
and release it when .remove timing. And use DMA on .start/.stop
But, Audio DMAC power ON was handled when request timing (= .probe),
and power OFF was when release timing (= .remove).
This means Audio DMAC power is always ON during driver was enabled.
To fixup this issue, it should request/release DMA channel on each
playback/recorde timing.
But, DMA channel request/release function uses mutex lock inside.
This means it will breaks current spinlock's interrupt protect.
To solve this issue, DMA channel request/release function needs to
be called from non-spinlock area. This patch adds its callback.
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      10a9cca1