1. 30 6月, 2017 2 次提交
  2. 10 6月, 2017 1 次提交
  3. 09 6月, 2017 1 次提交
  4. 08 6月, 2017 3 次提交
  5. 19 4月, 2017 1 次提交
  6. 12 4月, 2017 1 次提交
  7. 28 2月, 2017 1 次提交
  8. 18 1月, 2017 1 次提交
    • L
      ASoC: dapm: handle probe deferrals · 37e1df8c
      Linus Walleij 提交于
      This starts to handle probe deferrals on regulators and clocks
      on the ASoC DAPM.
      
      I came to this patch after audio stopped working on Ux500 ages
      ago and I finally looked into it to see what is wrong. I had
      messages like this in the console since a while back:
      
      ab8500-codec.0: ASoC: Failed to request audioclk: -517
      ab8500-codec.0: ASoC: Failed to create DAPM control audioclk
      ab8500-codec.0: Failed to create new controls -12
      snd-soc-mop500.0: ASoC: failed to instantiate card -12
      snd-soc-mop500.0: Error: snd_soc_register_card failed (-12)!
      snd-soc-mop500: probe of snd-soc-mop500.0 failed with error -12
      
      Apparently because the widget table for the codec looks like
      this (sound/soc/codecs/ab8500-codec.c):
      
      static const struct snd_soc_dapm_widget ab8500_dapm_widgets[] = {
      
              /* Clocks */
              SND_SOC_DAPM_CLOCK_SUPPLY("audioclk"),
      
              /* Regulators */
              SND_SOC_DAPM_REGULATOR_SUPPLY("V-AUD", 0, 0),
              SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC1", 0, 0),
              SND_SOC_DAPM_REGULATOR_SUPPLY("V-AMIC2", 0, 0),
              SND_SOC_DAPM_REGULATOR_SUPPLY("V-DMIC", 0, 0),
      
      So when we call snd_soc_register_codec() and any of these widgets
      get a deferred probe we do not get an -EPROBE_DEFER (-517) back as
      we should and instead we just fail. Apparently the code assumes
      that clocks and regulators must be available at this point and
      not defer.
      
      After this patch it rather looks like this:
      
      ab8500-codec.0: Failed to create new controls -517
      snd-soc-mop500.0: ASoC: failed to instantiate card -517
      snd-soc-mop500.0: Error: snd_soc_register_card failed (-517)!
      (...)
      abx500-clk.0: registered clocks for ab850x
      snd-soc-mop500.0: ab8500-codec-dai.0 <-> ux500-msp-i2s.1 mapping ok
      snd-soc-mop500.0: ab8500-codec-dai.1 <-> ux500-msp-i2s.3 mapping ok
      
      I'm pretty happy about the patch as it it, but I'm a bit
      uncertain on how to proceed: there are a lot of users of the
      external functions snd_soc_dapm_new_control() (111 sites)
      and that will now return an occassional error pointer, which
      is not handled in the calling sites.
      
      I want an indication from the maintainers whether I should just
      go in and augment all these call sites, or if deferred probe
      is frowned upon when it leads to this much overhead.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      37e1df8c
  9. 13 1月, 2017 1 次提交
  10. 15 12月, 2016 2 次提交
  11. 12 12月, 2016 1 次提交
  12. 05 12月, 2016 2 次提交
  13. 09 11月, 2016 1 次提交
  14. 05 11月, 2016 5 次提交
  15. 04 11月, 2016 4 次提交
  16. 29 10月, 2016 1 次提交
  17. 23 8月, 2016 1 次提交
  18. 11 8月, 2016 1 次提交
  19. 08 8月, 2016 1 次提交
  20. 05 5月, 2016 1 次提交
  21. 28 4月, 2016 2 次提交
  22. 21 4月, 2016 2 次提交
  23. 22 2月, 2016 2 次提交
  24. 16 2月, 2016 2 次提交