Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 22 9月, 2012 1 次提交
  3. 26 8月, 2012 4 次提交
  5. 23 8月, 2012 3 次提交
  7. 27 7月, 2012 1 次提交
  9. 23 5月, 2012 3 次提交
  11. 12 3月, 2012 9 次提交
  13. 04 2月, 2012 1 次提交
    • L
      ASoC: core: Add support for DAI and machine kcontrols. · 022658be
      由 Liam Girdwood 提交于 
      Currently ASoC can only add kcontrols using codec and platform component device
handles. It's also desirable to add kcontrols for DAIs (i.e. McBSP) and for
SoC card machine drivers too. This allows the kcontrol to have a direct handle to
the parent ASoC component DAI/SoC Card/Platform/Codec device and hence easily
get it's private data.

This change makes snd_soc_add_controls() static and wraps it in the folowing
calls (card and dai are new) :-

snd_soc_add_card_controls()
snd_soc_add_codec_controls()
snd_soc_add_dai_controls()
snd_soc_add_platform_controls()

This patch also does a lot of small mechanical changes in individual codec drivers
to replace snd_soc_add_controls() with snd_soc_add_codec_controls().

It also updates the McBSP DAI driver to use snd_soc_add_dai_controls().

Finally, it updates the existing machine drivers that register controls to either :-

1) Use snd_soc_add_card_controls() where no direct codec control is required.
2) Use snd_soc_add_codec_controls() where there is direct codec control.

In the case of 1) above we also update the machine drivers to get the correct
component data pointers from the kcontrol (rather than getting the machine pointer
via the codec pointer).
Signed-off-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      022658be
  15. 17 12月, 2011 1 次提交
  17. 25 11月, 2011 1 次提交
  19. 23 11月, 2011 1 次提交
    • L
      ASoC: Constify snd_soc_dai_ops structs · 85e7652d
      由 Lars-Peter Clausen 提交于 
      Commit 1ee46ebd("ASoC: Make the DAI ops constant in the DAI structure")
introduced the possibility to have constant DAI ops structures, yet this is
barley used in both existing drivers and also new drivers being submitted,
although none of them modifies its DAI ops structure. The later is not
surprising since existing drivers are often used as templates for new drivers.
So this patch just constifies all existing snd_soc_dai_ops structs to eliminate
the issue altogether.

The patch was generated with the following coccinelle semantic patch:
// <smpl>
@@
identifier ops;
@@
-struct snd_soc_dai_ops ops =
+const struct snd_soc_dai_ops ops =
{ ... };
// </smpl>
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      85e7652d
  21. 10 10月, 2011 1 次提交
  23. 03 10月, 2011 1 次提交
    • J
      ASoC: omap-mcbsp: Prepare for init time DAI format setting · 4dd04172
      由 Jarkko Nikula 提交于 
      Before commit 75d9ac46 ("ASoC: Allow DAI formats to be specified in the
dai_link") expectation for omap-mcbsp was that snd_soc_dai_set_fmt is to be
called first in machine hw_params callback before other CPU DAI functions.
Thus it was enough that only omap_mcbsp_dai_set_dai_fmt cleared the
mcbsp->regs structure.  [Note that this was pure convention, it's always
been OK to set things on init -- broonie]

Now this doesn't hold anymore since machine drivers can set the DAI format
only once on init time and thus mcbsp->regs may get out of sync when other
CPU DAI functions are modifying them dynamically with different values
between the calls. Therefore clear the accessed mcbsp->regs bits and
bitfields in other functions too.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      4dd04172
  25. 30 9月, 2011 1 次提交
  27. 26 9月, 2011 1 次提交
  29. 23 9月, 2011 1 次提交
    • J
      ASoC: omap-mcbsp: Do not attempt to change DAI sysclk if stream is active · 34c86985
      由 Jarkko Nikula 提交于 
      Attempt to change McBSP CLKS source while another stream is active is not
safe after commit d135865 ("OMAP: McBSP: implement functional clock
switching via clock framework") in 2.6.37.

CLKS parent clock switching using clock framework have to idle the McBSP
before switching and then activate it again. This short break can cause a
DMA transaction error to already running stream which halts and recovers
only by closing and restarting the stream.

This goes more fatal after commit e2fa61d4 ("OMAP3: l3: Introduce
l3-interconnect error handling driver") in 2.6.39 where l3 driver detects a
severe timeout error and does BUG_ON().

Fix this by not changing any configuration in omap_mcbsp_dai_set_dai_sysclk
if the McBSP is already active. This test should have been here just from
the beginning anyway.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org
      34c86985
  31. 12 8月, 2011 1 次提交
  33. 13 5月, 2011 1 次提交
  35. 11 5月, 2011 1 次提交
  37. 25 2月, 2011 1 次提交
  39. 28 1月, 2011 1 次提交
  41. 23 12月, 2010 1 次提交
  43. 03 11月, 2010 1 次提交
  45. 09 10月, 2010 2 次提交
    • P
      OMAP: McBSP: implement functional clock switching via clock framework · d1358657
      由 Paul Walmsley 提交于 
      Previously the OMAP McBSP ASoC driver implemented CLKS switching by
using omap_ctrl_{read,write}l() directly.  This is against policy; the OMAP
System Control Module functions are not intended to be exported to drivers.
These symbols are no longer exported, so as a result, the OMAP McBSP ASoC
driver does not build as a module.

Resolve the CLKS clock changing portion of this problem by creating a
clock parent changing function that lives in
arch/arm/mach-omap2/mcbsp.c, and modify the ASoC driver to use it.
Due to the unfortunate way that McBSP support is implemented in ASoC
and the OMAP tree, this symbol must be exported for use by
sound/soc/omap/omap-mcbsp.c.

Going forward, the McBSP device driver should be moved from
arch/arm/*omap* into drivers/ or sound/soc/* and the CPU DAI driver
should be implemented as a platform_driver as many other ASoC CPU DAI
drivers are.  These two steps should resolve many of the layering
problems, which will rapidly reappear during a McBSP hwmod/PM runtime
conversions.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Acked-by: NJarkko Nikula <jhnikula@gmail.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com>
Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      d1358657
    • P
      OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c · cf4c87ab
      由 Paul Walmsley 提交于 
      The OMAP ASoC McBSP code implemented CLKR and FSR signal muxing via
direct System Control Module writes on OMAP2+.  This required the
omap_ctrl_{read,write}l() functions to be exported, which is against
policy: the only code that should call those functions directly is
OMAP core code, not device drivers.  omap_ctrl_{read,write}*() are no
longer exported, so the driver no longer builds as a module.

Fix the pinmuxing part of the problem by removing calls to
omap_ctrl_{read,write}l() from the OMAP ASoC McBSP code and
implementing signal muxing functions in arch/arm/mach-omap2/mcbsp.c.
Due to the unfortunate way that McBSP support is implemented in ASoC
and the OMAP tree, these symbols must be exported for use by
sound/soc/omap/omap-mcbsp.c.

Going forward, the McBSP device driver should be moved from
arch/arm/*omap* into drivers/ or sound/soc/*, and the CPU DAI driver
should be implemented as a platform_driver as many other ASoC CPU DAI
drivers are.  These two steps should resolve many of the layering
problems, which will rapidly reappear during a McBSP hwmod/PM runtime
conversion.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Acked-by: NJarkko Nikula <jhnikula@gmail.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@nokia.com>
Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
Acked-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      cf4c87ab
  47. 08 9月, 2010 1 次提交