1. 27 4月, 2012 4 次提交
    • L
      ASoC: dpcm: Add bespoke trigger() · 07bf84aa
      Liam Girdwood 提交于
      Some on SoC DSP HW is very tightly coupled with DMA and DAI drivers. It's
      necessary to allow some flexability wrt to PCM operations here so that we
      can define a bespoke DPCM trigger() PCM operation for such HW.
      
      A bespoke DPCM trigger() allows exact ordering and timing of component
      triggering by allowing a component driver to manage the final enable
      and disable configurations without adding extra complexity to other
      component drivers. e.g. The McPDM DAI and ABE are tightly coupled on
      OMAP4 so we have a bespoke trigger to manage the trigger to improve
      performance and reduce complexity when triggering new McPDM BEs.
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      07bf84aa
    • L
      ASoC: dpcm: Add API for DAI link substream and runtime lookup · 47c88fff
      Liam Girdwood 提交于
      Some component drivers will need to be able to look up their
      DAI link substream and RTD data. Provide a mechanism for this.
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      47c88fff
    • L
      ASoC: dpcm: Add debugFS support for DPCM · f86dcef8
      Liam Girdwood 提交于
      Add debugFS files for DPCM link management information.
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      f86dcef8
    • L
      ASoC: dpcm: Add Dynamic PCM core operations. · 01d7584c
      Liam Girdwood 提交于
      The Dynamic PCM core allows digital audio data to be dynamically
      routed between different ALSA PCMs and DAI links on SoC CPUs with
      on chip DSP devices. e.g. audio data could be played on pcm:0,0 and
      routed to any (or all) SoC DAI links.
      
      Dynamic PCM introduces the concept of Front End (FE) PCMs and Back
      End (BE) PCMs. The FE PCMs are normal ALSA PCM devices except that
      they can dynamically route digital audio data to any supported BE
      PCM. A BE PCM has no ALSA device, but represents a DAI link and it's
      substream and audio HW parameters.
      
      e.g. pcm:0,0 routing digital data to 2 external codecs.
      
      FE pcm:0,0  ----> BE (McBSP.0) ----> CODEC 0
                   +--> BE (McPDM.0) ----> CODEC 1
      
      e.g. pcm:0,0 and pcm:0,1 routing digital data to 1 external codec.
      
      FE pcm:0,0 ---
                   +--> BE (McBSP.0) ----> CODEC
      FE pcm:0,1 ---
      
      The digital audio routing is controlled by the usual ALSA method
      of mixer kcontrols. Dynamic PCM uses a DAPM graph to work out the
      routing based upon the mixer settings and configures the BE PCMs
      based on routing and the FE HW params.
      
      DPCM is designed so that most ASoC component drivers will need no
      modification at all. It's intended that existing CODEC, DAI and
      platform drivers can be used in DPCM based audio devices without
      any changes. However, there will be some cases where minor changes
      are required (e.g. for very tightly coupled HW) and there are
      helpers to support this too.
      
      Somethimes the HW params of a FE and BE do not match or are
      incompatible, so in these cases the machine driver can reconfigure
      any hw_params and make any DSP perform sample rate / format conversion.
      
      This patch adds the core DPCM code and contains :-
      
       o The FE and BE PCM operations.
       o FE and BE DAI link support.
       o FE and BE PCM creation.
       o BE support API.
       o BE and FE link management.
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      01d7584c
  2. 24 4月, 2012 2 次提交
  3. 17 4月, 2012 1 次提交
    • M
      ASoC: core: Support transparent CODEC<->CODEC DAI links · c74184ed
      Mark Brown 提交于
      Rather than having the user half start a stream but avoid any DMA to
      trigger data flow on links which don't pass through the CPU create a
      DAPM route between the two DAI widgets using a hw_params configuration
      provided by the machine driver with the new 'params' member of the
      dai_link struct.  If no configuration is provided in the dai_link then
      use the old style even for CODEC<->CODEC links to avoid breaking
      systems.
      
      This greatly simplifies the userspace usage of such links, making them
      as simple as analogue connections with the stream configuration being
      completely transparent to them.
      
      This is achieved by defining a new dai_link widget type which is created
      when CODECs are linked and triggering the configuration of the link via
      the normal PCM operations from there.  It is expected that the bias
      level callbacks will be used for clock configuration.
      
      Currently only the DAI format, rate and channel count can be configured
      and currently the only DAI operations which can be called are hw_params
      and digital_mute().  This corresponds well to the majority of CODEC
      drivers which only use other callbacks for constraint setting but there
      is obviously much room for extension here.  We can't simply call
      hw_params() on startup as things like the system clocking configuration
      may change at runtime and in future it will be desirable to offer some
      configurability of the link parameters.
      
      At present we are also restricted to a single DAPM link for the entire
      DAI.  Once we have better support for channel mapping it would also be
      desirable to extend this feature so that we can propagate per-channel
      power state over the link.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      c74184ed
  4. 03 4月, 2012 1 次提交
  5. 01 4月, 2012 5 次提交
    • M
      ASoC: core: Use driver core probe deferral · b19e6e7b
      Mark Brown 提交于
      In version 3.4 the driver core acquired probe deferral which is a core way
      of doing essentially the same thing as ASoC has been doing since forever
      to make sure that all the devices needed to make up the card are present
      without needing open coding in the subsystem.
      
      Make basic use of this probe deferral mechanism for the cards, removing the
      need to handle partially instantiated cards. We should be able to remove
      even more code than this, though some of the checks we're currently doing
      should stay since they're about things like suppressing unneeded DAPM runs
      rather than deferring probes.
      
      In order to avoid robustness issues with our teardown paths (which do need
      quite a bit of TLC) add a check for aux_devs prior to attempting to set
      things up, this means that we've got a reasonable idea that everything will
      be there before we start. As with the removal of partial instantiation
      support more work will be needed to make this work neatly.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      b19e6e7b
    • M
      ASoC: jack: Push locking for jacks down to the jack · 2667b4b8
      Mark Brown 提交于
      Currently operations on jack reporting take the CODEC mutex both to protect
      the current jack status and also to protect the DAPM run which is triggered
      on status updates. Since the addition of a DAPM-specific lock we no longer
      need to worry about locking DAPM as it has its own finer grained lock so
      create a per jack lock to take care of the jack status.
      
      This is both cleaner where the jack isn't specifically associated with a
      CODEC and clearer as it's much more obvious what the lock is protecting.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      2667b4b8
    • L
      ASoC: core: Rename card mutex subclass to better align with usage · 6874a918
      Liam Girdwood 提交于
      Change SND_SOC_CARD_CLASS_PCM to SND_SOC_CARD_CLASS_RUNTIME to better
      describe all uses for this mutex subclass and align with DAPM too.
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      6874a918
    • 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
  6. 07 3月, 2012 1 次提交
  7. 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
  8. 18 2月, 2012 1 次提交
  9. 16 2月, 2012 1 次提交
  10. 09 2月, 2012 1 次提交
  11. 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
  12. 22 1月, 2012 1 次提交
  13. 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
  14. 11 1月, 2012 1 次提交
  15. 23 12月, 2011 1 次提交
  16. 22 12月, 2011 1 次提交
  17. 20 12月, 2011 2 次提交
  18. 13 12月, 2011 1 次提交
  19. 02 12月, 2011 1 次提交
  20. 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
  21. 10 11月, 2011 2 次提交
  22. 27 10月, 2011 1 次提交
  23. 15 10月, 2011 1 次提交
  24. 07 10月, 2011 1 次提交
  25. 06 10月, 2011 5 次提交