1. 20 Jan, 2020 2 commits
    • Takashi Iwai's avatar
      Merge branch 'for-linus' into for-next · 9d0af44c
      Takashi Iwai authored
      Resolved the merge conflict in HD-audio Tegra driver.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      9d0af44c
    • Takashi Iwai's avatar
      ALSA: hda: Apply aligned MMIO access only conditionally · 4d024fe8
      Takashi Iwai authored
      It turned out that the recent simplification of HD-audio bus access
      helpers caused a regression on the virtual HD-audio device on QEMU
      with ARM platforms.  The driver got a CORB/RIRB timeout and couldn't
      probe any codecs.
      
      The essential difference that caused a problem was the enforced
      aligned MMIO accesses by simplification.  Since snd-hda-tegra driver
      is enabled on ARM, it enables CONFIG_SND_HDA_ALIGNED_MMIO, which makes
      the all HD-audio drivers using the aligned MMIO accesses.  While this
      is mandatory for snd-hda-tegra, it seems that snd-hda-intel on ARM
      gets broken by this access pattern.
      
      For addressing the regression, this patch introduces a new flag,
      aligned_mmio, to hdac_bus object, and applies the aligned MMIO only
      when this flag is set.  This change affects only platforms with
      CONFIG_SND_HDA_ALIGNED_MMIO set, i.e. mostly only for ARM platforms.
      
      Unfortunately the patch became a big bigger than it should be, just
      because the former calls didn't take hdac_bus object in the argument,
      hence we had to extend the call patterns.
      
      Fixes: 19abfefd ("ALSA: hda: Direct MMIO accesses")
      BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1161152
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20200120104127.28985-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      4d024fe8
  2. 17 Jan, 2020 1 commit
  3. 16 Jan, 2020 4 commits
  4. 15 Jan, 2020 2 commits
  5. 14 Jan, 2020 4 commits
  6. 13 Jan, 2020 17 commits
  7. 12 Jan, 2020 3 commits
  8. 11 Jan, 2020 2 commits
    • Takashi Iwai's avatar
      Merge branch 'for-linus' into for-next · 3cdca6d6
      Takashi Iwai authored
      Sync 5.5-devel branch once again for applying the HD-audio fixes.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      3cdca6d6
    • Takashi Iwai's avatar
      ALSA: hda: Rename back to dmic_detect option · 7fba6aea
      Takashi Iwai authored
      We've got quite a few bug reports showing the SOF driver being loaded
      unintentionally recently, and the reason seems to be that users didn't
      know the module option change: with the recent kernel, a new option
      dsp_driver=1 has to be passed to a new module snd-intel-dspcfg
      instead of snd_hda_intel.dmic_detect=0 option.
      
      That is, actually there are two tricky things here:
      - We changed the whole detection in another module and another
        option semantics.
      - The existing option for skipping the DSP probe was also renamed.
      
      For avoiding the confusion and giving user more hint, this patch
      reverts the renamed option dsp_driver back to dmic_detect for
      snd-hda-intel module, and show the warning about the module option
      change when the non-default value is passed.
      
      Fixes: 82d9d54a ("ALSA: hda: add Intel DSP configuration / probe code")
      Link: https://lore.kernel.org/r/20200109082000.26729-1-tiwai@suse.deSigned-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      7fba6aea
  9. 10 Jan, 2020 1 commit
  10. 09 Jan, 2020 1 commit
    • 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
  11. 08 Jan, 2020 3 commits