1. 20 5月, 2014 1 次提交
  2. 19 3月, 2014 1 次提交
  3. 25 2月, 2014 1 次提交
  4. 15 2月, 2014 1 次提交
  5. 11 2月, 2014 1 次提交
  6. 09 1月, 2014 1 次提交
  7. 17 12月, 2013 1 次提交
  8. 28 11月, 2013 2 次提交
  9. 31 10月, 2013 1 次提交
    • R
      DMA-API: sound: fix dma mask handling in a lot of drivers · c9bd5e69
      Russell King 提交于
      This code sequence is unsafe in modules:
      
      static u64 mask = DMA_BIT_MASK(something);
      ...
      	if (!dev->dma_mask)
      		dev->dma_mask = &mask;
      
      as if a module is reloaded, the mask will be pointing at the original
      module's mask address, and this can lead to oopses.  Moreover, they
      all follow this with:
      
      	if (!dev->coherent_dma_mask)
      		dev->coherent_dma_mask = mask;
      
      where 'mask' is the same value as the statically defined mask, and this
      bypasses the architecture's check on whether the DMA mask is possible.
      
      Fix these issues by using the new dma_coerce_coherent_and_mask()
      function.
      Acked-by: NMark Brown <broonie@linaro.org>
      Acked-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c9bd5e69
  10. 25 10月, 2013 1 次提交
  11. 22 10月, 2013 1 次提交
  12. 21 10月, 2013 1 次提交
  13. 01 10月, 2013 1 次提交
  14. 26 9月, 2013 1 次提交
  15. 21 9月, 2013 1 次提交
  16. 17 9月, 2013 1 次提交
    • R
      ASoC: kirkwood-dma: remove IEC958_SUBFRAME formats · b51600c0
      Russell King 提交于
      The Audio block does not support IEC958 subframes as formatted by
      ALSA: they're very close, but not close enough.  The formats differ
      by:
      
      3  2   2   2   1   1
      1  8   4   0   6   2   8   4   0
      PCUVDDDDDDDDDDDDDDDD....AAAATTTT - IEC958 subframe
      PCUV0000........DDDDDDDDDDDDDDDD - Audio block format
      
      Where P = parity, C = channel status, U = user data, V = validity,
      D = sample data, A = aux, T = preamble.  As can be seen, the
      position of the sample is in a different position, and the audio
      block does not have the aux or preamble bits.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      b51600c0
  17. 06 9月, 2013 1 次提交
    • T
      ASoC: kirkwood: change the compatible string of the kirkwood-i2s driver · d098b2f0
      Thomas Petazzoni 提交于
      The compatible string of the kirkwood-i2s driver was chosen as
      "marvell,mvebu-audio". Using such a compatible string is not a good
      idea, since "mvebu" is the name of a large family of SOCs, in which
      new, unknown SOCs will be coming in the future. It is therefore
      impossible to know what will be evolutions of this hardware block in
      the next generations of the SOCs. For this reason, the recommandation
      for compatible strings of on-SOCs devices has always been to use the
      name of the oldest SOC that has the hardware block. New SOCs that have
      an exactly compatible hardware block can reference it using the same
      compatible string. See [1], [2] and [3] for various cases were this
      suggestion was made, including from Rob Herring, a Device Tree binding
      maintainer.
      
      As an example, there are already small differences between current
      generations:
      
       * On Kirkwood, only one interrupt is used for audio.
       * On Dove, two interrupts are used, one for audio data and one for
         error reporting.
      
      In the near future, I'll be adding audio support to Armada 370, which
      allows has the same hardware block (but maybe with minor variants).
      
      Therefore, this patch changes the driver to accept
      "marvell,kirkwood-audio" and "marvell,dove-audio" as compatible
      strings instead of the too-generic "marvell,mvebu-audio". The reason
      for the two different compatible strings is the difference in the
      number of interrupts used by the two SOCs for audio.
      
      This Device Tree binding has never been part of a Linux kernel stable
      release so far, so it can be changed now without breaking backward
      compatibility.
      
      [1] http://lists.infradead.org/pipermail/linux-mtd/2012-March/040417.html
      [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/161065.html
      [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2012-March/087702.htmlSigned-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      d098b2f0
  18. 28 8月, 2013 1 次提交
  19. 23 8月, 2013 1 次提交
  20. 06 8月, 2013 4 次提交
  21. 05 8月, 2013 1 次提交
  22. 16 7月, 2013 3 次提交
  23. 15 7月, 2013 3 次提交
  24. 18 5月, 2013 1 次提交
  25. 15 5月, 2013 1 次提交
  26. 27 3月, 2013 1 次提交
  27. 23 1月, 2013 1 次提交
  28. 09 12月, 2012 1 次提交
  29. 21 11月, 2012 4 次提交