1. 20 May, 2022 4 commits
  2. 19 May, 2022 12 commits
  3. 17 May, 2022 18 commits
  4. 16 May, 2022 6 commits
    • Mark Brown's avatar
      ASoC: fsl_sai: Add support for i.MX8MM, MP, ULP · dba2d5ae
      Mark Brown authored
      Merge series from Shengjiu Wang <shengjiu.wang@nxp.com>:
      
      ASoC: fsl_sai: Add support for i.MX8MM, MP, ULP platforms
      dba2d5ae
    • Mark Brown's avatar
      firmware: mtk: add adsp ipc protocol for SOF · 0af9de0e
      Mark Brown authored
      Merge series from Tinghan Shen <tinghan.shen@mediatek.com>:
      
      This patch provides mediatek adsp ipc support for SOF.
      ADSP IPC protocol offers (send/recv) interfaces using
      mediatek-mailbox APIs.
      
      This patch was tested and confirmed to work with SOF fw on
      MT8195 cherry board and MT8186 krabby board.
      
      changes since v8:
      - fix patchset 2 and 3.
        move "depends on MTK_ADSP_IPC" from SND_SOC_SOF_MTK_COMMON
        to SND_SOC_SOF_MT8195/MT8186 to prevent generating wrong
        config.
      
      changes since v7:
      - rebase to linux-next/next-22020504
      - use EXPORT_SYMBOL_GPL instead of EXPORT_SYMBOL in mtk-adsp-ipc.c
      - move mtk-adsp-ipc.c out from driver/firmware/mediatek
      - add user of mtk-adsp-ipc.h in patchset 2 and 3.
      
      changes since v6:
      - rebase to matthias.bgg/linux.git, v5.18-next/soc
      - Prefer "GPL" over "GPL v2" for MODULE_LICENSE
      
      changes since v5:
      - fix WARNING: modpost: missing MODULE_LICENSE() in drivers/mailbox
        /mtk-adsp-mailbox.o. Add MODULE_LICENSE in the last line.
      - Due to WARNING: Missing or malformed SPDX-License-Identifier tag
        in line 1 in checkpatch, we don't remove SPDX-License in line 1.
      
      changes since v4:
      - add error message for wrong mbox chan
      
      changes since v3:
      - rebase on v5.16-rc8
      - update reviewers
      
      changes since v2:
      - add out tag for two memory free phases
      
      changes since v1:
      - add comments for mtk_adsp_ipc_send and mtk_adsp_ipc_recv
      - remove useless MODULE_LICENSE
      - change label name to out_free
      
      Allen-KH Cheng (1):
        ASoC: SOF: mediatek: Add ipc support for mt8195
      
      TingHan Shen (1):
        firmware: mediatek: add adsp ipc protocol interface
      
      Tinghan Shen (1):
        ASoC: SOF: mediatek: Add mt8186 ipc support
      
       drivers/firmware/Kconfig                      |   9 +
       drivers/firmware/Makefile                     |   1 +
       drivers/firmware/mtk-adsp-ipc.c               | 157 ++++++++++++++++++
       .../linux/firmware/mediatek/mtk-adsp-ipc.h    |  65 ++++++++
       sound/soc/sof/mediatek/Kconfig                |   2 +
       sound/soc/sof/mediatek/adsp_helper.h          |  12 +-
       sound/soc/sof/mediatek/mt8186/mt8186-loader.c |   5 +
       sound/soc/sof/mediatek/mt8186/mt8186.c        | 141 ++++++++++++++++
       sound/soc/sof/mediatek/mt8195/mt8195.c        | 138 ++++++++++++++-
       9 files changed, 519 insertions(+), 11 deletions(-)
       create mode 100644 drivers/firmware/mtk-adsp-ipc.c
       create mode 100644 include/linux/firmware/mediatek/mtk-adsp-ipc.h
      
      --
      2.18.0
      0af9de0e
    • Lin Ma's avatar
      ASoC: rt5645: Fix errorenous cleanup order · 2def44d3
      Lin Ma authored
      There is a logic error when removing rt5645 device as the function
      rt5645_i2c_remove() first cancel the &rt5645->jack_detect_work and
      delete the &rt5645->btn_check_timer latter. However, since the timer
      handler rt5645_btn_check_callback() will re-queue the jack_detect_work,
      this cleanup order is buggy.
      
      That is, once the del_timer_sync in rt5645_i2c_remove is concurrently
      run with the rt5645_btn_check_callback, the canceled jack_detect_work
      will be rescheduled again, leading to possible use-after-free.
      
      This patch fix the issue by placing the del_timer_sync function before
      the cancel_delayed_work_sync.
      Signed-off-by: default avatarLin Ma <linma@zju.edu.cn>
      Link: https://lore.kernel.org/r/20220516092035.28283-1-linma@zju.edu.cnSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      2def44d3
    • Charles Keepax's avatar
      ASoC: soc-component: Update handling to component delays · 232213bd
      Charles Keepax authored
      Currently the checking for if a component sits on the CPU or CODEC side
      of the DAI link is done with a helper function that checks if the
      component defines legacy_dai_naming. However, there are already a couple
      of CPU side components that explicitly opt in to non-legacy DAI naming
      and it doesn't seem like a very robust solution. Rather than looking for
      the flag check if the component is attached to any of the CODEC DAIs on
      the DAI link. This is more robust and helps to bring the core further in
      the direction of a component being a generic block rather than being
      classified as platform or CODEC drivers.
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Link: https://lore.kernel.org/r/20220513090532.1450944-3-ckeepax@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      232213bd
    • Charles Keepax's avatar
      ASoC: core: Pass legacy_dai_naming flag directly · 8c8a0f01
      Charles Keepax authored
      Passing the result of the helper function snd_soc_component_is_codec
      to snd_soc_register_dai is less clear than just passing the DAI
      naming flag directly. snd_soc_register_dai wants to know if it
      should use the legacy DAI naming. The CODEC distinction is more
      of a historical thing and not obviously directly related, and there
      are already a couple of CPU side components that explicitly opt in
      to non-legacy DAI naming.
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.cirrus.com>
      Link: https://lore.kernel.org/r/20220513090532.1450944-2-ckeepax@opensource.cirrus.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      8c8a0f01
    • Charles Keepax's avatar