1. 03 9月, 2014 1 次提交
    • J
      ASoC: max98090: Add recovery for PLL lock failure · b8a3ee82
      Jarkko Nikula 提交于
      All MAX98090 input clocks MCLK, LRCLK and BCLK must be running and stable
      before powering on the codec in slave mode. Otherwise the PLL may not lock
      to LRCLK causing silence in playback and capture. How often that happens is
      somewhat hardware and clock configuration specific.
      
      Now if wanting to follow strictly this clocks must be active before
      powering the codec on requirement we should have a notification from DAI
      driver to codec driver when clocks are activated and take codec out of
      shutdown only after that. Plus take care of possible active bypass paths.
      
      However, when PLL unlock occurs, MAX98090 asserts the PLL Unlock Flag which
      can be configured as an IRQ source. This allows to workaround around the
      issue by toggling the codec power shortly in case of PLL lock failure.
      
      In order to prevent needlessly toggling codec power in case of short PLL
      unlocks at the beginning of stream this patch implements delayed activation
      for PLL unlock interrupt. Then workaround is run only when the PLL doesn't
      lock at all.
      
      Power toggling workaround for PLL unlock comes originally from
      Liam Girdwood <liam.r.girdwood@linux.intel.com> and delayed activation from
      me.
      Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      b8a3ee82
  2. 07 7月, 2014 1 次提交
  3. 05 7月, 2014 2 次提交
  4. 01 7月, 2014 1 次提交
  5. 19 6月, 2014 2 次提交
  6. 26 5月, 2014 2 次提交
  7. 17 5月, 2014 7 次提交
  8. 15 4月, 2014 3 次提交
  9. 01 4月, 2014 1 次提交
  10. 15 3月, 2014 1 次提交
  11. 11 3月, 2014 1 次提交
  12. 01 3月, 2014 1 次提交
  13. 20 2月, 2014 1 次提交
  14. 16 2月, 2014 1 次提交
  15. 13 2月, 2014 1 次提交
  16. 13 1月, 2014 1 次提交
  17. 19 7月, 2013 1 次提交
  18. 06 6月, 2013 1 次提交
  19. 20 5月, 2013 1 次提交
    • A
      ASoC: max98090: request IRQF_ONESHOT interrupt · 3d15aacb
      Andrew Bresticker 提交于
      request_threaded_irq() rejects calls which both do not specify a handler
      (indicating that the primary IRQ handler should be used) and do not set
      IRQF_ONESHOT because the combination is unsafe with level-triggered
      interrupts.  It is safe in this case, though, since max98090 IRQs are
      edge-triggered and the interrupts aren't ACK'ed until the codec's IRQ
      status register is read.  Because of this, an IRQF_ONESHOT interrupt
      doesn't really make a difference, but request one anyway in order to make
      request_threaded_irq() happy.
      Signed-off-by: NAndrew Bresticker <abrestic@chromium.org>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      3d15aacb
  20. 17 5月, 2013 1 次提交
  21. 20 3月, 2013 1 次提交
  22. 04 3月, 2013 5 次提交
  23. 07 2月, 2013 2 次提交
  24. 21 11月, 2012 1 次提交