1. 03 May, 2013 1 commit
  2. 30 Apr, 2013 1 commit
  3. 23 Apr, 2013 2 commits
  4. 05 Apr, 2013 2 commits
  5. 26 Mar, 2013 1 commit
  6. 12 Mar, 2013 1 commit
  7. 04 Mar, 2013 1 commit
    • Michal Bachraty's avatar
      ASoC: davinci-mcasp: Add support for multichannel playback · 2952b27e
      Michal Bachraty authored
      Davinci McASP has support for I2S multichannel playback.
      For I2S playback/receive, each serializer is capable to play 2 channels
      (L/R) audio data.Serializer function (Playback-receive-none) is configured
      in DT, depending on hardware specification. It is possible to play less
      channels than configured in DT. For that purpose,only specific number of
      active serializers are enabled. McASP FIFO need to have DMA transfer Bcnt
      set to number of enabled serializers, otherwise no data are transfered to
      McASP and Alsa generates "DMA/IRQ playback write error (DMA or IRQ trouble?)"
      error. For TDM mode, McASP is capable to play or receive 32 channels for one
      serializer. McAsp has support for max 16 serializer, therefore max channels
      is 32 * 8.
      Signed-off-by: default avatarMichal Bachraty <michal.bachraty@streamunlimited.com>
      Tested-by: default avatarDaniel Mack <zonque@gmail.com>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
  8. 27 Jan, 2013 1 commit
  9. 07 Dec, 2012 3 commits
  10. 22 Oct, 2012 1 commit
  11. 15 Oct, 2012 5 commits
  12. 06 Sep, 2012 1 commit
  13. 27 Aug, 2012 2 commits
  14. 09 Aug, 2012 2 commits
  15. 02 Jan, 2012 1 commit
    • Julia Lawall's avatar
      ASoC: davinci-mcasp.c: use devm_ functions · 96d31e2b
      Julia Lawall authored
      The various devm_ functions allocate memory that is released when a driver
      detaches.  This patch uses devm_kzalloc, devm_request_mem_region and
      devm_ioremap for data that is allocated in the probe function of a platform
      device and is only freed in the remove function.
      In this case, the original code did not contain a call to iounmap, nor does
      one appear anywhere else in the file.  I have assumed that it is safe to
      use devm_ioremap for the allocation in any case.
      Signed-off-by: default avatarJulia Lawall <julia.lawall@lip6.fr>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
  16. 25 Nov, 2011 1 commit
  17. 23 Nov, 2011 1 commit
    • Lars-Peter Clausen's avatar
      ASoC: Constify snd_soc_dai_ops structs · 85e7652d
      Lars-Peter Clausen authored
      Commit 1ee46ebd("ASoC: Make the DAI ops constant in the DAI structure")
      introduced the possibility to have constant DAI ops structures, yet this is
      barley used in both existing drivers and also new drivers being submitted,
      although none of them modifies its DAI ops structure. The later is not
      surprising since existing drivers are often used as templates for new drivers.
      So this patch just constifies all existing snd_soc_dai_ops structs to eliminate
      the issue altogether.
      The patch was generated with the following coccinelle semantic patch:
      // <smpl>
      identifier ops;
      -struct snd_soc_dai_ops ops =
      +const struct snd_soc_dai_ops ops =
      { ... };
      // </smpl>
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
  18. 29 Aug, 2011 1 commit
  19. 19 May, 2011 1 commit
  20. 26 Apr, 2011 4 commits
  21. 09 Feb, 2011 3 commits
  22. 17 Nov, 2010 1 commit
    • Chris Paulson-Ellis's avatar
      ASoC: davinci: fixes for multi-component · bedad0ca
      Chris Paulson-Ellis authored
      Multi-component commit f0fba2ad broke a few things which this patch should
      fix. Tested on the DM355 EVM. I've been as careful as I can, but it would be
      good if those with access to other Davinci boards could test.
      The multi-component commit put the initialisation of
      snd_soc_dai.[capture|playback]_dma_data into snd_soc_dai_ops.hw_params of the
      McBSP, McASP & VCIF drivers (davinci-i2s.c, davinci-mcasp.c & davinci-vcif.c).
      The initialisation had to be moved from the probe function in these drivers
      because davinci_*_dai changed from snd_soc_dai to snd_soc_dai_driver.
      Unfortunately, the DMA params pointer is needed by davinci_pcm_open (in
      davinci-pcm.c) before hw_params is called. I have moved the initialisation to
      a new snd_soc_dai_ops.startup function in each of these drivers. This fix
      indicates that all platforms that use davinci-pcm must have been broken and
      need to test with this fix.
      The multi-component commit also changed the McBSP driver name from
      "davinci-asp" to "davinci-i2s" in davinci-i2s.c without updating the board
      level references to the driver name. This change is understandable, as there
      is a similarly named "davinci-mcasp" driver in davinci-mcasp.c.
      There is probably no 'correct' name for this driver. The DM6446 datasheet
      calls it the "ASP" and describes it as a "specialised McBSP". The DM355
      datasheet calls it the "ASP" and describes it as a "specialised ASP". The
      DM365 datasheet calls it the "McBSP". Rather than fix this problem by
      reverting to "davinci-asp", I've elected to avoid future confusion with the
      "davinci-mcasp" driver by changing it to "davinci-mcbsp", which is also
      consistent with the names of the functions in the driver. There are other
      fixes required, so it was never going to be as simple as a revert anyway.
      The DM365 only has one McBSP port (of the McBSP platforms, only the DM355 has
      2 ports), so I've changed the the id of the platform_device from 0 to -1.
      In davinci-evm.c, the DM6446 EVM can no longer share a snd_soc_dai_link
      structure with the DM355 EVM as they use different cpu DAI names (the DM355
      has 2 ports and the EVM uses the second port, but the DM6446 only has 1 port).
      This also means that the 2 boards need different snd_soc_card structures.
      The codec_name entries in davinci-evm.c didn't match the i2c ids in the board
      files. I have only checked and fixed the details of the names used for the
      McBSP based platforms. Someone with a McASP based platform (eg DA8xx) should
      check the others.
      Signed-off-by: default avatarChris Paulson-Ellis <chris@edesix.com>
      Acked-by: default avatarLiam Girdwood <lrg@slimlogic.co.uk>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
  23. 18 Oct, 2010 1 commit
  24. 12 Aug, 2010 1 commit
    • Liam Girdwood's avatar
      ASoC: multi-component - ASoC Multi-Component Support · f0fba2ad
      Liam Girdwood authored
      This patch extends the ASoC API to allow sound cards to have more than one
      CODEC and more than one platform DMA controller. This is achieved by dividing
      some current ASoC structures that contain both driver data and device data into
      structures that only either contain device data or driver data. i.e.
       struct snd_soc_codec    --->  struct snd_soc_codec (device data)
                                +->  struct snd_soc_codec_driver (driver data)
       struct snd_soc_platform --->  struct snd_soc_platform (device data)
                                +->  struct snd_soc_platform_driver (driver data)
       struct snd_soc_dai      --->  struct snd_soc_dai (device data)
                                +->  struct snd_soc_dai_driver (driver data)
       struct snd_soc_device   --->  deleted
      This now allows ASoC to be more tightly aligned with the Linux driver model and
      also means that every ASoC codec, platform and (platform) DAI is a kernel
      device. ASoC component private data is now stored as device private data.
      The ASoC sound card struct snd_soc_card has also been updated to store lists
      of it's components rather than a pointer to a codec and platform. The PCM
      runtime struct soc_pcm_runtime now has pointers to all its components.
      This patch adds DAPM support for ASoC multi-component and removes struct
      snd_soc_socdev from DAPM core. All DAPM calls are now made on a card, codec
      or runtime PCM level basis rather than using snd_soc_socdev.
      Other notable multi-component changes:-
       * Stream operations now de-reference less structures.
       * close_delayed work() now runs on a DAI basis rather than looping all DAIs
         in a card.
       * PM suspend()/resume() operations can now handle N CODECs and Platforms
         per sound card.
       * Added soc_bind_dai_link() to bind the component devices to the sound card.
       * Added soc_dai_link_probe() and soc_dai_link_remove() to probe and remove
         DAI link components.
       * sysfs entries can now be registered per component per card.
       * snd_soc_new_pcms() functionailty rolled into dai_link_probe().
       * snd_soc_register_codec() now does all the codec list and mutex init.
      This patch changes the probe() and remove() of the CODEC drivers as follows:-
       o Make CODEC driver a platform driver
       o Moved all struct snd_soc_codec list, mutex, etc initialiasation to core.
       o Removed all static codec pointers (drivers now support > 1 codec dev)
       o snd_soc_register_pcms() now done by core.
       o snd_soc_register_dai() folded into snd_soc_register_codec().
      CS4270 portions:
      Acked-by: default avatarTimur Tabi <timur@freescale.com>
      Some TLV320aic23 and Cirrus platform fixes.
      Signed-off-by: default avatarRyan Mallon <ryan@bluewatersys.com>
      TI CODEC and OMAP fixes
      Signed-off-by: default avatarPeter Ujfalusi <peter.ujfalusi@nokia.com>
      Signed-off-by: default avatarJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
      Signed-off-by: default avatarJarkko Nikula <jhnikula@gmail.com>
      Samsung platform and misc fixes :-
      Signed-off-by: default avatarChanwoo Choi <cw00.choi@samsung.com>
      Signed-off-by: default avatarJoonyoung Shim <jy0922.shim@samsung.com>
      Signed-off-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Reviewed-by: default avatarJassi Brar <jassi.brar@samsung.com>
      Signed-off-by: default avatarSeungwhan Youn <sw.youn@samsung.com>
      MPC8610 and PPC fixes.
      Signed-off-by: default avatarTimur Tabi <timur@freescale.com>
      i.MX fixes and some core fixes.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      J4740 platform fixes:-
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      CC: Tony Lindgren <tony@atomide.com>
      CC: Nicolas Ferre <nicolas.ferre@atmel.com>
      CC: Kevin Hilman <khilman@deeprootsystems.com>
      CC: Sascha Hauer <s.hauer@pengutronix.de>
      CC: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
      CC: Kuninori Morimoto <morimoto.kuninori@renesas.com>
      CC: Daniel Gloeckner <dg@emlix.com>
      CC: Manuel Lauss <mano@roarinelk.homelinux.net>
      CC: Mike Frysinger <vapier.adi@gmail.com>
      CC: Arnaud Patard <apatard@mandriva.com>
      CC: Wan ZongShun <mcuos.com@gmail.com>
      Acked-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarLiam Girdwood <lrg@slimlogic.co.uk>
  25. 20 Jul, 2010 1 commit
    • Sekhar Nori's avatar
      ASoC: davinci: let platform data define edma queue numbers · 48519f0a
      Sekhar Nori authored
      Currently the EDMA queue to be used by for servicing ASP through
      internal RAM is fixed to EDMAQ_0 and that to service internal RAM
      from external RAM is fixed to EDMAQ_1.
      This may not be the desirable configuration on all platforms. For
      example, on DM365, queue 0 has large fifo size and is more suitable
      for video transfers. Having audio and video transfers on the same
      queue may lead to starvation on audio side.
      platform data as defined currently passes a queue number to the driver
      but that remains unused inside the driver.
      Fix this by defining one queue each for ASP and RAM transfers in the
      platform data and using it inside the driver.
      Since EDMAQ_0 maps to 0, thats the queue that will be used if
      the asp queue number is not initialized. None of the platforms
      currently utilize ping-pong transfers through internal RAM so that
      functionality remains unchanged too.
      This patch has been tested on DM644x and OMAP-L138 EVMs.
      Signed-off-by: default avatarSekhar Nori <nsekhar@ti.com>
      Acked-by: default avatarLiam Girdwood <lrg@slimlogic.co.uk>
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>