1. 13 5月, 2014 1 次提交
  2. 22 4月, 2014 1 次提交
    • L
      ASoC: Move IO abstraction to the component level · e2c330b9
      Lars-Peter Clausen 提交于
      We currently have two very similar IO abstractions in ASoC, one for CODECs, the
      other for platforms. Moving this to the component level will allow us to unify
      those two. It will also enable us to move the standard kcontrol helpers as well
      as DAPM support to the component level.
      
      The new component level abstraction layer is primarily build around regmap.
      There is a per component pointer for the regmap instance for the underlying
      device. There are four new function snd_soc_component_read(),
      snd_soc_component_write(), snd_soc_component_update_bits() and
      snd_soc_component_update_bits_async(). They have the same signature as their
      regmap counter-part and will internally forward the call one-to-one to regmap.
      If the component it not using regmap it will fallback to using the custom IO
      callbacks. This is done to be able to support drivers that haven't been
      converted to regmap yet, but it is expected that this will eventually be removed
      in the future once all component drivers have been converted to regmap.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      e2c330b9
  3. 15 4月, 2014 1 次提交
  4. 10 3月, 2014 1 次提交
  5. 01 3月, 2014 2 次提交
    • L
      ASoC: dapm: Consolidate MUXs and virtual MUXs · 236aaa68
      Lars-Peter Clausen 提交于
      MUXs and virtual MUXs are almost identical, the only difference is that for
      virtual MUX there is no hardware backing register in which setting is stored.
      This patch adds code, which is similar to what we already do for DAPM mixer
      controls to support virtual mixer controls, to DAPM enum controls. The new code
      will check if the enum does a hardware backing register and skip over reading
      and writing to the register if it has not.  This allows us to use the same code
      path for both MUXs and virtual MUXs and a lot of nearly identical code can be
      removed.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      236aaa68
    • L
      ASoC: dapm: Consolidate MUXs and value MUXs · 3727b496
      Lars-Peter Clausen 提交于
      MUXs and value MUXs are almost identical, the only difference is that a value
      MUX uses a look-up table to map from the selected control item to a register
      value, while MUXs use a direct mapping. This patch uses
      snd_soc_enum_item_to_val() and snd_soc_enum_val_to_item(), which where earlier
      introduced during the consolidation of enum and value enum controls, to hide
      this difference. This allows us to use the same code path for both MUXs and
      value MUXs and a lot of nearly duplicated code can be removed.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      3727b496
  6. 20 2月, 2014 2 次提交
  7. 08 1月, 2014 1 次提交
  8. 24 11月, 2013 1 次提交
    • S
      ASoC: dapm: Use SND_SOC_DAPM_INIT_REG_VAL in SND_SOC_DAPM_MUX · faf6615b
      Stephen Warren 提交于
      SND_SOC_DAPM_MUX() doesn't currently initialize the .mask field. This
      results in the mux never affecting HW, since no bits are ever set or
      cleared. Fix SND_SOC_DAPM_MUX() to use SND_SOC_DAPM_INIT_REG_VAL() to
      set up the reg, shift, on_val, and off_val fields like almost all other
      SND_SOC_xxx() macros. It looks like this was a "typo" in the fixed
      commit linked below.
      
      This makes the speakers on the Toshiba AC100 (PAZ00) laptop work again.
      
      Fixes: de9ba98b ("ASoC: dapm: Make widget power register settings more flexible")
      Signed-off-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      Cc: <stable@vger.kernel.org> # v3.12+
      faf6615b
  9. 07 10月, 2013 1 次提交
  10. 27 8月, 2013 1 次提交
  11. 05 8月, 2013 1 次提交
    • L
      ASoC: dapm: Implement mixer input auto-disable · 57295073
      Lars-Peter Clausen 提交于
      Some devices have the problem that if a internal audio signal source is disabled
      the output of the source becomes undefined or goes to a undesired state (E.g.
      DAC output goes to ground instead of VMID). In this case it is necessary, in
      order to avoid unwanted clicks and pops, to disable any mixer input the signal
      feeds into or to active a mute control along the path to the output. Often it is
      still desirable to expose the same mixer input control to userspace, so cerain
      paths can sill be disabled manually. This means we can not use conventional DAPM
      to manage the mixer input control. This patch implements a method for letting
      DAPM overwrite the state of a userspace visible control. I.e. DAPM will disable
      the control if the path on which the control sits becomes inactive. Userspace
      will then only see a cached copy of the controls state. Once DAPM powers the
      path up again it will sync the userspace setting with the hardware and give
      control back to userspace.
      
      To implement this a new widget type is introduced. One widget of this type will
      be created for each DAPM kcontrol which has the auto-disable feature enabled.
      For each path that is controlled by the kcontrol the widget will be connected to
      the source of that path. The new widget type behaves like a supply widget,
      which means it will power up if one of its sinks are powered up and will only
      power down if all of its sinks are powered down. In order to only have the mixer
      input enabled when the source signal is valid the new widget type will be
      disabled before all other widget types and only be enabled after all other
      widget types.
      
      E.g. consider the following simplified example. A DAC is connected to a mixer
      and the mixer has a control to enable or disable the signal from the DAC.
      
                           +-------+
        +-----+            |       |
        | DAC |-----[Ctrl]-| Mixer |
        +-----+       :    |       |
           |          :    +-------+
           |          :
          +-------------+
          | Ctrl widget |
          +-------------+
      
      If the control has the auto-disable feature enabled we'll create a widget for
      the control. This widget is connected to the DAC as it is the source for the
      mixer input. If the DAC powers up the control widget powers up and if the DAC
      powers down the control widget is powered down. As long as the control widget
      is powered down the hardware input control is kept disabled and if it is enabled
      userspace can freely change the control's state.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      57295073
  12. 30 7月, 2013 5 次提交
  13. 24 7月, 2013 2 次提交
    • L
      ASoC: dapm: Add a update parameter to snd_soc_dapm_{mux,mixer}_update_power · 6b3fc03b
      Lars-Peter Clausen 提交于
      In order to avoid race conditions the assignment of dapm->update should happen
      while card->dapm_mutex is being held. To allow CODEC drivers to run a register
      update when using snd_soc_dapm_mux_update_power() or
      snd_soc_dapm_mixer_update_power() add a update parameter to these two functions.
      The update parameter will be assigned to dapm->update while card->dapm_mutex is
      locked.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      6b3fc03b
    • L
      ASoC: dapm: Run widget updates for shared controls at the same time · ce6cfaf1
      Lars-Peter Clausen 提交于
      Currently when updating a control that is shared between multiple widgets the
      whole power-up/power-down sequence is being run once for each widget. The
      control register is updated during the first run, which means the CODEC internal
      routing is also updated for all widgets during this first run. The input and
      output paths for each widgets are only updated though during the respective run
      for that widget. This leads to a slight inconsistency between the CODEC's
      internal state and ASoC's state, which causes non optimal behavior in regard to
      click and pop avoidance.
      
      E.g. consider the following setup where two MUXs share the same control.
      
                +------+
       A1 ------|      |
                | MUX1 |----- C1
       B1 ------|      |
                +------+
                   |
        control ---+
                   |
                +------+
       A2 ------|      |
                | MUX2 |----- C2
       B2 ------|      |
                +------+
      
      If the control is updated to switch the MUXs from input A to input B with the
      current code the power-up/power-down sequence will look like this:
      
      Run soc_dapm_mux_update_power for MUX1
        Power-down A1
        Update MUXing
        Power-up B1
      
      Run soc_dapm_mux_update_power for MUX2
        Power-down A2
        (Update MUXing)
        Power-up B2
      
      Note that the second 'Update Muxing' is a no-op, since the register was already
      updated.
      
      While the preferred order for avoiding pops and clicks should be:
      
      Run soc_dapm_mux_update_power for control
        Power-down A1
        Power-down A2
        Update MUXing
        Power-up B1
        Power-up B2
      
      This patch changes the behavior to the later by running the updates for all
      widgets that the control is attached to at the same time.
      
      The new code is also a bit simpler since callers of
      soc_dapm_{mux,muxer}_update_power don't have to loop over each widget anymore
      and neither do we need to keep track for which of the kcontrol's widgets the
      current update is.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      ce6cfaf1
  14. 14 6月, 2013 1 次提交
  15. 07 6月, 2013 1 次提交
  16. 13 5月, 2013 1 次提交
  17. 08 3月, 2013 1 次提交
  18. 25 2月, 2013 1 次提交
    • M
      ASoC: dapm: Fix handling of loops · 8af294b4
      Mark Brown 提交于
      Currently if a path loops back on itself we correctly skip over it to
      avoid going into an infinite loop but this causes us to ignore the need
      to power up the path as we don't count the loop for the purposes of
      counting inputs and outputs. This means that internal loopbacks within a
      device that have powered devices on them won't be powered up.
      
      Fix this by treating any path that is currently in the process of being
      recursed as having a single input or output so that it is counted for
      the purposes of power decisions.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
      8af294b4
  19. 26 9月, 2012 1 次提交
  20. 08 9月, 2012 1 次提交
  21. 06 9月, 2012 2 次提交
  22. 07 7月, 2012 1 次提交
  23. 03 6月, 2012 1 次提交
  24. 19 4月, 2012 1 次提交
  25. 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
  26. 04 4月, 2012 1 次提交
  27. 01 4月, 2012 5 次提交
  28. 16 3月, 2012 1 次提交
    • P
      device.h: audit and cleanup users in main include dir · 313162d0
      Paul Gortmaker 提交于
      The <linux/device.h> header includes a lot of stuff, and
      it in turn gets a lot of use just for the basic "struct device"
      which appears so often.
      
      Clean up the users as follows:
      
      1) For those headers only needing "struct device" as a pointer
      in fcn args, replace the include with exactly that.
      
      2) For headers not really using anything from device.h, simply
      delete the include altogether.
      
      3) For headers relying on getting device.h implicitly before
      being included themselves, now explicitly include device.h
      
      4) For files in which doing #1 or #2 uncovers an implicit
      dependency on some other header, fix by explicitly adding
      the required header(s).
      
      Any C files that were implicitly relying on device.h to be
      present have already been dealt with in advance.
      
      Total removals from #1 and #2: 51.  Total additions coming
      from #3: 9.  Total other implicit dependencies from #4: 7.
      
      As of 3.3-rc1, there were 110, so a net removal of 42 gives
      about a 38% reduction in device.h presence in include/*
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      313162d0