1. 06 3月, 2014 1 次提交
  2. 09 1月, 2014 1 次提交
  3. 26 12月, 2013 1 次提交
  4. 05 12月, 2013 1 次提交
  5. 21 11月, 2013 1 次提交
  6. 24 9月, 2013 1 次提交
  7. 22 8月, 2013 3 次提交
  8. 22 7月, 2013 1 次提交
  9. 24 6月, 2013 1 次提交
  10. 18 6月, 2013 1 次提交
  11. 15 4月, 2013 1 次提交
  12. 03 4月, 2013 1 次提交
  13. 20 3月, 2013 1 次提交
  14. 22 12月, 2012 1 次提交
  15. 19 11月, 2012 1 次提交
    • L
      ARM: davinci: dm644x: fix out range signal for ED · e37212aa
      Lad, Prabhakar 提交于
      Fix the video clock setting when custom timings are used with
      pclock <= 27MHz. Existing video clock selection uses PLL2 mode
      which results in a 54MHz clock whereas using the MXI mode results
      in a 27MHz clock (which is the one actually desired).
      
      This bug affects the Enhanced Definition (ED) support on DM644x.
      Without this patch, out-range signals errors are were observed on
      the TV when viewing ED. An out-of-range signal is often caused when
      the field rate is above the rate that the television will handle.
      Signed-off-by: NLad, Prabhakar <prabhakar.lad@ti.com>
      Signed-off-by: NManjunath Hadli <manjunath.hadli@ti.com>
      Cc: Sekhar Nori <nsekhar@ti.com>
      [nsekhar@ti.com: reword commit message based on on-list discussion]
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      e37212aa
  16. 27 10月, 2012 1 次提交
  17. 06 10月, 2012 1 次提交
  18. 28 8月, 2012 1 次提交
  19. 11 3月, 2012 1 次提交
  20. 25 2月, 2012 5 次提交
  21. 21 1月, 2012 1 次提交
  22. 05 1月, 2012 1 次提交
  23. 03 12月, 2011 1 次提交
  24. 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
  25. 22 8月, 2011 1 次提交
  26. 27 4月, 2011 1 次提交
  27. 31 3月, 2011 1 次提交
  28. 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
  29. 25 9月, 2010 1 次提交
  30. 24 9月, 2010 2 次提交
  31. 06 8月, 2010 1 次提交
  32. 14 5月, 2010 2 次提交