1. 03 3月, 2012 1 次提交
  2. 24 2月, 2012 1 次提交
  3. 22 2月, 2012 2 次提交
    • M
      ASoC: core: Add support for masking out parts of coefficient blocks · f831b055
      Mark Brown 提交于
      Chip designers frequently include things like the enable and disable
      controls for algorithms in the register blocks which also hold the
      coefficients. Since it's desirable to split out the enable/disable
      control from userspace the plain SND_SOC_BYTES() isn't optimal for
      these devices.
      
      Add a SND_SOC_BYTES_MASK() which allows a bitmask from the first word
      of the block to be excluded from the control. This supports the needs
      of devices I've looked at and lets us have a reasonably simple API.
      Further controls can be added in future if that's needed.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      f831b055
    • M
      ASoC: core: Add SND_SOC_BYTES control for coefficient blocks · 71d08516
      Mark Brown 提交于
      Allow devices to export blocks of registers to the application layer,
      intended for use for reading and writing coefficient data which can't
      usefully be worked with by the kernel at runtime (for example, due to
      requiring complex and expensive calculations or being the results of
      callibration procedures). Currently drivers are using platform data to
      provide configurations for coefficient blocks which isn't at all
      convenient for runtime management or configuration development.
      
      Currently only devices using regmap are supported, an error will be
      generated for any attempt to work with a byte control on a non-regmap
      device. There's no fundamental block to other devices so support could
      be added if required.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      71d08516
  4. 18 2月, 2012 4 次提交
  5. 16 2月, 2012 1 次提交
  6. 15 2月, 2012 1 次提交
  7. 09 2月, 2012 1 次提交
  8. 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
  9. 01 2月, 2012 2 次提交
    • M
      ASoC: core: Support suspend to disk · 5aa44b13
      Mark Brown 提交于
      Use the same pm_ops for all system suspend and resume paths. This isn't
      ideal for suspend to disk with older CODECs as we'll suspend and then
      resume the CODEC before powering off all of which takes a long time due
      to VMID ramps but it's very simple to implement and for modern CODECs the
      overhead should be minimal.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      5aa44b13
    • M
      ASoC: core: Better support for idle_bias_off suspend ignores · 125a25da
      Mark Brown 提交于
      If an idle_bias_off device is in any state other than off then it is still
      active for some reason (typically a low power function such as accessory
      detection). This wasn't an issue when the feature was implemented as we
      always went to _ON for any active function, subsequent power improvements
      have changed things.
      
      With the modern way of doing things we should overhaul the infrastructure
      to allow devices to explicitly take references for these functions but
      that's a much more invasive change and will require driver updates to
      deploy, this will bring the framework into line with the existing driver
      set before we do that work.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      125a25da
  10. 22 1月, 2012 1 次提交
  11. 20 1月, 2012 1 次提交
  12. 16 1月, 2012 1 次提交
  13. 11 1月, 2012 1 次提交
  14. 23 12月, 2011 1 次提交
  15. 22 12月, 2011 1 次提交
  16. 20 12月, 2011 2 次提交
  17. 11 12月, 2011 1 次提交
  18. 09 12月, 2011 1 次提交
  19. 02 12月, 2011 1 次提交
  20. 28 11月, 2011 1 次提交
  21. 24 11月, 2011 1 次提交
    • S
      ASoC: Implement fully_routed card property · 1633281b
      Stephen Warren 提交于
      A card is fully routed if the DAPM route table describes all connections on
      the board.
      
      When a card is fully routed, some operations can be automated by the ASoC
      core. The first, and currently only, such operation is described below, and
      implemented by this patch.
      
      Codecs often have a large number of external pins, and not all of these pins
      will be connected on all board designs. Some machine drivers therefore call
      snd_soc_dapm_nc_pin() for all the unused pins, in order to tell the ASoC core
      never to activate them.
      
      However, when a card is fully routed, the information needed to derive the
      set of unused pins is present in card->dapm_routes. In this case, have
      the ASoC core automatically call snd_soc_dapm_nc_pin() for each unused
      codec pin.
      
      This has been tested with soc/tegra/tegra_wm8903.c and soc/tegra/trimslice.c.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      1633281b
  22. 23 11月, 2011 2 次提交
    • E
      ASoC: skip resume of soc-audio devices without codecs · 5ff1ddf2
      Eric Miao 提交于
      There are cases where there is no working codec on the soc-audio devices,
      and snd_soc_suspend() will skip such device when suspending. Yet its
      counterpart snd_soc_resume() does not check this, causing complaints
      about spinlock lockup:
      
      [  176.726087] BUG: spinlock lockup on CPU#0, kworker/0:2/1067, d8ab82a8
      [  176.732539] [<80014a14>] (unwind_backtrace+0x0/0xec) from [<805b3fc8>] (dump_stack+0x20/0x24)
      [  176.741082] [<805b3fc8>] (dump_stack+0x20/0x24) from [<80322208>] (do_raw_spin_lock+0x118/0x158)
      [  176.749882] [<80322208>] (do_raw_spin_lock+0x118/0x158) from [<805b7874>] (_raw_spin_lock_irqsave+0x5c/0x68)
      [  176.759723] [<805b7874>] (_raw_spin_lock_irqsave+0x5c/0x68) from [<8002a020>] (__wake_up+0x2c/0x5c)
      [  176.768781] [<8002a020>] (__wake_up+0x2c/0x5c) from [<804a6de8>] (soc_resume_deferred+0x3c/0x2b0)
      [  176.777666] [<804a6de8>] (soc_resume_deferred+0x3c/0x2b0) from [<8004ee20>] (process_one_work+0x2e8/0x50c)
      [  176.787334] [<8004ee20>] (process_one_work+0x2e8/0x50c) from [<8004fd08>] (worker_thread+0x1c8/0x2e0)
      [  176.796566] [<8004fd08>] (worker_thread+0x1c8/0x2e0) from [<80053ec8>] (kthread+0xa4/0xb0)
      [  176.804843] [<80053ec8>] (kthread+0xa4/0xb0) from [<8000ea70>] (kernel_thread_exit+0x0/0x8)
      Signed-off-by: NEric Miao <eric.miao@linaro.org>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      5ff1ddf2
    • 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
  23. 18 10月, 2011 1 次提交
  24. 12 10月, 2011 1 次提交
  25. 09 10月, 2011 1 次提交
  26. 08 10月, 2011 1 次提交
  27. 06 10月, 2011 3 次提交
  28. 04 10月, 2011 2 次提交
  29. 28 9月, 2011 1 次提交
    • M
      ASoC: Allow DAI formats to be specified in the dai_link · 75d9ac46
      Mark Brown 提交于
      For almost all machines the DAI format is a constant, always set to the
      same thing. This means that not only should we normally set it on init
      rather than in hw_params() (where it has been for historical reasons) we
      should also allow users to configure this by setting a variable in the
      dai_link structure. The combination of these two will make many machine
      drivers even more data driven.
      
      Implement a new dai_fmt field in the dai_link doing just that. Since 0 is
      a valid value for many format flags and we need to be able to tell if the
      field is actually set also add one to all the values used to configure
      formats.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      75d9ac46
  30. 21 9月, 2011 1 次提交