1. 20 2月, 2014 1 次提交
  2. 19 2月, 2014 1 次提交
  3. 18 1月, 2014 1 次提交
  4. 15 1月, 2014 1 次提交
  5. 08 1月, 2014 1 次提交
  6. 17 12月, 2013 1 次提交
  7. 08 11月, 2013 2 次提交
  8. 29 10月, 2013 2 次提交
  9. 10 10月, 2013 2 次提交
    • M
      ASoC: dapm: Run clock and regulator events separately to other supplies · 1dd275b6
      Mark Brown 提交于
      In order to avoid trying to use an external clock or supply for an
      on-chip supply prior to it being enabled move the clock and regulator
      supply events to a separate step in DAPM sequencing from normal supply
      events.
      
      This should have minimal practical impact since these widgets are sorted
      using SND_SOC_NOPM which is a negative value and hence sorted
      separately to any real register writes, though it may be relevant if
      supplies have event callbacks only.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      1dd275b6
    • M
      ASoC: dapm: Use async I/O for DAPM sequences · eb270e98
      Mark Brown 提交于
      Within a DAPM sequence we normally don't care about when exactly a register
      write has completed so long as they happen in the order we requested. This
      means that we can issue most of the writes we do asynchronously which
      should maximise the ability of the underlying frameworks to keep the
      hardware busy, providing a small performance improvement on some systems.
      
      We currently ensure that all writes are completed both when changing to a
      different device and when calling into the regulator and clock frameworks.
      This should ensure that the previous ordering is maintained.
      
      We also ensure that writes are completed prior to calling into widget
      event functions since some event functions implement delays.  This
      should be improved in future so that widgets can disable this sync in
      order to add extra writes.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      eb270e98
  10. 07 10月, 2013 2 次提交
  11. 30 8月, 2013 1 次提交
  12. 27 8月, 2013 2 次提交
  13. 13 8月, 2013 2 次提交
  14. 06 8月, 2013 1 次提交
    • R
      ASoC: avoid duplicated DAI routes · 19c2c5f5
      Russell King 提交于
      ASoC automatically creates snd_soc_dapm_dai_in and snd_soc_dapm_dai_out
      widgets for DAI drivers, and adds them to the list.  Later on, ASoC
      creates automatic routes between these widgets and a widget with a
      stream name.
      
      We look for a snd_soc_dapm_dai_in or snd_soc_dapm_dai_out widget, and
      use this to obtain the DAI structure.  We then scan all widgets for
      any with a stream name refering to either the capture or the playback
      stream, and create routes.
      
      If you have both a snd_soc_dapm_dai_in and a snd_soc_dapm_dai_out
      referring to the same DAI structure, this ends up creating one set of
      routes for the DAI for the snd_soc_dapm_dai_in widget, and a duplicated
      set of routes for the snd_soc_dapm_dai_out widget.
      
      Fix this by checking that the stream name for the widget matches the
      DAI widget name.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      19c2c5f5
  15. 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
  16. 02 8月, 2013 2 次提交
  17. 01 8月, 2013 1 次提交
  18. 31 7月, 2013 1 次提交
  19. 30 7月, 2013 9 次提交
  20. 24 7月, 2013 5 次提交
    • 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
    • L
      ASoC: dapm: Pass snd_soc_card directly to soc_dpcm_runtime_update() · c3f48ae6
      Lars-Peter Clausen 提交于
      soc_dpcm_runtime_update() operates on a ASoC card as a whole. Currently it takes
      a snd_soc_dapm_widget as its only parameter though. The widget is then used to
      look up the card and is otherwise unused. This patch changes the function to
      take a pointer to the card directly. This makes it possible to to call
      soc_dpcm_runtime_update() for updates which are not related to one specific
      widget.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      c3f48ae6
    • M
      ASoC: dapm: Use generic power check for everything except DAIs · 63c69a6e
      Mark Brown 提交于
      As noticed by Lars-Peter Clausen since the move to using widgets to hook
      into the DAIs we no longer directly manage the power of AIF or DAC/ADC
      widgets from the stream integration so they can just use the generic power
      checks instead of the custom stream integration ones they currently do.
      Signed-off-by: NMark Brown <broonie@linaro.org>
      63c69a6e
    • L
      ASoC: dapm: Fix return value of snd_soc_dapm_put_{volsw,enum_virt}() · 56a67834
      Lars-Peter Clausen 提交于
      The ALSA core expect the put callback of a control to return 1 if the value of
      the control changed and 0 if it did not. Both snd_soc_dapm_put_volsw() and
      snd_soc_dapm_put_enum_virt() currently always returns 0. For both functions we
      already have a 'change' variable which either contains 1 or 0 depending on
      whether the value has changed or not, so just return that.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      56a67834
  21. 23 7月, 2013 1 次提交