1. 09 Apr, 2015 1 commit
  2. 04 Nov, 2014 1 commit
    • Takashi Iwai's avatar
      ASoC: dpcm: Fix race between FE/BE updates and trigger · ea9d0d77
      Takashi Iwai authored
      DPCM can update the FE/BE connection states totally asynchronously
      from the FE's PCM state.  Most of FE/BE state changes are protected by
      mutex, so that they won't race, but there are still some actions that
      are uncovered.  For example, suppose to switch a BE while a FE's
      stream is running.  This would call soc_dpcm_runtime_update(), which
      sets FE's runtime_update flag, then sets up and starts BEs, and clears
      FE's runtime_update flag again.
      
      When a device emits XRUN during this operation, the PCM core triggers
      snd_pcm_stop(XRUN).  Since the trigger action is an atomic ops, this
      isn't blocked by the mutex, thus it kicks off DPCM's trigger action.
      It eventually updates and clears FE's runtime_update flag while
      soc_dpcm_runtime_update() is running concurrently, and it results in
      confusion.
      
      Usually, for avoiding such a race, we take a lock.  There is a PCM
      stream lock for that purpose.  However, as already mentioned, the
      trigger action is atomic, and we can't take the lock for the whole
      soc_dpcm_runtime_update() or other operations that include the lengthy
      jobs like hw_params or prepare.
      
      This patch provides an alternative solution.  This adds a way to defer
      the conflicting trigger callback to be executed at the end of FE/BE
      state changes.  For doing it, two things are introduced:
      
      - Each runtime_update state change of FEs is protected via PCM stream
        lock.
      - The FE's trigger callback checks the runtime_update flag.  If it's
        not set, the trigger action is executed there.  If set, mark the
        pending trigger action and returns immediately.
      - At the exit of runtime_update state change, it checks whether the
        pending trigger is present.  If yes, it executes the trigger action
        at this point.
      Reported-and-tested-by: default avatarQiao Zhou <zhouqiao@marvell.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Acked-by: default avatarLiam Girdwood <liam.r.girdwood@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      ea9d0d77
  3. 17 Jan, 2014 1 commit
  4. 24 Jul, 2013 1 commit
  5. 26 Apr, 2012 4 commits
    • Liam Girdwood's avatar
      ASoC: dpcm: Add bespoke trigger() · 07bf84aa
      Liam Girdwood authored
      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: default avatarLiam Girdwood <lrg@ti.com>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      07bf84aa
    • Liam Girdwood's avatar
      ASoC: dpcm: Add runtime dynamic route update · 618dae11
      Liam Girdwood authored
      This patch allows DPCM to dynamically alter the FE to BE PCM links
      at runtime based on mixer setting updates. DAPM is looked up after
      every mixer update and we perform a DPCM runtime update if the
      mixer has a change of value.
      
      This patchs adds/changes the following :-
      
       o Adds DPCM runtime update core.
       o Changes soc_dapm_mixer_update_power() and soc_dapm_mux_update_power()
         to return if a change has occured rather than 0. No other users check
         atm.
      Signed-off-by: default avatarLiam Girdwood <lrg@ti.com>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      618dae11
    • Liam Girdwood's avatar
      ASoC: dpcm: Add debugFS support for DPCM · f86dcef8
      Liam Girdwood authored
      Add debugFS files for DPCM link management information.
      Signed-off-by: default avatarLiam Girdwood <lrg@ti.com>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      f86dcef8
    • Liam Girdwood's avatar
      ASoC: dpcm: Add Dynamic PCM core operations. · 01d7584c
      Liam Girdwood authored
      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: default avatarLiam Girdwood <lrg@ti.com>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      01d7584c