1. 14 Jan, 2020 7 commits
  2. 13 Jan, 2020 16 commits
  3. 10 Jan, 2020 11 commits
  4. 09 Jan, 2020 6 commits
    • Shuming Fan's avatar
    • 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
    • Olivier Moysan's avatar
      ASoC: stm32: sai: fix possible circular locking · a14bf98c
      Olivier Moysan authored
      In current driver, locks can be taken as follows:
      - Register access: take a lock on regmap config and then on clock.
      - Master clock provider: take a lock on clock and then on regmap config.
      This can lead to the circular locking summarized below.
      
      Remove peripheral clock management through regmap framework, and manage
      peripheral clock in driver instead. On register access, lock on clock
      is taken first, which allows to avoid possible locking issue.
      
      [ 6696.561513] ======================================================
      [ 6696.567670] WARNING: possible circular locking dependency detected
      [ 6696.573842] 4.19.49 #866 Not tainted
      [ 6696.577397] ------------------------------------------------------
      [ 6696.583566] pulseaudio/6439 is trying to acquire lock:
      [ 6696.588697] 87b0a25b (enable_lock){..-.}, at: clk_enable_lock+0x64/0x128
      [ 6696.595377]
      [ 6696.595377] but task is already holding lock:
      [ 6696.601197] d858f825 (stm32_sai_sub:1342:(sai->regmap_config)->lock){....}
      ...
      [ 6696.812513]  Possible unsafe locking scenario:
      [ 6696.812513]
      [ 6696.818418]        CPU0                    CPU1
      [ 6696.822935]        ----                    ----
      [ 6696.827451]   lock(stm32_sai_sub:1342:(sai->regmap_config)->lock);
      [ 6696.833618]                                lock(enable_lock);
      [ 6696.839350]                                lock(stm32_sai_sub:1342:
                                                    (sai->regmap_config)->lock);
      [ 6696.848035]   lock(enable_lock);
      
      Fixes: 03e78a24 ("ASoC: stm32: sai: add h7 support")
      Signed-off-by: default avatarOlivier Moysan <olivier.moysan@st.com>
      Link: https://lore.kernel.org/r/20200109083254.478-1-olivier.moysan@st.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      a14bf98c
    • 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