1. 20 Nov, 2020 6 commits
    • Mark Brown's avatar
      Merge series "ASoC: Intel/SOF: extend run-time driver selection to ACPI... · 991e74d1
      Mark Brown authored
      Merge series "ASoC: Intel/SOF: extend run-time driver selection to ACPI devices" from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
      
      The module snd-intel-dspcfg, suggested by Jaroslav last year,
      currently provide the means to select a PCI driver at run-time, based
      on quirks, recommendations or user selection via a kernel
      parameter. This capability removed a lot of confusions in
      distributions and removed the need for recompilations to select legacy
      HDaudio, SST or SOF drivers.
      
      This patchset extends the concept to ACPI devices. This was driven by
      the desire to at some point deprecate the Atom/SST driver for Baytrail
      and Cherrytrail, which is no longer maintained by Intel. By having the
      SOF driver enabled by distributions for Baytrail/Cherrytrail, we can
      enable more end-user tests and make the transition easier for
      distributions (likely in 2021 at this point).
      
      This patchset provides the same solution for Broadwell, mainly to have
      a single build for all Intel platforms. SOF on Broadwell remains an
      option not recommended for distributions, as long as the 'catpt'
      driver is maintained there is no burning desire to make SOF the
      default on the three Broadwell-based platforms with the DSP
      enabled.
      
      Pierre-Louis Bossart (14):
        ASoC: Intel: broadwell: add missing pm_ops
        ASoC: Intel: bdw-rt5677: add missing pm_ops
        ALSA: hda: intel-dsp-config: add helper for ACPI DSP driver selection
        ASoC: soc-acpi: add helper to identify parent driver.
        ASoC: Intel: boards: byt/cht: set card and driver name at run time
        ASoC: Intel: byt/cht: set pm ops dynamically
        ASoC: SOF: acpi: add dynamic selection of DSP driver
        ASoC: Intel: Atom: add dynamic selection of DSP driver
        ASoC: SOF: Intel: allow for coexistence between SOF and Atom/SST
          drivers
        ALSA: hda: intel-dsp-config: add Broadwell ACPI DSP driver selection
        ASoC: Intel: broadwell: set card and driver name dynamically
        ASoC: Intel: catpt: add dynamic selection of DSP driver
        ASoC: SOF: Intel: allow for coexistence between SOF and catpt drivers
        ALSA: hda: intel-dsp-config: ignore dsp_driver parameter for PCI
          legacy devices
      
       include/sound/intel-dsp-config.h             |   7 ++
       include/sound/soc-acpi.h                     |   6 +
       sound/hda/intel-dsp-config.c                 | 111 +++++++++++++++++++
       sound/soc/intel/Kconfig                      |   2 +
       sound/soc/intel/atom/sst/sst_acpi.c          |   8 ++
       sound/soc/intel/boards/bdw-rt5650.c          |  17 ++-
       sound/soc/intel/boards/bdw-rt5677.c          |  18 ++-
       sound/soc/intel/boards/broadwell.c           |  20 ++--
       sound/soc/intel/boards/bytcht_cx2072x.c      |  27 +++--
       sound/soc/intel/boards/bytcht_da7213.c       |  27 +++--
       sound/soc/intel/boards/bytcht_es8316.c       |  29 +++--
       sound/soc/intel/boards/bytcr_rt5640.c        |  30 +++--
       sound/soc/intel/boards/bytcr_rt5651.c        |  27 +++--
       sound/soc/intel/boards/cht_bsw_max98090_ti.c |  29 +++--
       sound/soc/intel/boards/cht_bsw_nau8824.c     |  29 +++--
       sound/soc/intel/boards/cht_bsw_rt5645.c      |  38 ++++---
       sound/soc/intel/boards/cht_bsw_rt5672.c      |  29 +++--
       sound/soc/intel/catpt/device.c               |  12 ++
       sound/soc/sof/intel/Kconfig                  |  33 +++---
       sound/soc/sof/sof-acpi-dev.c                 |  14 ++-
       20 files changed, 392 insertions(+), 121 deletions(-)
      
      --
      2.25.1
      991e74d1
    • Dmitry Baryshkov's avatar
      ASoC: qcom: sm8250: fix HDMI audio playback · ddf1c4b3
      Dmitry Baryshkov authored
      Current code does not setup CPU dai (causing -EIO errors on playback)
      and does not pass SND_SOC_DAIFMT_I2S to codec fmt (causing i2s-hifi
      errors). Fix both errors to enable HDMI audio playback on SM8250. Tested
      on RB5 platform.
      Signed-off-by: default avatarDmitry Baryshkov <dmitry.baryshkov@linaro.org>
      Fixes: aa2e2785 ("ASoC: qcom: sm8250: add sound card qrb5165-rb5 support")
      Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Reviewed-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Link: https://lore.kernel.org/r/20201119123145.709891-1-dmitry.baryshkov@linaro.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      ddf1c4b3
    • Kyle Russell's avatar
      ASoC: mmp-sspa: set phase two word length register · 82d1aeb8
      Kyle Russell authored
      If hw params enables dual phase transmission, then the word length for
      the second phase should be set to match the sample format instead of
      remaining at the reset default.  This matches the configuration already
      being done for the first phase.
      
      This driver already sets the phase two sample size, so this should complete
      the phase two configuration.
      Signed-off-by: default avatarKyle Russell <bkylerussell@gmail.com>
      Link: https://lore.kernel.org/r/20201119034106.1273906-1-bkylerussell@gmail.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      82d1aeb8
    • Srinivas Kandagatla's avatar
      ASoC: codecs: lpass-va-macro: add missing MODULE_DEVICE_TABLE · 2b3f6f4a
      Srinivas Kandagatla authored
      Fix module loading due by adding missing MODULE_DEVICE_TABLE.
      
      Fixes: 908e6b1d ("ASoC: codecs: lpass-va-macro: Add support to VA Macro")
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Link: https://lore.kernel.org/r/20201120123813.14059-1-srinivas.kandagatla@linaro.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      2b3f6f4a
    • Rob Herring's avatar
      ASoC: dt-bindings: renesas, rsnd: Fix duplicate 'allOf' entries · 73d2784e
      Rob Herring authored
      Commit e52f3f29 ("ASoC: audio-graph-card: Refactor schema") added an
      'allOf' entry, but one is already present in the schema. Multiple keys
      is not valid and results in an error:
      
      ruamel.yaml.constructor.DuplicateKeyError: while constructing a mapping
        in "<unicode string>", line 4, column 1
      found duplicate key "allOf" with value "[]" (original value: "[]")
        in "<unicode string>", line 262, column 1
      
      Fixes: e52f3f29 ("ASoC: audio-graph-card: Refactor schema")
      Cc: Liam Girdwood <lgirdwood@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
      Cc: Sameer Pujar <spujar@nvidia.com>
      Cc: alsa-devel@alsa-project.org
      Signed-off-by: default avatarRob Herring <robh@kernel.org>
      Link: https://lore.kernel.org/r/20201119161848.3379929-1-robh@kernel.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      73d2784e
    • Jaska Uimonen's avatar
      ASoC: SOF: control: override volume info callback · fca18e62
      Jaska Uimonen authored
      ASoC dapm controls currently don't support more than 2 channels. This is
      a problem for SOF-based devices where individual volume control cannot
      be provided on the 4 DMIC input path.
      
      If we want to provide controls for more than 2 channels, this patch
      suggests a simple solution based on an override of the info callback.
      For example, in the case with 4 channel DMIC PGAs, a sof_info callback
      would be used. Mono and stereo cases will keep using the existing dapm
      info callback.
      
      A longer-term solution would be to remove the limits to 2 channels in
      ASoC/DAPM/topology. This is a topic Intel is currently looking into,
      e.g. by removing the use of 'reg' and 'rreg' fields and use arrays
      instead. Such changes will be rather intrusive and touch multiple codec
      and platform drivers. Removing restrictions is the right thing to do,
      but this will need to be done in steps with lots of validation.
      Signed-off-by: default avatarJaska Uimonen <jaska.uimonen@linux.intel.com>
      Reviewed-by: default avatarRanjani Sridharan <ranjani.sridharan@linux.intel.com>
      Reviewed-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarKai Vehmanen <kai.vehmanen@linux.intel.com>
      Link: https://lore.kernel.org/r/20201111173105.1927466-1-kai.vehmanen@linux.intel.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      fca18e62
  2. 19 Nov, 2020 27 commits
  3. 18 Nov, 2020 7 commits