1. 06 10月, 2012 1 次提交
  2. 11 3月, 2012 1 次提交
  3. 25 2月, 2012 5 次提交
  4. 21 1月, 2012 1 次提交
  5. 05 1月, 2012 1 次提交
  6. 03 12月, 2011 1 次提交
  7. 17 9月, 2011 1 次提交
    • I
      ARM: davinci: Explicitly set channel controllers' default queues · f23fe857
      Ido Yariv 提交于
      Davinci platforms may define a default queue for each channel
      controller. If one is not defined, the default queue is set to EVENTQ_1.
      However, there's no way to distinguish between an unset default queue to
      one that is set to EVENTQ_0, as EVENTQ_0 = 0.
      
      Explicitly specify the default queue for all channel controllers on all
      Davinci platforms to EVENTQ_1, and don't overwrite it in the EDMA probe
      function.
      
      One exception is the DA850 board, for which EVENTQ_1 is not a valid
      option for its second channel controller. Use EVENTQ_0 instead for that
      channel controller.
      Signed-off-by: NIdo Yariv <ido@wizery.com>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      f23fe857
  8. 22 8月, 2011 1 次提交
  9. 27 4月, 2011 1 次提交
  10. 31 3月, 2011 1 次提交
  11. 18 11月, 2010 1 次提交
    • C
      ASoC: davinci: fixes for multi-component · bedad0ca
      Chris Paulson-Ellis 提交于
      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: NChris Paulson-Ellis <chris@edesix.com>
      Acked-by: NLiam Girdwood <lrg@slimlogic.co.uk>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      bedad0ca
  12. 25 9月, 2010 1 次提交
  13. 24 9月, 2010 2 次提交
  14. 06 8月, 2010 1 次提交
  15. 14 5月, 2010 5 次提交
  16. 07 5月, 2010 4 次提交
  17. 27 2月, 2010 1 次提交
  18. 05 2月, 2010 2 次提交
  19. 26 11月, 2009 2 次提交
  20. 17 9月, 2009 1 次提交
  21. 26 8月, 2009 5 次提交
  22. 29 5月, 2009 1 次提交
    • D
      davinci: soc-specific SRAM setup · 0d04eb47
      David Brownell 提交于
      Package on-chip SRAM.  It's always accessible from the ARM, so
      set up a standardized virtual address mapping into a 128 KiB
      area that's reserved for platform use.
      
      In some cases (dm6467) the physical addresses used for EDMA are
      not the same as the ones used by the ARM ... so record that info
      separately in the SOC data, for chips (unlike the OMAP-L137)
      where SRAM may be used with EDMA.
      
      Other blocks of SRAM, such as the ETB buffer or DSP L1/L2 RAM,
      may be unused/available on some system.  They are ignored here.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
      0d04eb47