1. 01 Jul, 2024 4 commits
  2. 26 Jun, 2024 2 commits
  3. 24 Jun, 2024 1 commit
    • Chen-Yu Tsai's avatar
      ASoC: mediatek: mt8195: Add platform entry for ETDM1_OUT_BE dai link · 282a4482
      Chen-Yu Tsai authored
      Commit e70b8dd2 ("ASoC: mediatek: mt8195: Remove afe-dai component
      and rework codec link") removed the codec entry for the ETDM1_OUT_BE
      dai link entirely instead of replacing it with COMP_EMPTY(). This worked
      by accident as the remaining COMP_EMPTY() platform entry became the codec
      entry, and the platform entry became completely empty, effectively the
      same as COMP_DUMMY() since snd_soc_fill_dummy_dai() doesn't do anything
      for platform entries.
      
      This causes a KASAN out-of-bounds warning in mtk_soundcard_common_probe()
      in sound/soc/mediatek/common/mtk-soundcard-driver.c:
      
      	for_each_card_prelinks(card, i, dai_link) {
      		if (adsp_node && !strncmp(dai_link->name, "AFE_SOF", strlen("AFE_SOF")))
      			dai_link->platforms->of_node = adsp_node;
      		else if (!dai_link->platforms->name && !dai_link->platforms->of_node)
      			dai_link->platforms->of_node = platform_node;
      	}
      
      where the code expects the platforms array to have space for at least one entry.
      
      Add an COMP_EMPTY() entry so that dai_link->platforms has space.
      
      Fixes: e70b8dd2 ("ASoC: mediatek: mt8195: Remove afe-dai component and rework codec link")
      Signed-off-by: default avatarChen-Yu Tsai <wenst@chromium.org>
      Reviewed-by: default avatarAngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
      Link: https://patch.msgid.link/20240624061257.3115467-1-wenst@chromium.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      282a4482
  4. 20 Jun, 2024 1 commit
  5. 19 Jun, 2024 3 commits
  6. 18 Jun, 2024 1 commit
  7. 14 Jun, 2024 2 commits
    • Srinivas Kandagatla's avatar
      ASoC: q6apm-lpass-dai: close graph on prepare errors · be1fae62
      Srinivas Kandagatla authored
      There is an issue around with error handling and graph management with
      the exising code, none of the error paths close the graph, which result in
      leaving the loaded graph in dsp, however the driver thinks otherwise.
      
      This can have a nasty side effect specially when we try to load the same
      graph to dsp, dsp returns error which leaves the board with no sound and
      requires restart.
      
      Fix this by properly closing the graph when we hit errors between
      open and close.
      
      Fixes: 30ad723b ("ASoC: qdsp6: audioreach: add q6apm lpass dai support")
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Reviewed-by: default avatarDmitry Baryshkov <dmitry.baryshkov@linaro.org>
      Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # X13s
      Link: https://lore.kernel.org/r/20240613-q6apm-fixes-v1-1-d88953675ab3@linaro.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      be1fae62
    • Richard Fitzgerald's avatar
      ASoC: cs35l56: Disconnect ASP1 TX sources when ASP1 DAI is hooked up · 8af49868
      Richard Fitzgerald authored
      If the ASP1 DAI is hooked up by the machine driver the ASP TX mixer
      sources should be initialized to disconnected. There aren't currently
      any available products using the ASP so this doesn't affect any
      existing systems.
      
      The cs35l56 does not have any fixed default for the mixer source
      registers. When the cs35l56 boots, its firmware patches these registers
      to setup a system-specific routing; this is so that Windows can use
      generic SDCA drivers instead of needing knowledge of chip-specific
      registers. The setup varies between end-products, which each have
      customized firmware, and so the default register state varies between
      end-products. It can also change if the firmware on an end-product is
      upgraded - for example if a change was needed to the routing for Windows
      use-cases. It must be emphasized that the settings applied by the
      firmware are not internal magic tuning; they are statically implementing
      use-case setup that on Linux would be done via ALSA controls.
      
      The driver is currently syncing the mixer controls with whatever
      initial state the firmware wrote to the registers, so that they report
      the actual audio routing. But if the ASP DAI is hooked up this can create
      a powered-up DAPM graph without anything intentionally setting up a path.
      This can lead to parts of the audio system powering up unexpectedly.
      
      For example when cs35l56 is connected to cs42l43 using a codec-codec link,
      this can create a complete DAPM graph which then powers-up cs42l43. But
      the cs42l43 can only be clocked from its SoundWire bus so this causes a
      bunch of errors in the kernel log where cs42l43 is unexpectedly powered-up
      without a clock.
      
      If the host is taking ownership of the ASP (either directly or as a
      codec-to-codec link) there is no need to keep the mixer settings that the
      firmware wrote. The driver has ALSA controls for setting these using
      standard Linux mechanisms. So if the machine driver hooks up the ASP the
      ASP mixers are initialized to "None" (no input). This prevents unintended
      DAPM-graph power-ups, and means the initial state of the mixers is
      always going to be None.
      
      Since the initial state of the mixers can vary from system to system and
      potentially between firmware upgrades, no use-case manager can currently
      assume that cs35l56 has a known initial state. The firmware could just as
      easily default them to "None" as to any input source. So defaulting them
      to "None" in the driver is not increasing the entropy of the system.
      Signed-off-by: default avatarRichard Fitzgerald <rf@opensource.cirrus.com>
      Link: https://lore.kernel.org/r/20240613132527.46537-1-rf@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      8af49868
  8. 13 Jun, 2024 1 commit
  9. 12 Jun, 2024 3 commits
  10. 11 Jun, 2024 4 commits
  11. 10 Jun, 2024 5 commits
  12. 06 Jun, 2024 1 commit
  13. 05 Jun, 2024 2 commits
  14. 04 Jun, 2024 4 commits
  15. 03 Jun, 2024 6 commits