1. 23 Nov, 2010 4 commits
  2. 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>
  3. 14 Nov, 2010 1 commit
  4. 13 Nov, 2010 3 commits
  5. 12 Nov, 2010 1 commit
  6. 10 Nov, 2010 2 commits
  7. 08 Nov, 2010 1 commit
  8. 07 Nov, 2010 9 commits
  9. 05 Nov, 2010 5 commits
  10. 03 Nov, 2010 5 commits
  11. 02 Nov, 2010 1 commit
  12. 01 Nov, 2010 1 commit
    • Paul Mundt's avatar
      ARM: mach-shmobile: include drivers/sh/Kconfig · be8cb585
      Paul Mundt authored
      Many of the config bit are presently duplicated between the platforms,
      which will gradually cleaned up through centralization. For the moment we
      expose some new INTC features through drivers/sh/Kconfig that the ARM
      platforms presently don't enable, so make it generally available.
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
  13. 31 Oct, 2010 3 commits
  14. 29 Oct, 2010 3 commits