1. 09 Jan, 2020 7 commits
    • Mark Brown's avatar
      Merge tag 'sdw_interfaces_5.6' of... · c23ff4b3
      Mark Brown authored
      Merge tag 'sdw_interfaces_5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire into asoc-5.6
      
      SoundWire tag for ASoC
      
      This contains the recently merged soundwire interface changes for ASoC
      subsystem.
      c23ff4b3
    • Srinivas Kandagatla's avatar
      ASoC: codecs: add wsa881x amplifier support · a0aab9e1
      Srinivas Kandagatla authored
      This patch adds support to WSA8810/WSA8815 Class-D Smart Speaker
      Amplifier. This Amplifier is primarily interfaced with SoundWire.
      One WSA is used for mono speaker configuration and second one
      would give stereo setup.
      
      This patch is tested on SDM845 based DragonBoard DB845c and
      Lenovo YOGA C630 Laptop based on SDM850 with WSA8815
      speaker amplifiers.
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Reviewed-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Link: https://lore.kernel.org/r/20200107135929.3267-3-srinivas.kandagatla@linaro.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      a0aab9e1
    • Srinivas Kandagatla's avatar
      dt-bindings: ASoC: Add WSA881x bindings · fbcdf32f
      Srinivas Kandagatla authored
      This patch adds bindings for WSA8810/WSA8815 Class-D Smart Speaker
      Amplifier. This Amplifier also has a simple thermal sensor for
      over temperature and speaker protection.
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Reviewed-by: default avatarRob Herring <robh@kernel.org>
      Link: https://lore.kernel.org/r/20200107135929.3267-2-srinivas.kandagatla@linaro.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      fbcdf32f
    • Marek Szyprowski's avatar
      ASoC: max98090: fix lockdep warning · 2dc98af6
      Marek Szyprowski authored
      Commit 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing
      sensitive registers") extended the code for handling many controls by
      adding a custom put function to them. That new custom put function
      properly handles relations between codec's hardware registers. However
      they used card->dapm_mutex to properly serialize those operations. This
      in turn triggers a lockdep warning about possible circular dependency.
      Fix this by introducing a separate mutex only for serializing the SHDN
      hardware register related operations.
      
      This fixes the following lockdep warning observed on Exynos4412-based
      Odroid U3 board:
      ======================================================
      WARNING: possible circular locking dependency detected
      5.5.0-rc5-next-20200107 #166 Not tainted
      ------------------------------------------------------
      alsactl/1104 is trying to acquire lock:
      ed0d50f4 (&card->dapm_mutex){+.+.}, at: max98090_shdn_save+0x1c/0x28
      
      but task is already holding lock:
      edb4b49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&card->controls_rwsem){++++}:
             snd_ctl_add_replace+0x3c/0x84
             dapm_create_or_share_kcontrol+0x24c/0x2e0
             snd_soc_dapm_new_widgets+0x308/0x594
             snd_soc_bind_card+0x80c/0xad4
             devm_snd_soc_register_card+0x34/0x6c
             odroid_audio_probe+0x288/0x34c
             platform_drv_probe+0x6c/0xa4
             really_probe+0x200/0x490
             driver_probe_device+0x78/0x1f8
             bus_for_each_drv+0x74/0xb8
             __device_attach+0xd4/0x16c
             bus_probe_device+0x88/0x90
             deferred_probe_work_func+0x3c/0xd0
             process_one_work+0x22c/0x7c4
             worker_thread+0x44/0x524
             kthread+0x130/0x164
             ret_from_fork+0x14/0x20
             0x0
      
      -> #0 (&card->dapm_mutex){+.+.}:
             lock_acquire+0xe8/0x270
             __mutex_lock+0x9c/0xb18
             mutex_lock_nested+0x1c/0x24
             max98090_shdn_save+0x1c/0x28
             max98090_put_enum_double+0x20/0x40
             snd_ctl_ioctl+0x190/0xbb8
             ksys_ioctl+0x470/0xaf8
             ret_fast_syscall+0x0/0x28
             0xbefaa564
      
      other info that might help us debug this:
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock(&card->controls_rwsem);
                                     lock(&card->dapm_mutex);
                                     lock(&card->controls_rwsem);
        lock(&card->dapm_mutex);
      
       *** DEADLOCK ***
      
      1 lock held by alsactl/1104:
       #0: edb4b49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8
      
      stack backtrace:
      CPU: 0 PID: 1104 Comm: alsactl Not tainted 5.5.0-rc5-next-20200107 #166
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      (unwind_backtrace) from [<c010e180>] (show_stack+0x10/0x14)
      (show_stack) from [<c0b2a09c>] (dump_stack+0xb4/0xe0)
      (dump_stack) from [<c018a1c0>] (check_noncircular+0x1ec/0x208)
      (check_noncircular) from [<c018c5dc>] (__lock_acquire+0x1210/0x25ec)
      (__lock_acquire) from [<c018e2d8>] (lock_acquire+0xe8/0x270)
      (lock_acquire) from [<c0b49678>] (__mutex_lock+0x9c/0xb18)
      (__mutex_lock) from [<c0b4a110>] (mutex_lock_nested+0x1c/0x24)
      (mutex_lock_nested) from [<c0839b3c>] (max98090_shdn_save+0x1c/0x28)
      (max98090_shdn_save) from [<c083a5b8>] (max98090_put_enum_double+0x20/0x40)
      (max98090_put_enum_double) from [<c080d0e8>] (snd_ctl_ioctl+0x190/0xbb8)
      (snd_ctl_ioctl) from [<c02cafec>] (ksys_ioctl+0x470/0xaf8)
      (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
      ...
      
      Fixes: 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing sensitive registers")
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Link: https://lore.kernel.org/r/20200108115007.31095-2-m.szyprowski@samsung.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      2dc98af6
    • Marek Szyprowski's avatar
      ASoC: max98090: fix incorrect helper in max98090_dapm_put_enum_double() · 4e93c129
      Marek Szyprowski authored
      Commit 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing
      sensitive registers") extended the code for handling "LTENL Mux", "LTENR
      Mux", "LBENL Mux" and "LBENR Mux" controls by adding a custom
      max98090_dapm_put_enum_double() function to them. However that function
      used incorrect helper to get its component object. Fix this by using the
      proper snd_soc_dapm_* helper.
      
      This fixes the following NULL pointer exception observed on
      Exynos4412-based Odroid U3 board:
      8<--- cut here ---
      Unable to handle kernel NULL pointer dereference at virtual address 000000b0
      pgd = (ptrval)
      [000000b0] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 0 PID: 1104 Comm: alsactl Not tainted 5.5.0-rc5-next-20200107 #166
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      PC is at __mutex_lock+0x54/0xb18
      LR is at ___might_sleep+0x3c/0x2e0
      ...
      Process alsactl (pid: 1104, stack limit = 0x(ptrval))
      ...
      [<c0b49630>] (__mutex_lock) from [<c0b4a110>] (mutex_lock_nested+0x1c/0x24)
      [<c0b4a110>] (mutex_lock_nested) from [<c0839b3c>] (max98090_shdn_save+0x1c/0x28)
      [<c0839b3c>] (max98090_shdn_save) from [<c083a4f8>] (max98090_dapm_put_enum_double+0x20/0x40)
      [<c083a4f8>] (max98090_dapm_put_enum_double) from [<c080d0e8>] (snd_ctl_ioctl+0x190/0xbb8)
      [<c080d0e8>] (snd_ctl_ioctl) from [<c02cafec>] (ksys_ioctl+0x470/0xaf8)
      [<c02cafec>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
      ...
      ---[ end trace 0e93f0580f4b9241 ]---
      
      Fixes: 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing sensitive registers")
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Reviewed-by: default avatarTzung-Bi Shih <tzungbi@google.com>
      Link: https://lore.kernel.org/r/20200108115007.31095-1-m.szyprowski@samsung.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      4e93c129
    • Marek Szyprowski's avatar
      ASoC: max98090: fix incorrect helper in max98090_dapm_put_enum_double() · 1d7b0518
      Marek Szyprowski authored
      Commit 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing
      sensitive registers") extended the code for handling "LTENL Mux", "LTENR
      Mux", "LBENL Mux" and "LBENR Mux" controls by adding a custom
      max98090_dapm_put_enum_double() function to them. However that function
      used incorrect helper to get its component object. Fix this by using the
      proper snd_soc_dapm_* helper.
      
      This fixes the following NULL pointer exception observed on
      Exynos4412-based Odroid U3 board:
      8<--- cut here ---
      Unable to handle kernel NULL pointer dereference at virtual address 000000b0
      pgd = (ptrval)
      [000000b0] *pgd=00000000
      Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      Modules linked in:
      CPU: 0 PID: 1104 Comm: alsactl Not tainted 5.5.0-rc5-next-20200107 #166
      Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      PC is at __mutex_lock+0x54/0xb18
      LR is at ___might_sleep+0x3c/0x2e0
      ...
      Process alsactl (pid: 1104, stack limit = 0x(ptrval))
      ...
      [<c0b49630>] (__mutex_lock) from [<c0b4a110>] (mutex_lock_nested+0x1c/0x24)
      [<c0b4a110>] (mutex_lock_nested) from [<c0839b3c>] (max98090_shdn_save+0x1c/0x28)
      [<c0839b3c>] (max98090_shdn_save) from [<c083a4f8>] (max98090_dapm_put_enum_double+0x20/0x40)
      [<c083a4f8>] (max98090_dapm_put_enum_double) from [<c080d0e8>] (snd_ctl_ioctl+0x190/0xbb8)
      [<c080d0e8>] (snd_ctl_ioctl) from [<c02cafec>] (ksys_ioctl+0x470/0xaf8)
      [<c02cafec>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
      ...
      ---[ end trace 0e93f0580f4b9241 ]---
      
      Fixes: 62d5ae4c ("ASoC: max98090: save and restore SHDN when changing sensitive registers")
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Reviewed-by: default avatarTzung-Bi Shih <tzungbi@google.com>
      Link: https://lore.kernel.org/r/20200108115007.31095-1-m.szyprowski@samsung.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      1d7b0518
    • Wei Yongjun's avatar
      ASoC: amd: acp3x: Fix return value check in acp3x_dai_probe() · f0df2e65
      Wei Yongjun authored
      In case of error, the function devm_ioremap() returns NULL pointer not
      ERR_PTR(). The IS_ERR() test in the return value check should be
      replaced with NULL test.
      
      Fixes: c9fe7db6 ("ASoC: amd: Refactoring of DAI from DMA driver")
      Signed-off-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Link: https://lore.kernel.org/r/20200108035954.51317-1-weiyongjun1@huawei.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      f0df2e65
  2. 07 Jan, 2020 3 commits
  3. 06 Jan, 2020 1 commit
    • Sam McNally's avatar
      ASoC: Intel: sof_rt5682: Ignore the speaker amp when there isn't one. · d4b74e21
      Sam McNally authored
      Some members of the Google_Hatch family include a rt5682 jack codec, but
      no speaker amplifier. This uses the same driver (sof_rt5682) as a
      combination of rt5682 jack codec and max98357a speaker amplifier. Within
      the sof_rt5682 driver, these cases are not currently distinguishable,
      relying on a DMI quirk to decide the configuration. This causes an
      incorrect configuration when only the rt5682 is present on a
      Google_Hatch device.
      
      For CML, the jack codec is used as the primary key when matching,
      with a possible speaker amplifier described in quirk_data. The two cases
      of interest are the second and third 10EC5682 entries in
      snd_soc_acpi_intel_cml_machines[]. The second entry matches the
      combination of rt5682 and max98357a, resulting in the quirk_data field
      in the snd_soc_acpi_mach being non-null, pointing at
      max98357a_spk_codecs, the snd_soc_acpi_codecs for the matched speaker
      amplifier. The third entry matches just the rt5682, resulting in a null
      quirk_data.
      
      The sof_rt5682 driver's DMI data matching identifies that a speaker
      amplifier is present for all Google_Hatch family devices. Detect cases
      where there is no speaker amplifier by checking for a null quirk_data in
      the snd_soc_acpi_mach and remove the speaker amplifier bit in that case.
      Signed-off-by: default avatarSam McNally <sammc@chromium.org>
      Acked-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Link: https://lore.kernel.org/r/20200103124921.v3.1.Ib87c4a7fbb3fc818ea12198e291b87dc2d5bc8c2@changeidSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      d4b74e21
  4. 03 Jan, 2020 2 commits
  5. 01 Jan, 2020 2 commits
  6. 31 Dec, 2019 9 commits
  7. 27 Dec, 2019 1 commit
  8. 25 Dec, 2019 14 commits
  9. 24 Dec, 2019 1 commit
    • Daniel Baluta's avatar
      ASoC: SOF: imx8: Fix dsp_box offset · dcf08d0f
      Daniel Baluta authored
      dsp_box is used to keep DSP initiated messages. The value of dsp_offset
      is set by the DSP with the first message, so we need a way to bootstrap
      it in order to get the first message.
      
      We do this by setting the correct default dsp_box offset which on i.MX8
      is not zero.
      
      Very interesting is why it has worked until now.
      
      On i.MX8, DSP communicates with ARM core using a shared SDRAM memory
      area. Actually, there are two shared areas:
      	* SDRAM0 - starting at 0x92400000, size 0x800000
      	* SDRAM1 - starting at 0x92C00000, size 0x800000
      
      SDRAM0 keeps the data sections, starting with .rodata. By chance
      fw_ready structure was placed at the beginning of .rodata.
      
      dsp_box_base is defined as SDRAM0 + dsp_box_offset and it is placed
      at the beginning of SDRAM1 (dsp_box_offset should be 0x800000). But
      because it is zero initialized by default it points to SDRAM0 where
      by chance the fw_ready was placed in the SOF firmware.
      
      Anyhow, SOF commit 7466bee378dd811b ("clk: make freq arrays constant")
      fw_ready is no longer at the beginning of SDRAM0 and everything shows
      how lucky we were until now.
      
      Fix this by properly setting the default dsp_box offset.
      
      Fixes: 202acc56 ("ASoC: SOF: imx: Add i.MX8 HW support")
      Signed-off-by: default avatarDaniel Baluta <daniel.baluta@nxp.com>
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Link: https://lore.kernel.org/r/20191220170531.10423-1-pierre-louis.bossart@linux.intel.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      dcf08d0f