1. 02 6月, 2018 1 次提交
    • G
      ASoC: topology: Improve backwards compatibility with v4 topology files · ac9391da
      Guenter Roeck 提交于
      Commit dc31e741 ("ASoC: topology: ABI - Add the types for BE
      DAI") introduced sound topology files version 5. Initially, this
      change made the topology code incompatible with v4 topology files.
      Backwards compatibility with v4 configuration files was
      subsequently added with commit 288b8da7 ("ASoC: topology:
      Support topology file of ABI v4").
      
      Unfortunately, backwards compatibility was never fully implemented.
      
      First, the manifest size in (Skylake) v4 configuration files is set
      to 0, which causes manifest_new_ver() to bail out with error messages
      similar to the following.
      
      snd_soc_skl 0000:00:1f.3: ASoC: invalid manifest size
      snd_soc_skl 0000:00:1f.3: tplg component load failed-22
      snd_soc_skl 0000:00:1f.3: Failed to init topology!
      snd_soc_skl 0000:00:1f.3: ASoC: failed to probe component -22
      skl_n88l25_m98357a skl_n88l25_m98357a: ASoC: failed to instantiate card -22
      skl_n88l25_m98357a: probe of skl_n88l25_m98357a failed with error -22
      
      After this problem is fixed, the following error message is seen instead.
      
      snd_soc_skl 0000:00:1f.3: ASoC: old version of manifest
      snd_soc_skl 0000:00:1f.3: Invalid descriptor token 1093938482
      snd_soc_skl 0000:00:1f.3: ASoC: failed to load widget media0_in cpr 0
      snd_soc_skl 0000:00:1f.3: tPlg component load failed-22
      
      This message is seen because backwards compatibility for loading widgets
      was never implemented.
      
      The lack of audio support when running the upstream kernel on recent
      Chromebooks has been reported in various forums, and can be traced back
      to this problem. Attempts to fix the problem, usually by providing v5
      configuration files, were only partially successful.
      
      Let's implement backward compatibility properly to solve the problem
      for good.
      Signed-off-by: NGuenter Roeck <groeck@chromium.org>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      ac9391da
  2. 18 4月, 2018 5 次提交
  3. 17 4月, 2018 4 次提交
  4. 12 4月, 2018 1 次提交
  5. 27 3月, 2018 1 次提交
  6. 19 3月, 2018 1 次提交
  7. 13 3月, 2018 1 次提交
  8. 15 9月, 2017 2 次提交
  9. 30 6月, 2017 3 次提交
  10. 10 6月, 2017 1 次提交
  11. 09 6月, 2017 1 次提交
  12. 08 6月, 2017 3 次提交
  13. 19 4月, 2017 1 次提交
  14. 12 4月, 2017 1 次提交
  15. 28 2月, 2017 1 次提交
  16. 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
  17. 13 1月, 2017 1 次提交
  18. 15 12月, 2016 2 次提交
  19. 12 12月, 2016 1 次提交
  20. 05 12月, 2016 2 次提交
  21. 09 11月, 2016 1 次提交
  22. 05 11月, 2016 5 次提交