1. 28 Jan, 2019 25 commits
  2. 25 Jan, 2019 4 commits
  3. 24 Jan, 2019 1 commit
  4. 22 Jan, 2019 1 commit
  5. 21 Jan, 2019 7 commits
  6. 18 Jan, 2019 2 commits
    • Kuninori Morimoto's avatar
      ASoC: soc.h: add explanation of legacy/modern style of dai_link · 62bc79d3
      Kuninori Morimoto authored
      Current ALSA SoC is assuming 1 CPU 1 Platform (= DMA) style system.
      Because of this background, it is directly using
      xxx_name / xxx_of_node / xxx_dai_name on dai_link.
      Let's call it as legacy style here.
      
      More complex style system like multi CPU multi Platform (= DMA) will
      coming. To supporting it, we can use snd_soc_dai_link_component on
      dai_link. Let's call it as modern style here.
      But current ALSA SoC can't support it so far. Thus, we need to have
      multi CPU / multi Codec / multi Platform style in the future on ALSA SoC.
      
      Currently we already have multi Codec support. Platform is starting to
      use modern style on dai_link, but still style only. Multi Platform is
      not yet implemented. And we still don't have multi CPU support on ALSA
      SoC, and not have modern style either.
      
      Currently, if driver is using legacy style Codec/Platform, it will be
      converted to modern style on soc-core. This means, we are using glue code
      for legacy vs modern style so far on ALSA SoC.
      We can fully switch to modern style on all drivers if ALSA SoC supported
      modern style for CPU, and then, legacy style code will be removed from
      ALSA SoC.
      Untile then, we need to keep both legacy/modern style and its glue code.
      This patch adds such future plan and background on soc.h
      Signed-off-by: default avatarKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      62bc79d3
    • Mark Brown's avatar
      Merge tag 'asoc-fix-v5.0-rc2' into asoc-5.1 · f557d39a
      Mark Brown authored
      ASoC: Fixes for v5.0
      
      Quite a big batch of fixes here.  There's a couple of things going on,
      the main one is that we found some issues with not deferring probe when
      we should, causing us to skip some driver initialization.  The fixes for
      this then in turn exposed some issues with how we were searching for
      components which had previously gone unnoticed due to the original
      issue.
      
      There's also been the normal driver specific stuff and there's been what
      looks like several batches of automated scanning for issues which have
      generated quite a large set of smaller fixes for potential crashes and
      missed error handling.
      f557d39a