1. 09 Jan, 2020 5 commits
    • 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 3 commits