1. 11 8月, 2012 1 次提交
  2. 10 8月, 2012 1 次提交
  3. 07 8月, 2012 1 次提交
  4. 02 8月, 2012 1 次提交
  5. 12 7月, 2012 1 次提交
  6. 04 7月, 2012 1 次提交
  7. 13 6月, 2012 4 次提交
  8. 03 6月, 2012 2 次提交
    • A
      ASoC: core: Add single controls with specified range of values · 6c9d8cf6
      Adam Thomson 提交于
      Control type added for cases where a specific range of values
      within a register are required for control.
      
      Added convenience macros:
      
      SOC_SINGLE_RANGE
      SOC_SINGLE_RANGE_TLV
      
      Added accessor implementations:
      
      snd_soc_info_volsw_range
      snd_soc_put_volsw_range
      snd_soc_get_volsw_range
      Signed-off-by: NMichal Hajduk <Michal.Hajduk@diasemi.com>
      Signed-off-by: NAdam Thomson <Adam.Thomson@diasemi.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      6c9d8cf6
    • S
      ASoC: make snd_soc_dai_link more symmetrical · bc92657a
      Stephen Warren 提交于
      Prior to this patch, the CPU side of a DAI link was specified using a
      single name. Often, this was the result of calling dev_name() on the
      device providing the DAI, but in the case of a CPU DAI driver that
      provided multiple DAIs, it needed to mix together both the device name
      and some device-relative name, in order to form a single globally unique
      name.
      
      However, the CODEC side of the DAI link was specified using separate
      fields for device (name or OF node) and device-relative DAI name.
      
      This patch allows the CPU side of a DAI link to be specified in the same
      way as the CODEC side, separating concepts of device and device-relative
      DAI name.
      
      I believe this will be important in multi-codec and/or dynamic PCM
      scenarios, where a single CPU driver provides multiple DAIs, while also
      booting using device tree, with accompanying desire not to hard-code the
      CPU side device's name into the original .cpu_dai_name field.
      
      Ideally, both the CPU DAI and CODEC DAI loops in soc_bind_dai_link()
      would now be identical. However, two things prevent that at present:
      
      1) The need to save rtd->codec for the CODEC side, which means we have
      to search for the CODEC explicitly, and not just the CODEC side DAI.
      
      2) Since we know the CODEC side DAI is part of a codec, and not just
      a standalone DAI, it's slightly more efficient to convert .codec_name/
      .codec_of_node into a codec first, and then compare each DAI's .codec
      field, since this avoids strcmp() on each DAI's CODEC's name within
      the loop.
      
      However, the two loops are essentially semantically equivalent.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      bc92657a
  9. 16 5月, 2012 1 次提交
  10. 30 4月, 2012 1 次提交
  11. 27 4月, 2012 3 次提交
    • 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
  12. 26 4月, 2012 1 次提交
  13. 24 4月, 2012 3 次提交
  14. 18 4月, 2012 1 次提交
  15. 17 4月, 2012 4 次提交
    • 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
    • M
      ASoC: core: Bind DAIs to CODECs at registration time · 054880fe
      Mark Brown 提交于
      We should always have a CODEC already there when registering a CODEC DAI
      and for CODEC<->CODEC links a dai_link will have two CODECs so it's much
      simpler to do things at registration time.
      
      This results in a slight change in the error handling for failed CODEC
      DAI registrations but practically speaking these are never supposed to
      fail so there shouldn't be much issue. The change is that we don't fail
      the overall CODEC registration if the DAI registration fails; this seems
      more robust anyway as we may not need to use a given DAI in a particular
      system.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      054880fe
    • M
      ASoC: core: Flip master for CODECs in the CPU slot of a CODEC<->CODEC link · f04209a7
      Mark Brown 提交于
      When two CODEC DAIs are linked directly to each other then if we give the
      same master mode settings to both devices things won't work as either
      neither will drive or they'll drive against each other. Flip the settings
      for the DAI in the CPU slot of the DAI link.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      f04209a7
    • M
      ASoC: core: Return -ENOTSUPP instead of -EINVAL if mute is not supported · 04570c62
      Mark Brown 提交于
      This helps us ignore errors in callers if the operation failed due to not
      being available as opposed to an error.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      04570c62
  16. 06 4月, 2012 2 次提交
    • S
      simple_open: automatically convert to simple_open() · 234e3405
      Stephen Boyd 提交于
      Many users of debugfs copy the implementation of default_open() when
      they want to support a custom read/write function op.  This leads to a
      proliferation of the default_open() implementation across the entire
      tree.
      
      Now that the common implementation has been consolidated into libfs we
      can replace all the users of this function with simple_open().
      
      This replacement was done with the following semantic patch:
      
      <smpl>
      @ open @
      identifier open_f != simple_open;
      identifier i, f;
      @@
      -int open_f(struct inode *i, struct file *f)
      -{
      (
      -if (i->i_private)
      -f->private_data = i->i_private;
      |
      -f->private_data = i->i_private;
      )
      -return 0;
      -}
      
      @ has_open depends on open @
      identifier fops;
      identifier open.open_f;
      @@
      struct file_operations fops = {
      ...
      -.open = open_f,
      +.open = simple_open,
      ...
      };
      </smpl>
      
      [akpm@linux-foundation.org: checkpatch fixes]
      Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Julia Lawall <Julia.Lawall@lip6.fr>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      234e3405
    • S
      ASoC: set idle_bias_off=1 for all platform DAPM contexts · 3fec6b6d
      Stephen Warren 提交于
      The ASoC core currently defaults to using STANDBY rather than OFF for
      idle ASoC platform devices, which causes a permanent pm_runtime_get() on
      them. This keeps the device active unnecessarily. This can be especially
      problematic when the ASoC platform device and DAI device are the same
      device.
      
      The distinction between OFF and STANDBY is likely not relevant for ASoC
      platform drivers, since they aren't analog devices. So, solve this issue
      by hard-coding idle_bias_off = 1 for all ASoC platform devices. If this
      turns out to be a problem, this value could be sourced from the
      snd_soc_platform_driver, similarly to soc_probe_codec().
      
      Note: Prior to this change, this caused a large (10) runtime_active count
      for the Tegra I2S controller even when not in use, and a leak in that
      value as streams were started and stopped. This change probably hides a
      bug.
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      3fec6b6d
  17. 04 4月, 2012 1 次提交
  18. 03 4月, 2012 1 次提交
  19. 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
    • L
      ASoC: dapm: Add platform stream event support · d9b0951b
      Liam Girdwood 提交于
      Currently stream events are only perfomed on codec stream widgets only.
      There is now a need to be able to perform stream events on platform
      widgets too.
      
      e.g. we have the ABE platform driver with several DAI links
      to dummy codecs. We need to be able to perform stream events on any
      of the dummy codec DAI links.
      
      This patch also removes the snd_soc_dai * parameter since it's already
      contained within the rtd * parameter.
      
      Finally makle stream event return void since no one checks it anyway.
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      d9b0951b
    • L
      ASoC: core: Add platform DAI widget mapping · be09ad90
      Liam Girdwood 提交于
      Add platform driver support for CPU DAI DAPM widgets.
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      be09ad90
    • 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
  20. 15 3月, 2012 1 次提交
  21. 09 3月, 2012 1 次提交
  22. 07 3月, 2012 1 次提交
  23. 03 3月, 2012 2 次提交