1. 10 9月, 2009 1 次提交
  2. 09 9月, 2009 1 次提交
    • M
      ASoC: Allow per-route connectedness checks for supplies · 215edda3
      Mark Brown 提交于
      Some chips with complex internal supply (particularly clocking)
      arragements may have multiple options for some of the supply
      connections. Since these don't affect user-visible audio routing
      the expectation would be that they would be managed automatically
      by one of the drivers.
      
      Support these users by allowing routes to have a connected function
      which is queried before the connectedness of the path is checked as
      normal. Currently this is only done for supplies, other widgets
      could be supported but are not currently since the expectation for
      them is that audio routing will be under the control of userspace.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      215edda3
  3. 07 9月, 2009 1 次提交
  4. 06 9月, 2009 1 次提交
  5. 03 9月, 2009 1 次提交
  6. 01 9月, 2009 2 次提交
  7. 29 8月, 2009 1 次提交
    • J
      ASoC: OMAP: Add functionality to set CLKR and FSR sources in McBSP DAI · d2c0bdaa
      Jarkko Nikula 提交于
      The McBSP1 port in OMAP3 processors (I believe OMAP2 too but I don't have
      specifications to check it) have additional CLKR and FSR pins for McBSP1
      receiver. Reset default is that receiver is using bit clock and frame
      sync signal from those pins but it is possible to configure to use
      also CLKX and FSX pins as well. In fact, other McBSP ports are doing that
      internally that transmitter and receiver share the CLKX and FSX.
      
      Add functionaly that machine drivers can set the CLKR and FSR sources by
      using the snd_soc_dai_set_sysclk.
      
      Thanks to "Aggarwal, Anuj" <anuj.aggarwal@ti.com> for reporting the issue.
      Signed-off-by: NJarkko Nikula <jhnikula@gmail.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      d2c0bdaa
  8. 28 8月, 2009 1 次提交
  9. 26 8月, 2009 5 次提交
  10. 25 8月, 2009 4 次提交
    • S
      ASoC: S3C platform: Fix s3c2410_dma_started() called at improper time · faf907c7
      Shine Liu 提交于
      s3c24xx dma has the auto reload feature, when the the trnasfer is done,
      CURR_TC(DSTAT[19:0], current value of transfer count) reaches 0, and DMA
      ACK becomes 1, and then, TC(DCON[19:0]) will be loaded into CURR_TC. So
      the transmission is repeated.
      
      IRQ is issued while auto reload occurs. We change the DISRC and
      DCON[19:0] in the ISR, but at this time, the auto reload has been
      performed already. The first block is being re-transmitted by the DMA.
      
      So we need rewrite the DISRC and DCON[19:0] for the next block
      immediatly after the this block has been started to be transported.
      
      The function s3c2410_dma_started() is for this perpose, which is called
      in the form of "s3c2410_dma_ctrl(prtd->params->channel,
      S3C2410_DMAOP_STARTED);" in s3c24xx_pcm_trigger().
      
      But it is not correct. DMA transmission won't start until DMA REQ signal
      arrived, it is the time s3c24xx_snd_txctrl(1) or s3c24xx_snd_rxctrl(1)
      is called in s3c24xx_i2s_trigger().
      
      In the current framework, s3c24xx_pcm_trigger() is always called before
      s3c24xx_pcm_trigger(). So the s3c2410_dma_started() should be called in
      s3c24xx_pcm_trigger() after s3c24xx_snd_txctrl(1) or
      s3c24xx_snd_rxctrl(1) is called in this function.
      
      However, s3c2410_dma_started() is dma related, to call this function we
      should provide the channel number, which is given by
      substream->runtime->private_data->params->channel. The private_data
      points to a struct s3c24xx_runtime_data object, which is define in
      s3c24xx_pcm.c, so s3c2410_dma_started() can't be called in s3c24xx_i2s.c
      
      Fix this by moving the call to signal the DMA started to the DAI
      drivers.
      Signed-off-by: NShine Liu <liuxian@redflag-linux.com>
      Signed-off-by: NShine Liu <shinel@foxmail.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      faf907c7
    • J
      ARM: OMAP: McBSP: Merge two functions into omap_mcbsp_start/_stop · d09a2afc
      Jarkko Nikula 提交于
      Functionality of functions omap_mcbsp_xmit_enable and omap_mcbsp_recv_enable
      can be merged into omap_mcbsp_start and omap_mcbsp_stop since API of
      those omap_mcbsp_start and omap_mcbsp_stop was changed recently allowing
      to start and stop individually the transmitter and receiver.
      
      This cleans up the code in arch/arm/plat-omap/mcbsp.c and in
      sound/soc/omap/omap-mcbsp.c which was the only user for those removed
      functions.
      Signed-off-by: NJarkko Nikula <jhnikula@gmail.com>
      Acked-by: NEero Nurkkala <ext-eero.nurkkala@nokia.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      d09a2afc
    • J
      ASoC: OMAP: Fix setup of XCCR and RCCR registers in McBSP DAI · 32080af7
      Jarkko Nikula 提交于
      Commit ca6e2ce0 is setting up few XCCR and
      RCCR bits for I2S and DPS_A formats. Part of the bits are already set
      for all formats and I believe that XDISABLE and RDISABLE bits are
      format independent.
      
      As XCCR and RCCR are found only from OMAP2430 and OMAP34xx, I move setup
      of XDISABLE and RDISABLE to where those cpu's are tested and remove format
      dependent part for simplicity.
      Signed-off-by: NJarkko Nikula <jhnikula@gmail.com>
      Acked-by: NEero Nurkkala <ext-eero.nurkkala@nokia.com>
      Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      32080af7
    • M
      ASoC: Select core DMA when building for S3C64xx · 239a22aa
      Mark Brown 提交于
      Ensure that the core DMA support is available when building for
      S3C64xx.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      239a22aa
  11. 24 8月, 2009 3 次提交
  12. 23 8月, 2009 1 次提交
  13. 22 8月, 2009 1 次提交
    • M
      ASoC: Add DAPM widget power decision debugfs files · 79fb9387
      Mark Brown 提交于
      Currently when built with DEBUG DAPM will dump information about
      the power state decisions it is taking for each widget to dmesg.
      This isn't an ideal way of getting the information - it requires
      a kernel build to turn it on and off and for large hub CODECs the
      volume of information is so large as to be illegible. When the
      output goes to the console it can also cause a noticable impact
      on performance simply to print it out.
      
      Improve the situation by adding a dapm directory to our debugfs
      tree containing a file per widget with the same information in
      it. This still requires a decision to build with debugfs support
      but is easier to navigate and much less intrusive.
      
      In addition to the previously displayed information active streams
      are also shown in these files.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      79fb9387
  14. 21 8月, 2009 14 次提交
  15. 19 8月, 2009 1 次提交
  16. 18 8月, 2009 2 次提交
    • M
      ASoC: WM8993 digital mixing support · 59ae07a5
      Mark Brown 提交于
      The WM8993 provides digital sidetone paths and also allows each
      channel on the audio interface to be routed separtately to the
      DACs and ADCs.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      59ae07a5
    • M
      ASoC: Add input and output AIF widgets · 010ff262
      Mark Brown 提交于
      Currently DAPM interfaces with the audio streams to and from the
      processor at the DAC and ADC widgets. As the digital capabilities
      of parts increases this is becoming a less and less able to meet
      the needs of parts.
      
      To meet the needs of these devices create new widgets interfacing
      with the TDM bus but not integrated into any other functionality.
      Audio can then be routed to and from these widgets using existing
      routing widgets.
      
      A slot number is provided in the definition but this is currently
      not used yet. This is intended to support devices which can use
      more than one TDM slot on a single interface.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      010ff262