1. 01 4月, 2012 2 次提交
    • L
      ASoC: dapm: Use DAPM mutex for DAPM ops instead of codec mutex · a73fb2df
      Liam Girdwood 提交于
      It has now become necessary to use a DAPM mutex instead of the codec
      mutex to lock the DAPM operations. This is due to the recent multi
      component support and forth coming Dynamic PCM updates.
      
      Currently we lock DAPM operations with the codec mutex of the calling
      RTD context. However, DAPM operations can span the whole card context
      and all components.
      
      This patch updates the DAPM operations that use the codec mutex to
      now use the DAPM mutex PCM subclass for all DAPM ops.
      
      We also add a mutex subclass for DAPM init and PCM operations.
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      a73fb2df
    • L
      ASoC: core: Add card mutex locking subclasses · 01b9d99a
      Liam Girdwood 提交于
      This is the first part of a change that is intended to improve
      ASoC locking protection for DAPM and PCM operations.
      
      This part of the series adds a mutex class for the soc_card mutex. The
      SND_SOC_CARD_CLASS_INIT class is used for card initialisation only whilst the
      SND_SOC_CARD_CLASS_PCM class is used for the forth coming Dynamic
      PCM operations. The new mutex classes are required otherwise we will see a false
      positive mutex deadlock warning between the card initialisation and the PCM
      operations (something that would never deadlock in real life).
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      01b9d99a
  2. 07 3月, 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 1 次提交
  5. 16 2月, 2012 1 次提交
  6. 09 2月, 2012 1 次提交
  7. 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
  8. 22 1月, 2012 1 次提交
  9. 20 1月, 2012 1 次提交
    • M
      ASoC: Allow drivers to specify how many bits are significant on a DAI · 58ba9b25
      Mark Brown 提交于
      Most devices accept data in formats that don't correspond directly to
      their internal format. ALSA allows us to set a msbits constraint which
      tells userspace about this in case it finds it useful (for example, in
      order to avoid wasting effort dithering bits that will be ignored when
      raising the sample size of data) so provide a mechanism for drivers to
      specify the number of bits that are actually significant on a DAI and
      add the appropriate constraints along with all the others.
      
      This is done slightly awkwardly as the constraint is specified per sample
      size - we loop over every possible sample size, including ones that the
      device doesn't support and including ones that have fewer bits than are
      actually used, but this is harmless as the upper layers do the right thing
      in these cases.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      58ba9b25
  10. 11 1月, 2012 1 次提交
  11. 23 12月, 2011 1 次提交
  12. 22 12月, 2011 1 次提交
  13. 20 12月, 2011 2 次提交
  14. 13 12月, 2011 1 次提交
  15. 02 12月, 2011 1 次提交
  16. 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
  17. 10 11月, 2011 2 次提交
  18. 27 10月, 2011 1 次提交
  19. 15 10月, 2011 1 次提交
  20. 07 10月, 2011 1 次提交
  21. 06 10月, 2011 5 次提交
  22. 04 10月, 2011 3 次提交
  23. 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
  24. 21 9月, 2011 2 次提交
    • D
      ASoC: soc-core: symmetry checking for each DAIs separately · 17841020
      Dong Aisheng 提交于
      The orginal code does not cover the case that one DAI such as codec
      may be shared between other two DAIs(CPU).
      When do symmetry checking, altough the codec DAI requires symmetry,
      the two CPU DAIs may still be configured to run on different rates.
      
      We change to check each DAI's state separately instead of only checking
      the dai link to prevent this issue.
      Signed-off-by: NDong Aisheng <b29396@freescale.com>
      Tested-by: NWolfram Sang <w.sang@pengutronix.de>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      17841020
    • M
      ASoC: Trace and collect statistics for DAPM graph walking · de02d078
      Mark Brown 提交于
      One of the longest standing areas for improvement in ASoC has been the
      DAPM algorithm - it repeats the same checks many times whenever it is run
      and makes no effort to limit the areas of the graph it checks meaning we
      do an awful lot of walks over the full graph. This has never mattered too
      much as the size of the graph has generally been small in relation to the
      size of the devices supported and the speed of CPUs but it is annoying.
      
      In preparation for work on improving this insert a trace point after the
      graph walk has been done. This gives us specific timing information for
      the walk, and in order to give quantifiable (non-benchmark) numbers also
      count every time we check a link or check the power for a widget and report
      those numbers. Substantial changes in the algorithm may require tweaks to
      the stats but they should be useful for simpler things.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      de02d078
  25. 31 8月, 2011 2 次提交
  26. 23 8月, 2011 1 次提交
  27. 08 8月, 2011 2 次提交